Black-Box-Penetrationstest gegen HackSudo Thor: CVE-2014-6271 Shellshock RCE über Apache mod_cgi, verknüpft mit sudo-Fehlkonfiguration und Bash-Eval-Injection für vollständige Privilege-Escalation. Enthält benutzerdefinierte CSRF-bewusste Brute-Force-Tools und Metasploit-RPC-Automatisierung.
heventafese/penetration-testing-walkthrough-hacksudo-thor
Ziel: HackSudo Thor von VulnHub
Aufgabe: Root-Zugriff erlangen und/root/proof.txtlesen
Umgebung: Isolierte VirtualBox-Lab-Umgebung, segmentiert durch eine pfSense-Firewall
Dieses Repository dokumentiert einen partiellen Black-Box-Penetrationstest, der auf HackSudo Thor durchgeführt wurde – eine absichtlich verwundbare virtuelle Maschine, die von Vishal Waghmare auf VulnHub veröffentlicht wurde. Ziel war es, einen realitätsnahen Angriff zu simulieren, bei dem ein externer Angreifer versucht, ein isoliertes internes System zu kompromittieren. Das primäre Ziel bestand darin, Root-Zugriff zu erlangen und den Inhalt von /root/proof.txt auszulesen.
Die Bewertung folgt dem vollständigen Penetrationstest-Lebenszyklus: passive Aufklärung, Netzwerkermittlung, Enumeration, Schwachstellenbewertung, Exploitation, Privilegieneskalation, Post-Exploitation und Spurenverwischung.
Die primär verwendeten Werkzeuge waren Nmap für das Netzwerk-Scanning, Nessus für die Schwachstellenbewertung und das Metasploit-Framework als zentrale Plattform für Exploitation und Post-Exploitation. John the Ripper, Hashcat und Online-Rainbow-Tables kamen in der Phase des Passwortknackens zum Einsatz, obwohl alle Versuche aufgrund der Stärke des verwendeten Hash-Algorithmus letztlich erfolglos blieben.
Das virtuelle Labor wurde vollständig in VirtualBox aufgebaut und darauf ausgelegt, ein realistisches Unternehmensnetzwerk mit drei verschiedenen Sicherheitszonen abzubilden, die alle von einer pfSense 2.7.2-Firewall verwaltet werden. Die drei NAT-Netzwerke waren wie folgt konfiguriert: eine WAN-Zone, die das öffentliche Internet simuliert, in der sich die Kali-Angreifer-Maschine befindet; eine DMZ-Zone, die das Zielsystem hostet; und eine interne LAN-Zone mit außerhalb des Prüfumfangs liegenden Maschinen.``` Internet Zone — NatNetwork (10.0.2.0/24) │ │ Kali Linux 2025.4 [attacker] — 10.0.2.9 │ pfSense WAN interface — 10.0.2.8 │ ├── pfSense Firewall (boundary device) │ ├── DMZ Zone — DMZnat (10.0.4.0/24) │ ├── HackSudo Thor [TARGET] — 10.0.4.3 │ └── DVWA — 10.0.4.4 (out of scope) │ └── LAN Zone — LANnat (10.0.3.0/24) ├── Metasploitable 2 — 10.0.3.5 (out of scope) └── Windows XP Cyberlab — 10.0.3.4 (out of scope)
*Durch pfSense verwaltete logische Netzwerktopologie-Sicherheitszonen*
Die WAN-Schnittstelle erhielt per DHCP die Adresse `10.0.2.8/24`, die LAN-Schnittstelle wurde auf `10.0.3.1/24` und die OPT1 (DMZ)-Schnittstelle auf `10.0.4.1/24` gesetzt. Um eine bewusste Fehlkonfiguration in das Labor einzuführen, wurde Port 80 absichtlich auf der pfSense-WAN-Schnittstelle offen gelassen, wodurch eine typische reale Admin-Panel-Exposition simuliert wurde, die als primärer Einstiegspunkt in das interne Netzwerk diente.
---
## Zusammenfassung der Angriffskette```
[Kali Linux — 10.0.2.9]
│
│ CSRF-aware Python brute force → admin / pfsense
▼
[pfSense webConfigurator — 10.0.2.8:80]
│
│ Firewall rules disabled → DMZ and LAN now reachable
▼
[HackSudo Thor — 10.0.4.3]
│
│ Shellshock RCE (CVE-2014-6271)
│ Apache mod_cgi → /cgi-bin/shell.sh
▼
[Meterpreter shell — www-data]
│
│ sudo -u thor /home/thor/hammer.sh
│ Command injection via eval → bash -i payload
▼
[Interactive shell — thor]
│
│ GTFOBins: sudo service ../../bin/bash
▼
[Root shell]
│
├── /root/proof.txt captured ✅
├── /etc/shadow + /etc/passwd exfiltrated
└── SSH RSA backdoor planted
Bevor jeglicher Kontakt mit der Zielumgebung aufgenommen wurde, wurden Informationen ausschließlich aus öffentlichen Quellen gesammelt. Die beiden Hauptquellen waren die offizielle VulnHub-Eintragsseite für HackSudo Thor und das öffentliche GitHub-Profil des Autors.
Die VulnHub-Seite bestätigte, dass es sich bei dem Ziel um ein Linux-basiertes System handelte, bewertet als einfach bis mittelschwer, mit dem Ziel, die proof.txt-Flagge zu finden. Die Überprüfung des GitHub-Profils des Autors lieferte zusätzliche Einblicke. Vishal Waghmare entwirft durchgängig Linux-Boot-to-Root-Maschinen mit Privilegieneskalation als Kernherausforderung in der gesamten HackSudo-Reihe. Dies prägte das Bedrohungsmodell für die aktiven Phasen: HTTP- und SSH-Dienste waren die wahrscheinlichste Angriffsfläche, und es wurde vorhergesagt, dass der Eskalationspfad eine falsch konfigurierte sudo-Berechtigung, den Missbrauch von SUID-Binärdateien oder die Ausnutzung eines benutzerdefinierten Dienstes beinhalten würde.
Diese Art der Autorenmusteranalyse ist auch bei einem echten Engagement wichtig. Zu verstehen, wie ein System wahrscheinlich entwickelt wurde und welche Kategorien von Schwachstellen sein Administrator wahrscheinlich wiederholt, gibt eine Richtung vor, bevor auch nur ein einziges Paket gesendet wird.
| Feld | Detail |
|---|---|
| Ziel | HackSudo Thor |
| Autor | Vishal Waghmare (@hacksudo) |
| Veröffentlichung | 3. August 2021 |
| Schwierigkeit | Einfach bis Mittel |
| Betriebssystem | Linux (Debian) |
| Format | VirtualBox OVA |
| DHCP | Aktiviert |
| Vorhergesagte Angriffsfläche | HTTP, SSH, wahrscheinlich falsch konfigurierte sudo-Berechtigungen |
Diese Phase beinhaltete den direkten aktiven Kontakt mit der Umgebung. Ziel war es, alle aktiven Hosts zu identifizieren, die Netzwerkgrenze zu verstehen und ein Bild der gesamten Angriffsfläche zu erstellen, bevor der Fokus auf das primäre Ziel verengt wurde.
Zunächst wurde ein leichter Nmap-Ping-Sweep (-sn) gegen das WAN-Subnetz (10.0.2.0/24) durchgeführt, um aktive Hosts mit minimaler Geräuschkulisse zu entdecken. Drei Hosts wurden identifiziert: 10.0.2.1 und 10.0.2.2 waren Standard-Adressen der VirtualBox-Infrastruktur, sodass 10.0.2.8 der einzige Nicht-Infrastruktur-Host blieb. Diese Maschine wurde zum unmittelbaren Fokus.
Ein vollständiger SYN-Stealth-Scan gegen 10.0.2.8 lieferte überhaupt keine Ergebnisse. Dies war erwartetes Verhalten und kein Fehler. Unternehmensfirewalls sind darauf ausgelegt, auf Port-Scans nicht zu reagieren, indem sie Pakete stillschweigend verwerfen, anstatt zu antworten. Das Fehlen von Ergebnissen war selbst die Bestätigung, dass es sich um ein Netzwerkgrenzgerät handelte, das den Datenverkehr aktiv filterte.