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:
-
App-ID (Application Identification) — classifies every session by application, not just port. It looks at the first few packets and decides: "this is
web-browsing,ssl,smb,wmi". Policy is applied per application. Running nmap? It might classify your scan as something suspicious before you even get results.Note: The four labels below are the most relevant examples for pentesters — App-ID's full library contains ~3,000+ named application signatures, updated via Palo Alto's content release feed alongside IPS signatures. A full, searchable list is available at applipedia.paloaltonetworks.com.
web-browsing: Unencrypted HTTP traffic. The firewall reads the payload looking for plaintext HTTP verbs (e.g.,GET / HTTP/1.1).ssl(or TLS): Encrypted traffic. The firewall inspects the initial unencrypted TLS "Client Hello" packet, using the SNI (Server Name Indication) to identify the target domain before encryption kicks in.smb: Windows file/printer sharing and IPC. The firewall looks deep into port 445 traffic for specific magic bytes (\xFFSMBor\xFESMB) in the SMB Negotiate Protocol request.wmi: Windows Management Instrumentation. Tricky because it uses dynamic ports. The firewall monitors RPC on TCP 135 for requests to the specific WMI UUID, then tracks whatever random high port is negotiated.msrpc: Generic Microsoft RPC traffic (lateral movement, DCOM, WinRM all generate MSRPC flows before their specific application is identified). Often used as a catch-all before the firewall fully resolves the app.kerberos: Port 88 authentication traffic. A non-standard host suddenly initiating Kerberos flows (e.g., a pivot box that is not a domain-joined workstation) will look anomalous to App-ID-aware policy rules.ldap/ldaps: Active Directory LDAP queries. High-volume LDAP classification from a single host is a direct signal of AD enumeration (SharpHound, ADExplorer,ldapsearch).nmap: App-ID contains an explicit named signature for Nmap. If nmap's service detection probes (-sV) are run against an App-ID-aware NGFW, the firewall can classify the session asnmapdirectly — enabling a policy rule to block it outright, independent of flood protection thresholds.unknown-tcp/unknown-udp: The most dangerous classification for a red teamer. If App-ID cannot match a session to any of its ~3,000 known signatures, it falls back tounknown-tcporunknown-udp. Many enterprises apply a stricter or deny policy to unknown traffic than to known-bad traffic — reasoning that if they can't identify it, they shouldn't allow it. Custom C2 implants running on unusual ports, non-standard protocol implementations, or poorly fingerprinted tools are at highest risk of landing inunknown-*and getting silently dropped.- 💡 Pentester Tip (Tool OPSEC): Firewalls don't just look at the HTTP method; they fingerprint the client. Default tools like
curl,ffuf, ordirsearchscream their identity via default User-Agents (e.g.,Fuzz Faster U Fool...) and missing browser headers (likeAccept-Language). To ensure traffic is confidently classed as normalweb-browsingand flies under the IPS radar, never run default configs. Always spoof a complete, modern browser User-Agent string. Even better, copy a full set of legitimate HTTP headers from a real browser session and inject them intoffuf/curl, or route traffic through Burp Suite while keeping your proxy's requests looking like standard browser traffic. - 💡 Pentester Tip (Avoiding
unknown-*): Route your C2 traffic over ports and protocols that App-ID can confidently classify as legitimate applications — HTTPS on port 443 (ssl), DNS on port 53 (dns). An implant beaconing over TCP/4444 with a custom binary protocol will almost certainly hitunknown-tcpand get denied or flagged for manual review. If you must use a non-standard protocol, wrap it inside a recognized one (e.g., WebSockets over HTTPS), so App-ID classifies the outer session assslorweb-browsing.
Sources: App-ID Overview — PAN-OS Docs · Applipedia — Full App-ID Library · App-ID Technology Brief · Unknown Traffic Policy — PAN-OS Docs
-
Threat Prevention (IPS Engine) — signature-based detection. Fires on known attack patterns in cleartext or decrypted traffic: SQLi, XSS, path traversal, brute force attempts. If you're using default tool configs (sqlmap, ffuf, nikto), signatures will match you. Present in every NGFW (Palo Alto, Fortinet IPS, Cisco Snort engine, Check Point IPS Blade).
- 💡 Pentester Tip (The HTTPS Blindspot): If a target exposes both port 80 (HTTP) and 443 (HTTPS), always launch your attacks over 443. Over port 80, the firewall reads your payload (
UNION SELECT,../) in plaintext and drops it instantly. Over port 443, the payload is encrypted. Unless the enterprise has gone through the painful process of importing the web server's private certificates into the firewall for "Inbound SSL Decryption", their IPS engine is completely blind to your encrypted attack and it sails right through.
- 💡 Pentester Tip (The HTTPS Blindspot): If a target exposes both port 80 (HTTP) and 443 (HTTPS), always launch your attacks over 443. Over port 80, the firewall reads your payload (
-
Zone Protection / Flood Protection — anti-reconnaissance at the zone or interface level. Rate-limits port scans, ICMP sweeps, UDP sweeps. Default thresholds on PAN-OS: ~100 events per 2 seconds. Enterprises often tune this lower. Equivalent features exist in FortiGate (DoS Policy), Cisco Firepower (Rate Limiting), etc.
- 💡 Pentester Tip (Rate Limiting): To slip past flood protection, you must artificially throttle your tools to stay well below the threshold (aim for < 10 req/sec).
nmap: Use explicit controls like--max-rate 10(never exceed 10 pkts/sec) or--scan-delay 500ms(hard pause between probes). Do not just rely on-T2.
nmap -Pn -sS -p 80,443,445 --max-rate 10 <target>ffuf: Use-rate 5to strictly limit the fuzzer to 5 requests per second.
ffuf -w dirlist.txt -u https://<target>/FUZZ -rate 5dirsearch: Lower the threads (-t 1) and add a delay (--delay 0.5).
dirsearch -u https://<target>/ -t 1 --delay 0.5curl: Since curl fires a single request, it's safe on its own. If you are scriptingcurlin a Bash loop, always addsleep 1to manually throttle it.
for ip in $(cat targets.txt); do curl -s https://$ip; sleep 1; done
- 💡 Pentester Tip (Rate Limiting): To slip past flood protection, you must artificially throttle your tools to stay well below the threshold (aim for < 10 req/sec).
-
SSL/TLS Decryption — without this policy configured, any inline IPS is blind to HTTPS payload. It only sees the TLS handshake (JA3 fingerprint, SNI). Most enterprises do not decrypt all traffic — this is your friend.
-
URL Filtering / Web Categorization — category-based blocking for HTTP/S. Less relevant during exploitation, more relevant during initial C2 callouts. Present in all NGFWs and standalone proxies (Zscaler, Netskope, etc.).
-
WildFire / Sandboxing — forwards unknown or suspicious files traversing the firewall to a cloud sandbox (or local appliance) for behavioral detonation and analysis. When a user downloads a binary over HTTP, or a file is transferred via SMB, the NGFW intercepts it, sends a copy to the sandbox, and holds or allows the delivery based on the verdict. This is not signature-based — the sandbox actually executes the file in an instrumented VM and watches for malicious behavior (C2 callbacks, privilege escalation, file encryption, etc.). Present in Palo Alto (WildFire), Fortinet (FortiSandbox), Check Point (SandBlast Threat Emulation), Cisco (Threat Grid / Secure Malware Analytics).
- 💡 Pentester Tip (Bypassing Sandboxes): Even fully custom, signature-free payloads can be caught by WildFire if they exhibit suspicious runtime behavior. Key evasion strategies:
- Sandbox Detection: Check for sandbox indicators before executing your payload — low RAM (<4GB), no user interaction history, VM artifacts (VMware tools, VirtualBox Guest Additions), short system uptime (<5 minutes), or a small number of running processes. If detected, have the payload exit cleanly or behave benignly.
- Time-Delayed Execution: Most sandboxes detonate files for 60–120 seconds. Add a
Sleep(300000)(5 minutes) or wait for genuine user interaction (mouse movement, keystrokes) before executing the malicious logic. (Caveat: Advanced sandboxes like WildFire now hookSleep()and fast-forward it. Use indirect delays — repeated file I/O loops, complex math operations — that are harder to accelerate.) - Staged Payloads: Deliver a benign first-stage dropper that passes sandbox inspection, then have it pull the real payload from your C2 only after confirming it's running on a real workstation. The sandbox never sees stage two.
- Encrypted / Password-Protected Archives: Deliver payloads inside password-protected ZIPs or encrypted containers. The NGFW cannot extract and detonate what it cannot open. The user opens it with the password you provided via a separate channel (email body, chat).
- 💡 Pentester Tip (Bypassing Sandboxes): Even fully custom, signature-free payloads can be caught by WildFire if they exhibit suspicious runtime behavior. Key evasion strategies:
-
DNS Security / DNS Sinkholing — intercepts all DNS queries passing through the firewall and inspects them against threat intelligence feeds, DGA (Domain Generation Algorithm) detection ML models, and DNS tunneling heuristics. Malicious or suspicious domains are either blocked outright or sinkholed (resolved to a controlled IP, killing the connection silently). Also detects abnormal DNS query patterns — high volume, long subdomain labels, TXT record abuse — that indicate DNS-based exfiltration or C2 tunneling. Present in Palo Alto (DNS Security subscription), Fortinet (DNS Filter), Check Point (Anti-Bot DNS), and standalone DNS firewalls (Cisco Umbrella, Infoblox BloxOne).
- 💡 Pentester Tip (DNS Evasion):
- C2 Domains: Never use freshly registered domains — they are instantly flagged as "newly seen" by DNS Security feeds. Age your domains 30+ days before an engagement, and categorize them (via domain fronting or by hosting legitimate content) so they appear as
business-and-economyortechnologyrather thanunknownorparked. - DNS Tunneling (
iodine,dnscat2): These tools encode data into DNS subdomain labels (e.g.,aGVsbG8.yourdomain.com). Modern DNS Security ML models detect the high-entropy, unusually long subdomain strings instantly. If you must tunnel over DNS, keep query volume extremely low, use short labels, and mix in legitimate-looking queries. - Sinkhole Awareness: If your C2 domain gets sinkholed, your implant resolves to the firewall's sinkhole IP and phones home to the SOC instead of you. Always have your implant validate the resolved IP against an expected value before connecting.
- C2 Domains: Never use freshly registered domains — they are instantly flagged as "newly seen" by DNS Security feeds. Age your domains 30+ days before an engagement, and categorize them (via domain fronting or by hosting legitimate content) so they appear as
- 💡 Pentester Tip (DNS Evasion):
-
File Blocking / File Type Filtering — a content-based policy that inspects files traversing the firewall and blocks specific file types regardless of whether IPS signatures match. The NGFW performs true file-type identification by reading magic bytes / file headers (not just extensions), so renaming
beacon.exetobeacon.pdfdoes not bypass it. Admins define policies like "block PE executables over HTTP in the untrust-to-trust zone" or "block.hta,.ps1,.jar,.vbsglobally." Present in every major NGFW (Palo Alto File Blocking profiles, Fortinet Antivirus file filter, Check Point Content Awareness).- 💡 Pentester Tip (Bypassing File Blocking):
- Know What's Blocked: Identify the file types the policy blocks before attempting delivery. Try downloading a benign
.exe— if it's blocked, you know PE files are filtered. - Use Allowed Containers: If raw executables are blocked, wrap payloads inside file types that are typically allowed —
.iso,.img,.vhdxdisk images (which mount natively on Windows 10+), or Office documents with embedded macros. The NGFW sees an ISO file, not a PE. - In-Memory Delivery: Skip file transfer entirely. Use
execute-assembly(Cobalt Strike / Sliver) or PowerShellIEX(IWR ...)to load payloads directly into memory over an encrypted channel. No file ever crosses the NGFW for inspection. (Caveat: This shifts the detection risk to the endpoint — EDR/AMSI will be your concern instead.) - Abuse Allowed Protocols: File blocking policies are often scoped per-application (e.g., blocking
.exeoverweb-browsingbut not oversslorftp). If the policy has gaps, pivot your delivery to an uninspected protocol.
- Know What's Blocked: Identify the file types the policy blocks before attempting delivery. Try downloading a benign
- 💡 Pentester Tip (Bypassing File Blocking):
-
Data Loss Prevention (DLP) — inspects outbound traffic for patterns matching sensitive data. Looks for credit card numbers (Luhn algorithm validation), Social Security Numbers, custom regex patterns (employee IDs, project codenames), and document fingerprints. When a match is found, the NGFW can block the transfer, alert, or both — even if the transfer is over an allowed protocol. Present in Palo Alto (Enterprise DLP), Fortinet (DLP sensor), Check Point (DLP Blade), and standalone DLP proxies (Symantec DLP, Digital Guardian).
- 💡 Pentester Tip (DLP-Aware Exfiltration): DLP is primarily a concern during the exfiltration phase:
- Encrypt Before Exfil: DLP pattern matching works on cleartext. If you
7z a -pPassword -mhe=on loot.7z dump.csvand then exfiltrate the encrypted archive, DLP sees random bytes, not SSNs. (The-mhe=onflag encrypts even the filenames inside the archive.) - Chunk and Encode: Break large data extracts into small chunks and Base64-encode them. DLP regex patterns are tuned for contiguous structured data (16-digit card numbers, SSN format
XXX-XX-XXXX). Fragmented, encoded data doesn't match. - Use Steganography for Small Extracts: For high-value, low-volume data (API keys, passwords, hashes), embed the data into image files or DNS queries. DLP is looking for bulk structured data patterns, not 32 characters hidden inside a JPEG.
- Encrypt Before Exfil: DLP pattern matching works on cleartext. If you
- 💡 Pentester Tip (DLP-Aware Exfiltration): DLP is primarily a concern during the exfiltration phase:
-
Credential Phishing Prevention — detects when corporate credentials (AD usernames and passwords) are being submitted to websites outside the corporate domain. The NGFW learns what corporate credential patterns look like (by integrating with AD via User-ID) and then inspects outbound HTTP POST bodies for strings that match known usernames or password hashes. If a user types their corporate password into
evil-login.com, the firewall blocks the submission in real-time. Present in Palo Alto (Credential Phishing Prevention), Zscaler (Cloud Browser Isolation + credential exposure), and some endpoint-based solutions (Microsoft Defender SmartScreen).- 💡 Pentester Tip (Phishing Engagements): If your red team is running a phishing campaign with a credential-harvesting portal:
- Categorize Your Domain: Ensure your phishing domain is categorized as something legitimate (
business-and-economy,health-and-medicine) on Palo Alto's URL filtering database. Uncategorized or newly-registered domains trigger extra scrutiny and credential submission monitoring. - Use HTTPS: Credential Phishing Prevention on some platforms only inspects HTTP POST bodies in cleartext. If your phishing site runs over HTTPS and the enterprise does not perform outbound SSL decryption on that URL category, the credential submission is encrypted and invisible to the engine.
- Submit via JavaScript: Instead of a standard HTML
<form>POST, use JavaScriptfetch()orXMLHttpRequestto submit credentials via an API endpoint. Some engines only inspect traditional form submissions, not XHR/fetch payloads. (This is increasingly less effective on modern deployments, but still works against older configurations.)
- Categorize Your Domain: Ensure your phishing domain is categorized as something legitimate (
- 💡 Pentester Tip (Phishing Engagements): If your red team is running a phishing campaign with a credential-harvesting portal:
-
IoT / Device-ID Security — profiles every device on the network by its traffic patterns, OS fingerprint, DHCP fingerprint, and application usage — then enforces security policy per device type (workstation, IP camera, printer, HVAC controller, medical device, etc.). If a device classified as "IP Camera" suddenly starts initiating SMB connections or running PowerShell, the firewall flags or blocks the anomalous behavior immediately. Present in Palo Alto (IoT Security / Device-ID), Fortinet (device identification), Cisco (ISE device profiling), and standalone NAC solutions (Forescout).
- 💡 Pentester Tip (IoT Pivoting): If you compromise an IoT device (printer, camera, building management system) as a pivot point:
- Expect Strict Microsegmentation: Many enterprises create per-device-type security zones. A compromised printer might only be allowed to talk to the print server on port 9100. Your lateral movement from that device will be blocked at the NGFW before it reaches anything useful.
- Mimic the Device's Normal Traffic: If you pivot through a device, keep your traffic profile matching what the firewall expects from that device class. An IP camera making DNS queries to your C2 domain looks anomalous; an IP camera streaming RTSP to its NVR looks normal.
- Prefer Workstations as Pivots: IoT devices are increasingly monitored precisely because they're soft targets. If you have the choice, always pivot through a standard Windows/macOS workstation — the expected traffic profile is far broader, giving you more room to operate.
- 💡 Pentester Tip (IoT Pivoting): If you compromise an IoT device (printer, camera, building management system) as a pivot point:
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:
- Correlation Rules / Scheduled Searches — pre-built detection rules that run on a schedule (e.g., every 15 minutes checking the last 1-hour window). In Splunk, these are ESCU (Enterprise Security Content Updates). Sentinel uses KQL-based Analytics Rules. Elastic uses Detection Rules. The principle is identical: if your activity stays below a threshold within a single time window, the rule simply never fires. Know the window; pace your activity.
- Example 1 (Auth Spraying): A rule triggers on
> 10 failed logins per user in 1 hour. Strategy: Run 8 login attempts at 1:45 PM. Pause. Run 8 more at 2:05 PM. Because you stayed under the threshold within the rolling time window, no alert fires. - Example 2 (Web Fuzzing): A rule triggers on a
High volume of HTTP 404 errors (>50) in 30 mins. Strategy: Throttle your fuzzer to yield roughly forty 404s per half hour, or run a fast burst, hit 40 errors, and pause the scan entirely for 31 minutes. - Example 3 (Lateral Movement): A rule triggers on
Multiple Windows Event 4624 (Network Logon) to 5 distinct hosts within 15 minutes. Strategy: Pass-the-Hash into 3 hosts. Wait 20 minutes before pivoting to the next group of hosts.
- Example 1 (Auth Spraying): A rule triggers on
- Indicator Lookup Tables — exact-match lists of known-bad strings. Most commonly applied to User-Agent fields (
sqlmap,nikto,nmap,python-requests), but also IP reputation lists, JA3 hashes, and known C2 domain IOCs.- 💡 Pentester Tip (Header Replay): The easiest and most bulletproof bypass is to just capture a real HTTP request from your own Chrome/Firefox browser (using DevTools or Burp Suite) and play it back in your tooling. Don't just paste right over the
User-Agentstring—copy the entire header block (Accept,Accept-Language,Sec-Fetch-*). Because these tables operate on a naive blocklist of known-bad strings, sending a copied real request completely circumvents them while perfectly mimicking all expected secondary browser headers.
- 💡 Pentester Tip (Header Replay): The easiest and most bulletproof bypass is to just capture a real HTTP request from your own Chrome/Firefox browser (using DevTools or Burp Suite) and play it back in your tooling. Don't just paste right over the
- Statistical Anomaly Detection (UEBA) — flags massive statistical outliers (e.g., a "3-sigma" event falls outside 99.7% of normal behavior — in UEBA's one-tailed model, this means the rarest ~0.15% of activity). It automatically learns a 30+ day baseline per user and host. If an HR employee usually transfers 50MB a day between 9 AM and 5 PM, and suddenly pulls 2GB at 3 AM, it triggers an anomaly alert. In short pentests, this rarely matters. In long-term red teams, it's deadly. Present in Splunk UEBA, Sentinel UEBA, Exabeam, Securonix, etc.
- 💡 Pentester Tip (Blending into "1-Sigma"): To avoid triggering a 2-sigma or 3-sigma anomaly alert, you must operate exactly within the target's "1-sigma" (normal everyday) behavior curve. Use their account only during their active business hours. Do not make bizarre connections (e.g., an HR rep RDP-ing into a Domain Controller). When exfiltrating data, do not pull gigabytes at once; "bleed" the data out via a slow trickle (e.g., 20MB per day) mixed into normal web traffic so it registers as standard baseline activity.
- Risk-Based Alerting (RBA) — the harder one. Instead of one rule firing on a threshold, multiple weak signals accumulate into a risk score. You trigger 3 low-severity detections and nothing happens — until the 4th tips the score over the threshold and creates a high-priority alert. You can't always evade this by staying slow; you have to minimize your signal footprint altogether.
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:
- ICMP host discovery — sweep of /24 with ping is logged and often alerted
- TCP SYN scans at any real speed — flood protection tracks per-source, per-zone
- UDP scans — noisy, slow to respond, and logged
- Banner grabbing / service detection (
-sV) — App-ID fingerprints your probes - OS detection (
-O) — generates unusual TCP flag combinations, IPS signature territory
Web application testing is where IPS Threat Prevention shines:
- Default sqlmap HTTP headers include
sqlmap/X.Yin the User-Agent — instant lookup table hit in any SIEM --level=5 --risk=3sqlmap fires hundreds of payloads per parameter, very fast — IPS will match SQLi signatures- ffuf/gobuster: At default concurrency (40-100 req/s), this looks like a DDoS scan, not a browser. It also triggers repeated 404s.
- Evasion Pivot: Use a tight delay, inject real headers, and filter known-bogus sizes so the SIEM doesn't see a flood of uniform errors.
ffuf -w wordlist.txt -u https://<target>/FUZZ -rate 5 -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36..." -fc 404
- dirsearch: Like ffuf, the default threads will trip flood protection, and the default UA will trip lookup tables.
- Evasion Pivot: Drop threads to 1, enforce a hard delay, and use the built-in random user-agent flag.
dirsearch -u https://<target>/ -t 1 --delay 1 --random-agent
- Nuclei: The most dangerous tool to run blind. It sends known, highly signatured public exploit payloads (CVEs) at incredible speed. Any inline IPS will flag this immediately.
- Evasion Pivot: Never run default Nuclei against a defended target. Only run informational templates, lower the rate limit drastically, and use a proxy to manipulate headers/timing if needed.
nuclei -u https://<target> -t http/misconfiguration/ -rl 10 -c 2 -H "User-Agent: Mozilla/5.0..."
- Nikto hits known paths in a predictable sequence — signature-matched immediately
DNS and passive recon — this is your safest phase:
- crt.sh, SecurityTrails, Shodan, BGP/ASN lookups don't touch the target network at all
- Do as much passive recon as possible before going active
Credentials / brute force:
- Repeated auth failures per user within a window → SIEM lockout/brute force correlation
- Spraying is safer than stuffing, but slow spray still accumulates risk score events
- Default tools (Hydra, Medusa) have obvious UA strings and connection patterns
- 💡 Pentester Tip (Safe Auth Evasion): When testing lists of credentials against a protected portal, follow these rules to evade baseline detection:
- Never use Hydra/Medusa for web apps: Send requests through Burp Suite Intruder or a custom script wrapping a real browser session. This ensures your headers and TLS fingerprints perfectly mimic a standard user.
- Spray, don't Stuff: Never test 500 passwords against 1 user (Stuffing). That instantly triggers Event 4625 (Account Lockout). Instead, test 1 highly-likely password against 500 different users (Spraying).
- Rotate Source IPs (FireProx): If 50 failed logins hit the SIEM from your single IP, the firewall blocks you. Route your authentication attacks through tools like FireProx (using AWS API Gateways) or Proxychains. Each auth attempt arrives from a different AWS API Gateway IP, breaking SIEM source-IP correlation. (Caveat: AWS has a finite IP pool per region, so IPs will eventually repeat on large sprays. Also, some enterprises block known cloud provider IP ranges entirely — verify first.)
- Time Dilate: Defeat domain-wide correlation thresholds by pacing your spray over hours. Map the spray to the detection window (e.g., executing exactly 1 auth attempt every 2 minutes across the domain).
- 💡 Pentester Tip (Safe Auth Evasion): When testing lists of credentials against a protected portal, follow these rules to evade baseline detection:
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:
- 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 flagEvent 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 KerberosAS-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 triggersEvent 4768alerts).
- Rubeus Syntax:
- Pass-the-Ticket (PTT): The pinnacle of stealth. Reach into a compromised machine's
LSASSmemory, 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 logsEvent 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
- Rubeus Syntax:
- 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 (
- Defense: Modern domains disable NTLM entirely, enforce Credential Guard (which isolates NTLM hashes in VBS), and place admins in
- WMI Remote Execution
- Defense: Highly signatured by EDRs. SIEMs immediately flag
Event 4688(Process Creation) ifWmiPrvSE.exespawns suspicious child processes likecmd.exeorpowershell.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.ApplicationorShellWindows). When you ask that COM object to run a command over the network, the execution happens inside a trusted process (likemmc.exeorexplorer.exe) instead of the highly monitoredWmiPrvSE.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 flagmmc.exespawning 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.
- Why it works: Windows is full of legitimate administrative COM objects (like
- Defense: Highly signatured by EDRs. SIEMs immediately flag
- 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 (loadingSystem.Management.Automationinto an unexpected process) to break process tree correlation.
- Defense: PowerShell Script Block Logging (
- SMB Enumeration
- Defense: EDRs flag telemetry when binaries like
net.exeorsmbclientrun with specific arguments (e.g.,net use /IPC$). SIEMs flag rapid sequentialIPC$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 directNetShareEnumAPI calls, generating zero command-line telemetry and zero process creations.
- Defense: EDRs flag telemetry when binaries like
- LDAP / AD Recon (BloodHound)
- Defense: Default
SharpHound.exeis 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.
- Defense: Default
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):
- Overrides Always Win, Order Doesn't Matter: It's a common misconception that argument order determines precedence (e.g., putting
-Tlast to override--scan-delay). In reality, Nmap processes-Ttemplates in Phase 1, then unconditionally overwrites them withdelayed_options(--scan-delay,--max-retries,--max-rtt-timeout) in Phase 2, completely ignoring argument order. (Note:--max-rateis slightly different—it's an entirely independent packet-governor mechanism that places a hard volume ceiling on top of whatever the-Ttemplate calculates).Under the Hood:nmap.ccOverride LogicNmap stores specific timing flags in memory during the initial parsing phase. It waits until the
-Ttemplate has set the global baseline, and then systematically overwrites those baseline constraints. Because this code block sits after the parsing loop, command-line argument order is mathematically irrelevant./* 1. Apply the -T template first to set the background baseline */ if (o.timing_level != -1) { apply_timing_template(o.timing_level); } /* 2. Unconditionally overwrite with explicit delayed_options */ if (delayed_options.scan_delay != -1) o.scan_delay = delayed_options.scan_delay; if (delayed_options.max_retries != -1) o.max_retries = delayed_options.max_retries; - Why keep
-Tif using--scan-delay? Never use--scan-delayalone. 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-T1background processing while explicitly capping the probe rate. - The "Too Slow" Paradox: Lab-based packet capture analysis reveals an OPSEC paradox: in controlled environments,
nmap -T1stealth scans can actually generate more total packets on a target interface than-T3over time. Why? Because a 20-port-T1scan 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-T4burst 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.) - The Ultimate Proxy Evasion: For maximum stealth against a single target, stop scanning directly. Routing modern tools (like
naabu -proxyornmap -sTviaproxychains) through a SOCKS proxy or SSH-Dtunnel 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:
--max-rate(The Ceiling): Ensures Nmap never exceeds a certain volume of packets per second.--scan-delay(Strict Pacing): Forces Nmap to go to sleep for exactlyXmilliseconds between every single packet, destroying any possibility of a burst. (Note: Using this silently kills any--max-parallelismarguments).
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)
endAvoid App-ID fingerprinting. Craft traffic that looks like normal applications:
- Use HTTPS wherever possible — payload is encrypted, inline IPS sees only TLS metadata unless they have SSL decrypt
- Mimic browser TLS fingerprints (JA3) — tools like
curlhave distinct JA3s; use an actual browser or a tool that mimics one - Avoid running raw Nmap service detection (
-sV) against App-ID-aware firewalls — it sends weird probes that App-ID doesn't classify cleanly
Bypass IPS Threat Prevention signatures:
- Don't use default tool payloads. The fastest way to get blocked by a WAF or IPS is running default
sqlmapagainst a target. An inline IPS will catch a standardUNION SELECTimmediately. - Use
sqlmapTamper Scripts: Tamper scripts proactively mutate your payloads so they still execute on the backend database but bypass the regex firewall signatures trying to match them.- Syntax Example:
sqlmap -u "http://target.com/page?id=1" --tamper="space2comment,randomcase" --dbs space2comment: Replaces all spaces with inline SQL comments (e.g.,SELECT id FROMbecomesSELECT/**/id/**/FROM). WAFs triggering on spaces miss the payload entirely, but the database parser strips the comments and runs it flawlessly.randomcase: Randomizes capitalization of SQL keywords (e.g.,SELECTbecomessElEct). Great for archaic, case-sensitive WAF regexes.between: Replaces the>operator withNOT BETWEEN. Many simple WAFs instantly ban angle brackets>inside HTTP requests to stop XSS and SQLi globally. This script convertsid > 1into the functionally identical (but bracketless)id NOT BETWEEN 0 AND 1.charencode: URL-encodes the entire payload string. This works well if the WAF inspects the raw HTTP request linearly, but the backend web application decodes the string before feeding it to the database driver.
- Syntax Example:
- Fragmented payloads across multiple requests can bypass simple pattern matching
- For path traversal: use URL encoding variations (
%2e%2e%2f,..%2f,%2e%2e/)
SSL decrypt blind spot:
- If your C2 is over HTTPS to a domain that looks legitimate, inline IPS likely won't decrypt it
- Use domains with clean categorization (not "uncategorized" — that flags URL filtering)
- Avoid IPs as C2 destinations — suspicious in App-ID classification
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:
- PTH: Do it exactly once to reach your objective, not as a broad network sweep.
- BloodHound: Use the
--stealthflag (targets only necessary LDAP queries), or collect manually with targeted AD Explorer snapshots instead of generating massive LDAP read spikes. - Avoid enumerating every host — enumerate strictly what you need for the immediate objective.
Blend with the Baseline (UEBA):
- Stay active exclusively during business hours when event volume is naturally high. Admin tools running at 3 AM flag immediately.
- Avoid perfectly consistent timing patterns (e.g., executing exactly every 5.0 seconds is a statistical, robotic anomaly).
Minimize RBA (Risk-Based Alerting) Signal Count:
- Each weak detection event adds to an aggregate "Risk Score." Even if no single alert fires, enough events clump together into a SOC "Notable."
- The fewer types of suspicious activity you generate, the safer you are. Recon → exploit → post-ex in one linear host chain is infinitely safer than broad scanning + multiple exploitation attempts + massive lateral movement all at once.
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
- 6_EDR — endpoint detection evasion (separate problem from network detection)
References
Palo Alto NGFW — Inline Engines
- App-ID: App-ID Overview — PAN-OS Administrator's Guide
- Threat Prevention (IPS): Threat Prevention Overview — PAN-OS Administrator's Guide
- Zone / Flood Protection: Zone Protection and DoS Protection — PAN-OS Administrator's Guide
- SSL/TLS Decryption: Decryption Overview — PAN-OS Administrator's Guide
- URL Filtering: URL Filtering Overview — PAN-OS Administrator's Guide
- WildFire / Sandboxing: WildFire Overview — PAN-OS Administrator's Guide; Advanced WildFire — Evasion Technique Coverage
- DNS Security / Sinkholing: DNS Security Overview — PAN-OS Administrator's Guide; Configure DNS Sinkholing
- File Blocking: File Blocking Profiles — PAN-OS Administrator's Guide
- Enterprise DLP: Enterprise Data Loss Prevention Overview; Palo Alto Enterprise DLP Product Page
- Credential Phishing Prevention: Credential Phishing Prevention — PAN-OS Administrator's Guide; Set Up Credential Phishing Prevention (Feature introduced PAN-OS 8.0)
- IoT Security / Device-ID: Device-ID Overview — PAN-OS Administrator's Guide; IoT Security Overview
Off-Path Detection — SIEM & Detection Platforms
- Splunk ESCU (Enterprise Security Content Updates): Splunk Security Content on GitHub; Splunk Enterprise Security Documentation
- Microsoft Sentinel Analytics Rules (KQL): Microsoft Sentinel Documentation; Sentinel Detection Rules on GitHub
- Elastic Detection Rules: Elastic Detection Rules on GitHub; Elastic SIEM Documentation
- Risk-Based Alerting (Splunk RBA): Splunk Risk-Based Alerting Framework
- UEBA: Splunk UEBA Documentation; Microsoft Sentinel UEBA
Nmap Timing & Evasion
- Nmap Timing Templates: Nmap Timing and Performance — Official Docs
- Nmap Source (
nmap.cc) — timing override logic: Nmap Source Code on GitHub
Evasion Tooling & Techniques
- sqlmap Tamper Scripts: sqlmap Tamper Scripts — Official Wiki
- FireProx (rotating AWS API Gateway IPs): FireProx on GitHub
- naabu (proxy-based port scanning): naabu on GitHub
- ffuf (web fuzzer): ffuf on GitHub
- dirsearch: dirsearch on GitHub
- dnscat2 (DNS C2/tunneling): dnscat2 on GitHub
- iodine (DNS tunneling): iodine on GitHub
Lateral Movement & Post-Exploitation
- Overpass-the-Hash / Pass-the-Key: Rubeus — Kerberos Abuse Toolkit; HarmJ0y — Abusing Kerberos
- Pass-the-Ticket: Rubeus ptt documentation; Mimikatz
kerberos::ptt - DCOM Lateral Movement: Matt Nelson (enigma0x3) — DCOM Lateral Movement; MITRE ATT&CK T1021.003 — DCOM
- BOFs (Beacon Object Files): Cobalt Strike BOF Docs; TrustedSec BOF Collection
- BloodHound / SharpHound: BloodHound on GitHub; SharpHound — Collection Methods
- AD Explorer (offline snapshot): Sysinternals ADExplorer
Windows Event IDs Referenced
- Event 4624 (Successful Logon): Microsoft — 4624 Event Schema
- Event 4625 (Failed Logon): Microsoft — 4625 Event Schema
- Event 4688 (Process Creation): Microsoft — 4688 Event Schema
- Event 4768 (Kerberos TGT Request): Microsoft — 4768 Event Schema
- Event 4769 (Kerberos Service Ticket Request): Microsoft — 4769 Event Schema
- Event 4104 (PowerShell Script Block Logging): Microsoft — 4104 Event Schema