Eine MSP, 32 Breaches: Containment-Lehren aus den Korean Leaks
23.09.2026 containmentmsp-securityransomwaresupply-chainincident-response
Im September 2025 brauchten die Betreiber hinter Qilin keine 32 einzelnen Einbrüche, um 32 südkoreanische Finanzunternehmen lahmzulegen. Sie brauchten genau einen: den südkoreanischen Managed-Service-Provider GJTec. Am 23. September 2025 berichtete die Korea JoongAng Daily, dass mehr als 20 Vermögensverwaltungsgesellschaften im Land nach der Kompromittierung von GJTec mit Ransomware infiziert wurden. Am Ende zählte die Kampagne, die als “Korean Leaks” bekannt wurde, mindestens 28 bis 32 betroffene Organisationen. Durch den Zugriff auf einen einzigen Managed Service Provider, GJTec, nutzte Qilin dessen dauerhafte privilegierte Zugangsdaten, um sich lateral in 32 südkoreanische Finanzinstitute zu bewegen, ohne jedes einzeln kompromittieren zu müssen. Über eine Million Dateien und mehr als zwei Terabyte Daten wurden exfiltriert.
Für IR-Teams ist das kein exotischer Einzelfall, sondern ein Belastungstest für ein Containment-Modell, das die meisten Organisationen immer noch für Einzelvorfälle bauen.
Das One-to-Many-Containment-Problem
Klassische Containment-Playbooks gehen von einem Angreifer aus, der sich in einem Netzwerk bewegt, das man selbst überwacht und kontrolliert. Bei Korean Leaks existierte dieser Kontrollpunkt nicht bei den Opfern, sondern beim Dienstleister. Um diese Angriffe durchzuführen, hat der Qilin-Affiliate offenbar einen einzigen vorgelagerten Managed Service Provider kompromittiert und dessen Zugang genutzt, um mehrere Opfer gleichzeitig zu kompromittieren. Bitdefender bezeichnete dies treffend als “kritischen blinden Fleck” der aktuellen Sicherheitsdiskussion: Das Ausnutzen eines Anbieters, Auftragnehmers oder MSP mit Zugriff auf andere Unternehmen sei ein realistischerer und praktikablerer Weg für RaaS-Gruppen, um gebündelte Opfer zu erreichen.
Besonders bitter: Keines der betroffenen Institute hatte eine realistische Chance, den Angriff vor der Verschlüsselung zu erkennen. Die GJTec-Kompromittierung wurde von keinem der 28 betroffenen Finanzinstitute vor der Detonation der Ransomware-Payloads entdeckt – sie wurde erst erkannt, nachdem Daten auf Qilins Leak-Seite erschienen. Ein Containment-Playbook, das auf eigener Telemetrie basiert, ist in diesem Szenario wirkungslos, weil der Angriffspunkt außerhalb der eigenen Sichtbarkeit liegt.
Der aktuelle Unit-42-Report bestätigt, dass dies kein Nischenphänomen mehr ist: Das Risiko in der Software-Lieferkette hat sich über verwundbaren Code hinaus auf den Missbrauch vertrauenswürdiger Konnektivität ausgeweitet – Angreifer nutzen SaaS-Integrationen, Vendor-Tools und Applikationsabhängigkeiten, um Perimeter im großen Maßstab zu umgehen.
Was ein MSP-taugliches Containment-Playbook leisten muss
Drei strukturelle Lücken erklären, warum Standard-Playbooks hier versagen – und woran IR-Teams jetzt arbeiten sollten:
Fehlende Segmentierung dauerhafter Zugänge. Standing Privileged Access von MSPs muss als eigene, hochkritische Angriffsfläche behandelt werden – mit Just-in-Time-Freigaben statt permanenter administrativer Rechte, die im Ernstfall gebündelt abgeschaltet werden können.
Kein gemeinsamer Kill-Switch. Ein Containment-Playbook für MSP-Beziehungen braucht vertraglich fixierte, technisch vorbereitete Notfallmechanismen: Wer darf im Zweifel den MSP-Zugang zu allen Kundennetzwerken gleichzeitig kappen, und wie schnell ist das technisch umsetzbar?
Keine geübte Kommunikationskette. Wenn ein Angriff über einen gemeinsamen Dienstleister läuft, betrifft die Benachrichtigungspflicht nicht nur das eigene Unternehmen, sondern potenziell Dutzende gleichzeitig Betroffene, die untereinander keine etablierte Kommunikation haben. Tabletop-Übungen sollten dieses Szenario explizit durchspielen: nicht “Wie reagieren wir auf einen Vorfall?”, sondern “Wie reagieren wir, wenn zwanzig andere Unternehmen im selben Moment dasselbe Problem haben – über einen Dienstleister, den wir nicht kontrollieren?”
Regulatorische Realität statt Checkbox-Übung
Rahmenwerke wie NIS2 und branchenspezifische Vorgaben verlangen zunehmend belastbares Third-Party-Risk-Management. In der Praxis bleibt das jedoch oft folgenlos: Diese Kontrollen werden in der Praxis häufig als Checkbox-Übung umgesetzt – ein Vendor-Fragebogen, einmal beim Onboarding ausgefüllt, ohne Mechanismus, um die tatsächliche Sicherheitslage des Anbieters zu verifizieren oder einen Breach auf Anbieterseite zu erkennen.
Korean Leaks zeigt, wohin das führt: eine Sicherheitsarchitektur, die auf Selbstauskünften statt auf kontinuierlichem Monitoring und vorbereiteten Containment-Mechanismen beruht, ist im Ernstfall wirkungslos. IR-Teams, die MSP-Beziehungen bislang nur vertraglich, nicht aber operativ in ihre Containment-Playbooks integriert haben, sollten dies als Weckruf verstehen – nicht als südkoreanisches Einzelereignis.
← Zurück zur Übersicht