FortiGate unter Beschuss: Wie Angreifer Firewalls kompromittieren und ganze Netzwerke übernehmen

Seit Ende 2024 läuft eine der aggressivsten Angriffskampagnen gegen Perimeter-Infrastruktur, die die Security-Branche je gesehen hat. Im Zentrum: FortiGate Next-Generation Firewalls von Fortinet. Innerhalb von 15 Monaten wurden mindestens fünf kritische Schwachstellen aktiv ausgenutzt, über 600 Geräte in 55 Ländern kompromittiert, und Angreifer entwickelten Techniken, die selbst nach dem Patchen den Zugriff aufrechterhalten. Dieser Artikel rekonstruiert die Chronologie, analysiert die Angriffskette im Detail und zeigt, welche Lehren Unternehmen daraus ziehen sollten.

Die Chronologie: 15 Monate eskalierender Angriffe

Die Angriffskette im Detail: Vom Firewall-Exploit zum Domain-Takeover

Ein im März 2026 veröffentlichter DFIR-Bericht von SentinelOne dokumentiert zwei reale Vorfälle, die das volle Ausmass der Bedrohung zeigen. Die Angriffskette folgt einem klaren Muster:

Phase 1: Initialer Zugang und Persistenz

Die Angreifer nutzen eine der oben genannten Schwachstellen, um unauthentifiziert Super-Admin-Rechte auf der FortiGate zu erlangen. Anschliessend erstellen sie lokale Admin-Konten mit unauffälligen Namen wie support, ssl-admin, audit oder backup. Zusätzlich werden neue Firewall-Policies erstellt, die uneingeschränkten Datenverkehr zwischen allen Zonen erlauben - effektiv wird die Firewall ausgeschaltet.

Phase 2: Credential-Diebstahl - das Schlüsselproblem

Hier liegt der kritischste Punkt der gesamten Kette: FortiOS speichert Zugangsdaten in Konfigurationsdateien mit reversibler Verschlüsselung. Die Angreifer exportieren die Konfiguration über den Befehl show full-configuration und entschlüsseln die darin enthaltenen LDAP-Service-Account-Credentials.

In den dokumentierten Fällen wurde konkret der fortidcagent-Account kompromittiert - ein Service-Account, der für die Integration zwischen FortiGate und Active Directory genutzt wird und typischerweise über weitreichende AD-Leserechte verfügt.

Phase 3: Active-Directory-Übernahme

Mit den entschlüsselten Credentials authentifizieren sich die Angreifer am Active Directory. Im ersten dokumentierten Vorfall missbrauchten sie das AD-Attribut mS-DS-MachineAccountQuota, um eigene Workstations in die Domäne aufzunehmen. Die Rogue-Workstations trugen generische Namen wie WIN-X8WRBOSK0OF.

Im zweiten Vorfall ging es noch schneller: Nur 10 Minuten nach der Erstellung des Backdoor-Accounts auf der Firewall hatten die Angreifer bereits Domain-Administrator-Rechte.

Phase 4: Remote-Access-Tools und Malware

Für persistenten Zugriff unabhängig von der Firewall setzten die Angreifer zwei legitime Remote-Management-Tools ein:

• arrow_rightPulseway - gehostet auf Google Cloud Storage (storage.googleapis[.]com/apply-main/)
• arrow_rightMeshAgent - versteckt über Registry-Key SystemComponent=1, damit es nicht in der Softwareliste erscheint

Zusätzlich wurde eine Java-basierte Malware mit DLL-Sideloading eingesetzt, die über AWS S3 verteilt wurde und Beacon-Verbindungen zu den C2-Domains ndibstersoft[.]com und neremedysoft[.]com aufbaute.

Phase 5: NTDS.dit-Exfiltration - Game Over

Das endgültige Ziel: die NTDS.dit-Datenbank des Primär-Domain-Controllers. Diese Datei enthält sämtliche Passwort-Hashes aller Domain-Benutzer. Die Angreifer:

1. Erstellten eine Volume Shadow Copy über WMIC
2. Extrahierten NTDS.dit und den SYSTEM-Registry-Hive
3. Komprimierten die Dateien mit makecab
4. Exfiltrierten sie über Port 443 an 172.67.196[.]232 (8 Minuten Verbindungsdauer)
5. Löschten die komprimierten Dateien nach der Exfiltration

Wer steckt hinter den Angriffen?

SentinelOne schätzt die Akteure als finanziell motivierte Initial Access Broker (IABs) ein - spezialisierte Kriminelle, die in hochwertige Ziele einbrechen und den Zugang anschliessend an Ransomware-Operatoren weiterverkaufen. Die unterschiedlichen Vorgehensweisen in den beiden dokumentierten Vorfällen deuten auf mindestens zwei separate Operatorgruppen hin.

Parallel dazu dokumentierte das AWS-Security-Team eine separate Kampagne eines russischsprachigen, KI-gestützten Akteurs, der zwischen Januar und Februar 2026 über 600 FortiGate-Geräte in 55 Ländern kompromittierte - in diesem Fall über exponierte Management-Ports und schwache Einzel-Faktor-Authentifizierung.

Das Logging-Problem: Warum die Firewall selbst nicht genug sieht

Ein wiederkehrendes Muster in den dokumentierten Vorfällen: Die Protokollierung auf den FortiGate-Geräten reichte für eine vollständige forensische Analyse nicht aus. In vielen Fällen konnte der genaue Zeitpunkt der initialen Kompromittierung nicht festgestellt werden.

Fortinet hat inzwischen spezifische Log-IDs veröffentlicht, die Unternehmen aktiv überwachen sollten:

Zusätzlich sollten auf Windows-Seite folgende Event-IDs überwacht werden:

Sofort-Massnahmen für betroffene Unternehmen