Peter Stephenson
Peter Stephenson

This week I am writing the blog jointly with a well-known threat hunter, Josh Liburdi from Sqrrl.  Josh has had a long career in threat hunting as you can see from his brief bio below so I asked him to take our sample, turn it loose in his sand box and tell us how he would go about hunting the new DiamondFox on the enterprise. We started out discussing detection data sources. He pointed us to logs that contain artifacts of outbound HTTP requests.

Given that DiamondFox bots use the HTTP protocol as a command and control channel - a bit unusual, actually... we see HTTPS or some covert channel a bit more frequently - any log data that contains artifacts describing outbound HTTP requests will be effective for hunting bot activity. Log data should include information that identifies the internal client making the HTTP request, the requested URI, and the User-Agent string used in the request. This rather careless configuration may allow us to identify and block the C&C.

DiamondFox Crystal Version includes the capability to use Domain Generation Algorithms (DGA) to establish a command and control channel-- log data that contains artifacts describing DNS resolution activity will be effective at finding DGA activity. Log data should include information that identifies the internal client performing the DNS resolution and the resolved domain name. You can use DNS log data to search for a pattern of DNS resolutions from a single internal client where the client unsuccessfully resolved unique domains containing what appears to be random characters in the subdomain content.

The DGA domains produced by a single bot will all have the same subdomain length-- this an indication that you may be dealing with DiamondFox or a similar bot that uses DGA to find its command and control. Some tools, like Sqrrl and a few others, have detection analytics that can automatically find DGA activity.

By default, the DiamondFox builder has a limited list of options for the installation methods of the bots, so log data that contains artifacts describing process execution and file creation/modification may be useful at finding bot installation and execution activity. This log data could also be used to identify actions taken by the bot-- password stealing, process discovery, persistence, etc.

Remember that artifacts for a given sample may vary from sample to sample because of the actions of the builder.

Moving on to network detection, by default, the DiamondFox builder configures the botnet URI to be hosted on a page named ‘gate.php'. If the botnet owner relies on this default behavior, then this partial URI string may be an effective indicator for identifying command and control activity. This indicator can be manually searched through HTTP request log data or written into an intrusion detection system (IDS) signature for automated detection.

By default, the DiamondFox builder will automatically generate a User-Agent string for the bot based on an MD5 hash function. If the botnet owner relies on this default behavior, then hunting through HTTP request data for User-Agent strings that conform to the MD5 hash string format (32 hexadecimal characters) can help identify bot activity.

If you have an intrusion detection system that supports regular expression pattern matching, this indicator could also be written into a signature for automated detection. Remember, however, that string searches for random collections of 32 hex character strings can yield false positives, especially where a 32 character pattern is part of a longer string completely unrelated to the MD5 hash.

If the botnet owner relies on the default patterns provided by the DiamondFox builder-- URI path, DGA, User-Agent string-- then the chance of successfully identifying bots by hunting through HTTP request logs is high. However, if the botnet owner customizes these options and significantly deviates from the default patterns, then detection will be more difficult.

Moving to the endpoints, we may be able to detect the bot start-up. DiamondFox Crystal Version supports a variety of startup methods for deployed bots, including execution when a user logs on (Run and RunOnce registry entries) and execution via scheduled tasks. Due to the prevalent use of these startup methods in a normal enterprise, hunting for this behavior isn't trivial.  

However, an effective option for doing so is to hunt for anomalous binaries (identified by either filename or file hash) executing via these normal Windows methods. To do this efficiently, an analyst should be able to differentiate normal instances of this behavior from abnormal instances of the behavior.  We have found that there is limited reliability in the directory where the bot ends up residing. remember that after being run, our sample (see Threat Hunter Blog, "Inside Diamond Fox") installed itself in StartMenu/Programs/Startup under the name explorer.exe. It then dropped another copy in a hidden folder and adds both paths to autorun in the Registry. Other samples have not behaved exactly that way so not finding the defaults does not mean that you don't have a problem brewing. Checking the Registry can be of use here.

DiamondFox has two options that are used to determine where the bot is installed on the compromised host: a user configurable filename and a static list of file extensions (including ‘exe', ‘scr', and ‘cmd'). Given that the filename is user configurable, one can't predict what a bot's filename will be-- however, if the botnet owner builds the bot to have one of the less common file extensions (‘scr', 'cmd'), then defenders can hunt for executable activity that contains these extensions.  Again, examining the Registry may give you a clue since the filename often is giberish.

Though perhaps not the most efficient method of identifying DiamondFox bots, hunting for activity related to the installation and execution of the bot can be somewhat effective due to the limited number of configuration options given to the botnet owner.

DiamondFox detection approaches should be combined in a variety of ways. For example, one could hunt for the builder's default User-Agent String pattern and default URI path to create a higher confidence detection method. One could also combine opportunities across network and endpoint data; for example, hunt for binaries with uncommon file extensions (‘scr') that make HTTP requests to websites that have the builder's default URI path.

Not every approach that you may be accustomed to using will work reliably with this bot.  However, rather than rejecting those techniques completely, you might try applying them as a test of what you found using more reliable techniques.

Each DiamondFox bot is encrypted with a (presumably) unique key, which means that, in practice, each build will have a unique file hash-- this can make using file hashes as a pre-discovery indicator of bot activity ineffective. While it's possible that one bot operator may use the same bot build for his or her entire botnet, you shouldn't expect this nor should you expect that a bot used in one network will be used in another network.

As with the file hash example above, the bot filename is user configurable and may change from build to build. This can make using file names as a pre-discovery indicator of bot activity ineffective. Similarly, it's possible that one bot operator may use the same bot build for their entire botnet, but you shouldn't expect this or that a bot used in one network will be used in another network. However, recall the filename pattern and directory structure.

Knowing what is supposed to be installed where is a huge benefit but in today's complicated servers we can expect a lot of filenames and paths with which we are unfamiliar. The DiamondFox Crystal Version builder comes with a pre-defined list of installation paths for bots (including the “AppData”, “Temp”, and user profile directories). These installation paths are high-volume directories, which makes it difficult to identify anomalous files within them.

Working with Josh was a treat and I hope to have him back again in the future. By way of full disclosure, Josh and I discussed this blog in the context of threat hunting without constraint of using his product.  However, we have reviewed Sqrrl here in the Labs (see https://www.scmagazine.com/next-generation-security-monitoring-and-analytics-innovators-2015/article/534147/) and found it to be an innovative approach to threat hunting.  While Sqrrl may not have invented threat hunting or coined the term, the company certainly has formalized it into a structured process.

Now, here are your numbers for this week.

--Dr. S in collaboration with Josh Liburdi

Josh Liburdi is a Security Technologist at Sqrrl where he acts as a threat hunting subject matter expert and helps drive the direction of Sqrrl Enterprise. Before joining Sqrrl, Josh worked at CrowdStrike on the Professional Services team where he performed threat hunting and incident investigations on behalf of Fortune 500 clients. Prior to joining CrowdStrike, Josh was a member of the General Electric Computer Incident Response Team (CIRT) where he led development of scalable, advanced threat detection scenarios.

Figure 1 - Top 10 Command and Control IPs Hitting the Packetsled Sensor on our Honeynet

 

Figure 2 - Top 10 IPs Hitting the Packetsled Sensor on our Honeynet

Figure 3 - This Week's New Malicious Domains from MDL


Figure 4 - Top Attack Types as Seen by our Niksun NetDetector against our Honeynet

Figure 5 - STIX Analysis of the 5 Most Malicious IP Addresses from our RecordedFuture Live Cyber Feed


Figure 6 - Top Event Categories Against our Honeynet from our AlienVault USM