RansomHouse wzmacnia szyfrowanie: „Mario” przechodzi na wielowarstwowe przetwarzanie danych

Wprowadzenie do problemu / definicja luki

Ransomware od dawna nie jest już „tylko” szyfrowaniem plików. Dla wielu grup to kompletna platforma wymuszeń: kradzież danych, presja medialna, szantaż prawny i dopiero na końcu — szyfrowanie infrastruktury krytycznej (często wirtualizacji i kopii zapasowych). RansomHouse to dobry przykład takiej ewolucji: start jako operacja data extortion, a dziś rozwijanie własnych narzędzi do blokowania środowisk, szczególnie VMware ESXi.

W grudniu 2025 badacze i media opisali istotną aktualizację szyfratora RansomHouse o nazwie „Mario”: przejście z prostego, liniowego przekształcania danych do podejścia warstwowego, trudniejszego do analizy i potencjalnie bardziej dotkliwego dla ofiar.

W skrócie

• RansomHouse zaktualizował szyfrator „Mario” z jednoprzebiegowego przekształcania danych do dwustopniowego procesu z dwoma kluczami (32B + 8B).
• Nowa wersja stosuje przetwarzanie plików porcjami (chunking) o zmiennym rozmiarze i próg 8 GB, a także elementy szyfrowania „rzadkiego” (sparse), czyli tylko wybranych bloków pliku.
• Przetwarzanie jest nieliniowe i oparte o złożone obliczenia wyznaczające kolejność/offsety, co utrudnia analizę statyczną i inżynierię wsteczną.
• Cel pozostaje ten sam: szybkie „położenie” wirtualizacji i utrudnienie odtwarzania — pliki dostają rozszerzenie .emario, a w katalogach pojawia się notatka „How To Restore Your Files.txt”.

Kontekst / historia / powiązania

Wczesne komunikaty o RansomHouse (2022) podkreślały, iż grupa deklaruje model „nie szyfrujemy, tylko kradniemy” i oferuje „raport” z lukami po opłaceniu okupu — pozycjonując się niemal jak agresywni „audytorzy”.

Z czasem jednak widać było coraz bardziej „ransomware’ową” dojrzałość: rozwój narzędzi, infrastruktury negocjacyjnej oraz koncentrację na środowiskach wirtualnych. Unit 42 opisuje także narzędzie MrAgent, które służy do działań w środowisku ESXi i ułatwia wdrożenie „Mario”.

RansomHouse bywa też analizowany w szerszym ekosystemie grup, gdzie pojawiają się cross-claimy (różne gangi przypisujące sobie te same ofiary) oraz możliwe współdzielenie danych/zasobów. Analyst1 łączy jego genezę i kontekst z falą „potomków” po wycieku kodu Babuk oraz opisuje zjawisko współpracy i przenikania się działań w podziemiu.

Analiza techniczna / szczegóły luki

1) Dwustopniowe przekształcanie danych i „dwa klucze”

Kluczowa zmiana w „Mario” to przejście na dwustopniową transformację z dodatkowym kluczem. Unit 42 wskazuje, iż nowsze próbki generują losowo 32-bajtowy klucz główny i 8-bajtowy klucz pomocniczy, a szyfrowanie jest przetwarzane osobno dla wszystkich z nich. Efekt: bez kompletu materiału kluczowego odzysk danych staje się istotnie trudniejszy.

BleepingComputer streszcza to jako odejście od „single-pass” do „two-stage transformation”, co ma zwiększać entropię i utrudniać częściowy odzysk danych.

2) Porcjowanie danych: dynamiczne „chunking” i próg 8 GB

Z perspektywy IR/DFIR druga duża zmiana to sposób obchodzenia się z dużymi plikami: „Mario” przechodzi z prostego, sekwencyjnego pętlenia po stałych segmentach do segmentów o zmiennej długości (z progiem 8 GB) i obliczeń wyznaczających rozmiary/offsety porcji.

3) „Sparse encryption”: szyfrowanie selektywne

W nowszej wersji pojawia się też sparse encryption — szyfrowanie tylko wybranych bloków pliku na określonych offsetach. Taki model potrafi drastycznie skrócić czas operacji przy zachowaniu skutecznej blokady (np. systemy plików/VM mogą przestać działać mimo, iż nie zaszyfrowano 100% bajtów).

4) Nieliniowość i utrudnianie analizy

Unit 42 podkreśla, iż chunking jest nieliniowy, oparty o złożone formuły matematyczne determinujące kolejność przetwarzania i różne strategie w zależności od rozmiaru pliku — to realnie utrudnia szybkie „rozpoznanie wzorca” w analizie.

5) Target: wirtualizacja (ESXi) i rozszerzenie .emario

W praktyce „Mario” skupia się na plikach związanych z wirtualizacją i backupem (m.in. typowe rozszerzenia VMware/Veeam) oraz dodaje rozszerzenie .emario. Ransom note ma nazwę How To Restore Your Files.txt.

Praktyczne konsekwencje / ryzyko

1. Trudniejsza analiza i wolniejsze reagowanie. Nieliniowe przetwarzanie i dodatkowa warstwa kluczowania zwiększają koszt analizy wstecznej oraz utrudniają szybkie tworzenie „reguł” pod konkretne warianty.
2. Większa presja negocjacyjna. Szybsze lub bardziej niezawodne unieruchamianie VM/backupów zwykle przekłada się na krótsze RTO w realu (czyli większą presję biznesu, by „coś” zrobić natychmiast). BleepingComputer wskazuje, iż celem zmian jest m.in. lepsza skuteczność i dźwignia po szyfrowaniu.
3. Ryzyko „podwójnego uderzenia”: dane + szyfrowanie. RansomHouse historycznie silnie akcentował warstwę wycieku danych (szantaż publikacją/sprzedażą), a jednocześnie rozwija tooling do blokowania infrastruktury — co zwiększa łączny koszt incydentu (prawny, reputacyjny, operacyjny).

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań, które mają największy sens „tu i teraz”, gdy widzimy ofensywne inwestycje w ESXi i w szyfrowanie selektywne:

Twardnienie i ekspozycja ESXi

• Ogranicz dostęp do paneli zarządzania ESXi/vCenter (VPN + MFA + allowlist IP; absolutnie nie „na świat”).
• Segmentuj sieć: oddziel zarządzanie hypervisorami, backupy, storage i sieć użytkowników.

Kopie zapasowe odporne na atak

• Stosuj kopie offline/immutable i regularnie testuj odtwarzanie (nie tylko „czy backup się robi”).
• Upewnij się, iż repozytoria backup nie są „jednym kliknięciem” dostępne z domeny/tej samej płaszczyzny uprawnień.

Detekcja i reakcja

• Alarmuj na pojawienie się .emario oraz pliku How To Restore Your Files.txt (to proste i często daje pierwsze sygnały skali).
• Włącz telemetrykę dla krytycznych serwerów plików/hostów wirtualizacji (EDR/NDR, logi z vCenter/ESXi) oraz korelacje pod nietypową aktywność na dużych plikach (w tym szybkie modyfikacje/odczyty blokowe).

Gotowość proceduralna

• Przygotuj „minimum viable IR” dla scenariusza zaszyfrowania wirtualizacji: kontakty, decyzje o izolacji, priorytety przywracania, ścieżka komunikacji do prawników i DPO.
• Dla organizacji regulowanych: plan na obsługę wycieku danych (bo „extortion” jest w tym modelu równie istotny jak szyfrowanie).

Różnice / porównania z innymi przypadkami

Aktualizacja „Mario” wpisuje się w szerszy trend: mniej „głośnego” szyfrowania wszystkiego, więcej sprytnego przetwarzania, które:

• skraca czas operacji (np. szyfrowanie selektywne),
• utrudnia analizę i tworzenie uniwersalnych narzędzi obrony,
• maksymalizuje presję na organizację (blokada VM/backup).

Ciekawostką u RansomHouse jest to, iż grupa długo budowała markę w modelu „extortion-only”, a dziś rozwija dojrzałe elementy typowe dla RaaS i ekosystemu współdzielenia/krzyżowych roszczeń w podziemiu — co w praktyce zwiększa niepewność atrybucji i utrudnia przewidywanie TTP.

Podsumowanie / najważniejsze wnioski

RansomHouse nie stoi w miejscu. „Mario” zyskuje dwustopniowe szyfrowanie z dwoma kluczami, dynamiczne porcjowanie i elementy sparse encryption, a do tego nieliniowe przetwarzanie utrudniające analizę.

Dla obrońców oznacza to jedno: priorytetem powinny być odporne kopie zapasowe, twardnienie i izolacja warstwy wirtualizacji (ESXi/vCenter) oraz detekcja nastawiona na szybkie uchwycenie pierwszych symptomów (np. .emario i ransom note), zanim szyfrowanie rozleje się na całą farmę.

Źródła / bibliografia

1. BleepingComputer — „RansomHouse upgrades encryption with multi-layered data processing” (20 grudnia 2025) (BleepingComputer)
2. Palo Alto Networks Unit 42 — „From Linear to Complex: An Upgrade in RansomHouse Encryption” (Unit 42)
3. SentinelOne — „RansomHouse Ransomware: Analysis, Detection, and Mitigation” (SentinelOne)
4. Help Net Security — „RansomHouse: Bug bounty hunters gone rogue?” (Help Net Security)
5. Analyst1 — „RansomHouse: Stolen Data Market, Influence Operations & Other Tricks Up the Sleeve” (Analyst1)