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

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

Ein MSP-Ransomware-Angriff ist ein einzelner Einbruch, der alle Kunden gleichzeitig 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 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 lautet die planungsrelevante Frage nicht, ob eine Kundenumgebung getroffen wird, sondern wie viele gleichzeitig getroffen werden.

Dieser Leitfaden behandelt, warum Ransomware-Gruppen MSPs ins Visier nehmen, wie Angreifer von den Management-Tools eines MSP in Kundennetzwerke wechseln, 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 in einen 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-and-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 MSP-Lieferkettenangriff 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 hochprivilegierte Anmeldedaten – designbedingt –, 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 einen großen Bestand effizient betreibbar. Sie machen ihn 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 ICT-Service-Management einer der Sektoren mit hoher Kritikalität in Anhang I 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 steuert in dieselbe 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 Meldefristen für Vorfälle auf 24 und 72 Stunden. ^[5]

Wie Angreifer über Ihr RMM in einen MSP gelangen

Jeder MSP basiert auf zwei Plattformen. Remote-Monitoring-and-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 größte einzelne 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 diese Verteilung wie ein geplantes Software-Update aus, was diese Angriffe so schwer erkennbar macht.

DragonForce-Akteure 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 Kunden-Backups auslöschen?

In vielen MSPs steuert ein Backup-Administratorkonto die Backups für jeden Kunden, sodass die Anmeldedaten, die ein Angreifer stiehlt, um sich durch Kundenumgebungen zu bewegen, oft den Wiederherstellungsplan für alle regeln. MSPs landen hier, weil gemeinsam genutzte Konsolen das Management von 50+ Kunden wirtschaftlich machen, und dieser Trade-off ist eine der MSP-Backup-Herausforderungen beim Betrieb vieler Umgebungen gleichzeitig.

Dieses Konto ist auch der Weg zu den Datensicherungen. Viele MSPs betreiben ein Hybridmodell, bei dem sie eine lokale Kopie an jedem Kundenstandort 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 jagen 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; das bedeutet, dass während eines vordefinierten Zeitfensters ein Backup nicht verändert oder gelöscht werden kann.

Hier ist jedoch Vorsicht geboten, weil viele Systeme, die behaupten, unveränderliche Backups anzubieten, versteckte Ausnahmen und Schlupflöcher haben. 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 kann nur mit einem Backup-Speicher-System erreicht werden, das Sicher-by-Design ist – mit Zero Access, um destruktive Aktionen auszuführen. Dieser Zero Access muss außerdem durch Tests durch Dritte verifizierbar sein.

Unter IT-Führungskräften sagen 93%, Backup-Speicher müsse Backups schützen, selbst 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 übersteht – für jeden Kunden gleichzeitig.

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

Ob ein Angriff die Backups eines Kunden oder alle nimmt, wird überwiegend durch die Architektur entschieden – nicht dadurch, wie gut der Vorfall gehandhabt wird. In beiden Fällen sieht die Arbeit gleich aus: Viele Kundenumgebungen werden gleichzeitig wiederhergestellt, über eine einzige Pipeline, wobei jeder Kunde 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 Kundensysteme anfassen

Trennen Sie zuerst die RMM- und PSA-Plattformen, bevor irgendwelche Behebungsarbeiten an Kundensystemen 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. Kundensysteme 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

Nachdem die Plattform eingedämmt ist, stellen Sie fest, welche Kunden-Backups intakt sind, welche verschlüsselt oder gelöscht wurden und wie weit der letzte saubere Wiederherstellungspunkt 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 Wiederherstellungspunkt 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; ein Wiederherstellungspunkt innerhalb dieses Fensters kann den initialen Zugriff erneut einschleusen.

Wo Backup-Speicher absolut unveränderlich ist, legt dieser Schritt fest, welchen Wiederherstellungspunkt man verwendet. Wo das nicht der Fall ist, legt er fest, wie viel verloren gegangen ist – und für manche Kunden 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 geklärt 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 Kunden gleichzeitig dieselbe Frage stellen. Ein dokumentierter Ransomware-Reaktionsplan ist der Ort, an dem diese Reihenfolge festgehalten ist – zusammen mit den Rollen, Eskalationspfaden und Pflichten zur Kundenkommunikation, die dazugehören.

Planen Sie für Restore-Durchsatz, nicht für die 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 Kopien vor Ort verloren gehen, jeder Client gleichzeitig aus dem Rechenzentrum des MSP wiederherstellt und die Einschränkung zu dieser gemeinsamen Pipeline wird, einschließlich der Verbindungen zu jedem Client-Standort, statt zu irgendeinem einzelnen Job. Der über die gesamte Umgebung gemessene Restore-Durchsatz ist die Kennzahl, die entscheidet, wie lange der Vorfall dauert, und es lohnt sich, ihn zu testen, bevor er benötigt wird.

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 Kapazitäts- und Archiv-Tiers längere Aufbewahrung zu geringeren Kosten tragen.

Aktuelle Client-Backups auf On-Premises-Backup-Speicher am Client-Standort in der Performance-Tier zu halten, 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, das für langfristige Aufbewahrung ausgelegt ist.

Die Reporting-Uhr startet, bevor der Restore abgeschlossen ist

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

Die Wiederherstellung der Daten schließt die Angelegenheit ebenfalls nicht ab. Ransomware-Akteure stehlen Daten oft, bevor sie sie verschlüsseln, sodass eine saubere Ransomware-Wiederherstellung neben einer meldepflichtigen Datenschutzverletzung 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 Sicher mit Absolute Immutability und stellt sicher, dass niemand, nicht einmal der am höchsten privilegierte Admin oder ein Angreifer mit Zugriff auf Backup-Speicher, Backup Daten verändern oder löschen kann.

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

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-Abonnementpreisgestaltung 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-sicheren 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 erneut angreifen wird. Ein MSP mit verifizierten, absolut unveränderlichen Backups kann Client-Umgebungen ohne Verhandlungen wiederherstellen, wodurch sich die Frage erübrigt.

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

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

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

Artikel 21 nennt Business Continuity, einschließlich Backup-Management und Disaster Recovery, unter den Risikomanagement-Maßnahmen, die betroffene Einrichtungen umsetzen müssen, und das Management von IKT-Services ist in Anhang I als Sektor von hoher Kritikalität aufgeführt. ^[3] Die Richtlinie nennt keine spezifische Technologie, daher besteht die Verpflichtung darin nachzuweisen, dass die 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