I ran across Manuel Arrieta‘s Hunting Fileless Malware in the Windows Registry article recently, and found it to be an interesting read.
Let me start by saying that the term “fileless malware”, for me, is like finger nails dragged down a chalkboard. Part of this is due to the DarkWatchman write-up, where the authors stated that some parts of the malware were “…written to the Registry to avoid writing to disk.” That kind of distinction has always just rubbed me the wrong way. However, regardless of what we call it, I do “get” the concept behind the turn of phrase, and why folks tend to feel that this sort of thing is more difficult to detect than malware that actually writes a file to disk. I’m not sure why they feel that way…maybe it’s because this code that downloads the malware and injects it directly into memory (in some cases) can reside anywhere on the system, and within any Registry value. However, the key is that this somehow needs to remain persistent, which limits the number of locations for the code that initiates the download, accesses the shellcode, or performs whichever initiating function.
In his article, Manuel discusses the use of LOLBins to write information to the Registry, and how this can be used for detection. He references several LOLBins, and something that we have to keep in mind is that there’s often more to these detections than just what we see on the surface. For example, is PowerShell used extensively within your infrastructure to create Registry values; if not then just the use of PowerShell in that manner would make for a good hunt, or even a good detection opportunity. The same is true for other LOLBins, including reg.exe, rundll32.exe, etc. If these are not something that you usually ‘see’ within your infrastructure, then those instances that you do see would need to be investigated.
Manuel’s article discusses a number of interesting approaches for creating detections for “fileless” malware that’s written to the Registry, and anyone involved with detection engineering should strongly consider giving it a good, solid read, and seeing how it can be applied to their environment.
I’d like to take the opportunity to add to Manuel’s work by presenting means for detecting this type of malware from a triage or “dead box” perspective. For example, Manuel mentions looking for LOLBins writing Registry values of suspicious lengths. I like this approach, because I’d taken a similar approach in 2015 when I originally wrote the RegRipper sizes.pl plugin. This plugin walks through a Registry hive and looks for all values over a specific $min_size, which is set to 5000 bytes (you can easily change this by opening the plugin in Notepad and changing the size value). Now, you’re going to have legitimate Registry values that contain a lot of data, and that’s to be expected; it’s normal. However, a way to extend this is to look to publicly available threat intel based on actual incident data, see what different threat actors are placing in Registry values, and tailor your approach.
Almost 2 yrs ago, I announced that I’d found a way to integrate Yara into RegRipper v4.0, so any Yara rule that looks for indications of “fileless” malware or shellcode within a file can be run against Registry values, through RegRipper. This can include rules that look for base64-encoded strings, or that begin with some variation of “powershell” (i.e., mixed-case, carets between the letters, etc.).
The findexes.pl plugin, which looks for strings beginning with “MZ” in Registry values, was originally written in 2009, based off an engagement that Don Weber worked while he was a member of the IBM ISS X-Force ERS team. Don found that, during the engagement, the threat actor had written a PE file to a Registry value, and then rather than reaching out to a network resource to download the malware, it was simply extracted from the Registry value. I found this very interesting at the time, because several years prior, while working on network exploitation research for the military, I’d theorized something similar happening, and actually created a working demo. Jump forward several years, and Don was showing me that this was actually being used in the wild. This findexes.pl plugin is one approach, and using Yara rules is another.
Examples
Here’s an example of a persistence mechanism in the Registry pointing to a value that contains a base64-encoded string.
Here’s an example from Splunk; scroll down to the section called “Fileless Execution Through Registry”; this one creates a Run key value that creates Javascript code to run calc.exe, so it’s clearly not “fileless”, per se, but it does serve as a harmless example you can use to test dead-box detections.
Here are some practical examples from Securonix; unfortunately, some of the examples are in screen captures, so you can’t get specifics about them, such as the length of the value data, but you can use these example to round out your detections.
Source: Read MoreÂ