Ereignisprotokolle: Anmeldungen, RDP, Dienste und PowerShell

Windows-Ereignisprotokolle zeichnen auf, wer sich von wo und auf welche Weise angemeldet hat, welche Dienste und Aufgaben installiert wurden, wann das System gestartet und heruntergefahren wurde und mitunter auch, welcher PowerShell-Code ausgeführt wurde – jeweils mit einer präzisen UTC-Zeit. Diese Lektion behandelt das EVTX-Format, die von Prüfern unter Windows 10 und 11 am häufigsten verwendeten Ereignisse und die Korrelation mehrerer Protokolle zu einer zusammenhängenden Darstellung einer Sitzung.

Speicherort der Protokolle und Aufbau von EVTX

Die Protokolle befinden sich in C:\Windows\System32\winevt\Logs, mit einer Datei pro Kanal. Die klassischen Protokolle sind Security.evtx, System.evtx und Application.evtx. Andere Kanäle verwenden den Kanalnamen, wobei der Schrägstrich als %4 geschrieben wird: Der Kanal Microsoft-Windows-TerminalServices-LocalSessionManager/Operational wird als Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx gespeichert. Bei einer Triage-Erfassung werden diese Dateien mit ihren ursprünglichen Pfaden kopiert; prüfen Sie, ob die benötigten Kanäle erfasst wurden, bevor Sie zu dem Schluss kommen, dass ein Ereignis nie stattgefunden hat.

Das EVTX-Format ist auf oberster Ebene einfach aufgebaut:

Datensätze werden als binäres XML gespeichert, eine kompakte Kodierung, die auf im Chunk gespeicherte Vorlagen verweist; Parser rekonstruieren daraus das XML, das Sie in der Ereignisanzeige sehen. Eigenständige Chunks lassen sich auch mittels Carving aus nicht zugeordnetem Speicherplatz wiederherstellen.

Datensatzfelder

Jeder Datensatz besitzt einen System-Abschnitt und einen Datenabschnitt:

• Provider (die Komponente, die ihn geschrieben hat, z. B. Microsoft-Windows-Security-Auditing) und EventID. Dieselbe Nummer kann bei unterschiedlichen Anbietern verschiedene Bedeutungen haben; lesen Sie beide daher immer zusammen.
• TimeCreated SystemTime, immer UTC, z. B. 2026-03-14T22:47:33.2014417Z.
• EventRecordID, eine fortlaufende Nummer pro Protokoll; Lücken oder ein Neustart bei 1 verdienen eine genauere Untersuchung.
• Channel und Computer (der Hostname zum Zeitpunkt, als das Ereignis geschrieben wurde).
• EventData (oder UserData): benannte Felder wie TargetUserName oder IpAddress.

Größe und Überschreiben

Jedes Protokoll hat eine maximale Größe und überschreibt standardmäßig seine ältesten Ereignisse, wenn es voll ist. Das Security-Protokoll ist standardmäßig häufig 20 MB groß und reicht daher auf einem stark ausgelasteten System möglicherweise nur wenige Tage zurück. Betriebskanäle haben eigene, oft kleinere Größenlimits, erhalten aber weniger Ereignisse und können deshalb weiter zurückreichen als Security. Bei klassischen Protokollen steht die konfigurierte Größe im Wert MaxSize unter ControlSet00x\Services\EventLog\<log> in der SYSTEM-Hive; vergleichen Sie den ältesten Datensatz mit dem Untersuchungszeitraum.

Anmeldungen im Security-Protokoll

Security-Ereignisse hängen von der Überwachungsrichtlinie ab. Windows 10 und 11 überwachen standardmäßig erfolgreiche und fehlgeschlagene Anmeldungen, aber viele Kategorien, darunter die Prozesserstellung, sind deaktiviert, sofern sie nicht ausdrücklich aktiviert werden. Das Fehlen eines Ereignisses beweist nicht, dass die Aktion nicht stattgefunden hat.

4624 (erfolgreiche Anmeldung) ist das zentrale Ereignis. Seine wichtigsten Felder sind TargetUserName, TargetUserSid, TargetLogonId, LogonType, IpAddress, WorkstationName (der Name des Clients), LogonProcessName (z. B. User32, NtLmSsp, Kerberos) und AuthenticationPackageName (z. B. Negotiate, NTLM, Kerberos).

4625 (fehlgeschlagene Anmeldung) hat denselben Aufbau, ergänzt um Status und SubStatus. SubStatus 0xC000006A bedeutet ein falsches Kennwort für ein vorhandenes Konto; 0xC0000064 bedeutet, dass der Benutzername nicht existiert. Viele Fehler mit 0xC0000064 von einer IP-Adresse deuten auf das Erraten von Benutzernamen hin; eine Häufung von 0xC000006A, gefolgt von einem Ereignis 4624 für dieses Konto, deutet auf ein erfolgreich erratenes Kennwort hin.

Weitere Ereignisse derselben Gruppe:

• 4634 Abmeldung (die Sitzung wurde beendet) und 4647 vom Benutzer initiierte Abmeldung (der Benutzer hat „Abmelden“ gewählt).
• 4648 Anmeldung mit expliziten Anmeldeinformationen, z. B. runas oder das Verbinden eines Laufwerks mit einem anderen Konto.
• 4672 einer neuen Anmeldung wurden besondere Berechtigungen zugewiesen: Das Konto besitzt sicherheitsrelevante Berechtigungen, üblicherweise als Administrator (oder SYSTEM).
• 4720 Benutzerkonto erstellt, 4722 aktiviert, 4724 Versuch einer Kennwortzurücksetzung, 4732 Mitglied zu einer sicherheitsaktivierten lokalen Gruppe hinzugefügt (z. B. Administratoren).
• 4688 Prozesserstellung, nur wenn „Prozesserstellung überwachen“ aktiviert ist; das Feld CommandLine wird nur ausgefüllt, wenn zusätzlich die Richtlinie „Befehlszeile in Prozesserstellungsereignisse einschließen“ festgelegt ist.

Die Anmelde-ID (TargetLogonId in 4624, ein als Hexadezimalzahl angezeigter 64-Bit-Wert) identifiziert eine Anmeldesitzung bis zu deren Ende. Spätere Ereignisse führen sie als SubjectLogonId (4672, 4688, 4648) oder TargetLogonId (4634, 4647), sodass sich durch Filtern nach dieser ID alle Aktivitäten dieser Sitzung zusammenführen lassen. Anmelde-IDs sind nur bis zum nächsten Neustart eindeutig; verknüpfen Sie die ID daher mit dem Zeitfenster.

Remotedesktop in drei Protokollen

Eine RDP-Sitzung hinterlässt auf dem Zielsystem Ereignisse in drei Kanälen:

• RemoteConnectionManager/Operational 1149, „Benutzerauthentifizierung erfolgreich“, mit Benutzer, Domäne und Quell-IP-Adresse. Es zeigt, dass eine RDP-Verbindung von dieser IP-Adresse für diesen Benutzernamen angenommen wurde; es zeigt nicht, dass eine Desktopsitzung gestartet wurde.
• Security 4624 Typ 10 mit derselben IP-Adresse in IpAddress. Bei der Authentifizierung auf Netzwerkebene (Network Level Authentication, NLA) erscheint häufig unmittelbar davor eine Anmeldung vom Typ 3 von derselben IP-Adresse. Bei einer Wiederverbindung oder Entsperrung kann stattdessen Typ 7 erscheinen.
• LocalSessionManager/Operational (LSM) 21 (Sitzungsanmeldung erfolgreich), 22 (Benachrichtigung über Shell-Start empfangen), 24 (Sitzung getrennt) und 25 (Sitzungswiederverbindung erfolgreich), jeweils mit Benutzer, Sitzungs-ID und Quelladresse. Konsolenanmeldungen zeigen LOCAL als Adresse.
• Security 4778 (Sitzung wiederverbunden) und 4779 (Sitzung getrennt), mit LogonID, ClientName und ClientAddress, sofern „Andere Anmelde-/Abmeldeereignisse“ überwacht wird.

Das Schließen des RDP-Fensters trennt die Sitzung ohne Abmeldung: 24 und 4779 erscheinen, 4634 jedoch erst, wenn sich der Benutzer abmeldet oder die Sitzung zurückgesetzt wird.

Dienste, Aufgaben, Systemstart und Herunterfahren

Im System-Protokoll zeichnet 7045 (Anbieter Service Control Manager) eine Dienstinstallation mit ServiceName, ImagePath, StartType und AccountName auf. Ein zufälliger Name mit einem ImagePath, der cmd.exe oder powershell.exe ausführt, ist typisch für Werkzeuge zur Remoteausführung. 7036 zeichnet auf, dass ein Dienst in den Status „Wird ausgeführt“ oder „Beendet“ wechselt. 6005 und 6006 (Ereignisprotokolldienst gestartet/beendet) markieren den Systemstart und das ordnungsgemäße Herunterfahren, 6008 zeichnet auf, dass das vorherige Herunterfahren unerwartet war, und 1074 (Anbieter User32) nennt den Prozess und den Benutzer, die das Herunterfahren oder einen Neustart initiiert haben.

In Microsoft-Windows-TaskScheduler/Operational zeichnet 106 die Registrierung einer Aufgabe mit ihrem Namen und dem registrierenden Benutzer auf; 200/201 zeichnen den Start und den Abschluss einer Aufgabenaktion auf. Dieser Kanal kann deaktiviert sein; prüfen Sie daher, ob er Ereignisse enthält. Lektion 2.6 behandelt Ereignisse zu USB-Geräten.

PowerShell

• Microsoft-Windows-PowerShell/Operational 4104 (Skriptblockprotokollierung) zeichnet den ausgeführten Code nach der Dekodierung mit einer ScriptBlockId auf; lange Skripte erstrecken sich über mehrere Datensätze („1 von 3“). Bei aktivierter Richtlinie werden alle Blöcke protokolliert. Ohne diese Richtlinie kann Windows PowerShell 5.x einige Skriptblöcke automatisch auf der Stufe „Warnung“ protokollieren, wenn deren Inhalt als verdächtig eingestuft wird.
• 4103 (Modulprotokollierung) zeichnet Details zur Pipelineausführung wie Befehle und Parameter auf, wenn die Modulprotokollierung aktiviert ist.
• Windows PowerShell.evtx 400 und 403 markieren den Start und das Beenden der Engine; ihr Feld HostApplication zeigt die Befehlszeile, mit der PowerShell gestartet wurde, einschließlich der Werte von -EncodedCommand. 600 zeichnet den Start von Anbietern auf.
• PowerShell 7 verwendet seinen eigenen Kanal PowerShellCore/Operational.

Außerhalb der Protokolle speichert PSReadLine für jeden Benutzer eingegebene Konsolenbefehle in %APPDATA%\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt und bewahrt standardmäßig die letzten 4.096 Zeilen auf. Die Datei enthält keine Zeitstempel; ordnen Sie ihre Einträge daher durch Korrelation zeitlich ein (4104, Dateisystemzeiten).

Gelöschte Protokolle

Security 1102 („Das Überwachungsprotokoll wurde gelöscht“) und System 104 (ein anderes Protokoll wurde gelöscht) zeichnen auf, wer ein Protokoll gelöscht hat. Modul 7 behandelt das Löschen von Protokollen als antiforensische Maßnahme.

Werkzeuge und Vorgehensweise

Die Ereignisanzeige kann eine kopierte .evtx für Stichproben öffnen, zeigt aber die lokale Zeit des Analysecomputers an. Parsen Sie zur Analyse alle Protokolle in eine gemeinsame Tabelle: EvtxECmd verwendet beispielsweise Zuordnungen, die Ereignisfelder in einheitliche Spalten (Benutzer, Remotehost, ausführbare Datei) normalisieren, und schreibt CSV-Dateien mit UTC-Zeiten. Suchwerkzeuge wie Hayabusa und Chainsaw wenden Erkennungsregeln auf viele Protokolle an; überprüfen Sie jeden Treffer im ursprünglichen Datensatz.

Durchgearbeitetes Beispiel: eine RDP-Sitzung

Eine Triage-Erfassung von der Arbeitsstation WS-FIN-07 zeigt diese Ereignisse (UTC):

Verknüpfung. Der Benutzer und die IP-Adresse verknüpfen 1149 mit 4624; die TargetLogonId aus 4624 verknüpft es mit 4672 und 4779; Benutzer, IP-Adresse und Sitzungs-ID verknüpfen die drei LocalSessionManager-Ereignisse. Einige Werkzeuge zeigen Anmelde-IDs als Dezimalzahlen an: 0x3E1A2B = 62 × 65.536 + 0x1A2B (6.699) = 4.069.931.

Interpretation. mreyes stellte eine Verbindung von 203.0.113.45 (Clientcomputer DESKTOP-K2M9QX) her, meldete sich um 22:47:33Z mit besonderen Berechtigungen (4672) an und trennte die Verbindung um 23:31:05Z. Dauer: 23:31:05.117 − 22:47:33.201 = 43 min 31,916 s. Es folgt kein Ereignis 4634 oder 4647; die Sitzung blieb daher angemeldet, war aber getrennt. Eine Filterung nach 0x3E1A2B in diesem Zeitfenster würde zeigen, was in der Sitzung ausgeführt wurde, sofern 4688 überwacht wurde.

Ereignis-ID-Referenz

Prüfungsschwerpunkt: Rechnen Sie damit, eine Anmeldezeit in UTC, eine Quell-IP-Adresse, eine Anmelde-ID, den Namen einer Clientarbeitsstation oder den ImagePath eines Dienstes aus geparsten Protokollen angeben und das richtige Ereignis für eine Frage auswählen zu müssen (1149 gegenüber 4624 Typ 10 gegenüber LSM 21). Kennen Sie die Anmeldetypen und die beiden häufigen SubStatus-Codes von 4625, und seien Sie darauf vorbereitet zu erklären, warum ein fehlendes Ereignis auf die Überwachungsrichtlinie oder das Überschreiben älterer Ereignisse statt auf Inaktivität zurückzuführen sein kann. Entnehmen Sie Zeiten aus SystemTime, nicht aus einer Anzeige, die sie in die lokale Zeit umrechnet.

Kernpunkte

• EVTX-Dateien befinden sich in C:\Windows\System32\winevt\Logs; auf einen 4 KB großen ElfFile-Header folgen 64 KB große ElfChnk-Chunks mit binären XML-Datensätzen, die UTC-Zeiten und eine EventRecordID enthalten.
• Protokolle überschreiben ältere Ereignisse: Das Security-Protokoll ist oft nur 20 MB groß; vergleichen Sie daher seinen ältesten Datensatz mit dem relevanten Zeitraum.
• 4624 liefert Benutzer, SID, LogonType, Anmelde-ID, IP-Adresse und Arbeitsstation; Status/SubStatus von 4625 erklären Fehler; 4672 kennzeichnet privilegierte Anmeldungen.
• RDP erscheint als 1149, 4624 Typ 10, LSM 21/22/24/25 und 4778/4779; verknüpfen Sie diese über Benutzer, IP-Adresse, Sitzungs-ID und Anmelde-ID.
• 7045 zeichnet neue Dienste auf, 106/200/201 geplante Aufgaben und 4104 PowerShell-Code; ConsoleHost_history.txt speichert eingegebene Befehle ohne Zeitangaben.
• Viele Ereignisse hängen von Überwachungs- oder Protokollierungsrichtlinien ab; ihr Fehlen beweist daher nicht, dass die betreffende Aktivität nicht stattgefunden hat.