Ransomware-Angriffe auf MSPs: Ein Leitfaden zu Schutz und Wiederherstellung

Heute ist in 48% aller Datenschutzverletzungen ein Drittanbieter beteiligt, ein Plus von 60% innerhalb nur eines Jahres. ^[1] Für jeden Kunden in seinem Bestand ist ein Managed Service Provider (MSP) ein Drittanbieter – und meist derjenige mit dem privilegiertesten Zugriff.

Ein MSP-Ransomware-Angriff ist ein einzelner Einbruch, der alle Kunden auf einmal erreicht. Statt in fünfzig Unternehmen einzubrechen, kompromittiert der Angreifer das eine, das bereits privilegierten Zugriff auf alle fünfzig hat, und nutzt diesen Zugriff dann so, wie es ein Techniker tun würde.

Da 83% der Organisationen in den letzten zwei Jahren mindestens einen Ransomware-Angriff erlitten haben, ist es kein realistischer Plan mehr, Ransomware vollständig zu vermeiden. ^[2] Für einen MSP ist die planungsrelevante Frage nicht, ob eine Kundenumgebung getroffen wird, sondern wie viele gleichzeitig getroffen werden.

Dieser Leitfaden erläutert, warum Ransomware-Gruppen MSPs ins Visier nehmen, wie Angreifer von den Management-Tools eines MSP in Kundennetzwerke gelangen, warum gemeinsam genutzte Backup Anmeldedaten den Wiederherstellungsplan für jeden Kunden zunichtemachen können und wie mehrere Umgebungen gleichzeitig wiederhergestellt werden.

Wichtigste Erkenntnisse

• Ein einzelner Einbruch bei einem MSP kann Ransomware gleichzeitig an jeden Kunden ausliefern, weil der privilegierte Zugriff, der den Service ermöglicht, derselbe Zugriff ist, den ein Angreifer übernimmt.

• Remote-Monitoring- und -Management-(RMM-)Plattformen sind der wertvollste Einstiegspfad, weil ein RMM eine dauerhafte Verbindung zu jedem Kundennetzwerk aufrechterhält, die ein Angreifer intakt übernimmt.

• Gemeinsam genutzte Backup Administrator-Anmeldedaten entscheiden über den Ausgang eines MSP-Ransomware-Angriffs. Backup-Speicher mit Absolute Immutability ist das, was Backup Daten schützt, wenn diese Anmeldedaten in den Händen eines Angreifers sind.

Warum Ransomware-Gruppen MSPs ins Visier nehmen

Ransomware-Gruppen nehmen MSPs nicht ins Visier, weil sie leichter zu kompromittieren wären als die Kunden, die sie schützen, sondern weil ein einzelner Einbruch viele Opfer erzeugen kann und der Zugriff, der nötig ist, um sie zu erreichen, bereits vorhanden ist.

Es gibt vier Aspekte von MSPs, die sie zu hochwertigen Zielen für böswillige Akteure machen.

• Ein Einbruch, viele Opfer: Bei einem Supply-Chain-Angriff auf einen MSP erreicht der Angreifer die beabsichtigten Ziele über einen Lieferanten, dem diese Ziele bereits vertrauen. Die Kompromittierung eines einzelnen MSP kann Ransomware auf Dutzende oder Hunderte nachgelagerte Umgebungen ausbreiten, sodass der Aufwand pro Opfer auf einen Bruchteil dessen sinkt, was ein direkter Angriff kosten würde.

• Die Schlüssel kommen mit dem Vertrag: MSPs halten in jeder Kundenumgebung designbedingt hochprivilegierte Anmeldedaten, weil Remote-Administration der Service ist, für den Kunden bezahlen. Ein Angreifer, der diese Anmeldedaten übernimmt, erbt diese Reichweite, ohne sie sich erarbeiten zu müssen.

• Ein Playbook passt für jeden Kunden: Die Tooling-Landschaft, Namenskonventionen und Sicherheit Baselines, die ein MSP über seinen Bestand hinweg anwendet, machen ein großes Estate effizient betreibbar. Sie machen es auch effizient angreifbar, weil eine einmal durchgeführte Aufklärung tendenziell überall gilt.

• Regulierer kamen zum selben Schluss: Sowohl die EU als auch das Vereinigte Königreich haben Managed Service Provider als eigene Kategorie in Cybersicherheitsgesetze aufgenommen, statt sie wie gewöhnliche Unternehmen zu behandeln. Ihre Begründung entspricht der eines Angreifers: Ein kompromittierter MSP kann viele Organisationen gleichzeitig stören.

• Unter NIS2 ist das ICT-Service-Management einer der Anhang-I-Sektoren mit hoher Kritikalität und umfasst Anbieter von Managed Services und Managed Sicherheit Services. ^[3] Die Einstufung folgt dann der EU-Definition der Unternehmensgröße, sodass MSPs mit 250 oder mehr Beschäftigten oder mit einem Umsatz über 50 Mio. € und einer Bilanzsumme über 43 Mio. € als wesentliche Einrichtungen gelten. ^[4]

• Das Vereinigte Königreich bewegt sich in die gleiche Richtung. Sein Cyber Sicherheit and Resilience Bill ist noch kein Gesetz, aber wenn es Gesetz wird, schafft es eine Kategorie relevanter Managed Service Provider und setzt die Incident-Meldung auf 24 und 72 Stunden fest. ^[5]

Wie Angreifer über Ihr RMM in einen MSP gelangen

Jeder MSP basiert auf zwei Plattformen. Remote-Monitoring- und -Management-(RMM-)Software gibt Technikern eine dauerhafte Verbindung zu jedem Kundennetzwerk. Professional-Services-Automation-(PSA-)Software enthält die Tickets, Verträge und Kundendatensätze, die beschreiben, was sich in diesen Netzwerken befindet. Das RMM ist das wertvollere Ziel, weil es Kundenumgebungen nicht nur beschreibt, sondern sie auch erreicht.

In diese Plattform einzudringen, erfolgt üblicherweise über einen von zwei Wegen. Der erste ist ein Management-Server, der ohne aktuelle Patches dem Internet ausgesetzt bleibt, und das Ausnutzen einer Software-Schwachstelle ist inzwischen mit 31% der mit Abstand größte Ausgangspunkt für Sicherheitsverletzungen. ^[1] Der zweite ist ein Techniker-Konto ohne Multi-Faktor-Authentifizierung, bei dem ein gestohlenes Passwort allein ausreicht.

Beide Wege enden am selben Punkt. Der Angreifer eskaliert die Berechtigungen innerhalb der Plattform und verteilt dann Ransomware über die eigenen Agents des MSP – mit demselben Mechanismus, den Techniker zum Ausrollen von Patches und Skripten verwenden. Auf einem Monitoring-Dashboard sieht dieser Push wie ein geplantes Software-Update aus, was diese Angriffe so schwer erkennbar macht.

Akteure von DragonForce haben genau das 2025 getan. Sie haben wahrscheinlich drei Schwachstellen in SimpleHelp, dem RMM-Tool, das ein MSP für seine Kunden gehostet hat, verkettet und diesen Zugriff dann genutzt, um deren Netzwerke zu kartieren, bevor sie Ransomware ausrollten und Daten stahlen. ^[6]

Zu diesem Zeitpunkt verfügt der Angreifer über Administratorrechte in jeder Umgebung, die das RMM berührt – einschließlich der Konsolen, die die Backups steuern.

Kann ein gestohlener Admin-Login alle Client-Backups auslöschen?

In vielen MSPs steuert ein einziges Backup-Administratorkonto die Backups für jeden Client, sodass die Zugangsdaten, die ein Angreifer stiehlt, um sich durch Client-Umgebungen zu bewegen, häufig auch den Wiederherstellungsplan für alle bestimmen. MSPs landen hier, weil gemeinsame Konsolen das Management von 50+ Clients wirtschaftlich machen, und dieser Trade-off ist eine der MSP-Backup-Herausforderungen beim gleichzeitigen Betrieb vieler Umgebungen.

Dieses Konto ist auch der Zugang zu den Datensicherungen. Viele MSPs betreiben ein Hybridmodell, bei dem sie eine lokale Kopie an jedem Client-Standort und eine Offsite-Kopie in ihrem eigenen Rechenzentrum vorhalten, um die 3-2-1-1-0-Regel zu erfüllen: drei Kopien, auf zwei unterschiedlichen Medien, eine Offsite, eine unveränderlich und null Fehler bei der Restore-Verifizierung.

Wenn eine Konsole beide steuert, kann ein einzelner gestohlener Login beide erreichen. Angreifer suchen gezielt nach Backups, um die Wiederherstellung zu blockieren und Lösegeldzahlungen zu erzwingen, und ohne sie ist Lösegeld der einzige Ausweg. Ein Grundpfeiler von Datensicherung und Wiederherstellung ist das Vorhalten unveränderlicher Backups, was bedeutet, dass innerhalb eines vordefinierten Zeitfensters ein Backup nicht verändert oder gelöscht werden kann.

Hier ist jedoch Vorsicht geboten, denn viele Systeme, die behaupten, unveränderliche Backups anzubieten, haben versteckte Ausnahmen und Schlupflöcher. Das häufigste ist eine Einstellung: S3 Object Lock im Governance-Modus erlaubt es einem Benutzer mit spezifischen Override-Berechtigungen, die Sperre zu entfernen – genau das, was ein gestohlenes Backup-Administratorkonto ermöglicht.

Eine Lösung dafür ist Absolute Immutability, was bedeutet, dass selbst der privilegierteste Admin oder ein Angreifer mit Zugriff auf Backup-Speicher keine Daten ändern oder löschen kann. Dieses Niveau an Ransomware-sicheres Backup-Schutz lässt sich nur mit einem Backup-Speicher-System erreichen, das Sicher-by-Design ist, mit Zero Access zur Ausführung destruktiver Aktionen. Dieser Zero Access muss außerdem durch Tests von Drittanbietern verifizierbar sein.

Unter IT-Führungskräften sagen 93 %, Backup-Speicher müsse Backups selbst dann schützen, wenn Angreifer die IT-Geheimnisse einer Organisation kennen, während nur 16 % sagen, ihr Storage sei absolut unveränderlich. ^[2] Für einen MSP entscheidet diese Lücke darüber, ob die unveränderliche Kopie in einem 3-2-1-1-0-Setup einen gestohlenen Login überlebt – für jeden Client gleichzeitig.

Wie man mehrere Clients nach einem MSP-Ransomware-Angriff wiederherstellt

Ob ein Angriff die Backups eines Clients oder alle betrifft, wird überwiegend durch die Architektur entschieden, nicht dadurch, wie gut der Vorfall gehandhabt wird. So oder so sieht die Arbeit gleich aus: Viele Client-Umgebungen werden gleichzeitig wiederhergestellt, über eine einzige Pipeline, wobei jeder Client erwartet, als Erster dran zu sein. Was sich ändert, ist, wie viel überhaupt noch wiederherzustellen ist.

Organisationen stellen außerdem weniger wieder her als früher: Unter den von Ransomware Betroffenen haben 2026 nur 39 % mindestens 75 % ihrer Daten wiederhergestellt, gegenüber 57 % im Jahr 2024. ^[2]

Trennen Sie Ihre eigenen Tools ab, bevor Sie Client-Systeme anfassen

Trennen Sie zuerst die RMM- und PSA-Plattformen, bevor irgendwelche Remediation-Arbeiten an Client-Systemen beginnen. Wenn der Angreifer weiterhin Zugriff auf den Deployment-Mechanismus hat, können Systeme, die morgens bereinigt wurden, am Nachmittag erneut verschlüsselt werden.

Das bedeutet, Remote-Access-Tools zu deaktivieren, aktive Sessions zu beenden, API-Tokens und Integrationsschlüssel zu widerrufen und die Plattform auf Konten, Skripte und geplante Tasks zu prüfen, die der Angreifer hinzugefügt hat. Client-Systeme bleiben isoliert, bis bestätigt ist, dass die Management-Ebene sauber ist.

Bestätigen Sie, welche Backups überlebt haben, bevor Sie irgendjemandem einen Zeitplan zusagen

Wenn die Plattform eingedämmt ist, ermitteln Sie, welche Client-Backups intakt sind, welche verschlüsselt oder gelöscht wurden und wie weit der letzte saubere Restore-Punkt für jedes einzelne zurückliegt. Ein Wiederherstellungsplan, der auf Backups basiert, die niemand verifiziert hat, ist eine Vermutung mit angehängten Daten.

Prüfen Sie jeden Restore-Punkt gegen das Datum der initialen Kompromittierung statt gegen das Datum, an dem die Ransomware lief. Angreifer halten den Zugriff oft Tage oder Wochen aufrecht, bevor sie die Verschlüsselung auslösen, sodass ein Restore-Punkt innerhalb dieses Fensters den Einstiegspunkt erneut einführen kann.

Wo Backup-Speicher absolut unveränderlich ist, legt dieser Schritt fest, welchen Restore-Punkt man verwendet. Wo das nicht der Fall ist, legt er fest, wie viel verloren gegangen ist – und für manche Clients entscheidet die Antwort, ob Wiederherstellung überhaupt eine Option ist.

Stellen Sie in der Reihenfolge wieder her, die der Vertrag bereits festlegt

Zu wissen, was überlebt hat, sagt Ihnen, was laufen kann, aber nicht, was zuerst läuft. Diese Reihenfolge sollte im Voraus festgelegt werden, schriftlich, auf benannten Grundlagen: vertragliche Recovery Time Objective (RTO)-Zusagen, regulatorische Exponierung und geschäftliche Kritikalität. Beachten Sie, dass das Volumen der Telefonanrufe nach dem Ereignis nicht dazugehört!.

Das vor einem Vorfall zu vereinbaren, nimmt die Verhandlung aus dem denkbar schlechtesten Moment heraus und gibt Account Managern etwas, worauf sie verweisen können, wenn dreißig Clients gleichzeitig dieselbe Frage stellen. Ein dokumentierter Ransomware-Response-Plan ist der Ort, an dem diese Reihenfolge festgehalten ist – zusammen mit den Rollen, Eskalationspfaden und Client-Kommunikationsaufgaben, die damit einhergehen.

Planen Sie für Restore-Durchsatz, nicht für Restore-Zeit pro Client

Die Reihenfolge zu kennen, sagt Ihnen nicht, wie lange es dauert. Ein Restore, der bei einem Client eine Stunde läuft, läuft über dreißig hinweg Tage, weil – wenn die On-Site-Kopien verloren sind – jeder Client gleichzeitig aus dem Rechenzentrum des MSP wiederherstellt, und der Engpass dann diese gemeinsame Pipeline wird, einschließlich der Verbindungen zu jedem Client-Standort, statt irgendeines einzelnen Jobs. Der über das gesamte Estate gemessene Restore-Durchsatz ist die Kennzahl, die entscheidet, wie lange der Vorfall dauert, und es lohnt sich, ihn zu testen, bevor man ihn braucht.

Storage-Tiering ist das, was diese Kennzahl verschiebt. In einem Veeam Scale-out-Backup-Repository hält die Performance-Tier aktuelle Daten für schnelle Restores, während die Capacity- und Archive-Tiers längere Aufbewahrung zu geringeren Kosten tragen.

Aktuelle Client-Backups auf On-Premises-Backup-Speicher am Client-Standort in der Performance-Tier vorzuhalten bedeutet, dass die dringendsten Restores mit lokaler Netzwerkgeschwindigkeit laufen, sodass die Wiederherstellung von Daten nach einem Ransomware-Angriff nicht hinter der Offsite-Kopie im Rechenzentrum des MSP ansteht, die für langfristige Aufbewahrung ausgelegt ist.

Die Meldeuhr startet, bevor der Restore fertig ist

Meldepflichten warten nicht auf den Restore. Sie beginnen, sobald ein MSP von dem Vorfall Kenntnis erlangt, sodass unter NIS2 eine Frühwarnung innerhalb des ersten Tages fällig ist und eine ausführlichere Meldung innerhalb von drei Tagen. ^[7] Beide fallen an, während Restores noch laufen. Der UK Bill folgt demselben zweistufigen Muster. ^[5]

Auch die Wiederherstellung der Daten schließt die Angelegenheit nicht. Ransomware-Operatoren stehlen Daten oft, bevor sie sie verschlüsseln, sodass eine saubere Ransomware-Wiederherstellung neben einem meldepflichtigen Breach für den MSP und betroffene Clients stehen kann. Rechtsbeistand und der Cyber-Versicherer sollten am ersten Tag in die Reaktion einbezogen werden, nicht erst, wenn Systeme wieder online sind.

Backup-Speicher entwickelt für MSP-Flexibilität

MSPs benötigen Backup-Speicher, das Unkompliziert zu betreiben ist, resilient gegen Ransomware und flexibel genug, um unterschiedliche Client-Umgebungen zu unterstützen – an Client-Standorten und im eigenen Rechenzentrum des MSP.

Traditionelle Lösungen erfordern oft manuelles Hardening, stützen sich auf fragmentierte Tools und zwingen MSPs in starre Preismodelle, die das Wachstum bremsen.

Object First Ootbi macht Veeam Daten mit Absolute Immutability Sicher, sodass niemand – nicht einmal der privilegierteste Admin oder ein Angreifer mit Zugriff auf Backup-Speicher – Backup-Daten ändern oder löschen kann.

Die Durchsetzung sitzt im Storage selbst statt in Software-Policy, sodass sie nicht durch Zugangsdaten, Konfigurationsänderungen oder Remote-Kommandos deaktiviert werden kann, und destruktive Aktionen werden vollständig aus der Administrationsoberfläche entfernt, statt nur über Berechtigungen zu sperren.

Für die oben beschriebenen Ausfälle bedeutet das:

• Ein gestohlenes Backup-Administratorkonto kann sich weiterhin anmelden und wiederherstellen, was die Wiederherstellung erfordert, kann aber Backups nicht verändern oder löschen.

• Ransomware, die über die eigenen Agents des MSP ausgerollt wird, kann neue Backups schreiben, kann aber nicht ändern, was bereits geschrieben ist, weil Immutability in dem Moment greift, in dem jedes Backup ankommt.

• Eine Konsole, die in einem Hybrid-Setup beide Kopien erreicht, kann die Sperre bei keiner von beiden aufheben, weil die Durchsetzung in jeder Appliance sitzt.

MSPs können ihr Management mehrerer Deployments mit dem cloudbasierten Monitoring-Tool Fleet Manager vereinfachen. Beim Kauf von Appliances können MSPs zwischen verbrauchsbasierter und CapEx-Abonnement-Preisgestaltung wählen, um sie an ihr Geschäftsmodell anzupassen.

Laden Sie das Whitepaper herunter, um die Herausforderungen zu entdecken, denen MSPs gegenüberstehen, und wie Object First Ransomware-sicheres Backup-Speicher bereitstellt und gleichzeitig Operativer Overhead reduziert.

FAQ

Sollten Sie das Lösegeld zahlen?

Zahlen garantiert keine funktionierenden Entschlüsselungsschlüssel, und das Geld finanziert eine Operation, die wieder angreifen wird. Ein MSP mit verifizierten, absolut unveränderlichen Backups kann Client-Umgebungen ohne Verhandlungen wiederherstellen, womit sich die Frage erledigt.

Was ist der beste Ransomware-Schutz für MSPs?

Der kurze Stack ist Multi-Faktor-Authentifizierung auf RMM- und PSA-Plattformen, zeitnahes Patchen internetexponierter Management-Tools sowie getrennte Zugangsdaten und Storage-Ziele für jeden Client. All das reduziert die Wahrscheinlichkeit eines Breaches, während Backup-Speicher mit Absolute Immutability entscheidet, ob ein MSP sich von einem erholen kann.

Verlangt NIS2 von MSPs, dass sie sich von Ransomware erholen können?

Artikel 21 führt Business Continuity, einschließlich Backup-Management und Disaster Recovery, unter den Risikomanagement-Maßnahmen auf, die In-Scope-Entitäten implementieren müssen, und das Management von IKT-Diensten ist in Anhang I als Sektor hoher Kritikalität aufgeführt. ^[3] Die Richtlinie nennt keine spezifische Technologie, daher besteht die Verpflichtung darin, nachzuweisen, dass Wiederherstellung tatsächlich funktioniert – was MSPs anhand der vollständigen Liste der NIS2-Risikomanagement-Maßnahmen verifizieren können.

Quellen

[1] Verizon. "Vulnerability exploitation is top breach entry point, 2026 DBIR finds." 2026. https://www.verizon.com/about/news/breach-industry-wide-dbir-finds

[2] Omdia. "Recovery without Compromise: The Data-Backed Case for Backup Storage with Absolute Immutability." Research commissioned by Object First. 2026. https://objectfirst.com/recovery-without-compromise/

[3] European Parliament and Council. "Directive (EU) 2022/2555 (NIS2)." 2022. https://eur-lex.europa.eu/eli/dir/2022/2555/oj

[4] European Commission. "Commission Recommendation 2003/361/EC concerning the definition of micro, small and medium-sized enterprises." 2003. https://eur-lex.europa.eu/eli/reco/2003/361/oj

[5] UK Parliament. "Cyber Security and Resilience (Network and Information Systems) Bill, HL Bill 32 of 2026-27." 2026. https://bills.parliament.uk/bills/4035

[6] Sophos. "DragonForce actors target SimpleHelp vulnerabilities to attack MSP, customers." 2025. https://www.sophos.com/en-us/blog/dragonforce-actors-target-simplehelp-vulnerabilities-to-attack-msp-customers/

[7] European Parliament and Council. "Directive (EU) 2022/2555 (NIS2), Article 23." 2022. https://eur-lex.europa.eu/eli/dir/2022/2555/oj