Nowy wariant ClickFix: nslookup i DNS jako kanał dostarczania ładunku PowerShell (ModeloRAT)

Wprowadzenie do problemu / definicja luki

ClickFix to technika socjotechniczna, w której ofiara — „naprawiając problem” (fałszywy błąd, weryfikację CAPTCHA, rzekomą aktualizację) — sama uruchamia polecenia prowadzące do infekcji. Nowość w opisywanej kampanii polega na tym, że kolejne etapy nie są pobierane klasycznym HTTP/HTTPS, lecz… przez DNS, z użyciem wbudowanego narzędzia nslookup.

---

W skrócie

• Atakujący nakłaniają użytkownika do uruchomienia komendy w oknie Windows Run.
• Komenda wykonuje niestandardowe zapytanie DNS do kontrolowanego przez napastnika serwera DNS i parsuje pole „Name:” z odpowiedzi, by uzyskać kolejny ładunek (PowerShell), który jest następnie wykonywany.
• Łańcuch infekcji prowadzi finalnie do instalacji ModeloRAT (RAT napisany w Pythonie), z mechanizmami rozpoznania i utrzymania się w systemie.

---

Kontekst / historia / powiązania

ClickFix nie jest „jedną rodziną malware”, tylko powtarzalnym wzorcem nadużycia interakcji użytkownika: ofiara uruchamia polecenie, bo wierzy, że to element weryfikacji lub naprawy. Microsoft i inni dostawcy opisywali już wcześniej ClickFix jako łańcuch, który często kończy się infostealerami, RAT-ami lub loaderami i chętnie korzysta z LOLBins (np. PowerShell) w modelu „fileless”.

Proofpoint pokazywał, że ClickFix szybko rozlał się po ekosystemie zagrożeń (różni aktorzy, różne przynęty, wspólny mechanizm „skopiuj-wklej-uruchom”), a kampanie kończyły się m.in. AsyncRAT, DarkGate, Lumma Stealer czy NetSupport.

---

Analiza techniczna / szczegóły luki

1) „Dostarczenie” polecenia i uruchomienie nslookup

W opisywanym wariancie użytkownik dostaje instrukcję uruchomienia polecenia w Windows Run. Polecenie uruchamia nslookup tak, aby zapytać konkretny, zewnętrzny serwer DNS (zamiast systemowego resolvera). W materiale wskazano przykład infrastruktury DNS napastnika (adres IP serwera DNS) oraz mechanikę: odpowiedź DNS jest „spreparowana” tak, by zawierała kolejny etap w polu NAME:.

2) DNS jako „lekki staging”

Kluczowe jest to, że DNS służy tu jako kanał etapowania: ofiara najpierw wykonuje zapytanie DNS, a dopiero potem system uruchamia PowerShell pozyskany z odpowiedzi. To utrudnia pracę obronie opartej wyłącznie o filtrowanie web/URL i proxy HTTP.

3) Kolejne etapy: ZIP → Python → VBS → ModeloRAT

W dalszej części łańcucha (wg opisu bazującego na obserwacjach Microsoft) następuje pobranie archiwum ZIP z zewnętrznej infrastruktury, uruchomienie skryptu w Pythonie (rekonesans, discovery), a następnie zrzut/uruchomienie VBScript i finalnie ModeloRAT zapewniający zdalną kontrolę.

4) Co tu jest sprytne z perspektywy detekcji?

DNS zwykle jest dozwolony w egress, a nslookup.exe to narzędzie administracyjne. To tworzy „szarą strefę” — aktywność może wyglądać jak troubleshooting, dopóki nie spojrzymy na kontekst procesu (np. cmd.exe/Run → nslookup.exe → uruchomienie poleceń/PowerShell) i cechy zapytań (nietypowy serwer, nietypowe typy odpowiedzi, podejrzane payloady w danych odpowiedzi).

---

Praktyczne konsekwencje / ryzyko

• Zwiększona szansa obejścia kontroli webowych: jeśli organizacja mocno filtruje HTTP/HTTPS, a DNS traktuje „po macoszemu”, kanał DNS może stać się skutecznym stagingiem.
• RAT w sieci = ryzyko pełnej kompromitacji: ModeloRAT jako narzędzie zdalnego dostępu może posłużyć do kradzieży danych, rozpoznania, ruchu bocznego i dalszego dropowania ładunków.
• Trudniejsze dochodzenie: część „pobrania” dzieje się w DNS, więc bez logów DNS (i korelacji z endpointem) analiza incydentu jest istotnie utrudniona.

---

Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (0–72h)

1. Wymuś DNS tylko przez zaufane resolvery
   • Blokuj bezpośredni DNS (UDP/TCP 53) do Internetu z sieci użytkowników, jeśli możesz; pozwól tylko na DNS do twoich resolverów / zabezpieczonego forwardera.
2. Wykrywanie nslookup z parametrem serwera / nietypowym wzorcem użycia
   • Alarmuj na nslookup.exe wywołany przez cmd.exe/explorer.exe w kontekście Run + szybkie następstwo uruchomienia PowerShell.
   • Skorzystaj z gotowych reguł detekcji pod nadużycia DNS/nslookup (np. podejrzanie częste wywołania).
3. Zbieraj i koreluj logi DNS + EDR
   • Bez telemetrii DNS możesz nie zobaczyć kluczowego elementu stagingu.

Wzmocnienie średnioterminowe (1–4 tygodnie)

4. Ogranicz PowerShell tam, gdzie się da
   • Constrained Language Mode / polityki aplikacyjne (AppLocker/WDAC), ASR rules, wzmacnianie AMSI/Defender w środowiskach Windows — ClickFix często kończy się PowerShellem.
5. Szkolenia i „bezpieczniki” UX
   • W ClickFix „security boundary” jest użytkownik. Ucz: „nie uruchamiam poleceń z okienek ‘naprawczych’, CAPTCHA i pseudo-aktualizacji”.

---

Różnice / porównania z innymi przypadkami

• Klasyczne ClickFix: często kończy się poleceniem PowerShell, które pobiera payload po HTTP/HTTPS.
• Ten wariant: DNS jest użyty jako kanał etapowania/„sygnalizacji” — a nslookup staje się narzędziem do pobrania kolejnego polecenia z odpowiedzi DNS. To zmienia priorytety obrony: same kontrole webowe nie wystarczą, jeśli DNS nie jest monitorowany i ograniczany.

---

Podsumowanie / kluczowe wnioski

• ClickFix dalej ewoluuje: teraz nie tylko „uruchom PowerShell”, ale też „uruchom nslookup na zewnętrzny DNS i wykonaj to, co wróci”.
• DNS jako staging jest groźny, bo zwykle jest dozwolony i słabiej inspekcjonowany.
• Obrona wymaga połączenia: kontrola egress DNS + telemetria DNS + EDR na endpointach + edukacja użytkowników.

---

Źródła / bibliografia

1. BleepingComputer – opis kampanii DNS/nslookup i mechaniki „Name:” → PowerShell (BleepingComputer)
2. Malwarebytes – omówienie łańcucha ZIP → Python → VBS → ModeloRAT (Malwarebytes)
3. Microsoft Security Blog – tło i typowy łańcuch ClickFix (microsoft.com)
4. Proofpoint – szerszy kontekst rozprzestrzenienia ClickFix i typowe przynęty/payloady (Proofpoint)
5. Elastic – referencje i podejście detekcyjne dla nadużyć DNS/nslookup (Elastic)