INC Ransomware: błąd OpSec ujawnił infrastrukturę i pozwolił odzyskać dane 12 ofiar w USA

Wprowadzenie do problemu / definicja luki

W ransomware zwykle zakładamy, iż po eksfiltracji dane „znikają” w ekosystemie przestępców: trafiają na serwery pośrednie, do chmury, na leak site albo do prywatnych archiwów grupy. Ten przypadek pokazuje, iż czasem o losie danych decyduje nie kryptografia, a operacyjna higiena atakujących (OpSec).

W styczniu 2026 r. ujawniono, iż błąd OpSec grupy INC Ransomware doprowadził do odsłonięcia długowiecznej infrastruktury przechowującej zaszyfrowane paczki danych wielu ofiar — co finalnie umożliwiło odzyskanie danych skradzionych 12 organizacjom z USA.

W skrócie

• Punktem startowym było klasyczne IR: wykrycie aktywnego szyfrowania na produkcyjnym SQL Server i analiza próbki wariantu RainINC.
• Śledczy znaleźli artefakty użycia legalnego narzędzia backupowego restic (m.in. skrypty PowerShell, zmienione nazwy binarek, zmienne repozytorium), mimo iż w tej konkretnej intruzji eksfiltracja poszła inną ścieżką.
• W skrypcie new.ps1 znajdowały się (po dekodowaniu Base64) twardo wpisane parametry do repozytorium restic w S3-kompatybilnym storage (endpoint/bucket/repo) oraz zmienne środowiskowe typu AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, RESTIC_PASSWORD.
• Kontrolowana enumeracja repozytoriów doprowadziła do identyfikacji zaszyfrowanych danych 12 niepowiązanych ofiar (różne branże), a następnie do ich odszyfrowania i zabezpieczenia we współpracy z organami ścigania.

Kontekst / historia / powiązania

INC Ransomware działa w modelu ransomware-as-a-service (RaaS) co najmniej od 2023 r. i łączy szyfrowanie z presją publikacyjną (double extortion). W przeszłości przypisywano jej ataki na organizacje z różnych państw i sektorów, a jej operacje często pokazują „enterprise’owy” poziom standaryzacji narzędzi i procedur.

W tym incydencie istotne jest nie „kolejne ransomware”, tylko to, jak atakujący próbowali ukryć eksfiltrację w „normalnym” ruchu operacyjnym. MITRE ATT&CK opisuje ten wzorzec jako eksfiltrację przez usługi webowe / chmurowe (np. obiekty w chmurze), co bywa trudne do odróżnienia od legalnych procesów w organizacji.

Analiza techniczna / szczegóły luki

1) Punkt wejścia w analizę: szyfrowanie i staging w „niewinnej” lokalizacji

W badanej sprawie ładunek ransomware uruchomiono z C:\PerfLogs\win.exe (PerfLogs to katalog domyślnie obecny w Windows i bywa ignorowany). Korelacja TI wskazała na wariant RainINC powiązany z INC.

2) Artefakty restic jako „ślad kampanii”, a nie pojedynczego incydentu

Kluczowy zwrot nastąpił, gdy w środowisku znaleziono pozostałości po restic, mimo iż w tej konkretnej intruzji dane miały zostać skopiowane inaczej (np. podczas ruchu bocznego). To zasugerowało, iż restic jest elementem powtarzalnego toolchainu INC, wdrażanym selektywnie.

Śledczy odnotowali m.in.:

• binarkę restic podmienioną nazwą (np. winupdate.exe) i lokowaną w podejrzanych miejscach (np. System32),
• skrypty PowerShell do uruchamiania backupu,
• zmienne konfiguracyjne repozytorium i komendy backupu,
• listy plików sterujące selektywną kradzieżą.

3) „Wpadka” OpSec: twardo wpisane parametry dostępu do S3-kompatybilnego repo

Najbardziej obciążającym artefaktem był new.ps1 z komendami zakodowanymi Base64. Po dekodowaniu ujawniał on schemat uruchomienia restic oraz twardo wpisane dane potrzebne do połączenia z repozytorium w obiektowej chmurze (S3-kompatybilny endpoint), w tym RESTIC_REPOSITORY i RESTIC_PASSWORD oraz klucze w stylu AWS.

To ważne z dwóch powodów:

1. Restic szyfruje dane po stronie klienta i przechowuje je w repozytorium jako nieczytelne obiekty — więc przejęcie „gołych” blobów nic nie daje bez poprawnej konfiguracji.
2. Skrypt pozostawił wystarczająco dużo „kontekstu”, by badacze mogli bez destrukcyjnych działań enumerować snapshoty repozytoriów (w logice restic, a nie w logice samego S3) i zidentyfikować dane wielu ofiar.

4) Efekt: repozytoria jako długowieczna „hurtownia” łupów

Hipoteza okazała się trafna: infrastruktura restic/S3 była najwyraźniej wielokrotnie używana i nie została zdemontowana po zakończeniu negocjacji z pojedynczą ofiarą. Enumeracja wykazała zaszyfrowane dane 12 niepowiązanych podmiotów (m.in. healthcare, manufacturing, tech, usługi profesjonalne).

Praktyczne konsekwencje / ryzyko

• Dla ofiar: choćby jeżeli incydent jest „zamknięty” (negocjacje, płatność lub brak płatności), dane mogą dalej zalegać w infrastrukturze atakujących — czasem dłużej, niż wszyscy zakładają.
• Dla obrońców: legalne narzędzia (backup, synchronizacja, zdalna administracja) coraz częściej stają się bronią. Ruch wygląda jak „normalny”, a eksfiltracja do chmury wpisuje się w znane taktyki ATT&CK.
• Dla IR/DFIR: artefakty z „nieużytego” narzędzia mogą być cenniejsze niż sama próbka ransomware — bo prowadzą do infrastruktury i metod operacyjnych.

Rekomendacje operacyjne / co zrobić teraz

1) Threat hunting: gdzie patrzeć (konkretne tropy)

• Telemetria procesów/EDR pod kątem uruchomień z nietypowych lokalizacji: C:\PerfLogs\ oraz „binarki systemowe” uruchamiane z katalogów stagingowych.
• Wykrywanie restic i „podszywek” typu winupdate.exe, zwłaszcza gdy:
  • binarka pojawia się w System32 lub innych wrażliwych ścieżkach,
  • wykonywana jest z parametrami backupu --files-from (selektywna kradzież).
• PowerShell: alerty na Base64 w poleceniach oraz skrypty ustawiające zmienne środowiskowe AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, RESTIC_REPOSITORY, RESTIC_PASSWORD.

2) Kontrola egress i chmury

• Ogranicz/monitoruj ruch do S3-kompatybilnych endpointów (nie tylko „AWS proper”), zwłaszcza z serwerów, które nie powinny wykonywać backupów do Internetu.
• Wprowadź allow-listę domen/IP dla backupów i wymuś identyfikację aplikacji (proxy/NGFW) — „backupowy” ruch z nietypowego procesu to sygnał ostrzegawczy.

3) Gotowość na ransomware: procedury i odporność

• Uporządkuj plan reakcji (izolacja, triage, polowanie na lateral movement, analiza danych wrażliwych) według checklist i dobrych praktyk dla ransomware.
• Zadbaj o kopie zapasowe odporne na sabotaż (immutability/offline), regularne testy odtwarzania i segmentację uprawnień do repozytoriów backupowych.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

W wielu kampaniach ransomware spotyka się narzędzia „living off the land” (legalne, powszechne w IT), ale ten przypadek wyróżnia się tym, że:

• restic nie był tylko „narzędziem do kradzieży”, ale też standardowym elementem infrastruktury, potencjalnie współdzielonym między kampaniami,
• błąd OpSec polegał na pozostawieniu artefaktów umożliwiających rekonstrukcję sposobu dostępu do repozytoriów (a nie na „dziurze” w chmurze),
• skala odzysku danych (wielu niepowiązanych poszkodowanych) jest rzadkością w realnych sprawach ransomware.

Podsumowanie / najważniejsze wnioski

• Najcenniejsze w IR bywa to, co wygląda na „szum”: skrypty, staging, pozostałości po legalnych narzędziach.
• INC wykorzystało restic i S3-kompatybilny storage do utrzymania zaszyfrowanych łupów w sposób przypominający legalne backupy — ale ich OpSec nie dowiózł.
• Dla obrony oznacza to jedno: jeżeli polujesz na ransomware, poluj też na „backup-like exfiltration” i na wszelkie anomalie wokół narzędzi kopii zapasowych, PowerShell oraz ruchu do chmury.

Źródła / bibliografia

1. BleepingComputer — „INC ransomware opsec fail allowed data recovery for 12 US orgs” (22 stycznia 2026). (BleepingComputer)
2. Cyber Centaurs — „When Ransomware Makes a Mistake Inside INC Ransomware’s Backup Infrastructure” (22 stycznia 2026). (Digital Forensics & Data Breach Services)
3. restic docs — „Preparing a new repository” (S3 i backendy S3-kompatybilne). (restic.readthedocs.io)
4. MITRE ATT&CK — T1567 / T1567.002 (Exfiltration Over Web Service / Exfiltration to Cloud Storage). (attack.mitre.org)
5. CISA — #StopRansomware Guide / ransomware response resources. (CISA)