GootLoader wraca z „zepsutym” ZIP-em: 500–1000 sklejonych archiwów omija analizę i część kontroli bezpieczeństwa

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 przez cały czas 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 najważniejsze 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.
  1. 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 adekwatnoś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 przez cały czas może się rozpakować — mimo iż 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: choćby jeżeli 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/.jse tak, 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.exe uruchamiający .js z %AppData%\Local\Temp,
• tworzenie .LNK w folderze autostartu użytkownika i wskazywanie na skrypty w nietypowych lokalizacjach,
• cscript.exe uruchamiający .js z użyciem krótkich nazw NTFS (np. FILENA~1.js),
• drzewo procesów cscript.exe → powershell.exe i 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ę, iż 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, iż 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 / najważniejsze wnioski

GootLoader pokazuje, iż 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

1. Expel – „Planned failure: Gootloader’s malformed ZIP actually works perfectly” (15 stycznia 2026). (Expel)
2. BleepingComputer – „Gootloader now uses 1,000-part ZIP archives for stealthy delivery” (15 stycznia 2026). (BleepingComputer)
3. Security Affairs – „GootLoader uses malformed ZIP files to bypass security controls” (18 stycznia 2026). (Security Affairs)
4. Red Canary – „Gootloader” (Threat Detection Report – opis zagrożenia i typowego wektora). (Red Canary)
5. Microsoft Learn – Policy CSP: AttachmentManager (zarządzanie oznaczaniem strefy pochodzenia plików). (Microsoft Learn)