Der Logeintrag als Standardartefakt

Bei der Incident Response gehören Logeinträge für Anmeldungen zu den Standardartefakten, die Hinweise darauf geben, wann sich ein Angreifer wo angemeldet hat.

In der Standardeinstellung werden auf Windows-Servern erfolgreiche und fehlgeschlagene Anmeldeversuche im Security Log protokolliert. Allerdings ist dieses Protokoll relativ aktiv und die Standardobergrenze von 20 MB wird auf Servern mit viel Betrieb innerhalb weniger Stunden erreicht. An dieser Stelle greift die nächste Standardeinstellung von Windows: Die ältesten Einträge werden überschrieben. Als Incident Responder, der zwei Tage nach einem Angriff die Logs durchforstet, eine sehr frustrierende Situation, zumal die meisten IT-Sicherheitsvorfälle erst Monate später erkannt werden (Quelle: https://www2.fireeye.com/rs/848-DID-242/images/Mtrends2016.pdf).

Alle diese Standardeinstellungen lassen sich ändern. Gerade auf Servern mit vielen Anmeldungen oder Domain Controllern sind 20 MB für die maximale Loggröße sehr knapp bemessen. Eine Null anzuhängen, schadet in der Regel nicht. Die Option "Volles Protokoll archivieren" ist für den Incident Responder äußerst angenehm, da unter Umständen auch sehr lange zurückliegende Ereignisse rekonstruiert werden können. Hier muss man allerdings den Festplattenspeicher im Auge behalten, denn der Speicherverbrauch für Logfiles kann durchaus relevant werden, gerade mit Blick auf den Trend zur Virtualisierung.

Die Ideallösung ist selbstverständlich, Logs auf einem zentralen Server zu speichern. Insbesondere eine laterale Rechteausweitung lässt sich mit solchen Systemen sehr effizient nachvollziehen.

Alle diese Maßnahmen können natürlich nur greifen, wenn sie vor dem Eintreten eines Vorfalls bereits ergriffen worden sind. Im eingangs beschriebenen Fall, in dem die interessanten Anmeldeereignisse bereits überschrieben sind, muss auf andere Wege zurückgegriffen werden.

Das Security Log ist der klassische Ort, an dem man bei der Incident Response nach Spuren von Anmeldungen sucht. Allerdings wurde Windows noch nie vorgeworfen, beim Logging übermäßig zurückhaltend zu sein. Entsprechend gibt es noch einige weniger bekannte Orte, an denen Anmeldungen protokolliert werden.

Speziell ist hier das Protokoll TerminalServices-LocalSessionManager zu nennen. Diese Logdatei enthält ausschließlich Informationen über interaktive Verbindungen – wann zum Beispiel RDP-Sitzungen eröffnet, geschlossen oder getrennt worden sind. Auch wenn das Protokoll TerminalServices im Namen trägt, ist es nicht nur auf Terminalservern aktiv. Auch auf Clientbetriebssystemen werden hier An- und Abmeldungen gespeichert.

Die interessantesten Event IDs sind: 

• 21: Session logon succeeded
• 22: Shell start notification received
• 23: Session logoff succeeded
• 24: Session has been disconnected
• 25: Session reconnection succeeded

Zum Teil sind diese Events bei Microsoft dokumentiert (siehe Event ID 21 — Remote Desktop Services Availability), für die konkrete Windows-Version ist es aber meist sinnvoll, die menschenlesbare Information aus dem Windows Event Log Viewer durchzusehen.

Dadurch, dass in diesem Protokoll nur interaktive Sitzungen protokolliert werden, gibt es hier deutlich weniger Einträge als im üblichen Security Log, sodass es nicht so schnell überläuft. Allerdings ist die Obergrenze für dieses Protokoll mit 1 MB auch deutlich kleiner. Dennoch können hier unter Umständen noch Informationen liegen, die über andere Logfiles nicht mehr rekonstruierbar sind.

Allgemein gilt: Was in den Standards nicht (mehr) zu finden ist, muss man woanders suchen. Auch deshalb ist und bleibt Computerforensik ein spannendes Betätigungsfeld, in dem es immer etwas Neues zu finden gibt.