Risks Under the Radar: Understanding Fileless Threats

A typical infection chain of a fileless threat that launches via document exploit, installs payload, and maintains persistence

An attack can be initiated by a user action, such as clicking on an attached document embedded with abused code, which then makes use of other applications installed on the machine. Fileless attacks occur in a machine’s random access memory (RAM) and usually utilize built-in Windows tools such as PowerShell and Windows Management Instrumentation (WMI) to execute malicious commands. These known applications carry out system tasks for endpoints, which makes them ideal for facilitating the attacks. Fileless threats can also be coupled with other attack vectors such as ransomware in an attack.

Since fileless threats do not require downloaded files, detecting and preventing them can be tricky. However, because RAM only keeps its data when the machine is on, the infection should no longer be live when the computer has been rebooted. However, this doesn't mean hackers cannot take advantage of other weaknesses in the computer or even perform other techniques to give it persistence. For instance, a hacker can continue an attack by setting up scripts that run when the system restarts.

How do fileless threats enter systems and how are they detected?

Malware attacks typically involve malicious files written to disk or require interaction to carry out their malicious intent. These characteristics would leave traces, in one form or another, for post-infection forensics. However, since fileless threats are intended to be memory resident, more often than not, they don't leave a footprint after execution. The malicious payload occurs in the RAM, which means it doesn't write anything to the disk. This makes memory-based attacks trickier and harder to detect than file-based malware. However, fileless threat activities can be detected by tracking nonfile-based indicators such as particular execution events or behaviors.

396% in fileless threats
Jan 2018 - Jun 2019 Fileless attacks thrive in stealth and subtlety, and the month-over-month numbers show that the threat is appealing to cybercriminals. Tracking fileless threat detections from 2018 to the first half of 2019 show a noticeable increase. The upsurge can be attributed to the continued use of different fileless techniques to evade conventional blacklisting detection and solutions.

Monthly comparison of fileless events blocked, based on data from the Trend Micro^™ Smart Protection Network^™ infrastructure (January 2018 to June 2019)

Percentage of fileless events detected (January to June 2019)

Here’s how fileless threats work and what techniques to look out for:

Launching attacks via document or in-memory exploits

A fileless attack can start “traditionally” via malicious macro code (e.g. JavaScript or VBScript) embedded in archives, other seemingly normal files, and approved applications such as Office documents (e.g. Microsoft Word and Excel) and PDFs. Attackers take advantage of these, enabling them to run code with the same privileges as the running application. The macros can run scripts and abuse legitimate tools like PowerShell to launch, download, or execute code, scripts, and payloads. These scripts can also be obfuscated, which makes detecting keywords that trigger execution a challenge for organizations. A fileless attack can also make its way to systems through a spam or phishing message that entices a receiver to click on a malicious link, which then starts the infection process.

Fileless threats can also employ different ways to execute from memory. A recent example of this is the in-memory exploit EternalBlue, which takes advantage of a vulnerability in the Server Message Block 1 (SMB 1) protocol. An attack can also take advantage of legitimate processes through DLL injection, which forces the loading of a dynamic-link library (DLL) into a host process, thus eliminating the need to write the DLL to the disk. A technique like process hollowing, which replaces some code with a malicious function, can also be employed. This involves code execution directly in memory and can even be kept running in the background even after the software has been closed.

Installing malware via built-in system tools or scripts

Attackers can abuse system administration tools and utilities for fileless infections. Instead of using executables, attackers can misuse the tools that are already on the target system to conduct their attacks. Some of these tools are command-line interfaces such as BITSAdmin (Background Intelligence Transfer Service), used for creating and downloading jobs and monitoring progress; CertUtil, used for certificate services/management; and msiexec, used for installing, modifying, and performing Windows Installer applications.

Script-based attacks are the most common fileless threat, based on our data (at 38% for 2019 1H). Many script-based attacks use interpreted scripts, as they run directly on the command line (via PowerShell, JavaScript, VBScript, WScript, mshta, etc.), and can lead to arbitrary code execution. PowerShell, for instance, can execute a hidden command in the system that can be set depending on the length of time planned for the attack. Many malware types have since been delivered filelessly through code execution in memory to bypass endpoint-based security.

Many fileless threats abuse PowerShell, in particular, as it is a built-in feature on many Windows operating systems. The Microsoft framework is also capable of accessing application programming interfaces (APIs) that execute crucial system and application functions. It is also appealing for attackers because it has no executable on the disk, thus allowing them to deliver payloads and executive malicious commands filelessly. IT administrators can best detect the misuse of PowerShell through behavioral detection, i.e., discerning a PowerShell session executed via an encoded command in command line.

Maintaining persistence via Task Scheduler, Registry, or WMI

Often, breaches caused by fileless threats can be halted as soon as the user restarts the computer since the malicious code only resides in memory. However, malicious actors have already been using techniques to ensure that fileless infections do not rely on endpoints to sustain an attack. Hackers can make subtle changes to the system registry by planting entries and setting up scripts to run even after a system restart. What makes this particularly noteworthy is that by having a system’s own commands execute an attack, it might not be considered in some monitoring efforts. For one thing, the Windows Registry can also be compromised by storing malicious codes in the registry with auto-run capabilities, so that attacks refresh in the background even after a computer reboot. An example is the fileless version of the evolving malware KOVTER, which was previously seen creating registry entries that load malicious codes into memory whenever an infected machine has been restarted or batch files have been triggered.

Windows Task Scheduler, which is used to enable programs scripted to be launched at a predetermined time, can also be abused to maintain persistence. For fileless threats, this means that tasks can be scheduled for execution. Attackers can even set the tasks to recur and create registry entries to automatically reinfect systems.

Interpreted codes such as those in PowerShell or a Windows component such as Windows Management Instrumentation (WMI) that are typically used by enterprise networks for system administration task automation, can be abused to allow malicious scripts to run, which could then affect the endpoint without writing to disk. Attackers abuse this for code execution, lateral movement, and persistence. They can use WMI repositories to store malicious scripts that are periodically invoked using WMI bindings. Notably, iterations of cryptocurrency-mining malware were also seen abusing WMI for persistence.