Wieloetapowa kampania phishingowa w Rosji: Amnesia RAT + ransomware (Hakuna Matata) i WinLocker, a wszystko bez exploitów - Security Bez Tabu

Wieloetapowa kampania phishingowa w Rosji: Amnesia RAT + ransomware (Hakuna Matata) i WinLocker, a wszystko bez exploitów

Wprowadzenie do problemu / definicja luki

Opisywana kampania to dobry przykład „pełnego przejęcia stacji roboczej bez podatności”: atak nie potrzebuje CVE ani exploita, bo opiera się na socjotechnice, natywnych mechanizmach Windows oraz nadużyciu zaufanych usług (GitHub/Dropbox/Telegram). Łańcuch zaczyna się od archiwum z przynętami biznesowymi (w tym skrótem LNK podszywającym się pod plik tekstowy), a kończy kombinacją: Amnesia RAT (kradzież danych i zdalna kontrola) + ransomware pochodne Hakuna Matata (szyfrowanie) + WinLocker (blokada interakcji z systemem).

Kluczowym „wyróżnikiem” jest operacyjne użycie defendnot – narzędzia PoC, które potrafi doprowadzić do samowyłączenia Microsoft Defender przez rejestrację fałszywego AV w Windows Security Center (WSC).

W skrócie

  • Cel/geografia: użytkownicy i organizacje w Rosji; przynęty osadzone w realiach biurowo-księgowych.
  • Wejście: archiwum z dokumentami-wabikami + LNK z podwójnym rozszerzeniem, uruchamiający PowerShell.
  • Infrastruktura: skrypty na GitHub, binaria na Dropbox (modułowość i odporność na blokady).
  • Ewazja/utrudnianie obrony: ukrywanie okna PowerShell, opóźnienie 444 s, mocna obfuskacja VBE, eskalacja przez wymuszanie UAC, masowe zmiany konfiguracji Defender + defendnot (WSC).
  • Efekt: kradzież danych i zdalne sterowanie (Amnesia RAT), szyfrowanie plików, podmiana adresów kryptowalut w schowku, końcowa blokada systemu (WinLocker).

Kontekst / historia / powiązania

Badanie techniczne opublikował Fortinet FortiGuard Labs (20 stycznia 2026), a temat szybko podchwyciły media branżowe (m.in. 24 stycznia 2026).

W tej samej fali doniesień pojawiają się także inne kampanie wymierzone w rosyjskie podmioty (np. Operation DupeHike / UNG0902 z implantem DUPERUNNER i frameworkiem AdaptixC2 czy aktywność Paper Werewolf/GOFFEE z XLL-ami). Warto to traktować jako szerszy krajobraz zagrożeń „office-themed lures → LNK/archiwum → loader”, a nie dowód bezpośredniego powiązania z opisywaną kampanią.

Analiza techniczna / szczegóły luki

1) Etap początkowy: archiwum + LNK „udający dokument”

Ofiara dostaje skompresowane archiwum z wieloma plikami-wabikami oraz złośliwym skrótem LNK. Nazwa LNK wykorzystuje podwójne rozszerzenie (np. „…txt.lnk”), by wyglądać jak zwykły plik tekstowy.

Po uruchomieniu LNK wykonywany jest PowerShell, który pobiera kolejny skrypt (loader) z repozytorium na GitHub.

2) Loader PowerShell: „dym i lustra” + sygnał do operatora

Pierwszy skrypt:

  • ukrywa widoczną egzekucję (np. chowa okno PowerShell),
  • generuje i otwiera dokument-wabik w profilu użytkownika,
  • wysyła potwierdzenie wykonania do operatora przez Telegram Bot API,
  • czeka 444 sekundy, po czym uruchamia kolejny etap: obfuskowany skrypt VBE.

Ten „projekt” jest typowy dla kampanii nastawionych na elastyczność: pierwszy etap jest lekki, a funkcje można wymieniać po stronie hostowanego repozytorium bez zmiany całego łańcucha.

3) Orkiestrator VBE: obfuskacja + składanie payloadu w pamięci + wymuszanie UAC

Kolejny komponent (VBE) jest mocno obfuskowany i pełni rolę kontrolera, który rekonstruuje następny etap w pamięci, ograniczając artefakty na dysku. W dalszej fazie skrypt sprawdza uprawnienia i – jeśli trzeba – potrafi natrętnie wyświetlać prompt UAC, aby skłonić użytkownika do podniesienia uprawnień.

4) Neutralizacja ochrony: Defender „rozbrojony” kilkoma metodami

Fortinet opisuje sekwencję działań obniżających widoczność i skuteczność EPP/AV, w tym:

  • dodawanie wykluczeń Defender dla typowych katalogów roboczych (ProgramData, Desktop, Downloads itd.),
  • wyłączanie dodatkowych komponentów ochrony przez PowerShell,
  • modyfikacje polityk/rejestru ograniczające narzędzia administracyjne i diagnostyczne,
  • użycie defendnot, aby zarejestrować fałszywy AV w WSC i doprowadzić do samowyłączenia Defendera „dla uniknięcia konfliktu”.

To ostatnie jest krytyczne: defendnot nie musi „zabijać” procesów Defendera wprost – wykorzystuje model zaufania Windows Security Center. Huntress podkreśla, że narzędzie opiera się na (w ich opisie) nieudokumentowanych API WSC do rejestracji sfabrykowanego produktu AV.

5) Rozpoznanie i obserwacja: zrzuty ekranu + eksfiltracja przez Telegram

Po osłabieniu ochrony następuje rozpoznanie środowiska i monitoring aktywności, m.in. moduł robiący screenshot co 30 sekund oraz eksfiltracja przez Telegram (Bot API), z możliwością użycia zewnętrznych hostingów plików dla większych paczek danych (np. GoFile).

6) Payloady końcowe: Amnesia RAT + ransomware + WinLocker

Amnesia RAT (pobierany z Dropbox) ma szerokie możliwości: kradzież danych z przeglądarek, portfeli krypto, Discord/Steam/Telegram, zbieranie metadanych systemu, zrzuty ekranu, obraz z kamery, audio z mikrofonu, schowek, tytuł aktywnego okna oraz pełna zdalna interakcja (enumeracja procesów, shell, dowolne payloady).

Równolegle/po nim uruchamiany jest ransomware wywodzący się z rodziny Hakuna Matata, który szyfruje zestawy plików (dokumenty, archiwa, multimedia, kod źródłowy, zasoby aplikacji) i ubija procesy, które mogłyby przeszkadzać. Dodatkowo monitoruje schowek i podmienia adresy portfeli kryptowalut na kontrolowane przez atakujących. Łańcuch kończy WinLocker blokujący interakcję z systemem.

7) Mitre ATT&CK

Fortinet mapuje zachowania m.in. na: T1566.001 (Phishing: Attachment), T1059.001 (PowerShell), T1059.005 (VBScript), T1562.001 (Impair Defenses), T1113 (Screen Capture), T1486 (Data Encrypted for Impact).

Praktyczne konsekwencje / ryzyko

  • Ryzyko „pełnego incydentu” na endpointach: od kradzieży danych i przejęcia sesji po szyfrowanie plików i zablokowanie stanowiska.
  • Szybka eskalacja bez CVE: klasyczne „patchuj i śpisz spokojnie” nie wystarczy, bo łańcuch opiera się o zachowania użytkownika i funkcje systemu.
  • Trudniejszy takedown i filtracja: GitHub/Dropbox są powszechne w firmach; blokada „na sztywno” bywa trudna operacyjnie, a atakujący rozdzielają komponenty po usługach.
  • Obrona punktowa może zawieść: jeśli atakujący zdoła wyłączyć/ograniczyć Defendera (wykluczenia/polityki/defendnot), endpoint staje się „ślepy” na krytycznym etapie.

Rekomendacje operacyjne / co zrobić teraz

1) Zbij łańcuch na wejściu (email/WWW/endpoint)

  • Blokuj/oznaczaj archiwa z LNK oraz pliki z podwójnymi rozszerzeniami (np. *.txt.lnk). Rozważ politykę: „LNK z poczty = kwarantanna”.
  • Monitoruj i ogranicz PowerShell: logowanie Script Block, Constrained Language Mode (tam gdzie ma sens), kontrola -ExecutionPolicy Bypass i podejrzanych wzorców typu irm … | iex.
  • Wprowadź reguły ograniczające uruchamianie skryptów z katalogów użytkownika i ProgramData (allowlisting/AppLocker/WDAC – w zależności od dojrzałości).

2) Utrudnij rozbrajanie Defendera

  • Włącz Ochronę przed naruszeniami (Tamper Protection), bo jest projektowo nastawiona na blokowanie nieautoryzowanych zmian w ustawieniach ochrony i m.in. uniemożliwia modyfikację/dodawanie wykluczeń.
  • Dodaj detekcje na:
    • nagłe masowe dodawanie wykluczeń Defender,
    • wyłączanie komponentów ochrony,
    • nietypową rejestrację produktu AV w WSC / zmiany w stanie „kto jest AV”.

3) Odetnij C2/eksfiltrację i „sygnały powodzenia”

  • Polityki sieciowe/Proxy: alerty na Telegram Bot API z segmentów użytkowników, zwłaszcza gdy to nie jest zatwierdzona usługa.
  • DLP/egress: obserwuj nietypowe uploady do zewnętrznych hostingów plików (w raporcie pojawia się m.in. GoFile jako kanał dla większych danych).

4) Wczesne wskaźniki kompromitacji (praktyczne playbooki SOC)

  • Procesy/komendy: powershell.exe startujący z kontekstu LNK/Explorer i pobierający treść z GitHub, potem VBScript/WSH.
  • Artefakty behawioralne: nagłe ograniczenie narzędzi administracyjnych, zmiany skojarzeń plików (file association hijacking), cykliczne zrzuty ekranu.
  • Zasada IR: jeżeli widzisz „Defender nagle zgasł” + dziwne wykluczenia + podejrzane skrypty, traktuj to jak incydent wysokiej wagi (przed szyfrowaniem bywa bardzo mało czasu).

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

  • Defender bypass przez WSC (defendnot) to inna klasa niż klasyczne „wyłącz AV rejestrem”. Binary Defense opisuje tę ideę jako „przekonanie Windows, by samo wyłączyło ochronę”, zamiast bezpośredniego łamania Defendera.
  • Nadużycie zaufanych usług (GitHub/Dropbox) przypomina trend widoczny także w innych wieloetapowych kampaniach: legalna infrastruktura utrudnia blokowanie i zwiększa „szum tła” w logach.
  • Warto odróżnić ten przypadek od AiTM/BEC (np. SharePoint/OneDrive do kradzieży sesji i przejęć kont) – tam celem bywa tożsamość i poczta, tu finalnie dochodzi do kompromitacji endpointu i destrukcji danych. (Jeśli chcesz, mogę przygotować zestawienie TTP „endpoint takeover” vs „identity takeover” na jednym diagramie).

Podsumowanie / kluczowe wnioski

  1. To kampania „bez-CVE”, więc priorytetem stają się: kontrola uruchamiania skryptów, ochrona przed socjotechniką oraz monitoring zmian konfiguracji bezpieczeństwa.
  2. Rozdzielenie komponentów między GitHub i Dropbox zwiększa żywotność ataku i komplikuje reakcję.
  3. defendnot pokazuje, jak narzędzia dual-use (PoC) mogą przejść do realnych łańcuchów infekcji – i czemu „tamper protection + telemetry” to dziś must-have, a nie opcja.

Źródła / bibliografia

  1. Fortinet FortiGuard Labs – „Inside a Multi-Stage Windows Malware Campaign” (Cara Lin, 20.01.2026). (Fortinet)
  2. The Hacker News – „Multi-Stage Phishing Campaign Targets Russia with Amnesia RAT and Ransomware” (24.01.2026). (The Hacker News)
  3. Huntress – „Detecting Malicious Security Product Bypass Techniques” (defendnot / WSC). (Huntress)
  4. Binary Defense – „DefendNot: Turning Windows Defender Against Itself”. (Binary Defense)
  5. Microsoft Learn (PL) – „Chroń ustawienia zabezpieczeń z ochroną przed naruszeniami (Tamper Protection)”. (Microsoft Learn)