So lesen Sie das
Bewertungsprotokoll (Trace)
Zu jeder Bewertung hält der Threat Correlator fest, was er sich angesehen hat, welche Tools er aufgerufen hat und auf welcher Grundlage er zu seinem Schluss kam. Echte Ausführungsprotokolle können wir noch nicht veröffentlichen. Deshalb erklären wir auf dieser Seite den Aufbau und lesen ein Beispiel von Anfang bis Ende.
Was in einem Protokoll steht
Von oben nach unten gelesen entspricht das Protokoll der Reihenfolge, in der die Bewertung entstanden ist.
Zu einer Bewertung gehören mehrere Schritte (steps), und jeder Schritt bündelt Beobachtung, Tool-Aufruf, Beleg und Schlussfolgerung.
| Feld | Inhalt | Worauf Sie beim Lesen achten |
|---|---|---|
| input_hash | SHA-256 über das gesamte Eingabepaket der Bewertung | Bei einer Wiederholung prüfen Sie hiermit, ob dieselbe Eingabe verwendet wurde |
| sources | Herkunft der Eingaben (EDR, Mail-Gateway, Proxy usw.) und Zeitraum | Fehlt eine Quelle, ist auch die Bewertung entsprechend eingeschränkt |
| steps[].observation | Die Tatsache, auf die der Schritt sich stützt | Ein Satz, der das Rohlog zusammenfasst. Prüfen Sie, ob er zu den Belegen darunter passt |
| steps[].tool_call | Aufgerufenes Tool, Parameter, zusammengefasstes Ergebnis | Stimmen Parameter wie Zeitraum oder Hostname? |
| steps[].evidence | Beleg-ID, Fundstelle im Original, Hash | Angehängt ist auch das Ergebnis des automatischen Abgleichs, ob das zitierte Log im Original existiert |
| steps[].reasoning | Warum aus den Belegen dieser Schluss folgt, ATT&CK-Technik-ID | Jeder Begründungssatz muss auf eine Beleg-ID verweisen |
| verdict · confidence | Label, Risiko, Konfidenz und die Gründe, die die Konfidenz gesenkt haben | Ist begründet, warum die Konfidenz nicht höher liegt? |
| recommended_actions | Empfohlene Maßnahmen und ob eine Freigabe nötig ist | Host-Isolierung und Kontosperrung erfordern immer eine Freigabe |
| approval | Rollen-ID der freigebenden Person, Freigabe, Änderung oder Ablehnung, Zeitpunkt, Kommentar | Hier lässt sich auch ablesen, wie lange die Freigabe gedauert hat |
| versions | Modellversion, Version der Prompt-Vorlage, Richtlinienversion | Schon eine geänderte Formulierung im Prompt bedeutet geänderte Bewertungskriterien |
| replay | Ergebnis eines späteren Laufs unter denselben Bedingungen und Abweichung von der ursprünglichen Bewertung | Der Wortlaut darf abweichen. Entscheidend ist, ob Label und Risiko gleich sind |
Ein Beispielprotokoll von Anfang an gelesen
Beispielprotokoll · keine echten Kundendaten und kein echter Lauf. Wir haben es aus Techniken zusammengesetzt, die MITRE ATT&CK für die frühe Phase von Ransomware beschreibt (Phishing-Anhang, PowerShell-Ausführung, Löschen von Schattenkopien). Hostnamen, Konten, Uhrzeiten und Konfidenzwerte dienen nur der Erklärung. Für Domain und IP haben wir die für Dokumentation reservierten Werte (.example, 203.0.113.0/24) verwendet.
Wo Sie in diesem Protokoll zuerst hinschauen
Beginnen Sie mit der Frage, warum die Konfidenz in der Bewertungszeile bei 0,91 stehen bleibt. In diesem Beispiel ist vermerkt, dass noch keine Dateiverschlüsselung beobachtet wurde und dass der Hash der heruntergeladenen ausführbaren Datei in der Threat Intelligence keinen Treffer hatte. Umgekehrt gilt: Ein Protokoll mit hoher Konfidenz, aber ohne Gründe für Abzüge verdient mehr Misstrauen.
Danach kommt die Freigabezeile. Host-Isolierung wird laut Richtlinie nie automatisch ausgeführt. Aus dem Protokoll geht auch hervor, dass zwischen der Bewertung und der Freigabe durch den Analysten, der die Begründung gelesen hat, gut zwei Minuten lagen.
Schritt für Schritt gelesen
- E-Mail-Eingang (step 1). Im Log des Mail-Gateways steht eine E-Mail von
billing@invoice-notice.examplemit dem Anhang견적서_1021.docm(„Angebot“). Die KI hat mitmail.search(message_id=…)die Metadaten der Originalmail und mitintel.domain_whois("invoice-notice.example")die Domaininformationen abgefragt. Ergebnis: Die Domain ist drei Tage alt. Der Begründungssatz lautet „Office-Anhang mit Makro in Kombination mit neuer Domain, möglicherweise T1566.001“ und verweist auf die Belege E1 und E2. Allein auf Grundlage dieses Schritts wurde keine Bewertung abgegeben. - PowerShell-Ausführung (step 2). In Sysmon-Event-ID 1 (Prozesserstellung) steht eine Zeile mit
WINWORD.EXEals Eltern- undpowershell.exe -NoP -W Hidden -enc JABjAD0A…als Kindprozess. Die KI hat mitedr.process_tree(host="fin-ws-0412", from="09:12", to="09:20")den Prozessbaum abgerufen, den kodierten Befehl dekodiert und festgestellt, dass erhttps://203.0.113.45/u.ps1herunterlädt. Lautbaseline.parent_child(host, 30d)hat auf diesem Host in den letzten 30 Tagen keine Office-Anwendung PowerShell gestartet. Begründung T1059.001, Belege E3 und E4. - Löschen der Schattenkopien (step 3). Sysmon-Event-ID 11 (Dateierstellung) zeigt, dass
C:\Users\user01\AppData\Local\Temp\upd.exeangelegt wird. Gut 20 Sekunden später erscheint in Event-ID 1vssadmin.exe delete shadows /all /quietmitupd.exeals Elternprozess.intel.hash_lookuplieferte keinen Treffer. Begründung ist T1490 (Inhibit System Recovery). Der ATT&CK-Eintrag zu T1490 führt ebenfalls mehrere Ransomware-Fälle auf, in denen vor der Verschlüsselung zuerst die Schattenkopien gelöscht wurden. - Bewertung. Echter Treffer, Vorbereitungsphase einer Ransomware-Ausführung, Risiko CRITICAL, Konfidenz 0,91. Als Gründe für den Abzug bei der Konfidenz stehen zwei Punkte im Protokoll: „keine massenhaften Dateiänderungen beobachtet“ und „Hash von upd.exe ohne Treffer in der Threat Intelligence“.
- Empfohlene Maßnahmen und Freigabe. Host vom Netz isolieren (Freigabe nötig), E-Mails mit demselben Anhang-Hash zurückziehen, Absenderdomain und 203.0.113.45 sperren. Die Isolierung hat analyst-07 um 09:17 freigegeben, mit dem Kommentar „Bitte SMB-Sitzungen zum Fileserver prüfen“. Die beiden Sperren lagen innerhalb der mit dem Kunden vereinbarten Richtlinie für automatische Reaktionen und wurden ohne Freigabe ausgeführt.
- Wiederholung. Am nächsten Tag wurde die Bewertung mit demselben input_hash, derselben Modell- und Richtlinienversion erneut ausgeführt. Label und Risiko waren gleich, die Konfidenz lag bei 0,89, und die Begründungssätze waren teilweise anders formuliert. Der Wortlaut wird nicht verglichen, das Ergebnis gilt daher als „übereinstimmend“.
Dasselbe Protokoll im Rohformat
Hier steht das obige Beispiel gekürzt im Protokollformat. Die Feldnamen dienen der Erklärung. Das tatsächliche Exportformat dokumentieren wir zum Marktstart.
// Beispielprotokoll · keine echten Kundendaten und kein echter Lauf
{
"trace_id": "VT-EXAMPLE-0001",
"input_hash": "sha256:9f3a…c21e",
"sources": [
{"type": "mail_gateway", "range": "09:00~09:20"},
{"type": "edr_sysmon", "host": "fin-ws-0412", "range": "09:00~09:20"}
],
"steps": [
{"n": 1,
"observation": "Anhang mit Makro (견적서_1021.docm), Absenderdomain seit 3 Tagen registriert",
"tool_calls": ["mail.search(message_id=…)", "intel.domain_whois(\"invoice-notice.example\")"],
"evidence": [{"id": "E1", "ref": "mailgw/2026/10/21/09.log#L2207", "sha256": "1c0d…7be2", "verified": true},
{"id": "E2", "ref": "intel/whois/invoice-notice.example", "verified": true}],
"reasoning": "E1+E2: möglicher Spearphishing-Anhang", "attack": ["T1566.001"]},
{"n": 2,
"observation": "WINWORD.EXE → powershell.exe -NoP -W Hidden -enc …",
"tool_calls": ["edr.process_tree(host=\"fin-ws-0412\", from=\"09:12\", to=\"09:20\")",
"baseline.parent_child(host=\"fin-ws-0412\", window=\"30d\")"],
"evidence": [{"id": "E3", "ref": "sysmon:EventID=1 RecordID=884213", "verified": true},
{"id": "E4", "ref": "baseline/fin-ws-0412/parent_child", "verified": true}],
"reasoning": "E3: Office-Anwendung startet kodierte PowerShell, E4: in 30 Tagen ohne Präzedenzfall",
"attack": ["T1059.001"]},
{"n": 3,
"observation": "upd.exe angelegt, danach vssadmin.exe delete shadows /all /quiet",
"tool_calls": ["edr.process_tree(…)", "intel.hash_lookup(\"sha256:3b7e…a19f\")"],
"evidence": [{"id": "E5", "ref": "sysmon:EventID=11 RecordID=884240", "verified": true},
{"id": "E6", "ref": "sysmon:EventID=1 RecordID=884251", "verified": true}],
"reasoning": "E6: Wiederherstellungsmittel gelöscht, als Phase vor der Verschlüsselung eingestuft", "attack": ["T1490"]}
],
"verdict": {"label": "true_positive", "severity": "critical",
"summary": "Vorbereitungsphase einer Ransomware-Ausführung",
"confidence": 0.91,
"confidence_notes": ["keine massenhaften Dateiänderungen beobachtet", "Hash von upd.exe ohne Treffer in der Threat Intelligence"]},
"recommended_actions": [
{"action": "isolate_host", "target": "fin-ws-0412", "requires_approval": true},
{"action": "recall_mail", "match": "attachment_sha256", "requires_approval": false},
{"action": "block", "targets": ["invoice-notice.example", "203.0.113.45"], "requires_approval": false}
],
"approval": {"action": "isolate_host", "by": "analyst-07", "decision": "approved",
"at": "2026-10-21T09:17:40+09:00", "comment": "Bitte SMB-Sitzungen zum Fileserver prüfen"},
"versions": {"model": "correlator-model-x.y", "prompt_template": "triage-vNN", "policy": "auto-response-YYYY.MM"},
"replay": {"at": "2026-10-22T10:05:12+09:00", "same_input_hash": true,
"label_match": true, "severity_match": true, "confidence": 0.89,
"text_diff": "Begründungssätze teilweise anders formuliert"}
}
verified ist das Ergebnis des automatischen Abgleichs, ob das zitierte Log im Originalspeicher tatsächlich existiert. Steht dort auch nur einmal false, wird die Bewertung zurückgehalten und an Analysten übergeben. Wie wir diesen Abgleich zählen, steht auf der Seite zur Qualität der KI-Bewertungen unter „Erkennung erfundener Ausgaben“.
Was die Empfänger mit dem Protokoll anfangen
Das Bewertungsprotokoll ist kein internes Log, das nur Genox liest.
Wir legen es so an, dass das Sicherheitsteam des Kunden und Prüfer es selbst öffnen und lesen können.
Audits
Kommt bei einem Audit oder einer Vorfalluntersuchung die Frage „Warum wurde dieser Host isoliert?“, beantworten Sie sie mit einem einzigen Protokoll. Was gesehen wurde, steht in evidence, wer freigegeben hat, in approval, und welches Modell und welche Richtlinie damals liefen, in versions. Belege werden als Fundstelle und Hash gespeichert. Die Aufbewahrungsfrist der Rohlogs sollten Sie deshalb an die der Bewertungsprotokolle angleichen.
Fehlalarme analysieren
Bei einer Bewertung, die sich als Fehlalarm herausgestellt hat, suchen Sie den Schritt, an dem es schiefging. Ob ein Parameter beim Tool-Aufruf falsch war, die Baseline-Abfrage leer blieb oder die Schlussfolgerung über die Belege hinausging, zeigt sich meist, wenn man die steps einzeln durchgeht. Wenn wir Fehlalarme im Monatsbericht aufführen, hängen wir genau dieses Protokoll an.
Regeln verbessern
Wird die Konfidenz immer wieder aus demselben Grund gesenkt, sehen Sie, wo Erfassungsumfang oder Erkennungsregeln nachgebessert werden müssen. Im Beispiel oben fehlte das Audit-Log des Fileservers in sources, deshalb ließ sich Lateral Movement nicht prüfen. Nach einer Richtlinienänderung lassen wir frühere Bewertungen mit der neuen Version erneut laufen und prüfen die Unterschiede.
Echte Protokolle veröffentlichen wir,
sobald sie vorliegen
In der isolierten Umgebung des Research Lab stellen wir öffentlich bekannte Angriffstechniken nach und sammeln die Protokolle, mit denen der Threat Correlator sie bewertet hat. Sobald genug Ausführungsprotokolle ohne Kundendaten vorliegen, stellen wir sie unverändert auf diese Seite. Bis dahin sind alle Protokolle hier Beispiele.
Unsere Regeln für die Veröffentlichung
- Protokolle mit falscher Bewertung veröffentlichen wir genauso wie die mit richtiger
- Die Technik-IDs und das Vorgehen beim Nachstellen stehen jeweils dabei
- Jedes Protokoll trägt Modell- und Richtlinienversion. Ändert sich eine Version, ergänzen wir das Ergebnis eines erneuten Laufs
- Hostnamen und Konten der isolierten Umgebung legen wir so an, dass sie sich nicht mit echten Kundenumgebungen überschneiden
Weiterführende Seiten
Wie wir die Qualität von KI-Bewertungen messen
Wie wir anhand der Bewertungsprotokolle Genauigkeit, Fehlalarme und übersehene Angriffe, fehlende Belege und die Übereinstimmung bei Wiederholung messen.
Zur MessmethodeThreat Correlator
Die Engine, die Alerts zu Fällen bündelt und Belege, Begründung, Bewertung, empfohlene Maßnahmen und Konfidenz protokolliert.
Threat CorrelatorPlattform
Wie Vulnerability Scanner, Behavioral Analyzer, Threat Correlator und Research Lab zusammenhängen.
Zur PlattformQuellen
- Phishing: Spearphishing Attachment (T1566.001), MITRE ATT&CK
- Command and Scripting Interpreter: PowerShell (T1059.001), MITRE ATT&CK
- Inhibit System Recovery (T1490), MITRE ATT&CK
- Sysmon, Microsoft Sysinternals (Event-ID 1 Prozesserstellung, 11 Dateierstellung)
- vssadmin delete shadows, Microsoft Learn
- RFC 5737 IPv4 Address Blocks Reserved for Documentation, IETF
- RFC 2606 Reserved Top Level DNS Names, IETF