Wprowadzenie do problemu / definicja luki
GootLoader (JScriptowy „loader” wykorzystywany często jako initial access pod kolejne etapy, w tym ransomware) został zaobserwowany z nową techniką unikania detekcji: dystrybucją ładunku w celowo zniekształconym (malformed) archiwum ZIP, które psuje analizę wielu narzędzi bezpieczeństwa i popularnych rozpakowywarek, ale nadal otwiera się w domyślnym eksploratorze Windows. W praktyce nie jest to pojedyncza luka CVE, tylko sprytnie zaprojektowany anti-analysis & evasion pattern na poziomie formatu pliku i łańcucha dostarczenia.
W skrócie
- Kampania wykorzystuje ZIP-y sklejone z 500–1000 następujących po sobie archiwów (ZIP „działa”, bo parser czyta kluczowe struktury od końca pliku).
- Archiwum ma cechy celowego „uszkodzenia” (m.in. nietypowe/popsute pola w strukturach ZIP), przez co 7-Zip/WinRAR i część pipeline’ów analitycznych potrafi się wywracać lub nie wyciągać zawartości.
- etap zawiera zwykle JScript, który po uruchomieniu prowadzi do uruchomienia kolejnych procesów (m.in. PowerShell) i persistence.
- Expel opublikował podejście detekcyjne (w tym regułę YARA) oparte o unikalne właściwości tych archiwów.
Kontekst / historia / powiązania
GootLoader to znany od lat komponent ekosystemu „access-as-a-service”: jego rolą bywa wejście do sieci ofiary, a następnie „handoff” dostępu do kolejnych operatorów (np. do wdrożenia narzędzi post-exploitation lub ransomware). Źródła branżowe łączą jego powrót (po przerwie) z aktywnością od listopada 2025 i wskazują na powiązania z aktorem śledzonym jako Vanilla Tempest oraz kontekstem ransomware (np. Rhysida).
Równolegle Red Canary opisuje GootLoader jako zagrożenie często sprzęgnięte z SEO poisoning i dystrybucją ZIP-ów „udających” dokumenty (prawne/finansowe), co dobrze pasuje do profilu kampanii nastawionych na masowe infekcje i wysoki współczynnik kliknięć.
Analiza techniczna / szczegóły luki
1) „Hashbusting” i sklejanie setek ZIP-ów
Najbardziej charakterystyczna cecha: plik wynikowy to setki (500–1000) ZIP-ów sklejonych w jeden. Ponieważ standardowy odczyt ZIP bazuje na strukturze End of Central Directory (EOCD) znajdującej się na końcu, archiwum nadal może się rozpakować — mimo że wcześniej w pliku „siedzi” mnóstwo śmieci/powtórek. Co ważne: liczba sklejonych archiwów jest losowa, co utrudnia detekcję po hashu (każdy pobierający dostaje inny plik).
2) Malformed ZIP jako anti-analysis (psucie narzędzi)
Expel opisuje dodatkowe „anomalia” w strukturach ZIP (m.in. problemy w EOCD oraz randomizacje pól, które nie są krytyczne dla działania w Windows, ale potrafią wprowadzać inne narzędzia w błąd). Efekt: część unarchiverów i automatycznych workflowów analitycznych nie potrafi stabilnie wyciągnąć zawartości lub traktuje plik jako uszkodzony.
3) „Egzotyczne” dostarczenie: budowanie finalnego ZIP-a po stronie ofiary
Ciekawy detal: w opisie Expel finalny plik nie musi być po prostu pobrany jako gotowy ZIP. Ofiara może otrzymać XOR-owaną „bryłę” danych, która na hoście jest dekodowana i wielokrotnie dopisywana do siebie aż osiągnie docelowy rozmiar — co utrudnia wykrycie w tranzycie (np. po stronie sieci/secure web gateway).
4) Uruchomienie JScript z ZIP-a i łańcuch procesów
Gdy użytkownik otworzy archiwum w Eksploratorze i kliknie plik .js, domyślne skojarzenie uruchamia Windows Script Host (wscript.exe), często z katalogu tymczasowego (bo Explorer wypakowuje do temp). Expel wskazuje to jako mocny punkt detekcyjny: wscript.exe uruchamiający .js z %AppData%\Local\Temp jest w większości środowisk anomalią. Dalej pojawia się persistence przez .LNK w folderze autostartu oraz kolejne uruchomienia .js z użyciem cscript.exe, po czym typowo następuje cscript.exe → powershell.exe z obfuskacją.
5) Gdzie w tym „bypass security controls”?
To obejście jest wielowarstwowe:
- statyczne skanowanie i automatyczne rozpakowywanie przez część narzędzi może się nie udać (bo ZIP jest „malformed”), więc silnik nie dociera do payloadu,
- detekcje oparte o hash stają się mało użyteczne (hashbusting),
- jeśli finalny plik powstaje po stronie endpointu, narzędzia sieciowe mogą zobaczyć coś innego niż finalne archiwum.
Praktyczne konsekwencje / ryzyko
- Wyższa skuteczność initial access: nawet jeśli organizacja ma dobre filtry na bramie e-mail / web, problemy z ekstrakcją i analiza statyczna mogą dawać „ślepe plamy”.
- Szybszy „handoff” do kolejnych operatorów: GootLoader jest opisywany jako komponent, który ułatwia dalsze wdrożenia (C2, narzędzia post-exploitation, potencjalnie ransomware).
- Ryzyko operacyjne w SOC: analitycy mogą dostać artefakt, którego nie da się łatwo rozpakować standardowymi narzędziami, co spowalnia triage i IR.
Rekomendacje operacyjne / co zrobić teraz
1) „Wyłącz łatwe uruchamianie JScript”
Jeśli biznes nie wymaga JScript, rozważ:
- zmianę skojarzeń
.js/.jsetak, aby otwierały się np. w Notatniku, a nie w Windows Script Host, - ograniczenie uruchamiania
wscript.exe/cscript.exe(np. politykami, allowlistingiem, ASR/EDR).
2) Detekcje behawioralne (praktyczne i odporne na hashbusting)
W SOC/EDR poluj na:
wscript.exeuruchamiający.jsz%AppData%\Local\Temp,- tworzenie
.LNKw folderze autostartu użytkownika i wskazywanie na skrypty w nietypowych lokalizacjach, cscript.exeuruchamiający.jsz użyciem krótkich nazw NTFS (np.FILENA~1.js),- drzewo procesów
cscript.exe → powershell.exei kolejne, silnie obfuskowane polecenia PowerShell.
3) Detekcja po kształcie pliku (YARA / własne parsowanie ZIP)
Zamiast polegać na hashu:
- wykorzystaj regułę YARA/heurystyki wykrywające wielokrotne wystąpienia struktur ZIP (np. setki nagłówków lokalnych i EOCD) oraz ich specyficzne bajty/pola,
- traktuj ZIP-y „nie do rozpakowania” jako sygnał, nie przeszkodę: nieudana ekstrakcja powinna eskalować, a nie kończyć analizę.
4) Uporządkowanie polityk Mark-of-the-Web / stref pochodzenia
Windows bazuje na oznaczaniu plików informacją o strefie pochodzenia (Attachment Manager / „zone information”). Upewnij się, że polityki nie wyłączają tego mechanizmu tam, gdzie jest potrzebny, bo jego brak utrudnia ocenę ryzyka przez system i narzędzia zależne od tych metadanych.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
- Klasyczne kampanie ZIP często liczą na hashe, proste obfuskacje lub password-protected archiwa. Tutaj nacisk jest na psucie analizy narzędziami i na to, że Windows i tak to otworzy.
- W porównaniu z typowymi „archive bombs”, to nie jest próba kompresyjnego DoS, tylko kontrolowane „zepsucie” formatu + masowe duplikacje struktur (pod automaty, nie pod człowieka).
Podsumowanie / kluczowe wnioski
GootLoader pokazuje, że w 2026 roku „bypass” nie musi oznaczać exploita w EDR — czasem wystarczy inteligentne wykorzystanie różnic w parsowaniu formatów plików i projektowanie łańcucha dostarczenia pod słabe punkty automatyzacji obrony. Najlepsza odpowiedź to połączenie: twardych ograniczeń uruchamiania skryptów (JScript/WSH), detekcji behawioralnej oraz identyfikacji anomalii w strukturze ZIP (zamiast hashy).
Źródła / bibliografia
- Expel – „Planned failure: Gootloader’s malformed ZIP actually works perfectly” (15 stycznia 2026). (Expel)
- BleepingComputer – „Gootloader now uses 1,000-part ZIP archives for stealthy delivery” (15 stycznia 2026). (BleepingComputer)
- Security Affairs – „GootLoader uses malformed ZIP files to bypass security controls” (18 stycznia 2026). (Security Affairs)
- Red Canary – „Gootloader” (Threat Detection Report – opis zagrożenia i typowego wektora). (Red Canary)
- Microsoft Learn – Policy CSP: AttachmentManager (zarządzanie oznaczaniem strefy pochodzenia plików). (Microsoft Learn)