Szenario Lieferanten-Hack: Dein IT-Dienstleister wurde kompromittiert

Montag, 11:23 Uhr: Der Anruf, der alles ändert

Die Fischer Medizintechnik GmbH entwickelt und vertreibt Diagnose-Geräte für Arztpraxen. 85 Mitarbeiter, Standort Freiburg, zertifiziert nach ISO 13485 (Medizinprodukte) und ISO 27001. Die IT wird zu großen Teilen von einem Managed Service Provider (MSP) namens ComTech Solutions betreut. ComTech administriert die Server, das Active Directory, die Firewall und das Backup-System der Fischer Medizintechnik. Dafür hat ComTech einen permanenten VPN-Tunnel und mehrere Admin-Accounts in der Domäne der Fischer GmbH.

Am Montagvormittag um 11:23 Uhr ruft der Geschäftsführer von ComTech persönlich bei IT-Leiterin Katharina Berger an. Er klingt angespannt.

„Katharina, ich muss dich über einen Sicherheitsvorfall informieren. Wir haben am Wochenende festgestellt, dass unser internes RMM-System kompromittiert wurde. Die Angreifer hatten Zugriff auf unser Remote-Management-Tool, mit dem wir die Systeme unserer Kunden administrieren. Wir können nicht ausschließen, dass auch eure Systeme betroffen sind. Wir arbeiten mit Forensikern zusammen und werden euch auf dem Laufenden halten."

RMM steht für Remote Monitoring and Management. Es ist das zentrale Werkzeug, mit dem MSPs die IT-Systeme ihrer Kunden aus der Ferne verwalten. Wer Zugriff auf das RMM-System eines MSPs hat, hat potenziell Admin-Zugriff auf alle Kundensysteme, die darüber verwaltet werden. Das sind bei einem mittelgroßen MSP wie ComTech typischerweise 30 bis 80 Unternehmen.

Katharina versteht sofort die Tragweite. Die nächsten Stunden werden entscheiden, ob die Fischer Medizintechnik nur ein potenzielles Opfer ist oder ein tatsächliches.

Warum Supply-Chain-Angriffe so gefährlich sind

Bevor wir den weiteren Verlauf schildern, ein Blick auf den Mechanismus. Supply-Chain-Angriffe gehören zu den effektivsten Angriffsformen, weil sie das Vertrauensverhältnis zwischen einem Unternehmen und seinen Dienstleistern ausnutzen. Der Angreifer kompromittiert nicht das eigentliche Ziel, sondern einen Lieferanten, der privilegierten Zugriff auf die Systeme des Ziels hat.

Für Angreifer bietet dieses Modell einen enormen Skalierungseffekt: Statt 50 Unternehmen einzeln anzugreifen, kompromittieren sie den einen MSP, der alle 50 betreut. Ein erfolgreicher Angriff auf das RMM-System des MSPs öffnet gleichzeitig 50 Türen.

Bekannte Beispiele wie Kaseya (2021) und SolarWinds (2020) haben gezeigt, dass selbst große, sicherheitsbewusste Organisationen über ihre Lieferkette getroffen werden können. Der Artikel zu Supply-Chain-Angriffen beschreibt die verschiedenen Angriffsvektoren im Detail. Im Mittelstand, wo MSP-Verhältnisse oft auf Vertrauen und Handschlag basieren und die vertraglichen Sicherheitsanforderungen dünn sind, ist das Risiko sogar noch höher.

Montag, 11:30 Uhr: Die Sofortmaßnahmen

Katharina hat 15 Minuten, um die richtigen Entscheidungen zu treffen. Sie greift zum Notfallplan und ruft gleichzeitig ihren intern verbliebenen IT-Kollegen Thomas an.

Sofortmaßnahme 1: Alle Dienstleister-Zugänge kappen

Das ist die wichtigste Maßnahme und sie muss sofort passieren, noch bevor die Geschäftsführung informiert wird, bevor das Ausmaß bekannt ist, bevor irgendjemand „Aber wir brauchen ComTech für den Support" sagen kann.

Katharina und Thomas führen in den nächsten 20 Minuten folgende Schritte durch:

VPN-Tunnel schließen. Die Firewall hat einen Site-to-Site-VPN-Tunnel zu ComTech. Katharina deaktiviert den Tunnel auf der eigenen Firewall-Seite. Damit ist die permanente Netzwerkverbindung zum MSP unterbrochen.

RMM-Agent deaktivieren. Auf jedem Server und jedem verwalteten Client der Fischer Medizintechnik läuft ein RMM-Agent von ComTech, ein kleines Programm, das dem MSP den Fernzugriff ermöglicht. Wenn das RMM-System des MSPs kompromittiert ist, ist dieser Agent der direkte Angriffsvektor. Thomas deaktiviert den Agent auf allen Servern per Group Policy und erstellt ein Skript, das den Agent auf allen Clients stoppt. Das dauert etwa 30 Minuten für die Server und bis zu zwei Stunden für alle Clients.

Alle MSP-Accounts sperren. ComTech hat drei benannte Admin-Accounts in der Active-Directory-Domäne der Fischer GmbH. Katharina deaktiviert alle drei und setzt deren Passwörter zurück. Zusätzlich prüft sie, ob ComTech Zugriff auf weitere Systeme hat, die nicht über Active Directory authentifizieren: Firewall-Management, Backup-Software, Hypervisor. Auch diese Zugänge werden gesperrt.

Remote-Desktop-Zugriffe blockieren. Zusätzlich zum VPN-Tunnel hatte ComTech eine Fallback-Verbindung über einen Remote-Desktop-Gateway. Katharina deaktiviert den Gateway-Zugang für alle externen Quellen.

Sofortmaßnahme 2: Eigene Systeme prüfen

Die Tatsache, dass ComTech kompromittiert wurde, bedeutet nicht automatisch, dass auch die Fischer Medizintechnik kompromittiert ist. Aber es muss angenommen werden, bis das Gegenteil bewiesen ist. Katharina startet eine erste Sichtprüfung:

• Gibt es unbekannte Admin-Accounts im Active Directory?
• Gibt es verdächtige geplante Aufgaben auf den Servern?
• Zeigen die Firewall-Logs ungewöhnliche ausgehende Verbindungen?
• Gibt es Anmeldungen von ComTech-Accounts zu ungewöhnlichen Zeiten (Wochenende, nachts)?

Die erste Sichtung ergibt keine offensichtlichen Anomalien, aber Katharina weiß, dass das wenig aussagekräftig ist. Ein professioneller Angreifer hinterlässt selten offensichtliche Spuren. Die tiefe Analyse muss ein externer Forensiker übernehmen.

Sofortmaßnahme 3: Geschäftsführung informieren

Katharina informiert den Geschäftsführer Dr. Fischer persönlich, nicht per E-Mail. Sie schildert drei Dinge: Was ist passiert (MSP kompromittiert), was hat sie getan (alle Zugänge gekappt), und was braucht sie (Freigabe für externe Forensik und die Entscheidung über den weiteren Betrieb).

Dr. Fischer stellt die Frage, die jeder Geschäftsführer in dieser Situation stellt: „Wie lange sind wir ohne IT-Support?" Katharinas ehrliche Antwort: „Wir können die grundlegenden Systeme selbst am Laufen halten. Aber größere Änderungen, Patches und die Backup-Verwaltung haben bisher ComTech gemacht. Wenn wir das intern abdecken müssen, brauche ich kurzfristig externe Unterstützung von einem anderen Dienstleister."

Montag, 14:00 Uhr: Die unbequeme Wahrheit über Dienstleister-Zugriffe

Während Thomas die Firewall-Logs der letzten 30 Tage exportiert, nimmt sich Katharina eine Stunde, um den tatsächlichen Umfang der ComTech-Zugriffe zu dokumentieren. Das Ergebnis ist ernüchternd:

ComTech hatte Zugriff auf:

• Alle Windows-Server (Domain Admin)
• Die Firewall (Full Admin)
• Das Backup-System (Full Admin)
• Den Hypervisor (Full Admin)
• Die Netzwerk-Switches (Full Admin)
• Jeden einzelnen Client über den RMM-Agenten (SYSTEM-Level-Rechte)

ComTech hatte nicht:

• Zugriff auf das ERP-System (eigener Hersteller-Support)
• Zugriff auf die Entwicklungssysteme (separates Netz, eigene Verwaltung)
• Physischen Zugriff auf den Serverraum

Mit anderen Worten: ComTech hatte die gleichen Rechte wie ein interner IT-Administrator. Im Normalbetrieb ist das praktisch, im Kompromittierungsfall ist es ein Albtraum. Denn der Angreifer hatte über das RMM-System potenziell denselben Zugriff, den ComTech im Tagesgeschäft nutzt.

Katharina notiert: Nach diesem Vorfall muss das Zugriffsmodell grundlegend überarbeitet werden.

Dienstag: Forensik und Bestandsaufnahme

Der externe Forensiker beginnt am Dienstagmorgen mit der Analyse. Seine Aufgabe ist klar definiert: Feststellen, ob die Systeme der Fischer Medizintechnik über den kompromittierten MSP-Zugang tatsächlich angegriffen wurden.

Die Analyse

Der Forensiker prüft mehrere Datenquellen:

RMM-Logs. Die lokalen Logs des RMM-Agenten auf den Servern der Fischer GmbH zeigen, welche Aktionen über das Tool ausgeführt wurden. Die Analyse ergibt: In den letzten zwei Wochen gab es drei Sessions über das RMM-Tool, die nicht den üblichen Mustern entsprechen, zwei davon am vergangenen Wochenende, als ComTech nach eigener Aussage den Vorfall entdeckt hat. Die Sessions haben PowerShell-Befehle ausgeführt, die nach Aufklärungsaktivitäten aussehen: Auslesen von Benutzerkonten, Netzwerkfreigaben und installierter Software.

Active-Directory-Logs. Keine neuen verdächtigen Accounts, keine Änderungen an Gruppenmitgliedschaften. Das deutet darauf hin, dass der Angreifer sich in der Aufklärungsphase befand und noch keine Persistence geschaffen hat.

Firewall-Logs. Keine ungewöhnlichen ausgehenden Verbindungen, keine Datenexfiltration erkennbar.

Ergebnis. Der Angreifer war auf den Systemen der Fischer Medizintechnik aktiv, aber die Kompromittierung ist in einem frühen Stadium. Es wurde aufgeklärt, aber noch nicht exfiltriert oder Persistenz geschaffen. Die schnelle Reaktion von Katharina, die innerhalb einer Stunde nach dem Anruf alle Zugänge gekappt hat, hat wahrscheinlich verhindert, dass der Angriff weiter eskalierte.

Trotzdem: Reset

Obwohl kein tiefgreifender Schaden festgestellt wird, empfiehlt der Forensiker einen umfassenden Credential Reset. Alle Admin-Passwörter werden geändert, der krbtgt-Account doppelt zurückgesetzt, und alle Service-Account-Passwörter erneuert. Die Begründung: Es kann nicht mit absoluter Sicherheit ausgeschlossen werden, dass der Angreifer Credentials ausgelesen hat, die nicht in den Logs sichtbar sind.

Mittwoch: Kommunikation auf allen Ebenen

Kommunikation mit ComTech

Katharina führt ein strukturiertes Gespräch mit ComTech. Sie will Antworten auf konkrete Fragen:

1. Wann genau wurde die Kompromittierung entdeckt, und wann hat sie tatsächlich begonnen?
2. Welche Kunden sind betroffen, und wie wurden sie priorisiert?
3. Welche forensischen Maßnahmen hat ComTech ergriffen?
4. Welche Informationen kann ComTech über die Aktivitäten auf den Systemen der Fischer GmbH liefern?
5. Welche konkreten Sicherheitsmaßnahmen wird ComTech umsetzen, bevor die Zusammenarbeit wiederaufgenommen wird?

ComTech kann einige Fragen beantworten, andere nicht. Die Forensik läuft noch. Was Katharina auffällt: ComTech hat den Vorfall am Wochenende entdeckt, sie aber erst am Montagvormittag informiert. Auf die Frage nach der Verzögerung antwortet ComTech, man habe erst die eigenen Systeme stabilisieren wollen, bevor man die Kunden informiert. Katharina notiert: Die vertragliche Vereinbarung mit dem MSP enthält keine definierte Benachrichtigungsfrist für Sicherheitsvorfälle. Das wird sich ändern.

Kommunikation mit Behörden

Katharina prüft die Meldepflichten:

NIS2. Die Fischer Medizintechnik fällt als Hersteller von Medizinprodukten unter die NIS2-Regulierung. Der Vorfall muss dem BSI als Erstmeldung innerhalb von 24 Stunden gemeldet werden, auch wenn die eigene Kompromittierung begrenzt war. Der Vorfall hat die Verfügbarkeit und Integrität der Systeme potenziell beeinträchtigt.

DSGVO. Da der Forensiker bestätigt hat, dass der Angreifer Aufklärungsaktivitäten durchgeführt, aber keine Daten exfiltriert hat, ist die DSGVO-Meldepflicht ein Grenzfall. Katharina entscheidet sich in Abstimmung mit dem Datenschutzbeauftragten für eine freiwillige Meldung, auch um bei einer späteren Entdeckung weiterer Auswirkungen auf der sicheren Seite zu sein.

Kommunikation mit Kunden

Die Fischer Medizintechnik vertreibt Diagnose-Geräte an Arztpraxen und Kliniken, die über ein Cloud-Portal Gerätedaten einsehen können. Katharina prüft, ob dieses Portal in irgendeiner Weise betroffen ist. Das Portal läuft auf einer separaten Cloud-Infrastruktur, die nicht von ComTech verwaltet wird. Trotzdem informiert sie die wichtigsten Kunden proaktiv, dass es einen Sicherheitsvorfall bei einem IT-Dienstleister gab und Vorsichtsmaßnahmen ergriffen wurden.

Woche 2: Die Neubewertung der Dienstleisterbeziehung

Der akute Vorfall ist bewältigt, aber die eigentliche Arbeit beginnt jetzt: die grundlegende Überarbeitung der Zusammenarbeit mit IT-Dienstleistern.

Das Zugriffsmodell überarbeiten

Das bisherige Modell war einfach und bequem: permanenter VPN-Tunnel, permanenter Admin-Zugriff, RMM-Agent auf jedem System. Dieses Modell wird durch ein restriktiveres ersetzt:

Just-in-Time-Access. ComTech bekommt keinen permanenten Admin-Zugriff mehr. Stattdessen wird ein System eingerichtet, bei dem ComTech-Mitarbeiter für eine konkrete Aufgabe einen zeitlich begrenzten Zugang anfordern müssen. Der Zugang wird nach Abschluss der Aufgabe automatisch deaktiviert. Das erfordert mehr Aufwand, aber es reduziert die Angriffsfläche drastisch.

Getrennte Credentials. Die Admin-Accounts, die ComTech nutzt, werden von den internen Admin-Accounts getrennt. ComTech-Accounts haben nur die Berechtigungen, die für die jeweilige Aufgabe nötig sind, nicht pauschal Domain-Admin-Rechte.

Session-Recording. Alle Zugriffe von ComTech auf die Systeme der Fischer GmbH werden aufgezeichnet. Nicht zur Überwachung, sondern zur Nachvollziehbarkeit und für den Fall eines erneuten Vorfalls.

RMM-Agent ersetzen. Der bisherige RMM-Agent, der SYSTEM-Rechte hatte und eine permanente Verbindung zum ComTech-Management-Server aufbaute, wird durch ein restriktiveres Remote-Access-Tool ersetzt, das nur bei Bedarf aktiv ist und dessen Verbindungen geloggt werden.

Vertragliche Anpassungen

Katharina arbeitet mit dem Unternehmensanwalt einen Nachtrag zum MSP-Vertrag aus. Die Lieferanten-Sicherheitsrichtlinie bildet dafür die Grundlage:

Benachrichtigungspflicht. ComTech muss die Fischer GmbH innerhalb von vier Stunden nach Entdeckung eines Sicherheitsvorfalls benachrichtigen, der potenziell die Kundensysteme betrifft. Die Benachrichtigung muss schriftlich erfolgen und die bekannten Fakten enthalten.

Sicherheitsaudits. Die Fischer GmbH erhält das Recht, jährlich eine Sicherheitsüberprüfung der relevanten ComTech-Systeme durchzuführen oder durch einen unabhängigen Dritten durchführen zu lassen.

Sicherheitsstandards. ComTech muss ein Mindestmaß an Sicherheitsstandards einhalten: MFA für alle Admin-Zugänge, verschlüsselte Kommunikation, regelmäßige Penetrationstests des eigenen RMM-Systems, dokumentiertes Patch-Management.

Haftung. Die Haftungsregelung wird angepasst: Bei nachweisbarer Fahrlässigkeit (etwa fehlende Sicherheitsupdates für das RMM-System) haftet ComTech für die direkten Schäden, die dem Kunden durch die Kompromittierung entstehen.

Exit-Strategie. Der Vertrag enthält eine klare Regelung für den Fall, dass die Zusammenarbeit beendet wird: Übergabe aller Zugangsdaten, Dokumentation, Konfigurationen und die vollständige Deaktivierung aller ComTech-Zugänge innerhalb von 48 Stunden.

NIS2 und die Lieferkette

NIS2 stellt in Art. 21 Abs. 2 lit. d explizite Anforderungen an die „Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen den einzelnen Einrichtungen und ihren unmittelbaren Anbietern oder Diensteanbietern". Das bedeutet konkret:

Risikobewertung der Lieferanten. Unternehmen müssen die Sicherheitsrisiken ihrer Dienstleister systematisch bewerten, etwa mit einem Sicherheitsfragebogen. Ein MSP mit Admin-Zugriff auf die gesamte IT-Infrastruktur ist ein Hochrisiko-Lieferant und muss entsprechend behandelt werden.

Vertragliche Sicherheitsanforderungen. Die Sicherheitsanforderungen an den Dienstleister müssen vertraglich fixiert sein, nicht als vage Absichtserklärung, sondern als konkrete, überprüfbare Anforderungen.

Regelmäßige Überprüfung. Die Einhaltung der vereinbarten Sicherheitsstandards muss regelmäßig überprüft werden, durch Audits, Zertifizierungsnachweise oder Sicherheitsfragebögen.

Incident-Response-Koordination. Für den Fall eines Vorfalls beim Dienstleister muss ein koordinierter Prozess existieren: Wer informiert wen, innerhalb welcher Frist, über welchen Kanal, und welche Sofortmaßnahmen werden ausgelöst.

Der alternative Dienstleister

Katharina nutzt den Vorfall, um ein Dual-Vendor-Konzept zu prüfen. Die Abhängigkeit von einem einzelnen MSP war einer der größten Risikofaktoren. Wenn ComTech morgen vom Markt verschwindet oder erneut kompromittiert wird, steht die Fischer GmbH ohne IT-Support da.

Die Lösung: Kritische Kompetenzen werden intern aufgebaut (ein zweiter IT-Mitarbeiter wird eingestellt), und für spezialisierte Aufgaben wird ein zweiter Dienstleister mit Rahmenvertrag bereitgestellt, der im Notfall einspringen kann.

Lessons Learned

Drei Wochen nach dem Vorfall führt Katharina den Lessons-Learned-Workshop durch. Die zentralen Erkenntnisse betreffen weniger die technische Reaktion (die war gut) als die strukturellen Voraussetzungen:

Was hat funktioniert:

• Die schnelle Reaktion innerhalb einer Stunde nach dem Anruf hat die Kompromittierung auf die Aufklärungsphase begrenzt
• Die separate Verwaltung der Entwicklungssysteme und des Cloud-Portals hat verhindert, dass kritische Bereiche betroffen waren
• Der Incident-Response-Plan hatte ein Kapitel „Dienstleister-Kompromittierung", das die ersten Schritte strukturiert hat

Was hat nicht funktioniert:

• Der permanente VPN-Tunnel und die permanenten Admin-Zugänge haben eine unnötig große Angriffsfläche geschaffen
• Es gab kein Monitoring der Dienstleister-Zugriffe; die RMM-Aktivitäten wurden nicht geloggt
• Die vertraglichen Sicherheitsanforderungen an ComTech waren unzureichend: keine Benachrichtigungsfrist, kein Auditrecht, keine definierten Sicherheitsstandards
• Es gab keinen Plan B für den Fall, dass ComTech ausfällt

Die wichtigste Erkenntnis: Vertrauen ist keine Sicherheitsstrategie. In ISMS Lite lassen sich Dienstleisterbeziehungen dokumentieren, Sicherheitsanforderungen nachverfolgen und Vorfälle bei Supply-Chain-Incidents strukturiert aufarbeiten. Die Beziehung zu einem MSP muss auf denselben Prinzipien basieren wie jede andere sicherheitskritische Beziehung: minimale Rechte, maximale Transparenz, vertragliche Absicherung und regelmäßige Überprüfung. Das gilt unabhängig davon, wie lange die Zusammenarbeit besteht und wie vertrauenswürdig der Partner erscheint.

Weiterführende Artikel

• Supply-Chain-Angriffe: Risiken in der Lieferkette verstehen und absichern
• Lieferantenbewertung und Sicherheitsfragebogen: Dienstleister systematisch prüfen
• AVV prüfen und Dienstleister bewerten: DSGVO-konforme Auftragsverarbeitung
• NIS2 für IT-Dienstleister und MSPs: Was sich für Managed Service Provider ändert
• Zero Trust im Mittelstand: Vertraue niemandem, verifiziere alles