MuddyWater, eine mit dem iranischen Staat verbundene Gruppierung, hat begonnen, gezielte Spionage- und Sabotageoperationen unter dem „Label“ der Erpresser Chaos durchzuführen. Dabei nutzt sie Microsoft Teams für hochgradig interaktives Social Engineering, den Diebstahl von Zugangsdaten und die Umgehung von Multi-Faktor-Authentifizierung, verzichtet aber auf Verschlüsselung und konzentriert sich stattdessen auf verdeckte Persistenz und Datenabfluss. Dies betrifft unmittelbar Organisationen in den USA und im Nahen Osten und erfordert ein Umdenken im Umgang mit Vorfällen, die wie „gewöhnliche“ Ransomware-Angriffe aussehen, in Wirklichkeit aber strategische Ziele Irans verfolgen können.

Technische Details der MuddyWater-Kampagne unter dem Chaos-Brand

Im von Rapid7 untersuchten Vorfall (Anfang 2026) imitiert MuddyWater die Handschrift der RaaS‑Gruppe Chaos, ändert jedoch das zentrale Ziel: Statt Verschlüsselung stehen Spionageaktivitäten und eine feste Verankerung in der Infrastruktur im Vordergrund.

Erstzugriff: Microsoft Teams als Kanal für hochgradig interaktives Social Engineering

• Der Angriff beginnt mit externen Chats in Microsoft Teams: Die Angreifer kontaktieren Mitarbeiter direkt und geben sich häufig als IT‑Support aus.
• Es wird interaktives screen sharing genutzt: Der Operator „nimmt das Opfer buchstäblich an die Hand“, zeigt, wohin geklickt und was eingegeben werden soll.
• Während der Session:
  • werden grundlegende Befehle zur Umfeldaufklärung ausgeführt;
  • werden Dateien mit VPN‑Konfigurationen geöffnet;
  • werden Nutzer gebeten, Login/Passwort in lokal erstellte Textdateien einzugeben.
• Mithilfe der erlangten Zugangsdaten umgehen die Angreifer MFA, indem sie den Benutzer während des Authentifizierungsvorgangs gezielt manipulieren.

Nach der Terminologie von MITRE ATT&CK T1566 (Phishing) handelt es sich hierbei nicht um eine klassische E‑Mail‑Phishing‑Kampagne, sondern um eine gefährlichere Variante direkter sozialer Manipulation im Unternehmens‑Messenger. Dort ist für den Mitarbeiter die Grenze zwischen legitimer „Support“-Instanz und Angreifer praktisch verwischt.

Persistenz und laterale Bewegung: Fokus auf legitime Remote-Management-Werkzeuge

• Für Persistenz werden DWAgent und AnyDesk sowie eingebaute Funktionen wie RDP eingesetzt.
• Mindestens in einem Fall wird AnyDesk direkt während der screen‑sharing‑Session installiert.
• Über RDP startet der Angreifer curl, um die ausführbare Datei ms_upd.exe von einem externen Server 172.86.126[.]208 herunterzuladen.
• Diese Binärdatei stößt eine mehrstufige Infektionskette an und installiert eine RAT:
  • dauerhafte Verbindung mit dem C2;
  • Abfrage des C2‑Servers alle 60 Sekunden;
  • Ausführung von Systembefehlen und PowerShell‑Skripten;
  • Dateioperationen;
  • interaktive cmd.exe‑ oder PowerShell‑Shell auf Anforderung des Operators.

Eine solche Taktik fügt sich gut in T1078 (Valid Accounts) und T1105 (Ingress Tool Transfer) ein: Der Angreifer bricht das System nicht „mit roher Gewalt“ auf, sondern lebt innerhalb der Infrastruktur unter der Identität eines legitimen Benutzers und mit legitimen Werkzeugen.

Scheinbare Ransomware-Artefakte und die Rolle des Zertifikats

• In der Infrastruktur des Opfers werden Artefakte festgestellt, die mit Chaos ransomware (Brand, Erpressungsmethoden) in Verbindung stehen, jedoch:
  • findet keine Verschlüsselung von Dateien statt;
  • liegt der Schwerpunkt auf Datenexfiltration und dem Aufbau eines langfristigen Zugangs;
  • werden „Lösegeldverhandlungen“ per E‑Mail geführt.
• Ein kritisches Attributionsmerkmal ist die Verwendung eines Code‑Signing‑Zertifikats mit dem Subjekt „Donald Gay“ zur Signierung von ms_upd.exe.
• Dasselbe Zertifikat wurde zuvor im MuddyWater‑Cluster zum Signieren des Loaders CastleLoader (Fakeset) verwendet, der CastleRAT und weitere Komponenten installiert.

Gerade diese Verbindung über das Zertifikat – und nicht der „Ransomware‑Brand“ – stellt hier die verlässliche technische Brücke zwischen der aktuellen Kampagne und der bisherigen MuddyWater‑Aktivität dar.

IOC aus der beschriebenen Kampagne

• C2‑/Downloader‑IP‑Adresse: 172.86.126[.]208
• IP‑Adresse der Infrastruktur in der Operation gegen Oman: 172.86.76[.]127
• Ausführbare Datei: ms_upd.exe
• Code‑Signing‑Zertifikat: Subjekt "Donald Gay"
• RMM‑Tools in verdächtigem Kontext: DWAgent, AnyDesk, Microsoft Quick Assist

Kontext zur Gruppe MuddyWater und Nutzung der kriminellen Ökosysteme

MuddyWater (auch bekannt als Seedworm, Mango Sandstorm, Static Kitten) wird seit Langem mit Iran in Verbindung gebracht und ist im MITRE‑Profil als G0069 dokumentiert. Die aktuelle Kampagne setzt diese Entwicklung logisch fort.

Vom destruktiven „Pseudo-Ransomware“-Einsatz zur tief integrierten RaaS-Nutzung

• 2020: Angriffe auf israelische Organisationen mit dem Loader PowGoop, der eine modifizierte Version von Thanos mit destruktiven Funktionen ausrollte.
• 2023: Zusammenarbeit mit dem Cluster DEV‑1084 (Persona DarkBit) für destruktive Angriffe unter dem Deckmantel von Erpressung.
• Oktober 2025: Einsatz der Ransomware Qilin gegen ein israelisches staatliches Krankenhaus über ein Partner‑„Affiliate“-Programm.

In jedem dieser Fälle diente die Ransomware nicht als Selbstzweck, sondern als Deckmantel für Zerstörung, Druckausübung und die Verschleierung von Aufklärungszielen. In der neuen MuddyWater‑Kampagne unter dem „Brand“ Chaos ist dies noch deutlicher:

• Es werden Methoden und Services genutzt, die typisch für das kommerzielle RaaS‑Modell sind (doppelte, dreifache, teils sogar vierfache Erpressung – zusätzlich DDoS und Druck durch Kontaktaufnahme mit Kunden/Wettbewerbern);
• statt breit angelegter Monetarisierung zeigt sich jedoch ein fokussiertes Interesse an Daten, stabilem Zugang und spezifischen Zielorganisationen.

Für SOC‑ und IR‑Teams lautet die zentrale Erkenntnis: Das Auftauchen bekannter „Ransomware‑Brands“ in Artefakten garantiert nicht länger, dass es sich um rein kriminelle Erpressung handelt. Es kann sich um eine staatliche Operation handeln, die den RaaS‑Markt als Tarnung und Logistik nutzt.

Weitere iranische Operationen: Oman und die Verknüpfung mit physischem Schaden

Oman: Offenes Verzeichnis mit C2-Code und 26.000 Nutzerdatensätzen

Hunt.io entdeckte auf 172.86.76[.]127 ein offenes Verzeichnis mit:

• Angriffswerkzeugen und C2‑Code;
• Sitzungsprotokollen;
• Archiven exfiltrierter Daten.

Ziel war das Ministerium für Justiz und Rechtsangelegenheiten des Oman (Domain mjla.gov[.]om):

• mehr als 26.000 Nutzerdatensätze;
• Daten zu Gerichtsverfahren und Entscheidungen von Ausschüssen;
• Dumps der System‑Registry‑Hives SAM und SYSTEM (Grundlage für weitere Kompromittierung von Konten und der Domain‑Infrastruktur).

Hacktivismus und Hafen Fujairah: Verbindung von Cyber- und kinetischen Domänen

Parallel dazu behaupten dem Iran nahestehende Proxy‑Strukturen (z. B. Handala Hack):

• Veröffentlichung von Daten zu fast 400 Angehörigen der US‑Marine im Persischen Golf;
• Kompromittierung des Hafens Fujairah in den VAE mit einem Abfluss von rund 11.000 Dokumenten (Frachtpapiere, Schifffahrts‑ und Zolldaten);
• Nutzung der gestohlenen Infrastrukturdaten des Hafens zur Zielauswahl für Raketenangriffe.

Sollten sich diese Aussagen bestätigen, wäre dies eines der deutlichsten Beispiele dafür, wie Cyberoperationen unmittelbar die Grundlage für die physische Zerstörung von Infrastrukturobjekten legen. Für Betreiber von Häfen, Logistik‑ und Energieinfrastruktur bedeutet dies, dass der traditionelle Fokus auf den Schutz von IT‑Assets unzureichend ist, wenn nicht gleichzeitig analysiert wird, wie diese Daten die Effektivität kinetischer Angriffe steigern können.

Auswirkungsbewertung und Risikoprofil

• Geografischer Risikoradius: USA (Hauptmasse der Chaos‑Opfer, Stand März 2026), Israel, Oman, VAE und generell der Nahe Osten.
• Branchen:
  • Bau, Fertigung, Business‑Services (typische Ziele von Chaos);
  • Gesundheitswesen (israelisches Krankenhaus);
  • Behörden und Justiz (Oman);
  • Hafen‑ und Transport‑/Logistikinfrastruktur (Fujairah).
• Art der Folgen bei Untätigkeit:
  • langfristige, verdeckte Präsenz durch RMM‑Tools und gültige Benutzerkonten;
  • Abfluss sensibler Daten (personenbezogene Daten, Gerichtsentscheidungen, interne Infrastrukturschemata);
  • Nutzung der Daten für politischen Druck, Destabilisierung oder Vorbereitung physischen Schadens.

Am stärksten gefährdet sind Organisationen, in denen RMM‑Tools weit verbreitet und nur unzureichend kontrolliert werden und externe Kommunikation in Teams standardmäßig erlaubt ist.

Praktische Empfehlungen zu Schutz und Reaktion

1. Strikte Kontrolle von Microsoft Teams und Support-Kanälen

• Deaktivieren oder beschränken Sie externe Chats in Teams auf verifizierte Partnerdomänen.
• Richten Sie Benachrichtigungen ein bei:
  • Initiierung von screen sharing mit externen Nutzern;
  • massiven Anfragen an Konten oder Änderungen von MFA‑Einstellungen über solche Sessions.
• Etablieren Sie einen klar definierten, einheitlichen IT‑Support‑Kanal: Mitarbeiter müssen wissen, dass jeglicher „Support“ außerhalb dieses Kanals verdächtig ist.
• Nehmen Sie Schulungen mit einem konkreten Szenario auf: „Eine Person in Teams bittet darum, das Passwort in eine Textdatei einzugeben / den Bildschirm während der Passworteingabe zu teilen“ – dies ist ein Anlass, die Session sofort zu beenden und die Sicherheitsabteilung zu informieren.

2. Steuerung von RMM-Tools (DWAgent, AnyDesk, Quick Assist u. a.)

• Führen Sie ein Verzeichnis aller zugelassenen Remote‑Administration‑Tools.
• Implementieren Sie Application Control (Allow‑List): Jede neue RMM‑Software außerhalb dieser Liste ist ein Anlass für eine Untersuchung.
• Überwachen Sie:
  • Installation und Start von AnyDesk und DWAgent auf Servern und kritischen Workstations;
  • ausgehende Sessions dieser Software außerhalb der Unternehmens‑IP‑Bereiche.
• Verbieten Sie die Nutzung von RDP aus externen Netzen ohne VPN und strikte Authentifizierung.

3. Stärkung der Authentifizierung und Abwehr von Social Engineering rund um MFA

• Setzen Sie MFA‑Mechanismen wie number‑matching und kontextbezogene Hinweise ein, um es Angreifern schwerer zu machen, Nutzer über Teams zu „überreden“.
• Begrenzen Sie die Anzahl von MFA‑Anfragen und sperren Sie Konten bei mehrfacher Ablehnung (Schutz vor „MFA‑Fatigue“).
• Minimieren Sie die Anzahl lokaler Administratoren – insbesondere auf Workstations von Mitarbeitern mit häufigen externen Kontakten (Support, Vertrieb, Hafenbetreiber usw.).

4. Suche nach Kompromittierungsindikatoren und Threat Hunting nach TTPs

• Überprüfen Sie Logdaten auf:
  • Verbindungen zu 172.86.126[.]208 und 172.86.76[.]127 (direkt oder über curl);
  • Erstellung oder Ausführung von Dateien ms_upd.exe auf Servern und Workstations;
  • Installation/Start von AnyDesk und DWAgent in untypischen Netzwerksegmenten;
  • verdächtige Microsoft‑Teams‑Sessions von externen Nutzern mit anschließender Aktivität derselben Konten in VPN/AD.
• Analysieren Sie alle kürzlich hinzugefügten vertrauenswürdigen Code‑Signing‑Zertifikate; achten Sie besonders auf Subjekte, die nicht Ihren Richtlinien entsprechen (z. B. „Donald Gay“).
• Erstellen Sie Erkennungsregeln für Szenarien gemäß T1041 (Exfiltration Over C2 Channel), unter Berücksichtigung langlebiger, unauffälliger RAT‑Sessions mit periodischer Abfrage des C2.

5. Für den Regierungssektor und kritische Infrastruktur in der Region

• Segmentieren Sie IT‑ und OT‑Netzwerke (Operational Technology) und beschränken Sie die Routing‑Möglichkeiten zwischen Segmenten für Hafen‑, Energie‑ und Geschäftssysteme.
• Überprüfen Sie den Zugriff von Lieferanten und Dienstleistern auf Infrastruktursysteme (einschließlich RMM und VPN). Jeder externe Zugriff sollte:
  • einer konkreten Person zugeordnet sein;
  • zeitlich begrenzt werden;
  • protokolliert und aufgezeichnet werden (Session Recording).
• Nehmen Sie in Ihre Incident‑Response‑Pläne ein Szenario auf, in dem ein „Ransomware‑Vorfall“ als Deckmantel für die Vorbereitung eines physischen Angriffs dient (analog zum Fall des Hafens Fujairah).

Die zentrale Schlussfolgerung für Organisationen, die mit sensiblen Daten und Infrastruktur arbeiten, lautet, dass jeder Vorfall mit Erpressungselementen künftig als potenzielle staatliche Operation betrachtet werden sollte. Ein vorrangiger praktischer Schritt muss die Aktualisierung der Reaktionsverfahren sein: Neben der Blockierung der Ransomware ist systematisch nach verdeckter Persistenz über RMM‑Werkzeuge zu suchen, die Datenexfiltration zu analysieren und anomale Aktivitäten in Teams und anderen Remote‑Kommunikationskanälen zu prüfen.