When you hear about malware, there’s a good chance you think of sketchy executables or files with extensions like .DOCX or .PDF that, once opened, execute malicious code. These are examples of file-based attacks—and while they can be bad, they’re nothing compared to their fileless cousins.
As the name suggests, fileless attacks don’t rely on traditional executable files to get the job done but rather in-memory execution, which helps them evade detection by conventional security solutions.
In this post, we’ll explore topics like how fileless attacks work, why they’re effective, and what you can do to find and block fileless threats.
Fileless attacks explained
In contrast to file-based attacks that execute the payload in the hard drive, fileless attacks execute the payload in Random Access Memory (RAM). Executing malicious code directly into memory instead of the hard drive has several benefits, such as:
- Evasion of traditional security measures: Fileless attacks bypass antivirus software and file signature detection, making them difficult to identify using conventional security tools.
- Increased potential for damage: Since fileless attacks can operate more stealthily and with greater access to system resources, they may be able to cause more damage to a compromised system than file-based attacks.
-
Memory-based attacks can be difficult to remediate: Since fileless attacks don’t create files, they can be more challenging to remove from a system once they have been detected. This can make it extra difficult for forensics to trace an attack back to the source and restore the system to a secure state.
Fileless attacks vs Living-off-the-land (LOTL) attacks
If you read our article on LOTL attacks, you may be confused: Aren’t fileless attacks and LOTL attacks the same thing? Well, yes and no.
LOTL attacks are anytime an attacker leverages legitimate tools to evade detection, steal data, and more, while fileless attacks refer purely to executing code directly into memory. While both types of attacks often overlap, they are not synonymous.
Think of fileless attacks as an occasional subset of LOTL attacks. Fileless attacks can and often do leverage LOTL techniques to execute payload into memory, but they can also do so without leveraging a legitimate system tool or process at all.
PowerShell script extracted from a Microsoft Word document. If macros are enabled, it would execute the code in memory upon being opened. Source.
For example, an attacker can use PowerShell to download and execute a malicious payload directly in memory, without writing it to the disk. In this case, the attack is both LOTL (since PowerShell is a legitimate tool) and fileless (as the payload is executed in memory).
On the other hand, an attacker injecting malicious JavaScript into a website can exploit browser vulnerabilities and execute payloads in memory. This fileless attack executes code without writing to the hard drive, but doesn’t qualify as LOTL as it doesn’t use a legitimate system tool or process.
5 different ways fileless attacks execute code in memory
Once an attacker gains access through phishing or exploiting vulnerabilities, they can execute malicious code in memory using several methods, some of which may overlap with LOTL techniques.
Below are five common techniques used in fileless attacks:
- PowerShell: A legitimate scripting that can execute malicious code directly in memory. As mentioned earlier, this technique overlaps with LOTL attacks as it leverages a built-in system tool.
- Process hollowing: Process hollowing is a fileless technique where attackers create a new process in a suspended state, replace its memory content with malicious code, and then resume the process. The malicious code executes in memory without writing to the disk.
- Reflective DLL injection: In this fileless attack, attackers load a malicious Dynamic Link Library (DLL) into a legitimate process’s memory without writing it to the disk. The DLL is executed directly in memory, evading detection by traditional security software.
- JavaScript and VBScript: Fileless attackers can use JavaScript or VBScript to run malicious code directly in memory within a web browser or other applications that support these scripting languages.
- Microsoft Office macros: Fileless attackers can use malicious macros embedded in Microsoft Office documents to execute code in memory when the document is opened. This method takes advantage of the legitimate macro functionality, making it an example of an LOTL technique as well.
Note that fileless attacks often rely on exploiting vulnerabilities in system components in each of these instances (such as Office or web-browsers) to execute their code.
Preventing and spotting fileless attacks: Quick tips
| Prevention Method | Description |
|---|---|
| Keep software and systems updated | Regularly update your operating systems, applications, and security software to patch vulnerabilities that could be exploited by fileless attackers. |
| Regularly review security logs | Examine security logs for unusual activity or patterns that could indicate a fileless attack, such as unexpected PowerShell usage or excessive network connections. |
| Employ behavioral analytics | Use advanced threat detection tools that employ behavioral analytics to identify and block fileless attacks based on their unique behavior patterns. |
| Restrict macro usage | Limit the use of Microsoft Office macros by disabling them or allowing only digitally signed and trusted macros. |
Malwarebytes EDR and Exploit Protection: Safeguarding against fileless attacks
Malwarebytes Exploit Protection can effectively block many fileless attacks by monitoring and reinforcing application behavior, hardening applications, and ensuring advanced memory protection.
To configure Exploit Protection Advanced settings, follow these steps:
-
Go to Configure > Policies in Nebula.
-
Select a policy and navigate to Protection settings > Advanced settings > Anti-exploit settings.
Exploit Protection settings in a policy in Malwarebytes EDR.
Here’s an overview of the protection layers offered by Malwarebytes EDR Exploit Protection:
- Application Hardening: By enforcing security measures like DEP and ASLR, and disabling potentially vulnerable components like Internet Explorer VB Scripting, Application Hardening reduces the attack surface and makes it more difficult for fileless malware to exploit weaknesses in applications.
- Advanced Memory Protection: This layer prevents fileless malware from executing payload code in memory by detecting and blocking techniques such as DEP bypass, memory patch hijacking, and stack pivoting, thereby stopping the attack before it can cause harm.
- Application Behavior Protection: This layer also detects and blocks exploits that do not rely on memory corruption, such as Java sandbox escapes or application design abuse exploits. Options include Malicious LoadLibrary Protection, Protection for Internet Explorer VB Scripting, Protection for MessageBox Payload, and protection against various Microsoft Office macro exploits.
- Java Protection: These settings protect against exploits commonly used in Java programs. By guarding against Java-specific exploits, such as web-based Java command execution and Java Meterpreter payloads, Java Protection can effectively prevent fileless attacks that leverage Java vulnerabilities to infiltrate systems and execute malicious code.
Fighting fileless threats with Malwarebytes EDR: Configuring Suspicious Activity Monitoring in Nebula
Malwarebytes Endpoint Detection and Response (EDR) offers an effective solution to detect and mitigate fileless malware threats by monitoring potentially malicious behavior on endpoints. The Suspicious Activity Monitoring feature in Nebula uses machine learning models and cloud-based analysis to detect questionable activities. In this section, we will outline how to configure Suspicious Activity Monitoring in Nebula.
To enable Suspicious Activity Monitoring in your policy:
- Log in to your Nebula console.
- Navigate to Configure > Policies.
- Click “New” or select an existing policy.
- Choose the “Endpoint Detection and Response” tab.
- Locate “Suspicious Activity Monitoring” and enable it for the desired operating systems.
Suspicious Activity monitoring detections in Nebula showing a possible fileless attack. On the right, we see the command line context for this process in our organization.
Advanced Settings offer additional options for activity monitoring. To configure these settings:
- In the same “Endpoint Detection and Response” tab, find the “Advanced Settings” section.
- Enable “Server operating system monitoring for suspicious activity” to extend monitoring to server operating systems.
- Enable “Very aggressive detection mode” to apply a tighter threshold for flagging processes as suspicious.
- Toggle “Collect networking events to include in searching” to ON (default) or OFF, depending on your preference. Turning it OFF decreases traffic sent to the cloud.
Flight Recorder Search
Flight Recorder Search collects all endpoint events within its search functionality. By configuring Suspicious Activity Monitoring in Malwarebytes EDR through the Nebula platform, you can effectively counter fileless malware threats by monitoring processes, registry, file system, and network activity on the endpoint.
Respond to fileless attacks quickly and effectively
Managed Detection and Response (MDR) services provide an attractive option for organizations without the expertise to manage EDR solutions. MDR services offer access to experienced security analysts who can monitor and respond to threats 24/7, detect and respond to fileless attacks quickly and effectively, and provide ongoing tuning and optimization of EDR solutions to ensure maximum protection.