Privilege Escalation (MITRE ATT&CK, Taktik TA0004) umfasst alle Techniken, mit denen ein Angreifer von eingeschränkten Rechten zu Administrator, SYSTEM oder root gelangt. Praktisch teilt sich die Taktik in zwei Familien: das Ausnutzen von Schwachstellen (Exploits) und das Ausnutzen von Fehlkonfigurationen. Dieser Hub konzentriert sich auf den zweiten, in echten Tests weitaus häufigeren Weg - und zwar über das bewährte Muster "erst aufklären, dann den gefundenen Fehler ausnutzen". Die Aufklärungs-Payloads sind kopierbar, die eigentliche Ausnutzung wird mit Verweis auf publizierte Quellen beschrieben. Zu jeder Technik steht die passende Erkennung dabei.
Was ist Privilege Escalation?
Nach der ersten Ausführung (Execution) läuft der Code eines Angreifers meist im Kontext eines normalen Benutzers. Viele Ziele - Zugangsdaten im Speicher, geschützte Dateien, die Kontrolle über das System - erfordern aber höhere Rechte. Privilege Escalation schließt diese Lücke.
In der Praxis sind Fehlkonfigurationen der häufigere Hebel, nicht Kernel-Exploits: zu weit gesetzte Dateirechte, schwach konfigurierte Dienste, großzügige sudo-Regeln oder gefährliche SUID-Binaries. Der typische Ablauf ist deshalb immer gleich: aufklären, welche Schwachstelle vorliegt, und dann gezielt den passenden, meist längst dokumentierten Hebel ansetzen. Genau an dieser Aufklärung setzt auch die Verteidigung an.
| Technik | ATT&CK | Plattform | Kurzbeschreibung |
|---|---|---|---|
| Token-Privilegien / SeImpersonate | T1134 | Windows | Missbrauch von Impersonation-Rechten von Dienstkonten |
| Dienst-Fehlkonfiguration | T1574 | Windows | Schwache Dienstrechte, unquoted Service Paths |
| SUID/SGID-Binaries | T1548.001 | Linux/macOS | Programme, die mit Besitzerrechten laufen |
| Sudo-Fehlkonfiguration | T1548.003 | Linux/macOS | Zu großzügige oder gefährliche sudo-Regeln |
| UAC Bypass | T1548.002 | Windows | Umgehung der Benutzerkontensteuerung (konzeptionell) |
Operatives Ziel, Voraussetzungen und Alternativen
Das operative Ziel ist, von Benutzer- zu Administrator-, SYSTEM- oder root-Rechten zu gelangen - meist, um an Zugangsdaten zu kommen oder Kontrollen zu beeinflussen. Ein Red Teamer bevorzugt den zuverlässigsten, leisesten Weg und greift selten zuerst zum Kernel-Exploit.
| Frage | Überlegung |
|---|---|
| Wann? | Wenn die aktuellen Rechte das nächste Ziel nicht hergeben - oft vor Credential Access oder Defense Impairment. |
| Voraussetzungen | Ein Fuß im System und die passende Fehlkonfiguration oder ein Privileg (z. B. SeImpersonate); reine Exploits brauchen eine verwundbare Version. |
| Alternativen | Fehlkonfiguration vor Exploit: schwache Dienstrechte, SUID, sudo-Regeln sind zuverlässiger und leiser als instabile Kernel-Exploits. |
| Tradeoff | Ein Exploit ist schnell, aber riskant (Absturz, Version). Der Weg über Fehlkonfiguration ist langsamer in der Aufklärung, dafür stabil und unauffälliger. |
Auf der Disponenten-Workstation von Nordlicht Logistik ist kein Kernel-Exploit nötig: Ein Dienst läuft als SYSTEM mit einer durch normale Nutzer beschreibbaren Binary. Das Team wählt diesen leisen, zuverlässigen Weg zu SYSTEM - und hält die Aufklärungs-Kommandos bewusst knapp, um nicht als Enumerationsmuster aufzufallen.
Token-Privilegien und SeImpersonate (T1134)
Dienstkonten unter Windows besitzen oft das Recht SeImpersonatePrivilege. Wer Code in einem solchen Kontext ausführt (etwa auf einem Webserver), kann unter bestimmten Bedingungen ein SYSTEM-Token übernehmen. Der erste Schritt ist immer die Prüfung der eigenen Privilegien:
Zeigt die Ausgabe SeImpersonatePrivilege oder SeAssignPrimaryTokenPrivilege als aktiviert, ist das Konto ein Kandidat für die bekannte "Potato"-Familie (JuicyPotato, PrintSpoofer, RoguePotato). Funktionierende Implementierungen sind publiziert und werden hier bewusst nur als Quelle genannt, nicht als fertiges Werkzeug.
Die reine Abfrage mit whoami ist unauffällig, die Ausnutzung dagegen nicht: Token-Impersonation über Named Pipes, ein Dienstkonto, das plötzlich cmd.exe oder powershell.exe als SYSTEM startet, und Sysmon Event ID 1 für bekannte Potato-Binaries sind starke Indikatoren. Entscheidend ist die Prozess-Eltern-Kind-Kette. Die Sigma-Regeln dazu stehen auf blue-team.net.
Dienst-Fehlkonfigurationen (T1574)
Windows-Dienste laufen häufig als SYSTEM. Lässt sich die zugehörige Binary oder die Dienstkonfiguration durch einen normalen Benutzer verändern, wird daraus ein direkter Weg nach oben. Die Aufklärung prüft Pfade, Startkonten und Schreibrechte:
Eine geänderte Dienstkonfiguration erzeugt Event ID 7045 beziehungsweise Modifikationseinträge, der Austausch einer Dienst-Binary fällt über File Integrity Monitoring auf. Der Einsatz von accesschk.exe oder vergleichbaren Enumerationstools durch einen Standardbenutzer ist selbst schon ein Signal. Verdächtig ist jeder Dienstneustart, nach dem ein ungewöhnlicher Kindprozess erscheint. Erkennungslogik auf blue-team.net.
SUID-Binaries unter Linux (T1548.001)
Unter Linux laufen SUID-Binaries mit den Rechten ihres Besitzers, oft root. Ist ein ungewöhnliches oder bekannt ausnutzbares Programm mit SUID-Bit gesetzt, lässt sich daraus eine Root-Shell gewinnen. Die Aufklärung listet alle SUID-Dateien:
Steht ein Treffer wie find, vim, nano oder weniger geläufige Programme in der Liste, liefert das Projekt GTFOBins die dokumentierte, publizierte Methode, daraus eine Shell mit erhöhten Rechten zu bauen. Diese konkrete Abfolge ist bewusst dort nachzulesen und wird hier nicht dupliziert.
Eine Baseline der gesetzten SUID-Bits ist das wirksamste Mittel: Jede neue oder unerwartete SUID-Datei ist verdächtig. auditd protokolliert die Ausführung von SUID-Binaries, und ein breiter find-Lauf über das gesamte Dateisystem ist selbst ein typisches Enumerationsmuster. Besonders auffällig: ein Interpreter oder Editor mit gesetztem SUID-Bit. Details auf blue-team.net.
Sudo-Fehlkonfigurationen (T1548.003)
Zu großzügige sudo-Regeln sind eine der häufigsten Ursachen für Rechteausweitung unter Linux. Darf ein Benutzer ein bestimmtes Programm per sudo ausführen, und lässt sich dieses Programm zum Starten einer Shell bewegen, ist root erreicht. Der erste Schritt ist die Abfrage der eigenen Rechte:
Erscheint ein Programm wie find, awk, vim, less oder ein Skript-Interpreter in der Liste - besonders mit NOPASSWD - verweist GTFOBins auf die publizierte Methode, daraus eine Root-Shell zu erhalten. Auch hier gilt: Quelle statt Copy-Paste-Exploit.
Jeder sudo-Aufruf landet in /var/log/auth.log beziehungsweise im journald. Verdächtig ist sudo, das einen Interpreter, Editor oder eine Shell startet, sowie die wiederholte Ausführung von sudo -l zur Aufklärung. Eine Auswertung der sudoers-Regeln gegen bekannte GTFOBins-Kandidaten deckt riskante Konfigurationen proaktiv auf. Mehr dazu auf blue-team.net.
Einordnung und Grenze
Dieser Hub zeigt bewusst die Aufklärung und das Prinzip, nicht fertige Exploits. Kernel-Exploits für konkrete CVEs, funktionsfähige UAC-Bypass-Bausteine und einsatzbereite Potato-Implementierungen werden nicht geliefert - sie sind in publizierten Quellen wie GTFOBins, LOLBAS, der Exploit-Datenbank und der MITRE-Dokumentation dokumentiert und dort im legitimen Kontext nachzulesen. Das Verständnis von "welche Fehlkonfiguration öffnet welchen Weg" ist für Angriff und Verteidigung gleichermaßen der entscheidende Teil.
Alle Commands gehören ausschließlich in autorisierte Tests mit wirksamer Erlaubnis des Berechtigten. Die Ausweitung von Rechten auf fremden Systemen ohne Berechtigung kann abhängig vom Einzelfall strafrechtlich relevant sein. Dieser Beitrag dient der Information und der Absicherung legitimer Sicherheitsarbeit und ist keine Rechtsberatung.
Einordnung in die Angriffskette
Privilege Escalation folgt meist auf Execution und ist Voraussetzung für Credential Access (etwa das Auslesen von LSASS) sowie für robuste Persistence und anschließendes Lateral Movement. Einen Überblick über alle Taktiken gibt die Payload-Sammlung.
Häufige Fragen
Sind Kernel-Exploits der Normalfall bei Privilege Escalation?
Nein. In echten Tests sind Fehlkonfigurationen - schwache Dienst- und Dateirechte, großzügige sudo-Regeln, gefährliche SUID-Binaries - weitaus häufiger und zuverlässiger als Kernel-Exploits, die oft instabil und versionsabhängig sind.
Warum nennt dieser Hub Tools wie GTFOBins nur als Quelle?
Weil die Aufklärung (welche Schwachstelle liegt vor) der lehrreiche und übertragbare Teil ist. Die konkrete Ausnutzung ist in diesen Projekten sauber dokumentiert und muss hier nicht dupliziert werden - das hält den Fokus auf Verständnis und Erkennung.