FrameworkGuidesModulesRelease NotesAbout

Fileless Malware Surge: 2026 Trends in Memory-Only Attacks

Understand the 2026 surge in fileless and memory-only malware techniques, learn where defenders can detect them, and implement practical monitoring to catch threats that never touch disk.

Fileless Malware Surge: 2026 Trends in Memory-Only Attacks

File-based detection — scanning executables on disk, checking hashes against threat intelligence feeds, monitoring file creation events — has been the backbone of endpoint security for decades. Fileless malware deliberately avoids all of these detection surfaces by operating entirely in memory. No malicious files are written to disk. No new executables appear in file system monitoring. The payload exists only in memory, executing through legitimate system processes, and disappears on reboot.

In 2026, fileless techniques are no longer advanced tradecraft reserved for state-level operators. They appear in commodity malware, ransomware precursors, and off-the-shelf attack frameworks. This article examines why fileless attacks surged, how they operate, and where defenders can actually catch them.

What Changed Recently

Fileless techniques have existed for over a decade, but several trends accelerated their adoption in 2025–26:

  • EDR coverage expansion — As more organizations deploy EDR, file-based evasion has become unreliable. Dropping a custom executable to disk and hoping it is not scanned is a losing strategy. Operating in memory avoids the file scanning entirely.
  • PowerShell and .NET maturity — PowerShell, .NET, and the Windows Script Host provide rich execution environments that support complex operations without compiled executables. Combined with AMSI bypass techniques, these become reliable fileless execution platforms.
  • Reflective loading frameworks — Tools for reflective DLL loading, .NET assembly loading in memory, and shellcode execution through legitimate processes have matured and are widely available.
  • Cobalt Strike and alternatives — The dominant C2 frameworks all support fully in-memory operation by default. Beacon's reflective loading, inline execution, and BOF (Beacon Object Files) are designed specifically to avoid disk artifacts.

Categories of Fileless Attacks in 2026

| Category | Technique | Persistence | |---|---|---| | Script-based | PowerShell, VBScript, JScript execution via WMI or scheduled tasks | Registry/WMI persistence, no files | | Reflective loading | DLL or .NET assembly loaded directly into memory from a network resource or embedded payload | None — volatile by default | | Process hollowing | Legitimate process spawned, memory replaced with malicious code | Survives only until process terminates | | Registry-resident | Payload stored in registry values, loaded into memory at execution | Persistent across reboots | | Living off the land | Using built-in tools (certutil, mshta, rundll32) to fetch and execute payloads in memory | Depends on trigger mechanism |

How Fileless Attacks Work at a Conceptual Level

The common thread across all fileless techniques is that the malicious code is never written to the file system as a standalone executable. Instead, it exists as:

  • Encoded content in a registry value
  • A script passed as a command-line argument
  • Shellcode injected into an existing process's memory
  • A .NET assembly loaded via reflection
  • Content fetched from a remote URL and executed directly in memory

A Typical Fileless Attack Chain

  1. Initial access — A phishing email contains a macro, a link to a malicious page, or an attachment that triggers script execution.
  2. Script execution — PowerShell or WScript executes a command that downloads a second-stage payload and loads it directly into memory using .NET reflection or shellcode injection.
  3. In-memory operation — The payload runs entirely in the memory space of a legitimate process. It communicates with a C2 server, executes commands, and performs reconnaissance without creating files.
  4. Persistence — If persistence is needed, the attack stores encoded payloads in registry keys, WMI subscriptions, or scheduled tasks with inline scripts. No executable files are created.

Where Defenders Can Observe It

Fileless attacks avoid disk-based detection but leave traces in other telemetry:

PowerShell and Script Logging

  • Script Block Logging (Event ID 4104) — Records the full text of every PowerShell script block, including dynamically generated and decoded content. This is the single most valuable data source for detecting fileless PowerShell activity.
  • Module Logging — Records PowerShell pipeline execution details.
  • Transcription Logging — Records all PowerShell input and output to text files.

Process and Command-Line Monitoring

  • Sysmon Event ID 1 (Process Creation) with command-line logging captures the arguments passed to PowerShell, WScript, CScript, MSHTA, and other script hosts.
  • WMI Event Subscription monitoring (Sysmon Event ID 19/20/21) detects WMI-based persistence.
  • Scheduled Task creation (Event ID 4698) with inline script content in the task definition.

Memory-Level Telemetry

  • ETW Threat Intelligence provider — Provides kernel-level visibility into memory allocation and write operations, which is critical for detecting reflective loading and injection.
  • AMSI — The Antimalware Scan Interface inspects script content at execution time, catching known malicious patterns even when the script is assembled dynamically.
  • Memory scanning — Periodic scanning of process memory for known indicators (shellcode patterns, known framework signatures) detects resident threats that file scanning misses.

Network Telemetry

  • Cradle detection — Fileless attacks often fetch payloads from remote URLs. Network monitoring for download cradles (PowerShell IEX (New-Object Net.WebClient).DownloadString(...), certutil -urlcache, mshta <remote-url>) provides detection opportunities at the network layer.

Common Detection Blind Spots

  1. PowerShell logging not enabled — Without Script Block Logging, fileless PowerShell attacks are invisible. This remains the most common gap.
  2. AMSI bypassed — AMSI bypass techniques exist and are routinely used. If AMSI is bypassed, real-time script inspection fails.
  3. No memory scanning — Most organizations rely entirely on file-based scanning. Memory-resident threats persist until someone looks at memory.
  4. Command-line logging truncation — Some SIEM configurations truncate long command lines, cutting off the encoded payload portion that is the critical detection indicator.
  5. WMI and scheduled task blind spots — WMI subscriptions and scheduled tasks with inline scripts are often overlooked in detection coverage.

Practical Hardening and Monitoring Guidance

For Detection Engineering Teams

  • Enable and collect all PowerShell logging — Script Block Logging is the minimum. Module and Transcription logging provide additional coverage. Forward everything to your SIEM.
  • Build AMSI bypass detections — Monitor for known AMSI bypass patterns: amsiInitFailed, patching of AmsiScanBuffer, and reflection-based disabling of the AMSI provider.
  • Detect download cradles — Alert on process creation events where script hosts fetch content from URLs. The combination of powershell.exe with DownloadString, DownloadData, or Invoke-Expression from a network source is high-confidence suspicious activity.
  • Monitor for reflective loading indicators — .NET Assembly.Load() called from unexpected contexts, VirtualAlloc with PAGE_EXECUTE_READWRITE in script host processes, and thread creation in unusual memory regions.

For System Administrators

  • Enforce Constrained Language Mode — CLM through AppLocker or WDAC restricts PowerShell to a safe subset that prevents most fileless attack techniques. This is one of the most effective preventive controls.
  • Disable unused script hosts — If your environment does not need WScript, CScript, or MSHTA, block them through application control policies.
  • Harden WMI — Restrict remote WMI access and monitor WMI event subscriptions. Most legitimate automation does not create permanent WMI subscriptions.
  • Deploy ASR rules — Attack Surface Reduction rules for blocking Office macro child processes, script host launches from email, and other fileless attack entry points.

Lab Testing Context

The Veil Framework generates payloads that test various aspects of fileless execution and detection. Testing in a controlled lab environment validates that your PowerShell logging, AMSI, and memory scanning capabilities actually catch the techniques you expect them to catch.

The PowerShell payloads reference covers the defensive monitoring considerations specific to PowerShell-based attacks. Earlier articles on process injection and BYOVD attacks are related since injection and EDR disabling are often prerequisites for sustained fileless operation.

Related Reading

If your detection strategy requires a malicious file to exist on disk, you are missing a growing majority of attacks. Fileless is the new default. Your telemetry must cover memory, scripts, and behavior — not just files.