Sophos ITDR Dark Web Intelligence untersuchen und bereinigen

Dark Web Intelligence zeigt die von Sophos zu den konfigurierten Domains gesammelten Leak-Datensätze. Das Ziel dieses Runbooks ist nicht, jeden Treffer als aktuellen Kontozugriff zu behandeln. Zuerst werden Identität, Zeitbezug, Passworttyp und Leak-Status geprüft. Danach folgt nur eine freigegebene Reaktion für die tatsächlich verknüpfte Identität.

Aktive Credential Leaks erhöhen den Risk Score einer Identität. Historische Datensätze bleiben jedoch sichtbar, auch wenn sie inaktiv sind. Die Tabelle ist deshalb zugleich Arbeitsansicht für aktuelle Risiken und Nachweis älterer Funde.

Schnellablauf

1. My Products > Identity > Dark Web Intelligence öffnen und die Standardfilter dokumentieren.
2. Einen aktiven Datensatz priorisieren und Source, verknüpfte Identität, Passworttyp sowie Publish Date, Leaked Date und Breach Date erfassen.
3. Prüfen, weshalb der Datensatz Active ist; Zeilen nicht mit eindeutigen Konten oder Passwörtern gleichsetzen.
4. Bei einem zugehörigen Finding den angezeigten Schweregrad anhand von Kontotyp, Passworttyp und MFA-Stärke mit der Matrix abgleichen.
5. Zuständigkeit und Freigabe bestätigen. Erst danach die passende, bereits autorisierte Reaktion ausführen.
6. Die Zugangsdaten im zuständigen Identity Provider nach dem freigegebenen Prozess bereinigen. Finding- oder Leak-Status nicht als Ersatz für diese Bereinigung verwenden.
7. Nach mindestens einem 15-Minuten-Zyklus Status, Finding und Risk Score erneut prüfen und den Nachweis dokumentieren.

Ansichten und Standardfilter

Direkter Einstieg

My Products > Identity > Dark Web Intelligence

Beim direkten Einstieg ist die Tabelle standardmässig auf Active beim Leak-Status und Active beim Identitätsstatus gefiltert. Vor der Untersuchung einen Screenshot oder eine Notiz der aktiven Filter sichern. Ein leerer Standardausschnitt beweist nicht, dass keine historischen Leak-Daten vorhanden sind; für diese Prüfung die Statusfilter bewusst erweitern.

Einstieg über Identity Overview

Identity Overview > Credential Leaks

Ein Klick auf eine Kennzahl im Widget Credential Leaks öffnet Dark Web Intelligence mit einem zur Kennzahl passenden Ausschnitt:

Breached Email Accounts und Unique Passwords Breached sind Gesamtkennzahlen der zugrunde liegenden Daten. Es gibt keinen zusätzlichen Tabellenfilter, der ihre eindeutige Zählweise vollständig abbildet. Die Kennzahl lässt sich deshalb nicht exakt aus den nach dem Klick sichtbaren Tabellenzeilen rekonstruieren.

Kennzahlen richtig interpretieren

Die Kennzahlen oben auf Dark Web Intelligence beziehen sich auf aktive Leaks:

Diese Werte verwenden unterschiedliche Einheiten: Quellen, Leak-Datensätze, Konten und eindeutige Passwörter. Sie dürfen weder addiert noch durch blosses Zählen der Tabellenzeilen gegengeprüft werden.

Einen Leak-Datensatz untersuchen

1. Arbeitsumfang festlegen

Zuerst die Filter und Sortierung notieren. Für die Ersttriage sind mindestens diese Merkmale relevant:

• Leak-Status Active oder Inactive
• Identitätsstatus und verknüpfte Identität
• Plaintext oder Hashed
• Admin-, Nicht-Admin- oder VIP-Kontext, soweit angezeigt
• Source
• Publish Date, Leaked Date und Breach Date
• zugehöriges Finding, falls vorhanden

Nicht allein nach dem neuesten Tabellenzeitpunkt priorisieren. Ein Datensatz mit neuem Publish Date kann ältere Inhalte enthalten, insbesondere bei Combolists.

2. Details öffnen

Auf das Feld Source klicken. Das Detailpanel zeigt zusätzliche Angaben zum Leak und, sofern vorhanden, zur verknüpften Identität. Vor einer Reaktion müssen Tabellenzeile und Detailpanel auf dieselbe Quelle und Identität verweisen.

Wenn keine Identität zugeordnet ist, bleibt der Datensatz für die historische Untersuchung relevant, gilt aber als inaktiv. Actions ist in diesem Fall deaktiviert. Keine Identität auf Verdacht zuordnen und keine Reaktion gegen ein ähnlich benanntes Konto ausführen.

3. Datumsfelder trennen

Publish Date

Zeitpunkt, zu dem Sophos den Leak-Datensatz erstmals in den ausgewerteten Daten gefunden hat. Er bezeichnet weder den Zeitpunkt der öffentlichen Verfügbarkeit noch zwingend den Vorfallzeitpunkt.

Leaked Date

Zeitpunkt, zu dem der Datensatz öffentlich verfügbar wurde. Dieses Datum wird mit dem letzten Passwortwechsel verglichen, um die Aktualität des Credential-Risikos zu bewerten.

Breach Date

Zeitpunkt, zu dem der zugrunde liegende Breach stattfand. Das Datum liefert Vorfallkontext, kann aber fehlen.

Ein fehlendes Breach Date macht Leaked Date nicht zum bestätigten Breach-Zeitpunkt. Ebenso beweist ein neues Publish Date nicht, dass das Passwort neu kompromittiert wurde. Für die Statuslogik ist entscheidend, ob der letzte Passwortwechsel vor oder nach dem massgeblichen ersten Leak-Zeitpunkt liegt.

4. Duplikate und Combolists einordnen

Mehrere Zeilen für dieselbe Person innerhalb einer Quelle sind möglich. Gründe sind insbesondere:

• die Person erscheint mehrfach im ursprünglichen Datensatz;
• derselbe Inhalt wurde in einer generischen Quelle wie einer Combolist erkannt;
• ältere Leak-Daten werden in einer später gefundenen Sammlung erneut sichtbar.

Mehrere Zeilen sind daher weder automatisch mehrere kompromittierte Konten noch mehrere aktuelle Passwortkompromittierungen. Für jede Zeile Quelle, Datum, Passworttyp und verknüpfte Identität vergleichen. Die Kennzahlen Emails und Unique Passwords verwenden eine Eindeutigkeitslogik; die Tabellenzeilen tun dies nicht in derselben Weise.

Wann ein Leak Active oder Inactive ist

Ein Leak ist Active, wenn beide Bedingungen erfüllt sind:

1. Der Datensatz kann mit einer aktiven Identität in einem konfigurierten Identity Provider verknüpft werden.
2. Der letzte Passwortwechsel des zugehörigen Kontos liegt vor dem ersten Leak-Zeitpunkt.

Damit bezeichnet Active ein noch relevantes Credential-Risiko. Der Status beweist für sich allein weder eine erfolgreiche Anmeldung durch Dritte noch einen laufenden Angriff.

Ein Leak ist Inactive, wenn mindestens eines der dokumentierten Szenarien zutrifft:

• Es gibt keine passende Identität in den konfigurierten Identity Providern.
• Der jüngste Passwortwechsel liegt nach dem Leak-Zeitpunkt.
• Das Passwort des Kontos wurde kürzlich geändert.
• Das Konto wurde deaktiviert oder gelöscht.
• Ein zugehöriges Finding wurde Resolved oder Dismissed.

Historische Daten zu überwachten Domains werden weiter gesammelt und aufbewahrt. Ein inaktiver Datensatz ist deshalb weder fehlerhaft noch allein wegen seines Alters irrelevant. Er kann erklären, weshalb dieselbe Person oder Quelle mehrfach erscheint.

Wann ein Finding entsteht

Sophos beschreibt für Account-Compromise-Findings diese Verarbeitung:

1. Sophos prüft, ob in den konfigurierten Identity Providern eine aktive Identität existiert.
2. Sophos bestimmt anhand verfügbarer historischer Daten, wann der Klartextwert oder Hash erstmals geleakt wurde. Damit sollen unter anderem alte Inhalte in neuen Combolists erkannt werden.
3. Bei einem Klartextwert vergleicht Sophos den Wert mit den globalen Kennwort-Komplexitätsanforderungen von Microsoft Entra ID, um ungültige Werte auszusortieren.
4. Sophos vergleicht den ersten Leak-Zeitpunkt des Passworts mit dem letzten Passwortwechsel. Liegt der erste Leak danach, erzeugt Sophos ein Finding.

Findings werden nur für aktive Identitäten erzeugt. Die Rohdaten bleiben auf Dark Web Intelligence auch dann sichtbar, wenn keine aktive Identität verknüpft ist.

Schweregradmatrix für Account Compromise

Der Finding-Schweregrad hängt gemäss Sophos vom Kontotyp, Passworttyp und der MFA-Stärke ab:

Die Matrix priorisiert die Bearbeitung, ersetzt aber nicht die Einzelfallprüfung. Besonders bei Admin-Konten muss vor einer Reaktion die tatsächliche Kontozuordnung bestätigt werden. Ein niedrigerer Schweregrad bedeutet nicht, dass keine Bereinigung erforderlich ist.

Umgang mit Passwortwerten

Sophos gibt an, weder Klartextpasswörter noch Hashwerte zu speichern. Sophos kann diese Werte nach eigener Aussage auch nicht aus den Identity Providern erfassen. Bei der Sammlung wendet Sophos einen eigenen Hash auf beobachtete Werte an und kategorisiert den Datensatz anschliessend als Plaintext oder Hashed. Nach Angaben von Sophos ermöglicht dieses Verfahren, eindeutige Werte und daraus abgeleitete Kennzahlen zu ermitteln, ohne den zugrunde liegenden Passwortwert aufzubewahren.

Für den Betrieb folgt daraus:

• Plaintext beschreibt die Art des beobachteten Leak-Inhalts, nicht ein in Sophos Fusion (ehemals Sophos Central) abrufbares Passwort.
• Nicht versuchen, den ursprünglichen Wert aus Sophos Fusion, Screenshots oder Exporten zu gewinnen.
• Keine vermuteten Passwörter, Hashwerte oder neuen Zugangsdaten in Tickets, Notizen oder Chat-Nachrichten kopieren.
• Ein neues Passwort ausschliesslich über den freigegebenen Prozess des Identity Providers setzen und im vorgesehenen Passwortsystem behandeln.

Autorisierte Reaktion und Bereinigung

Entscheidung vor jeder Aktion

Vor Actions müssen alle folgenden Punkte erfüllt sein:

• Die verknüpfte Identität ist anhand des Detailpanels eindeutig bestätigt.
• Kontoinhaber, Kontotyp und geschäftliche Funktion sind bekannt.
• Der aktuelle Leak-Status, Passworttyp und die drei Datumsfelder wurden geprüft.
• Eine Response-Action-Autorisierung ist für den Tenant vorhanden.
• Die ausführende Person ist für die konkrete Identität und die erwartete Auswirkung freigegeben.
• Bei privilegierten oder gemeinsam genutzten Konten ist der zuständige Service- oder Systemverantwortliche einbezogen.

Fehlt eine dieser Bedingungen, wird keine Aktion ausgelöst. Der Datensatz wird mit Zeitstempel, Filterzustand und Angabe der fehlenden Freigabe an die zuständige Person im Identity- oder Security-Team übergeben.

Reaktion in Dark Web Intelligence

Wenn Response Actions autorisiert wurden, stehen sie für verknüpfte Identitäten in der Tabelle oder im Leak-Detail zur Verfügung:

1. Richtige Zeile beziehungsweise das Detailpanel der bestätigten Identität öffnen.
2. Actions wählen.
3. Ausschliesslich die bereits freigegebene Response Action auswählen.
4. Hinweise und Bestätigungen der Oberfläche vollständig prüfen und befolgen.
5. Aktion, ausführende Person, Zeitpunkt, Zielidentität und sichtbares Resultat dokumentieren, jedoch keine Credentials erfassen.

Es dürfen ausschliesslich die im Tenant angebotenen und organisatorisch autorisierten Response Actions verwendet werden. Ist keine passende Identität vorhanden, bleibt Actions deaktiviert; dies darf nicht umgangen werden.

Credential-Risiko bereinigen

Die technische Bereinigung erfolgt über den für das Konto verantwortlichen Identity Provider und den dort freigegebenen Credential-Prozess:

1. Letzten Passwortwechsel und Kontostatus der bestätigten Identität gegen den Leak-Zeitpunkt prüfen.
2. Wenn sich nicht ausschliessen lässt, dass die im Leak beobachteten Zugangsdaten noch gültig sind, einen autorisierten Passwortwechsel für genau dieses Konto veranlassen oder durchführen.
3. Bei einem deaktivierten oder gelöschten Konto den Provider-Status bestätigen, statt das Konto zur Bereinigung wieder zu aktivieren.
4. Bei fehlender Zuordnung den Datensatz als historischen, inaktiven Leak behandeln und die Kontoidentität nicht erraten.
5. Ein zugehöriges Finding erst dann nach dem vorgesehenen Findings-Prozess bearbeiten, wenn die reale Credential-Bereinigung belegt ist. Dismissed nur nach fachlich dokumentierter Entscheidung verwenden, nicht zur Verkürzung der Warteschlange.

Keine zusätzlichen Konto-, Sitzungs-, MFA- oder Verzeichnisänderungen aus dem Leak-Datensatz ableiten. Solche Massnahmen benötigen einen separat bestätigten Anlass und die dafür geltende Freigabe.

15-Minuten-Takt und Validierung

Sophos prüft Dark Web Intelligence alle 15 Minuten. Sophos überwacht und sammelt Leak-Ergebnisse fortlaufend; wenn ein aktiver Leak erkannt wird, wird ein Finding im Allgemeinen innerhalb von 15 Minuten erzeugt. «Im Allgemeinen» ist keine garantierte Maximalzeit.

Nach der Bereinigung nicht sofort einen endgültigen Erfolg protokollieren. Stattdessen:

1. Abschlusszeit des Passwortwechsels oder der bestätigten Kontoänderung mit Zeitzone festhalten.
2. Mindestens einen vollständigen 15-Minuten-Zyklus abwarten. Berücksichtigen, dass die Übernahme aktualisierter Identity-Provider-Daten durch Sophos zusätzlich Zeit benötigen kann.
3. My Products > Identity > Dark Web Intelligence erneut öffnen.
4. Dieselbe Identität und Quelle mit denselben Filtern suchen.
5. Prüfen, ob der Leak von Active auf Inactive gewechselt hat und ob der angezeigte Identitätsstatus korrekt ist.
6. Das zugehörige Finding separat prüfen. Ein fehlendes neues Finding ist kein ausreichender Nachweis, wenn der Leak weiterhin Active ist.
7. Den Risk Score der Identität als Folgesignal beobachten. Er ist nicht der Primärnachweis für den Passwortwechsel.
8. Ausgangswert, Massnahme, Abschlusszeit, Prüfzeit und Endstatus dokumentieren.

Abnahmekriterien

Die Bearbeitung ist erst abgeschlossen, wenn:

• Identität und Leak-Quelle eindeutig dokumentiert sind;
• Passworttyp und Datumsfelder bewertet wurden;
• die Credential-Bereinigung im zuständigen Identity Provider bestätigt ist oder das Konto nachweislich deaktiviert beziehungsweise gelöscht ist;
• der bearbeitete Leak-Datensatz nach der Verarbeitung nicht mehr Active ist;
• das zugehörige Finding kontrolliert bearbeitet wurde;
• keine geheimen Werte in der Dokumentation stehen.

Bleibt der Datensatz nach mehreren 15-Minuten-Zyklen Active, zuerst den tatsächlichen letzten Passwortwechsel, den Kontostatus und die verknüpfte Identität erneut prüfen. Sind diese Angaben korrekt und bleibt der Status dennoch nicht nachvollziehbar, Filterzustand, Quelle, alle drei Datumsfelder, Identitätsreferenz, Finding-Referenz und Zeitstempel sichern. Anschliessend an Sophos Support eskalieren. Keine weiteren Kontoänderungen auf Verdacht ausführen.

Triage-Protokoll

Tenant / Umgebung:
Prüfzeit mit Zeitzone:
Pfad und aktive Filter:
Source:
Verknüpfte Identität:
Identitätsstatus:
Kontotyp: Admin / Nicht-Admin / unklar
VIP-Monitoring: ja / nein / unklar
Passworttyp: Plaintext / Hashed
Leak-Status vor der Massnahme:
Publish Date:
Leaked Date:
Breach Date: Wert / nicht verfügbar
Mehrfachzeilen oder Combolist-Kontext:
Finding-Referenz und Schweregrad:
Letzter Passwortwechsel laut Identity Provider:
Freigabe für Reaktion:
Ausgeführte autorisierte Massnahme:
Abschlusszeit mit Zeitzone:
Validierung nach 15-Minuten-Zyklus:
Leak-Status nach der Massnahme:
Finding-Status nach der Massnahme:
Risk Score als Folgesignal:
Offene Abweichung / Eskalation:

Häufige Fehlentscheidungen vermeiden

• Jede Tabellenzeile als eigenes Konto zählen: Duplikate und Combolists können mehrere Zeilen für dieselbe Person erzeugen.
• Publish Date als Breach Date lesen: Die drei Datumsfelder beschreiben unterschiedliche Ereignisse; Breach Date kann fehlen.
• Inactive als gelöscht interpretieren: Historische Daten bleiben erhalten und können weiter sichtbar sein.
• Keine Zeile im Standardfilter als Entwarnung werten: Der direkte Einstieg zeigt standardmässig nur aktive Leaks aktiver Identitäten.
• Ein Finding manuell schliessen und damit die Bereinigung ersetzen: Ein Statuswechsel ändert keine Zugangsdaten im Identity Provider.
• Actions ohne verknüpfte Identität erzwingen: Ohne passende Identität ist die Schaltfläche absichtlich deaktiviert.
• Plaintext mit einem abrufbaren Passwort verwechseln: Sophos sagt, dass weder Klartextwerte noch Hashwerte gespeichert werden.
• Sofortige Aktualisierung erwarten: Die Prüfung läuft im 15-Minuten-Takt; vorgelagerte Identitätsdaten können zusätzliche Verarbeitungszeit benötigen.