Skip to main content
Lately, an increasing number of companies have been suffering from fileless malware. This type of cyber attack has become so widespread because of its invisibility to traditional anti-malware solutions. Fileless malware runs via legitimate Windows processes, so such attacks leave no traces that can be found by most cybersecurity systems. This article covers specifics of fileless malware and provides tips for effectively detecting and protecting against such attacks.
Fileless malware is at the height of popularity among hackers. According to a 2017 Verizon Data Breach Investigations Report, only 51 percent of all attacks on companies were performed using traditional malware in 2017. This means that 49 percent of attacks that hackers used involved other methods of intrusion, including fileless malware that easily bypasses standard security solutions.
Another study, conducted by the Ponemon Institute (which surveyed 665 IT security professionals), concludes that a significant increase in malwareless attacks is expected in 2018 mainly due to fileless malware being ten times harder to detect than file-based malware.
One of the biggest fileless malware attacks ever happened in February 2017. During this attack, hackers associated with the GCMAN and Carbanak groups compromised more than 140 private banks, government organizations, and telecom companies in 40 countries across the world.
The threat of fileless attacks is quite evident, so let’s look closer at what fileless malware is and how you can protect against it.
Contents
What Is Fileless Malware?
The term fileless malware refers to malicious code that has no body in the file system. In other words, fileless malware doesn’t need any files to execute.
Terminate-Stay-Resident (TSR) viruses were the first fileless malware examples. Though TSR viruses had a body from which they started, the executable file could then be deleted once the code was loaded to memory. Yet pure fileless malware can start without having any body on the disk and can operate in Random Access Memory (RAM) for a predetermined amount of time.
Moreover, fileless malware is also a kind of virus, exploiting some Remote Code Execution (RCE) vulnerability to make legitimate processes execute small pieces of shellcode. This shellcode then downloads the main part of the malware – called the payload – to the memory and runs it. So the malware code becomes part of a legitimate process and is executed.
Initially, fileless malware required a file and ran exclusively in RAM. Currently, the term is also applied to any malware that doesn’t have a body in the form of a native executable file on the disk. Thus, script-based malware (JavaScript, VBScript, Sh, PowerShell) is also considered fileless malware.
Main Types of Fileless Malware
There are two main types of fileless malware depending on the executable environment:
- Fileless malware that operates in RAM
- Fileless malware that exploits vulnerabilities in software scripts
RAM-Based Malware
The main advantage of malware that executes strictly in RAM is that it’s stealthy. Since most of the checks performed by antivirus software are done when a process starts (verifying digital signatures, searching for virus signatures), processes that are already running are considered unsuspicious. So if malware doesn’t create anything on the file system, it doesn’t trigger any event that antivirus software can react to.
Besides, most antivirus databases contain signatures for files with viruses that basically act as recipes for how to cure malware. Consequently, antivirus software decides how to act based on the files found on the disk. However, nothing can be used against fileless malware even if it’s detected by runtime protection. There’s only indirect evidence of fileless malware, for instance processes acting suspiciously. Yet terminating each suspicious process in RAM is not an option, since this could threaten valuable unsaved user data.
The main disadvantage of fileless malware is that it’s highly dependent on the process within which it runs. In order for the payload to run, the malware has to be compiled as position-independent code because the base address for the payload is random. The payload needs to detect which DLLs are available in the process it’s running in. In order to keep a low profile, this type of malware has to rely only on DLLs that are already loaded, as antivirus software usually monitors new modules being loaded. Thus, the malware has to have its own implementation of critical features in case some API isn’t accessible due to a DLL not being loaded.
If the process terminates too early:
- Shellcode won’t be able to download its payload
- Even if malware has downloaded its payload, the payload may be terminated before it’s reached its goal
- A process may be terminated right before it tries to persist in the system
In the past, internet connection speed was the main limitation for this kind of malware. Attackers had to download at least some part of the malware and save it to the disk before the user closed the browser. Therefore, there wasn’t much use in a fileless approach, and instead a file-based approach was used: a shellcode downloaded the loader or dropper – a small executable that didn’t do any harm itself. The aim of the loader was to get the payload from the hardcoded URL secretively and then execute it.
Modern software runs long enough for fileless attacks to succeed, and often processes keep running in the background after software is closed. Thus, fileless malware based on RAM has a much better chance of surviving.
Script-Based Malware
Using scripts as an attack vector is another known way to infect a computer. The most popular types of script-based malware have been developed to exploit vulnerabilities in Microsoft Office and Windows PowerShell.
Fileless Malware Targeted at Microsoft Office
In the past, VBScript in Microsoft Office documents was mainly used to download the loader or the payload. VBScript helped attackers to at least execute some legitimate operating system command that would trigger the download. However, VBScript is pretty limited as a base for a malware body due to the difficulty of working with operating system entities such as processes, threads, services, modules, the registry, and so on.
Antivirus software couldn’t do much to protect against these kinds of attacks, however, as implementing such protection would require deep integration with the Microsoft Office scripting engine, which is undocumented. So the common approach to protection was to add the hashes of known infected documents to the virus database and block these from being downloaded or opened. Sometimes, antivirus software tried to analyze the contents of a document to find known VBScript bytecode sequences. However, malware very soon overcome this by using VBScript obfuscation.
The battle was lost, and the only solution provided by Microsoft Office was disabling scripts by default and showing an Active Content warning if any VBScript code was used in an Office document. This measure reduced the number of infections, though it didn’t decrease the effectiveness of this kind of attack to zero.
Fileless Malware Targeted at Windows PowerShell
Then the attack vector turned to a new target: Windows PowerShell.
Windows PowerShell is a Windows command-line shell designed especially for system administrators. It includes an interactive prompt and a scripting environment that can be used independently or in combination.
In addition, Windows PowerShell providers enable you to access other data stores, such as the registry and the digital signature certificate stores, as easily as the file system.
PowerShell is not the only scripting environment that can be used to manipulate operating system entities. Basically, any interpreted language such as Python or Ruby can be used for this. However, PowerShell has a big advantage: it’s preinstalled on Windows, so there’s no need to install an interpreter first.
Consequently, PowerShell is an ideal platform for fileless malware because:
- it uses scripting
- it has access to critical operating system objects
- it’s available on all modern Windows versions
- there’s no native executable on the disk
Finally, PowerShell can’t simply be disabled (as was done for VBScript in Office documents), as many system administration tools rely on it.
Thus, modern malware can be fully implemented as a PowerShell script and there’s no need to download native binaries unless something really specific is needed.
Once again, antivirus software has problems analyzing script execution. Antivirus software is designed to analyze native code, in other words x86 assembly code, and lacks tools to analyze PowerShell scripts. Besides, malware has already started using obfuscation to hide the source code of PowerShell scripts. So there’s no easy way to distinguish if a script is legitimate or malware. Antivirus software also can’t be sure whether a PowerShell process was created by malware or for legitimate system needs. And what makes it even worse is that the PowerShell engine is built on .NET. This means that the PowerShell interpreter is running as JIT code on a .NET platform, which makes the analysis of PowerShell process actions even more complicated for antivirus software. Finally, PowerShell scripts rely on external processes to do specific parts of the job. So from the antivirus standpoint, a PowerShell process doesn’t do any harm – it just runs multiple operating system utilities.
How Does Fileless Malware Work?
Here’s a typical scenario for how cyber attackers infect computers with fileless malware:
- A user visits an infected website or opens an infected email in a browser.
- An exploit kit scans the computer for unpatched vulnerabilities in Java or Flash plugins or software scripts that involve PowerShell processes.
- The exploit kit uses vulnerabilities for inserting fileless malware into Windows PowerShell or other system administration tools built into Windows.
- After successful installation, the fileless malware runs its payload in the available DLL.
- The malware starts its malicious activity within a legitimate process in the memory.
- The attack is successfully performed!
How to Detect and Protect Against Fileless Malware
The challenge raised by fileless malware is finding a new approach to executable entities in the system. Traditional approaches are sandboxing, execution emulation, and heuristics.
Sandboxing
Whenever a PowerShell process runs, it must be sandboxed so that all its API calls are wrapped by the sandbox layer and all potentially dangerous calls are thoroughly monitored and blocked in case a threat is detected.
But since PowerShell executes external processes quite often, sandboxing can only help to detect suspicious actions done by the script via cmdlets. As for RAM-based malware, sandboxing can help but only if what to sandbox is known. This can be a decent solution if potential attack vectors are known and corresponding processes are sandboxed. Otherwise, sandboxing the browser won’t help if malware is distributed via a remote code execution (RCE) vulnerability in an email client.
Execution Emulation
Since PowerShell became open source, it’s now possible to create an execution emulating interpreter for PowerShell scripts. Such an engine can be used to verify a script before allowing it to run in the actual PowerShell. An emulation engine can also be used to deal with script obfuscation and find magic string constants that can be used to identify a script as malicious. However, this won’t help you see what will happen after the external process is executed.
In the case of RAM-based malware, execution emulation is problematic. While it’s unknown at which point the thread will start to execute the shell code, it’s also unknown at which point execution emulation should be started.
Heuristics
The main heuristics that can be applied to PowerShell scripts are monitoring the appearance of new PowerShell scripts and the sources from which they come. It’s also necessary to monitor which processes are starting the PowerShell process, since it’s quite suspicious for a browser or Word to suddenly run PowerShell. Restrictions could be made to limit the processes that are allowed to start PowerShell. Yet heuristics can’t make precise conclusions as to whether a script is malicious. This is merely a plan B to find out that something is wrong.
For RAM-based malware, there’s a set of anti-exploitation techniques that are provided by EMET and Windows Defender Exploit Guard in Windows 10. These techniques include Control Flow Guard, CallerCheck, and StackPivot. But these aren’t always enough because, for example, modern browsers use JIT code compilers that produce pieces of executable code in memory. So there’s a set of memory pages that are accessible for writing and executing and aren’t related to any module. Thus, the Exploit Guard techniques can’t be applied to such code and malware can successfully exploit this fact.
The Silver Bullet
As you can see, the standard methods of fileless malware protection have many disadvantages. The most effective solution for both RAM-based and script-based malware detection would be so-called next-gen antivirus software that can analyze the behavior of the system as a whole instead of separate files and processes. The idea is that antivirus software should be capable of taking apart the timeline of system events to see if there are actions that demonstrate malware-like behavior. The challenging part is to find a way to detect malware actions in the stream of events. This is difficult because there are multiple legitimate actions happening between individual malware actions, and these actions are coming from various processes running across the operating system.
Conclusion
Fileless malware is an increasing threat, and there are still few ways to protect against it. Both RAM-based and script-based malware have a high chance of going unnoticed by standard antivirus software. We’ve discussed possible methods of fileless malware detection and protection. If you’re currently working on a security solution, Apriorit can offer you our professional cybersecurity development skills.
