Is Fileless Malware Really Fileless?

Image

Over the past few weeks I have been seeing quite a few news articles around fileless malware infecting companies around the world. The article from Ars Technica specifically states that the goal of fileless malware is to reside in memory in order to remain nearly invisible. Besides residing in memory, the second aspect of fileless malware is the usage of widely deployed tools which systems administrators rely on, such as PowerShell. I wrote back in 2015 on how attackers could be living off the LAN by using similar techniques. Why are attackers leveraging fileless malware? Well for one, not every endpoint solution inspects memory directly. This makes memory an ideal place to hide. Second, tools such as PowerShell are already deployed. These have multiple benefits for the attacker. Being able to live off the LAN reduces the noise in having to deploy malware to their victims. Since every endpoint solution will monitor the file system, writing to disk can trip the tripwire where defenses are looking. Having malware only reside in memory will avoid that risk. These tools are also widely used, malicious usage can attempt to blend into the typical noise of the environment. Because Windows is the primary focus of existing fileless malware, we’ll look at why fileless malware isn’t really fileless. With a narrow scope of defining malware as the actual code executing on the operating system, then fileless malware can indeed be fileless. Even the best endpoint products can miss advanced malware running in memory, and few organizations are running memory analysis tools like Volatility. Taking a step back from the narrow definition, the goal of the person behind the malware is to gather as much data against their target as possible. In order to do that, the malware needs to be able to recover from interruptions, and the way to do that is persist across reboots. In order to persist, something needs to be written to disk. In looking at the Indicators of Compromise for the malware Ars Technica referenced, the fileless malware created a service in order to persist after a reboot. The two registry keys written to were:

• HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services
• HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\services\PortProxy\v4tov4\tcp

The services section of the ControlSet hives are where system services live within the registry. This is how the malware will persist after a system reboot. The registry hive has CurrentControlSet, ControlSet001, and ControlSet002. According to a helpful Microsoft KB Article:

"ControlSet001 may be the last control set you booted with, while ControlSet002 could be what is known as the last known good control set, or the control set that last successfully booted Windows NT. The CurrentControlSet subkey is really a pointer to one of the ControlSetXXX keys."

Registry hives are stored as a file on the operating system in the System32 directory. The SYSTEM hive referenced above is written to the %WINDIR%\System32\config\SYSTEM file on the operating system – definitive proof that fileless malware is in fact, not actually fileless. Any malware that hopes to survive for an extended length of time ultimately needs to persist something, and that will likely be found somewhere on disk.