WireLurker, a recently discovered malware combination that infects OS X computers, has been all the rage in the news. WireLurker earned its name because it spreads from an infected OS X computer to an iOS device once the IOS device is connected via USB.
Recently, my colleague Berni McCoy published a blog on the basics of WireLurker and how to avoid getting infected. Since Bit9 + Carbon Black supports Windows, OS X (Mac), and Linux, we can leverage both tools to detect and protect against WireLurker.
I am going to show you how to create Carbon Black watchlists to monitor your entire enterprise for these threats. Then I will describe how to turn these watchlists into Bit9 block rules to proactively protect your organization from them.
Recon, research, repeat: gathering data for your watchlist
I am going to skip ahead here and assume you read the WireLurker report, the detector scripts, a few more blogs on the malware, and have a decent understanding of it.
From this research, you should have generated a list of known artifacts about the malware (indicators).
My list is as follows:
Known malicious files:
- Taken from detector script:
- Found through various blogs and forums:
- The first step WireLurker takes is to append an underscore to the original bundle executable name, then copy its malicious loader into the bundle to replace the original executable.
- Next, WireLurker then adds a shell script, “start.sh”, and a ZIP archive, “FontMap1.cfg”, to the “Contents/Resources” folder of the bundle.
- To me, that means that we should look inside all subdirectories in /applications for start.sh and Fontmap1.cfg.
- The “hidden” flag is then set for these files. This flag is an Apple-specified file property defined at “/usr/include/sys/stat.h” as “UF_HIDDEN.” With this flag set, a standard user won’t see the files in the Finder, but can still view them through the Terminal.
- Look for change flag on files in /Applications.
- This idea came from one of the scripts that the malware drops
- The loader first drops an embedded script file to “/Users/Shared/run.sh”.
- Known network traffic
Now, your list may be different than mine. That’s OK. The biggest perk of the watchlists, in my opinion, is their flexibility and ease of updating/adapting to incorporate new information. Basically, the more you learn, the more the feed can be refined for efficiency and effectiveness in your environment.
Breaking your findings down into watchlists
Now that we have all of this information, we need to break it down in different ways. I suggest one of two ways:
- File system artifacts, registry artifacts, memory artifacts, and network artifacts
- High confidence, medium confidence, low confidence
Both of these approaches have their pros and cons and should be chosen based on your findings and your confidence in those finding to not produce false positives.
Creating the watchlists
I chose to go with the three-tiered confidence method. I chose this approach because of my confidence in the data gathered. I think a few of these rules could produce false positive events in my environment and because of that, I have chosen the approach that allows me to separate these possible problem rules to unique watchlists. This approach will allow me to disable any noisy watchlists without turning everything off and keep my environment quiet, secure and functional.
Watchlist 1: High Confidence
- This Watchlist will contain:
- All file paths take from the detector script
- All registry values
- All other static values I can find
Watchlist 2: Medium Confidence
- This Watchlist will contain:
- Network traffic
- Other traffic that could have potential false positive events
Watchlist 3: Low Confidence
- This Watchlist will contain:
- Any items that will most likely produce false positives
Example Carbon Black Watchlists:
(NOTE: Not all indicators from above are used in these examples. These are simply a few examples of what you would use in Carbon Black for detecting WireLurker or a similar malware using the information you gathered online.)
This watchlist contains all of the file artifacts I gathered. These are all indicators that if I see them, I know they are not false positives and that I should immediately take action. I have high confidence in these indicators and am treating them as such.
- filemod:Users/Shared/run.sh OR filemod:Library/LaunchDaemons/com.apple.machook_damon.plist OR filemod:Library/LaunchDaemons/com.apple.globalupdate.plist OR filemod:usr/bin/globalupdate/usr/local/machook/ OR filemod:usr/bin/WatchProc OR filemod:usr/bin/itunesupdate OR filemod:Library/LaunchDaemons/com.apple.watchproc.plist OR filemod:Library/LaunchDaemons/com.apple.itunesupdate.plist OR filemod:System/Library/LaunchDaemons/com.apple.appstore.plughelper.plist OR filemod:System/Library/LaunchDaemons/com.apple.MailServiceAgentHelper.plist OR filemod:System/Library/LaunchDaemons/com.apple.systemkeychain-helper.plist OR filemod:System/Library/LaunchDaemons/com.apple.periodic-dd-mm-yy.plist OR filemod:usr/bin/com.apple.MailServiceAgentHelper OR filemod:usr/bin/com.apple.appstore.PluginHelper OR filemod:usr/bin/periodicdate OR filemod:usr/bin/systemkeychain-helper OR filemod:usr/bin/stty5.11.pl OR filemod:etc/manpath.d/ OR filemod:usr/local/ipcc/
This watchlist is looking for the known domain that WireLurker connects to. Currently, there is only one known domain. This is uncommon for malware these days but not unheard of. This watchlist is kept uniquely to network traffic only to cut down on editing later on. I have high confidence in this domain being malicious. However, domains change quickly, and I do not expect this watchlist to always give me a true positive result, nor do I expect it to be around for a long time.
Therefore, I keep it separate and can easily disable it when I deem it no longer useful.
- domain: comeinbaby.com
This watchlist contains my low-confidence queries. These queries will contain false positives and I know that going into this. The reason they will fire false positives is because of how broad they are. I have high confidence that anything under “/Applications/*/start.sh” will not be legitimate but I have not tested every software ever in every environment, so I leave room for false positives.
Also, the command for chflags to hidden is not an uncommon command. It is usually not used legitimately because it hides things from finder but not from command line.
- cmdline:”/usr/bin/chflags -v hidden”
Above you can see an example of the watchlist I created for “filemod:Applications/*/start.sh.” As you can see, when I set off the watchlist with the creation of start.sh in the file path of “/Applications/TeamViewer.app/Contents/MacOS/start.sh.”
Below, you can see the drill down of the command the script used to create this file (it used the touch command).
Example Bit9 block rules:
We all want to proactively blog threats like. Below is a screen shot of the creation of a block rule in Bit9 that will not allow these files to run if they are found. The alternative to this is to keep your endpoints in high enforcement and you will not have to create custom block rules because this malware will not be allowed to run on a Bit9 protected host.
Using these types of techniques, you can find enough information online about pretty much any common threat/malware and create a watchlist for detection and a block rule for protection. In this post I used WireLurker as an example, but it could have easily been replaced with Zeus, CryptoLocker, or whatever is currently threatening your environment.
Until next time, remember my motto. Flag it, Tag it, and Bag it.