17.8 Sicherheitsvorfall anhand von Logs analysieren: Fallbeispiel

Ein Sicherheitsvorfall anhand von Logs zu analysieren, gehört zu den wichtigsten praktischen Fähigkeiten in der IT-Sicherheit, weil Angriffe, Fehlkonfigurationen und Missbrauch selten direkt live beobachtet werden. In der Praxis werden Vorfälle oft erst Stunden oder Tage später bemerkt. Dann sind Logs die wichtigste Grundlage, um zu verstehen, was passiert ist, wann es begonnen hat, welche Systeme betroffen waren und wie weit sich ein Angreifer bewegt hat. Für CCNA, Netzwerkpraxis und Cybersecurity ist dieses Thema besonders relevant, weil es die Brücke zwischen Theorie und realer Incident-Analyse schlägt. Firewalls, VPN-Gateways, Switches, Server, Endgeräte, Identitätssysteme und SIEM-Plattformen liefern dabei jeweils nur einen Teil des Bildes. Erst die strukturierte Auswertung dieser Quellen macht aus isolierten Meldungen ein nachvollziehbares Vorfallsszenario. Wer ein Sicherheitsereignis anhand von Logs analysieren kann, versteht schnell, dass Security Monitoring nicht nur aus Alarmen besteht, sondern aus Methodik, Kontextbewertung und systematischer Rekonstruktion von Ereignissen.

Warum Logs bei Sicherheitsvorfällen so wichtig sind

Logs sind die technische Erinnerung eines Vorfalls

Ein Sicherheitsvorfall hinterlässt fast immer Spuren. Benutzer melden sich an, Systeme erzeugen Fehlermeldungen, Firewalls protokollieren Verbindungen, Endgeräte starten Prozesse und Server verzeichnen Datei- oder Dienstaktivität. Diese Spuren liegen in Logdaten vor. Genau deshalb sind Logs für die Analyse so wichtig: Sie dokumentieren, was ein Mensch im Nachhinein nicht mehr direkt beobachten kann.

• Sie zeigen den zeitlichen Ablauf.
• Sie machen beteiligte Systeme sichtbar.
• Sie verknüpfen Benutzer, Geräte und Aktionen.
• Sie helfen, Ursache und Folge zu unterscheiden.

Ohne Logs bleibt ein Vorfall oft spekulativ. Mit Logs wird er rekonstruierbar.

Einzelne Logeinträge genügen selten

Ein weiterer wichtiger Punkt ist, dass selten ein einzelner Logeintrag den gesamten Vorfall erklärt. Ein fehlgeschlagener Login, eine VPN-Verbindung oder eine Firewall-Meldung kann für sich harmlos wirken. Erst die Kombination mehrerer Quellen zeigt das eigentliche Muster. Genau deshalb ist Loganalyse immer auch Korrelationsarbeit.

Das Fallbeispiel: Ein verdächtiger Zugriff im Unternehmensnetz

Ausgangssituation des Unternehmens

In diesem Fallbeispiel betrachten wir ein mittelständisches Unternehmen mit zentralem Standort, Homeoffice-Zugängen per VPN, Windows-Servern, einem Active Directory, einer Firewall mit zentralem Logging, EDR auf Endgeräten und einem SIEM für Korrelation und Alarmierung. Die Benutzer greifen per VPN auf interne Systeme zu, darunter Dateiserver, Intranet und Fachanwendungen.

Die Sicherheitsinfrastruktur besteht vereinfacht aus:

• Firewall mit VPN-Gateway
• Windows-Domain mit zentralem Identitätssystem
• Dateiserver für gemeinsame Projektablagen
• EDR auf Arbeitsplatzrechnern
• SIEM zur Sammlung und Korrelation der Logs

Der erste Hinweis auf einen möglichen Vorfall

Am Montagmorgen erhält das Security-Team einen SIEM-Alarm. Die Regel lautet vereinfacht: „Ungewöhnlicher VPN-Login außerhalb üblicher Arbeitszeit mit anschließender auffälliger Dateiaktivität.“ Der Alarm betrifft das Benutzerkonto mmeyer, das am Sonntagabend aktiv war.

Der erste Alarmtext enthält folgende Hinweise:

• VPN-Login am Sonntag um 23:41 Uhr
• Herkunft der Verbindung aus einer Region, die für den Benutzer untypisch ist
• innerhalb von 20 Minuten Zugriff auf mehrere Projektverzeichnisse
• erhöhte ausgehende Datenmenge vom Dateiserver an eine externe IP

Dieses Muster reicht noch nicht für eine endgültige Bewertung, ist aber stark genug, um eine Untersuchung auszulösen.

Schritt eins: Den Alarm sauber einordnen

Ist der Alarm grundsätzlich plausibel?

Bevor Details untersucht werden, wird zuerst die Plausibilität des Alarms geprüft. Dabei geht es um eine erste Triage: Könnte es sich um reguläre Arbeit, einen Fehlalarm oder einen echten Sicherheitsvorfall handeln?

• Arbeitet der Benutzer normalerweise sonntags nachts?
• Ist der angezeigte Herkunftsort bekannt oder plausibel?
• Gab es geplante Wartung oder Sonderfreigaben?
• Ist das Konto privilegiert oder normal?

Die erste Rückfrage beim zuständigen Fachbereich ergibt: Der Benutzer mmeyer arbeitet regulär werktags im Vertrieb und hat keine bekannte Wochenendarbeit. Der Herkunftsort der VPN-Anmeldung ist für seine übliche Nutzung ungewöhnlich. Damit steigt die Relevanz des Alarms deutlich.

Welche Systeme und Daten sind betroffen?

Im nächsten Schritt wird bewertet, welche Tragweite der Vorfall haben könnte. Das Konto selbst ist kein Administrationskonto, hat aber Zugriff auf vertrauliche Projekt- und Angebotsdaten. Der betroffene Dateiserver gehört somit zu den geschäftlich relevanten Systemen.

Schritt zwei: VPN-Logs analysieren

Verbindungsaufbau und Login-Zeit prüfen

Die Untersuchung beginnt mit den VPN-Logs, weil der Alarm dort seinen Ursprung hat. Relevante Fragen sind:

• Wann genau wurde die Verbindung aufgebaut?
• Von welcher Quell-IP kam der Zugriff?
• War MFA erfolgreich oder gab es Auffälligkeiten?
• Gab es kurz davor weitere fehlgeschlagene Logins?

Die VPN-Logs zeigen folgendes Muster:

• 23:36 Uhr: drei fehlgeschlagene Login-Versuche für mmeyer
• 23:41 Uhr: erfolgreicher VPN-Login mit korrektem Passwort und bestätigter MFA
• 23:42 Uhr: Zuweisung einer internen VPN-IP
• 23:43 Uhr: erste Verbindung zum Dateiserver

Die fehlgeschlagenen Versuche kurz vor dem erfolgreichen Login sind bereits ein wichtiges Detail. Sie können auf Tippfehler hindeuten, aber auch auf eine fremde Person, die Zugangsdaten testet.

Warum die MFA hier besonders wichtig ist

Da MFA erfolgreich war, stellt sich die Frage, ob der Benutzer die Anmeldung selbst bestätigt hat oder ob eine Push-Anfrage unkritisch bestätigt wurde. Später in der Analyse wird dieser Punkt noch wichtig. Im Moment zeigt die Loglage nur: Es gab keinen reinen Passwortangriff ohne zweiten Faktor.

Schritt drei: IAM- und Authentifizierungslogs prüfen

Gab es weitere Login-Auffälligkeiten?

Nach den VPN-Logs werden die Identitäts- und MFA-Systeme untersucht. Ziel ist es zu prüfen, ob das Konto auch an anderer Stelle auffällig war.

Die IAM-Logs zeigen:

• 23:35 Uhr: MFA-Push an registriertes Smartphone gesendet
• 23:35 Uhr: Anfrage abgelehnt
• 23:41 Uhr: erneute MFA-Anfrage
• 23:41 Uhr: Anfrage bestätigt

Dieses Muster ist hochinteressant. Eine erste Push-Anfrage wurde abgelehnt, die zweite kurz danach bestätigt. Das kann bedeuten, dass der Benutzer die erste Anfrage nicht zuordnen konnte und die zweite später reflexhaft bestätigte. Genau solche Muster passen zu sogenannter MFA-Fatigue oder sozial erzeugtem Bestätigungsdruck.

Gab es Änderungen am Konto?

Wichtig ist auch zu prüfen, ob das Konto selbst verändert wurde:

• keine Passwortänderung
• keine Gruppen- oder Rollenänderung
• kein MFA-Reset

Damit deutet bisher wenig auf eine tiefe Kontomanipulation hin. Es spricht eher für missbrauchte legitime Anmeldung als für eine direkte Änderung des IAM-Status.

Schritt vier: Dateiserver-Logs auswerten

Welche Dateien und Verzeichnisse wurden geöffnet?

Nun wird untersucht, was der Benutzer nach dem VPN-Zugang tatsächlich gemacht hat. Die Dateiserver-Logs zeigen zwischen 23:43 Uhr und 00:02 Uhr mehrere Lesezugriffe auf Verzeichnisse, die für Angebots- und Projektunterlagen genutzt werden.

• Zugriff auf mehrere Kundendossiers
• Lesen von Angebots-PDFs und Excel-Dateien
• keine Änderungen oder Löschungen
• ungewöhnlich viele Dateiöffnungen in kurzer Zeit

Dieses Verhalten ist für den Benutzer untypisch. Historische Vergleichsdaten zeigen, dass mmeyer werktags meist nur wenige Kundendossiers pro Stunde öffnet, nicht aber dutzende Dateien in weniger als zwanzig Minuten.

Warum das Muster verdächtig ist

Technisch ist nicht die Existenz eines Dateizugriffs verdächtig, sondern dessen Menge, Zeit und Auswahl. Mehrere sensible Dateien wurden in kurzer Folge gelesen, ohne dass ein normales Arbeitsmuster sichtbar wäre. Das deutet eher auf Sammlung und Sichtung als auf reguläre Bearbeitung hin.

Schritt fünf: Firewall- und Netzwerklogs korrelieren

Gab es danach externen Datenverkehr?

Nun wird geprüft, ob nach dem internen Dateizugriff ausgehende Kommunikation sichtbar war. Die Firewall-Logs zeigen zwischen 00:03 Uhr und 00:07 Uhr eine HTTPS-Verbindung von der VPN-IP des Benutzers zu einem externen Cloud-Speicher-Dienst, der im Unternehmen nicht regulär freigegeben ist, aber technisch nicht vollständig blockiert wurde.

• neue Ziel-Domain ohne bekannte Geschäftsnutzung
• hohe ausgehende Datenmenge in kurzer Zeit
• kein vergleichbares Muster in den letzten 30 Tagen

Jetzt entsteht ein deutlich klareres Vorfallsbild: VPN-Login, Zugriff auf viele sensible Dateien, danach Upload-ähnlicher Verkehr zu einem externen Ziel. Diese Kette ist sicherheitsrelevant.

Warum NetFlow- oder Traffic-Daten hier helfen

Falls verfügbar, liefern NetFlow- oder vergleichbare Daten zusätzliche Hinweise auf Datenvolumen, Dauer und Richtung der Kommunikation. Diese Informationen helfen, aus einer normalen Webverbindung ein wahrscheinliches Exfiltrationsmuster abzuleiten.

Schritt sechs: Endpunkt- und EDR-Daten betrachten

War das Benutzergerät kompromittiert?

Die nächste Frage lautet: Hat der Benutzer selbst die Dateien bewegt oder war sein Endgerät kompromittiert? EDR-Logs des normalerweise verwendeten Laptops zeigen jedoch keine Aktivität zur Tatzeit. Stattdessen wird sichtbar, dass der VPN-Zugang von einem bisher für den Benutzer unbekannten System erfolgte.

• kein bekannter Corporate Laptop
• kein verwaltetes Gerät
• kein EDR-Agent sichtbar

Das ist ein starkes Indiz dafür, dass nicht das reguläre Endgerät des Mitarbeiters genutzt wurde. Damit steigt die Wahrscheinlichkeit einer Kontoübernahme oder missbräuchlichen Nutzung legitimer Zugangsdaten.

Warum dieser Punkt entscheidend ist

Wenn der Zugriff von einem unbekannten Gerät erfolgt, wird aus einem ungewöhnlichen Benutzerverhalten ein deutlich belastbarerer Sicherheitsverdacht. Das Unternehmen muss nun davon ausgehen, dass Anmeldedaten und MFA-Bestätigung missbraucht wurden.

Schritt sieben: Die Chronologie des Vorfalls rekonstruieren

Die Ereigniskette in richtiger Reihenfolge

Nach Sichtung der Quellen lässt sich der Ablauf des Vorfalls strukturiert rekonstruieren:

• 23:35 Uhr: erste MFA-Anfrage für mmeyer, abgelehnt
• 23:36 Uhr: mehrere fehlgeschlagene Login-Versuche im VPN
• 23:41 Uhr: erfolgreicher VPN-Login mit bestätigter MFA
• 23:43 bis 00:02 Uhr: massenhafte Lesezugriffe auf sensible Dateien
• 00:03 bis 00:07 Uhr: ausgehende HTTPS-Kommunikation zu externem Cloud-Ziel

Diese Kette ist konsistent und spricht stark für einen kompromittierten Fernzugriff mit Datenabfluss.

Warum diese Rekonstruktion so wichtig ist

Erst die Chronologie macht aus vielen isolierten Logs ein belastbares Incident-Bild. Sie zeigt nicht nur, was passiert ist, sondern auch, in welcher Reihenfolge und mit welchen Abhängigkeiten. Genau das ist für Reaktion, Ursachenanalyse und spätere Dokumentation entscheidend.

Schritt acht: Bewertung des Vorfalls

Wie kritisch ist das Ereignis?

Nach der Rekonstruktion wird der Vorfall bewertet. Die wichtigsten Kriterien sind:

• betroffenes Konto mit legitimen Zugriffsrechten
• ungewöhnlicher externer Zugriff
• massenhafte Zugriffe auf sensible Daten
• wahrscheinlicher Upload an externes Ziel

Das Ereignis ist damit nicht mehr nur verdächtig, sondern als schwerwiegender Sicherheitsvorfall einzustufen. Es betrifft Vertraulichkeit geschäftlicher Daten und wahrscheinlich eine kompromittierte Identität.

Was noch unklar bleibt

Trotz guter Loglage bleiben häufig Fragen offen. In diesem Fall ist zum Beispiel noch nicht abschließend geklärt, wie die Zugangsdaten erlangt wurden. Möglich sind Phishing, Passwortwiederverwendung oder Social Engineering im Zusammenhang mit der MFA-Bestätigung. Genau solche Restfragen sind in echten Vorfällen normal.

Schritt neun: Sofortmaßnahmen aus der Loganalyse ableiten

Konten und Sitzungen absichern

Aus den Logs ergibt sich unmittelbar, welche Sofortmaßnahmen nötig sind:

• VPN-Sitzung beenden
• Konto mmeyer sperren oder Passwort zurücksetzen
• MFA neu registrieren
• aktive Sessions in verbundenen Diensten widerrufen

Diese Maßnahmen verhindern, dass derselbe Zugang weiter genutzt werden kann.

Exfiltrationspfad und Zielsysteme prüfen

Parallel sollten die betroffenen Dateien, externen Ziele und eventuell weitere betroffene Systeme geprüft werden. Die Firewall- und Proxy-Daten geben dabei wichtige Hinweise, wohin Daten abgeflossen sein könnten.

Ähnliche Muster im Bestand suchen

Ein sehr wichtiger nächster Schritt ist die Suche nach ähnlichen Mustern in historischen Logs. Falls derselbe externe Zielhost, dieselbe Angriffsmethode oder ähnliche MFA-/VPN-Kombinationen bei anderen Konten auftraten, könnte der Vorfall größer sein als zunächst angenommen.

Was dieses Fallbeispiel über Loganalyse zeigt

Keine einzelne Quelle hätte den Vorfall allein erklärt

Dieses Beispiel zeigt sehr deutlich, dass der Vorfall nicht aus einer einzigen Logquelle vollständig ableitbar war. Erst die Kombination aus VPN-Logs, IAM-Daten, MFA-Ereignissen, Dateiserver-Zugriffen, Firewall-Verkehr und Endpunktstatus erzeugte ein belastbares Bild.

• VPN zeigte den externen Zugang
• IAM und MFA zeigten das Identitätsmuster
• Dateiserver-Logs zeigten die sensible Aktivität
• Firewall-Daten deuteten auf Datenabfluss hin
• EDR-/Endpoint-Sicht zeigte das unbekannte Gerät

Kontext war genauso wichtig wie Rohdaten

Ebenso wichtig war der Kontext: Arbeitszeit, normales Benutzerverhalten, übliche Endgeräte und bekannte Kommunikationsziele. Ohne diese Vergleichsebene wären viele Ereignisse weniger eindeutig gewesen.

Typische Fehler bei der Analyse von Sicherheitsvorfällen anhand von Logs

Zu früh auf eine Ursache festlegen

Ein häufiger Fehler ist, schon nach den ersten Auffälligkeiten eine feste Theorie zu bilden. Gute Loganalyse bleibt zunächst hypothesenoffen und prüft alternative Erklärungen, bis die Datenlage klar genug ist.

Nur eine Datenquelle betrachten

Wer nur Firewall- oder nur Server-Logs prüft, übersieht leicht entscheidende Zusammenhänge. Gerade Sicherheitsvorfälle verlaufen fast immer quellenübergreifend.

Zeitstempel nicht sauber vergleichen

Wenn Systeme nicht sauber per NTP synchronisiert sind oder Zeitverschiebungen nicht berücksichtigt werden, kann die Rekonstruktion fehlerhaft werden. Zeitkonsistenz ist in der Vorfallsanalyse essenziell.

Fehlende Basislinie ignorieren

Ein Muster ist nur dann auffällig, wenn es vom Normalverhalten abweicht. Ohne Wissen über übliche Arbeitszeiten, Geräte und Zugriffspfade wird es schwer, Logmuster richtig zu bewerten.

Praktische CLI-Beispiele im Cisco-Kontext

Lokale Hinweise auf Netzwerkgeräten prüfen

Auch wenn die Hauptanalyse in zentralen Plattformen stattfindet, sind lokale Prüfkommandos auf Netzwerkgeräten im Incident Handling weiter nützlich. Beispiele dafür sind:

show logging
show users
show access-lists
show running-config

show logging zeigt lokale Syslog-Meldungen, show users aktive Sitzungen, show access-lists Treffer auf ACLs und show running-config den aktuellen Konfigurationszustand. Diese Kommandos helfen, lokale Netzperspektive und zentrale Logdaten miteinander abzugleichen.

Lokale Prüfung ersetzt keine zentrale Korrelation

Für Einsteiger ist wichtig: Solche Befehle helfen bei der Detailanalyse, aber der eigentliche Mehrwert im Fallbeispiel entstand erst durch die zentrale Zusammenführung vieler Logquellen. Genau darin liegt die Stärke moderner Monitoring- und SIEM-Umgebungen.

Warum dieses Fallbeispiel für Einsteiger besonders lehrreich ist

Es zeigt die komplette Kette von Erkennung bis Bewertung

Das Beispiel bildet einen realistischen Ablauf ab: Ein einzelner Alarm wird geprüft, Logquellen werden Schritt für Schritt korreliert, eine Chronologie wird erstellt und daraus werden Bewertung sowie Maßnahmen abgeleitet. Genau so läuft Incident-Analyse in vielen Unternehmen in vereinfachter Form tatsächlich ab.

• Alarm wahrnehmen
• Plausibilität prüfen
• mehrere Quellen korrelieren
• Zeitlinie erstellen
• Kritikalität bewerten
• Maßnahmen ableiten

Loganalyse ist strukturierte Ermittlungsarbeit

Am Ende ist die wichtigste Erkenntnis sehr klar: Einen Sicherheitsvorfall anhand von Logs zu analysieren bedeutet nicht, wahllos Meldungen zu lesen, sondern systematisch zu ermitteln. Wer Schritt für Schritt vorgeht, Quellen verknüpft und Kontext einbezieht, kann aus scheinbar isolierten Daten ein belastbares Vorfallsbild ableiten und damit die Grundlage für wirksame Reaktion und bessere Sicherheitsarchitektur schaffen.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.