Der Benutzer analyst verfügt bereits über eine Shell auf lab-linux, und CORP.LOCAL\svcuser meldet sich bereits an LAB-WIN01 an. Keiner dieser Einstiegspunkte (Footholds) stellt bereits Administratorrechte dar. Die zentrale Frage der Untersuchung ist, ob ein lokaler Konfigurationsfehler es einem der beiden Konten ermöglicht, die lokale Berechtigungsgrenze zu root oder SYSTEM zu überschreiten, und ob wir dieses Risiko nachweisen können, ohne einen Exploit auszuführen. Ein in der sudoers-Datei erlaubter Befehl, ein beschreibbarer Dienstpfad oder gespeicherte Anmeldeinformationen können als ausreichender Beleg dienen, sofern Konto, Konfiguration und Voraussetzungen entsprechend zusammenwirken.
Alle Arbeiten in diesem Kurs finden innerhalb der fest definierten Offline-Labore (Ubuntu 22.04 und Windows Server 2022) statt, die uns gehören oder für deren Untersuchung wir ausdrücklich autorisiert sind. Die Methodik liefert belastbare Ergebnisse, keine Payloads, Exploit-Ketten oder Schritte zur Umgehung von Sicherheitsmaßnahmen. Unter Ubuntu können eine sudo-Anfrage und deren Ergebnis Nachweise zur Autorisierung in /var/log/auth.log sowie im System-Journal hinterlassen, während Aktivitäten mit erhöhten Rechten unter Windows mit dem entsprechenden Sicherheitsprotokoll (Security Log) oder Dienst-Artefakten verknüpft sein müssen.
Das feste Laborszenario macht die Berechtigungsgrenze sowie die zugehörigen Nachweisquellen sichtbar:
Dieses Diagramm veranschaulicht, warum die Enumeration auf dem Host beginnt. Da die relevante Konfiguration und der Nachweis ihrer Nutzung meist auf entgegengesetzten Seiten derselben Berechtigungsgrenze liegen, erfordert ein Befund beide Elemente – eine isolierte, verdächtige Einstellung reicht nicht aus.
Da eine sichtbare Grenze noch keinen Pfad über diese hinweg begründet, liefert jeder Enumerationsdurchlauf vier miteinander verknüpfte Ergebnisse. Eine Hypothesenliste ist eine nach Priorität geordnete Zusammenstellung möglicher Angriffsvektoren, wie etwa delegierte Linux-Befehle, geplante Aufgaben (Scheduled Tasks), unsichere Windows-Dienstkonfigurationen oder für Nicht-Administratoren zugängliche Anmeldeinformationen. Eine Hypothese ist noch kein Befund; sie wird erst dann zu einem solchen, wenn die Host-Konfiguration die Voraussetzungen des jeweiligen Vektors erfüllt.
Wenn ein Analyst beispielsweise eine ausführbare Datei mit erweiterten Berechtigungen entdeckt, ist dies noch kein Beweis für eine tatsächlich stattfindende Rechteausweitung. Es muss geklärt werden, wer Eigentümer der Datei ist, ob der Analyst sie beeinflussen kann, welche privilegierte Komponente sie ausführt und ob der Ausführungskontext tatsächlich root-Rechte erreicht. Das Windows-Gegenstück hierzu ist nicht bloß das Erkennen eines Dienstes; erforderlich sind Informationen über das Dienstkonto, den Pfad zur Binärdatei, die Zugriffssteuerung sowie die Berechtigungen des Kontos CORP.LOCAL\svcuser.
Dieselben Beweise liefern Antworten auf Fragen der Verteidiger. Unter Ubuntu lassen sich anhand akzeptierter und abgelehnter sudo-Aktivitäten das aufrufende Konto, der Zielbenutzer, das Arbeitsverzeichnis und der Befehl identifizieren; Richtliniendateien wie /etc/sudoers und /etc/sudoers.d/ erläutern, warum die Aktion zulässig war. Verteidiger können diese Aufzeichnungen mit der beabsichtigten Delegationsregel abgleichen und bei ungewöhnlichen privilegierten Befehlen oder unerwarteten Änderungen an Richtliniendateien Alarm schlagen.
Die Analyseergebnisse unterscheiden zwischen einem plausiblen Pfad und einer melderelevanten Situation der Rechteausweitung: