The Myth of "Fileless" Malware

Is "fileless" malware really fileless?

Now, don't get me wrong...I get what those who use this term are trying to say; that is, the actual malware itself, the malicious code, does not exist as a file on the local hard drive. However, for the uninitiated, the use of the term "fileless" is misleading, because in order for the things to happen and for the malware to persist, there has to be something in a file somewhere on the drive. Otherwise, what's the point?

Yes, threat actors can release code that had a devastating, even catastrophic effect without persisting on an endpoint. This is not in question. 

However, the term "fileless" can imply to the uninitiated reader that files are not used at all, and this simply is not the case. This is important to understand, as this allows us to develop appropriate protections, detections, and responses for this kind of malware. Understanding this also means allows us to leverage DFIR skill sets to learn more about the threat actor leveraging various techniques to "remain fileless".

Sometimes, we just get the descriptions of the malware wrong. In Prevailion's DarkWatchman write-up, at the bottom of pg, 3, the authors state, "Various parts of DarkWatchman, including configuration strings and the keylogger itself, are stored in the registry to avoid writing to disk" (emphasis added), as illustrated in figure 1.

Fig. 1: Excerpt from DarkWatchman Write-up

The Registry is on disk, and is, at it's most basic, a file. Even though the Registry has a binary (rather than ASCII) format, and may be considered a "file system within a file", that does not mean that something that stores its configuration and/or persistence in the Registry is not using a file.

On pg 10, the same write-up states that persistence is achieved via a Scheduled Task, which is contained both in the Registry (a file), as well as within an XML file. Even using various techniques to hide the Scheduled Task XML file from view still means that the configuration and reference to the malware is stored within a file.

Reliaquest's recent article on LotL and "fileless" malware describes "fileless" malware as "running from memory or scripts...instead of executables". Even this definition can be confusing, as a script is a file on disk. 

Yes, I understand that intent is to say that the script isn't the actual malware itself, but instead reaches out off-system to download the actual malware, and then run it in memory so that ideally, the malicious code never touches the disk. Yes, I get it...but it's still misleading and without the appropriate review, the impression is that this malware is incredibly difficult, if not impossible to detect and respond to without a very specific set of tools. 

The article starts off by saying that fileless malware is "harder to detect than traditional malware because it relies solely in memory." I'm not sure that's the case; at work, we detect a lot of SocGholish (referenced in the statement as an example) and other fileless malware, without requiring something that scans memory. 

The article also states that fileless malware "manipulates the command lines of trusted applications...allowing malicious activities to blend in with normal, authorized operations..."; I'm unclear as to what this means, and confused as to how it makes fileless malware harder to detect. In fact, in my experience, it's quite the opposite...if you're monitoring an organization with the appropriate visibility, modified command lines for known-good applications should stand out pretty clearly.

Something else to consider is that not all organizations actually use LOLBins (or LotL) on a regular basis. I've seen organizations that don't use curl.exe or certutil.exe at all. I've worked with customers who, by policy, do not use "net user" to create and manage user accounts. As such, use of these LotL techniques will not remain hidden, particularly if you're looking. How they will remain hidden is if you haven't employed some modicum of visibility, by enabling "Process Tracking" along with full command lines, or Sysmon, or EDR, or some form of AV such as Windows Defender.

The Reliaquest article also discusses threat actor use of LotL techniques, also referred to as LOLBins or LOLBAS to remain stealthy and minimize their impact within a compromised infrastructure. However, this can be a bit misleading. The article indicates that threat actors prefer LotL techniques given the "lack of IoCs" associated with the use of these techniques, and this simply isn't the case, when, in fact, the use of native utilities such as msiexec.exe actually produces quite a few IoCs that can be very valuable to the responders and investigators. And this is simply how the operating system works, without any additional EDR or EDR-like capabilities.

From the Technical Breakdown of the first case study in the Reliaquest article, the SocGholish malware performs the actions illustrated in figure 2.

Fig. 2: First Case Study

How often do users or even admins run "cmdkey /list" within your organization? How about the "net" commands, or "gwmi"? If you have the necessary visibility, and know this, then you can also assess control efficacy, and possibly even use 

So, What?
Who cares, right? Someone calls something "fileless", and whether it really is or not, doesn't matter, does it?

The insistence on the use of the term "fileless" tends to imply that only so much can be done about the malware. After all, just look at the Reliaquest article. The implication is that the malware exists only in memory, so the options for detecting, responding to and analyzing the malware are extremely limited. 

However, this simply is not the case. For the malware to truly be effective, it has to persist in some manner, and whatever that is can be used to hunt for, detect and respond to, and possibly even prevent the malware from impacting the endpoint. Understanding the details of how the malware arrives on the endpoint, and how it persists, allows organizations to assess their own control efficacy and determine how best to address the issue. So while the actual malicious code itself may not be directly detected without some sort of memory-based detection, the precursors, effects/impacts, and follow-on activities tied directly to and associated with the malware can all be detected, because they will "appear" in a detectable manner. This will depend upon your aperture and visibility, of course, but the fact remains that they will be detectable. They could be processes, code retrieved from Registry values, Scheduled Tasks, or even other endpoint impacts recorded in the Windows Event Log, but they will be detectable.

Given the amount of "fileless" malware organizations see with the initial download capability embedded within the Windows Registry, I added the capability of running Yara rules to RegRipper 4.0, in hopes that folks would use that capability to help detect such things.

Addendum, 5 June:
Not long after I published this blog post, John Hammond shared a post on LinkedIn, as shown in figure 3.

Fig. 3 - John's LinkedIn post

Again, the underlined phrase refers to the fact that rather than writing a malware EXE to a value (or values) in the Registry, a "fileless payload" is written instead. This can be confusing because, depending upon the path, "HKEY_CURRENT_USER" can refer to either the NTUSER.DAT or the USRCLASS.DAT file in the user's profile.