The notion of fileless attacks describes incidents where adversaries avoid writing malicious code to disk, aiming to operate solely in memory and abuse features of applications and the OS.
Such tactics offer numerous opportunities to evade detection, allowing malware to stay in the blind spot of many antivirus solutions. Let’s examine the common ways in which adversaries bootstrap their presence on the endpoint during fileless attacks.
In order to interact with built-in tools or run malicious code without leaving footprints on the file system, the adversary first needs to gain a foothold on the endpoint. Common types of interactions that begin fileless attacks include the following scenarios.
In-Memory Exploits
The adversary can take advantage of a vulnerability in software running on the endpoint, tricking the buggy application or OS component into executing malicious code.
The victim could be subjected to this attack vector when browsing an exploit kit-affected website that pursues vulnerabilities in web browsers, PDF readers and other client-side software. The person might encounter such drive-by attacks when accessing a trusted site that’s hosting a malicious banner ad. In another scenario, the adversary could infect the endpoint by exploiting server-side vulnerabilities, as demonstrated by the UIWIX worm’s use of the ETERNALBLUE exploit.
In these scenarios, the attacker supplies malicious code as payload of the exploit, which the vulnerable software ends up executing. Once active on the compromised endpoint, the payload can download or extract additional attack components without placing them on disk.
Malicious Documents
Another form of bootstrapping a fileless attack involves boobytrapped document files. This approach could abuse macro or scripting capabilities of business applications such as Microsoft Office and Adobe Reader. In other scenarios, adversaries could use the document as a container within which they conceal malicious code that begins the infection.
For instance, the attacker could embed a malicious JavaScript in a Microsoft Office document, employing social engineering tactics to launch the infection by double-clicking the embedded object. Such attacks take advantage of the OLE feature of Microsoft Office. In similar scenarios, attackers took advantage of DDE functionality of Microsoft Office to trigger the execution of malicious code in the document.
Another approach to misusing document features involves implementing malicious code as a document script. The most common infection vector of this manner involves macros, which are natively supported by Microsoft Office. Once running, the macro’s VBA code can continue the infection, for instance by generating and executing malicious PowerShell scripts and batch files, as exhibited by notoriously-evasive Emotet malware.
Once the document’s malicious code starts running, it can act as a downloader or dropper to continue the infection chain in a fileless manner.
Malicious Programs
Despite the purist’s interpretation of the term fileless malware, some attacks that security practitioners consider “fileless” actually have files. (See the malicious document discussion above, for example.) In these situations, the attack that exhibits many fileless characteristics could start with a malicious program designed to evade initial detection.
Consider Kovter, which evolved into a classic fileless threat. Though some Kovter infections began with a malicious document, others involved a compiled Windows executable. The attackers crafted the file to appear innocuous to antivirus software. When the executable ran, it placed encrypted and obfuscated artifacts in the registry, staying away from the file system. Kovter effectively re-infected the system upon a reboot by using JavaScript, PowerShell, shellcode and other fileless methods to operate out of memory.
For another example of a mostly fileless threat that began with a Windows executable, consider GhostMiner. This malicious cryptominer bypassed detection by employing two PowerShell evasion frameworks, Out-CompressedDll and Invoke-ReflectivePEInjection, to unpack payload into memory without committing the decoded malicious code disk. Attackers can easily use such wrappers to turn a traditional malicious executable that antivirus tools detect into an in-memory threat that evades detection, as you can see from an evasive Saturn ransomware example.
In other instances, attacks that exhibit fileless characteristics can start with a program written in Java. Many anti-malware tools struggle with such malware even when it lacks fileless attributes. Unfortunately, Java malware can take measures to conceal themselves from detection even further. One example of this is the approach to performing memory injection out of Java, as demonstrated by the CoffeeShot evasion framework.
Stopping Fileless Malware
Once a fileless threat has entrenched itself on the endpoint, the attacker can continue to operate out of sight of many security tools. This entails not only residing in memory of various processes, but also “living off the land” by abusing the various non-malicious utilities built into the OS. (For details, see the Living Off the Land Binaries and Scripts collection.) Therefore, the earlier the organization can interfere with the attack, the greater chances it has to stop the infection.
Minerva’s Anti-Ransomware Platform is highly effective at stopping fileless threats at the very onset of the attack, addressing the common vectors described above. The solution’s multiple modules work together to prevent the misuse of memory associated with fileless malware, defang boobytrapped document files, foil exploit kits and interfere with malicious scripts before the attacker can compromise the endpoint. But don’t take my word for it—see it for yourself.