How to Hunt: The [File] Path Less Traveled

As any good hunter knows, one of the first quick-win indicators to look for is malware within designated download or temp folders. When users are targeted via spear phishing or browser based attacks, malware will often be initially staged and executed from those folders because they are usually accessible to non-privileged processes. In comparison, legitimate software rarely runs from, and even more rarely persists from, these locations. Consequently, collecting and analyzing file paths for outliers provides a signature-less way to detect suspicious artifacts in the environment.

In this post, we focus on the power of file paths in hunting. Just as our earlier post on COM Hijacking demonstrated the value of the ATTACKTM framework for building defensive postures, this piece addresses another branch of the persistence framework and illustrates the efficacy of hunting for uncommon file paths. This method has proven effective time and time again in catching cyber criminals and nation state actors alike early in their exploitation process.


Hunting for Uncommon Paths: The Cheap Approach

In past posts, we highlighted some free approaches for hunting to include passive DNS, DNS anomaly detection, and persistence techniques. Surveying file locations on disk is another cost effective approach for your team. The method is straightforward: simply inspect running process paths or persistent file locations and then look through the data for locations where attackers tend to install their first-stage malware. For an initial list of such locations, Microsoft’s Malware Protection Center provides a good list of common folders where malware authors commonly write files.

Your hunt should focus on files either running or persisting within temp folders, such as %TEMP%, %APPDATA%, %LOCALAPPDATA%, and even extending to %USERPROFILE%, but first you need to collect the appropriate data. To gather persistence data with freely available tools, you can use Microsoft’s SysInternals Autoruns to discover those persistent files and extract their paths. For detailed running process lists, there are many tools available, but we recommend utilizing PowerShell via the Get-Process cmdlet.

Some popular commands include:

  • “Get-Process | Select -Property name, path”: To list current processes and their path.
  • “Get-Process | Select -Property path | Select-String C:\\Users”: In this case we filter for running processes from a user’s path. Like grep, utilize Select-String to filter results.
  • “Get-Process | Group-Object -Property path | Sort count | Select count, name”: For the number of occurrences, group objects.

Expanding your hunt beyond just temp folders can also be beneficial, but legitimate processes will be running from %SystemRoot% or %ProgramFiles%. Because of this, outlier analysis will be effective and assist your hunt. Simply aggregate the results from your running process or persistent surveys across your environment, then perform frequency analysis to find the least occurring samples.


The Noise Dilemma

As you may have guessed, anomalous items uncovered with this approach to hunting does not necessarily mean they were suspicious. Users can install applications locally in uncommon locations, adding benign results to your hunt. Experienced hunters know that noise is always going to be part of many hunt analytics, and the art is in discerning the artifacts that are most likely to be malicious and should thus be focused on first.

There are many ways to triage and filter results, but here are a few examples.

  • You can utilize authenticode by filtering out executables that are legitimately signed by well-known signers or by signers you might expect in your environment. Unsigned code out of an odd location might be especially unusual and worth inspecting.
  • If you have a known-good, baseline image of your environment, you can use hash lookups to weed out any applications which were not approved for installation.
  • You may want to ignore folders protected by User Account Controls (UAC). In a well-configured environment, a standard user is not allowed to write to a secure directory, such as %SystemRoot% and some directories under %ProgramFiles%. Filtering out items executing from there can reduce the data set. It’s worth mentioning that you are assuming administrative credentials weren’t harvested and UAC wasn’t bypassed.
  • Once you’ve filtered data out, especially if you are left with many suspicious files, you may want to submit files for malware scans (e.g. VirusTotal). At Endgame, we prioritblize based on the MalwareScore™ of the file, our proprietary signature-less malware detection engine. The higher the score, the more likely it is that the file is malicious.

You may come up with many other ways to filter and reduce the data based on your specific knowledge of your environment. As always, your analysis of the hunt data and subsequent analytics should be driven by environmental norms, meaning that if you observe something uncommon to your system configurations, it’s worth investigating.


How Endgame Detects

At Endgame, we facilitate one-click collection of processes and persistence locations to allow for rapid anomaly and suspicious behavior detection. Our platform examines each endpoint within your network and can prevent, alert, or hunt for malicious behavior at scale. The following video shows a simple PowerShell-based approach to collection and stacking, and then shows the Endgame platform enumerating and enriching data in seconds to bubble suspicious artifacts to the top with the uncommon path technique.



There are many very effective ways to hunt for suspicious artifacts across your systems. Hunting for files executing or persisting out of strange paths can be effective in many environments. We’ve discussed some free ways to make this happen, and shown you how this can be done with the Endgame platform, highlighting malicious activity with ease. Layering this hunt approach with other analytics in your hunt operations will allow you to find intrusions quickly and do what every hunter wants to do: close the gap between breach and discovery to limit damage and loss.