Czy da się wykorzystać legalny serwis Googla do dystrybucji złośliwego oprogramowania? Cyberprzestępcy znaleźli sposób – szczegóły kampanii DesckVB RAT

Badacze bezpieczeństwa z firmy Huntress przeprowadzili analizę złośliwej kampanii spamowej dostarczającej trojana DesckVB RAT. To, co ją przede wszystkim wyróżnia, to mechanizm automatycznego dostosowywania strony phishingowej do profilu celu. 

TLDR:

• Badacze bezpieczeństwa z firmy Huntress opisali złośliwą kampanię spamową, której celem jest dystrybucja trojana DesckVB RAT.
• Cyberprzestępcy korzystają z platformy DoubleClick (należącej do Google), aby ominąć zabezpieczenia bramek pocztowych i dostarczyć złośliwy link ukryty wewnątrz załącznika HTML w wiadomości email.
• To, co wyróżnia tę kampanię, to m.in. sposób przygotowania witryny phishingowej.
• Strona jest dynamicznie generowana, na podstawie adresu email użytkownika. W przypadku problemów ze znalezieniem nazwy oraz logo firmy, do skryptu generującego podpięto wyszukiwarkę Bing.
• Dalsza część ataku to już klasyka gatunku: unieszkodliwienie systemów antywirusowych, nawiązanie komunikacji z serwerem atakujących, pobranie właściwego ładunku oraz przejęcie kontroli nad maszyną celu.

Cyberprzestępcy nie muszą już przeprowadzać manualnego OSINT-u, aby dostosować wygląd witryny do konkretnej organizacji. Nie potrzebują również utrzymywać kilkunastu serwerów hostujących różne warianty paneli phishingowych. Wystarczy im jeden serwer oraz odpowiedni skrypt, który “w locie” wygeneruje odpowiednie treści.

Jak to wygląda w praktyce? 

Użytkownik otrzymuje wiadomość email z załącznikiem w postaci pliku HTML o nazwie Bestellung_2026.html (jest to przykład podany przez badaczy, w innych odsłonach kampanii nazwa pliku może się różnić). Po jego otwarciu, zaszyty w środku kod automatycznie przekierowuje użytkownika na legalny, służący do śledzenia kliknięć adres URL w domenie ad[.]doubleclick[.]net (należący do Google). Serwer po odnotowaniu tego faktu natychmiast “odbija” użytkownika dalej, wysyłając go na witrynę kontrolowaną przez atakującego.

Co ciekawe, skrypt automatycznie dekoduje (Base64) adres email celu (zaszyty na samym końcu linku) i na jego podstawie pobiera logo oraz nazwę potencjalnej firmy. Korzystając z adresu IP określa również przybliżoną lokalizację użytkownika (wyświetlając miasto oraz lokalny czas). 

Dzięki temu formularz jest generowany dynamicznie i dopasowuje się do konkretnego użytkownika, sugerując że znajduje się w bezpiecznej lokalizacji korporacyjnej. W przypadku problemów ze znalezieniem odpowiedniej grafiki lub nazwy firmy skrypt może odpytać wyszukiwarkę Bing, aby na podstawie domeny odczytanej z adresu email spróbować wyciągnąć powyższe informacje.

Warto zadać sobie pytanie, dlaczego atakujący skorzystali z domeny ad.doubleclick[.]net. Odpowiedź jest stosunkowo prosta: chodzi o uśpienie czujności systemów antywirusowych i bramek pocztowych. Z punktu widzenia mechanizmów bezpieczeństwa taki link wygląda na bezpieczny, zwłaszcza że platforma DoubleClick posiada nienaganną reputację i jest często stosowana przez reklamodawców.

Ponadto cyberprzestępcy często stosują mechanizmy, które w przypadku wykrycia bota lub środowiska wirtualnego przekierowują użytkownika na niegroźną stronę (np. wyszukiwarkę). W efekcie złośliwa akcja nie zostanie wykonana, a automatyczne systemy filtrujące ruch uznają link za bezpieczny.

Jeżeli do tego momentu, użytkownik nie zorientuje się, że coś jest nie tak i uruchomi zapakowany w archiwum plik, jego maszyna zostanie zainfekowana. Dalszy schemat ataku powiela scenariusze, które często pokazujemy na łamach sekuraka. 

Pobrane archiwum zawiera silnie zaciemniony plik JavaScript, którego zadaniem jest pobranie loadera .NET (hostowanego przez cyberprzestępców). Podczas uruchomienia, skrypt w pierwszej kolejności weryfikuje lokalizację, z której został wywołany. Jeżeli znajduje się ona przykładowo w Downloads, kopiuje się do katalogu C:\\Users\Public, a następnie uruchamia ponownie z nowej lokalizacji, zamykając swoją pierwotną instancję.

Wewnątrz skryptu umieszczono szereg instrukcji nie mających związku ze złośliwą aktywnością. Zostały zaimplementowane celowo, aby utrudnić proces analizy. Śledząc zawartość pliku możemy zauważyć wiele zakodowanych zmiennych, funkcji, komentarzy w języku portugalskim oraz obiekt typu BLOB zakodowany w Base64. Został on zaciemniony za pomocą znaków “A” oraz tokenów “9999”.

Po zdjęciu warstwy obfuskacyjnej, atakujący zapisują odczytany obiekt jako skrypt PowerShell, a następnie uruchamiają go z uprawnieniami zalogowanego użytkownika.

W następnym kroku skrypt sprawdza połączenie sieciowe z serwisem Google. W przypadku braku dostępu do sieci lub wykrycia środowiska testowego (m.in. Any.run, OllyDbg, Wireshark), skrypt przerywa działanie i restartuje komputer (Restart-Computer -Force). Jeśli jednak proces weryfikacji zakończy się pomyślnie i nie zostanie wykryty żaden sandbox, złośliwy kod kontynuuje pracę. Efektem końcowym jest pobranie loadera .NET oraz zapisanie go w postaci pliku pliku 03.txt. 

Pobrany loader ponownie weryfikuje środowisko uruchomieniowe, szukając dodatkowo artefaktów maszyn wirtualnych, wskaźników środowisk chmurowych (Azure Guest Agent) oraz podłączonych debuggerów. Wykrycie któregokolwiek z nich powoduje restart systemu lub ciche zakończenie działania procesu. Jeśli proces zakończy się zgodnie z oczekiwaniami atakujących, loader przeprowadzi szereg akcji w systemie (w przypadku niektórych z nich wymagane jest konto lokalnego administratora), skutecznie paraliżując tym samym działanie mechanizmów bezpieczeństwa.

Malware dokonuje zmian w Antimalware Scan Interface (AMSI) w systemie Windows 11 (wersja 24H2), biorąc na cel funkcję NtManageHotPatch. Nadpisuje jej prolog w taki sposób, aby każdorazowo zwracała wartość STATUS_NOT_SUPPORTED. W efekcie automatyczne skanowanie złośliwych skryptów “w locie” przestaje działać.

Malware neutralizuje mechanizm Event Tracing for Windows (ETW) poprzez nadpisanie funkcji EtwEventWrite w bibliotece ntdll.dll. Wykorzystuje do tego celu instrukcje assemblerowe: xor rax, rax; ret, które zerują rejestr rax wykorzystywany w ABI (Application Binary Interface) x86-64 do przekazywania wartości zwracanej z funkcji i natychmiast przerywają jej działanie, symulując pomyślne wykonanie. W konsekwencji systemowe logi przestają rejestrować podejrzaną aktywność.

Dla jasności, po uruchomieniu złośliwego oprogramowania system automatycznie ładuje do procesu biblioteki systemowe, a malware przeprowadza powyższe modyfikacje wyłącznie w ramach swojego procesu. Nie globalnie w całym systemie. Z tego powodu, każdorazowo po uruchomieniu złośliwego kodu, proces “wyciszania” mechanizmów bezpieczeństwa musi zostać powtórzony.

Kolejnym krokiem jest wyłączenie ochrony w czasie rzeczywistym w Microsoft Defender oraz dodanie dysku systemowego do listy wykluczeń skanowania.

Jeżeli system jest już “oślepiony” następuje nawiązanie połączenia z serwerem Command & Control (C2) celem pobrania właściwego ładunku. Malware pobiera dwa pliki: szablon PowerShell oraz bibliotekę .dll zapisując je odpowiednio pod nazwami 02.txt i 01.txt. Analogicznie jak w przypadku loadera, ich zawartość została silnie zaciemniona.

Po zdjęciu warstw obfuskacji następuje przygotowanie złośliwego skryptu .ps1 oraz zapisanie go pod losową nazwą w ukrytym katalogu użytkownika (najczęściej jest to AppData\Local\ w podfolderze imitującym legalne oprogramowanie firmy NVIDIA). Malware zapewnia sobie trwałość w środowisku użytkownika poprzez modyfikację rejestru systemowego (klucze Run/RunOnce) oraz utworzenie zaplanowanych zadań (Scheduled Tasks).

Co istotne, złośliwe instrukcje są wczytywane bezpośrednio do pamięci RAM korzystając z techniki Reflective Loading. Dzięki temu proces infekcji odbywa się w trybie bezplikowym (fileless), co pozwala na ominięcie tradycyjnych skanerów antywirusowych oraz utrudnia późniejszy etap analizy powłamaniowej.

Zaprezentowany schemat ataku jest szczególnie niebezpieczny, ponieważ wykorzystuje legalne serwisy oraz narzędzia systemowe, aby zmylić automatyczne skanery bezpieczeństwa oraz uniknąć wykrycia przez zaawansowane systemy klasy EDR.

Z punktu widzenia użytkownika, najlepszym sposobem obrony przed tego typu zagrożeniami jest zachowanie szczególnej ostrożności. Nie istnieje uniwersalna metoda pozwalająca na odparcie ataków socjotechnicznych. To użytkownik jest celem i od jego decyzji zależy bezpieczeństwo przetwarzanych danych.

Źródło: huntress.com 

~_secmike