What Is Fileless Malware? How Memory-Only Attacks Evade Detection

• Definition: Fileless malware is malicious code that operates without writing executable files to disk, using legitimate OS tools or memory resident techniques instead.
• Where it appears: It commonly surfaces in enterprise attacks for example, via PowerShell scripts, Office macros, WMI, or registry hacks to deliver payloads entirely in memory.
• Why it matters: Because it leaves minimal disk artifacts, fileless malware often evades traditional antivirus and EDR tools.
• Key risk: Fileless attacks can maintain stealthy persistence e.g. via scheduled tasks or registry backdoors without triggering signature based defenses.

Introduction: Fileless malware aka memory based or zero footprint malware refers to threats that execute without dropping a visible file on the hard drive. Instead of installing a malicious EXE, the attack injects code into memory or leverages trusted system processes PowerShell, WMI, Regsvr32, etc. to run its payload. This approach means there is no new file for AV scanners to detect it may only live in RAM or in entries like the Windows Registry. For example, one analyst describes fileless attacks as injecting malicious code directly in memory or a medium which allows the malicious code to execute without touching the disk, leaving minimal or no artifacts on the hard drive.

Fileless malware is especially relevant today because modern attackers increasingly favor stealthy, fileless techniques in spearphishing, advanced persistent threats APTs, and ransomware campaigns. These attacks often start with everyday tools a PowerShell command from a phishing email or a compromised website that silently run malicious code. Once inside, attackers use fileless methods like loading code from registry keys or using signed system binaries to avoid detection. This tactic is common on enterprise endpoints and networks, where patch gaps or misconfigurations can expose living off the land vectors. As a result, fileless malware is a core concern for defenders: it underpins sophisticated intrusion chains and makes traditional defenses less effective.

How Fileless Malware Works

Fileless attacks follow a multi stage process similar to other intrusions but replace disk based payloads within memory or legitimate tool execution. A typical chain might look like this:

• Initial Access: The attacker gains entry by exploiting a vulnerability or tricking a user e.g. phishing an Office document. For instance, an exploit kit might run code directly in memory from a browser vulnerability. Common vectors include malicious Office macros, PDF exploits, or scripts in compromised websites.
• Payload Execution Memory: Instead of dropping an EXE, the exploit launches a script or command interpreter in memory. PowerShell is a popular vehicle MITRE T1059.001, as are WMI scripts, mshta.exe, or signed binaries e.g. regsvr32 that fetch and run code. In one documented case, attackers used a benign curl.exe call to download a PowerShell script which runs filelessly, meaning nothing obviously lands on disk. That script then allocated memory and loaded the malware payload entirely in RAM.
• Privilege Escalation / Credential Theft: With code running in memory, the attacker often harvests credentials e.g. using in memory credential dumpers to move laterally. CrowdStrike notes that Stage 2 of a fileless attack often involves stealing credentials to pivot through the environment. This, too, happens without leaving a binary on disk for example, the attacker may invoke Mimikatz via PowerShell.
• Persistence Memory or Trusted Keys: To survive reboots or user logouts, fileless malware may abuse registry keys, WMI event subscriptions, or scheduled tasks. CrowdStrike describes Stage 3 as modifying the registry or OS settings for a backdoor e.g. the Sticky Keys bypass. In practice, this means writing a malicious command into a registry Run key or WMI filter. Even though no EXE was dropped, the attacker has set up a way to re-invoke their code after reboot.
• Actions on Objectives: Finally, the attacker carries out their goal data theft, encryption, etc. using built in tools. In Stage 4, data is gathered and sent out or encrypted using native utilities. For example, an attacker might use Windows’ own compression and FTP clients to zip and exfiltrate data. In ransomware cases, the payload might invoke PowerShell one last time to encrypt files with a hidden encryption algorithm all while sidestepping disk based signatures.

Throughout this flow, the key is that the malicious code lives in volatile locations or trusted processes. The Securonix Threat Lab showed how an advanced backdoor subtly named SUBTLE#PAWS worked: it dumped large chunks of obfuscated PowerShell into HKCU\System registry keys, then used Get ItemProperty and Invoke Expression to execute them in memory. In effect, even though functions were stored persistently, the execution never touched disk the code went straight from the registry into RAM.

Similarly, another fileless technique is memory injection. As Qualys documented, an HTA/VBScript can download a PowerShell payload which reconstructs shellcode and uses Win32 APIs VirtualAlloc, CallWindowProc, etc. to execute a RAT in memory. In their Remcos RAT case, the 24.ps1 script simply assembled two Base64 blobs into memory and ran them without any EXE dropped on disk. The diagram below Figure illustrates this attack flow: a malicious .lnk launches mshta which downloads 24.ps1, and that PowerShell script itself allocates memory and executes the Remcos payload directly.

Figure: Example of a fileless Remcos RAT attack via malicious LNK→HTA→PowerShell. The loader script 24.ps1 reconstructs and runs the RAT entirely in memory, with no file written to disk.

Beyond scripts and registry tricks, fileless malware can also use legitimate living off the land binaries. For example, attackers might call Windows’ rundll32.exe, wmic.exe, or certutil.exe with special parameters to download or execute remote code. In one threat report, Storm 0249 used just curl.exe Windows 10+ built in to fetch a PowerShell loader from a spoofed Microsoft URL, then ran it with no user visible output. In another step, the group used reg.exe and findstr.exe to harvest the machine’s GUID but because those commands ran under a trusted SentinelOne process, most security tools simply don’t question them.

Real World Examples

Fileless techniques have been observed across many recent attacks. Below are notable examples 2024–2025 illustrating how adversaries use fileless malware:

• Quasar RAT via PSLoramyra Dec 2024: A security bulletin reported a fileless loader called PSLoramyra that abuses living off the land binaries to install Quasar RAT in memory. In this case, a script was injected into a process RegSvcs.exe with no executable on disk. The loader decoded a .NET payload in RAM and injected it into the running process. As researchers noted, the malware functions entirely within memory, leaving no traces on the disk. Persistence was achieved by creating a scheduled task, not by a conventional file.
• Remcos RAT K Loader May 2025: Qualys reported a PowerShell based shellcode loader named K Loader that delivered the Remcos RAT entirely in memory. The attack began with a malicious shortcut LNK file inside a ZIP. An HTA/VBScript used mshta.exe to run obfuscated VBScript, which in turn launched powershell.exe. The PowerShell script 24.ps1 combined two large Base64 blobs into memory and executed them via Windows API calls, with no binary dropped. Researchers highlight that the loader allocates memory and executes binary code directly in memory, a textbook fileless behavior. Figure
• Storm 0249 APT Dec 2025: The Storm 0249 group, an initial access broker shifted to highly stealthy tactics for ransomware access. A report described how they used a ClickFix social engineering trick to get a user to run a curl.exe command via the Windows Run dialog. This command fetched a PowerShell script from a spoofed site and executed it filelessly. The script then installed a malicious MSI that placed a trojanized SentinelAgentCore.dll alongside the real SentinelOne binary. When SentinelAgentWorker.exe ran, it sideloaded the rogue DLL, again staying off disk. Meanwhile, Storm 0249 used native tools e.g. reg.exe, findstr.exe under that trusted process to gather system identifiers. Because these ran under a signed security binary, the activity is unlikely to raise any red flags for defenders.
• Qakbot Qbot Campaigns: Qakbot, a prevalent banking trojan, has employed fileless loading in some campaigns. In one analysis, the Qakbot dropper set up a scheduled task and created several registry keys in HKCU:\SOFTWARE containing long Base64 encoded strings. The task’s script read each registry value, decoded the content, and executed the payloads in memory. In effect, Qakbot hid its components inside the registry and ran them via scheduled execution, leaving no new files.
• Cookbox Ukrainian Government: A CERT UA report described the Cookbox backdoor where malicious Excel documents with VBA macros downloaded a PowerShell payload and then stored it in the Windows registry. The macro called PowerShell from GitHub, and the payload ultimately hid in the Windows Registry which could then be called and executed at any given time. Specifically, Cookbox placed obfuscated PowerShell code under a key like HKU\SOFTWARE\Microsoft\XboxCache\db for later use. This registry injection meant the code persisted across reboots but only ran in memory.

These examples show that fileless malware is not just a theoretical trick it is actively used by ransomware gangs and APT actors alike. In each case, the malware resided in memory or trusted storage like registry keys, not as a standalone EXE. Defenders must therefore focus on detecting behaviors and telemetry around these steps, not just scanning for malicious files.

Why Fileless Malware Is Important

Fileless malware is critically important because it undercuts many standard security measures. Traditional antivirus and endpoint protection rely on identifying malicious files, but fileless attacks leave minimal or no artifacts for such tools. As Securonix explains, executing code straight from memory or registry allows modern malware to sidestep traditional detection methods. In practice, this means many fileless incidents go unnoticed until after data is stolen or systems are encrypted.

For organizations, this invisibility poses severe risks. Fileless attacks can lay dormant inside networks, using legitimate tools as cover. By blending into normal processes or Windows signed binaries, they evade signatures and whitelists. One analysis noted that when attackers ran reg.exe and findstr.exe under a trusted security process, the activity is unlikely to raise any red flags. This stealth buys attackers time to move laterally, harvest credentials, or stage ransomware without triggering alarms.

Operationally, fileless malware complicates incident response. With no dropped file to analyze, forensic recovery is harder. Investigators must rely on memory dumps and log analysis. For example, an IR team might need to search process memory or registry snapshots for injected shellcode. If memory is cleared e.g. system reboot or logging was not enabled, evidence may vanish.

The business impact can be high. Successful fileless breaches have enabled massive exfiltration or ransomware deployment without immediate detection, leading to extended outages and costly remediation. In some statistics, memory only attacks have been found to succeed far more often than file based ones though those are older Ponemon figures. What matters today is that as one expert put it, fileless attacks are 10 times more likely to succeed because they slip past endpoint defenses. In short, fileless malware demands that security teams adopt advanced detection behavioral analysis, memory forensics and assume that any system may already be compromised unless proven otherwise.

Common Abuse or Misuse

Attackers favor fileless techniques for their stealth and versatility. Why it’s effective: By using legitimate system tools, a fileless attack piggybacks on trusted functionality. Security products that allow PowerShell, WMI, or signed binaries to run normally give attackers free rein. For example, Storm 0249’s use of curl.exe under a signed process illustrates this: the adversary executed malicious steps in an environment the endpoint defense assumed was safe. This living off the land strategy means the malicious activity blends into routine operations, making it extremely hard to distinguish.

Abuse scenarios: Fileless methods are often part of multifaceted intrusion chains. An attacker may start with phishing or a drive-by exploit to drop a small script, then use it to roll out more powerful in-memory implants across the domain. Ransomware groups have also embraced fileless techniques for instance, embedding their payload in a macro and calling PowerShell so that no executable is ever written to disk. In a sense, any dual use admin tool becomes a weapon. Even Windows Event Viewer or Task Scheduler can be misused to reload malicious code from the registry or a hidden service.

Detection difficulty: Since fileless malware leaves little for signature scanning, defenders must look for anomalies. Securonix warns that such tactics are increasingly relevant and rely on manipulating trusted processes, so by the time conventional defenses notice something is wrong, the attacker may have already extracted data or encrypted systems. In short, attackers abuse fileless techniques to bypass whitelists and AV, and they do it by executing all steps in memory or via native functionality.

Detection & Monitoring

Detecting fileless attacks hinges on monitoring behavior and telemetry, since traditional file based indicators may be absent. Key sources include endpoint logs and audit data:

• Sysmon / Endpoint Logs: Enable Sysmon or similar agents to capture detailed events. Sysmon Event ID 13 registry value set is particularly useful. As one threat analyst notes, it’s highly unusual for legitimate software to create registry values containing scripting code. A query that flags any registry SetValue containing PowerShell commands Get ItemProperty, Invoke Expression, etc. can reveal malware injecting scripts. For example, Securonix used Sysmon to catch the SUBTLE#PAWS backdoor by spotting a new registry key with a long PowerShell script as its value. Similarly, watch for Sysmon Event ID 1 and 10 process creation and image loaded that show unusual parent child chains e.g. mshta.exe spawned by a user initiated process.
• PowerShell Logging: Turn on Windows PowerShell Module and Script Block Logging Event ID 4104. These logs capture executed PowerShell commands and scripts. Threat hunters look for suspicious patterns like Set ItemProperty writing to registry combined with web download aliases curl, Invoke WebRequest, IEX. In the SUBTLE#PAWS case, a hunting query looked for Set ItemProperty plus curl in PowerShell logs and successfully flagged the backdoor script. In general, any encoded commands, base64 blobs, or Invoke Expression calls in PS logs warrant investigation.
• Process Creation Event 4688/4689: Audit Windows process creation. Unusual launches of powershell.exe, cmd.exe, regsvr32.exe, mshta.exe, or cscript.exe from odd parents e.g. office apps, Explorer are suspicious.
• WMI Event Logs: Log event subscriptions or process starts via WMI e.g. Event ID 4698/4699 for scheduled tasks. Many fileless payloads use WMI event filters or tasks for persistence; watching for new filters or tasks referencing powershell.exe or scripts can catch them.
• Network/Endpoint Analytics: Some indicators may appear on the network e.g. unusual traffic from endpoints. EDR/XDR solutions should be tuned to flag anomalies like a process injecting code into another or an unusual DLL side loading as in Storm 0249. Because fileless attacks often ultimately contact C2 servers, abnormal DNS or HTTP patterns from workstations can also hint at a compromise. Behavioral detection IOAs observing the sequence of actions exploit → in memory code execution → lateral tools is vital.

Common blind spots: Fileless attacks thrive when logging is not comprehensive. For example, if PowerShell logging is disabled, or if Sysmon/EDR is not installed on a host, the fileless steps may leave no record. Also, memory only payloads leave no forensic traces on disk, making post mortem analysis difficult. This underscores the need for proactive monitoring of Sysmon, PowerShell logs, EDR and threat hunting: teams should assume an attacker could already be on the network and look for unusual behavior patterns.

Mitigation & Prevention

A defense in depth approach is required to block fileless malware:

• Application Control / Allowlisting: Enforce strict allowlisting AppLocker/WDAC to limit what can execute. For example, block or restrict Windows utilities known for abuse powershell.exe, wmic.exe, mshta.exe, rundll32.exe, etc. except for approved admins. White listing approved scripts and signing can prevent unauthorized scripts from running. Attack Surface Reduction ASR rules in Microsoft Defender or group policies can disable common exploits e.g. block macros from the internet.
• PowerShell Constrained Language: Use Group Policy to constrain PowerShell to Constrained Language Mode for non administrators, or block it entirely if not needed. This prevents many advanced fileless scripts from running. Similarly, disable or remove legacy scripting hosts cscript/wscript if possible.
• EDR and Memory Scanning: Deploy a modern EDR with capability to scan memory. CrowdStrike notes that its accelerated memory scanning feature helps protect against fileless and malware free attacks like APTs. In practice, use tools that can inspect process memory for known malicious code or anomalous hooks e.g. scanning for known shellcode patterns or dubious reflective injection.
• Restrict Macros and Office Settings: Configure Office to disable VBA macros by default, or only allow signed macros. Train users not to enable macros from untrusted sources. Macro based fileless infection is common, so this simple policy cuts off many attacks.
• Least Privilege & Hardening: Run users and servers with the least privileges needed. If attackers can’t gain administrative rights, many fileless payloads which need privileges to run code in other processes or write to HKLM will fail. Use tools like Microsoft LAPS for local admin accounts so credentials aren’t reused, and enable Credential Guard/LSA protection where available.
• Network Segmentation and Egress Controls: Limit communications from endpoints. Even if code runs in memory, it typically has to call home. Block known malicious domains and use proxy filtering for outbound connections. Segment critical systems so that if an attacker runs fileless malware on one machine, they can’t easily leap to domain controllers or file servers.
• Patching and Vulnerability Management: Keep systems patched. Many fileless attacks begin with exploitation of unpatched software to inject code. By reducing the attack surface e.g. hotfix Exchange, update browsers, you remove vectors that could host in memory exploits.
• Continuous Monitoring and Hunting: Finally, maintain strong logging as above and practice active threat hunting. Prevention isn’t perfect, so be prepared to detect anomalies. For instance, implement checks for abnormal registry writes or PowerShell invocations. A proactive hunt might look for the very signs Securonix did: registry SetValue events containing PowerShell keywords.

In summary, there is no single silver bullet. Mitigating fileless threats requires layering controls script restriction, EDR, network policy and assuming attackers will try to hide in plain sight. Behavioral and architectural defenses are key, since signature scans alone will miss fileless techniques.

Related Concepts

Fileless malware overlaps with several broader concepts:

• Living Off the Land LOTL: Attackers using fileless methods are often said to live off the land. This means they hijack legitimate tools already on the system PowerShell, certutil, etc. instead of bringing their own. Understanding common LOLBIN living off the land binaries abuse scenarios is crucial, as many fileless attacks abuse these signed utilities.
• In Memory Attacks: Fileless malware is a subset of in memory or memory resident malware. Other related techniques include reflective DLL injection and rootkits that never appear on disk. All of these require advanced detection strategies, memory forensics, behavior analysis.
• Script Based Attacks: Fileless often goes hand in hand with script abuse. Powershell scripts, WMI scripts, and Office macros are all vectors. In contrast, file based malware relies on dropping executables or libraries. When considering mitigation, it helps to cross reference defenses for script based threats.
• Attack Kill Chain: In a broader attack chain, fileless methods usually appear in execution and persistence phases MITRE ATT&CK. They complement credential theft or lateral movement tactics. For example, after stealing credentials with a fileless dumper, an attacker may also use credential theft tools. Understanding related lateral movement methods like Pass the Hash, remote WMI, Pass the Ticket can help contextualize a fileless breach.
• Endpoint Detection Engineering: Fileless malware highlights the need for endpoint analytics and low level logging. Concepts like Sysmon based hunting, EDR heuristics, and threat intelligence are adjacent areas that defenders must be proficient in to catch these attacks.

Together, these concepts emphasize that combating fileless malware isn’t isolated, it ties into the overall defense strategy against stealthy, advanced threats.

FAQs

• How is fileless malware different from traditional malware?

Traditional malware typically involves installing a program or dropping a malicious file on disk. Fileless malware avoids this by executing in memory or using built in tools. For example, instead of running a bad .exe, it might execute a PowerShell script in memory. The result is fewer disk artifacts; security software that scans files will often miss it.

• How do attackers deliver a fileless malware payload?

Common delivery methods include phishing attachments or compromised websites. For instance, an email might contain an Office document with a malicious macro that launches a PowerShell command. Or a malicious link might exploit a browser to run code in memory. Once the attacker has initial access, they often use native tools PowerShell, WMI, regsvr32, etc. to fetch and execute the payload directly in RAM.

• How can we detect if fileless malware is on a system?

You must rely on behavior and logs. Key indicators include unusual process activity e.g. powershell.exe launching from Word, or mshta.exe running unexpectedly and registry changes containing script code. Enabling Sysmon and PowerShell ScriptBlock logging is critical. For example, look for Sysmon Event ID 13 entries where the transactionstring contains Base64 or PowerShell commands. Also monitor PowerShell logs Event ID 4104 for encoded commands or abnormal cmdlet usage like Set ItemProperty with Invoke Expression. Any sign of scripting commands running without a file is suspicious. Network telemetry can help too a host making odd outbound connections after an internal exploit may indicate fileless C2.

• Can rebooting the machine remove fileless malware?

If the malware truly lived only in volatile memory, a reboot would wipe it out and all RAM clears on shutdown. In fact, some sources note that since fileless code exists in RAM, a reboot halts the breach. However, attackers often establish persistence before reboot by writing a startup script or registry entry. For example, they might set a reg key under HKCU\Run or WMI subscription that re launches the payload after reboot. So a reboot may temporarily eject the attacker, but they can simply reinfect via the persistence mechanism. Full remediation requires disabling the persistence e.g. cleaning the registry or scheduled task and then rebooting.

• What is living off the land LotL in fileless attacks?

LotL means using legitimate system utilities as malware launchers. It is a common technique in fileless attacks. For example, an attacker might use the signed binary regsvr32.exe with a malicious script or call powershell.exe to run an attack script. By doing this, the malicious action is hidden inside a trusted process. As one threat report noted, running reg.exe and findstr.exe under a legitimate SentinelOne process meant the actions are unlikely to raise any red flags. The LotL approach is essentially the core of many fileless schemes.

• How do fileless malware attacks stay persistent if they don’t create files?

Attackers write to places like the Registry or create scheduled tasks instead of files. For instance, they might add a command in the Windows Run keys or use a Sticky Keys or Ease of Access backdoor trick to launch code at login. They could also install a WMI event subscription to re-trigger their code on certain events. In every case, something on disk registry entries or settings causes the in memory code to run, even though the main payload file itself never existed. Persistence is often achieved by abusing these legitimate startup mechanisms.

• Can antivirus software detect fileless malware?

Signature based AV generally struggles with fileless threats, since there is no malicious file to hash or scan. Modern AV/EDR products rely on behavioral analysis or memory scanning to catch fileless attacks. For example, they may detect suspicious scripting activity or anomalous process injection. Ensuring endpoint protection has script monitoring and applying rules like Microsoft’s Attack Surface Reduction policies is important. In short, you need behavior based or managed detection, not just classic AV signatures.

Fileless malware is a stealthy category of attack that abuses native system tools and memory to run without touching disk. It is important because it circumvents many traditional defenses, making breaches harder to detect and investigate. Defenders should assume attackers will attempt fileless methods and therefore focus on behavioral indicators: enable advanced logging Sysmon, PowerShell, watch for anomalous script execution, and use EDR/Endpoint tools that scan memory or hook native APIs. Strict application controls blocking unnecessary scripting, least privilege policies, and threat hunting are key to mitigating fileless attacks. In short, combating fileless malware means shifting from file based defenses to monitoring what actions are happening in the system, so that even in memory exploits and payloads trigger alerts and can be stopped.

About the Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements for Fortune 500 companies, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.