Ich habe verschiedene Setups für CTFs und Pentesting-Labs ausprobiert. Mir war wichtig, die benötigten Tools griffbereit zu haben, ohne sämtliche Abhängigkeiten auf meinem Host zu installieren. Gleichzeitig wollte ich meinen gewohnten Browser, meine Notizen und meinen Clipboard-Manager weiterverwenden.

Mit Exegol lässt sich das gut verbinden. Früher habe ich es unter Windows über WSL genutzt, heute läuft es bei mir auf Arch Linux mit Hyprland. In diesem Beitrag zeige ich mein Setup und die Funktionen, die mir bei meiner CPTS-Vorbereitung am meisten helfen.

📦 Warum ich Exegol nutze#

Exegol ist eine Docker-basierte Umgebung für Offensive Security. Es bringt vorbereitete Images mit Tools und Ressourcen mit. Über den Exegol-Wrapper verwalte ich die Container. Das Image dient dabei als Vorlage für den Container, in dem ich arbeite.

Beim eJPT-Training konnte ich direkt im Browser mit einer vorbereiteten Pentesting-Umgebung arbeiten. Die benötigten Tools waren schon installiert. Nach der Zertifizierung habe ich den HTB Penetration Tester Job Role Path wieder aufgenommen und brauchte für längere Labs eine eigene Umgebung.

Besonders in den Active-Directory-Modulen brauche ich viele verschiedene Tools. In einem einzigen Lab nutze ich teilweise NetExec, Impacket, BloodHound, Certipy, BloodyAD und pyWhisker. Würde ich alles direkt auf dem Host installieren, müsste ich mich dort auch um die Updates und Abhängigkeiten kümmern.

Eine virtuelle Maschine wäre ebenfalls eine Möglichkeit. Für meine Labs lasse ich die Security-Tools aber lieber in einem Container laufen und nutze meine übrigen Anwendungen auf dem Host.

🖥️ Mein Host- und Desktop-Setup#

Meinen Browser, meine Notizen und Screenshots verwalte ich weiterhin auf dem Host. Dort nutze ich auch meinen Clipboard-Manager. Beim Lösen einer Box kopiere ich ständig Befehle, IP-Adressen, Benutzernamen und Pfade, auf die ich später wieder zugreifen möchte. Dabei können allerdings auch Passwörter im Zwischenablageverlauf landen. Das sollte man beim Kopieren sensibler Daten im Blick behalten.

Grafische Anwendungen in Exegol öffne ich über VNC. Dafür verbinde ich mich mit TigerVNC zum Desktop des Containers. Ein Desktop-Eintrag auf meinem Host macht das mit einem Klick möglich.

X11-Forwarding war in meinem alten Windows- und WSL-Setup etwas fummelig. Auf Arch Linux mit Hyprland funktionieren bei mir sowohl X11 als auch VNC problemlos. Ich bleibe trotzdem bei VNC, damit ich auf die grafischen Anwendungen in allen Containern auf dieselbe Weise zugreifen kann.

Für die beiden HTB-Umgebungen habe ich jeweils einen eigenen Container:

Container VPN-Verbindung
htba HTB Academy VPN
htbl HTB Labs VPN

Für Academy-Module nutze ich htba, für Maschinen in HTB Labs htbl. In beiden Containern ist die passende VPN-Konfiguration bereits hinterlegt. So muss ich beim Wechsel zwischen Academy und Labs nicht jedes Mal eine andere Konfigurationsdatei auswählen.

Dabei muss ich den Netzwerkmodus beachten: Bei Host-Networking teilen sich die Container den Netzwerkstack des Hosts. Zwei getrennte Container bedeuten also nicht automatisch, dass auch ihre VPN-Routen voneinander getrennt sind.

📁 Arbeiten mit gemeinsamen Dateien#

Exegol bindet einen Workspace unter /workspace in den Container ein. Die Dateien darin bleiben auch nach dem Verlassen des Containers erhalten. Auf dem Host liegen die zugehörigen Verzeichnisse standardmäßig unter ~/.exegol/workspaces/. Den Speicherort kann ich in der Wrapper-Konfiguration ändern.

Meine Tools speichern Scanergebnisse und gesammelte Dateien im Workspace. Auf dem Host kann ich diese Dateien direkt öffnen und für meine Notizen verwenden, ohne sie erst aus dem Container kopieren zu müssen.

Beim Erstellen eines Containers kann ich ein bestimmtes Host-Verzeichnis als Workspace verwenden:

exegol start <CONTAINER> <IMAGE> --workspace <WORKSPACE_PATH>

<CONTAINER> steht für den Containernamen, <IMAGE> für das gewünschte Image und <WORKSPACE_PATH> für das Host-Verzeichnis, das unter /workspace eingebunden wird.

Alternativ kann ich das aktuelle Verzeichnis einbinden:

exegol start <CONTAINER> <IMAGE> --cwd-mount

Diese Optionen legen den Workspace beim Erstellen des Containers fest. Die Mounts eines bestehenden Containers lassen sich damit nicht nachträglich ändern. Der gemeinsame Workspace ist praktisch, erlaubt dem Container aber auch den Zugriff auf die eingebundenen Host-Dateien. Der Container ist dadurch nicht vollständig vom Host abgeschottet.

🔐 Exegol-history und vorbereitete Befehle#

Anfangs habe ich vor allem Exegols Shell-History unterschätzt. Sie enthält bereits vorbereitete Befehle für viele der mitgelieferten Tools. Gerade bei Befehlen mit vielen Optionen muss ich die Syntax sonst regelmäßig nachschlagen. Mit den History-Einträgen habe ich eine Vorlage, die ich prüfen und anpassen kann.

Besonders praktisch ist das zusammen mit Exegol-history, kurz exh. Damit speichere ich Zugangsdaten und Hosts in einer Datenbank und wähle aus, mit welchen ich in der aktuellen Shell arbeiten möchte.

Zugangsdaten füge ich zum Beispiel so hinzu:

exh add creds -u '<USER>' -p '<PASSWORD>' -H '<NT_HASH>' -d '<DOMAIN>'

Die Optionen stehen für Benutzername, Passwort, NT-Hash und Domäne. Ich gebe nur die Werte an, die mir vorliegen. Für ein lokales Linux-Konto brauche ich beispielsweise nicht alle diese Angaben.

Um gespeicherte Zugangsdaten auszuwählen, führe ich folgenden Befehl aus:

exh set creds

Der Befehl öffnet eine interaktive Auswahl. Die gewählten Zugangsdaten stehen anschließend als Umgebungsvariablen wie USER, PASSWORD, NT_HASH und DOMAIN bereit. Mein Prompt zeigt außerdem an, welche Zugangsdaten gerade aktiv sind. So behalte ich beim Wechsel zwischen Konten den Überblick.

Hosts verwalte ich auf ähnliche Weise. Hier füge ich einen fiktiven Domain Controller hinzu und öffne anschließend die Host-Auswahl:

exh add hosts --ip '10.10.10.10' -n 'dc01.lab.local' -r 'DC'
exh set hosts

--ip gibt die IP-Adresse an, -n den Hostnamen und -r die Rolle. Bei der Auswahl eines Hosts werden die passenden Variablen geladen, etwa TARGET, IP, DC_IP und DC_HOST.

Die aktuell ausgewählten Werte kann ich mir so anzeigen lassen:

exh show

Normalerweise wähle ich zuerst die Zugangsdaten und den Host aus und suche anschließend den benötigten Befehl in der Shell-History. Exegols vorbereitete Befehle verwenden bereits die passenden Variablen. Zum Beispiel:

nxc smb "$TARGET" -u "$USER" -p "$PASSWORD"

Wenn ich andere Zugangsdaten oder einen anderen Host auswähle, verwendet derselbe Befehl die neuen Werte. Durch die doppelten Anführungszeichen wird der Inhalt jeder Variable als ein einzelnes Argument übergeben. Das ist zum Beispiel bei Passwörtern mit Leerzeichen wichtig.

Gerade in längeren AD-Labs mit mehreren Konten und Zielsystemen spart mir das einiges an Tipparbeit. Vor der Ausführung prüfe ich mit exh show, welche Zugangsdaten und welcher Host ausgewählt sind, und sehe mir den Befehl noch einmal an. Auch bei einer Vorlage muss ich verstehen, was sie ausführt und auf welchem System.

🎥 Shell-Logging mit Asciinema#

Mit Exegols Shell-Logging kann ich später nachvollziehen, welche Befehle ich ausgeführt habe und welche Ausgaben die Tools geliefert haben. Das ist hilfreich, wenn ich einen Versuch noch einmal durchgehen oder einen Walkthrough schreiben möchte. Meine Notizen bleiben wichtig, aber ich muss nicht jede Ausgabe von Hand festhalten.

Aktivieren lässt es sich beim Start eines Containers:

exegol start <CONTAINER> <IMAGE> --log

Exegol verwendet dafür standardmäßig Asciinema. Mit --log-method asciinema kann ich die Methode auch ausdrücklich angeben. Aktiviere ich das Logging beim Erstellen des Containers, werden auch spätere Shell-Sitzungen in diesem Container automatisch aufgezeichnet.

Die Aufzeichnungen liegen unter /workspace/logs/ und werden standardmäßig mit gzip komprimiert. Da der Workspace gemeinsam genutzt wird, kann ich vom Host darauf zugreifen.

Eine Aufzeichnung spiele ich so ab:

gunzip -c <SESSION>.asciinema.gz | asciinema play -

gunzip -c gibt den entpackten Inhalt auf der Standardausgabe aus. Über die Pipe liest asciinema play - diese Daten ein und spielt die Sitzung ab. Dabei bleibt der zeitliche Ablauf der Terminalausgabe erhalten, sodass sich auch die Bedienung interaktiver Tools wie exh nachvollziehen lässt.

Brauche ich nur den Text, nutze ich:

gunzip -c <SESSION>.asciinema.gz | asciinema cat -

Ich spiele die Aufzeichnungen auf dem Host ab. In einer Shell mit aktivem Logging würde sonst auch die Wiedergabe wieder aufgezeichnet.

In solchen Aufzeichnungen können Passwörter, Hashes, Tokens und andere sensible Daten stehen. Deshalb prüfe ich die gesamte Aufnahme, bevor ich sie teile. Für öffentliche Demonstrationen zeichne ich separate Sitzungen mit fiktiven Daten auf. Die Logs und die Exegol-history-Datenbank schütze ich genauso wie die anderen Dateien aus einem Pentest.

✅ Mein Fazit#

Für mein aktuelles Setup passt Exegol gut: Die Pentesting-Tools laufen im Container, meine gewohnten Anwendungen bleiben auf dem Host. Über den gemeinsamen Workspace und TigerVNC kann ich mit beiden arbeiten, ohne ständig Dateien hin und her zu kopieren.

Vor allem Exegol-history nutze ich während meiner CPTS-Vorbereitung inzwischen regelmäßig. Ich wähle Zugangsdaten und Hosts aus und kann sie dann in den vorbereiteten Befehlen verwenden, statt sie jedes Mal neu einzutippen. Mit den Shell-Logs kann ich meine Schritte später noch einmal durchgehen und für meine Writeups nutzen.

Auch mit Exegol muss ich meine Container aktuell halten und wissen, was die einzelnen Tools tun. Wenn ich die Arbeitsumgebung stärker vom Host trennen möchte, ist eine eigene VM sinnvoll. Für HTB-Maschinen und Academy-Labs arbeite ich aber lieber mit Exegol.

📚 Quellen#