:quality(90):no_upscale()){kind=logo}
Vier Gateway-Angriffe in fünf Wochen offenbaren die Koordinationslücke zwischen Angriff und Reaktion
STATUS: Aktives Ausnutzungsmuster SCHWERWIEGENDKEIT: 8/10 ZIELGRUPPE: Verantwortliche für Sicherheit in den Bereichen Regierung, Verteidigung und kritische Infrastruktur
12. Oktober 2026
·Blog
·Sichere Kommunikation
:quality(90):no_upscale())
In den vergangenen fünf Wochen haben Angreifer kritische Sicherheitslücken in vier weit verbreiteten Gateway-Kategorien ausgenutzt, darunter E-Mail, Fernzugriff, sicherer Datenaustausch und OT-Protokoll-Konnektivität. Bei drei der Vorfälle handelte es sich um Sicherheitslücken, die zu einer Kontrolle auf Root-Ebene führen konnten. Zusammengenommen zeigen diese Ereignisse zwei unterschiedliche Herausforderungen bei der Koordination auf, die bei der Planung von Reaktionsmaßnahmen selten getrennt betrachtet werden: die Kommunikation, während ein Angreifer möglicherweise bereits vertrauenswürdige Kanäle kontrolliert, und die Kommunikation, nachdem diese Kanäle absichtlich isoliert wurden, um den Angriff einzudämmen.
Was ist passiert?
Diese Schwachstellen führten zu zwei Koordinationsproblemen: der Kommunikation während eines aktiven Angriffs und der Kommunikation während der Isolierung, die diesen Angriff stoppen sollte.
Am 21. August hat die CISA die Zimbra-Sicherheitslücke CVE-2026-73570 in ihren Katalog „Known Exploited Vulnerabilities“ aufgenommen, nachdem Angreifer diese bereits vor der öffentlichen Bekanntgabe ausgenutzt hatten.1 Bis Ende August hatte Shadowserver 274 kompromittierte Instanzen bestätigt, wobei die Angreifer die vertrauenswürdige SSH-Identität von Zimbra selbst nutzten, um sich zwischen den Clusterknoten zu bewegen,2 was das erste Problem verdeutlicht: die Koordination über einen Kanal, den der Angreifer bereits kontrolliert.
Drei Wochen später bestätigte Citrix zwei Zero-Day-Schwachstellen, CVE-2026-88771 und CVE-2026-88772, die beide mit 9,5 bewertet wurden und in NetScaler-ADC- und Gateway-Geräten aktiv ausgenutzt werden.3 Mandiant und die Threat Intelligence Group von Google führten die Ausnutzung auf mutmaßlich staatlich verbundene Akteure zurück.4 Beide Schwachstellen ermöglichen die vollständige Kontrolle auf Root-Ebene über das Gerät.5
Ende September nahm ein Anbieter für den sicheren Austausch von Inhalten seine kundenorientierten Systeme vom Netz, nachdem er Hinweise auf eine glaubwürdige Bedrohung erhalten hatte.7 Die vorsorgliche Abschaltung dauerte etwa neun Stunden und veranschaulicht die Art von Isolierungsmaßnahme, die in Sicherheitsrichtlinien häufig empfohlen wird, wenn ein Risiko nicht sofort ausgeschlossen werden kann. Für die Dauer dieser Maßnahme standen alle Koordinationsfunktionen, die normalerweise über diese Systeme abliefen, nicht zur Verfügung.
Am 2. Oktober gab Moxa zwei Sicherheitslücken in seinen MGate-Protokoll-Gateways bekannt, die in den Bereichen Energie, Wasserversorgung, Fertigung und im öffentlichen Sektor zum Einsatz kommen.6 Die eine, mit einer Schweregradbewertung von 9,4, ermöglicht es einem Benutzer mit Lesezugriff, den Gerätespeicher zu manipulieren, während für die andere noch kein Firmware-Patch verfügbar ist. Es handelt sich genau um jene Gateways, die Betreiber laut CISA und internationalen Leitlinien beim ersten Anzeichen einer Kompromittierung isolieren sollen. Diese Leitlinien enden an der Netzwerkgrenze und enthalten keine Anweisungen zur Aufrechterhaltung der Koordination, sobald diese geschlossen wird.
In allen vier Fällen treten immer wieder dieselben beiden Schwachstellen auf. Wenn ein Angreifer den vertrauenswürdigen Kanal kontrollieren kann, wie bei Zimbra und NetScaler, besteht bei der Koordination über diesen Kanal die Gefahr, dass diese unter den Augen des Angreifers erfolgt. Sobald eine Organisation ein kompromittiertes oder gefährdetes System isoliert – wie es die OT-Leitlinien für Geräte der Moxa-Klasse empfehlen –, entfällt jegliche Koordination, die auf diesem System beruhte, es sei denn, es existiert bereits ein separater Kanal.
Ergebnis | Was das bedeutet | Operative Konsequenz | Offene Frage |
Bei drei der vier Vorfälle ging es um Sicherheitslücken, die Root-Rechte über kritische Gateway-Infrastrukturen gewährten oder zu einer Eskalation dieser Rechte führen konnten.7 | Ein Angreifer mit solchen Zugriffsrechten kann alles überwachen oder manipulieren, was über das Gateway läuft, einschließlich aller Koordinationsprozesse, die noch darauf angewiesen sind. | Die Nutzung der eigenen Kanäle des kompromittierten Systems zur Koordinierung einer Reaktion birgt das Risiko, dass die Koordinierung unter den Augen des Angreifers erfolgt, der diese Kanäle kontrolliert. | Wie viele Organisationen, die Gateway-Infrastruktur betreiben, verfügen über einen Koordinierungsplan, der davon ausgeht, dass das Gateway selbst kompromittiert sein könnte und nicht nur nicht verfügbar ist? |
Eine Organisation, die auf eine glaubwürdige Bedrohung reagierte, entschied sich dafür, kritische Infrastruktur für mehrere Stunden außer Betrieb zu nehmen, was verdeutlicht, wie das übliche Verteidigungskonzept ein eigenes Koordinationsvakuum schaffen kann. | Das übliche Verteidigungsschema, bei dem das verdächtige System isoliert wird, führt genau so lange zu einem Koordinationsvakuum, wie die Isolierung andauert. | Eine Organisation, die nur über einen einzigen Koordinationskanal verfügt, verliert diesen Kanal in dem Moment, in dem sie die richtigen Abwehrmaßnahmen ergreift und das System, auf dem sie läuft, isoliert. | Wie viele Organisationen verfügen bereits über einen erprobten, separaten Koordinationskanal, bevor sie überhaupt ein System isolieren müssen, anstatt während des Zeitfensters einen solchen zu improvisieren? |
Die Moxa-MGate-Sicherheitslücken betreffen Protokoll-Gateways, für die die gemeinsamen Leitlinien der CISA und internationaler Behörden bereits vorsehen, dass Betreiber kritischer Infrastrukturen diese beim ersten Anzeichen einer Kompromittierung isolieren müssen. | Die Isolationsrichtlinien für OT-Umgebungen befassen sich mit der Netzwerkgrenze, enthalten jedoch keine Angaben dazu, wie sich das Personal abstimmen soll, sobald diese Grenze geschlossen ist. | Einsatzteams, Mitarbeiter in der Leitstelle und Partner im Rahmen der gegenseitigen Hilfe benötigen einen Koordinierungsplan, der davon ausgeht, dass möglicherweise nicht nur das IT-Netzwerk, sondern auch das OT-Netzwerk selbst isoliert ist. | Sehen die aktuellen OT-Notfallpläne einen Koordinationskanal für das Isolationsfenster vor oder lediglich den Isolationsschritt selbst? |
Warum das wichtig ist
Alte Annahme | Aktuelle Realität | BlackBerry-Antwort |
Sollte ein Gateway kompromittiert werden, können die bestehenden Kommunikationskanäle des Unternehmens weiterhin zur Koordinierung der Gegenmaßnahmen genutzt werden, da es sich bei dem Vorfall um ein Datenproblem und nicht um ein Kanalproblem handelt. | Zwei von vier Sicherheitslücken im Gateway verschafften Angreifern Root-Rechte, was bedeutet, dass der bestehende Kanal dasselbe System ist, das der Angreifer nun kontrolliert. | BlackBerry® AtHoc® bietet einen Koordinationskanal, der unabhängig von der untersuchten Infrastruktur ist, sodass die Reaktion nicht über ein System laufen muss, das möglicherweise bereits feindlich gesinnt ist. |
Ein kompromittiertes oder gefährdetes System vom Netz zu nehmen, ist an sich schon eine umfassende Abwehrmaßnahme. | Eine kürzlich erfolgte vorsorgliche Abschaltung zeigt, dass durch die Isolierung eines Systems auch alle Koordinationsprozesse, die zuvor davon abhängig waren, für die Dauer der Isolierungsphase ebenfalls isoliert werden. | BlackBerry AtHoc wurde speziell für den Einsatz während Isolationsphasen entwickelt und bietet Teams einen Koordinationskanal, der nicht davon abhängt, ob das System isoliert ist oder nicht. |
Die OT-Isolierungsrichtlinie, wonach das Netzwerk sofort getrennt werden soll, sobald der Verdacht auf eine Kompromittierung besteht, ist für sich genommen bereits eine umfassende Maßnahme. | Die Moxa-Offenlegung betrifft genau jene Klasse von OT-Gateways, die Betreiber gemäß dieser Richtlinie isolieren sollen, und diese Richtlinie endet an der Netzwerkgrenze, ohne dass Anweisungen dazu gegeben werden, wie das Personal anschließend koordiniert vorgehen soll. | BlackBerry AtHoc BlackBerry® SecuSUITE® überträgt dasselbe Prinzip der Out-of-Band-Koordination auf OT-Umgebungen, sodass die Isolierung des Netzwerks nicht bedeutet, dass die Menschen, die darauf angewiesen sind, ebenfalls isoliert werden. |
Empfohlene Maßnahmen
SOFORT | Überprüfen Sie den Patch-Status auf allen betroffenen Plattformen in Ihrer Umgebung, einschließlich E-Mail-Gateways, Fernzugriffsinfrastruktur, Systemen für den sicheren Austausch von Inhalten und OT-Protokoll-Gateways. Behandeln Sie jede nicht gepatchte, über das Internet erreichbare Instanz als potenziell aktiv kompromittiert. |
SOFORT | Stellen Sie fest, ob Ihre Organisation über einen Koordinationskanal verfügt, der auch dann noch verfügbar ist, wenn Ihr E-Mail- oder Fernzugriffssystem ohne Vorankündigung ausfällt. |
KURZFRISTIG | Entwickeln und testen Sie explizit einen Out-of-Band-Koordinationskanal für beide Szenarien: den Betrieb, während ein vertrauenswürdiges System möglicherweise kompromittiert ist, und den Betrieb, nachdem dieses System absichtlich isoliert wurde. |
KURZFRISTIG | Die Planung der Isolierung und Koordination sollte speziell auf OT-Umgebungen ausgeweitet werden, da die aktuellen OT-Isolierungsrichtlinien zwar die Netzwerkgrenze behandeln, jedoch nicht darauf eingehen, wie die Koordination nach deren Schließung weiterverläuft. |
LAUFEND | Betrachten Sie die Zeitspanne, in der ein Koordinationskanal während eines Isolationsfensters funktionsfähig bleiben muss – sei es mehrere Stunden oder länger –, als Planungsannahme und nicht als nachträglichen Einfall. |
BlackBerry-Position
Jeder dieser vier Vorfälle wird letztendlich entweder durch das Schließen der Sicherheitslücke oder durch die Isolierung des betroffenen Systems behoben. Keine dieser Maßnahmen stellt die Koordination von sich aus wieder her. Ein Angreifer mit Root-Zugriff auf ein vertrauenswürdiges Gateway kann alles überwachen, was darüber läuft, und ein System, das offline geschaltet wird, um diesen Angreifer zu stoppen, nimmt damit auch seine Koordinationsfunktion außer Betrieb. Beide Szenarien weisen auf dieselbe Anforderung hin: einen Kanal, der so ausgelegt ist, dass er unabhängig von dem kompromittierten oder isolierten System weiterfunktioniert, denn genau in dem Moment, in dem eine Organisation diesen Kanal am dringendsten benötigt, ist der übliche Kanal möglicherweise gerade nicht verfügbar.
Quellenangaben:
1. Angreifer nutzen eine SNMP-Sicherheitslücke in Zimbra aus, um unauthorisierte Remote-Codeausführung zu ermöglichen (The Hacker News, Bericht über die aktive Ausnutzung von CVE-2026-73570, 20. August 2026).
2. Hacker haben bei anhaltenden Angriffen über 270 Zimbra-Server kompromittiert (BleepingComputer, Bericht über von Shadowserver nachverfolgte Angriffe auf Zimbra-Server, 25. August 2026).
3. Warnung: Zwei ungepatchte Citrix NetScaler-RCE-Zero-Days werden aktiv ausgenutzt (The Hacker News, Citrix bestätigt Ausnutzung von NetScaler-Zero-Days, 27. September 2026).
4. Abwehr gegen aktive Angriffe auf Citrix NetScaler ADC- und Gateway-Appliances (Google Cloud Blog, verfasst von Mandiant, der Google Threat Intelligence Group und Mandiant Services; Analyse und Abwehrempfehlungen im Zusammenhang mit der aktiven Ausnutzung der Citrix NetScaler-Sicherheitslücken CVE-2026-88772 und CVE-2026-88771, 29. September 2026).
5. Zero-Day-Schwachstellen bei Citrix NetScaler verdeutlichen wiederkehrendes Risiko für Root-Zugriff (TechTimes, Analyse wiederkehrender Muster bei NetScaler-Sicherheitslücken, die Root-Zugriff ermöglichen, 30. September 2026).
6. Sicherheitslücken bei Moxa MGate gefährden industrielle Protokoll-Gateways (SecurityOnline, Berichterstattung und Analyse der Moxa MGate-Sicherheitslücken CVE-2026-86325 und CVE-2026-86326, einschließlich betroffener Produkte, Schweregrade und Empfehlungen zur Abhilfe. 2. Oktober 2026).
7. Kiteworks behebt Sicherheitslücke mit maximaler Schweregradstufe durch Code-Injektion (BleepingComputer, Bericht über CVE-2026-54154, die das Kiteworks Email Protection Gateway (EPG) betrifft, 1. Oktober 2026).
:quality(90):no_upscale())