Scenario 1: External Recon — Scanning From Outside The Network

Position: Unauthenticated, NOT on the target network
Goal: Enumerate external attack surface through proxy infrastructure without getting burned

Visual Overview

graph LR
    subgraph "Your Infrastructure"
        A[Attack Box] --> B[VPS / Cloud]
        A --> C[Residential Proxy]
        A --> D[Tor / Anonimization]
    end

    subgraph "Proxy Layer"
        B --> E[SOCKS5 Proxy]
        C --> F[Rotating Proxies]
        D --> G[Exit Node]
    end

    subgraph "Target Perimeter"
        E --> H[Firewall / WAF / IDS]
        F --> H
        G --> H
        H --> I[Target Services]
    end

    style A fill:#ff6600
    style H fill:#ff0000
    style I fill:#00ff00

1. Why Proxychains For External Recon?

What You're Hiding

• Source IP: Your real IP never touches target infrastructure
• Geographic location: Proxy can be in target's country (looks normal)
• ISP fingerprint: Datacenter IP vs residential IP matters

What You're NOT Hiding

• Scan patterns: Sequential port scans look the same regardless of source
• Request signatures: Tool-specific User-Agents, TCP window sizes, TTL values
• Timing patterns: Automated scanning has distinctive cadence
• DNS queries: Leak your real IP if proxy_dns is not enabled

2. Infrastructure Setup

Option A: VPS SOCKS Proxy (Most Common)

# On your VPS (DigitalOcean, Vultr, Linode, etc.)
# Create SSH SOCKS proxy from attack box → VPS
ssh -D 1080 -N -f -C root@YOUR_VPS_IP

# Verify SOCKS proxy is listening
ss -tlnp | grep 1080

# Configure proxychains
cat > /etc/proxychains4.conf << 'EOF'
strict_chain
proxy_dns
quiet_mode
tcp_read_time_out 15000
tcp_connect_time_out 10000

[ProxyList]
socks5 127.0.0.1 1080
EOF

OPSEC Notes:

• VPS IP is in datacenter range → target may rate-limit or block datacenter IPs
• VPS provider logs SSH connections → subpoena-able
• If VPS gets burned, it's traceable to your account

Option B: Multi-Hop Chain (Better OPSEC)

# Chain through multiple VPS nodes
# VPS1 (purchased with crypto) → VPS2 (different provider) → Target

# On attack box: SSH to VPS1, then VPS2
ssh -D 1080 -N -f -J root@VPS1_IP root@VPS2_IP

# Or chain proxychains through multiple SOCKS
cat > /etc/proxychains4.conf << 'EOF'
strict_chain
proxy_dns
quiet_mode

[ProxyList]
socks5 127.0.0.1 1080    # VPS1
socks5 VPS2_IP 1081       # VPS2 (second hop)
EOF

OPSEC Notes:

• Each hop adds ~50-200ms latency → scans take longer
• Each hop is a potential log source
• strict_chain = if any proxy fails, connection drops (good for OPSEC)
• dynamic_chain = skip dead proxies (faster but less controlled)

Option C: Residential Proxies (Best for Blending In)

# Commercial residential proxy (BrightData, Oxylabs, etc.)
# Rotates IPs from real ISP ranges

cat > /etc/proxychains4.conf << 'EOF'
strict_chain
proxy_dns
quiet_mode

[ProxyList]
# Residential proxy with rotation
socks5 gate.smartproxy.com 7000 USERNAME PASSWORD
EOF

# Or HTTP proxy (some tools work better with HTTP)
# http gate.smartproxy.com 7000 USERNAME PASSWORD

OPSEC Notes:

• Residential IPs are much harder for target to distinguish from normal traffic
• Rotating IPs = each connection comes from different IP → defeats IP-based rate limiting
• Expensive ($5-15/GB) but nearly undetectable for light recon
• Provider logs everything → not anonymous, just IP-masked

Option D: Tor (Maximum Anonymity, Minimum Stealth)

# Start Tor service
sudo systemctl start tor

# Configure proxychains for Tor
cat > /etc/proxychains4.conf << 'EOF'
strict_chain
proxy_dns

[ProxyList]
socks5 127.0.0.1 9050
EOF

# Test connectivity
proxychains -q curl https://check.torproject.org/api/ip

OPSEC Notes:

• ⚠️ Tor exit nodes are KNOWN and BLOCKLISTED by most corporate WAFs
• Many services return 403/captcha for Tor traffic
• Extremely slow for scanning (500ms+ per connection)
• Good for: Single-page web recon, OSINT
• Bad for: Port scanning, service enumeration, anything requiring speed

3. Detection Surface Analysis

What The Target Sees

┌─────────────────────────────────────────────────────────────┐
│                    TARGET'S PERSPECTIVE                       │
├─────────────────────────────────────────────────────────────┤
│                                                               │
│  Source IP: [PROXY_IP]  (NOT your real IP)                   │
│  But they CAN detect:                                        │
│                                                               │
│  ► Datacenter IP range    → "Why is AWS scanning us?"        │
│  ► Known proxy/VPN IP     → Blocklisted, flagged             │
│  ► Tor exit node          → Immediately blocked              │
│  ► Scan pattern           → Sequential ports = obvious       │
│  ► Tool fingerprint       → Nmap TCP window size, TTL        │
│  ► Request cadence        → 1 req/sec = automated            │
│  ► DNS queries            → If proxy_dns off, YOUR real IP   │
│  ► TLS fingerprint        → JA3/JA4 hash identifies tool     │
│                                                               │
└─────────────────────────────────────────────────────────────┘

Detection Layers (Outside → Inside)

IDS Signatures That Catch External Scans

# Snort/Suricata rules that fire on proxychains-through scans:

# SYN scan detection (won't fire - proxychains uses full TCP connect)
# alert tcp $EXTERNAL_NET any -> $HOME_NET any (flags:S,12; threshold:type both,...)

# TCP Connect scan (WILL fire - this is what proxychains does)
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"ET SCAN Potential TCP Port Scan";
  flags:S; threshold:type both, track by_src, count 50, seconds 120; sid:2009582;)

# Banner grabbing
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"ET SCAN Suspicious inbound to MSSQL";
  flow:to_server; content:"|12 01 00|"; depth:3; sid:2010935;)

# Nmap fingerprint (even through proxychains, TCP window size leaks)
alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"ET SCAN NMAP OS Detection Probe";
  dsize:0; flags:S,12; window:1024; sid:2009581;)

4. DNS Leak Prevention (CRITICAL)

The #1 OPSEC Killer for External Recon

# ❌ FATAL: DNS query goes DIRECT, bypassing proxy
proxychains nc target.com 80
# Your real IP → DNS server: "Resolve target.com please"
# DNS server logs: [YOUR_REAL_IP] queried target.com at 14:23:01

# ✅ SAFE: Force DNS through proxy
# In /etc/proxychains4.conf:
proxy_dns

# ✅ SAFEST: Use IP addresses directly (no DNS needed)
proxychains nc 203.0.113.50 80

# ✅ ALSO SAFE: Resolve through proxy chain first
proxychains -q dig @8.8.8.8 target.com
# Then use the IP directly

Verify No DNS Leaks

# Test 1: Check with tcpdump while running proxychains
sudo tcpdump -i any port 53 &
proxychains -q curl https://target.com
# If you see ANY DNS traffic → proxy_dns is NOT working

# Test 2: Use a DNS leak test service
proxychains -q curl https://dnsleaktest.com/results.html

# Test 3: Check /etc/resolv.conf isn't overriding
cat /etc/resolv.conf
# If this points to your local DNS, and proxy_dns is off → LEAK

DNS Leak Scenarios

5. External Scanning Through Proxychains

Port Scanning

# ⚠️ IMPORTANT: Only TCP Connect (-sT) works through proxychains
# SYN scans (-sS) CANNOT traverse SOCKS proxies

# Basic port scan through proxy
proxychains -q nmap -sT -Pn -n -T2 --top-ports 100 --open TARGET_IP

# Stealthy scan (slow, randomized)
proxychains -q nmap -sT -Pn -n -T1 \
    --scan-delay 15s \
    --max-retries 1 \
    --randomize-hosts \
    --top-ports 50 --open TARGET_IP

# Service version detection (louder - sends probes)
proxychains -q nmap -sT -Pn -n -sV --version-intensity 2 \
    -p 22,80,443,8080,8443 TARGET_IP

# Single port check with nc (lighter than nmap)
proxychains -q nc -zv -w 3 TARGET_IP 443

OPSEC Considerations:

• -T1 or -T2 timing → avoids IDS rate-based detection
• --scan-delay 15s → 15 seconds between probes (very slow but stealthy)
• --randomize-hosts → if scanning multiple targets, don't go sequential
• -n → CRITICAL — disables DNS resolution (prevents leaks)
• --max-retries 1 → don't hammer closed ports

Web Application Recon

# HTTP banner grab (minimal footprint)
proxychains -q curl -sI https://target.com
# Target sees: GET / from [PROXY_IP] with curl User-Agent

# Custom User-Agent (blend in)
proxychains -q curl -s -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" \
    https://target.com

# Directory enumeration (LOUD - use sparingly)
proxychains -q gobuster dir -u https://target.com -w /usr/share/wordlists/dirb/common.txt \
    -t 5 --delay 2s --random-agent

# Subdomain enumeration (passive first, then active)
# PASSIVE (no proxychains needed - queries public APIs):
subfinder -d target.com -silent
amass enum -passive -d target.com

# ACTIVE (through proxy - touches target DNS):
proxychains -q gobuster dns -d target.com -w subdomains.txt -t 3 --delay 1s

OPSEC Considerations:

• Passive subdomain enum (subfinder, amass passive) → ZERO target contact
• Active subdomain enum → queries target's DNS servers → logged
• Directory brute-force → very loud even at low speed, WAFs detect patterns
• Custom User-Agent → prevents tool fingerprinting in access logs

SSL/TLS Reconnaissance

# Certificate transparency logs (PASSIVE - no target contact)
curl -s "https://crt.sh/?q=%.target.com&output=json" | jq '.[].name_value' | sort -u

# SSL certificate details through proxy
proxychains -q openssl s_client -connect TARGET_IP:443 -servername target.com </dev/null 2>/dev/null | \
    openssl x509 -noout -text

# TLS version enumeration (touches target)
proxychains -q nmap -sT -Pn -n --script ssl-enum-ciphers -p 443 TARGET_IP

# testssl.sh through proxy (comprehensive but LOUD)
proxychains -q testssl.sh --quiet --color 0 target.com

6. Tool Fingerprinting & Evasion

JA3/JA4 TLS Fingerprinting

Problem: Each tool has a unique TLS Client Hello fingerprint
         WAFs like Cloudflare use JA3/JA4 hashes to identify scanners

Tool                    JA3 Hash                           Detection
─────────────────────────────────────────────────────────────────────
curl (default)          [known hash]                       LOW risk
python-requests         [known hash]                       MEDIUM risk
nmap ssl scripts        [known hash]                       HIGH risk - known scanner
gobuster                [known hash]                       HIGH risk - known scanner
Chrome browser          [standard hash]                    SAFE - normal traffic

Evasion:

# Use curl with TLS fingerprint spoofing
# curl-impersonate mimics Chrome's JA3
curl_chrome116 --socks5 127.0.0.1:1080 https://target.com

# Or use a headless browser (real browser fingerprint)
# Playwright/Puppeteer through proxy

TCP Fingerprinting (Even Through Proxychains)

Problem: Nmap's TCP Connect has distinctive window sizes, options
         IDS can identify nmap even through a proxy

Nmap TCP Connect characteristics:
  - Initial window size: 1024 (distinctive)
  - TCP options ordering: specific to nmap
  - Timing patterns: predictable intervals

Evasion:
  - Use curl/wget instead of nmap for web ports
  - Use masscan through a direct tunnel (not SOCKS)
  - Randomize timing with --scan-delay + jitter

7. Rate Limiting & Throttling

WAF/IDS Thresholds (Approximate)

Recommended Scan Speeds

# PARANOID (avoid all detection, very slow)
proxychains -q nmap -sT -Pn -n -T1 --scan-delay 30s --max-retries 0 \
    -p 80,443 TARGET_IP
# Speed: ~2 ports/minute

# CAREFUL (avoid most detection)
proxychains -q nmap -sT -Pn -n -T2 --scan-delay 5s --max-retries 1 \
    --top-ports 20 --open TARGET_IP
# Speed: ~12 ports/minute

# MODERATE (acceptable risk, faster results)
proxychains -q nmap -sT -Pn -n -T3 --max-retries 2 \
    --top-ports 100 --open TARGET_IP
# Speed: ~100 ports/minute (likely triggers IDS)

# AGGRESSIVE (don't care about detection)
proxychains -q nmap -sT -Pn -n -T4 --top-ports 1000 --open TARGET_IP
# Speed: ~500+ ports/minute (WILL trigger everything)

IP Rotation Strategy

# Rotate source IP per target (using residential proxy)
for target in $(cat targets.txt); do
    # Each connection gets new residential IP
    proxychains -q nmap -sT -Pn -n --top-ports 20 --open $target
    sleep $(shuf -i 30-120 -n 1)  # Random 30-120 second pause
done

# Or use multiple VPS with round-robin
# proxychains.conf with random_chain:
random_chain
chain_len = 1

[ProxyList]
socks5 VPS1_IP 1080
socks5 VPS2_IP 1080
socks5 VPS3_IP 1080
# Each connection randomly picks one proxy

8. Operational Mistakes to Avoid

Common OPSEC Failures

Pre-Flight Checklist

# Before any external scan:
# 1. Verify proxy is working
proxychains -q curl -s https://api.ipify.org
# Should show PROXY IP, not your real IP

# 2. Verify DNS isn't leaking
sudo tcpdump -i any port 53 -c 5 &
proxychains -q curl -s https://target.com > /dev/null
# tcpdump should show ZERO packets

# 3. Verify proxy_dns is enabled
grep -i "proxy_dns" /etc/proxychains4.conf
# Should return: proxy_dns

# 4. Verify quiet mode
grep -i "quiet_mode" /etc/proxychains4.conf
# Should return: quiet_mode

# 5. Test with non-target site first
proxychains -q curl -sI https://httpbin.org/ip
# Verify returned IP matches proxy, not you

9. OPSEC Risk Matrix — External Recon

10. Alternatives to Proxychains for External Recon

Tools With Native Proxy Support (Better Than Proxychains)

# curl (native SOCKS5 support — no proxychains needed)
curl --socks5-hostname 127.0.0.1:1080 https://target.com
# --socks5-hostname = DNS resolved at proxy (safe)
# --socks5 = DNS resolved locally (UNSAFE)

# nmap (native proxy support since 7.90)
nmap --proxies socks4://127.0.0.1:1080 -sT -Pn -n TARGET_IP
# ⚠️ Limited: only supports -sT scan type

# wget (native proxy)
export ALL_PROXY=socks5://127.0.0.1:1080
wget https://target.com

# nikto (native proxy)
nikto -h target.com -useproxy socks5://127.0.0.1:1080

# gobuster (native proxy)
gobuster dir -u https://target.com -w wordlist.txt --proxy socks5://127.0.0.1:1080

# sqlmap (native proxy)
sqlmap -u "https://target.com/page?id=1" --proxy="socks5://127.0.0.1:1080"

Why native proxy is better than proxychains:

• No LD_PRELOAD library injection artifacts
• No libproxychains.so in process memory
• No proxychains config file on disk
• DNS handling is tool-controlled (more reliable)
• Better error handling when proxy dies

11. Quick Reference — External Recon Commands

# ===== INFRASTRUCTURE SETUP =====
# SSH SOCKS proxy to VPS
ssh -D 1080 -N -f -C root@VPS_IP

# ===== PASSIVE RECON (ZERO TARGET CONTACT) =====
# Certificate transparency
curl -s "https://crt.sh/?q=%.target.com&output=json" | jq -r '.[].name_value' | sort -u

# Shodan (API - no target contact)
shodan host TARGET_IP

# Subdomain enumeration (passive)
subfinder -d target.com -silent

# ===== ACTIVE RECON (THROUGH PROXY) =====
# Single port check
proxychains -q nc -zv -w 3 -n TARGET_IP 443

# Light port scan
proxychains -q nmap -sT -Pn -n -T2 --top-ports 20 --open TARGET_IP

# Web banner
proxychains -q curl -sI -A "Mozilla/5.0" https://target.com

# SSL cert info
proxychains -q openssl s_client -connect TARGET_IP:443 </dev/null 2>/dev/null

# ===== VERIFY OPSEC =====
# Check your exit IP
proxychains -q curl -s https://api.ipify.org

# Check for DNS leaks
sudo tcpdump -i any port 53 -c 3 &
proxychains -q curl -s https://target.com > /dev/null

7. Cloud Platform Detection & Logs

When targeting cloud-hosted infrastructure, understanding what gets logged is critical. Cloud providers log API calls extensively through CloudTrail (AWS), Activity Logs (Azure), and Cloud Audit Logs (GCP). Many external recon activities trigger these logs.

AWS CloudTrail (High-Risk Events)

Azure Activity Logs (High-Risk Events)

GCP Cloud Audit Logs (High-Risk Events)

Key Takeaway: Cloud providers log extensively. When performing external recon against cloud-hosted assets, assume every API call is logged with source IP, timestamp, and user-agent. The goal is to match normal access patterns (timing, geography, tools) rather than trying to avoid logs entirely.

References

• PayloadsAllTheThings – Network Pivoting Techniques
• RedTeamRecon – External Recon Methodology
• Pentesting Notes – External Reconnaissance
• HideAndSec – Pivoting Cheatsheet