Sophos XDR Threat Intelligence Explorer nutzen

Der Threat Intelligence Explorer macht die Bedrohungsinformationen der Sophos Counter Threat Unit (CTU) in Sophos Fusion (ehemals Sophos Central) durchsuchbar. Man kann Malware-Familien, Analysen und bekannte Bedrohungsgruppen recherchieren und den beschriebenen Kontext mit Detections aus der eigenen Umgebung vergleichen. Ein Eintrag in dieser Wissensbasis ist noch kein Treffer im eigenen Tenant und keine bestätigte Kompromittierung.

Der Kurzablauf: Security Operations > Threat Intelligence öffnen, über Malware, Threat Report oder Threat Group recherchieren, verfügbare Details lesen und Related Detections von Related Detectors unterscheiden. Erst die eigenen Ereignisse zeigen, ob der recherchierte Zusammenhang für einen konkreten Case relevant ist.

Voraussetzungen und Grenzen

Der Explorer benötigt eine XDR- oder Enterprise-Lizenz. Dieser Ablauf beschreibt die Ansicht Security Operations. Threat Analysis Center bleibt als Classic-Ansicht verfügbar; bestehende Untersuchungs- und Case-Runbooks können deshalb noch diesen Menüpfad zeigen. Die Beschriftungen beider Ansichten sollten nicht vermischt werden.

Die CTU aktualisiert ihre Intelligence aus Incident-Response-Untersuchungen, globaler Bedrohungsbeobachtung, technischen Malware- und Kampagnenanalysen sowie der Zusammenarbeit mit Partnern und Behörden. Diese Informationen beschreiben die Bedrohungslage; die Detections und Events im Tenant beschreiben die eigene beobachtete Aktivität. Für eine Untersuchung braucht man beide Ebenen.

Dabei sind drei Begriffe wichtig:

Ein Indicator of Compromise (IOC) ist beispielsweise ein in einer Analyse genannter Hinweis auf eine mögliche Kompromittierung. Seine Bedeutung wird zusammen mit Zeitpunkt, Herkunft und beobachtetem Verhalten geprüft.
Ein Detector ist die Erkennungslogik, die aus ungewöhnlichen oder verdächtigen Events eine Detection erzeugt. Ein zugehöriger Detector ist nicht dasselbe wie ein bereits vorhandener Treffer.
Tactics, Techniques and Procedures (TTPs) beschreiben die Vorgehensweise eines Angreifers. Ähnliche TTPs oder dieselbe Malware beweisen nicht, dass eine bestimmte Gruppe den eigenen Tenant angegriffen hat.

Der Explorer ist hier ein Recherche- und Untersuchungseinstieg. Das Lesen oder Filtern einer Malware-Familie wird nicht als Einrichtung eines Firewall-Threat-Feeds, einer Blockregel oder einer Response-Aktion behandelt.

Suchen, bevor man die Ergebnisse eingrenzt

Die Suchleiste oben rechts durchsucht Malware, Threat Reports und Threat Groups. Als Ausgangspunkt eignet sich ein Begriff aus einer Detection oder einem Bericht, etwa Emotet. Der Wert ist nur ein Suchbeispiel; verwendet wird der tatsächlich zu untersuchende Name.

Unter Security Operations > Threat Intelligence eine der drei Ansichten öffnen und den Suchbegriff eingeben.
Einen konkreten Treffer auswählen, um seine Details anzusehen. Wenn zunächst die Trefferliste verglichen werden soll, View in table oder See all wählen. Die entsprechende Tabelle wird auf die Suchergebnisse gefiltert.
Erst danach zusätzliche Filter setzen. So bleibt sichtbar, ob ein enger Filter nützliche Ergebnisse ausgeschlossen hat.
Für einen neuen Rechercheansatz das X rechts im Suchfeld anklicken. Es löscht die Suche und setzt auch die Tabellenfilter zurück. Vorher wichtige Suchbegriffe und Filter im Untersuchungsprotokoll festhalten.

Mehrere Filter sind sinnvoll, wenn sie eine konkrete Frage beantworten. Ein bekannter Malware-Name plus eine CVE ist eine andere Recherche als die Suche nach aktuellen Ransomware-Berichten für eine Branche. Zu viele Kriterien am Anfang machen eine leere Liste schwer interpretierbar.

Malware-Familie untersuchen

Malware enthält technische Analysen, IOCs und Verbindungen zu Bedrohungsakteuren. Standardmässig sortiert die Tabelle zuerst nach der von der CTU gesetzten Threat Priority für wichtige oder aktuelle Bedrohungen und danach nach der letzten Aktualisierung. Diese Reihenfolge ist eine Priorisierung der Intelligence, nicht die Severity einer eigenen Detection.

Die dokumentierten Filter erfüllen unterschiedliche Aufgaben:

Malware sucht nach dem Familiennamen, beispielsweise Emotet oder TrickBot.
Type grenzt die Klassifikation ein, etwa Trojan, Ransomware oder Backdoor.
Threat Group sucht nach Malware mit einer Verbindung zu einer bestimmten Gruppe, beispielsweise GOLD MYSTIC oder BRONZE BUTLER.
CVE sucht nach Malware, die eine bestimmte Schwachstelle ausnutzt. Beispielsweise verwendet man CVE-2021-44228, wenn genau diese Schwachstelle Gegenstand der Untersuchung ist. Der Filter ersetzt nicht die Prüfung, ob eigene Systeme tatsächlich betroffen sind.

Ein Klick auf den Familiennamen öffnet den seitlichen Detailbereich. Dort zuerst Malware family overview für Beschreibung und Klassifikation lesen, danach Technical details für Verhalten, Fähigkeiten und Indikatoren. Solution and mitigation enthält empfohlene Schutzmassnahmen. Empfehlungen werden gegen die eigene Plattform und den bereits vorhandenen Schutz geprüft, nicht allein wegen eines Suchtreffers umgesetzt.

Die zugehörige Intelligence steht, soweit verfügbar, in eigenen Tabs:

Threat Group nennt Gruppen, die diese Malware verwenden.
Threat Report führt zu verwandten CTU-Berichten.
Related Detections zeigt Detection-Daten aus der eigenen Umgebung.
Related Detectors zeigt Sophos-XDR-Detektoren, die diese Malware erkennen.

Mit dem New Tab-Symbol lässt sich die Detailansicht in einem neuen Tab öffnen. Von dort kann die URL kopiert und als genauer Verweis im Untersuchungsprotokoll verwendet werden. Das ist hilfreicher als nur der Familienname, wenn mehrere Analysten denselben Eintrag prüfen sollen.

Threat Report für die konkrete Frage auswählen

Threat Report enthält CTU-Veröffentlichungen wie tägliche Briefings, vertiefte Analysen und Bedrohungshinweise. Für eine konkrete Detection wird zunächst nach Malware, Gruppe oder CVE gesucht; für einen regelmässigen Lageüberblick eignen sich Thema und Veröffentlichungsart.

Die Filter unterscheiden Inhalt und Publikationsform:

Threat Report sucht nach dem Berichtsnamen, etwa Daily Threat Brief oder Ransomware Analysis.
Report Type ist die allgemeine Publikationskategorie, etwa Advisory, Analysis oder Brief.
Category bezeichnet die spezifischere Art, etwa Customer Advisory, Threat Analysis oder CTU TIPS.
Threat Type grenzt die behandelten Bedrohungen ein, beispielsweise Ransomware, APT oder Cybercrime.
Threat Actor Type unterscheidet Akteurstypen wie Nation-state, Cybercriminal oder Hacktivist.
Target Geography sucht nach dem geografischen Schwerpunkt, etwa Europe oder Global.
Target Sectors grenzt die diskutierten Branchen ein, etwa Financial, Healthcare oder Government.
Threat Group, Malware und CVE suchen nach den jeweils im Bericht behandelten Gruppen, Malware-Familien und Schwachstellen.

Target Geography und Target Sectors helfen bei der Priorisierung, sind aber keine Ausschlusskriterien für das eigene Risiko. Opportunistische Angriffe können jede Region und Branche betreffen, auch ohne spezifische Zielpräferenz. Ein Lageüberblick sollte deshalb nicht ausschliesslich auf die eigene Branche eingeschränkt werden.

Den Berichtsnamen anklicken und den Detailbereich lesen. Je nach Bericht stehen Full report text, Executive summary, Technical details und Indicators of compromise zur Verfügung. Nicht jede Veröffentlichung enthält alle diese Bereiche. Indicators of compromise kann zugehörige IOCs und Signaturen enthalten. Die Zusammenfassung gibt Orientierung; für die Untersuchung sind die konkreten technischen Angaben und ihre Grenzen entscheidend.

Soweit vorhanden, zeigt Related Detections eigene Detections und Related Detectors im Bericht erwähnte XDR-Detektoren. Auch hier sind eine verfügbare Erkennungslogik und ein beobachteter Tenant-Treffer zwei unterschiedliche Aussagen. Über New Tab den vollständigen Bericht öffnen und bei Bedarf seine URL für den Case kopieren.

Threat Group als Arbeitshypothese einordnen

Threat Group beschreibt bekannte Bedrohungsgruppen und ihre TTPs. Diese Ansicht ist sinnvoll, wenn ein Bericht eine Gruppe nennt, ein bekannter Alias aufgelöst werden soll oder man die eigene Abwehr gegen bestimmte Vorgehensweisen beurteilen möchte.

Die Filter decken Identität, Absicht und Vorgehen ab:

Threat Group sucht nach der Gruppenbezeichnung, etwa GOLD MYSTIC oder BRONZE ATLAS.
Thematic Area grenzt den thematischen oder regionalen Zusammenhang ein, etwa Cybercrime, China oder Russia.
Aliases sucht nach alternativen Namen wie APT1, Lazarus Group oder FIN7.
Status unterscheidet den aktuellen Aktivitätsstatus, etwa Active und Inactive.
Motivation beschreibt Beweggründe wie Financial, Political oder Military.
Objectives beschreibt Ziele wie Financial Gain, Espionage oder Disruption.
Target Geography und Target Sectors suchen nach geografischen beziehungsweise branchenspezifischen Zielmustern.
Malware sucht nach verbundenen Familien; Tools nach eingesetzten Werkzeugen und Techniken, beispielsweise PowerShell, Mimikatz oder PsExec.

Auch Gruppen ohne spezifische Zielpräferenz können die eigene Region oder Branche treffen. Eine leere Liste nach einem Sektorfilter ist deshalb keine Entwarnung.

Nach dem Klick auf den Gruppennamen enthält der Detailbereich Group description mit Hintergrund und eingeschätzten Fähigkeiten, Attribution assessment mit geografischer oder organisatorischer Zuordnung, Activity timeline mit Kampagnen und Operationen sowie die Analyse der Tactics, Techniques, and Procedures. New Tab öffnet die Details für einen kopierbaren direkten Verweis.

Die Attribution assessment bleibt eine Einschätzung der CTU. Sie beweist weder die Urheberschaft eines eigenen Vorfalls noch, dass jede Nutzung derselben Malware zu dieser Gruppe gehört. Im Case sollte man deshalb beispielsweise «Verhalten passt zu den beschriebenen Techniken» festhalten und getrennt dokumentieren, welche eigenen Events diese Aussage stützen. Eine definitive Akteur-Zuordnung benötigt mehr Evidenz als einen Namens-, Tool- oder Malware-Treffer.

Vom Intelligence-Eintrag zur Detection und zum Case

Threat Intelligence reichert Detections automatisch mit relevantem Kontext an; mehrere XDR-Detektoren nutzen diese Daten für die Erkennung. Daraus folgt keine Zusage, dass jede beschriebene Technik in jedem Tenant erkannt wird. Die Untersuchung geht deshalb vom Kontext zurück zu den tatsächlichen Ereignissen.

Eigene Detections gegenprüfen

Wenn Related Detections Treffer enthält, einen passenden Treffer öffnen und über New Tab die vollständigen Detection-Details ansehen. Alternativ unter Security Operations > Detections suchen. Die dortige Standardzeitspanne beträgt 72 Stunden; für einen älteren Vorfall muss der Zeitraum angepasst werden. Filter und Include Options kontrollieren, damit benutzerdefinierte oder bereits triagierte Detections nicht unbeabsichtigt ausgeschlossen bleiben.

In der Detection prüfen:

Auf Summary die Affected Entities, den auslösenden Detector, die verfügbaren Zeitangaben sowie Severity und Confidence lesen. First and Last Activity beschreiben Ereigniszeitpunkte; Inserted At bezeichnet den Zeitpunkt der Protokollierung.
Auf Events die Ereignisse öffnen, die zur Detection führten. Auf JSON bei Bedarf die zugrunde liegenden Detection-Daten ansehen. Die Zusammenfassung ist kein Ersatz für diese Evidenz.
Auf Insights verwandte offene und geschlossene Detections sowie Cases prüfen. Bereits vorhandene Cases können Doppelarbeit vermeiden; geschlossene Cases liefern historischen Untersuchungskontext.
Für weitere Intelligence auf das Shield-Symbol in Affected Entities klicken oder auf Entities eine Entität mit diesem Symbol auswählen. Der Pivot von einer Detection zur Intelligence funktioniert damit auch in der Gegenrichtung.

Für eine vertiefte Untersuchung von Endpoint-Prozessen und Graphen dient das Runbook zu Detections und Threat Graphs. Es behandelt auch die Classic-Ansicht. Fehlende eigene Detections in einem Intelligence-Eintrag beweisen weder einen sauberen Tenant noch vollständige Telemetrie. Wenn weitere Abfragen nötig sind, erklärt das Runbook zu Data Collection und Live Discover die Datengrundlage und den klassischen Abfrageablauf.

Passende Evidenz an einen Case übergeben

Vor dem Hinzufügen prüfen, ob bereits ein Case zur selben Untersuchung existiert und ob dieser bearbeitbar ist. Cases mit einem Closed-Status sind schreibgeschützt, ausgenommen Status und Archive; archivierte Cases erlauben nur Unarchive. Solche Cases zunächst als historischen Kontext verwenden, nicht als selbstverständlich bearbeitbares Ziel für neue Evidenz, Kommentare oder eine Neuzuweisung. Bei MDR-Cases hängen die verfügbaren Aktionen und die Optionen für Assignee auch davon ab, wer den Case verwaltet. Vor einer Änderung die tatsächlich verfügbaren Aktionen prüfen und fehlende Möglichkeiten mit dem zuständigen Bearbeiter klären.

Für die Übergabe sind Tabellenaktion und vollständige Detection-Details zu unterscheiden. Die offiziellen Anleitungen nennen für die Detailansicht nicht durchgehend dieselben Beschriftungen; es gibt deshalb keinen hier verlässlich belegten universellen Menüpfad für jede Ansicht:

Markierte Zeilen in der Detections-Tabelle: Die gewünschten Detections auswählen und Actions > Add to Case öffnen.
Vollständige Detection-Details: Die Detailanleitung nennt unter Actions die direkten Aktionen Add to Existing Case und Create New Case. Die Case-Anleitung beschreibt für einzelne Detections dagegen Actions > Add to Case mit anschliessender Auswahl von Existing Case oder New Case. Die tatsächlich angezeigte Aktion für einen bestehenden beziehungsweise neuen Case verwenden; nicht nach einer in dieser Ansicht fehlenden Beschriftung suchen.

Wenn der Dialog Add to Case angezeigt wird, gelten folgende Schritte:

Für einen vorhandenen Case Existing Case auswählen, den Case suchen und auswählen, dann mit Save to Existing Case speichern.
Für einen neuen Case New Case auswählen, Case Type, optional eine Vorlage, Titel, Case Severity und Case Status festlegen. Über das Stiftsymbol bei Key Findings erste Befunde und Kontext ergänzen, dann Create New Case wählen.

Bei einer Mehrfachauswahl darauf achten, ob nur die markierten Detections oder alle Detections aus der Tabelle hinzugefügt werden. Nicht ungeprüft eine ganze Ergebnisliste übernehmen. Bis die Evidenz im Case erscheint, können einige Minuten vergehen; danach den Ziel-Case öffnen und die tatsächliche Zuordnung kontrollieren.

Für MDR-Kunden benötigen die Case-Typen Investigation und Other zusätzlich Managed By. Diese Auswahl legt fest, wer den Case verwaltet, und kann nach dem Setzen nicht geändert werden. Sie wird vor dem Speichern mit der vorgesehenen Zuständigkeit abgeglichen. Eine spätere Änderung von Assignee ändert Managed By nicht.

In einem bearbeitbaren Case die kopierte Intelligence-URL und die konkret verwendeten Aussagen als Untersuchungskontext festhalten, beispielsweise in Key Findings oder, sofern verfügbar, als Kommentar auf der vollständigen Case-Detailseite über Comments > Comment > Save. Dabei Recherche und Tenant-Evidenz getrennt benennen: Was sagt der Bericht, was zeigen eigene Events und was bleibt eine Hypothese? Die URL allein konserviert nicht den Inhalt einer künftig aktualisierten Analyse; relevante Aussage und Zeitpunkt gehören deshalb in die Notiz.

Der bestehende Case- und Detection-Rule-Leitfaden beschreibt den klassischen Ablauf. Für Security Operations die oben erläuterten Beschriftungsvarianten und die im Tenant angezeigten Aktionen beachten. Der Explorer selbst ersetzt weder einen verantwortlichen Analysten noch die Entscheidung über Eindämmung oder Bereinigung.

Beispiel: einen Malware-Hinweis nachvollziehbar untersuchen

Angenommen, eine eigene Detection nennt eine Malware-Familie, die man noch nicht ausreichend kennt. Das folgende Beispiel behauptet keinen vorhandenen Treffer:

Den tatsächlichen Familiennamen suchen; Emotet ist nur ein Beispielwert. Nicht sofort zusätzlich eine Branche oder Gruppe wählen.
Beschreibung, technische Details und Schutzempfehlungen lesen. Unter Threat Report einen verfügbaren Bericht zum beobachteten Verhalten prüfen.
Unter Related Detections eigene Treffer suchen. Jeden relevanten Treffer gegen Gerät beziehungsweise Entität, Ereigniszeit und konkrete Events abgleichen. Unter Related Detectors nachvollziehen, welche Erkennungslogik zum Kontext gehört.
Wenn eine Gruppe genannt wird, ihre TTPs und Aktivitätszeitlinie vergleichen. Die Attribution als Einschätzung belassen, auch wenn einzelne Merkmale übereinstimmen.
Passende Detections einem vorhandenen oder neuen Case zuordnen. Im Case notieren: untersuchter Intelligence-Eintrag, Recherchezeitpunkt, Suchbegriffe und Filter, eigene Detection-Verweise, belegte Gemeinsamkeiten, offene Fragen und nächster Bearbeiter.

Ein nützliches Ergebnis kann auch sein, dass der Bericht nur eine allgemeine Ähnlichkeit liefert. Dann wird diese Grenze dokumentiert, statt daraus eine Kompromittierung oder einen bestimmten Angreifer abzuleiten.

Ergebnis prüfen und typische Sackgassen auflösen

Die Recherche ist nachvollziehbar, wenn ein anderer Analyst denselben Intelligence-Eintrag öffnen, die verwendeten Filter verstehen und jede Schlussfolgerung zu den eigenen Detection- und Event-Daten zurückverfolgen kann. Bei einer Case-Übergabe zusätzlich prüfen, dass die richtigen Detections im richtigen Case stehen und die nächste Aktion einem zuständigen Bearbeiter zugeordnet ist. Sofern der Case bearbeitbar ist und die Aktion verfügbar ist, lässt sich dieser in den vollständigen Case-Details unter Manage Case > Assignee auswählen.

Wenn die Ergebnisse nicht passen, helfen folgende Prüfungen:

Keine Suchtreffer: Schreibweise und bei Gruppen die Aliases prüfen. Zusatzfilter entfernen; mit dem X im Suchfeld die Suche samt Tabellenfiltern zurücksetzen und breiter neu beginnen. Eine leere Suche allein sagt nichts über das Risiko der Umgebung aus.
Zu viele Treffer: Ein fachlich passendes Merkmal ergänzen, etwa Type bei Malware oder Report Type und Threat Type bei Berichten. In Detections zusätzlich den Zeitraum eingrenzen. Die Detections-Tabelle ist auf 10'000 Ergebnisse begrenzt; aggregierte Filterergebnisse reichen höchstens bis 1'000. Eine breite Ansicht ist daher keine vollständige Bestandsaufnahme.
Bericht ohne erwartete IOCs oder Tabs: Die verfügbaren Inhalte hängen vom Bericht ab. Den vollständigen Text und vorhandene verwandte Intelligence lesen, ohne fehlende Inhalte oder eine bestimmte Abdeckung zu unterstellen.
Detektoren vorhanden, aber keine eigenen Treffer: Detector-Kontext und beobachtete Detection trennen. Zeitraum, Filter und die für die Untersuchung verfügbare Telemetrie prüfen. Nicht zum Test Malware ausführen oder Schutz abschalten.
Explorer nicht verfügbar: Zuerst XDR-/Enterprise-Lizenz und den verwendeten Tenant prüfen. Fehlt die neue Navigation, die Konsole auf Hinweise zur Umstellung kontrollieren; aus einem fehlenden Menü keinen technischen Produktfehler ableiten.
Case-Evidenz noch nicht sichtbar: Verarbeitung einige Minuten abwarten, danach Auswahl und Ziel-Case erneut kontrollieren. Nicht sofort einen zweiten Case erstellen.

Suche und Filter dienen hier nur der Recherche; für einen Neustart genügt das beschriebene Zurücksetzen. Das Hinzufügen von Evidenz oder Kommentaren und besonders die unveränderliche Wahl von Managed By sind dagegen Case-Änderungen. Es gibt dafür in diesem Runbook keinen pauschalen Rückgängig-Schritt. Falsche Zuordnungen werden mit dem zuständigen Case-Bearbeiter geklärt und dokumentiert. Cases nicht als Aufräumaktion schliessen: Ein Abschluss verändert auch die zugehörigen Detection-Bewertungen.

Für den laufenden Betrieb neue Malware-Einträge, Gruppenaktivitäten und Berichte regelmässig prüfen. Branchenfilter können den Lageüberblick fokussieren, sollten den allgemeinen Überblick aber ergänzen. Erkenntnisse gehören in den Incident-Response-Ablauf; Gruppen-TTPs eignen sich für Threat Modeling, Malware-Analysen für die Planung und Überprüfung eigener Schutzmassnahmen. Neue Intelligence ist Anlass für eine erneute Bewertung, kein automatischer Beleg für eine notwendige Konfigurationsänderung.