SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsre-evasion

re-evasion

Data & analytics

View repository

Updated 10-15 21:34

About this skill

Detection Evasion and EDR Countermeasure Analysis

When to Use / When Not to Use

  • Use: analyze the evasion techniques of malicious samples/tools after they are detected (by antivirus, EDR)—AMSI bypass, ETW disablement, fileless execution, lolbin chains
  • Use: answer "why was it detected" and "where are the bypass points" (align with the detection side, step 5)
  • Use: execution chain analysis of fileless/in-memory payloads (samples where the payload does not touch disk)
  • Don't use: pure static code analysis (that is [[re-binary-core]]); dynamic analysis that does not care about bypass mechanisms and only observes behavior (that is [[re-behavior]])
  • Don't use: detection rule authoring itself (that is the YARA and detection engineering side of [[re-ioc]])
  • Note: this skill is mainly Windows-focused (AMSI/ETW/lolbin are all Windows concepts); similar countermeasures on Linux/macOS (ptrace detection, Dyld injection, kext bypass) can be applied using the same "evasion identification→bypass point location" framework

Tool Preparation

Evasion analysis requires dynamic execution + memory forensics: all within a sandbox ([[re-sandbox]] mandatory prerequisite, [[re-analyze/platform-tips]] highest principle). Verify all tools before use.

amsi.dll memory comparison — the primary method for locating AMSI patches (no standalone installer)

  • Principle: byte-by-byte comparison of the on-disk C:\Windows\System32\amsi.dll and in-memory amsi.dll; differences in function headers are the patch points
  • Obtain memory copy: Sysinternals procdump (Microsoft official website/winget install Microsoft.Sysinternals.Procdump）procdump -accepteula -ma <pid> mem.dmp; or [[re-memdump]] (gcore/WSL) for a full dump
  • Verification: for scenarios where the sample is not running, use AMSITrigger as a fallback; see step 2 for the comparison script

AMSITrigger — locate strings that trigger AMSI scanning (by Outflank)

  • Download: search GitHub for AMSITrigger(the original outflanknl repository is no longer available; community mirrors are common, such as RythmStick/AMSITrigger); a .NET tool, ready to use after extraction
  • Verification: AMSITrigger.exe -i test.ps1 outputs the detection status line by line (Detected / Not Detected)
  • Purpose: analyze "which strings in the script trigger detection" → the corresponding obfuscation/evasion targets

ETW monitoring — logman / SilkETW / WPR / ETWConsumer-type tools

  • logman (built into Windows): verify logman query providers | findstr /i sysmon；logman query -ets to view active sessions
  • SilkETW (open-sourced by Mandiant, C#): download from GitHub releases; verification: SilkETW.exe -t user -pn Microsoft-Windows-Sysmon -ot file -p out.etl can generate .etl
  • WPR (Windows Performance Recorder, built in): wpr -start after wpr -stop out.etl
  • Third-party ETW consumer tools such as ETWConsumer (search GitHub, as needed); local alternative for viewing providers: tracerpt parse .etl
  • Purpose: confirm whether ETW has been disabled—an interrupted/missing event stream is evidence of disablement (see step 3)

Sysmon / procmon — process chains and execution behavior (lolbin chain tracing)

  • Sysmon (Sysinternals, Microsoft official): configuration includes ProcessCreate (event 1, records parent-child processes and command lines); verification: Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational';Id=1} | select -First 1
  • procmon (Sysinternals): full coverage of file/registry/process/network, filterable by process tree; verification: procmon.exe /AcceptEula /Quiet can start
  • Neither has a distribution package; download from the Microsoft official website/Sysinternals

Operating Steps

Execute in order; archive the sha256 + path of each step's artifact (memory dump/ETL/log/command-line walkthrough record) (required by the [[re-ioc]] evidence chain).

  1. Evasion technique identification (classify first, then go deep)：

    • Input: sample/tool + detection trigger information (AV alert, EDR log, sandbox alert)
    • Classification checklist (archive by characteristic): AMSI bypass (patch / reflective loading), ETW disabling (patch provider / mask), fileless (in-memory execution / registry Run key + remote script / WMI), lolbin chain (rundll32 / mshta / regsvr32 / WMI / PowerShell), string encoding obfuscation (anti-signature)
    • Evidence collection: run in sandbox ([[re-sandbox]]) → Sysmon/procmon records the process creation chain and command line; at the same time [[re-memdump]] keeps a memory snapshot (dump-first by default, [[re-analyze/platform-tips]] "direct read vs dump"); enable PowerShell ScriptBlock logging (event 4104) and module logging
    • First run a baseline sample without patching to confirm the "detection trigger point" (see pitfall 5, aligned with step 5)

  2. AMSI bypass analysis (in-memory patch localization)：

    procdump -accepteula -ma <pid> mem.dmp        # 运行后取进程内存（或 gcore，见 [[re-memdump]]）
# 对照: 磁盘 amsi.dll 与内存中 amsi.dll 的函数头字节
# 常见 patch: AmsiScanBuffer 入口改为直接返回 0x80070057（"AMSI 已初始化"假成功）
#            或 EtwEventWrite 系列前几字节 patch 成 ret
    • Localization method: entry offset of AmsiScanBuffer in the on-disk amsi.dll (Ghidra/IDA or dumpbin /exports) → compare bytes at the same offset in the memory dump; any difference is the patch point
    • Other forms: hook before reflectively loading amsi.dll (Detour to user code), CLR-side bypass (disable AMSI provider at the managed layer)
    • Use AMSITrigger to verify "which strings trigger" → mutually corroborate the sample's obfuscation target and the bypass's effectiveness
    • Before localizing the patch, confirm the environment baseline: when the sample is not running, the on-disk/in-memory amsi.dll are consistent (rule out interference from EDR's own hooks, see pitfall 4)

  3. ETW disabling analysis：

    logman query -ets                                   # 活动会话；与样本运行前后对比
# SilkETW 捕获: 运行样本前后各抓一段，对比事件数量/内容
# 定位: 内存中 ntdll 的 EtwEventWrite / EtwEventWriteEx 前几字节 vs 磁盘（同步骤 2 对照法）
    • Disabling evidence: after the sample runs, the ETW event stream is interrupted (a certain provider has zero events/overall loss); the patch point is usually located at ntdll's EtwEventWrite*
    • Confirm scope: global disabling (modify EtwEventWrite itself) vs specific provider disabling (modify the provider's enable mask/Level) — determines the impact surface and detection-side recovery recommendations
    • Often appears in combination with AMSI (one patch, multiple targets); compare and report the two's linkage (see pitfall 1)

  4. lolbin chain tracing (rundll32/mshta, etc.)：

    # Sysmon 事件 1（ProcessCreate）按进程树关联，重点看父进程 + 命令行
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational';Id=1} |
  Select TimeCreated, @{n='Parent';e={$_.Properties[1].Value}}, @{n='Image';e={$_.Properties[3].Value}}, @{n='Cmd';e={$_.Properties[4].Value}}
    • Typical chain: cmd → rundll32.exe javascript:"..."、regsvr32.exe /s /n /u /i:http://... scrobj.dll、mshta.exe javascript:...、powershell -enc ... → in-memory payload
    • Key: looking only at the sample's own process will miss the real behavior (the sample executes via a whitelisted process — see the brokered execution pitfall in [[re-sandbox]]); observe the entire process tree, recording parent→child level by level
    • Fileless determination: process image path is non-standard (%TEMP%), script engine (wscript/cscript/mshta) loads remote or purely in-memory content, no corresponding on-disk file — payload evidence relies on memory dump and command line (see pitfall 3)

  5. Align with the detection side (why it was detected → evasion point)：

    • Compare the content matched by the detection alert (trigger string/behavior signature/import table characteristic) with the evidence from steps 2-4, forming: detection point (AV signature/behavior rule) → evasion point (patch/obfuscation/lolbin) → gap that can still be detected (see version differences in pitfall 4)
    • Output: evasion technique checklist + corresponding IOCs — hashes of amsi.dll/ntdll after in-memory patching, command-line patterns of lolbin combinations, memory characteristics of fileless payloads (into [[re-ioc]] YARA)
    • Conclusions must annotate the validation environment (OS version/EDR version/AV), and evasion effectiveness claims must be version-qualified

Cross-domain correlation

  • [[re-anti-analysis]]: This skill is the detection evasion branch of the gateway—packers/obfuscation are "static anti-analysis", while AMSI/ETW/fileless are "detection countermeasures"; in orchestration they are parallel
  • [[re-sandbox]]: Dynamic execution mandatory prerequisite—the entire evasion analysis runs in an isolated environment (network isolation + snapshots, see the highest principle in [[re-analyze/platform-tips]])
  • [[re-memdump]]: Memory patch localization and fileless payload forensics (dump-first by default)
  • [[re-behavior]]: Process chain/execution behavior observation (behavior-side corroboration of lolbin chains)
  • [[re-tracing]]: API call tracing—call sequence corroboration of patch target functions (AmsiScanBuffer/EtwEventWrite) to verify whether the bypass is effective
  • [[re-ioc]]: Evasion features (memory hashes/command-line patterns/lolbin combinations) feed into IOC and YARA rules
  • [[re-malware]]: Evasion-layer analysis of malicious samples (after re-malware behavior analysis, switch to this skill to dig deeper into evasion)
  • [[re-ebpf]]: Identification and countering of resident bpf hooks (fentry/kprobe/tracepoint/cgroup)
  • Reference the highest principle in [[re-analyze/platform-tips]] (default sandbox) and the Windows branch

Common pitfalls and traps

  • Evasion techniques intertwined with anti-sandbox: Symptom—the sample behaves "normally" in the sandbox (no evasion actions at all), and only bypasses in the real environment; Cause—the evasion code embeds anti-sandbox detection (it first probes the environment before deciding whether to enable the bypass); Countermeasure—separate "evasion analysis" from "environment masquerading" (the [[re-anti-analysis]] domain): first locate the anti-sandbox detection points (the interaction/timing/hardware fingerprint pitfalls of [[re-sandbox]]), or first lengthen the observation window using the delayed-observation approach of [[re-behavior]], then analyze the evasion logic
  • AMSI patch triggers integrity verification: Symptom—after patching, the sample behaves abnormally/crashes/detection escalates instead; Cause—EDR/Defender verifies the memory integrity of amsi.dll/ntdll (compares hashes against disk, see the AD13 self-verification idea in [[re-anti-analysis]]), or the sample performs self-verification itself; Countermeasure—first confirm the verification exists (frequency of repeated memory hash comparisons), patch a location that is "invisible to verification" (hook rather than the function body, keeping the overall hash consistent), and during analysis record the patch timing and verification trigger points
  • Fileless samples are hard to forensically obtain: Symptom—there is no sample file on disk, the report lacks "physical evidence", and the conclusion cannot stand; Cause—the payload runs entirely in memory/remote scripts/registry run keys, and conventional file forensics cannot capture it; Countermeasure—before running, first perform a full dump with [[re-memdump]] + procmon/Sysmon to record command lines and network; enable PowerShell ScriptBlock logging (event 4104); base conclusions on memory evidence + command lines + network flows, and have [[re-ioc]] collect memory-hash-type features
  • EDR version differences: Symptom—the same patch technique succeeds in environment A but fails or alerts in environment B; Cause—the patch offset (e.g., the AmsiScanBuffer entry bytes) changes with Windows patches and EDR hook versions; Countermeasure—confirm the offset dynamically on site (the memory comparison method in step 2 does not rely on fixed offsets, do not trust hardcoded offsets from the internet); annotate the conclusion with the verified environment version, and state evasion effectiveness claims with version qualifications
  • Missing detection logs → wrong direction: Phenomenon — without Sysmon/EDR logs, it is impossible to confirm "why it was detected," and analysis cannot be aligned; Cause — the environment has no log collection configured (Windows does not record ProcessCreate details by default); Countermeasure — add Sysmon configuration (ProcessCreate + NetworkConnect + ImageLoad) + PowerShell 4104, then rerun to reproduce; for detection alert information (antivirus UI/EDR events), capture it fully before analysis