Vom Scan zur manuellen Intrusion

Ein Internet-Scan ist weder automatisch harmloses Hintergrundrauschen noch ein belastbarer Beleg für eine Kompromittierung. Die internationale Warnung zu Integrity Technology Group verdeutlicht jedoch, warum diese Einordnung nicht isoliert erfolgen sollte: Behörden beschreiben ein Vorgehen, das automatisierte beziehungsweise KI-gestützte Scans, großflächige Botnets und manuelle Exploitation-Techniken zur Kompromittierung von Netzen und zum Diebstahl vertraulicher Daten verbindet. Betroffen sein können ausdrücklich auch kritische Sektoren.

Der operative Schwerpunkt liegt deshalb nicht auf einer punktuellen IOC-Suche oder einer zeitlich begrenzten Kompromittierungsprüfung. Erforderlich ist ein dauerhaftes Modell, das die Entwicklung von externer Aufklärung über ausnutzbares Exposure bis zu möglichen manuellen Folgeaktivitäten sichtbar macht. Dafür müssen Attack-Surface-Management, Vulnerability Management, Infrastruktur, SOC und Incident Response mit gemeinsamen Daten und klaren Übergabekriterien arbeiten.

Was die Warnung belegt – und was sie nicht belegt

Das NCSC-UK beschreibt die bereitgestellten Fähigkeiten als Kombination automatisierter Scans, Botnet-Nutzung und manueller Ausnutzung. Die gemeinsame Advisory stellt laut NSA TTPs und Kompromittierungsindikatoren bereit, die Organisationen für Threat Hunting sowie veröffentlichte Detektions- und Minderungsmaßnahmen nutzen sollen.

Am 8. Oktober 2026 teilte das US-Justizministerium mit, dass die Werkzeuge beziehungsweise zugehörigen Domains Microscan und FishHub gerichtlich beschlagnahmt worden seien. Nach den offengelegten Unterlagen wurde Microscan für Schwachstellenscans eingesetzt. FishHub soll Spearphishing-gestützte Folgeaktivitäten und das Nachladen weiterer Schadsoftware ermöglicht haben. Die Affidavit beschreibt zudem ein Mirai-basiertes IoT-Botnet, das Microscan-Scans ausführte und deren Ursprung teilweise verschleiern sollte.

Diese Sachverhalte sind sorgfältig zu differenzieren. Die Zuordnung und technische Darstellung in der Affidavit sind Feststellungen beziehungsweise Einschätzungen eines Ermittlungs- und Beschlagnahmeverfahrens, kein gerichtliches Endurteil. Für zwei taiwanische Hochschulen dokumentiert sie jeweils einen Microscan-Scan und eine anschließende Kompromittierung. Daraus folgt aber gerade nicht, dass jedes gescannte Ziel kompromittiert wurde. Für die Verteidigung ist dies ein wesentlicher Unterschied: Scan-Aktivität ist ein Risiko- und Untersuchungssignal; eine bestätigte Intrusion benötigt zusätzliche technische Evidenz.

Wann Scan-Rauschen zum Exposure-Fall wird

Die Priorisierung sollte nicht allein auf Quell-IP-Adressen oder einzelnen Signaturen beruhen. Botnet-gestützte Scans können aus verteilten Quellen erfolgen; zudem verlieren statische Domains nach einer Beschlagnahme möglicherweise an unmittelbarem Blocking-Wert. Ihr Wert für retrospektive Log-Suche, Scoping und Fallkorrelation bleibt dennoch bestehen.

Ein risikobasiertes Triage-Modell kann Scan-Ereignisse anhand mehrerer Faktoren bewerten:

Asset- und Dienstkritikalität: Ist das Ziel öffentlich erreichbar, geschäftlich oder für kritische Dienste relevant und einem verantwortlichen Eigentümer zugeordnet?
Technisches Exposure: Besteht ein betroffener Dienst, eine bekannte Schwachstellenlage oder ein fehlender Patch- beziehungsweise Mitigationsstatus?
Scan-Charakteristik: Deuten Wiederholung, Zielauswahl, ungewöhnliche Anfragemuster oder verteilte Quellnetze auf zielgerichtete Aufklärung hin?
Kontextbezug: Gibt es eine Übereinstimmung mit veröffentlichten TTPs oder Indikatoren?
Folgesignale: Treten anschließend Auffälligkeiten bei Authentisierung, E-Mail, Endpoints, DNS, Proxy oder Datenabfluss auf?

Damit wird aus einem isolierten Perimeter-Ereignis ein nachvollziehbarer Exposure-Fall. Attack-Surface-Management und Vulnerability Management benötigen hierfür eine gemeinsame aktuelle Sicht auf internetexponierte Assets, Dienste, Eigentümer, Kritikalität sowie Patch- und Mitigationsstatus. Ohne diese Zuordnung kann ein SOC zwar auffällige Zugriffe sehen, aber kaum belastbar bewerten, ob ein realistischer Ausnutzungspfad besteht.

Telemetrie für den Übergang zu manuellen Aktivitäten

Die relevante Angriffskette endet nicht am Perimeter. Die in den Unterlagen zu FishHub beschriebenen Funktionen – Erstellen von Dateilisten, Suche nach bestimmten Dateien, Komprimieren von Dokumenten und Übertragung ausgewählter Dateien an kontrollierte Server – zeigen, welche nachgelagerten Artefakte überprüft werden sollten. Die konkrete technische Umsetzung kann variieren; die Korrelation sollte daher auf Verhaltensketten statt nur auf einzelne Indikatoren zielen.

Zentral auswertbar sein sollten insbesondere WAF-, Reverse-Proxy-, VPN-, Firewall- und DNS-Logs sowie Webserver- und Authentisierungsereignisse. Hinzu kommen E-Mail-Gateway- und M365- oder vergleichbare SaaS-Auditdaten, EDR-Telemetrie, Proxy- und NetFlow-Daten sowie Cloud-Control-Plane- und IAM-Logs. Die Aufbewahrungsdauer ist risikobasiert festzulegen und mit Datenschutz, Betriebsvereinbarungen sowie gegebenenfalls sektorspezifischen Anforderungen abzustimmen.

Eine belastbare Korrelation kann beispielsweise mit einem auffälligen Scan auf ein exponiertes, potenziell verwundbares System beginnen. Höhere Priorität entsteht, wenn danach ungewöhnliche Authentisierungsversuche oder erfolgreiche Logins, auffällige Prozesse, Remote-Management-Software, Persistenzmechanismen oder Verbindungen zu veröffentlichten Indikatoren folgen. Verdächtige Archivierung und ungewöhnliche Egress-Aktivität können die Untersuchung weiter verdichten. Kein einzelnes Glied dieser Kette trägt regelmäßig eine belastbare Attribution. Mehrere zeitlich und technisch zusammenpassende Signale rechtfertigen jedoch eine technische Untersuchung und gegebenenfalls Incident Response.

Threat Hunting als überprüfbare Hypothese

Threat Hunting sollte die veröffentlichten TTPs in überprüfbare Hypothesen übersetzen, nicht lediglich eine Liste von Domains blockieren. Jede Hypothese braucht eine erwartete Aktivitätskette, passende Datenquellen, definierte Ausschlusskriterien und einen Eskalationsweg. Eine geeignete Hypothese lautet etwa: Ein nach außen exponiertes Asset mit offenem Patch- oder Mitigationsbedarf wurde zielgerichtet gescannt; danach zeigen sich Zugriffs-, Authentisierungs- oder Endpoint-Anomalien, die mit Discovery, Persistenz oder Datenabfluss vereinbar sind.

Für die Spearphishing-bezogene Komponente sind E-Mail-, DNS-, Proxy- und Endpoint-Daten besonders wichtig. Gesucht werden können Verbindungen zwischen verdächtigen Nachrichten, nachgelagerten Downloads, Prozessausführungen, Dateioperationen und ausgehenden Verbindungen. Dabei sind bekannte, legitime Betriebsabläufe ausdrücklich als Ausschlusskriterien zu berücksichtigen. Der Zweck ist eine nachvollziehbare Verifikation oder Widerlegung, keine voreilige Zuschreibung.

Veröffentlichte Indikatoren sollten in SIEM, EDR, DNS-Schutz, E-Mail-Sicherheit und Network Detection aufgenommen werden. Erforderlich sind jedoch Qualitätsbewertung, Ablaufdatum und ein geregelter Change-Prozess. So bleibt nachvollziehbar, welche Indikatoren aktiv überwacht werden, welche nur retrospektiv relevant sind und wann Regeln überprüft oder entfernt werden müssen.

Übergaben und Eskalation verbindlich gestalten

Ein wirksames Modell braucht definierte Entscheidungen an den Schnittstellen. Infrastruktur und Vulnerability Management verantworten die belastbare Zuordnung von Asset, Dienst, Exposure und Abhilfemaßnahme. Das SOC korreliert die Sicherheitsereignisse und bewertet die technische Evidenz. Incident Response übernimmt, wenn Umfang, Beweissicherung, Containment oder forensische Analyse über die Routinebearbeitung hinausgehen.

Eine unmittelbare Übergabe an SOC und Incident Response liegt insbesondere nahe, wenn ein aktives Exposure mit zielgerichteten Scans korreliert, Exploit- oder Authentisierungsindikatoren auftreten oder Endpoint-, E-Mail- und Egress-Signale eine zusammenhängende Aktivitätskette erkennen lassen. Parallel sollten technische Sofortmaßnahmen, etwa das Deaktivieren nicht benötigter Dienste und Ports sowie die Absicherung von Web-Eingaben gegen XSS, anhand der eigenen Umgebung geprüft werden. Die kanadische Cyberbehörde nennt zudem Identity-, Credential- und Access-Management mit MFA, soweit möglich, als unmittelbare Schutzmaßnahme.

NIS2, KRITIS und Krisenentscheidungen

Die behördliche Warnung ist keine Rechtsnorm und begründet für sich genommen keine Meldepflicht. Sie ist aber relevante Threat Intelligence für Detection, Incident Handling, Nachweisführung und Eskalationsprozesse. Nach den Angaben des BSI ist das NIS-2-Umsetzungsgesetz seit dem 6. Dezember 2025 in Kraft. Das BSIG sieht für besonders wichtige und wichtige Einrichtungen bei erheblichen Sicherheitsvorfällen eine frühe Erstmeldung spätestens binnen 24 Stunden, eine Meldung spätestens binnen 72 Stunden mit erster Bewertung und gegebenenfalls Kompromittierungsindikatoren sowie grundsätzlich eine Abschlussmeldung binnen eines Monats vor.

Für Betreiber kritischer Anlagen kommen bei meldepflichtigen erheblichen Sicherheitsvorfällen Angaben zur betroffenen Anlage, kritischen Dienstleistung und möglichen Auswirkungen hinzu. Die Meldeschwelle richtet sich somit nach dem konkreten Sicherheitsvorfall und dessen Erheblichkeit, nicht nach dem Vorliegen eines Scans. Für besonders schutzbedürftige Organisationen sollte die technische Eskalation dennoch früh mit der Krisenführung verbunden werden: Beweissicherung, Bewertung von Abhängigkeiten und Auswirkungen auf kritische Dienste, Entscheidungen zu Containment-Maßnahmen sowie vorbereitete Kommunikations- und Meldewege gehören in dasselbe Entscheidungsmodell.

Operativer Mindestplan für die nächsten Prüfzyklen

Internetexponierte Assets, Dienste, Eigentümer und Patch- oder Mitigationsstatus konsolidieren.
Veröffentlichte Indikatoren retrospektiv in verfügbaren Logs suchen und ihre laufende Überwachung mit Qualitäts- und Ablaufregeln versehen.
Telemetrie-Lücken zwischen Perimeter, Identität, E-Mail, Endpoint, Netzwerk und Cloud dokumentieren und priorisiert schließen.
Hunting-Hypothesen als Ketten aus Scan, Exposure, Zugriff, Persistenz, Discovery und Egress testen.
Übergabekriterien zwischen Infrastruktur, Vulnerability Management, SOC, Incident Response und Management in einem Playbook festlegen und üben.

Der entscheidende Reifegrad entsteht nicht durch die Annahme, jeder Scan sei ein Incident. Er entsteht durch die Fähigkeit, risikoreiche externe Aufklärung schnell mit dem tatsächlichen Exposure und nachgelagerten Verhaltenssignalen zu verbinden. So wird aus breit gestreuter Threat Intelligence eine belastbare Grundlage für technische Priorisierung, Krisenentscheidungen und – sofern ein erheblicher Sicherheitsvorfall vorliegt – regulatorische Prozesse.