WS-017, eine in die Domäne eingebundene Workstation, löst einen Alarm aus, nachdem powershell.exe unter einem ungewöhnlichen Benutzerkonto gestartet wurde. Eine erste Analyse bestätigt zwar verdächtige Skriptaktivitäten, bleibt jedoch unvollständig und übersieht einen Persistenzmechanismus, der auch nach Beendigung des PowerShell-Prozesses bestehen bleibt. Der Angreifer benötigte keine neue Schwachstelle auf der Workstation; er brauchte lediglich ein nutzbares Domänenkonto und eine Möglichkeit, einen Host zur Ausführung seiner Aktion zu veranlassen.
Für die Verteidiger stellt sich die Frage, ob der PowerShell-Alarm ein isoliertes Ausführungsereignis oder Teil einer größeren Abfolge von Ereignissen war. In den folgenden sieben Lektionen werden wir die auf WS-017 hinterlassenen Datensätze in eine fundierte Zeitleiste überführen, Änderungen identifizieren und auf Basis der Beweislage über die geeignete Reaktion entscheiden. Eine fundierte Schlussfolgerung benennt Host, Konto, Aktion, Zeitpunkt und das jeweilige Artefakt, die die Erkenntnis stützen, anstatt sich lediglich auf die Bezeichnung des Alarms zu verlassen.
Der einfachste Fall ist ein Ausführungsereignis, bei dem ACME\svc_backup um 09:24 Uhr auf WS-017 die Datei powershell.exe startet. Dieser Datensatz belegt lediglich, dass ein Prozess unter diesem Benutzerkonto (Principal) gestartet wurde. Er gibt jedoch keinen Aufschluss darüber, wie das Konto auf den Host gelangte, welches Skript ausgeführt wurde, ob Persistenz etabliert wurde oder ob der Prozess erfolgreich war. Jedes weitere Artefakt liefert die Antwort auf eine dieser spezifischeren Fragen.
Regel für die Untersuchung
Betrachten Sie jeden Alarm als Ausgangspunkt. Untermauern Sie die Alarmmeldung mit hostspezifischen Beweisen, bevor Sie Aussagen zu Umfang, Ursache oder Auswirkungen treffen.
Um zu verhindern, dass nicht zusammenhängende Datensätze zu einer falschen Darstellung führen, gelten für jedes Lab feste Rahmenbedingungen. Der Host ist WS-017 und gehört zur Domäne ACME.LOCAL. Der reguläre interaktive Benutzer ist ACME\j.smith. Das verdächtige Konto ist ACME\svc_backup – ein Dienstkonto, dessen Verwendung auf einer Benutzer-Workstation erklärungsbedürftig ist. Der Untersuchungszeitraum erstreckt sich vom 14.09.2026, 09:10 Uhr, bis 10:05 Uhr (Ortszeit).
Diese Konstanten ermöglichen es uns, Beweise miteinander in Beziehung zu setzen, ohne pauschal von einer böswilligen Absicht bei jedem Ereignis auszugehen. Ein Eintrag im Sicherheitsprotokoll kann das Benutzerkonto (Principal) anhand von Feldern wie SubjectUserName identifizieren und die Art der Sitzung über LogonType bestimmen. Pfade zu Prozessabbildern (Image Path) oder Registry-Schlüsseln sowie Dienstkonfigurationen erhalten erst durch den Bezug zu WS-017 und dem definierten Zeitfenster ihre eigentliche Aussagekraft. Wenn ein Datensatz einen anderen Host nennt oder außerhalb des Zeitfensters liegt, behalten wir ihn nur dann bei, wenn Belege einen direkten Zusammenhang herstellen.
Die lokale Gruppe „Administratoren“ stellt in diesem Fall eine entscheidende Grenze dar. ACME\j.smith sollte als Standardbenutzer agieren, während Aktionen von ACME\svc_backup administrative Berechtigungen beinhalten können. Dieselbe ausführbare Datei hat eine unterschiedliche Bedeutung für die Untersuchung, wenn sie unter einem Konto ausgeführt wird, das Dienste installieren, systemweite Registrierungsschlüssel schreiben oder Sicherheitseinstellungen ändern kann.
Die Fallgrenze verknüpft die Domänenidentität, die lokale Berechtigungsgrenze und das Zeitfenster des Vorfalls in einer einzigen Ansicht:
Dieses Diagramm legt den Untersuchungsrahmen für alle nachfolgenden Fragestellungen fest. Wir untersuchen die Aktivitäten auf WS-017 im angegebenen Zeitraum von 55 Minuten und weiten die Untersuchung nur dann aus, wenn ein Artefakt über diese Grenzen hinausweist.
Sobald der Untersuchungsrahmen festgelegt ist, sollten die Beweisquellen anhand der Fragen ausgewählt werden, die sie beantworten können – und nicht, weil ein bestimmter Protokollkanal als maßgeblicher erscheint. Das Windows-Ereignisprotokoll (Event Log) erfasst Aktivitäten des Betriebssystems und sicherheitsrelevante Vorgänge, während Sysmon bei entsprechender Konfiguration detaillierte Endpunkt-Telemetriedaten liefert. Die Registry speichert Konfigurationsdaten, die über die Lebensdauer eines Prozesses hinaus bestehen bleiben können. Keine einzelne Quelle kann den gesamten Ablauf lückenlos belegen.
Für WS-017 werden in späteren Übungen vier Kategorien von Beweisquellen genutzt:
Microsoft-Windows-Sysmon/Operational zur Verknüpfung von Prozesserstellungen, Netzwerkaktivitäten, Dateierstellungen und Registry-Änderungen, sofern diese von Sysmon protokolliert wurden.Microsoft-Windows-PowerShell/Operational zur Analyse der PowerShell-Protokollierung von Skriptaktivitäten.HKLM und HKCU zur Überprüfung systemweiter und benutzerspezifischer Konfigurationsänderungen.Ein Systemereignis wie 7045 protokolliert die Installation eines Dienstes durch den Dienststeuerungs-Manager (Service Control Manager), einschließlich Dienstname, Pfad zur ausführbaren Datei (Image-Pfad), Starttyp und Dienstkonto. Für sich genommen belegt Ereignis 7045 lediglich die Erstellung eines Dienstes, nicht jedoch eine böswillige Absicht. Wir müssen Pfad und Konto mit den erwarteten administrativen Vorgängen abgleichen und anschließend zeitlich nahegelegene Anmeldevorgänge sowie Prozessdaten korrelieren. Wurde ein Dienst erstellt, ohne dass der Pfad zur ausführbaren Datei erfasst wurde oder die entsprechende Audit-Quelle fehlt, weist die Untersuchung eine Lücke auf, die explizit benannt werden muss.
Die Beweisquellen unterscheiden sich hinsichtlich Abdeckung, Datenfeldern und potenziellen Ausfall- oder Fehlerquellen: