Iranische Bedrohungsakteure mit Ziel US-Infrastruktur identifizieren

Im Juli erfuhr ein Optiv-Mitarbeiter mithilfe von Intrace, dass sein privater Arbeitsrechner in Darknet-Daten auftauchte, die mit einer Malware-Gruppe namens „Water Black" in Verbindung stehen. Der Hostname seines Desktops war in Untergrund-Datenquellen beobachtet worden, die Intrace überwacht – ein Hinweis darauf, dass der Rechner nicht nur kompromittiert, sondern auch als hochwertiges Ziel markiert war. Diese Einstufung passte zu seiner Rolle: Er hatte zuvor die Incident-Response-Arbeit in einem großen Ransomware-Fall geleitet, was ihn zu einem attraktiven Ziel für Bedrohungsakteure machte, die an Vergeltung oder an Erkenntnissen über Verteidigungstechniken interessiert waren.

Darknet-Fund und Offenlegung des Hostnamens

Das Ausgangssignal der Untersuchung war einfach, aber gravierend: Intrace' Darknet-Monitoring entdeckte den Hostnamen des Desktop-Rechners des Beraters in Daten mit Bezug zu Water Black.

Ein Hostname ist die für Menschen lesbare Bezeichnung eines Rechners in einem Netzwerk (zum Beispiel JOHN-DESKTOP oder CORP-LAPTOP-01). Taucht ein Hostname in Material von Bedrohungsakteuren auf, bedeutet das in der Regel, dass die Angreifer zumindest ein gewisses Maß an Zugriff auf das Gerät oder seine Umgebung erlangt haben. Anders als bei generischen IP-Adressen oder anonymisierten Opferverweisen ist das Auftauchen eines konkreten Desktop-Hostnamens ein starker Indikator dafür, dass das Gerät selbst Teil einer Kampagne war – und nicht bloß der zufällige Treffer eines Internet-Scanners.

Infrastruktur-Verbindung

Bei der ersten Triage korrelierte Intrace den Water-Black-Verweis mit internetseitig erreichbarer Infrastruktur. Das Team identifizierte einen einzelnen Host im Internet mit dem Hostnamen waterblack, gehostet in einem Rechenzentrum in Wyoming, das einem iranisch kontrollierten Anbieter gehört. Zu diesem Zeitpunkt galt:

• Das Hosting-Unternehmen war RouterHosting, LLC, das sich später in Cloudsy umbenannte.
• Derselbe Anbieter war in offenen Berichten als Unterstützer mehrerer regierungsnaher Hackergruppen genannt worden – was die Wahrscheinlichkeit erhöhte, dass es sich nicht um beliebige Massen-Malware-Infrastruktur handelte, sondern um Teil eines organisierteren Operationsgeflechts.

Das ist wichtig, weil die Attribution von Infrastruktur ein Kernbestandteil der Analyse von Angriffen ist. Wenn ein Anbieter oder ein Rechenzentrum bereits mit staatsnahen Gruppen in Verbindung gebracht wurde und dort neue verdächtige Domains oder Server auftauchen, steigt die Zuversicht, dass man es mit einem fortgeschrittenen, möglicherweise regierungsnahen Bedrohungsakteur zu tun hat – und nicht mit rein opportunistischen Kriminellen.

DNS- und Verkehrsmuster

Auf dem Arbeitsrechner selbst untersuchte Intrace ausgehende Verbindungen und DNS-Auflösungsmuster. Über mehrere Wochen hinweg hatte sich der Rechner häufig mit neu registrierten, „geparkten" Domains verbunden. Viele dieser Domains lösten auf Infrastruktur bei demselben Hosting-Anbieter mit iranischem Eigentümerhintergrund auf.

Eine geparkte Domain ist ein registrierter Domainname, der nicht aktiv für eine echte Website genutzt wird. Typischerweise zeigt sie eine generische Platzhalterseite oder Werbung. Angreifer nutzen gern geparkte oder nahezu leere Domains, weil:

• sie günstig sind und sich leicht in großen Mengen registrieren lassen,
• sie bei oberflächlicher Prüfung weitgehend harmlos wirken,
• sie sich schnell auf neue Server umleiten lassen, um Sperren zu umgehen.

Das wiederkehrende Verbindungsmuster deutete auf Beaconing-Verhalten hin: Der kompromittierte Host kontaktiert regelmäßig die von den Angreifern kontrollierte Infrastruktur, um Anweisungen oder Updates zu erhalten. Das ist ein gängiges Design bei Command-and-Control-Malware (C2), bei dem der infizierte Rechner sich periodisch bei einem entfernten Server meldet, um Statusinformationen zu senden und Befehle zu empfangen.

Als sofortige Verteidigungsmaßnahme blockierte der Berater den Zugriff auf geparkte Domains auf Netzwerkebene. Das ist aus analytischer Sicht interessant, weil das Kappen des primären C2-Kanals die Malware oft dazu zwingt, Rückfallmechanismen, Fehlkonfigurationen oder Fehlerverhalten zu offenbaren – und genau das geschah als Nächstes.

Absturz von „MicrosoftSecurityApp.exe"

Innerhalb weniger Tage nach der Blockierung geparkter Domains stürzte auf dem Arbeitsrechner ein Prozess namens MicrosoftSecurityApp.exe ab.

Dieser Binärdateiname ist aus mehreren Gründen verdächtig:

• Er imitiert eine plausibel klingende Microsoft-Sicherheitskomponente, ohne einem bekannten, dokumentierten Produkt zu entsprechen.
• Malware verwendet häufig gefälschte oder irreführende Dateinamen, um sich unter legitime Systemprozesse zu mischen (zum Beispiel durch das Anhängen von „Microsoft", „Security", „Update" oder „Service" an den Namen).

Der Absturz unmittelbar nach der Blockierung ausgehender Verbindungen legt nahe, dass dieser Prozess entweder der Kern-Agent der Malware war, der vergeblich versuchte, seine C2-Domains zu erreichen, oder ein Loader beziehungsweise Watchdog, der auf erfolgreiche ausgehende Kommunikation angewiesen war und abstürzte, als diese abriss. Analytisch betrachtet ist das ein klassisches Beispiel für Verhalten unter Stress: Sobald C2 blockiert ist, kann fortgeschrittene Malware abstürzen, neu starten, auf Ausweichkanäle wechseln oder lokale Persistenzmechanismen aggressiver einsetzen.

Hinweise auf lokale Persistenz

Nach dem Absturz von MicrosoftSecurityApp.exe versuchte der Arbeitsrechner, die Game Bar zu starten – eine integrierte Windows-Komponente, die üblicherweise für Gaming-Overlays und Bildschirmaufnahmen verwendet wird. Der Berater hatte die Game Bar zuvor wegen verdächtigen Verhaltens deaktiviert, weshalb dieser Reaktivierungsversuch auffiel.

In der Windows-Registrierung wurde die Game Bar unter Einträgen referenziert, die mit AppX begannen. Andere AppX-Einträge verwiesen auf FTP und SSH.

AppX ist Microsofts Paketformat für moderne Windows-Store-Apps. Malware kann App-Container-Mechanismen, geplante Aufgaben oder AppX-Manifeste mitunter für Persistenz missbrauchen. FTP (File Transfer Protocol) und SSH (Secure Shell) sind Standardprotokolle: FTP dient der Dateiübertragung, oft im Klartext, SSH dient verschlüsselten Remote-Anmeldungen und Tunneln.

AppX-Einträge, die auf FTP und SSH verweisen, sind für einen privaten Arbeitsrechner, der nicht als Server fungieren soll, merkwürdig. Es deutet darauf hin, dass die Malware möglicherweise App-ähnliche Entitäten oder geplante Aufgaben registriert hat, die mit entfernten FTP-/SSH-Endpunkten interagieren, oder alternative Kanäle für Datenexfiltration oder Befehlsempfang eingerichtet hat – getrennt vom HTTP/HTTPS-C2 über die geparkten Domains.

Der Versuch, die Game Bar wieder zu aktivieren oder auszulösen, könnte auf einen Missbrauch ihrer Overlay- und Aufnahmefunktionen für Bildschirmaufzeichnung oder das Ausspähen des Nutzers hindeuten – oder auf die Nutzung einer legitimen Windows-Komponente im Rahmen einer Living-off-the-Land-Strategie, um den Einsatz offensichtlich bösartiger Binärdateien zu reduzieren.

Netzwerkartefakt: TCP 22 und eine Verbindung zu „GhostContainer"

In diesem Zeitraum beobachtete der Berater eine TCP-Verbindung auf Port 22 zur Adresse 52.98.240.82.

TCP-Port 22 wird nahezu universell mit SSH assoziiert. Die betreffende IP ist mit legitimer Infrastruktur verknüpft (zum Beispiel Cloud- oder SaaS-Anbietern), doch in Online-Diskussionen war sie mit etwas namens „GhostContainer" in Verbindung gebracht worden. GhostContainer ist eine von Sicherheitsforschern dokumentierte Backdoor, die auf Microsoft-Exchange-Server abzielt. Sie verschafft Angreifern dauerhaften Fernzugriff auf Exchange-Umgebungen, einschließlich der Möglichkeit, Befehle auszuführen und sich lateral zu bewegen.

Der Rechner des Beraters war zwar kein Exchange-Server. Doch die Tatsache, dass SSH-artiges Verhalten auf TCP 22 zu einer Adresse mit GhostContainer-Bezug auftrat und der Host zuvor Beaconing zu verdächtigen Domains mit Verbindung zu staatsnaher Infrastruktur gezeigt hatte, legt nahe, dass der Arbeitsrechner Teil eines umfassenderen Werkzeugkastens derselben Akteure gewesen sein könnte, die GhostContainer andernorts einsetzen – oder als Sprungbrett beziehungsweise Beobachtungsknoten diente, um Exchange-seitige Operationen von einem vertrauenswürdigen Endpunkt aus zu überwachen oder zu steuern.

Das passt zum Muster der Kompromittierung eines hochwertigen Ziels: Statt nur Dateien zu stehlen, wollten die Angreifer möglicherweise einen vertrauenswürdigen Rechner in der Umgebung, den sie zum Pivotieren nutzen, mit dem sie Incident-Response-Maßnahmen beobachten oder über den sie sich Zugriff erhalten konnten, selbst während die Unternehmenssysteme gehärtet wurden.

Versuchte Installation eines bösartigen Root-Zertifikats

Der Berater erinnerte sich außerdem an einen Versuch, eine bösartige Root-Zertifizierungsstelle (Root CA) zu installieren.

Das ist ein entscheidendes Detail. Ein Root-CA-Zertifikat ist einer der Vertrauensanker, anhand derer Betriebssysteme und Browser entscheiden, ob eine verschlüsselte Verbindung (zum Beispiel HTTPS) vertrauenswürdig ist. Gelingt es einem Angreifer, ein eigenes bösartiges Root-Zertifikat auf einem System zu installieren, kann er:

• ansonsten sicheren TLS-Verkehr abfangen und entschlüsseln (zum Beispiel Webmail, Dashboards, Admin-Portale),
• gefälschte Zertifikate für beliebige Domains vorlegen (zum Beispiel outlook.com, vpn.company.com), die dem kompromittierten System als gültig erscheinen.

In der Praxis würde das den Angreifern erlauben, Man-in-the-Middle-Angriffe (MITM) auf die Verbindungen des Opfers durchzuführen, ohne Zertifikatswarnungen auszulösen, und sensible Kommunikation zu lesen oder zu verändern – einschließlich Incident-Response-E-Mail-Verläufen, Ticketsystemen und anderem vertraulichem Austausch. Der Versuch, eine Root CA zu installieren, ist ein starker Indikator für die Absicht, sich dauerhaft festzusetzen und zu überwachen – nicht für schnelles Zugreifen-und-Verschwinden.

Warum diese Person ins Visier geriet

Das Opfer wurde nicht zufällig ausgewählt. Intrace' Auswertung der Darknet-Verweise und des Kontexts ergab, dass er ausdrücklich als hochwertiges Ziel eingestuft war. Dieser Status rührte höchstwahrscheinlich von seiner früheren Incident-Response-Arbeit in einem großen Ransomware-Fall her.

Aus Angreifersicht liefert die Kompromittierung einer Person mit tiefem Einblick in Verteidigungsmaßnahmen und Reaktionsprozesse Erkenntnisse darüber, wie Verteidiger bestimmte Angriffe erkennen und darauf reagieren, potenzielle Druckmittel oder Vergeltungsmöglichkeiten gegenüber jemandem, der ihre Operationen zuvor gestört hat, sowie Zugang zu wertvollen Kontaktnetzwerken und Dokumentationen – selbst wenn diese primär auf Unternehmenssystemen liegen, denn der private Arbeitsrechner wird oft als Nebenkanal genutzt.

Diese Kombination aus gezielter persönlicher Ansprache, mit dem Iran verbundener Infrastruktur, Beaconing über geparkte Domains, versuchter Installation bösartiger Root-Zertifikate und Backdoor-artigem Verhalten spricht für einen gezielten, mehrstufigen Angriff – nicht für zufällige Drive-by-Malware.

Wie Intrace die Untersuchung strukturierte

Aus Sicht von Intrace folgte die Untersuchung einer klaren Struktur:

Signalaufnahme aus dem Darknet

• Den Hostnamen und die Einstufung als hochwertiges Ziel in Daten mit Water-Black-Bezug erkennen.
• Bestätigen, dass der referenzierte Host einem Optiv-Berater gehört.

Infrastruktur-Korrelation

• Den waterblack-Host im iranisch kontrollierten Rechenzentrum in Wyoming ausfindig machen.
• Zugehörige geparkte Domains kartieren, die auf denselben Anbieter auflösen.
• Mit früheren Berichten über die Verwicklung des Hosting-Unternehmens mit regierungsnahen Gruppen abgleichen.

Host-Telemetrie und Verhalten

• Ausgehende Verbindungen zu geparkten Domains über mehrere Wochen untersuchen.
• MicrosoftSecurityApp.exe als verdächtigen Prozess identifizieren und sein Verhalten rund um den Zeitpunkt der Netzwerkblockierung analysieren.
• Registrierungseinträge prüfen, einschließlich AppX-Verweisen auf Game Bar, FTP und SSH.

Netzwerkartefakte und Verbindungen zu externen Werkzeugen

• TCP-22-Verkehr zu 52.98.240.82 und dessen Erwähnung in Diskussionen über GhostContainer festhalten.
• Bewerten, ob das beobachtete Verhalten in ein Backdoor- oder Lateral-Movement-Muster passt.

Integrität von Vertrauensketten und Kryptografie

• Die versuchte Installation einer bösartigen Root CA untersuchen.
• Das Risiko einer fortlaufenden Abhörung verschlüsselten Verkehrs bewerten.

Empfehlungen zur Eindämmung und Härtung

• Den Arbeitsrechner von sensiblen Umgebungen isolieren.
• Verdächtige Binärdateien und Registrierungseinträge entfernen.
• Zugangsdaten zurücksetzen und die Multi-Faktor-Authentifizierung stärken.
• Strikte DNS- und Egress-Kontrollen durchsetzen, mit Monitoring auf neue geparkte Domains und verdächtigen SSH-Verkehr.
• Die vertrauenswürdigen Zertifikate auf dem Rechner prüfen und alle nicht autorisierten CAs widerrufen.

Ergebnis

Durch die Kombination von Darknet-Intelligence, Infrastrukturanalyse, Host-Forensik und sorgfältiger Interpretation von Netzwerkartefakten konnte Intrace den Kompromittierungspfad rekonstruieren und klären, wie ein Optiv-Berater zum gezielten Opfer iranisch verknüpfter Bedrohungsaktivitäten wurde. Der Fall verdeutlichte:

• Private Geräte von Sicherheitsexperten können zu strategischen Zielen werden.
• Geparkte Domains und obskure Hosting-Anbieter können als unauffällige C2-Infrastruktur dienen.
• Versuche, bösartige Root-Zertifikate zu installieren und integrierte Windows-Komponenten wie die Game Bar auszunutzen, passen zu langfristigen, verdeckten Zugriffszielen – nicht zu bloßem Rauschen.

Optiv nutzte diese Erkenntnisse, um den Vorfall einzudämmen, die Umgebung des Beraters zu härten und die Erkennungslogik anzupassen, um bei anderen Endpunkten und Kunden nach ähnlichen Mustern zu suchen.