Threat Intelligence

RansomHouse

Seit 2021 durchgehend aktiv – und seit Ende 2025 mit einem überarbeiteten Verschlüsseler, der eine Wiederherstellung ohne Schlüssel praktisch ausschließt. Ziel Nummer eins: die Virtualisierung.

Kurz erklärt

RansomHouse ist eine der langlebigsten Erpressergruppen überhaupt: seit 2021 aktiv, über 200 gelistete Opfer in 48 Ländern – und das ohne die sonst üblichen Rebrands nach einer Zerschlagung. Begonnen hat die Gruppe als reiner Marktplatz für gestohlene Daten, mit der Behauptung, selbst gar nicht zu verschlüsseln. Diese Selbstdarstellung ist längst überholt: Heute betreibt RansomHouse ein vollwertiges Partnerprogramm mit eigener Verschlüsselungs-Schadsoftware.

Der Angriff zielt auf die Virtualisierung. Statt hunderte Einzelrechner zu verschlüsseln, übernimmt die Gruppe die VMware-ESXi-Hosts und legt dort ein eigenes Steuerprogramm namens MrAgent ab: Es schaltet die Host-Firewall ab, meldet sich bei den Angreifern zurück und startet die Verschlüsselung aller virtuellen Maschinen auf einmal. Für Betroffene bedeutet das den Ausfall der gesamten Serverlandschaft binnen Minuten – einschließlich der Systeme, mit denen man den Vorfall bearbeiten würde.

Ende 2025 hat die Gruppe ihren Verschlüsseler grundlegend überarbeitet. Statt einer einfachen, gleichmäßigen Verschlüsselung arbeitet die neue Fassung zweistufig mit zwei Schlüsseln und wechselnden Blockgrößen. Praktische Folge: Teilrettungen von Dateien und Versuche, Schlüssel aus dem Arbeitsspeicher zu rekonstruieren, laufen ins Leere. Wer keine funktionierenden, getrennt aufbewahrten Backups hat, hat nach einem RansomHouse-Angriff faktisch keine technische Option mehr.

Aktiv

Modell

Ransomware-as-a-Service mit Partnerprogramm; Leak-Site, Verhandlungsportal und ein eigener „Datenmarkt“ für nicht bezahlte Vorfälle

Auch bekannt als

RansomHouse, Ransom House; die eingesetzten Verschlüsseler laufen unter den Namen Mario und Mario ESXi, die frühe Linie als White Rabbit. Sicherheitsforscher führen den Betreiber als „Jolly Scorpius“.

Gegründet

Erste Opfer ab Mitte 2021, öffentliche Leak-Site seit Dezember 2021

Entstanden aus

Keine belegte Vorgängergruppe. Die Gruppe startete als reiner Marktplatz für gestohlene Daten und behauptete, selbst nicht zu verschlüsseln; später kam eigene Verschlüsselungs-Schadsoftware hinzu. Zeitweise wurden Daten aus fremden Vorfällen mitvermarktet.

Herkunft

Nicht abschließend zugeordnet – russischsprachiges Umfeld wird angenommen, eine belastbare staatliche oder nationale Zuschreibung existiert nicht

Zielsektoren

Gesundheitswesen, Finanz- und Versicherungsdienstleister, Transport und Logistik, Regierung und Verwaltung, Fertigung, Handel, Technologie

Zielregionen

48 Länder weltweit; Schwerpunkte Nordamerika und Europa. DACH-Bezug belegt: mehrere deutsche Opfer sowie je Einträge in Österreich und der Schweiz.

Typisches Lösegeld

Öffentlich nicht einheitlich beziffert – die Forderungen richten sich nach Unternehmensgröße und Umfang der erbeuteten Daten; berichtet werden sechs- bis siebenstellige US-Dollar-Beträge

Opferzahl

206 gelistete Opfer in 48 Ländern seit 2021; letztes gelistetes Opfer am 1. September 2026 (Stand: 2. September 2026)

File Extensions

.scrypt (dokumentiert für die frühe White-Rabbit-Linie); für den Mario-Verschlüsseler ist keine einheitliche öffentliche Endungsangabe belegt

Ransom Note

How To Restore Your Files.txt (Mario); in der White-Rabbit-Linie zusätzlich je Datei eine Notiz nach dem Muster [Dateiname].scrypt.txt

Akut betroffen?
+49 89 45 24 24 112
24/7 erreichbar · Ersteinschätzung im Erstgespräch

Handlungsempfehlungen im Ernstfall

✅ Sofort tun
  • Zuerst die Virtualisierung sichern: ESXi-Hosts und vCenter vom übrigen Netz trennen, Verwaltungszugänge sperren, laufende Sitzungen beenden. Hier entscheidet sich, ob aus einem Vorfall ein Totalausfall wird.
  • Betroffene Systeme isolieren, aber nicht ausschalten – flüchtige Spuren im Arbeitsspeicher bleiben so erhalten.
  • Auf dem Hypervisor nach unbekannten dauerhaften Prozessen und deaktivierten Host-Firewalls suchen – das ist die Handschrift der Steuerkomponente MrAgent.
  • Sicherungen sofort schreibgeschützt trennen: Veeam-Sicherungsdateien gehören ausdrücklich zu den Zieldateien der Gruppe.
  • Alle Administratorzugangsdaten zurücksetzen, insbesondere die der Virtualisierungsverwaltung; Mehr-Faktor-Anmeldung erzwingen.
  • Umfang des Datenabflusses feststellen – die Veröffentlichung erfolgt unabhängig davon, ob die Verschlüsselung erfolgreich war.
  • Meldepflichten prüfen: Datenschutzaufsicht binnen 72 Stunden (DSGVO Art. 33), bei NIS2-Betroffenheit Erstmeldung binnen 24 Stunden; Strafanzeige bei Polizei oder ZAC erwägen.
  • Incident Response aktivieren – die Wiederherstellung einer vollständig verschlüsselten Virtualisierungsumgebung ist ein Projekt, kein Handgriff.
⛔ Unbedingt vermeiden
  • Nicht darauf hoffen, dass Dateien teilweise zu retten sind: Die überarbeitete Fassung des Verschlüsselers macht Teilrettungen und Schlüsselrekonstruktion praktisch unmöglich.
  • Backups nicht in dieselbe virtualisierte Umgebung zurückspielen, solange nicht sicher ist, dass die Angreifer keinen Zugang mehr haben.
  • Den Hypervisor nicht „schnell neu aufsetzen“, bevor die Forensik gesichert ist – sonst ist unklar, wie die Angreifer hereinkamen, und der nächste Angriff folgt über denselben Weg.
  • Nicht auf eigene Faust verhandeln – die Gruppe vermarktet nicht bezahlte Datensätze weiter; das erfordert eine durchdachte Strategie.
  • Nicht vorschnell zahlen: keine Garantie für Entschlüsselung oder Löschung; Zahlungen können sanktions- und strafrechtlich relevant sein.
  • Den Datenabfluss nicht als Nebensache behandeln, nur weil die Systeme wieder laufen – die Meldepflichten knüpfen an die Daten an, nicht an die Verfügbarkeit.

Bekannte Angriffe

  • DACH-Opfer (Auswahl): in Deutschland unter anderem Astro- und Feinwerktechnik Adlershof (Astrofein), die Oettinger Brauerei, die Unternehmensgruppe Hellmich und ein Unternehmen der WEBER-Gruppe; in Österreich Lopesan Hotels, in der Schweiz Soleol und Vennerhus Weine.
  • Keralty (Kolumbien, 2022) – Angriff auf einen der größten Gesundheitsdienstleister Lateinamerikas; Kliniken mussten Termine absagen, die Auswirkungen zogen sich über Wochen.
  • AMD (2022) – die Gruppe behauptete, rund 450 GB interne Daten des Chipherstellers erbeutet zu haben; das Unternehmen bestätigte eine Untersuchung.
  • Laufende Kampagne 2026 – Veröffentlichungen bis zum 1. September 2026, zuletzt mit rückläufiger Frequenz.
  • Nennungen auf Leak-Sites sind Eigenangaben der Täter. RansomHouse hat in der Vergangenheit auch Daten aus fremden Vorfällen vermarktet – Umfang und Herkunft eines Datensatzes sind daher stets eigenständig zu prüfen.

Angriffstechniken (TTPs)

  • Initialer Zugang:
    • Spear-Phishing gegen Administratoren und Fachanwender – T1566
    • Gestohlene oder gekaufte gültige Zugangsdaten, exponierte Fernzugänge – T1078, T1133
    • Ausnutzung von Schwachstellen in von außen erreichbaren Diensten – T1190
  • Ausbreitung und Vorbereitung:
    • Aufklärung im Netz, Identifikation der Virtualisierungs- und Backup-Infrastruktur
    • Ablage der Steuerkomponente MrAgent direkt auf ESXi-Hosts; sie hält eine Verbindung zum Steuerserver der Angreifer und nimmt Befehle entgegen (unter anderem Exec, Config, Info, Run, Remove, Abort)
    • Abschalten der Host-Firewall und Ermitteln von Host-Kennungen und IP-Adressen – T1562.004
  • Datendiebstahl:
    • Ausleitung großer Datenmengen vor der Verschlüsselung – T1567
  • Auswirkung:
    • Zentral ausgelöste Verschlüsselung aller virtuellen Maschinen eines Hosts – T1486
    • Gezielt adressierte Virtualisierungsdateien: .vmdk, .vmem, .vmsd, .vmsn, .vswp, .ova, .ovf sowie Veeam-Sicherungsdateien .vbk, .vbm, .vib – damit trifft der Angriff Produktivsysteme und Sicherungen zugleich
  • Erpressung:
    • Leak-Site, Verhandlungsportal und Weitervermarktung nicht bezahlter Datensätze – T1657

Technologie & Malware

MrAgent – die Steuerkomponente: Ein eigens für VMware ESXi geschriebenes Programm, das auf dem Hypervisor selbst läuft. Es hält eine Verbindung zum Steuerserver der Angreifer, deaktiviert die Host-Firewall, sammelt Host-Kennungen und IP-Adressen und nimmt Befehle entgegen, um die Verschlüsselung auf mehreren Hosts gleichzeitig auszulösen. Teile des Codes sind mit Füllcode verschleiert.

Mario – der Verschlüsseler: Existiert in einer ursprünglichen und einer Ende 2025 überarbeiteten Fassung. Die alte Version arbeitete linear mit einer festen Blockgröße von 0xA00000. Die neue Version verschlüsselt zweistufig mit zwei Schlüsseln – einem primären mit 32 Byte und einem sekundären mit 8 Byte –, wählt Blockgrößen dynamisch bis zu 8 GB und verschlüsselt gezielt einzelne Abschnitte großer Dateien statt durchgängig.

Warum das für Betroffene zählt: Durch die zweistufige Verarbeitung mit wechselnden Blockgrößen sind Teilrettungen einzelner Dateiabschnitte und die Rekonstruktion von Schlüsseln aus dem Arbeitsspeicher praktisch ausgeschlossen. Was früher gelegentlich forensisch zu retten war, ist heute verloren. Die Verteidigung muss deshalb vor der Verschlüsselung greifen – danach entscheidet allein die Qualität der Backups.

White Rabbit: Die frühe Linie (2021/22) verschlüsselte mit Endung .scrypt und legte je Datei eine eigene Notiz ab. Sie wird derselben Struktur zugerechnet.

Indicators of Compromise (IOCs)

  • Erpressernotiz: How To Restore Your Files.txt (Mario); [Dateiname].scrypt.txt (White-Rabbit-Linie)
  • SHA-256, Mario (überarbeitete Fassung): 0fe7fcc66726f8f2daed29b807d1da3c531ec004925625855f8889950d0d24d8
  • SHA-256, Mario (ursprüngliche Fassung): d36afcfe1ae2c3e6669878e6f9310a04fb6c8af525d17c4ffa8b510459d7dd4d
  • SHA-256, MrAgent: 26b3c1269064ba1bf2bfdcf2d3d069e939f0e54fc4189e5a5263a49e17872f2a
  • SHA-256, MrAgent: 8189c708706eb7302d7598aeee8cd6bdb048bf1a6dbe29c59e50f0a39fd53973
  • Zieldateitypen: .vmdk, .vmem, .vmsd, .vmsn, .vswp, .ova, .ovf sowie .vbk, .vbm, .vib
  • Verhaltensindikator: deaktivierte ESXi-Host-Firewall, unbekannter dauerhafter Prozess auf dem Hypervisor mit ausgehender Verbindung, ungewöhnliche SSH-Anmeldungen an ESXi-Hosts
  • Indikatoren vor dem Blocken gegen aktuelle Threat-Intelligence-Quellen prüfen.

Was Unternehmen jetzt prüfen sollten

  • Sind Ihre ESXi-Hosts und die Verwaltungsoberfläche (vCenter) in einem eigenen, streng abgeschotteten Netzsegment – und nicht über das normale Büronetz erreichbar?
  • Ist der SSH-Zugang zu den Hypervisoren abgeschaltet oder zumindest auf feste Quellen beschränkt, mit Mehr-Faktor-Anmeldung für die Verwaltung?
  • Würde auffallen, wenn die Firewall eines ESXi-Hosts deaktiviert wird oder dort ein unbekannter Prozess dauerhaft läuft? Werden Hypervisor-Protokolle überhaupt zentral ausgewertet?
  • Liegen Ihre Sicherungen außerhalb der virtualisierten Umgebung – unveränderlich oder offline? Die Gruppe verschlüsselt Veeam-Sicherungsdateien gezielt mit.
  • Wurde eine vollständige Wiederherstellung des Virtualisierungs-Stacks schon einmal geübt – einschließlich der Frage, womit man arbeitet, wenn alle virtuellen Maschinen gleichzeitig weg sind?
  • Sind Administratorkonten für die Virtualisierung von den allgemeinen Windows-Administratorkonten getrennt?

Wie Argos unterstützt

Bei RansomHouse entscheidet sich der Schaden auf der Virtualisierungsebene – und genau dort schauen die meisten Sicherheitswerkzeuge nicht hin. Das Cyber Defense Center von Argos Security bindet Hypervisoren und Verwaltungssysteme ausdrücklich in die 24/7-Überwachung ein und alarmiert bei den Vorboten dieses Angriffs: abgeschaltete Host-Firewalls, unbekannte dauerhafte Prozesse auf ESXi, ungewöhnliche SSH-Anmeldungen, große Datenübertragungen nach außen.

Da eine Entschlüsselung ohne Schlüssel bei der neuen Fassung des Verschlüsselers praktisch ausgeschlossen ist, prüfen wir im Rahmen unserer Vorbereitungsleistungen gezielt, ob Ihre Sicherungen den Angriff überleben würden – also unveränderlich, getrennt und wiederherstellbar sind. Im Ernstfall übernimmt unser Incident-Response-Team Eindämmung, Forensik und den geordneten Wiederanlauf der Virtualisierung und begleitet Meldepflichten und Krisenkommunikation.