Archiwa: PowerShell - Strona 7 z 53

GodDamn ransomware wykorzystuje sterownik PoisonX do wyłączania ochrony endpointów

Wprowadzenie do problemu / definicja

GodDamn to nowo opisana rodzina ransomware, która wyróżnia się użyciem sterownika jądra PoisonX do neutralizowania mechanizmów ochronnych jeszcze przed uruchomieniem szyfrowania. Taka taktyka wpisuje się w model BYOVD, czyli nadużycie zaufanego lub podpisanego sterownika w celu obejścia zabezpieczeń systemowych i ograniczenia skuteczności narzędzi EDR oraz AV.

W praktyce oznacza to przejście od prostego wyłączania procesów bezpieczeństwa do ingerencji na poziomie jądra Windows. Dla obrońców jest to szczególnie niebezpieczne, ponieważ atakujący zyskują możliwość osłabienia telemetrii i reakcji ochrony jeszcze przed właściwą fazą destrukcyjną.

W skrócie

GodDamn jest łączony z wcześniejszymi wariantami ransomware znanymi jako Monster i Beast.
Napastnicy wykorzystują AnyDesk do zdalnego dostępu i utrwalania obecności w środowisku.
Do kradzieży poświadczeń stosowane są narzędzia NirSoft, Mimikatz oraz dodatkowe utility do rozpoznania infrastruktury.
Kluczowym elementem kampanii jest sterownik PoisonX, wdrażany jako g11.sys, służący do wyłączania ochrony endpointów.
Ruch boczny realizowany jest między innymi przez PsExec, a sam atak ma charakter wieloetapowy i przygotowywany jest przez kilka dni.

Kontekst / historia

Z dostępnych analiz wynika, że operatorzy GodDamn mogą stanowić kontynuację linii rozwojowej zagrożenia obserwowanej wcześniej jako Monster, a następnie Beast. Starsze warianty były kojarzone z aktywnością przypisywaną podmiotowi śledzonemu jako Hyadina i od co najmniej 2022 roku były rozwijane z myślą o środowiskach Windows.

W kolejnych etapach ewolucji kampania zyskała nowe możliwości operacyjne, w tym szersze wsparcie dla różnych platform oraz bardziej dojrzały zestaw narzędzi do działań po uzyskaniu dostępu. GodDamn wydaje się następnym krokiem w tej ewolucji, z wyraźnym naciskiem na obchodzenie zabezpieczeń i przygotowanie infrastruktury ofiary przed uruchomieniem szyfratora.

Analiza techniczna

W badanym incydencie początkowy wektor wejścia nie został jednoznacznie ustalony, ale najwcześniejsze oznaki aktywności wskazywały na ręczne dostarczenie AnyDesk do niestandardowej lokalizacji w katalogu użytkownika. Taki wzorzec często sugeruje, że intruz posiadał już wstępny dostęp i przechodził do fazy utrwalania obecności.

Następnie wdrożono komponent podszywający się pod legalne oprogramowanie bezpieczeństwa, zapisany jako symantec.exe, którego zadaniem było zainstalowanie sterownika PoisonX pod nazwą g11.sys. Po załadowaniu sterownik miał umożliwiać kończenie procesów produktów ochronnych oraz usuwanie mechanizmów hookowania w przestrzeni użytkownika, co ogranicza widoczność działań napastnika i utrudnia skuteczną detekcję.

Równolegle operatorzy wdrażali narzędzia służące do pozyskiwania poświadczeń z przeglądarek, klientów pocztowych, menedżera poświadczeń Windows, konfiguracji Wi-Fi, sesji VNC i innych zasobów lokalnych. Obecność Mimikatz oraz utility do enumeracji hostów wskazuje, że faza poprzedzająca szyfrowanie była nastawiona na szybkie podniesienie uprawnień, rozpoznanie środowiska i rozszerzenie zasięgu kompromitacji.

Do ruchu bocznego wykorzystano PsExec, a na kolejnych hostach konfigurowano AnyDesk w trybie nienadzorowanego dostępu. Napastnicy przygotowywali własne pliki konfiguracyjne, ustawiali hasła, tworzyli usługi systemowe uruchamiane automatycznie po restarcie i w części przypadków automatyzowali wdrożenie przy użyciu skryptów PowerShell. Po rozmieszczeniu persystencji na wielu stacjach wykonywano restarty hostów w celu potwierdzenia poprawnego działania mechanizmów trwałości.

Dopiero po kilku dniach przygotowań wykrywano właściwy ładunek ransomware. W części obserwowanych przypadków zaszyfrowane pliki otrzymywały rozszerzenie .God8Damn, ale w niektórych incydentach używano rozszerzeń dostosowanych do nazwy ofiary, co może wskazywać na ręczne modyfikacje kampanii lub indywidualną konfigurację ataku.

Konsekwencje / ryzyko

Największe zagrożenie wynika tu z połączenia kradzieży poświadczeń, skutecznego ruchu bocznego i wyłączania ochrony na poziomie endpointu. Jeśli napastnik uzyskuje możliwość osłabienia lub wyłączenia narzędzi bezpieczeństwa przed szyfrowaniem, organizacja może stracić cenny czas potrzebny na wykrycie i powstrzymanie incydentu.

Dodatkowym ryzykiem jest wieloetapowy charakter operacji. Operatorzy nie ograniczają się do szybkiego zaszyfrowania pojedynczej stacji, lecz przygotowują środowisko na wielu hostach, budują trwały dostęp i dopiero potem przechodzą do fazy końcowej. Taki model zwiększa prawdopodobieństwo jednoczesnego uderzenia w większą część infrastruktury oraz stwarza warunki do potencjalnej eksfiltracji danych.

Dla zespołów SOC i IR wyzwaniem jest również to, że używane narzędzia, takie jak AnyDesk, PsExec czy utility klasy NirSoft, mogą występować także w legalnych scenariuszach administracyjnych. Kluczowe staje się więc monitorowanie kontekstu użycia, nietypowych ścieżek instalacji, sekwencji zdarzeń oraz korelacji czasowej między zmianami konfiguracji, restartami hostów i aktywnością związaną z poświadczeniami.

Rekomendacje

Organizacje powinny wzmocnić kontrolę ładowania sterowników i monitorować wszystkie przypadki instalacji nowych komponentów jądra, zwłaszcza jeśli pojawiają się one poza standardowym procesem zarządzania oprogramowaniem. W środowiskach Windows warto wdrożyć polityki ograniczające użycie nieautoryzowanych sterowników oraz mechanizmy blokowania znanych technik BYOVD.

Należy także ograniczyć możliwość niekontrolowanego stosowania narzędzi zdalnego dostępu. AnyDesk i podobne rozwiązania powinny działać wyłącznie w zatwierdzonym modelu, z centralnym nadzorem, kontrolą konfiguracji i jasno określonymi lokalizacjami instalacji. Uruchamianie takich aplikacji z katalogów użytkownika lub niestandardowych ścieżek powinno wywoływać alerty bezpieczeństwa.

Równie istotne jest monitorowanie narzędzi służących do odzyskiwania haseł i dumpingu poświadczeń. Pojawienie się ich w połączeniu z PsExec, zmianami w ustawieniach ochrony, tworzeniem usług systemowych i serią restartów hostów stanowi silny wskaźnik kompromitacji.

monitorowanie tworzenia i ładowania nietypowych sterowników,
wykrywanie prób wyłączania Microsoft Defender i innych agentów ochronnych,
analiza użycia PsExec do zdalnego uruchamiania poleceń,
identyfikacja masowej instalacji AnyDesk lub podobnych narzędzi,
korelacja obecności utility NirSoft i Mimikatz na wielu hostach,
wykrywanie nagłych restartów stacji po zmianach usług systemowych.

Uzupełnieniem tych działań powinny być segmentacja sieci, ograniczenie uprawnień administratorów lokalnych, MFA dla dostępu uprzywilejowanego, ścisłe zarządzanie udziałami administracyjnymi oraz regularne testy odtwarzania kopii zapasowych. W przypadku wykrycia takiej aktywności kluczowe jest szybkie odizolowanie hostów, zabezpieczenie artefaktów pamięci i dysku oraz sprawdzenie, czy na innych segmentach nie rozmieszczono już kanałów zdalnego dostępu.

Podsumowanie

GodDamn pokazuje, że nowoczesne kampanie ransomware coraz częściej mają charakter pełnoskalowych operacji intruzyjnych, a nie jedynie prostych incydentów szyfrowania danych. Wykorzystanie sterownika PoisonX znacząco podnosi poziom zagrożenia, ponieważ pozwala aktywnie osłabiać zabezpieczenia jeszcze przed uruchomieniem szyfratora.

Połączenie techniki BYOVD, kradzieży poświadczeń, ruchu bocznego i trwałego dostępu zdalnego sprawia, że organizacje muszą monitorować cały łańcuch operacyjny ataku. Skuteczna obrona wymaga nie tylko wykrywania samego ransomware, ale także wczesnego identyfikowania działań przygotowawczych, które poprzedzają fazę końcową.

Źródła

Agenci AI do programowania wywołują alerty EDR jak realni atakujący

Wprowadzenie do problemu / definicja

Narzędzia typu AI coding agent coraz częściej działają bezpośrednio na stacjach roboczych programistów, automatyzując pisanie kodu, testy, instalację zależności oraz obsługę lokalnego środowiska. Problem polega na tym, że część ich aktywności z perspektywy systemów EDR i detekcji behawioralnej wygląda niemal identycznie jak działania prowadzone przez intruzów.

W praktyce legalne operacje wykonywane przez asystentów AI mogą uruchamiać reguły bezpieczeństwa zaprojektowane do wykrywania kradzieży poświadczeń, nadużyć narzędzi systemowych oraz mechanizmów persistence. To nowy problem operacyjny dla zespołów bezpieczeństwa, które muszą odróżniać dozwoloną automatyzację od rzeczywistego incydentu.

W skrócie

Badania telemetryczne pokazały, że agenci AI do programowania generują zachowania podobne do aktywności malware i narzędzi post-exploitation.
Zaobserwowano m.in. użycie DPAPI, enumerację Credential Manager, pobieranie plików przez certutil i bitsadmin oraz zapisy do autostartu.
Choć działania te nie muszą być złośliwe, ich profil behawioralny pokrywa się z technikami regularnie monitorowanymi przez EDR.
Efektem jest wzrost szumu alertowego, trudniejszy triage i większe ryzyko przeoczenia realnego ataku.

Kontekst / historia

W ostatnich latach ochrona endpointów przesunęła się z prostego wykrywania szkodliwych plików w stronę analizy zachowań procesów, relacji rodzic–dziecko, dostępu do poświadczeń oraz nadużyć legalnych narzędzi systemowych. Taki model był odpowiedzią na wzrost ataków bezplikowych i technik living-off-the-land.

Pojawienie się autonomicznych agentów AI uruchamianych lokalnie zmienia jednak ten krajobraz. Asystent wspierający dewelopera może zatrzymywać procesy, uruchamiać PowerShell, pobierać komponenty, instalować interpretery i manipulować danymi przeglądarki lub środowiska testowego. Dla systemu EDR kluczowa nie jest intencja użytkownika, ale obserwowany wzorzec aktywności.

Analiza techniczna

Najważniejszy wniosek jest taki, że część agentów AI wykonuje operacje od dawna uznawane za sygnały wysokiego ryzyka. Jednym z przykładów jest użycie Windows Data Protection API do odszyfrowywania zapisanych danych przeglądarki. To legalny mechanizm systemowy, ale z perspektywy obrony jego wykorzystanie do dostępu do sekretów bywa kojarzone z infostealerami i narzędziami przejmującymi sesje.

W analizowanych scenariuszach obserwowano także zatrzymywanie aktywnej przeglądarki, a następnie uruchamianie skryptów pobierających informacje z magazynu poświadczeń. Taki łańcuch zdarzeń przypomina procedury stosowane podczas kradzieży haseł lub tokenów sesyjnych. Dodatkowo pojawiła się enumeracja danych z Windows Credential Manager przy użyciu polecenia cmdkey /list.

Kolejnym obszarem były operacje pobierania plików z użyciem certutil i bitsadmin. Oba narzędzia są natywnie dostępne w systemie Windows i od lat bywają nadużywane przez operatorów malware w ramach technik LOLBin. Szczególnie istotne jest to, że agent potrafił zmieniać metodę pobrania po niepowodzeniu pierwszej próby, co przypomina adaptacyjne zachowanie spotykane u bardziej zaawansowanych przeciwników.

Odnotowano również zapis skryptu do folderu autostartu przy pomocy PowerShell. Niezależnie od intencji taki zapis do lokalizacji uruchamianej przy starcie systemu jest klasycznym wskaźnikiem persistence i w środowiskach korporacyjnych zwykle wymaga szybkiej weryfikacji.

Problem nie wynika więc z pojedynczej podatności, ale z kolizji dwóch trendów: rosnącej autonomii agentów AI oraz coraz większej zależności obrony od detekcji behawioralnej. Jeżeli agent działa w kontekście zaufanego użytkownika i korzysta z jego uprawnień, granica między legalną automatyzacją a aktywnością podejrzaną zaczyna się zacierać.

Konsekwencje / ryzyko

Najbardziej oczywistym skutkiem jest wzrost liczby alertów na stacjach roboczych programistów. Taki szum może prowadzić do zmęczenia analityków SOC, opóźnień w triage oraz błędnej klasyfikacji zdarzeń. Jeżeli organizacja zbyt szeroko wyciszy reguły wyzwalane przez agentów AI, może jednocześnie obniżyć zdolność wykrywania realnych incydentów wykorzystujących identyczne techniki.

Drugim ryzykiem jest nadmierne zaufanie do narzędzi działających w kontekście konta użytkownika. Sam fakt, że operację inicjuje asystent AI, nie oznacza jeszcze, że dostęp do poświadczeń, danych przeglądarki czy autostartu powinien być akceptowany. Te czynności pozostają wrażliwe bez względu na to, czy wykonuje je człowiek, malware czy agent wspierający dewelopera.

Nie można też pominąć scenariuszy nadużycia. Jeśli agent jest podatny na zatrute wejście, manipulację promptem, złośliwe repozytorium lub niebezpieczną konfigurację, to te same uprawnienia, które dziś powodują fałszywe alarmy, jutro mogą posłużyć do wykonania rzeczywiście złośliwego kodu.

Rekomendacje

Rozdziel polityki detekcji dla stacji deweloperskich i pozostałych endpointów, uwzględniając specyfikę pracy agentów AI.
Nie wyciszaj automatycznie alertów związanych z poświadczeniami, DPAPI, Credential Manager czy mechanizmami persistence.
Wdróż centralne zarządzanie konfiguracją agentów i blokuj tryby ograniczające nadzór lub zgody użytkownika.
Monitoruj procesy potomne uruchamiane przez agentów, zwłaszcza PowerShell, cmd, python oraz inne narzędzia LOLBin.
Stosuj separację sekretów, tokeny o minimalnych uprawnieniach oraz izolowane środowiska uruchomieniowe.
Zaktualizuj procedury triage tak, aby alert generowany przez agenta AI nie był z góry uznawany za fałszywie dodatni.

Podsumowanie

Agenci AI do programowania stają się nowym źródłem aktywności, która z perspektywy platform EDR wygląda jak klasyczne techniki ataku. Nie oznacza to automatycznie, że same narzędzia są złośliwe, ale potwierdza, że bezpieczeństwo endpointów w erze agentów wymaga nowego modelu kontroli, nadzoru i strojenia reguł.

Dla organizacji najważniejszy wniosek jest praktyczny: należy utrzymać wysoką czułość wobec dostępu do poświadczeń i mechanizmów autostartu, a jednocześnie precyzyjnie dopasować polityki bezpieczeństwa do legalnych scenariuszy pracy agentów. W przeciwnym razie zespoły SOC będą zmuszone wybierać między nadmiarem alertów a utratą widoczności na realne techniki wykorzystywane przez atakujących.

Źródła

SCMBANKER atakuje klientów banków w Meksyku. ClickFix otwiera drogę do przejęcia sesji finansowych

Wprowadzenie do problemu / definicja

SCMBANKER to zestaw złośliwych narzędzi zaprojektowanych z myślą o oszustwach finansowych i przejmowaniu aktywności użytkownika związanej z bankowością elektroniczną. Najnowsza opisana kampania koncentruje się na klientach banków, fintechów, operatorów płatności i giełd kryptowalut w Meksyku, wykorzystując technikę ClickFix jako punkt wejścia do infekcji.

ClickFix polega na nakłonieniu ofiary do samodzielnego uruchomienia złośliwego polecenia w systemie Windows. To sprawia, że atak nie opiera się wyłącznie na klasycznym pobraniu pliku, ale na socjotechnice, która nadużywa zaufania użytkownika do pozornie legalnych komunikatów bezpieczeństwa.

W skrócie

Kampania wykorzystuje fałszywe strony weryfikacyjne stylizowane na mechanizmy CAPTCHA lub komunikaty bezpieczeństwa. Użytkownik jest instruowany, aby skopiować i uruchomić komendę, co rozpoczyna wieloetapowy łańcuch infekcji.

atak wykorzystuje technikę ClickFix,
malware wdraża kilka modułów PowerShell i VBScript,
może monitorować aktywność bankową ofiary,
przechwytuje dane ze schowka i wykonuje zrzuty ekranu,
wspiera phishing, vishing i zdalne przejęcie kontroli nad systemem.

Kontekst / historia

ClickFix zyskał popularność jako skuteczny element łańcucha infekcji, ponieważ przenosi część odpowiedzialności za uruchomienie ataku na samą ofiarę. Dzięki temu cyberprzestępcy mogą omijać część tradycyjnych mechanizmów ochronnych opartych na analizie plików i znanych wskaźnikach kompromitacji.

W analizowanej operacji badacze powiązali aktywność z klastrem śledzonym jako REF6045. Część komponentów SCMBANKER ma pochodzić co najmniej z października 2025 roku, co wskazuje, że narzędzie było rozwijane przez dłuższy czas i dostosowywane do lokalnego rynku finansowego.

Kampania wpisuje się w szerszy trend specjalizacji zagrożeń bankowych. Zamiast masowych infekcji coraz częściej obserwujemy operacje precyzyjnie dopasowane do konkretnych instytucji, sesji użytkownika i momentu, w którym ofiara loguje się do bankowości elektronicznej.

Analiza techniczna

Łańcuch infekcji zaczyna się od fałszywej strony weryfikacyjnej, która podszywa się pod legalny test bezpieczeństwa. Ofiara otrzymuje instrukcję wykonania działania w oknie „Uruchom” systemu Windows, co prowadzi do uruchomienia złośliwego polecenia.

Po wykonaniu komendy startuje skrypt wsadowy odpowiedzialny za kolejne etapy instalacji. W pierwszej fazie malware wyświetla ekran przypominający aktualizację Windows, aby odwrócić uwagę użytkownika i zyskać czas na pobranie dalszych komponentów.

Następnie zagrożenie sprawdza poziom uprawnień. Jeśli nie ma odpowiednich uprawnień, może wielokrotnie wywoływać monit UAC, próbując skłonić ofiarę do zatwierdzenia podniesienia uprawnień. Po ich uzyskaniu blokowane są wybrane elementy interfejsu, co utrudnia przerwanie procesu.

Do pobierania dodatkowych modułów wykorzystywane są natywne narzędzia systemowe, w tym bitsadmin. To przykład techniki living-off-the-land, w której atakujący używają legalnych komponentów Windows, aby ograniczyć liczbę łatwo wykrywalnych artefaktów.

Malware utrzymuje persystencję poprzez folder autostartu oraz klucz Run w rejestrze. Po zakończeniu instalacji może wymusić restart systemu, aby wznowić działanie po ponownym uruchomieniu w bardziej stabilnym stanie.

Kluczowym elementem zestawu jest VBScript pełniący rolę programu rozruchowego dla równoległych modułów PowerShell. Poszczególne komponenty odpowiadają za różne zadania operacyjne.

aktualizację zestawu narzędzi,
komunikację z infrastrukturą dowodzenia i kontroli,
instalację komercyjnego narzędzia zdalnego dostępu,
przechwytywanie i podmianę numerów rachunków CLABE oraz numerów kart w schowku,
wykonywanie poleceń PowerShell,
monitorowanie aktywności bankowej na podstawie tytułów aktywnych okien,
wyświetlanie fałszywych komunikatów wspierających vishing,
przekierowywanie przeglądarki na strony phishingowe.

Moduł monitorujący aktywność porównuje nazwy aktywnych okien z listą podmiotów finansowych powiązanych z rynkiem meksykańskim. Po wykryciu dopasowania może uruchomić zrzuty ekranu i rejestrowanie aktywności użytkownika, aktywując się wtedy, gdy ofiara staje się najbardziej wartościowym celem.

Szczególnie niebezpieczne są dwa scenariusze. Pierwszy to podmiana danych w schowku, w której numer rachunku lub karty zostaje zastąpiony przez wartość kontrolowaną przez przestępców. Drugi to aktywne przekierowanie przeglądarki, które może doprowadzić użytkownika na spreparowaną stronę phishingową bez oczywistego sygnału manipulacji.

Konsekwencje / ryzyko

Ryzyko związane z SCMBANKER jest wysokie, ponieważ kampania łączy socjotechnikę, wykorzystanie legalnych narzędzi systemowych, monitoring sesji bankowej oraz możliwość ręcznej interwencji operatora. Taki model znacząco zwiększa skuteczność przejęcia konta i modyfikacji przebiegu transakcji.

Dla użytkowników indywidualnych oznacza to ryzyko utraty środków, przejęcia kont bankowych, wyłudzenia danych uwierzytelniających oraz dalszych nadużyć po uzyskaniu zdalnego dostępu do urządzenia. Dla instytucji finansowych i fintechów problem jest szerszy, ponieważ kampania może prowadzić do oszustw autoryzowanych przez samych klientów, co komplikuje wykrywanie i obsługę incydentów.

Dodatkowym wyzwaniem jest warunkowe uruchamianie funkcji ataku. Oznacza to, że część aktywności może pozostać niewidoczna w standardowym monitoringu, jeśli użytkownik nie wejdzie w interakcję z konkretną usługą finansową.

Rekomendacje

Organizacje powinny traktować kampanie ClickFix jako pełnoprawny wektor początkowego dostępu. Obrona przed nimi wymaga połączenia kontroli technicznych, monitoringu behawioralnego i edukacji użytkowników.

wzmacniać ochronę przed nieautoryzowanym uruchamianiem PowerShell, VBScript i skryptów wsadowych,
monitorować nietypowe użycie bitsadmin, wpisów Run w rejestrze oraz folderów autostartu,
szkolić użytkowników, by nie uruchamiali poleceń kopiowanych ze stron podszywających się pod CAPTCHA lub komunikaty bezpieczeństwa,
budować detekcję opartą na zachowaniach zamiast wyłącznie na sygnaturach,
rozwijać mechanizmy antyfraudowe wykrywające anomalie w sesjach i transakcjach,
ograniczać możliwość instalacji narzędzi zdalnego dostępu oraz wdrażać EDR z dobrą widocznością procesów potomnych i aktywności PowerShell.

W środowiskach o podwyższonym ryzyku warto również rozważyć ścisłe audytowanie lub blokowanie interpreterów skryptowych tam, gdzie nie są one niezbędne biznesowo.

Podsumowanie

SCMBANKER pokazuje, że współczesne kampanie bankowe coraz rzadziej ograniczają się do zwykłej kradzieży haseł. Coraz częściej celem jest przejęcie całego kontekstu transakcyjnego ofiary, wpływanie na jej decyzje w czasie rzeczywistym i manipulowanie przebiegiem sesji finansowej.

Choć obecna kampania koncentruje się na użytkownikach sektora finansowego w Meksyku, sam model operacyjny można stosunkowo łatwo zaadaptować do innych krajów i instytucji. To oznacza, że obrona musi obejmować jednocześnie edukację użytkowników, telemetrię endpointów i zaawansowaną analitykę antyfraudową.

Źródła

The Hacker News — SCMBANKER Malware Uses ClickFix Lures to Target Mexican Banking Users

Agenci AI do programowania uruchamiają reguły EDR przeznaczone do wykrywania ataków

Wprowadzenie do problemu

Rosnąca popularność agentów AI wspierających programowanie zmienia sposób, w jaki zespoły bezpieczeństwa interpretują aktywność na stacjach roboczych deweloperów. Narzędzia takie jak asystenci kodowania, automatyzacja testów czy agenci wykonujący polecenia w kontekście użytkownika potrafią realizować działania, które z perspektywy systemów EDR wyglądają niemal identycznie jak techniki stosowane przez intruzów.

Problem nie sprowadza się wyłącznie do fałszywych alarmów. Coraz częściej dochodzi do zatarcia granicy między legalną automatyzacją a zachowaniami, które przez lata były uznawane za silny wskaźnik kompromitacji endpointu.

W skrócie

Agenci AI do kodowania zaczęli regularnie wyzwalać reguły bezpieczeństwa punktów końcowych.
Najczęściej dotyczy to dostępu do poświadczeń, uruchamiania kodu oraz pobierania plików narzędziami systemowymi.
Zjawisko utrudnia pracę SOC, ponieważ te same wzorce mogą oznaczać zarówno atak, jak i legalne działanie asystenta AI.
Największym wyzwaniem staje się dziś analiza kontekstowa, a nie sama obserwacja pojedynczej akcji.

Kontekst i historia

Przez lata systemy EDR były dostrajane do wykrywania aktywności charakterystycznej dla operatorów ataków lub złośliwego oprogramowania. Wysoką wagę przypisywano zwłaszcza sygnałom związanym z kradzieżą poświadczeń, nadużywaniem wbudowanych narzędzi systemowych oraz mechanizmami utrwalania dostępu.

Zmiana nastąpiła wraz z upowszechnieniem agentów AI, które zaczęły wykonywać podobne operacje w ramach codziennych zadań deweloperskich. Automatyzacja pracy z przeglądarką, testami, repozytoriami i środowiskiem systemowym sprawiła, że część dawnych heurystyk przestała być jednoznaczna.

To zjawisko wpisuje się w szerszy trend w cyberbezpieczeństwie, w którym nowoczesne ataki coraz częściej wykorzystują legalne poświadczenia, zaufane narzędzia administracyjne oraz działania bez klasycznego malware. W takim modelu sam fakt wykonania danej czynności nie wystarcza już do oceny ryzyka.

Analiza techniczna

Najbardziej problematyczną kategorią zdarzeń okazały się operacje związane z dostępem do poświadczeń. W analizowanych przypadkach obserwowano użycie mechanizmów takich jak Windows Data Protection API do odszyfrowywania danych przechowywanych przez przeglądarki. Z punktu widzenia EDR takie zachowanie od dawna kojarzone jest z próbą wykradania sekretów z endpointu.

W praktyce agent AI może jednak wykonywać podobną operację w ramach automatyzacji sesji użytkownika, testów logowania lub pracy z aplikacją webową. Dla silnika detekcji wzorzec pozostaje niemal taki sam, mimo że intencja może być inna.

Zaobserwowano również scenariusze, w których agent zamykał aktywną przeglądarkę, a następnie uruchamiał skrypt odczytujący dane z magazynu poświadczeń. W innych przypadkach wykonywano polecenia służące do enumeracji wpisów w Windows Credential Manager. Jeżeli dodatkowo agent działa bez rygorystycznych ograniczeń akceptacji operacji, jego zdolność do dotykania wrażliwych zasobów rośnie do poziomu bardzo zbliżonego do aktywności przeciwnika.

Drugą istotną grupę zdarzeń stanowiło użycie narzędzi typu living off the land. Gdy jedna metoda pobrania pliku była blokowana, agent potrafił przełączyć się na alternatywne narzędzie systemowe. Przykładem były próby pobierania plików za pomocą certutil lub bitsadmin. Tego typu adaptacyjne zmienianie techniki po niepowodzeniu jest szczególnie kłopotliwe, ponieważ historycznie uznawano je za cechę aktywnego atakującego.

Odnotowano też zachowania związane z utrwalaniem, takie jak zapisywanie skryptów w folderze autostartu przy użyciu PowerShell. Nawet jeśli działanie miało uzasadnienie operacyjne, sam mechanizm odpowiada wzorcowi wykorzystywanemu przez napastników do zapewnienia uruchamiania kodu po restarcie systemu.

Konsekwencje i ryzyko

Najważniejszym skutkiem jest wzrost liczby alertów bezpieczeństwa na stacjach deweloperskich oraz pogorszenie jakości sygnału dla zespołów SOC. Gdy organizacja wdraża agentów AI na większą skalę, analitycy częściej otrzymują zdarzenia, których nie można łatwo uznać ani za incydent, ani za bezpieczne odstępstwo.

Prowadzi to do zmęczenia alertami, wydłużenia czasu analizy i zwiększenia kosztów obsługi. Jednocześnie rośnie ryzyko, że rzeczywiste nadużycie zostanie ukryte wśród bardzo podobnych wzorców generowanych przez legalne narzędzia.

Drugim zagrożeniem jest nadmierne zaufanie do procesu działającego w kontekście legalnego użytkownika. Jeżeli agent AI ma dostęp do przeglądarki, plików roboczych, tokenów sesyjnych lub poświadczeń systemowych, jego kompromitacja albo manipulacja wejściem może pozwolić na wykonanie niebezpiecznych działań trudnych do wykrycia tradycyjnymi metodami.

Szczególnie istotne są tu scenariusze prompt injection, skażonych repozytoriów, złośliwych konfiguracji oraz poleceń pochodzących z niezweryfikowanego źródła. W takich przypadkach agent może stać się pośrednikiem ataku, mimo że sam nie jest narzędziem zaprojektowanym do działań ofensywnych.

Rekomendacje

Organizacje powinny wdrożyć oddzielne polityki bezpieczeństwa dla agentów AI używanych przez deweloperów. Obejmuje to profilowanie procesów nadrzędnych i potomnych związanych z konkretnym narzędziem, ograniczanie dostępu do magazynów poświadczeń oraz ścisłe monitorowanie operacji wykonywanych poza katalogami roboczymi projektu.

Utrzymać wysoki poziom kontroli nad operacjami dotyczącymi poświadczeń, danych przeglądarki i sekretów.
Dostroić reguły dla nietypowego pobierania plików oraz uruchamiania kodu z uwzględnieniem kontekstu aplikacyjnego.
Blokować tryby działania ograniczające mechanizmy zgód i potwierdzeń użytkownika.
Uruchamiać agentów w środowiskach odseparowanych i zgodnych z zasadą least privilege.
Stosować rotację tokenów, segregację sekretów oraz jawne polityki dostępu do przeglądarek i narzędzi administracyjnych.

Po stronie SOC kluczowe staje się wzbogacanie detekcji o telemetrię kontekstową. Znaczenie mają nie tylko sama akcja i użyte polecenie, ale również proces nadrzędny, linia komend, źródło artefaktu, reputacja pobieranego pliku, lokalizacja docelowa oraz historia podobnych działań wykonywanych przez danego użytkownika lub agenta.

Podsumowanie

Agenci AI do programowania stają się nowym elementem krajobrazu zagrożeń endpoint security. Nie są z definicji złośliwi, ale wykonują operacje, które przez lata stanowiły podstawę skutecznej detekcji intruzów.

W efekcie organizacje muszą odejść od modelu opartego wyłącznie na pojedynczych zachowaniach i przejść do analizy kontekstowej, uwzględniającej tożsamość procesu, uprawnienia, źródło poleceń oraz zakres dostępu do sekretów. To właśnie poświadczenia i mechanizmy uruchamiania kodu w zaufanym kontekście użytkownika powinny stać się głównym punktem nowych polityk bezpieczeństwa dla agentów AI.

Źródła

AI Coding Agents Found Triggering Endpoint Security Rules Built to Catch Attackers

Armored Likho rozwija kampanię APT z użyciem malware wspieranego przez AI

Wprowadzenie do problemu / definicja

Armored Likho to nowo opisana grupa APT prowadząca ukierunkowane kampanie przeciwko instytucjom rządowym oraz organizacjom z sektora elektroenergetycznego. Najnowsze analizy wskazują, że operatorzy wykorzystują złośliwe komponenty, których cechy mogą sugerować wsparcie modeli językowych przy tworzeniu pierwszych etapów infekcji.

Z perspektywy obrony to ważny sygnał ostrzegawczy. Automatyzacja przygotowania loaderów i elementów inicjalnych może przyspieszać modyfikowanie kodu, utrudniać detekcję opartą na sygnaturach i zwiększać tempo rozwoju kolejnych wariantów ataku.

W skrócie

Kampania przypisywana Armored Likho opiera się głównie na spear-phishingu z wykorzystaniem załączników EXE oraz LNK. Po uruchomieniu przynęty ofiara otrzymuje pozornie wiarygodny dokument, podczas gdy w tle aktywowany jest loader odpowiedzialny za pobranie następnych komponentów z infrastruktury atakującego.

Głównym ładunkiem pozostaje BusySnake Stealer, wielofunkcyjny infostealer napisany w Pythonie. Malware kradnie hasła, cookies, dane z Telegrama, kody i sekrety uwierzytelniające, pliki portfeli kryptowalut oraz potrafi zestawiać tunel reverse SSH, zapewniając operatorom głębszy dostęp do przejętego systemu.

wektor wejścia: spear-phishing z archiwami zawierającymi EXE lub LNK,
główny malware: BusySnake Stealer,
cel: kradzież poświadczeń, dokumentów i aktywnych sesji,
dodatkowe możliwości: trwałość, eksfiltracja danych i reverse SSH tunneling.

Kontekst / historia

Armored Likho, znane również jako Eagle Werewolf, łączy cechy kampanii cyberprzestępczych nastawionych na zysk z działaniami o charakterze szpiegowskim. Taki model operacyjny wyróżnia grupę na tle klasycznych aktorów APT, ponieważ obejmuje zarówno cele indywidualne, jak i organizacje posiadające wysoką wartość wywiadowczą.

W analizowanych incydentach ofiary znajdowały się między innymi w Rosji, Kazachstanie i Brazylii. Szczególne zainteresowanie budziły podmioty administracji publicznej oraz sektor energetyczny. Badacze powiązali BusySnake Stealer z wcześniejszymi aktywnościami grupy, w tym z użyciem AquilaRAT oraz narzędzi tunelujących, co sugeruje stopniową ewolucję arsenału zamiast jednorazowej operacji.

Analiza techniczna

Łańcuch ataku rozpoczyna się od wiadomości spear-phishingowej. Przynęty nawiązują do tematów urzędowych, pomocy humanitarnej, wniosków formalnych lub dokumentów psychologicznych. Załączniki są dostarczane jako archiwa zawierające pliki wykonywalne albo skróty LNK.

W wariancie z plikiem EXE uruchamiany jest samorozpakowujący pakiet, który wyświetla ofierze dokument-wabik, a równolegle ładuje złośliwy komponent do legalnego procesu działającego w pamięci. Następnie pobierane są kolejne archiwa i pliki robocze, zwykle zapisywane w katalogach profilu użytkownika.

W scenariuszu z plikiem LNK operatorzy ukrywają parametry wykonania w polu polecenia skrótu. Użytkownik widzi niegroźny dokument, natomiast w tle uruchamiany jest PowerShell odpowiedzialny za pobranie loadera. W kolejnych etapach malware dociąga interpreter Python 3.12, narzędzia instalacyjne oraz właściwy ładunek BusySnake Stealer.

Największą uwagę badaczy zwrócił loader pierwszego etapu. W próbkach zauważono nietypową stylistykę kodu, rozbudowane komentarze i cechy charakterystyczne dla fragmentów przygotowanych automatycznie, co sugeruje możliwe wykorzystanie narzędzi AI do tworzenia części złośliwego oprogramowania.

BusySnake Stealer jest chroniony przy użyciu mechanizmów obfuskacji, w tym PyArmor Pro. Kod odszyfrowuje się dopiero podczas wykonania określonych funkcji, a następnie ponownie ulega zaszyfrowaniu. Taki model znacząco utrudnia analizę statyczną i ogranicza widoczność logiki malware w pamięci procesu.

Funkcjonalnie BusySnake Stealer realizuje szeroki zestaw działań:

monitoruje schowek i zapisuje nowe treści wraz ze znacznikami czasu,
buduje lokalną bazę SQLite z metadanymi plików,
wyszukuje ciągi przypominające klucze lub sekrety API,
automatycznie eksfiltruje wybrane dokumenty z katalogów użytkownika,
kradnie hasła z przeglądarek Chromium z użyciem DPAPI,
odszyfrowuje dane Firefoksa z wykorzystaniem biblioteki NSS i plików profilu,
przechwytuje cookies oraz aktywne sesje przeglądarkowe,
pozyskuje dane Telegram Desktop, w tym pliki sesyjne,
zbiera informacje o portfelach kryptowalut i sekretach OTP,
może wdrażać dodatkowe moduły wspierające przejęcie sesji i dalszą eksfiltrację.

Mechanizm trwałości opiera się na skryptach VBScript i zadaniach harmonogramu. W nowszych wariantach operatorzy porzucili bezpośrednie wywołania schtasks na rzecz interakcji z usługą harmonogramu przez interfejs COM, co ma znaczenie z punktu widzenia detekcji behawioralnej.

Istotnym elementem kampanii jest również reverse SSH tunneling. BusySnake Stealer może pobierać z serwera C2 parametry tunelu, klucz prywatny i polecenie inicjalizujące połączenie, a następnie ustanawiać trwały kanał zwrotny do zainfekowanego hosta. To daje operatorom bardziej interaktywny dostęp po skutecznej kompromitacji.

Konsekwencje / ryzyko

Ryzyko związane z kampanią Armored Likho jest wysokie, zwłaszcza dla administracji publicznej oraz organizacji z obszaru infrastruktury krytycznej. BusySnake Stealer nie ogranicza się do kradzieży pojedynczych haseł, lecz działa jako rozbudowana platforma do zbierania danych, utrzymywania dostępu i rozszerzania zasięgu operacji.

utrata poświadczeń do przeglądarek, usług internetowych i narzędzi administracyjnych,
przejęcie aktywnych sesji dzięki kradzieży cookies,
wyciek dokumentów roboczych i danych operacyjnych,
naruszenie poufności komunikacji prowadzonej przez Telegram,
utrzymanie zdalnego dostępu przez tunel reverse SSH,
utrudniona detekcja z powodu obfuskacji, etapowania oraz zmian w TTP.

Dodatkowym problemem jest prawdopodobne użycie AI do generowania wczesnych komponentów ataku. Taki model może obniżać koszt przygotowania nowych próbek i zwiększać ich różnorodność, co osłabia skuteczność klasycznych mechanizmów wykrywania opartych na podobieństwie kodu.

Rekomendacje

Organizacje powinny traktować tę kampanię jako połączenie phishingu, kradzieży poświadczeń oraz trwałego zdalnego dostępu. W praktyce warto wdrożyć wielowarstwowe środki ochrony obejmujące pocztę, endpointy, przeglądarki i monitorowanie ruchu wychodzącego.

wzmocnić ochronę poczty elektronicznej i sandboxing załączników, szczególnie archiwów z EXE i LNK,
ograniczyć uruchamianie PowerShell, VBScript oraz interpretera Python na stacjach roboczych, jeśli nie są niezbędne,
monitorować tworzenie zadań harmonogramu również przez interfejsy COM,
wykrywać procesy uruchamiane z katalogów AppData i innych nietypowych ścieżek użytkownika,
inspekować dostęp do baz przeglądarek, artefaktów Firefoksa i plików Telegram Desktop,
analizować długotrwałe połączenia wychodzące, które mogą wskazywać na reverse SSH tunneling,
wymuszać MFA odporne na phishing tam, gdzie to możliwe,
prowadzić threat hunting pod kątem nietypowych rozszerzeń przeglądarek i lokalnych usług HTTP,
aktualizować reguły EDR i SIEM o detekcje związane z LNK abuse, PowerShellem i podejrzanymi łańcuchami uruchomień,
rozszerzyć szkolenia użytkowników o rozpoznawanie przynęt związanych z dokumentami urzędowymi i socjotechniką dopasowaną do roli ofiary.

Podsumowanie

Armored Likho pokazuje, że współczesne kampanie APT coraz częściej łączą klasyczny spear-phishing z modularnym malware, zaawansowaną obfuskacją i elastycznym podejściem do utrzymywania dostępu. BusySnake Stealer stanowi rozbudowane narzędzie do kradzieży poświadczeń, danych użytkownika i aktywnych sesji, a możliwość zestawiania tunelu reverse SSH znacząco zwiększa potencjał działań po kompromitacji.

Najważniejszym wnioskiem pozostaje jednak możliwa rola AI w przygotowywaniu początkowych elementów ataku. Jeśli ten trend się utrzyma, zespoły bezpieczeństwa będą musiały jeszcze silniej opierać detekcję na analizie zachowań, korelacji telemetrii i pełnym kontekście łańcucha ataku, a nie wyłącznie na statycznych wskaźnikach kompromitacji.

Źródła

Security Affairs — https://securityaffairs.com/194854/apt/ai-generated-malware-powers-new-armored-likho-apt-campaign.html
Securelist — Armored Likho digging a snake pit: inside the covert BusySnake Stealer campaign — https://securelist.com/tr/armored-likho-apt-with-busysnake-stealer/120292/

Veil#Drop wykorzystuje Blogspot do dostarczania malware i wdrażania PureLog Stealer

Wprowadzenie do problemu / definicja

Veil#Drop to wieloetapowy framework dostarczania złośliwego oprogramowania, zaprojektowany do infekowania stacji roboczych z użyciem socjotechniki, skryptów JavaScript, PowerShell oraz technik fileless. Wyróżnikiem kampanii jest wykorzystanie zaufanej infrastruktury chmurowej do hostowania kolejnych etapów ataku, co utrudnia wykrycie i zwiększa skuteczność omijania tradycyjnych mechanizmów ochronnych.

W skrócie

Łańcuch infekcji rozpoczyna się od pliku JavaScript podszywającego się pod dokument. Po jego uruchomieniu skrypt wywołuje PowerShell, który pobiera kolejne komponenty z zasobów hostowanych na Blogspot. Następne etapy obejmują wyświetlenie dokumentu-wabika, dekodowanie ukrytych danych, uruchamianie kodu bezpośrednio w pamięci oraz nadużycie legalnych narzędzi systemowych.

Finalnym payloadem jest PureLog Stealer, czyli infostealer kradnący dane z przeglądarek, portfeli kryptowalut, komunikatorów, klientów poczty, narzędzi zdalnego dostępu, aplikacji chmurowych i menedżerów haseł.

Kontekst / historia

Współczesne kampanie infostealerów coraz częściej odchodzą od prostych, jednoplikowych infekcji. Zamiast pojedynczego pliku wykonywalnego operatorzy budują modułowe łańcuchy, w których każdy etap pełni odrębną funkcję: inicjalne uruchomienie, pobranie kolejnych komponentów, ukrycie aktywności, utrudnienie analizy i wdrożenie właściwego malware.

Veil#Drop wpisuje się w ten trend. Kampania łączy kompromitowane lub kontrolowane zasoby internetowe z technikami living-off-the-land oraz pamięciowym uruchamianiem komponentów .NET. Takie podejście ogranicza liczbę artefaktów pozostawianych na dysku i zmniejsza skuteczność zabezpieczeń opartych wyłącznie na sygnaturach lub reputacji domen.

Analiza techniczna

Pierwszy etap ataku wykorzystuje plik JavaScript udający dokument, którego celem jest skłonienie użytkownika do wykonania kodu. Skrypt uruchamia PowerShell w sposób pomagający ominąć polityki wykonania i rozpocząć pobieranie dalszych elementów łańcucha infekcji.

Następnie PowerShell pobiera payloady z zasobów hostowanych na Blogspot. Wykorzystanie popularnej i powszechnie uznawanej usługi utrudnia filtrowanie ruchu wyłącznie na podstawie reputacji domeny, szczególnie w środowiskach dopuszczających szeroki dostęp do usług chmurowych bez głębokiej inspekcji treści.

Pobrany komponent wyświetla dokument-wabik, aby obniżyć czujność użytkownika i stworzyć wrażenie normalnego działania pliku. Równolegle malware wykonuje czynności przygotowawcze, takie jak kończenie wybranych procesów, dekodowanie osadzonych danych oraz generowanie kolejnych adresów używanych w dalszych etapach ataku.

Istotną częścią kampanii są zakodowane ładunki .NET przechowywane jako duże bloby danych. Komponenty te są rekonstruowane i odszyfrowywane dopiero podczas działania próbki, co znacząco utrudnia analizę statyczną. Dodatkowo moduły są ładowane refleksyjnie i wykonywane bezpośrednio w pamięci, co ogranicza ślady na dysku.

Badacze zwracają także uwagę na wykorzystanie podpisanych binariów systemowych, czyli klasyczny LOLBIN abuse. Tego typu technika pozwala uruchamiać złośliwy kod przy użyciu legalnych narzędzi obecnych w systemie operacyjnym, przez co odróżnienie aktywności napastnika od działań administracyjnych staje się trudniejsze.

Ostatecznie na urządzeniu ofiary uruchamiany jest PureLog Stealer. Malware prowadzi rekonesans systemu, a następnie wykrada poświadczenia, cookies, dane autouzupełniania, tokeny sesyjne i historię przeglądania. Celem są między innymi przeglądarki Chrome, Edge, Firefox, Brave, Opera i inne rozwiązania bazujące na Chromium. Zagrożenie zbiera też informacje z portfeli kryptowalut, komunikatorów, klientów pocztowych, aplikacji chmurowych, klientów FTP, narzędzi deweloperskich, oprogramowania do zdalnego dostępu i menedżerów haseł, po czym pakuje dane i przesyła je do infrastruktury kontrolowanej przez operatorów kampanii.

Konsekwencje / ryzyko

Ryzyko związane z Veil#Drop wykracza poza pojedynczą infekcję endpointu. Infostealer taki jak PureLog może zapewnić atakującym dostęp do haseł, tokenów sesyjnych, danych dostępowych do usług SaaS, konfiguracji narzędzi administracyjnych oraz sekretów zapisanych w przeglądarkach.

W środowisku firmowym oznacza to możliwość szybkiego rozszerzenia incydentu. Przejęte dane mogą zostać użyte do ataków na pocztę, VPN, panele administracyjne, środowiska chmurowe czy systemy deweloperskie. W praktyce infostealery bardzo często stanowią etap początkowy przed szerszym naruszeniem, obejmującym kradzież danych, oszustwa BEC, wdrożenie ransomware lub długotrwałą obecność w infrastrukturze ofiary.

Szczególnie groźne jest połączenie kilku elementów: użycia zaufanej infrastruktury do hostowania payloadów, uruchamiania kodu w pamięci, ograniczonej liczby artefaktów na dysku oraz nadużywania legalnych narzędzi systemowych. Taka kombinacja może obniżać skuteczność tradycyjnych metod detekcji.

Rekomendacje

Organizacje powinny wdrożyć wielowarstwowe podejście do ochrony przed podobnymi kampaniami. Priorytetem jest ograniczenie możliwości uruchamiania skryptów JavaScript pobranych z poczty lub internetu oraz zaostrzenie polityk dotyczących interpretera skryptowego i PowerShell.

Monitorować nietypowe łańcuchy procesów, zwłaszcza uruchomienie PowerShell z poziomu skryptów lub aplikacji użytkownika.
Włączyć szczegółowe logowanie aktywności PowerShell i centralną analizę zdarzeń telemetrycznych.
Wykrywać nadużycia LOLBIN oraz anomalie w użyciu podpisanych binariów systemowych.
Analizować procesy uzyskujące dostęp do magazynów haseł przeglądarek, plików cookies i tokenów sesyjnych.
Monitorować połączenia do usług chmurowych inicjowane przez procesy, które standardowo nie pobierają treści wykonywalnej.
Po wykryciu infekcji szybko rotować poświadczenia i unieważniać aktywne sesje użytkowników.

Dla użytkowników końcowych kluczowe pozostaje zachowanie ostrożności wobec plików udających dokumenty, zwłaszcza tych z nietypowymi rozszerzeniami lub podejrzanym zachowaniem po uruchomieniu. Samo wyświetlenie poprawnego dokumentu nie oznacza, że w tle nie został uruchomiony malware.

Podsumowanie

Veil#Drop pokazuje, że nowoczesne kampanie malware skutecznie łączą socjotechnikę, zaufaną infrastrukturę chmurową, techniki fileless i nadużycie legalnych narzędzi systemowych. Taka architektura zwiększa skuteczność dostarczenia payloadu i jednocześnie utrudnia zarówno detekcję, jak i analizę incydentu.

Dla organizacji najważniejszy wniosek jest jednoznaczny: infekcji infostealerem nie wolno traktować jako incydentu niskiej wagi. Kradzież danych z pojedynczej stacji roboczej może szybko doprowadzić do kompromitacji kont, sesji i systemów w całym środowisku.

Źródła

SecurityWeek — Blogspot-Hosted Payloads Delivered in ‘Veil#Drop’ Attacks — https://www.securityweek.com/blogspot-hosted-payloads-delivered-in-veildrop-attacks/
Securonix Threat Research — Veil#Drop — https://www.securonix.com/

Veil#Drop i PureLog Stealer: Blogspot oraz techniki fileless w nowym łańcuchu infekcji

Wprowadzenie do problemu / definicja

Veil#Drop to zaawansowany framework dostarczania złośliwego oprogramowania, zaprojektowany z myślą o omijaniu klasycznych mechanizmów ochronnych i skutecznym uruchamianiu stealerów informacji na urządzeniach ofiar. Kampania zwraca uwagę połączeniem zaufanej infrastruktury internetowej, skryptów JavaScript, PowerShella, technik fileless oraz uruchamiania komponentów bez pozostawiania wielu artefaktów na dysku.

W analizowanych przypadkach końcowym ładunkiem był PureLog Stealer, malware wyspecjalizowany w kradzieży danych uwierzytelniających, cookies, tokenów sesyjnych, danych przeglądarek oraz informacji mogących prowadzić do dalszej kompromitacji środowiska.

W skrócie

Badacze opisują Veil#Drop jako wieloetapowy łańcuch infekcji, który zaczyna się od pliku JavaScript podszywającego się pod dokument. Po uruchomieniu skrypt inicjuje PowerShell, pobiera kolejne komponenty z infrastruktury opartej o Blogspot, odszyfrowuje je w pamięci i uruchamia następne etapy ataku.

Początek infekcji następuje przez plik JavaScript udający dokument.
PowerShell odpowiada za pobranie dalszych payloadów.
Wykorzystana została zaufana infrastruktura, w tym Blogspot.
Ładunki są rekonstruowane i uruchamiane częściowo w pamięci.
Finalnym malware jest PureLog Stealer.

Kontekst / historia

Popularność infostealerów rośnie, ponieważ skradzione hasła, tokeny, sesje i pliki konfiguracyjne mają dużą wartość operacyjną dla cyberprzestępców. Tego typu dane są często wykorzystywane nie tylko do kradzieży informacji, ale także jako punkt wejścia do bardziej zaawansowanych operacji, w tym przejęć kont, oszustw biznesowych czy wdrożeń ransomware.

Veil#Drop dobrze wpisuje się w ten trend, ale pokazuje również zmianę w sposobie dystrybucji malware. Zamiast polegać wyłącznie na oczywiście podejrzanych domenach lub prostych dropperach, operatorzy kampanii wykorzystują legalnie wyglądającą infrastrukturę, kompromitowane witryny i techniki ukrywania aktywności, co znacząco utrudnia szybkie odróżnienie ruchu złośliwego od legalnego.

Analiza techniczna

Łańcuch infekcji rozpoczyna się od pliku JavaScript nazwanego w sposób sugerujący dokument. Taki zabieg socjotechniczny ma skłonić użytkownika do uruchomienia próbki, mimo że w rzeczywistości nie jest to plik biurowy. Po wykonaniu skrypt uruchamia PowerShell i podejmuje próbę obejścia ograniczeń związanych z politykami uruchamiania.

Następnie malware pobiera kolejne komponenty z zasobów hostowanych w serwisie Blogspot. Wykorzystanie rozpoznawalnej i zwykle zaufanej infrastruktury może obniżyć skuteczność prostych filtrów reputacyjnych oraz części mechanizmów blokowania ruchu sieciowego.

W dalszych etapach stosowane są dokumenty-wabiki, które mają uwiarygodnić działanie pliku i ograniczyć podejrzenia użytkownika. Równolegle uruchamiane są elementy przygotowujące środowisko do wykonania kolejnych loaderów oraz końcowego ładunku.

Jednym z ważnych elementów technicznych jest użycie osadzonych komponentów .NET zakodowanych metodą XOR. Zamiast przechowywać je w jawnej postaci na dysku, malware rekonstruuje i odszyfrowuje je dopiero podczas działania. Taki model utrudnia analizę statyczną i ogranicza skuteczność detekcji opartej wyłącznie na sygnaturach.

Veil#Drop wykorzystuje także podejście fileless oraz nadużywa legalnych binariów systemowych typu LOLBIN. Dzięki temu część złośliwych działań wykonywana jest przez narzędzia już obecne w systemie, co może utrudnić wykrycie incydentu przez zespoły SOC i rozwiązania ochronne skupione na prostych wskaźnikach kompromitacji.

Finalnym etapem jest uruchomienie PureLog Stealer, napisanego w .NET malware wyspecjalizowanego w kradzieży danych z przeglądarek i innych aplikacji. Zakres przechwytywanych informacji obejmuje:

nazwy użytkowników i hasła zapisane w przeglądarkach,
cookies i tokeny sesyjne,
dane autouzupełniania,
historię przeglądania,
informacje z portfeli kryptowalut,
dane z komunikatorów, klientów pocztowych, narzędzi FTP i menedżerów haseł,
sekrety przechowywane lokalnie przez wybrane aplikacje i narzędzia.

Zebrane dane są następnie pakowane i przesyłane do infrastruktury kontrolowanej przez operatorów kampanii.

Konsekwencje / ryzyko

Ryzyko związane z Veil#Drop nie kończy się na pojedynczej infekcji stacji roboczej. W środowisku firmowym przejęcie jednego hosta może oznaczać kompromitację kont użytkowników, aktywnych sesji przeglądarkowych, sekretów deweloperskich oraz dostępu do usług chmurowych i SaaS.

Szczególnie niebezpieczne są tokeny sesyjne i zapisane poświadczenia, ponieważ mogą umożliwić napastnikom obejście części zabezpieczeń opartych na MFA. Z perspektywy reagowania na incydenty problemem jest także wysoki poziom ukrycia aktywności: JavaScript, PowerShell, ładowanie pamięciowe, XOR, dokumenty-wabiki i LOLBIN-y tworzą łącznie sekwencję zdarzeń, która może wyglądać niepozornie do momentu eksfiltracji danych.

W praktyce infekcja infostealerem często bywa jedynie etapem przygotowawczym do kolejnych operacji. Skradzione dane mogą posłużyć do przejęcia poczty, ruchu lateralnego, ataków BEC, sabotażu, wycieku danych lub wdrożenia ransomware.

Rekomendacje

Organizacje powinny ograniczać możliwość uruchamiania skryptów JavaScript i PowerShella z nieautoryzowanych lokalizacji oraz wdrażać polityki kontroli aplikacji, w tym ograniczenia dla najczęściej nadużywanych LOLBIN-ów. Istotne jest też monitorowanie procesów potomnych uruchamianych przez interpretery skryptowe i łączenie tych zdarzeń z telemetrią sieciową.

Skuteczna obrona przed podobnymi kampaniami powinna obejmować detekcję behawioralną dla sekwencji takich jak uruchomienie skryptu, start PowerShella, pobranie treści z zewnętrznej infrastruktury, rekonstrukcja ładunku w pamięci oraz dostęp do baz danych przeglądarek i magazynów poświadczeń.

Egzekwować MFA odporne na przejęcie sesji tam, gdzie jest to możliwe.
Minimalizować lokalne przechowywanie sekretów i danych dostępowych.
Segmentować dostęp do systemów administracyjnych i usług krytycznych.
Monitorować nietypowe logowania z nowych urządzeń lub lokalizacji.
Szkolić użytkowników w zakresie plików udających dokumenty i kampanii socjotechnicznych.
Wzmacniać EDR/XDR o detekcję odczytu cookies, tokenów i danych przeglądarek.

W przypadku podejrzenia infekcji należy założyć możliwość kradzieży poświadczeń i aktywnych sesji. Reakcja powinna obejmować izolację hosta, reset haseł, unieważnienie sesji, rotację kluczy i sekretów oraz przegląd logów dostępowych do usług chmurowych.

Podsumowanie

Veil#Drop pokazuje, jak skuteczne stają się nowoczesne kampanie malware łączące socjotechnikę, legalnie wyglądającą infrastrukturę, techniki fileless i nadużycie natywnych narzędzi systemowych. To model ataku, który nie opiera się na jednym łatwym do wykrycia artefakcie, ale na wieloetapowym łańcuchu subtelnych działań.

Dla organizacji najważniejszy wniosek jest prosty: infostealery należy traktować jako zagrożenie strategiczne. Nawet pojedyncza kompromitacja stacji roboczej może stać się początkiem znacznie szerszego naruszenia bezpieczeństwa.

Źródła

SecurityWeek — Blogspot-Hosted Payloads Delivered in ‘Veil#Drop’ Attacks — https://www.securityweek.com/blogspot-hosted-payloads-delivered-in-veildrop-attacks/
Securonix Threat Research — Veil#Drop — https://www.securonix.com/blog/veildrop/