Wprowadzenie do problemu / definicja
W pierwszej połowie 2026 roku analitycy bezpieczeństwa zwrócili uwagę na dwa łańcuchy ataków, które nie polegały wyłącznie na klasycznym phishingu ani na prostym złośliwym oprogramowaniu. W obu przypadkach napastnicy wykorzystali zaufane elementy środowiska ofiary: autentyczne, wcześniej przejęte skrzynki pocztowe oraz lokalne mechanizmy systemowe i przeglądarkowe, a także schowek systemowy używany podczas płatności kryptowalutowych.
To podejście jest szczególnie groźne, ponieważ użytkownik często widzi poprawny, znajomy proces. Wiadomość może pochodzić z prawdziwego konta firmowego, a transakcja blockchain może być technicznie prawidłowa. Problem pojawia się dopiero na etapie wykonania, gdy kluczowe dane lub sesje zostały już przejęte albo zmanipulowane.
W skrócie
- Pierwszy scenariusz dotyczył malware bankowego dostarczanego przez wiadomości wysyłane z przejętych kont e-mail.
- Łańcuch infekcji obejmował załącznik uruchamiający JavaScript, kolejne etapy w PowerShell oraz finalną manipulację przeglądarką i ustawieniami proxy.
- Drugi scenariusz wykorzystywał clippera napisanego w Rust, który podmieniał adresy portfeli kryptowalut kopiowane do schowka.
- Wspólnym celem obu kampanii było obejście tradycyjnego modelu zaufania bez konieczności łamania podstawowych mechanizmów bezpieczeństwa.
Kontekst / historia
Kampania związana z trojanem bankowym była wymierzona między innymi w użytkowników z Europy Środkowo-Wschodniej, w tym z Polski. Przynęty przybierały formę typowych wiadomości biznesowych dotyczących przesyłek, dokumentów lub faktur. Kluczowe było jednak to, że e-maile pochodziły z autentycznych, wcześniej skompromitowanych kont firmowych, co znacząco zwiększało ich wiarygodność.
Drugi łańcuch ataku koncentrował się na użytkownikach realizujących płatności kryptowalutowe. Zamiast atakować sam portfel lub sieć blockchain, operatorzy malware uderzali w etap kopiowania i wklejania adresu odbiorcy. To skuteczna technika, ponieważ długie ciągi znaków są trudne do ręcznej weryfikacji i często sprawdzane jedynie pobieżnie.
Analiza techniczna
W pierwszym scenariuszu infekcja zaczynała się od załącznika uruchamiającego JavaScript dropper. Następnie aktywowane były kolejne komponenty oparte na PowerShell, które prowadziły do załadowania shellcode oraz końcowej funkcjonalności wiązanej z rodziną GepyS. Ostatni etap obejmował modyfikację ustawień proxy oraz instalację dodatku do przeglądarki, co pozwalało atakującym działać bardzo blisko sesji bankowej ofiary.
Istotnym elementem była także ochrona malware przed szybką analizą. Jeden z loaderów wykorzystywał 32-bitowy kod pozycyjnie niezależny, instrukcje śmieciowe MMX i SSE, skoki do środka instrukcji oraz rutynę deszyfrującą opartą na LFSR i operacji XOR. Taki zestaw technik nie jest całkowicie nowy, ale skutecznie zwiększa koszt analizy statycznej i utrudnia klasyfikację próbki.
Drugi scenariusz opierał się na clipperze skompilowanym w Rust. Malware monitorowało zawartość schowka i wykrywało wzorce adresów portfeli dla różnych blockchainów, w tym BTC, ETH i LTC. Po rozpoznaniu wspieranego formatu podmieniało adres na taki, który był kontrolowany przez napastnika. Z perspektywy użytkownika proces wyglądał normalnie: kopiowanie adresu, wklejenie do portfela lub giełdy i zatwierdzenie transakcji.
Na uwagę zasługuje również model komunikacji z infrastrukturą C2. Malware wykorzystywało Binance Smart Chain jako element mechanizmu odnajdywania wskaźników infrastruktury, w podejściu przypominającym EtherHiding. Zamiast przechowywać całe zaplecze operacyjne bezpośrednio on-chain, odczytywało ze smart kontraktu dane prowadzące do dalszej infrastruktury, takiej jak domena, adres URL lub IP. To utrudnia klasyczne blokowanie oparte na statycznych wskaźnikach kompromitacji.
Konsekwencje / ryzyko
Największe zagrożenie w pierwszej kampanii wynika z pozornego bezpieczeństwa wiadomości. Jeśli e-mail pochodzi z legalnej skrzynki i przechodzi kontrole nadawcy, użytkownik oraz część systemów ochronnych mogą przypisać mu zbyt wysoki poziom zaufania. To otwiera drogę do uruchomienia załącznika, wykonania kodu i przejęcia lub manipulacji sesją bankową.
W środowisku organizacyjnym skutki mogą obejmować oszustwa płatnicze, przejęcie procesów finansowych, kradzież danych uwierzytelniających oraz nadużycie zaufanych kanałów komunikacji. Dodatkowo przejęta skrzynka pocztowa sama staje się elementem infrastruktury ataku, co utrudnia wykrywanie kolejnych kampanii i zwiększa ich skuteczność.
W przypadku clippera ryzyko polega na tym, że ofiara sama autoryzuje technicznie poprawną transakcję na błędny adres. Blockchain nie zostaje złamany, a podpis kryptograficzny pozostaje ważny. W praktyce oznacza to, że utrata środków może być natychmiastowa i nieodwracalna, jeśli lokalne środowisko użytkownika zostało wcześniej zmanipulowane.
Rekomendacje
Organizacje nie powinny traktować uwierzytelnienia nadawcy jako ostatecznego dowodu bezpieczeństwa wiadomości. Konieczna jest korelacja sygnałów z poczty, punktów końcowych i przeglądarek, zwłaszcza gdy załączniki inicjują JavaScript, PowerShell, shellcode lub nietypowe zmiany w ustawieniach proxy i rozszerzeniach.
- Ograniczać użycie interpreterów skryptowych na stacjach roboczych, które ich nie wymagają.
- Wdrożyć application control dla załączników pobieranych z poczty.
- Monitorować zmiany ustawień proxy i instalację nowych rozszerzeń przeglądarki.
- Wykrywać oznaki przejęcia skrzynek pocztowych, takie jak nietypowe logowania, reguły przekierowań i anomalie w wysyłce.
- Analizować procesy modyfikujące schowek oraz wzorce odpowiadające adresom portfeli kryptowalut.
- Łączyć analizę artefaktów on-chain z obserwacją infrastruktury C2 i zachowań endpointów.
Użytkownicy wykonujący płatności kryptowalutowe powinni każdorazowo weryfikować pełny adres odbiorcy bezpośrednio przed autoryzacją transakcji. Samo sprawdzenie kilku pierwszych i ostatnich znaków może nie wystarczyć. W środowiskach wysokiego ryzyka warto stosować listy dozwolonych odbiorców, niezależną weryfikację drugim kanałem oraz urządzenia podpisujące, które prezentują cały adres docelowy.
Podsumowanie
Oba opisane łańcuchy ataków pokazują wyraźny trend: przeciwnik nie musi przełamywać głównych mechanizmów zaufania, jeśli może wykorzystać ich legalny wygląd albo zmodyfikować dane tuż przed krytyczną akcją użytkownika. W jednym przypadku atak zaczyna się od prawdziwej firmowej skrzynki e-mail i kończy w pobliżu sesji bankowej. W drugim legalna transakcja blockchain prowadzi do przesłania środków na podstawiony adres.
Dla zespołów bezpieczeństwa oznacza to potrzebę analizy pełnej sekwencji zdarzeń, a nie tylko pojedynczych wskaźników kompromitacji. Skuteczna obrona wymaga zrozumienia całego przebiegu operacji: od dostarczenia wiadomości i uruchomienia skryptów, po manipulację lokalnym środowiskiem użytkownika i jego decyzją końcową.
Źródła
- BleepingComputer — Real emails, hijacked payments: Two H1 2026 attack chains — https://www.bleepingcomputer.com/news/security/real-emails-hijacked-payments-two-h1-2026-attack-chains/
- Gen Digital — H1 2026 Threat Report — https://www.gendigital.com/us/en/research/h1-2026-threat-report