Die Sicherstellung der Werkzeuge Microscan und FishHub durch US-Behörden am 8. Oktober 2026 und die begleitende internationale Advisory liefern Organisationen einen konkreten Anlass für eine fokussierte Kompromissprüfung. Im Mittelpunkt sollte dabei nicht die eigene Bewertung einer Akteurszuschreibung stehen. Entscheidend ist die operative Frage, ob die in der Advisory beschriebenen Angriffswege, Infrastrukturindikatoren und Verhaltensmuster im eigenen Bestand Spuren hinterlassen haben könnten.
Ein IOC-Abgleich allein genügt dafür nicht. Die beschriebenen Aktivitäten verbinden Internet-Scanning, die Ausnutzung auch älterer Schwachstellen, Passwort-Spraying gegen Exchange- und Microsoft-365-nahe Schnittstellen, E-Mail-Sammlung und Persistenz über SoftEther-VPN. Daraus lässt sich ein zeitlich begrenzter, dokumentierter Hunt-Auftrag ableiten, der Exposition, Telemetrie und Identitäten zusammenführt.
Warum die Warnung ein Prüfauftrag ist
Nach Angaben des US-Justizministeriums wurden Microscan und FishHub für Schwachstellenscans, Spear-Phishing, das Nachladen von Malware und unbefugten Fernzugriff genutzt. Die gemeinsame Advisory von FBI, CISA, NSA und NCSC-UK ordnet die beschriebenen Taktiken, Techniken und Verfahren unter anderem Aktivitäten zu, die öffentlich als Flax Typhoon, Ethereal Panda oder Red Juliett bezeichnet werden. Zugleich weist sie darauf hin, dass solche industriellen Akteursbezeichnungen nicht zwingend eins zu eins der Erkenntnislage der US-Regierung entsprechen.
Für den eigenen Hunt ist diese Differenzierung wesentlich: Ein Unternehmen muss weder Attribution bestätigen noch jeden technischen Einzelindikator zwingend auf denselben Akteur zurückführen. Es sollte stattdessen belastbar beantworten können, welche relevanten Systeme historisch oder aktuell exponiert waren, welche Daten zur Rückschau vorliegen, welche Befunde validiert wurden und welche Restunsicherheit bleibt.
Der Prüfauftrag sollte einen Stichtag, den Scope, Untersuchungshypothesen, Datenquellen, Verantwortliche und einen Evidenzstandard festlegen. So wird aus einer externen Warnung eine nachvollziehbare Risikobehandlung statt einer punktuellen Suche ohne Abschlusskriterien.
Schritt 1: Exposition rückblickend und aktuell auflösen
Die Advisory beschreibt Reconnaissance gegen die Ports 21, 22, 53, 80, 443 und 1080 sowie die erfolgreiche Ausnutzung von CVE-2014-6278, CVE-2015-3306, CVE-2015-5477, CVE-2016-3081, CVE-2019-11510, CVE-2021-22205, CVE-2021-3199 und CVE-2023-22894. Gerade weil mehrere dieser Schwachstellen lange bekannt sind, ist nicht nur der heutige Patch-Status relevant. Entscheidend ist, ob ein betroffener Dienst in der Vergangenheit erreichbar war und ob die Zeit bis zur Behebung mit ausreichender Telemetrie abgedeckt ist.
Vulnerability Management, Infrastrukturteams und Asset Owner sollten dafür eine priorisierte Prüfliste bilden. Je Asset sind mindestens Internet-Erreichbarkeit, betroffene Version, Patch- oder Abschaltzeitpunkt, verantwortliche Stelle, Log-Abdeckung sowie Daten- und Privilegienreichweite festzuhalten. Besonders prioritär sind Systeme mit administrativen Funktionen, Fernzugängen, E-Mail-Anbindung oder Zugang zu kritischen Geschäftsprozessen.
Fehlen historische Web-, Firewall- oder Endpoint-Daten, ist das kein Beweis gegen eine Kompromittierung. Es ist eine dokumentationswürdige Untersuchungsgrenze. Diese Lücke beeinflusst die Bewertung des Restrisikos und gegebenenfalls die Entscheidung über weitergehende Kontrollen.
Schritt 2: IOCs und Verhalten in der Telemetrie korrelieren
Die vollständigen STIX-Indikatoren aus der Advisory können mit DNS-, Proxy-, Firewall-, EDR- und Webserver-Daten korreliert werden. Dazu gehören veröffentlichte Domains, IP-Adressen, Dateinamen und Hashes. Ein Treffer muss jedoch validiert werden: Kontext, Zeitpunkt, betroffener Host, Prozessbeziehung, Netzwerkverkehr und weitere Spuren entscheiden darüber, ob ein Indikator eine harmlose Überschneidung, einen Untersuchungsansatz oder einen belastbaren Kompromisshinweis darstellt.
Besondere Aufmerksamkeit verdient das beschriebene Persistenzmuster. Die Advisory nennt SoftEther-VPN-Clients, die unter anderem über PowerShell, andere Living-off-the-Land-Binaries, curl oder wget installiert wurden. Teilweise wurden sie als conhost.exe oder dllhost.exe benannt und für eine automatische Wiederverbindung beim Systemstart konfiguriert. Softwareinventar und EDR-Daten sollten SoftEther daher gegen einen genehmigten Bestand abgleichen. Eine nicht autorisierte Installation, eine tarnende Benennung, ungewöhnliche Startmechanismen oder ein Bezug zu veröffentlichten Infrastrukturindikatoren sind starke Gründe für eine Incident-Eskalation.
Schritt 3: Exchange, Microsoft 365 und privilegierte Zugänge prüfen
Für Exchange- und cloudnahe E-Mail-Umgebungen beschreibt die Advisory EBurst für Passwort-Spraying und Passwort-Raten über ECP, EWS, OAB, OWA, RPC, API, MAPI, PowerShell, Autodiscover und Microsoft-Server-ActiveSync. Zudem wurde ein PHP-Skript beobachtet, das über die Microsoft-EWS-API E-Mails, Kalender- und Kontakteinträge sammelte.
Der Hunt sollte daher fehlgeschlagene und erfolgreiche Anmeldungen gemeinsam auswerten. Relevante Muster sind Fehlerserien mit anschließender erfolgreicher Anmeldung, atypische Quellnetze, Zugriffe auf privilegierte Konten sowie auffällige EWS-Aktivitäten. Für verdächtige erfolgreiche Anmeldungen sind Sitzungen, betroffene Postfächer, Zugriffswege und nachfolgende Aktionen einzugrenzen. Administrative Berechtigungen verdienen besondere Aufmerksamkeit, weil kompromittierte privilegierte Konten den Untersuchungsumfang und die möglichen Wiederherstellungsmaßnahmen erheblich erweitern können.
Die Advisory empfiehlt zudem MFA insbesondere für Webmail, VPN und Konten mit Zugriff auf kritische Systeme sowie die Prüfung administrativer Berechtigungen. Im Hunt-Kontext sind diese Empfehlungen keine rückwirkenden Kompromissnachweise, aber sie helfen, festgestellte Exposition zu reduzieren und Prioritäten für Sofortmaßnahmen zu setzen.
OAuth und Enterprise Applications: ergänzender Identity-Workstream
OAuth- oder Enterprise-Application-Berechtigungen sind in der Advisory nicht als bestätigter Initialzugang oder Kampagnenindikator benannt. Ihre Prüfung ist deshalb sauber als ergänzende, risikoorientierte Cloud-Identity-Maßnahme zu behandeln, nicht als behaupteter Flax-Typhoon-Nachweis.
Microsoft Entra protokolliert Berechtigungs- und Consent-Vorgänge für Enterprise Applications. Untersuchungsrelevant sind insbesondere die Aktivitäten Add app role assignment to service principal, Add delegated permission grant und Consent to application. Neue oder unerwartete App-Consents, weitreichende Mail- oder „.All“-Berechtigungen, hinzugefügte Secrets oder Zertifikate, Rollen- und Owner-Änderungen sowie neue Redirect-URIs sollten gegen genehmigte Changes abgeglichen werden. Dadurch lässt sich klären, ob Anwendungen Zugriff auf sensible E-Mail- oder Dateidaten erhalten haben, ohne einen nicht belegten Kampagnenzusammenhang zu behaupten.
Wann ein Befund in Incident Response übergeht
Eskalationsschwellen sollten vor Beginn der Untersuchung vereinbart sein. Ein isolierter IOC-Treffer ist nicht automatisch ein bestätigter Sicherheitsvorfall. Ein validierter Kampagnenindikator zusammen mit passender Endpoint-, Netzwerk- oder Identity-Telemetrie rechtfertigt dagegen regelmäßig eine vertiefte Incident-Response-Behandlung. Gleiches gilt für unautorisierte SoftEther-Persistenz, bestätigten EWS-Mailzugriff, erfolgreiche Anmeldungen nach Passwort-Spraying oder Hinweise auf Credential-Dumping beziehungsweise unerwartete AD-Replikation.
Mögliche Sofortmaßnahmen sind die Isolation betroffener Systeme, Beweissicherung, der Widerruf aktiver Sitzungen, Credential-Rotation und die Prüfung lateraler Bewegung. Ihre Reihenfolge muss forensische Erfordernisse und Betriebsfolgen abwägen. Das Incident-Team sollte Scope, Entscheidungen, Belege und offene Fragen fortlaufend dokumentieren, damit Wiederherstellungs- und Kommunikationsentscheidungen nachvollziehbar bleiben.
BSIG, KRITIS und Management-Berichterstattung
Die US-Warnung begründet für deutsche Organisationen keine eigenständige Pflicht zu einem Threat Hunt. Für nach BSIG erfasste besonders wichtige und wichtige Einrichtungen verlangt § 30 BSIG jedoch dokumentierte, geeignete, verhältnismäßige und wirksame Risikomanagementmaßnahmen. Dazu gehören unter anderem Incident-Bewältigung, Wiederherstellung und Krisenmanagement, Schwachstellenmanagement, Zugriffskontrolle sowie MFA oder kontinuierliche Authentifizierung. Betreiber kritischer Anlagen müssen für maßgebliche Systeme zudem Angriffserkennung einsetzen. Das Hunt-Protokoll kann damit ein relevantes Nachweisartefakt für risikobasiertes Handeln sein.
Eine Advisory oder ein einzelner IOC-Treffer löst keine Meldung aus. Liegt ein erheblicher Sicherheitsvorfall im Sinne von § 32 BSIG vor, müssen erfasste Einrichtungen die Meldepflichten gesondert bewerten; das Gesetz nennt insbesondere eine frühe Erstmeldung binnen 24 Stunden und eine aktualisierte Meldung binnen 72 Stunden nach Kenntniserlangung. Die konkrete Einrichtungsart, Betroffenheit und Erheblichkeit sind im Einzelfall zu prüfen. Geschäftsleitungen erfasster Einrichtungen müssen die erforderlichen Risikomanagementmaßnahmen umsetzen und überwachen.
Ein entscheidungsfähiger Management-Bericht beginnt nicht mit Akteursnamen. Er zeigt relevante Assets und Datenklassen, historische und aktuelle Exposition, verfügbare Telemetrie und Lücken, validierte Befunde, eingeleitete Eindämmung, Auswirkungen auf Betrieb und Wiederherstellung sowie offene Restrisiken. Damit erhält die Geschäftsleitung eine belastbare Grundlage für Priorisierungen, Ressourcenentscheidungen und gegebenenfalls regulatorische Bewertungen.