Wprowadzenie do problemu / definicja luki
DNS poisoning (zatrucie odpowiedzi DNS) to technika, w której atakujący powoduje, iż ofiara rozwiązuje prawidłową domenę do nieprawidłowego (atakującego) adresu IP. W efekcie użytkownik może łączyć się „z adekwatnym adresem w pasku przeglądarki”, ale faktycznie trafia na serwer kontrolowany przez napastnika — a to idealny punkt wyjścia do cichej dystrybucji malware, zwłaszcza przez mechanizmy aktualizacji o słabej walidacji.
W grudniu 2025 Kaspersky opisał kampanię przypisaną do chińskojęzycznego APT Evasive Panda (alias m.in. Daggerfly/BRONZE HIGHLAND/StormBamboo), w której DNS poisoning posłużył do dostarczania backdoora MgBot w wysoce ukierunkowanych atakach obserwowanych między listopadem 2022 a listopadem 2024.
W skrócie
- Kto: Evasive Panda / Daggerfly (G1034 w MITRE ATT&CK), powiązany z Chinami i znany z ekskluzywnego użycia MgBot.
- Co: ukierunkowana dystrybucja MgBot przez DNS poisoning + fałszywe aktualizacje popularnych aplikacji.
- Gdzie: ofiary wykryte w Türkiye, Chinach i Indiach; część hostów utrzymywana w kompromitacji ponad rok.
- Jak: wieloetapowy łańcuch loaderów i shellcode’u, pobieranie kolejnego etapu jako „PNG” z domeny dictionary[.]com po uprzedniej manipulacji DNS, a następnie szyfrowanie hybrydowe DPAPI+RC5 wiążące payload z konkretną maszyną.
Kontekst / historia / powiązania
Evasive Panda jest aktywny co najmniej od 2012 r., a MITRE wskazuje na jego profil ofiar (m.in. podmioty rządowe/NGO/telekomy) oraz powiązanie z kampaniami o charakterze supply-chain.
To nie pierwsza historia, w której ta grupa „wchodzi w ścieżkę zaufania” użytkownika:
- ESET (kwiecień 2023) opisał przypadek, gdzie kanały aktualizacji legalnych aplikacji zostały przejęte/hijackowane, aby podsunąć instalator MgBot — z rozważanymi hipotezami supply-chain lub ataku typu adversary-in-the-middle.
- Volexity (sierpień 2024) pokazał scenariusz jeszcze cięższego kalibru: DNS poisoning na poziomie ISP, gdzie podmieniano odpowiedzi DNS dla domen mechanizmów aktualizacji, szczególnie gdy aktualizacje szły po HTTP i bez weryfikacji podpisu.
Analiza techniczna / szczegóły luki
1) „Aktualizacja” jako przynęta: SohuVA / iQIYI / Tencent QQ / IObit
W kampanii opisanej przez Kaspersky, startem infekcji był plik udający update do aplikacji (np. SohuVA). Telemetria wskazała pobieranie z zasobu pod domeną p2p.hd.sohu.com[.]cn, a badacze ocenili, iż mogło dojść do DNS poisoning, które kierowało ofiarę na serwer atakującego mimo użycia „prawidłowej” domeny.
Kaspersky dopisał też analogiczny schemat z „fałszywym updaterem” m.in. dla iQIYI, uruchamianym przez legalny qiyiservice.exe, oraz podobne podejście wobec IObit Smart Defrag i Tencent QQ.
2) Loader i etap shellcode: podszycie pod legalny projekt
Loader był napisany w C++ (WTL) i miał przypominać przykładową aplikację (sample) — co utrudnia szybkie odróżnienie „zwykłego” binarium od złośliwego.
3) DNS poisoning jako kanał dostarczania kolejnego etapu (dictionary[.]com)
Istotny fragment łańcucha: jeżeli lokalny plik z danymi nie był obecny, shellcode przechodził do pobrania zaszyfrowanych danych z „web source” kontrolowanego przez atakującego, ale realizowanego poprzez DNS poisoning — w telemetrii wyglądało to jak pobranie „PNG” z legalnego dictionary[.]com.
Co ważne, manipulacja miała być selektywna: ofiary rozwiązywały dictionary[.]com do różnych adresów IP w zależności od geolokalizacji i ISP.
4) „Sprytna” kryptografia: DPAPI + RC5, czyli payload związany z hostem
Kaspersky opisał hybrydę, w której klucz RC5 jest zaszyfrowany DPAPI i zapisany w pierwszych bajtach pliku (perf.dat), a reszta zawartości to payload szyfrowany RC5. Taki zabieg utrudnia analizę, bo DPAPI wiąże odszyfrowanie z konkretną maszyną.
5) In-memory execution i wstrzyknięcie MgBot
Po odszyfrowaniu kolejnego etapu secondary loader inicjuje uruchomienie/iniekcję (m.in. wskazano wstrzyknięcie wariantu MgBot do legalnego svchost.exe). Konfiguracja (m.in. nazwa kampanii, adresy C2) miała być odszyfrowywana prostym XOR, a część infrastruktury C2 wygląda na używaną wieloletnio.
Praktyczne konsekwencje / ryzyko
- Zaufanie do DNS i update’ów jako punkt pojedynczej porażki. jeżeli DNS zostanie „skręcony” (na ISP, w sieci firmowej, na routerze), to choćby rozsądne zachowania użytkownika mogą nie wystarczyć — bo ofiara pobiera „aktualizację” spod znanej domeny.
- Długotrwała, cicha kompromitacja. W tej kampanii część hostów pozostawała zainfekowana ponad rok, a całość (według telemetrii) trwała ok. 2 lata: XI 2022 – XI 2024.
- Trudniejsza analiza i detekcja. Unikalne, per-ofiara elementy (np. dobór odpowiedzi po nagłówkach/wersji Windows) oraz szyfrowanie powiązane z hostem utrudniają triage, sandboxing i „łatwe” IOC-driven hunting.
Rekomendacje operacyjne / co zrobić teraz
Priorytet 1: uszczelnij aktualizacje (software supply chain w skali mikro)
- Wymuszaj aktualizacje po HTTPS i z weryfikacją podpisów (oraz blokuj aktualizatory, które tego nie robią). Volexity wskazywał, iż atakujący wybierali oprogramowanie z niepewnymi mechanizmami update (np. HTTP, brak walidacji podpisu).
- W środowiskach firmowych rozważ allowlistę dla updaterów i repozytoriów aktualizacji oraz kontrolę uruchamiania binariów (AppLocker/WDAC).
Priorytet 2: zredukuj ryzyko manipulacji DNS
- Przestaw stacje/serwery na zaufane resolvery i rozważ DoH/DoT (tam, gdzie to zgodne z polityką), aby utrudnić podmianę odpowiedzi po drodze na poziomie dostawcy. Uwaga: to nie „magiczna tarcza”, jeżeli atakujący siedzi na brzegu sieci lub na urządzeniu końcowym — ale ogranicza klasę ataków na trasie. (W omawianej kampanii mechanizm poisoning pozostaje nie w pełni wyjaśniony).
- Monitoruj rozbieżności DNS (np. porównanie odpowiedzi z kilku resolverów, alerty na nagłe zmiany A/AAAA dla popularnych domen).
Priorytet 3: hunting/IR pod kątem tej kampanii
- Sprawdź artefakty ścieżek i plików wskazywanych w analizie (m.in. %ProgramData%\Microsoft\MF, status.dat, perf.dat) oraz nietypowe biblioteki/dropy związane z loaderem.
- Poluj na podejrzane połączenia do znanych adresów C2 i anomalie w ruchu HTTP związane z pobieraniem „obrazów PNG” z domen, które normalnie nie służą do dystrybucji binariów.
Różnice / porównania z innymi przypadkami
- ESET 2023: fokus na „przejęte aktualizacje” i rozważane scenariusze supply-chain/AitM przy dystrybucji MgBot.
- Volexity 2024: twardy dowód na poisoning na poziomie ISP i wykorzystywanie słabych mechanizmów aktualizacji (HTTP, brak weryfikacji).
- Kaspersky 2025: nacisk na selektywną dystrybucję kolejnych etapów (np. dictionary[.]com rozwiązywany do różnych IP zależnie od ISP/geo) oraz na utrudnianie analizy poprzez DPAPI+RC5 i in-memory injection.
Wspólny mianownik: atakowanie „zaufanych ścieżek” (DNS + aktualizacje), gdzie klasyczne „nie klikaj w linki” ma ograniczoną wartość, bo użytkownik i system robią to, co zwykle.
Podsumowanie / najważniejsze wnioski
Kampania Evasive Panda opisana pod koniec grudnia 2025 r. to podręcznikowy przykład, jak DNS poisoning może stać się „niewidzialnym przewodem” do dystrybucji backdoora MgBot: ofiara widzi legalne domeny, a mimo to pobiera złośliwy kod. Dodatkowo, hybrydowe szyfrowanie (DPAPI+RC5) oraz selektywne odpowiedzi po DNS/HTTP podnoszą koszt obrony i analizy.
Jeśli chcesz zmniejszyć ekspozycję na tę klasę operacji, najwięcej „zysku za wysiłek” dają: twarda polityka bezpiecznych aktualizacji, sensowne zarządzanie DNS (i jego monitoring) oraz przygotowane playbooki huntingowe pod MgBot/Evasive Panda.
Źródła / bibliografia
- The Hacker News — China-Linked Evasive Panda Ran DNS Poisoning Campaign to Deliver MgBot Malware (26.12.2025) (The Hacker News)
- Kaspersky Securelist — Evasive Panda APT poisons DNS requests to deliver MgBot (24.12.2025) (Securelist)
- Volexity — StormBamboo Compromises ISP to Abuse Insecure Software Update Mechanisms (02.08.2024) (Volexity)
- ESET WeLiveSecurity — Evasive Panda APT group delivers malware via updates for popular Chinese software (26.04.2023) (We Live Security)
- MITRE ATT&CK — Daggerfly / Evasive Panda (G1034) (aktualizacja: 31.10.2024) (MITRE ATT&CK)
