Hunting on the Cheap, part 3: Hunting on Hosts

In our previous posts, we focused on hunting on the cheap by collecting and analyzing data on the network.  However, hunting on networks is not the only option.  In fact, a richer set of data to find unknown malicious activity in your enterprise is available by looking on and across your hosts and servers.  This can include running processes, active network connections, listening ports, artifacts in the file system, user logs, autoruns, and more.  With all this data, the tough part is deciding what to focus on as you start your hunting process.  Once you’ve determined areas of focus, you can collect data, look for suspicious outliers, and investigate further.  In this final post in the series on how to get started with hunting, we’ll describe some tips for hunting on your hosts using freely available tools.  These techniques are simplified first steps to help you find evidence of malicious activity on your hosts - with or without signatures and IOCs. You can do this for free, while still getting a taste of the power of hunting.


Searching with Indicators

A common starting point is to look for IOCs (Indicators of Compromise) across your hosts.  While many call this hunting, it’s really just searching. And not just searching, but searching for indicators that are fleeting and constantly morphing.  In fact, the useful lifespan of an IOC is declining due to trends in adversary behavior.  Most security professionals already know this, and it was underscored in Verizon’s DBIR released last week.  That said, due diligence still necessitates searching across your systems for known IOCs, which remains a useful first step.  The following are several websites that publish freely available threat intelligence information in various forms.


IOC Source


One of the more resilient and useful IOCs to use on your hosts is a well-written Yara signature.   Yara applies binary patterns and sequences to detect and categorize badness on your system. Yara is similar to Grep, which employs a list of known patterns and searches for matches. But Yara does much more, scanning both files on disk and memory for binary patterns.  A good malware analyst will in many cases be able to craft a Yara signature to detect not only identical copies of a piece of malware but also variants of the tool, new versions of the tool, or even follow-on tools in the same malware family by focusing on unique patterns in the binary which are likely to survive through code reuse.  For this reason, one of our favorite open source tools for identifying malware is Yara.  And even better, it’s free.


Yara in Action

Yara rules are a great way to structure a known malicious pattern based on textual or binary sequences.  The following is a snippet of a robust Yara signature that detects Mimikatz, a tool used by adversaries and red teams to extract Windows credentials from memory. This particular signature was actually written by the author of the Mimikatz tool itself.

Rule Mimikatz


You can run Yara locally but it is even more powerful when run remotely on a single machine or across multiple machines.  Powershell can facilitate this. Running Yara remotely via Powershell can be done in a few simple steps, assuming you have credentials to the hosts and Powershell remoting is enabled.


Transfer Yara binary to target machine w/ native Windows functionality

PS> copy yara.exe \\TARGET-HOST\C$\TEMP\yara.exe

Transfer rules

PS> copy rules.yara \\TARGET-HOST\C$\TEMP\rules.yara

Execute scan w/ Invoke-Command

PS> Invoke-Command -ComputerName TARGET -ScriptBlock { c:\TEMP\yara.exe c:\TEMP\rules.yara c:\targetdir } -credential USER

This will have the effect of running a set of Yara rules (rules.yara in the above example) on a given directory (c:\targetdir in the above example).  It can easily be extended to search across the entire disk and across many hosts and identify exactly where a binary matching your signature exists on the hosts.  

This is very powerful, but is not without shortcomings. As we all know, signatures are brittle. This not only leads to false positives if the Yara signature is poorly written, but with the rapid pace of change of malware, rules need to be constantly updated or they become obsolete. This can be extremely resource and time intensive.  However, compared to searching for hashes, filenames, and other artifacts which are commonly used in IOC search, using Yara can be a more powerful and resilient approach.  


Hunting without Intelligence

Even if you have IOCs as a starting point, IOCs are not good enough to find all possible malicious activity in your enterprise.  This is where hunting comes into play.  Hunting is the systematic and proactive pursuit of unknown threats. This entails the identification of patterns and suspiciousness in your data that may indicate badness on your network.  As mentioned above, there are many places you can hunt on the host.  We suggest starting with autoruns.  Adversaries usually want to persist across reboots on at least some systems in your network.  Doing so is critical to entrenchment in your network for the long haul.

Autorun items are a good place to look for outliers and suspiciousness for several reasons. Autoruns tend to be relatively consistent across a network rendering pure outlier analysis feasible.  Any autoruns showing up in only in a handful of places may indicate badness, but these can be hard to find given all of the locations that need to analyzed. Additionally, files must be dropped to disk for autorun persistence. Some actors do obvious things you can treat as suspicious - for example, executing out of the %TEMP% folder with an obviously strange filename.  In many environments, malicious autoruns stand out and can be detected by a good hunter.  Once a malicious autorun is detected, deeper analysis can commence to confirm and deal with a compromise.


Collecting Autoruns

There are over one hundred places where an adversary can persist on a modern Windows machine.  This includes startup registry keys, services, drivers, browser and Office add-ons, and many other less well-known places and methods.  Beyond the sheer number of locations, grabbing the necessary data for analysis is non-trivial due to the way data is formatted by the operating system.  Sysinternals (maintained by Microsoft) created a tool called Autoruns to tackle this problem, free of charge.  While not perfect, this tool does a great job pulling in the right data for most autorun items on a Windows system, hashes them, and allows for some basic enrichment (such as submitting to VirusTotal).

We recommend using the command line version of autoruns (autorunsc.exe) in tandem with Powershell for remote gathering of autoruns from your systems.  This can be done in a few steps:


Transfer Autoruns binary and the required msvcr100.DLL to target machine w/ native Windows functionality

PS> copy autorunsc.exe \\TARGET-HOST\C$\TEMP\autorunsc.exe

PS> copy msvcr100.dll \\TARGET-HOST\C$\TEMP\msvcr100.dll

Execute program w/ Invoke-Command (w/ optional output)

PS> Invoke-Command -ComputerName TARGET -ScriptBlock { c:\TEMP\autorunsc.exe –a (??) –h (>> c:\TEMP\autoruns-output.txt) } -credential USER

Collect output

PS> copy \\TARGET-HOST\C$\TEMP\autoruns-output.txt c:\directory

As before, this can be extended to gather data from many systems across your network.  


Analyzing Data

We recommend submitting all autorun hashes to VirusTotal as the first step in your investigation.  Anything that comes back as malware is...well….malware and you should prioritize these for additional investigation.  Fortunately, this can be done inline with Sysinternals, or you can easily build something with the VirusTotal API.

So you’ve collected all your autoruns and determined if any are known to be malware.  That’s a good step, but you shouldn’t stop there.  You need to truly hunt for unknown badness and look for anomalies in the data.  There are many ways to do this, but we’d recommend first stacking by hash and looking for outliers that don’t match the general population of the data. To do this, pull hashes of all autorun items as described earlier, and then list them out as HOST:HASH.   The following provides a concrete example of how this might look (note that you will have many more autoruns for each machine in a real environment).


Cat Hash Map


An easy next step is to delineate the output by colon (:)

# cat hash-map.txt | cut -d’:’-f2 > hashes.txt

And then reduce and sort by the number of occurrences across your systems to quickly identify the anomalies.


Cat Hashes


In this example, we had 42 systems.  Many autoruns appeared on each system.  A couple only appeared on one.  These outliers could be suspicious.  A reasonable first step would be to look at the detailed output of autoruns from the host(s) where the outlier was seen.  You may note a strange description, strange filename, strange autostart location, or more.   The following example shows a binary named “svcchost.exe” executing on startup from C:\WINDOWS\temp:



The next example shows a binary executing on startup from the recycling bin with a one-character filename, both definitely signs of something strange going on.



These are not the only suspicious things you can note in autoruns data.  There are many more approaches.  You can take this much further, for example, by indexing all of the data in Elasticsearch (another freely available capability) to allow for fast search and exploration capabilities across your data to include regularly collecting autoruns from your endpoints and looking for changes in autoruns over time.  And, of course, there are many endpoint artifacts which are prime locations for hunting.  A true hunt effort should expand in scope to cover user logs, processes, network information, and more.  



Over this three-part series of posts, we’ve provided several approaches using only free software to help you begin hunting on both networks and hosts.  Hunt techniques are not reliant on ephemeral and constantly morphing signatures or IOCs, thereby providing ways to better match the sophistication of modern adversary techniques.  Every organization and researchers should begin proactively hunting to detect unknown threats inside the network.  From passive DNS to autoruns, we’ve covered a lot of ground and described a variety of free and powerful approaches for hunting on hosts and networks. Have fun!