Zum Hauptinhalt springen

Aktive Reconnaissance — Geführte Demonstration

Ein Lab, drei Ziele. Wir durchlaufen alle Schichten des Scans, lesen jede Ausgabe und kommen am Ende auf einen klaren Angriffsplan. Nichts Destruktives — wir wollen die Karte, nicht die Asche.

Erinnerung an den Rahmen

Alles Folgende spielt sich im Host-only-Lab von Modul 1 ab, erweitert auf drei Maschinen. Kein Befehl ist außerhalb eines Labs, das Ihnen gehört, oder eines Ziels unter RoE legitim.

Was Sie nach dieser Lektion können​

  • Aktive Hosts entdecken, ohne vorher eine bekannte IP zu haben.
  • Dienste und Versionen in drei logischen Nmap-Durchgängen kartieren.
  • Eine SMB-Freigabe ohne Passwort enumerieren und eine Benutzerliste extrahieren.
  • Einen vergessenen UDP-Dienst (SNMP) mit der Standard-Community-String aufspüren.
  • Einen zweiseitigen Reconnaissance-Bericht konsolidieren.

Das erweiterte Szenario​

Greifen Sie das Lab aus Woche 1 wieder auf und fügen Sie eine dritte verwundbare Linux-VM hinzu.

MaschineRolleIP
KaliAngreifer10.10.10.5
Metasploitable 3 (Windows)Ziel 110.10.10.12
Metasploitable 2 (Linux)Ziel 210.10.10.20

Metasploitable 2 wird von SourceForge heruntergeladen. Importieren Sie sie, setzen Sie sie in dasselbe Host-only-Netzwerk, erzwingen Sie ihre IP auf 10.10.10.20.

Erstellen Sie den Missionsordner:

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

Schritt 1 — Discovery auf Schicht 2 (ARP)​

Eine Discovery, die im eigenen Rauschen passiv bleibt: ARP ist im LAN nativ, es lockt keine IDS an.

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

Ausgabe:

Interface: eth0, type: EN10MB, MAC: 08:00:27:aa:bb:cc, IPv4: 10.10.10.5
Starting arp-scan 1.9.7 with 256 hosts

10.10.10.1     0a:00:27:00:00:0a   VirtualBox
10.10.10.12    08:00:27:c3:5f:1e   PCS Systemtechnik GmbH (VirtualBox)
10.10.10.20    08:00:27:aa:12:34   PCS Systemtechnik GmbH (VirtualBox)

3 packets received by filter, 0 packets dropped by kernel

Drei Zeilen, zwei Ziele. 10.10.10.1 ist der VirtualBox-Host (zu ignorieren). Unser Testbestand: .12 und .20.

Schritt 2 — Discovery per Ping (ICMP + TCP)​

arp-scan funktioniert außerhalb des LAN nicht. Für einen breiteren Scan kombiniert nmap -sn ICMP-Echo, TCP-SYN auf 443 und 80 sowie ARP, wenn möglich.

sudo nmap -sn 10.10.10.0/24 -oA scans/hosts
cat scans/hosts.gnmap | grep Up

Ausgabe:

Host: 10.10.10.12 () Status: Up
Host: 10.10.10.20 () Status: Up

Bestätigt, was ARP gesagt hat. Gut.

Schritt 3 — Vollständiger TCP-Portscan​

Alle Ports auf einmal, aber eine Maschine nach der anderen. Wir speichern:

sudo nmap -sS -Pn -p- --min-rate 2000 10.10.10.12 -oA scans/12-ports
sudo nmap -sS -Pn -p- --min-rate 2000 10.10.10.20 -oA scans/20-ports

Auszug für .20 (Metasploitable 2):

PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
23/tcp   open  telnet
25/tcp   open  smtp
53/tcp   open  domain
80/tcp   open  http
111/tcp  open  rpcbind
139/tcp  open  netbios-ssn
445/tcp  open  microsoft-ds
512/tcp  open  exec
513/tcp  open  login
514/tcp  open  shell
1099/tcp open  rmiregistry
1524/tcp open  ingreslock
2049/tcp open  nfs
2121/tcp open  ccproxy-ftp
3306/tcp open  mysql
3632/tcp open  distccd
5432/tcp open  postgresql
5900/tcp open  vnc
6000/tcp open  X11
6667/tcp open  irc
8009/tcp open  ajp13
8180/tcp open  unknown

Schnelle Auswertung:

  • telnet (23), rsh/rexec/rlogin (512-514): Klartext-Protokolle — Minenfelder; sie würden jeden Audit aufschreien lassen.
  • distccd (3632): distributed compiler — historische RCE.
  • ingreslock (1524): eine bekannte Hintertür der VM (direkte Root-Shell).
  • X11 (6000): grafischer Server, der im Netzwerk exponiert ist.
  • MySQL und PostgreSQL exponiert, ohne über ein Frontend zu laufen.

Diese VM wurde zum Zerstören gemacht — sie hat alles offen. Bei einem echten Ziel wäre eine solche Liste ein Signal für eine vergessene Infrastruktur.

Schritt 4 — Versionserkennung​

Wir fragen die Versionen nur für die offenen Ports ab. Zurück zur Liste:

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 \
  10.10.10.20 -oA scans/20-versions

Auszug:

PORT     STATE SERVICE     VERSION
21/tcp   open  ftp         vsftpd 2.3.4
22/tcp   open  ssh         OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
23/tcp   open  telnet      Linux telnetd
80/tcp   open  http        Apache httpd 2.2.8 ((Ubuntu) DAV/2)
445/tcp  open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
3306/tcp open  mysql       MySQL 5.0.51a-3ubuntu5
8180/tcp open  http        Apache Tomcat/Coyote JSP engine 1.1

Das Zauberwort: vsftpd 2.3.4. Genau diese Version enthält eine öffentlich bekannte Hintertür (die berühmte vsftpd 2.3.4 Smiley-Face-Backdoor, CVE-2011-2523). Es genügt, einen Login zu senden, der :) enthält, damit auf Port 6200 eine Root-Shell aufgeht. Wir kommen in Modul 5 darauf zurück.

Ebenso bei Samba 3.x: eine Historie von Schwachstellen (Usermap-Script, EternalRed …). Ziel bestätigt.

Schritt 5 — Gezielter UDP-Scan​

nmap -sU -p- ist zu langwierig (10 h+). Wir zielen auf die UDP-Ports, die oft etwas verraten:

sudo nmap -sU --top-ports 20 10.10.10.20 -oA scans/20-udp

Ausgabe:

PORT     STATE         SERVICE
53/udp   open          domain
69/udp   open|filtered tftp
111/udp  open          rpcbind
137/udp  open          netbios-ns
161/udp  open          snmp
2049/udp open          nfs

SNMP (161) offen. SNMP über UDP mit der Standard-Community public bedeutet, dass der Agent das vollständige Inventar der Maschine preisgibt.

Überprüfung:

snmpwalk -v 2c -c public 10.10.10.20 sysDescr
snmpwalk -v 2c -c public 10.10.10.20 hrSWRunName | head

Ausgabe:

SNMPv2-MIB::sysDescr.0 = STRING: Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686
HOST-RESOURCES-MIB::hrSWRunName.1 = STRING: "init"
HOST-RESOURCES-MIB::hrSWRunName.2 = STRING: "sshd"
HOST-RESOURCES-MIB::hrSWRunName.3 = STRING: "mysqld"
HOST-RESOURCES-MIB::hrSWRunName.4 = STRING: "apache2"
...

Sie kennen jetzt den genauen Kernel, die Distributionsversion, die Liste der laufenden Prozesse. Ohne Authentifizierung. Ohne Exploit.

Schritt 6 — SMB-Enumeration mit nxc​

Auf 10.10.10.12 (Windows) und 10.10.10.20 (Linux mit Samba), dasselbe Werkzeug:

nxc smb 10.10.10.12 10.10.10.20

Ausgabe:

SMB  10.10.10.12  445  METASPLOITABLE3  [*] Windows Server 2008 R2 SP1  (name:METASPLOITABLE3) (domain:METASPLOITABLE3) (signing:False) (SMBv1:True)
SMB  10.10.10.20  445  METASPLOITABLE   [*] Unix (Samba 3.0.20-Debian)   (name:METASPLOITABLE)   (domain:WORKGROUP)   (signing:False) (SMBv1:True)

Signing:False überall: SMB-Relay-Angriffe werden möglich sein. Notieren Sie das für Modul 10.

Enumerieren wir die Freigaben ohne Authentifizierung:

nxc smb 10.10.10.12 -u '' -p '' --shares
nxc smb 10.10.10.20 -u '' -p '' --shares

Ausgabe für .20:

SMB  10.10.10.20  445  METASPLOITABLE   [+] METASPLOITABLE\: 
SMB  10.10.10.20  445  METASPLOITABLE   [*] Enumerated shares
SMB  10.10.10.20  445  METASPLOITABLE   Share           Permissions     Remark
SMB  10.10.10.20  445  METASPLOITABLE   -----           -----------     ------
SMB  10.10.10.20  445  METASPLOITABLE   print$          READ            Printer Drivers
SMB  10.10.10.20  445  METASPLOITABLE   tmp             READ,WRITE      oh noes!
SMB  10.10.10.20  445  METASPLOITABLE   opt             READ
SMB  10.10.10.20  445  METASPLOITABLE   IPC$            NO ACCESS       IPC Service

Freigabe tmp mit READ,WRITE per Null-Session. Ein Angreifer kann dort eine Payload ablegen und sie remote ausführen (siehe Modul 8).

Enumerierbare Benutzer?

enum4linux-ng -U 10.10.10.20

Auszug:

users:
  user: games
  user: msfadmin
  user: postgres
  user: user
  user: service

msfadmin — das Standard-Administratorkonto der VM. Bei einem echten Ziel wäre die per Null-Session gewonnene Benutzerliste ein schwerwiegendes Leck. Hier notieren wir sie und machen weiter.

Schritt 7 — Wireshark während des Scannens​

Öffnen Sie Wireshark auf Kali, zeichnen Sie auf eth0 auf und starten Sie einen leichten Scan:

sudo nmap -sS -p 22,80,445 10.10.10.20

In Wireshark, Filter:

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

Sie sehen:

  • Drei SYN von Ihrer IP zu .20:22, .20:80, .20:445.
  • Drei zurückkommende SYN/ACK (offene Ports) → jedes Mal sendet Ihr Kali ein RST zurück (typisch für den SYN-Scan).

Sie sehen jetzt, was das Ziel in seinen eigenen Logs gesehen hätte — dieselbe Quell-IP, dieselbe Sequenz, dasselbe TCP-Fenster. Das ist Ihr Fingerabdruck. Bei einem lauten Pentest nimmt man das in Kauf; im Red Team verschleiert man ihn (siehe Modul 8).

Schritt 8 — Scapy zur Demonstration​

Ein Xmas-Scan eines einzelnen Ports, von Hand:

from scapy.all import IP, TCP, sr1

for port in [22, 445, 3389, 8080]:
    reponse = sr1(
        IP(dst="10.10.10.12") / TCP(dport=port, flags="FPU"),
        timeout=2, verbose=0
    )
    if reponse is None:
        print(f"{port}/tcp  open|filtered  (keine Antwort)")
    elif reponse.haslayer(TCP):
        flags = reponse[TCP].flags
        if flags == 0x14:  # RST+ACK
            print(f"{port}/tcp  closed  (RST empfangen)")
        else:
            print(f"{port}/tcp  ?  (flags={hex(int(flags))})")

Ausgabe:

22/tcp  open|filtered  (keine Antwort)
445/tcp open|filtered  (keine Antwort)
3389/tcp open|filtered (keine Antwort)
8080/tcp closed  (RST empfangen)

Interpretation: Windows-Ports antworten mit RST auf gewöhnliche Pakete, aber Windows antwortet nicht bei einem Xmas-Scan — ein Verhalten, das nicht mit RFC 793 konform ist. Nützlich, um Windows von Linux auf einer sehr niedrigen Ebene zu unterscheiden. Das ist die Art von Trick, bei dem Scapy nmap übertrifft.

Schritt 9 — Konsolidieren​

Öffnen Sie ~/labs/semaine-04/rapport/reconnaissance.md und füllen Sie es aus:

# Reconnaissance-Bericht — Lab Woche 4  (2026-04-16)

## 1. Aktive Hosts
- 10.10.10.12  Windows Server 2008 R2 (Metasploitable 3)
- 10.10.10.20  Linux Ubuntu 8.04 (Metasploitable 2)

## 2. Ziel 10.10.10.12 — Windows
- Offene TCP-Ports: 22, 80, 135, 139, 445, 3306, 3389, 4848, 8080
- SMB: SMBv1, signing:False, verwundbar für MS17-010 (siehe Woche 1)
- Priorität 1: EternalBlue erneut ausnutzen, falls ungepatcht.

## 3. Ziel 10.10.10.20 — Linux
- Offene TCP-Ports: siehe scans/20-ports.gnmap (24 offene Ports)
- Bemerkenswerte UDP-Ports: 53, 161 (SNMP public), 2049 (NFS)
- Identifizierte verwundbare Dienste:
  - KRITISCH: vsftpd 2.3.4  → Hintertür CVE-2011-2523
  - KRITISCH: Samba 3.0.20  → Usermap-Script (CVE-2007-2447)
  - KRITISCH: distccd  → RCE (CVE-2004-2687)
  - KRITISCH: ingreslock 1524  → direkte Root-Shell-Hintertür
  - HOCH    : SNMP-Community "public"  → Inventar-Leck
- SMB-Null-Session: Benutzerliste erhalten (msfadmin, user, service …)
- Freigabe tmp per Null-Session beschreibbar.

## 4. Plan für Woche 5-8
1. Jede der 4 CVE der .20 über gezielte NSE-Skripte verifizieren.
2. MS17-010 auf .12 bestätigen.
3. Das vollständige SNMP-Inventar der .20 extrahieren.
4. Eine vsftpd-Exploitation vorbereiten (Woche 8, Metasploit).

## 5. Artefakte
- scans/*.gnmap, scans/*.xml, scans/*.nmap  (12 Dateien)
- captures/wireshark-syn-scan.pcapng
- rapport/reconnaissance.md (diese Datei)

Fazit​

In 45 Minuten gut geführtem Scan, ohne einen einzigen Dienst zu zerstören:

  • Sie haben zwei Maschinen tiefgehend kartiert.
  • Sie haben fünf kritische Schwachstellen bestätigt oder als sehr wahrscheinlich isoliert.
  • Sie haben einen Traffic-Fingerabdruck in Wireshark, den Sie dem Kunden zeigen können („so hätte Ihr IDS das sehen müssen").
  • Sie haben einen Plan für die Wochen 5 bis 8.

Das ist das Ende der Reconnaissance. Ab Modul 5 geht es in die Exploitation.