Aktive Reconnaissance — Praktischer Workshop

Sie wiederholen die Demonstration allein. Drei Container, eine saubere Methodik, ein Bericht, den Sie einem Kunden übergeben würden. Das ist das Skelett der Reconnaissance, das Sie durch Ihre gesamte Karriere begleiten wird.

Dauer: 90 Min bis 2 h.

Ergebnis: ~/labs/rapport/reconnaissance.md (2 Seiten) und alle Artefakte in ~/labs/scans/ + ~/labs/captures/.

Das Lab in einem Befehl

Modul 01 hat das Docker-Lab mit einem Container eingeführt. Hier gehen wir zu drei Containern im selben privaten Netzwerk über: ein Kali-Angreifer und zwei Ziele mit sehr unterschiedlichem Profil, um Sie zu zwingen, Ihre Scans zu variieren. Das Compose-Setup erledigt die ganze Arbeit:

cd labs/docker/module-04-recon-active
docker compose up -d

Dreißig Sekunden später haben Sie ein Netzwerk 10.20.30.0/24 mit drei Maschinen darin. Als würden Sie ein echtes internes Segment scannen.

---

Was Sie liefern müssen

Am Ende des Workshops haben Sie in ~/labs/ innerhalb des Angreifer-Containers (auf Ihrem Host persistiert):

1. scans/decouverte.txt — Ausgabe des initialen ARP-Scans.
2. scans/12-ports.nmap + scans/20-ports.nmap — vollständige TCP-Scans pro Ziel.
3. scans/12-versions.nmap + scans/20-versions.nmap — Versionsscans.
4. scans/20-nse.nmap — gezielte NSE-Skripte auf den erwarteten Schwachstellen.
5. scans/20-udp.nmap + scans/20-snmp.txt — UDP-Recon und SNMP-Inventar.
6. scans/20-smb.txt — SMB-Enumeration (Freigaben, Benutzer, Richtlinie).
7. scans/12-web.txt — Web-Reconnaissance (whatweb, gobuster, curl).
8. captures/scan-syn.pcap — tcpdump-Mitschnitt eines SYN-Scans.
9. scans/scapy-verification.txt — Ausgabe des Scapy-Skripts.
10. rapport/reconnaissance.md — zwei Seiten, vorgegebene Struktur.

---

Voraussetzungen

Sie müssen Modul 01 abgeschlossen haben: Docker Desktop einsatzbereit, das Image inskillsec/kali-lab bereits gebaut. Andernfalls verweisen wir auf den Workshop von Modul 01 für den ersten Build (rund zehn Minuten).

Schnelle Überprüfung:

docker images inskillsec/kali-lab
docker info | grep -i "operating"

Falls inskillsec/kali-lab nicht aufgeführt ist, baut das Compose-Setup es beim ersten Befehl — bitte warten.

---

Schritt 1 — Das Lab starten (2 Min)

cd labs/docker/module-04-recon-active
docker compose up -d

Drei Container starten: der Angreifer (10.20.30.5), das reichhaltige Linux-Ziel (10.20.30.20) und das saubere Web-Ziel (10.20.30.12).

Zustand prüfen:

cd ..
./verifier-lab.sh module-04-recon-active     # bash / macOS / Linux / WSL
.\verifier-lab.ps1 module-04-recon-active    # PowerShell

Sie müssen drei Dienste mit Status running sehen. Falls m04-cible-linux bei starting bleibt, warten Sie noch dreißig Sekunden: Metasploitable 2 startet viele Dienste (Apache, Samba, MySQL, PostgreSQL, distccd, SNMP …), bevor es bereit ist.

Betreten Sie den Angreifer-Container:

cd module-04-recon-active
docker compose exec attaquant bash

Erstellen Sie die Ausgabestruktur:

mkdir -p ~/labs/{scans,captures,rapport}
cd ~/labs

Definition — warum dieses Lab cap_add: NET_ADMIN, NET_RAW benötigt

Ein klassischer Docker-Container läuft mit einem eingeschränkten Satz an Linux-Capabilities. Er kann seine Netzwerkschnittstellen nicht ändern, keine Rohpakete fälschen (z. B. ein SYN ohne ACK), und tcpdump nicht ausführen. Das ist gut für einen Webserver, aber tödlich für ein offensives Lab.

Zwei Capabilities sind hier unerlässlich. NET_RAW erlaubt das Öffnen von Raw-Sockets, jene, die Nmap für -sS (SYN-Scan) nutzt, jene, die Scapy zum Zusammenbauen eines Pakets von Hand nutzt, jene, die arp-scan und tcpdump nutzen, um Ethernet-Frames direkt zu lesen. NET_ADMIN erlaubt die Manipulation von Routen und die Änderung von Schnittstellen — nützlich für bestimmte NSE-Skripte und für arp-scan auf manchen Kerneln.

Das Compose-Setup von Modul 04 fügt sie nur dem Angreifer-Container hinzu:

cap_add:
  - NET_ADMIN
  - NET_RAW

Die Ziele haben dieses Recht nicht — sie haben keinen Grund, irgendetwas zu scannen. Das ist das Prinzip der geringsten Rechte, angewandt auf Container-Ebene.

---

Schritt 2 — Discovery auf Schicht 2 (5 Min)

Der Ausgangspunkt jeder internen Reconnaissance: Wer spricht auf diesem Segment?

sudo arp-scan --interface=eth0 --localnet | tee scans/decouverte.txt

Sie sehen drei Zeilen (oder vier, mit dem Gateway 10.20.30.1 des Docker-Netzwerks). Notieren Sie die beiden Ziel-IPs:

export CIBLE_LINUX=10.20.30.20
export CIBLE_WEB=10.20.30.12

Eine alternative Discovery, ohne ARP:

sudo nmap -sn 10.20.30.0/24 -oN scans/decouverte-nmap.txt

Beide Methoden müssen dieselbe Anzahl an Hosts liefern. Eine Abweichung würde auf ein Problem in Ihrem Lab hinweisen.

Definition — warum ARP die zuverlässigste Discovery-Methode intern ist

In einem lokalen Netzsegment muss jeder Host die MAC-Adresse seiner Nachbarn kennen, um ihnen ein Paket zu senden. Dieser Mechanismus, ARP, kann nicht gefiltert werden: Selbst eine Maschine mit blockiertem ICMP, gefiltertem TCP und allen geschlossenen Ports muss auf eine ARP-Anfrage antworten, um von ihrem Gateway erreichbar zu bleiben. Es ist ein Protokoll der Schicht 2, unterhalb von allem, was eine Anwendungs-Firewall sehen kann.

Deshalb beginnt ein ernsthafter Angreifer immer mit ARP, wenn er sich im Segment befindet. Ein ping sweep (nmap -sn) genügt bei vielen Netzwerken, aber in einem LAN, wo die Stationen gehärtet sind und ICMP verweigern, bleibt ARP das einzig zuverlässige Mittel, um die aktiven Hosts zu zählen. Wenn Sie sich das ab Woche 1 angewöhnen, verpassen Sie bei einem echten Auftrag nicht die Hälfte eines Netzwerks.

Achtung: ARP funktioniert nur im gleichen Segment wie Sie. Wenn Ihr Angreifer in ein anderes VLAN geroutet wird, liefert ARP nichts mehr. In diesem Fall müssen Sie entweder pivotieren oder auf Netzwerk-Discovery (ICMP, TCP-SYN auf wahrscheinlichen Ports) zurückgreifen.

---

Schritt 3 — TCP-Ports (10 Min)

Scannen Sie alle TCP-Ports auf jedem Ziel. In Docker ist die Verbindung perfekt, man kann das Tempo erhöhen:

sudo nmap -sS -Pn -p- --min-rate 4000 $CIBLE_LINUX -oN scans/20-ports.nmap
sudo nmap -sS -Pn -p- --min-rate 4000 $CIBLE_WEB   -oN scans/12-ports.nmap

Zu prüfen:

• 10.20.30.20 öffnet etwa zwanzig Ports (21, 22, 23, 25, 53, 80, 111, 139, 445, 512-514, 1099, 1524, 2049, 2121, 3306, 3632, 5432, 5900, 6000, 6667, 8009, 8180 …). Das Profil eines historisch schlecht gewarteten Servers.
• 10.20.30.12 öffnet nur Port 80. Ein aktueller, gut gepflegter Server mit einer einzigen Rolle. Das Profil der Hälfte der modernen Websites.

Notieren Sie in rapport/ die genaue Anzahl offener Ports pro Ziel. Ein Ziel mit mehr als zwanzig offenen Ports ist fast immer ein absichtliches Lab oder ein in der Produktion vergessener Server. Das ist bereits beim Lesen des Executive-Reports ein starkes Signal.

---

Schritt 4 — Versionen (10 Min)

Nehmen Sie die Listen der offenen Ports und starten Sie -sV nur auf diesen Ports erneut:

sudo nmap -sV -p 80 $CIBLE_WEB -oN scans/12-versions.nmap

sudo nmap -sV -p 21,22,23,25,53,80,111,139,445,512-514,1099,1524,2049,3306,3632,5432,5900,6000,6667,8009,8180 \
                 $CIBLE_LINUX -oN scans/20-versions.nmap

Schauen Sie, was Nmap enthüllt:

grep -E "vsftpd|OpenSSH|Samba|MySQL|Apache|Postgres|distcc" scans/20-versions.nmap
grep -E "nginx|X-Powered" scans/12-versions.nmap

Sie sollten lesen:

• vsftpd 2.3.4 (der alte Bekannte aus Modul 01)
• Samba smbd 3.X - 4.X
• MySQL 5.0.51a
• Apache/2.2.8
• distccd v1
• nginx 1.27.x (Server-Header nicht versteckt)

Ergebnis: Notieren Sie in rapport/ für jedes Ziel die 5 interessantesten Dienste mit ihrer exakten Version. Das ist Ihr Material für den Abschnitt „Ergebnisse" des Berichts.

---

Schritt 5 — Gezielte NSE-Skripte (10 Min)

Die NSE-Skripte (Nmap Scripting Engine) verwandeln Nmap von einem Portscanner in ein Werkzeug zur Bestätigung von Schwachstellen. Wir starten nur Skripte, die für das Gefundene relevant sind — niemals blind --script vuln, was Dienste zum Absturz bringen kann.

Auf dem Linux-Ziel:

sudo nmap --script "ftp-vsftpd-backdoor,smb-vuln-cve2009-3103,smb-enum-shares,smb-os-discovery,http-vuln-*" \
  -p 21,80,139,445 $CIBLE_LINUX -oN scans/20-nse.nmap

Auf dem Web-Ziel:

sudo nmap --script "http-headers,http-title,http-methods,http-robots.txt,http-enum" \
  -p 80 $CIBLE_WEB -oN scans/12-nse.nmap

Ergebnis: Notieren Sie in rapport/ die durch NSE bestätigten CVEs mit der betroffenen IP und der CVE-Referenz. Für das Linux-Ziel sollten Sie die vsftpd-2.3.4-Hintertür (CVE-2011-2523) und wahrscheinlich Samba usermap (CVE-2007-2447) finden.

Definition — warum niemals nmap --script vuln als breiten Scan

--script vuln bündelt etwa 150 NSE-Skripte, von denen manche destruktiv sind. Manche testen eine Schwachstelle, indem sie absichtlich das gefährliche Verhalten auslösen — ein Buffer-Overflow, der den Dienst zum Absturz bringt, eine SQL-Abfrage, die eine Tabelle sperrt, eine fehlgeformte Anfrage, die einen Router in eine Schleife versetzt.

Im Labor kein Problem. In der Produktion bei einem Kunden kann ein gut platziertes --script vuln eine Datenbank für drei Stunden offline nehmen. Sie haben den Vertrag, der Sie zum Testen berechtigt, nicht den Vertrag, der Sie zum Zerstören berechtigt.

Die Regel: NSE wird kategoriegenau gestartet, abhängig davon, was der Versionsscan gezeigt hat. Sie sehen SMB? Gezieltes smb-vuln-*. Sie sehen HTTP? http-headers, http-methods. Sie sehen FTP? ftp-anon, ftp-vsftpd-backdoor. Jedes Skript wird explizit in Ihrem Befehl genannt, mit der Begründung im Bericht. Das erlaubt es dem Kunden auch, Ihre Scans erneut auszuführen, um seine Korrekturen zu überprüfen.

---

Schritt 6 — UDP und SNMP (10 Min)

UDP ist langsamer und wird oft vergessen. Genau deshalb muss man dort hingehen.

sudo nmap -sU --top-ports 25 $CIBLE_LINUX -oN scans/20-udp.nmap

Falls SNMP (161/udp) offen ist:

snmpwalk -v 2c -c public $CIBLE_LINUX sysDescr
snmpwalk -v 2c -c public $CIBLE_LINUX hrSWRunName > scans/20-snmp.txt
snmpwalk -v 2c -c public $CIBLE_LINUX iso.3.6.1.2.1.4.20 >> scans/20-snmp.txt

Testen Sie weitere gängige Communities:

onesixtyone -c /usr/share/wordlists/onesixtyone/dict.txt $CIBLE_LINUX -o scans/20-community-strings.txt

Ergebnis: Die Anzahl der gefundenen SNMP-Communities und eine Zusammenfassung des Inventars (OS, Prozesse, Schnittstellen) in rapport/.

Definition — SNMP, der vergessene Schatz der Unternehmensnetzwerke

SNMP (Simple Network Management Protocol) stammt aus dem Jahr 1988. Es dient dazu, Switches, Router, Drucker, Server — alles, was einen Agenten betreibt — remote zu überwachen und zu verwalten. Version 1 verwendet eine Community-String, ein im Klartext geteiltes Passwort, das fast immer auf seinem Standardwert belassen wird: public für Lesezugriff, private für Schreibzugriff.

Was SNMP für einen Angreifer so fantastisch macht: im Klartext gelesen, liefert es das gesamte Software- und Hardware-Inventar der Maschine. Systemversion, Prozessliste, Netzwerkadressen, ARP-Tabellen, Routing-Tabellen, angemeldete Benutzer, gemountete Freigaben. In einem echten Netzwerk ist ein snmpwalk auf einem gut konfigurierten Server besser als ein kombiniertes whoami; ip addr; ps aux; ss -tunap.

Version 3 behebt alles — Authentifizierung, Verschlüsselung, Zugriffskontrolle. Aber 2026 laufen die meisten Switches und Drucker immer noch mit SNMPv1/v2c und unverändertem public. Das ist ein fast perfekter Indikator für die Reife eines Netzwerks: eine Umgebung, in der SNMP niemals mit public erreichbar ist, wurde auditiert. Andernorts ist es Ihr ergiebigster Einstiegspunkt.

---

Schritt 7 — Tiefe SMB-Enumeration (15 Min)

Port 445 ist intern Ihr bester Freund. Auf Metasploitable 2 ist er offen und leckt so ziemlich alles, was eine Domäne leaken kann.

# Banner + Signing
nxc smb $CIBLE_LINUX

# Freigaben per Null-Session (ohne Zugangsdaten)
nxc smb $CIBLE_LINUX -u '' -p '' --shares > scans/20-shares.txt

# Benutzer per RID-Cycling
enum4linux-ng -R $CIBLE_LINUX -oJ scans/20-rid.json

# Passwortrichtlinie
enum4linux-ng -P $CIBLE_LINUX > scans/20-policy.txt

# Alles in einer lesbaren Datei
enum4linux $CIBLE_LINUX > scans/20-smb.txt 2>&1

Ergebnis: Notieren Sie in rapport/:

• ob signing: False ist (erlaubt NTLM-Relay)
• die Liste der per Null-Session zugänglichen Freigaben (typischerweise tmp beschreibbar auf Metasploitable 2)
• die Anzahl der enumerierten Benutzer
• die Passwortrichtlinie (Mindestlänge, Sperrung)

---

Schritt 8 — Web-Reconnaissance (15 Min)

Das Web-Ziel weist keine exploitierbare Schwachstelle auf. Aber es leckt enorm, sobald man kratzt. Das ist bei der Hälfte der internen Websites der Fall, die Sie im Auftrag scannen werden.

# Applikations-Fingerprint
whatweb -a 3 http://$CIBLE_WEB > scans/12-web.txt
echo "---" >> scans/12-web.txt

# Header und Status
curl -s -I http://$CIBLE_WEB/ >> scans/12-web.txt
echo "---" >> scans/12-web.txt

# robots.txt und sitemap
curl -s http://$CIBLE_WEB/robots.txt >> scans/12-web.txt
echo "---" >> scans/12-web.txt
curl -s http://$CIBLE_WEB/sitemap.xml >> scans/12-web.txt
echo "---" >> scans/12-web.txt

# Brute-Force der Pfade (kleine, gezielte Liste)
gobuster dir -u http://$CIBLE_WEB \
  -w /usr/share/seclists/Discovery/Web-Content/common.txt \
  -q -o scans/12-gobuster.txt

# Interessante gefundene Pfade prüfen
for p in "/admin/" "/api/v1/" "/backup/" "/.env.example" "/package.json"; do
  echo "=== $p ==="
  curl -s -o /dev/null -w "HTTP %{http_code}\n" http://$CIBLE_WEB$p
done > scans/12-paths.txt

# .env.example und package.json abrufen
curl -s http://$CIBLE_WEB/.env.example  > scans/12-env-example.txt
curl -s http://$CIBLE_WEB/package.json  > scans/12-package.txt

Schauen Sie, was .env.example leckt:

cat scans/12-env-example.txt

Sie finden dort: den Namen des SMB-Servers (dev-server), den MySQL-Port, einen Nur-Lese-Benutzer (intranet_ro). Das ist genau die Art von Artefakt, das aus Unachtsamkeit in öffentlichen Repositories zurückgelassen wird und einem Angreifer seine allererste Liste zu testender Konten liefert.

Und die package.json:

cat scans/12-package.txt

Sie enthüllt eine genaue Applikationsversion und alle Abhängigkeiten mit ihren Versionen. Damit können Sie bekannte CVEs jeder Abhängigkeit auf nvd.nist.gov suchen — ohne das Ziel überhaupt anzufassen.

Definition — die stillen „Information Disclosures", diese Lecks, die nichts kaputt machen

OWASP stuft Informationslecks nicht als kritisch in den Top 10 ein — weil sie für sich allein nichts kompromittieren. Keine erlangte Shell, kein exfiltriertes Passwort, keine offengelegten Kundendaten. Ein .env.example auf einem Server ist kein Einbruch, sondern eine legitime Datei.

Aber im echten Leben eines Angreifers sind diese Lecks der Treibstoff für alles Weitere. Der Name eines internen Servers, der in einem Konfigurationsbeispiel genannt wird, wird zu einer anzugreifenden IP. Eine Liste von Abhängigkeiten mit Versionen wird zu einer Liste von CVE-Kandidaten. Eine in einem HTML-Kommentar hinterlassene Admin-E-Mail-Adresse wird zu einem Phishing-Ziel. Ein Nginx-Banner mit 1.14.0 wird zu einem Ansatzpunkt, um die CVEs dieses Zweigs zu versuchen.

Deshalb widmet ein ernsthafter Audit diesen Funden Zeit, selbst wenn sie isoliert betrachtet nirgendwohin führen. Der Kundenbericht listet sie unter „Informationsoffenlegung" auf, mit der impliziten Empfehlung: Entfernen Sie diese Dateien oder verbergen Sie diese Header, nicht weil sie direkt exploitierbar sind, sondern weil sie dem Angreifer die zwanzig Stunden ersparen, die er sonst mit Raten verbracht hätte.

---

Schritt 9 — tcpdump-Mitschnitt (10 Min)

Kein Wireshark in Docker (keine grafische Oberfläche). Wir zeichnen mit tcpdump auf und öffnen die PCAP-Datei auf unserem Host mit Wireshark.

In einem ersten Terminal des Angreifer-Containers:

sudo tcpdump -i eth0 -w captures/scan-syn.pcap host $CIBLE_LINUX and tcp

In einem zweiten Terminal des Angreifer-Containers (docker compose exec attaquant bash von Ihrem Host aus):

sudo nmap -sS -p 22,80,445,3389 10.20.30.20

Zurück im ersten Terminal, Strg+C auf tcpdump.

Überprüfen Sie den Mitschnitt:

tcpdump -r captures/scan-syn.pcap -c 20
capinfos captures/scan-syn.pcap    # falls verfügbar

Auf Ihrem Host erscheint die Datei unter labs/docker/module-04-recon-active/attaquant-home/captures/scan-syn.pcap. Öffnen Sie sie mit dem lokalen Wireshark.

Wenden Sie den Filter an:

tcp.flags.syn == 1 and tcp.flags.ack == 0 and ip.dst == 10.20.30.20

Zählen Sie die gesendeten Pakete, prüfen Sie, dass die Quelle tatsächlich 10.20.30.5 (der Angreifer) ist.

Ergebnis: Die PCAP-Datei + ein Screenshot von Wireshark mit dem angezeigten Filter.

---

Schritt 10 — Scapy als Übung (5 Min)

Schreiben Sie scapy_check.py in ~/labs/:

#!/usr/bin/env python3
from scapy.all import IP, TCP, sr1

CIBLES = {
    "10.20.30.20": [21, 22, 23, 80, 139, 445, 3306],
    "10.20.30.12": [80, 443, 22],
}

for ip, ports in CIBLES.items():
    print(f"\n=== {ip} ===")
    for p in ports:
        r = sr1(IP(dst=ip) / TCP(dport=p, flags="S"), timeout=2, verbose=0)
        if r is None:
            print(f"  {p}/tcp  filtered")
        elif r.haslayer(TCP):
            flags = int(r[TCP].flags)
            if flags == 0x12:
                print(f"  {p}/tcp  open   (SYN/ACK)")
            elif flags & 0x04:
                print(f"  {p}/tcp  closed (RST)")
            else:
                print(f"  {p}/tcp  ?      (flags={hex(flags)})")

Ausführen:

sudo python3 scapy_check.py | tee scans/scapy-verification.txt

Ergebnis: Die Ausgabe muss dem entsprechen, was Nmap in Schritt 3 gesagt hat. Eine Abweichung = ein zu verstehendes Problem — falsche Schnittstelle, diskretes Filtern, fehlende Capability.

---

Schritt 11 — Den Bericht verfassen (25 Min)

Öffnen Sie rapport/reconnaissance.md. Zwei Seiten. Nicht mehr.

# Reconnaissance-Bericht — Lab Woche 4 (Datum)

## 1. Executive Summary (maximal 5 Zeilen)
Kartierung von zwei Hosts im Segment 10.20.30.0/24. Zwei gegensätzliche
Profile: ein sehr geschwätziger historischer Linux-Server und ein
korrekt konfiguriertes nginx-Intranet, das jedoch sein Software-
Inventar leckt. Prioritäten für die nächste Phase: 1) vsftpd 2.3.4,
2) Samba usermap, 3) Enumeration der passwortlosen MySQL-Konten.

## 2. Umfang und Methode
- Netzwerk: 10.20.30.0/24, isoliertes Docker-Bridge-Netzwerk.
- Angreifer: Kali 10.20.30.5 (Container inskillsec/kali-lab).
- Methode: ARP → Ping-Sweep → SYN-Scan aller Ports → gezieltes -sV →
  NSE nach Kategorie → UDP-Top-25 → SMB-Enumeration → Web-Recon →
  Scapy-Verifikation.

## 3. Ergebnisse — 10.20.30.20 (Linux-Ziel, "dev-server")
- OS: Ubuntu 8.04 (SNMP + Apache-Banner).
- Bemerkenswerte TCP-Ports: 21, 22, 80, 139, 445, 3306, 3632, 5432, 5900, 8180…
- Durch NSE bestätigte Schwachstellen:
  - CVE-2011-2523 (vsftpd-2.3.4-Hintertür)
  - CVE-2007-2447 (Samba-Usermap-Script)
- Per Null-Session enumerierte Konten: root, msfadmin, user, service…
- SNMP-Community "public": vollständiges Inventar lesbar.
- Freigabe /tmp per Null-Session beschreibbar.
- Priorität 1 für Exploitation: vsftpd-Hintertür (einfach, unauffällig).

## 4. Ergebnisse — 10.20.30.12 (Web-Ziel, "intranet")
- Server: nginx 1.27.x, geschwätziger Server-Header.
- Applikation: Intranet-App 2.3.1 (Node.js).
- Keine direkt bestätigte CVE.
- Informationsoffenlegungen:
  - /.env.example — liefert Namen des SMB-Servers und MySQL-Nur-Lese-Konto.
  - /package.json — legt 8 Abhängigkeiten mit Versionen offen.
  - /admin/ und /api/v1/ existieren, aber geschützt (401/403).
  - robots.txt listet 17 interne Pfade, die nicht alle zwingend
    existieren, aber die erwartete Architektur zeigen.
- Priorität für Exploitation: nach CVEs für die 8 in package.json
  gelisteten Abhängigkeiten suchen.

## 5. Plan für die Module 5 bis 8
1. vsftpd 2.3.4 exploitieren (bereits in Modul 01 erprobt).
2. Samba-Usermap-Script exploitieren (Metasploit).
3. Die Hashes aller lokalen Konten extrahieren.
4. Die extrahierten Zugangsdaten gegen das Intranet wiederverwenden.

## 6. Artefakte
- scans/12-ports.nmap, scans/20-ports.nmap: vollständige TCP-Scans.
- scans/12-versions.nmap, scans/20-versions.nmap: Versionsscans.
- scans/12-nse.nmap, scans/20-nse.nmap: gezieltes NSE.
- scans/20-udp.nmap, scans/20-snmp.txt: UDP-Recon.
- scans/20-smb.txt, scans/20-rid.json, scans/20-policy.txt: SMB.
- scans/12-web.txt, scans/12-gobuster.txt, scans/12-env-example.txt: Web.
- captures/scan-syn.pcap: tcpdump-Mitschnitt.
- scans/scapy-verification.txt: unabhängige Scapy-Verifikation.

---

Selbstbewertungsraster

• scans/decouverte.txt enthält zwei Ziel-IPs.
• Zwei *-ports.nmap-Dateien — alle TCP-Ports gescannt.
• Zwei *-versions.nmap-Dateien — Versionserkennung.
• Gezielter NSE-Scan pro Ziel (niemals blind --script vuln).
• UDP-Top-25-Scan auf dem Linux-Ziel.
• snmpwalk-Ausgabe gespeichert, falls SNMP offen.
• SMB-Enumeration: Banner + Freigaben + Benutzer + Richtlinie.
• Web-Reconnaissance: whatweb + gobuster + .env.example + package.json.
• tcpdump-Mitschnitt eines SYN-Scans, PCAP im Host-Wireshark öffnbar.
• Scapy-Skript ausgeführt, Ausgabe gespeichert, konsistent mit Nmap.
• Zweiseitiger Bericht, strukturiert nach dem obigen Modell.
• Kein Befehl wurde außerhalb des Subnetzes 10.20.30.0/24 ausgeführt.

---

Was in der Regel blockiert

Symptom	Wahrscheinliche Ursache	Korrektur
arp-scan: permission denied	Capabilities NET_RAW nicht hinzugefügt	cap_add: im Compose prüfen, docker compose down dann up -d.
nmap -sS verweigert	Dasselbe — kein Raw-Socket	Dasselbe.
tcpdump zeigt nichts	Falsche Schnittstelle	ip -brief address im Container, um die Docker-Schnittstelle zu finden.
-sV zeigt überall unknown	Ziel noch nicht bereit	30 s warten, docker compose ps muss healthy für das Ziel anzeigen.
SNMP antwortet nicht	Metasploitable 2 noch nicht hochgefahren	Weitere 30 s warten, oder docker compose restart cible-linux.
enum4linux-ng sehr langsam	Normal — viele RPC-Aufrufe	Geduld, das ist nie schnell.
gobuster: connection refused	cible-web startet gerade neu	docker compose logs cible-web, nginx-Syntax prüfen.
Wireshark öffnet die PCAP-Datei nicht	Pfad auf dem Host, nicht im Container	Die Datei aus labs/docker/module-04-recon-active/attaquant-home/captures/ nehmen.

---

Was Sie aus diesem Workshop mitnehmen

• Eine buchstäblich wiederholbare Scan-Methodik in 90 Minuten, gültig für jedes interne Segment.
• Einen Reconnaissance-Bericht, den Sie unverändert als Anhang eines Kunden-Pentests einreichen können.
• Das Verständnis der Rauschkosten jeder Nmap-Option.
• Die Gewohnheit, Ihren eigenen Traffic mitzuschneiden — der erste Schritt zur Umgehung im Red Team.
• Eine geordnete Liste von Schwachstellen, die in den Modulen 5, 7, 8, 9 exploitiert werden.
• Einen konkreten Beweis, dass eine Website ohne exploitierbare Schwachstelle eine schockierende Menge an Informationen leaken kann — eine Lektion, die Ihre Kunden sich merken sollten.

Nächster Schritt: das Quiz des Moduls. Danach geht es in das Herzstück des Pentests — die Suche nach und Exploitation von Schwachstellen.