Cybercrime

Twój VS Code Cię zdradza?

Visual Studio Code to przykład narzędzia, które przekształciło się w niemal autonomiczne środowisko deweloperskie, często pozostające poza zasięgiem standardowych mechanizmów detekcyjnych SOC. Bezgraniczna swoboda, jaką VS Code daje programistom, wyprzedziła zdolności organizacji do nadzorowania tego, co dzieje się wewnątrz edytora, otwierając lukę, którą trudno załatać standardowymi narzędziami kontroli. Domyślne szerokie uprawnienia do systemu plików i terminali sprawiają, że środowisko to staje się uprzywilejowanym i trudnym do wykrycia punktem wejścia do infrastruktury, zwłaszcza gdy zespoły SOC koncentrują się na typowych kanałach, takich jak poczta czy przeglądarki. Ryzyko to potęguje paradoks zaufania do oficjalnego Marketplace’u – miliony pobrań nie są równoznaczne z rzetelnym audytem bezpieczeństwa, a popularność wtyczki czyni ją atrakcyjnym celem dla ataków na łańcuch dostaw, zamieniając warsztat pracy inżyniera w nieautoryzowany terminal łączący stację roboczą z infrastrukturą organizacji. 

Podatności w zaufanym ekosystemie 

Zagrożenia zakorzenione w ekosystemie rozszerzeń wynikają przede wszystkim z faktu, że operują one poza tradycyjnym sandboxem, wchodząc w interakcje z hostem na poziomie uprawnień zalogowanego użytkownika. Skala tego ryzyka jest ogromna, gdy spojrzymy na rozszerzenie Live Server, które posiada ponad 72 miliony instalacji. Podatność CVE-2025-65717 w rozszerzeniu Live Server umożliwia złośliwej stronie internetowej odpytywanie uruchomionego lokalnie serwera deweloperskiego. W scenariuszu, w którym użytkownik odwiedzi złośliwy adres URL przy aktywnym Live Server, atakujący może doprowadzić do nieautoryzowanego odczytu i eksfiltracji zasobów udostępnianych przez serwer — w tym kodu źródłowego, plików konfiguracyjnych, zmiennych środowiskowych (.env), kluczy API, a także innych lokalnych artefaktów i logów dostępnych w kontekście projektu. 

Sytuację pogarsza fakt, że proces usuwania tych podatności jest skrajnie nieefektywny. Mimo że badacze raportowali te błędy już w czerwcu 2025 roku, kluczowe problemy pozostają otwarte. Szczególnie alarmujący jest przypadek wtyczki Code Runner (37 mln instalacji) oraz Markdown Preview Enhanced (8,5 mln instalacji). Mimo, iż miliony deweloperów codziennie korzystają z narzędzi podatnych na zdalne wykonanie kodu, ich autorzy całkowicie zignorowali zgłoszenia, co wpisuje się w szerszy trend bierności, obserwowany również w przypadku Live Server. Obecnie publicznie dostępne są kody eksploitów (PoC), które stanowią gotowe schematy ataków. Pokazują one wprost, jak za pomocą zatrutego repozytorium lub manipulacji plikiem settings.json doprowadzić do wykonania kodu w kontekście zalogowanego użytkownika, co w środowiskach z podwyższonymi uprawnieniami może skutkować faktycznym przejęciem stacji roboczej. 

VS Code jako narzędzie Command & Control 

Tak szerokie pole ataku zostaje dopełnione przez funkcjonalność, która w rękach atakującego zmienia VS Code w klasyczny przykład narzędzia klasy LOLBin (Living Off the Land Binary). Mowa o funkcji Remote Tunnels, która pozwala na zestawienie szyfrowanego połączenia C2 przy użyciu podpisanych, zaufanych plików wykonywalnych Microsoftu. Atakujący, po uzyskaniu wstępnego dostępu do maszyny, nie musi instalować jawnie złośliwego oprogramowania – wystarczy, że wykorzysta istniejącą instalację lub uruchomi przenośną wersję edytora za pomocą prostej komendy code tunnel. Taka aktywność z natury umyka standardowym sygnaturom systemów AV i EDR, ponieważ proces jest uznawany za legalny, certyfikowany składnik środowiska programistycznego. 

Kluczowym elementem tej strategii jest mechanizm uwierzytelniania, który pozwala cyberprzestępcy na wykorzystanie własnego, osobistego konta GitHub lub Microsoft Entra ID do uruchomienia tunelu sieciowego. W praktyce oznacza to ominięcie korporacyjnych polityk dostępowych i mechanizmów warunkowego dostępu (Conditional Access), ponieważ uwierzytelnienie odbywa się przy użyciu zewnętrznej tożsamości kontrolowanej przez atakującego. Skuteczność tej metody potwierdzają kampanie grup APT realizowane w ostatnich latach. W 2023 roku grupa Mustang Panda wykorzystała VS Code w operacjach szpiegowskich wymierzonych w instytucje rządowe w Azji Południowo-Wschodniej. Atakujący dostarczali na stacje robocze ofiar pliki ZIP zawierające przenośną wersję code.exe oraz złośliwe biblioteki DLL wykorzystywane do techniki DLL side-loading. Po uruchomieniu tunelu za pomocą własnych tokenów GitHub, atakujący uzyskiwali stały, szyfrowany kanał dostępu. Ruch generowany przez tunel jest szyfrowany i kierowany do zaufanych domen Microsoftu, co znacząco utrudnia jego odróżnienie od rutynowej aktywności deweloperskiej i sprzyja długotrwałemu utrzymaniu obecności w sieci bez wzbudzania oczywistych alertów. 

Jeszcze bardziej precyzyjny schemat działania zidentyfikowano w ramach Operation Digital Eye (przełom czerwca i lipca 2024 r.), kampanii przypisywanej chińskim grupom APT, której celem była kompromitacja krytycznej infrastruktury cyfrowej w Europie Południowej m.in. we Włoszech. Atak wymierzony był w dużych dostawców usług IT typu B2B, którzy zarządzają danymi i infrastrukturą dla klientów z wielu branż. Po wstępnej infekcji serwerów bazodanowych za pomocą narzędzia sqlmap i wdrożeniu backdoorów takich jak ShadowPad, VS Code był użyty jako pomocniczy kanał komunikacji. Wykorzystanie legalnej domeny visualstudio.com umożliwiło atakującym rekonesans, lateral movement oraz omijanie polityk firewalli, czyniąc z IDE narzędzie do infiltracji łańcucha dostaw i pozyskiwania poświadczeń. 

AI i ShadowIT 

Brak centralnego nadzoru nad rozszerzeniami w VS Code jest klasycznym przykładem Shadow IT w środowisku deweloperskim. Ryzyko to rośnie wraz z popularyzacją asystentów AI, takich jak Claude czy Cline, integrowanych bezpośrednio z edytorem. Narzędzia te działają w kontekście uprawnień użytkownika i – w zależności od konfiguracji – mogą sugerować instalację dodatkowych wtyczek, generować komendy powłoki lub uzyskiwać szeroki dostęp do plików projektu. Choć nie instalują komponentów w pełni autonomicznie, półautomatyczne mechanizmy akceptacji oraz rutynowe zatwierdzanie rekomendacji przez użytkowników istotnie obniżają próg bezpieczeństwa operacyjnego. 

W przypadku kompromitacji rozszerzenia, przejęcia tokenów API lub prompt injection, atakujący może uzyskać dostęp do wszystkich zasobów dostępnych w kontekście zalogowanego użytkownika. Nie oznacza to automatycznej eskalacji uprawnień systemowych, jednak przy administracyjnych uprawnieniach lokalnych lub aktywnych tokenach chmurowych skutki mogą być porównywalne z przejęciem uprzywilejowanej stacji roboczej. Dodatkowo możliwość konfiguracji zdalnego tunelu jako trwałej usługi systemowej stwarza stały kanał komunikacji endpoint-to-cloud, który trudno wykryć, a który może posłużyć do lateral movement, pozyskiwania poświadczeń i pivotu do zasobów chmurowych oraz systemów CI/CD organizacji 

Od zaufania do aktywnego nadzoru 

Zapewnienie bezpieczeństwa nowoczesnego środowiska programistycznego wymaga proaktywnych działań – przejście od modelu domyślnego zaufania do monitorowania procesów wewnątrz IDE. Dla zespołów bezpieczeństwa rekomendujemy kompleksowe podejście obejmujące zarówno kontrolę nad funkcją tunelowania, jak i monitoring środowiska deweloperskiego. W środowiskach, które nie wymagają użycia Dev Tunnels, warto całkowicie wyłączyć tę funkcjonalność, a tam, gdzie jest konieczna, ograniczyć możliwość logowania wyłącznie do autoryzowanych instancji (tenantów), jednocześnie monitorując próby uruchomienia nieautoryzowanych tuneli. Zalecane jest filtrowanie połączeń wychodzących z procesów VS Code, takich jak code.exe i devtunnel.exe, oraz alertowanie w systemach SIEM i EDR w przypadku zestawienia tunelu do nieznanych domen lub adresów IP. Warto rozważyć monitorowanie nietypowych zmian w plikach konfiguracyjnych IDE, takich jak settings.json, oraz w katalogach rozszerzeń, a także flagowanie uruchamiania procesów z nietypowymi argumentami, np. –accept-server-license-terms. Dodatkowo, warto wdrożyć centralną politykę dopuszczającą instalację jedynie zweryfikowanych wtyczek. 

Więcej informacji: 
https://www.ox.security/blog/cve-2025-65717-live-server-vscode-vulnerability/ 
https://www.ox.security/blog/cve-2025-65716-markdown-preview-enhanced-vscode-vulnerability/ 
https://www.ox.security/blog/cve-2025-65715-code-runner-vscode-rce/ 
https://newtonpaul.com/blog/vscode-remote-tunnels-abuse-and-detections/ 
https://unit42.paloaltonetworks.com/stately-taurus-abuses-vscode-southeast-asian-espionage/
https://www.sentinelone.com/labs/operation-digital-eye-chinese-apt-compromises-critical-digital-infrastructure-via-visual-studio-code-tunnels/ 

Podatności

Menadżery haseł nie są „magicznie bezpieczne” 

Współczesne menadżery haseł od lat są przedstawiane jako fundament higieny cyberbezpieczeństwa – narzędzia, które rozwiązują problem słabych, powtarzalnych haseł i umożliwiają stosowanie unikalnych, silnych danych uwierzytelniających w każdej usłudze. Jednak najnowsze badania naukowe oraz rzeczywiste incydenty bezpieczeństwa pokazują, że krajobraz zagrożeń związany z ich używaniem jest znacznie bardziej złożony, niż sugerowałaby to marketingowa narracja o pełnej poufności. 

Punktem wyjścia do tej refleksji są badania opublikowane przez naukowców z ETH Zurich, opisane w artykule „Password managers less secure than promised” z 2026 roku. „Zero Knowledge Encryption” to termin powszechnie używany przez dostawców chmurowych menedżerów haseł. Choć nie ma on ścisłego znaczenia technicznego, pojęcie to ma sugerować, że serwer – który przechowuje zaszyfrowane bazy danych haseł użytkowników – nie jest w stanie uzyskać żadnych informacji o ich zawartości. Deklaracje bezpieczeństwa składane przez dostawców implikują, że założenie to powinno pozostawać prawdziwe nawet w sytuacji, gdy serwer zachowuje się w pełni złośliwie. Taki model zagrożeń jest w praktyce uzasadniony wysoką wrażliwością danych przechowywanych w sejfach haseł. 

Eksperci przeanalizowali architekturę popularnych chmurowych menedżerów haseł, wykazując, że deklarowany model bezpieczeństwa w praktyce może być podatny na nadużycia. Badanie zostało zaprojektowane w oparciu o jawnie wrogi model zagrożeń (malicious server threat model), który znacząco wykracza poza standardowe założenia przyjmowane przez dostawców menedżerów haseł. Zamiast zakładać, że serwer jest bezpieczny, badacze przyjęli, że jest w pełni skompromitowany lub działa intencjonalnie złośliwie, a mimo to system deklarujący Zero Knowledge Encryption powinien chronić poufność i integralność danych użytkownika.  

Naukowcy przeprowadzili symulacje na własnej infrastrukturze udającej zhakowane serwery Bitwarden, LastPass i Dashlane. Na serwerach, które emulowały zachowanie skompromitowanej infrastruktury dostawcy, uzyskano praktyczne potwierdzenie podatności. Serwery te generowały spreparowane odpowiedzi API, manipulowały strukturami danych sejfu, kluczami oraz metadanymi w sposób zgodny z protokołem, lecz sprzeczny z jego intencją bezpieczeństwa. Ataki były projektowane tak, aby wykorzystywały wyłącznie rutynowe czynności wykonywane przez użytkowników, takie jak logowanie, otwieranie sejfu, synchronizacja danych, dołączanie do organizacji czy korzystanie z funkcji współdzielenia haseł.

Wyniki badań jednoznacznie wykazały, że deklarowana odporność na złośliwy serwer nie jest spełniona w żadnym z analizowanych produktów. Łącznie zidentyfikowano kilkadziesiąt podatności umożliwiających naruszenie poufności i integralności sejfów, w tym ataki prowadzące do odzyskania haseł w postaci jawnej oraz do pełnej kompromitacji sejfów organizacyjnych.  

Pierwszym fundamentalnym problemem jest nadmierne zaufanie do kontekstu kryptograficznego dostarczanego przez serwer. Klient w wielu scenariuszach przyjmuje od backendu informacje dotyczące struktury sejfu, relacji między obiektami, identyfikatorów kluczy czy metadanych organizacyjnych i nie posiada wystarczających mechanizmów weryfikacji ich autentyczności oraz integralności. O ile same dane są szyfrowane, o tyle ich „oprawa logiczna” pozostaje pod kontrolą serwera. Złośliwy backend może więc manipulować kontekstem w sposób zgodny z protokołem, ale prowadzący do ujawnienia haseł lub naruszenia integralności sejfu.  

Drugą przyczyną jest błędne założenie projektowe, że serwer nie jest aktywnie wrogi. W efekcie wiele mechanizmów – zwłaszcza synchronizacja, odzyskiwanie konta, współdzielenie haseł czy obsługa organizacji – zostało zaprojektowanych tak, aby upraszczać operacje backendowe kosztem silnej weryfikacji po stronie klienta. To prowadzi do sytuacji, w której kryptografia chroni zawartość pojedynczych obiektów, ale nie zabezpiecza całej logiki systemu przed manipulacją. 

Ostatnim wskazanym kluczowym źródłem podatności jest złożoność funkcjonalna nowoczesnych menedżerów haseł. Funkcje takie jak współdzielenie wpisów, rotacja kluczy, dostęp organizacyjny, delegowanie uprawnień czy odzyskiwanie dostępu wprowadzają dodatkowe warstwy szyfrowania i zależności. Każda z tych warstw zwiększa powierzchnię ataku i tworzy nowe punkty, w których serwer może wpływać na stan klienta. W wielu przypadkach to właśnie mechanizmy „enterprise” okazały się najbardziej podatne, ponieważ wymagały bardziej skomplikowanego zarządzania kluczami i metadanymi.  

Istotnym czynnikiem są również anty-wzorce kryptograficzne i zaszłości historyczne. Część rozwiązań wywodzi się z architektur projektowanych w latach dziewięćdziesiątych i wczesnych dwutysięcznych, kiedy nie zakładano w systemach możliwości kompromitacji serwera. W efekcie zastosowano konstrukcje, które są matematycznie poprawne, lecz nie zapewniają odporności na aktywną manipulację kontekstem przez backend. 

Badania wykazały fundamentalne ryzyko systemowe: menedżer haseł centralizuje najbardziej wrażliwe dane użytkownika – dostęp do bankowości, poczty, systemów korporacyjnych, kluczy API, danych tożsamościowych – w jednym repozytorium. W przypadku kompromitacji tego repozytorium skutki są kaskadowe.  

Realnym potwierdzeniem tego scenariusza był incydent związany z LastPass w 2022 roku. Atakujący uzyskali dostęp do środowiska developerskiego, a następnie, wykorzystując skradzione dane uwierzytelniające oraz tokeny, dotarli do zasobów w chmurze – w tym do kopii zapasowych zawierających zaszyfrowane sejfy użytkowników oraz metadane. Choć same hasła były szyfrowane, wyciek objął m.in. adresy e-mail, URL-e serwisów, dane kontaktowe i inne informacje pomocnicze. Incydent ten udowodnił, że nawet jeśli kryptografia nie zostanie bezpośrednio złamana, przejęcie warstwy serwerowej lub łańcucha dostaw aplikacji dostawcy generuje poważne ryzyko operacyjne i reputacyjne, a w dłuższej perspektywie może umożliwić ataki offline na słabo zabezpieczone sejfy (np. przy użyciu słabego hasła głównego). 

Warto podkreślić, że model chmurowy nie jest jedynym obszarem ryzyka. Popularne rozwiązania desktopowe, takie jak KeePass, również doświadczyły problemów bezpieczeństwa. W kontekście podatności CVE-2023-24055 wskazywano możliwość eksportu konfiguracji w sposób, który przy spełnieniu określonych warunków mógł prowadzić do ujawnienia bazy haseł w postaci jawnej. Choć twórcy argumentowali, że atak wymaga już uprzedniego przejęcia uprawnień administracyjnych systemu, incydent ten unaocznił inną klasę ryzyka: jeśli komputer zostaje przejęty (np. przez malware), menedżer haseł staje się atrakcyjnym celem dla adwersarza.  

Dodatkową warstwą zagrożeń są ataki aplikacyjne i przeglądarkowe. Wiele menedżerów haseł integruje się z przeglądarką poprzez rozszerzenia i funkcję autowypełniania. Mechanizmy te, choć zwiększają wygodę użytkownika, jednocześnie tworzą nowe powierzchnie ataku – od manipulacji DOM, przez clickjacking, aż po wymuszanie wypełnienia formularzy w kontekście kontrolowanym przez atakującego. W określonych scenariuszach może to prowadzić do wycieku danych uwierzytelniających bez konieczności uzyskiwania dostępu do samej bazy haseł. 

W krajobrazie zagrożeń nie można także pomijać czynnika ludzkiego. Siła menedżera haseł w dużej mierze zależy od jakości hasła głównego, zastosowania uwierzytelniania wieloskładnikowego oraz poprawnej konfiguracji. W przypadku słabego hasła głównego, wyciek zaszyfrowanej bazy – jak pokazały doświadczenia po incydencie LastPass – może umożliwić skuteczne ataki brute-force offline. Użytkownicy często przeceniają bezpieczeństwo narzędzia, zakładając, że sam fakt korzystania z menedżera haseł eliminuje ryzyko, podczas gdy w praktyce bezpieczeństwo jest funkcją całego łańcucha: infrastruktury dostawcy, implementacji kryptografii, bezpieczeństwa komputera oraz świadomości użytkownika. 

Mimo nieco smutnych wniosków płynących z przedstawionych badań i dotychczasowych incydentów,  menadżery haseł nie przestają być rozwiązaniem rekomendowanym z perspektywy higieny bezpieczeństwa – w większości przypadków są to rozwiązania bezpieczniejsze. Jednak z perspektywy analizy zagrożeń należy brać pod uwagę ich kompromitację i poważne implikacje z niej wynikające.  Model bezpieczeństwa – zwłaszcza w wersji chmurowej – opiera się na zaufaniu do infrastruktury i integralności dostawcy. Badania akademickie oraz realne incydenty pokazują, że obietnica „zero knowledge” nie jest absolutna, a bezpieczeństwo menadżera haseł jest tak silne, jak najsłabszy element jego architektury i środowiska, w którym funkcjonuje. 

Więcej informacji: 
https://eprint.iacr.org/2026/058 
https://ethz.ch/en/news-and-events/eth-news/news/2026/02/password-managers-less-secure-than-promised.html 
https://blog.szurek.tv/post/cve-2023-24055/ 
https://github.com/alt3kx/CVE-2023-24055_PoC 
https://support.lastpass.com/s/document-item?language=en_US&bundleId=lastpass&topicId=LastPass/incident-1-details.html&_LANG=enus 
https://krebsonsecurity.com/2025/03/feds-link-150m-cyberheist-to-2022-lastpass-hacks/ 

Oszustwa i podszycia

Zwrot podatku i powiadomienie z KSeF? Tym razem to phishing i keylogger. 

W ostatnim czasie obserwujemy zintensyfikowane próby phishingu z wykorzystaniem grafik i treści podszywających się pod polskie serwisy rządowe. Wiadomości są dostarczane do odbiorców za pośrednictwem e-mail oraz SMS. Mimo różnych formatów i różnych celów, ataki pojawiają się w podobnym czasie i wiążą się zarówno z corocznym rozpoczęciem rozliczania e-PIT oraz wdrożeniem KSeF. Oba te wątki wywołują dużo emocji, które atakujący chcą wykorzystać, do tego uderzając w przemyślanych terminach. 

KSeF — mail z załącznikiem 

Jednym z pierwszych zaobserwowanych przykładów jest wiadomość e-mail mająca przypominać powiadomienie od Krajowej Administracji Skarbowej. Informacja ma dotyczyć wdrożenia KSeF i zachęcić do otwarcia załącznika „Powiadomienie z dnia. 04.02.2026.iso”.  

Niepokojący powinien wydać się typ pliku, ponieważ to nie dokument, lecz obraz ISO. Jego uruchomienie spowoduje wykonanie zawartego w nim pliku EXE, który rozpocznie łańcuch infekcji. Pierwszym etapem jest GuLoader służący do pobrania ostatecznego payloadu — VIP Keyloggera. To złośliwe oprogramowanie kradnie pliki oraz dane z przeglądarek i schowka , rejestruje naciśnięcia klawiszy klawiatury, a także robi zrzuty ekranu. 

KAS — mail z linkiem phishingowym 

CERT Polska ostrzegł o wiadomościach e-mail o tytule „Zawiadomienie o wszczęciu kontroli podatkowej” podszywających się pod KAS. W mailu zawarto odnośnik do strony phishingowej, na której znajduje się wierna kopia panelu logowania do profilu zaufanego. Możliwe jest „logowanie” za pomocą nazwy użytkownika i hasła lub za pomocą bankowości elektronicznej. Niezależnie od wybranej formy, atakujący może pozyskać cenne dane uwierzytelniające pozwalające na podjęcie nieautoryzowanych działań w imieniu ofiary lub kradzież pieniędzy z konta. W obu przypadkach konieczne byłoby przejście dodatkowego etapu, w którym oszust spróbowałby wyłudzić także drugi składnik logowania, na przykład kod z SMS.  

e-PIT — SMS z linkiem phishingowym 

W zeszłym tygodniu informowaliśmy o kampanii SMS-ów informujących o możliwym do otrzymania zwrocie podatku. W wiadomościach występujących w różnych wariantach znajdował się link do strony w domenie bezpieczny-zwrot-podatku[.]com, na której znajdował się panel phishingowy. Ta strona nie była jednak wierną kopią paneli logowania lub formularzy znanych ze stron rządowych, a połączeniem kilku elementów graficznych związanych ze stronami w domenie gov.pl. Pierwszym etapem do uzyskania rzekomego zwrotu podatku miało być przekazanie danych osobowych i adresowych. Drugim, mającym na celu wyłudzenie danych dostępowych do bankowości elektronicznej, było „uwierzytelnienie bankowe” przenoszące użytkownika na stronę imitującą logowanie do wybranego banku. Szczegóły tego oszustwa przedstawialiśmy w naszym artykule. 

Zwrot środków — mail z linkiem phishingowym 

Zwrot pieniędzy został wykorzystany także w innym mailu z odnośnikiem do strony phishingowej w treści. W tym scenariuszu początkowo wyłudzany był numer dowodu osobistego lub paszportu i kod pocztowy, by na kolejnym ekranie ofiara zobaczyła podsumowanie informacji o nienależnie pobranych środkach, dla których przysługuje zwrot.  

Następnie wyłudzane są dane karty płatniczej pod pretekstem zwrotu na nią środków. Ofiara z nadzieją na uzyskanie ponad 1,5 tysiąca zł może przekazać dane, a nawet autoryzować transakcje, które pojawią się później przy skorzystaniu przez atakujących z tej karty. 

Incydent ZUS — strona phishingowa z kodem QR 

Monitorując potencjalnie złośliwe domeny napotkaliśmy eincydent[.]org oraz e-incydent[.]org, które wyraźnie mają imitować polskie systemy do zgłaszania incydentów. Treść stron wskazywała na podszywanie się pod zgłaszanie incydentów w systemie ZUS.  

Po wybraniu jednej z opcji uwierzytelnienia — jedyną aktywną w czasie analizy było logowanie za pomocą mObywatela — zostaniemy przeniesieni na stronę z kodem QR do zeskanowania za pomocą tej właśnie aplikacji. Nie udało nam się prześledzić całego scenariusza, by potwierdzić co dzieje się po zeskanowaniu kodu. Niewykluczone, że jest to forma kradzieży cudzej tożsamości i wykorzystania jej w którymś z procesów wymagających Na ten moment nie znamy metody dostarczenia odnośnika do potencjalnej ofiary, lecz obserwując podobne scenariusze podejrzewamy wiadomości e-mail.  

Zarówno nowe, jak i te dobrze znane procesy stają się celem atakujących, którzy wykorzystują te scenariusze do wyłudzania informacji lub infekowania złośliwym oprogramowaniem. W pierwszym z przypadków działa niedostateczna znajomość przebiegu autoryzacji lub procesowania zaistniałych błędów, z czego korzystają oszuści tworząc własne, wiarygodne scenariusze. Z kolei oparcie się na dobrze znanych działaniach wymaga dokładnego odtworzenia procesu przez atakujących, by oprzeć się na przyzwyczajeniach użytkowników. Przechodząc przez pozornie znane etapy autoryzacji lub potwierdzeń można zapomnieć o niezbędnym elemencie przy każdym logowaniu do istotnych kont — uważności. Przy każdym logowaniu do istotnych usług, w tym bankowości internetowej i portali rządowych, należy uważnie przyjrzeć się adresowi URL odwiedzanej strony. Ze szczególną ostrożnością powinno się podchodzić także do załączników w wiadomościach e-mail. Przy każdej wiadomości wzbudzającej emocje, wywołującej poczucie presji czasu i zachęcającej do pobrania pliku lub wejścia w link, warto skierować się na oficjalne strony instytucji. Przypominamy adresy oficjalnych stron

• Krajowej Administracji Skarbowej: https://www.gov.pl/web/kas, 
• obsługi e-PIT: https://www.podatki.gov.pl/ 
• oraz KSeF: https://ksef.podatki.gov.pl/ 

Więcej informacji: 
https://x.com/CERT_Polska/status/2021283029461667966 
https://cert.orange.pl/ostrzezenia/e-pit-lada-moment-uwazaj-na-oszustwa

The post Krajobraz zagrożeń 12-18/02/2026 appeared first on CERT Orange.

Początek ataku to – jak bardzo często w ostatnich czasach – reklama na Facebooku:

Powyższa akurat wygląda tak bardzo podejrzanie, że ciężko wyobrazić sobie kogoś, kto mógłby się na nią złapać. Czy to niemożliwe? Nie. Ktoś się złapie na pewno. I choć zwrot:

listy wszystkich osób załamanych zostały stworzone

oraz pełno błędów w treści reklamy sprawiają, że łatwo się zorientować, że coś jest nie tak – inna treść z tego samego konta jest już przygotowana zdecydowanie lepiej:

Warto spojrzeć na sam dół tego zrzutu. Widzicie, że prezentowana reklama ma kilka (dokładnie 5) wersji? Dlaczego? Pierwsze 4 udają reklamę produktu – próbując ominąć mechanizmy bezpieczeństwa Meta – i w opisywanym przypadku faktycznie przekierowują do legalnego sklepu w jednym z dużych serwisów e-commerce. Dopiero za nimi ukryta jest wersja kluczowa, która najbardziej nas interesuje.

Rzućmy jeszcze okiem, kto opublikował tę reklamę:

Tutaj nic do siebie nie pasuje.

• Nazwa: EU Compensation, jedyne co spina się kontekstowo z tematem oszustwa
• Profil: firma nadająca i produkująca programy telewizyjne (?)
• Temat postu: Michael Crichton był wyższy od Michaela Jordana – jaki to ma związek z odzyskiwaniem wykradzionych pieniędzy?
• Adres: Teoretycznie w Kijowie (nie pasuje do pozostałych), jednak ulicy Kijowskiej w stolicy Ukrainy nie ma
• E-mail właściciela: po pierwsze nie pasuje do pozostałych elementów treści, ale przede wszystkim adresy w podobnym schemacie [imię][nazwisko][rok]@zoogeogramfala[.]com powtarzają się w innych schematach phishingowych – co ciekawe – powiązanych również z Kijowem

Oszustwo tylko w telefonie

Co się stanie jeśli klikniemy w link? To zależy. Jeśli otworzymy reklamę na komputerze, trafimy na prawdopodobnie niegroźną stronę, będącą kopią rzetelnego serwisu:

Zupełnie inny wariant będzie miał miejsce, gdy podstawioną nam witrynę otworzymy w telefonie:

Dlaczego tak? Przede wszystkim dlatego, że na małym ekranie telefonu:

• pasek adresu szybko się chowa
• skupiamy się na treści strony, która zajmuje większość ekranu – nie przyglądamy się adresowi witryny

Spójrzmy zatem – za radą niebieskiego przycisku – jak to (oszustwo) działa?

Brzmi poważnie i rzetelnie. Oficjalna lista poszkodowanych, kontakt ze strony zespołu prawnego, wniosek do EBC, no i 6 do 14 dni czekania. To poważna sprawa, nie może dziać się za szybko.

Pora na weryfikację

Sprawdźmy zatem, czy jesteśmy na liście poszkodowanych. Najpierw zerknijmy na listę fałszywych firm, które miały firmować oszustwo:

a następnie odpowiedzmy na trzy pytania weryfikacyjne:

Potem pozostanie tylko podanie naszych danych:

I oczekiwanie na kontakt w ciągu 1 dnia roboczego. Oczywiście poufnie i zgodnie ze standardami UE, a także z ochroną przed spamem i oszustwami:

Co się dzieje w kolejnym kroku? Na podany przez nas adres e-mail trafiła wiadomość od prawnika, z informacją, że do jego kancelarii trafił nasz wniosek i możemy się z nim skonsultować za pośrednictwem WhatsAppa bądź Telegrama.

Sposób kontaktu to nie były jedyne czerwone flagi w wiadomości, wskazujące na oszustwo:

• mimo użycia w e-mailu nazwy i logo istniejącej kancelarii prawniczej z Amsterdamu, nadawcą wiadomości było konto w domenie Gmail.com
• jedyny prawnik o takich personaliach na LinkedIn pracuje w innej kancelarii i wygląda zupełnie inaczej
• narzędzia wykazały, iż z prawdopodobieństwem bliskim 100 procent mamy do czynienia ze zdjęciem wygenerowanym przez sztuczną inteligencję
• wyszukanie w sieci nazwy wymienionej kancelarii prawnej wskazuje jej obecność na dwóch listach ostrzeżeń

Co dzieje się dalej

Skontaktowaliśmy się więc ze wspomnianym „pomocnikiem prawnika”. W komunikatorze Telegram ma podłączone pod swoje konto holenderski numer komórkowy (+31). W odpowiedzi rozmówca zapytał, czy może skontaktować się telefonicznie.

Po potwierdzeniu zadzwonił, z numeru stacjonarnego w warszawskiej strefie numeracyjnej. Próba oddzwonienia na ten numer kończy się informacją: „Wybrany numer jest nieaktywny”. Można więc założyć, że został po prostu wpisany w bramkę telefonu internetowego, żeby nie było sytuacji, gdy do ofiary dzwoni nieznany numer. W głosie rozmówca, choć przedstawił się polskimi personaliami, było słychać wyraźny wschodni akcent.

Podczas sześciominutowej rozmowy „pomocnik prawnika” zadał szereg pytań, w tym o:

• kwotę, którą wpłaciliśmy
• formę oszustwa (giełda, inwestycje w zasoby, kryptowaluty)
• nazwę strony/firmy oszustów
• w jakich sposób straciliśmy kontakt z giełdą

Uzyskawszy informację poinformował, że w ciągu 20 minut oddzwoni do nas „prawnik zajmujący się tego typu oszustwami.

Faktycznie oddzwonił. Po raz kolejny polskie personalia i całkiem dobrze ukrywany (ale czytelny) wschodni akcent. Pochodzenie rozmówcy było też słychać przy używaniu konkretnych formuł językowych, np.:

A u pana są potwierdzenia przelewów?

To konstrukcja charakterystyczna dla języków wschodniosłowiańskich – w języku polskim używamy zwrotu: „Czy ma pan potwierdzenia przelewów?”.

Tym razem rozmowa trwała prawie kwadrans. To rzadka sytuacja w przypadku sieciowych oszustw, gdy przestępcom zależy na przekonaniu jak największej liczby osób w jak najkrótszym czasie. Tym razem w ciągu 15 minut usłyszeliśmy szereg pytań, w dużej części podobnych do tych z poprzedniej rozmowy. Czyżby sposób na sprawdzenie, czy nie plączę się w „zeznaniach”?

Co jest istotą tego oszustwa?

Gdzie w takim razie tkwi haczyk? Tym bardziej, że rozmówca wyjaśnił mi, że „jego kancelaria” pobiera wynagrodzenie wyłącznie po odzyskaniu pieniędzy, biorąc dla siebie 8% kwoty, która miałaby wrócić do ofiary. Ostrzegł jednak, że może się zdarzyć, iż w trakcie procesu odzyskiwania pieniędzy pojawią się dodatkowe koszty (jako przykład podał konieczność przetłumaczenia dokumentów), które mogą wymagać dodatkowych płatności z naszej strony.

Ja zadeklarowałem, że przyślę do „prawnika” maile z korespondencji z fałszywą giełdą, potwierdzenia przelewów bankowych oraz numery portfeli kryptowalutowych na które przelewałem pieniądze. On natomiast – draft umowy, na podstawie której „kancelaria” ma mi pomóc odzyskać moje pieniądze.

Umowa dotarła.

Uprzedzając pytania – nie, PDF nie był „wzbogacony” o złośliwy kod. Umowa też wydaje się być generyczną umową o świadczenie usług prawnych. W czym zatem tkwi kruczek? Rąbka tajemnicy uchylają nam serwisy opinii klienckich, jak np. TrustPilot, ze średnią 1,9 z 13 opinii:

Twierdzili, że odzyskają pieniądze, które straciłem w wyniku oszustwa, a tak naprawdę sami próbowali mnie oszukać.

Ta firma to oszuści! Wpłaciliśmy 2300 dolarów i ukradli nam te pieniądze! [Imię i nazwisko] nie jest licencjonowanym prawnikiem! Dzwonił do 30 minut, żądając kolejnych pieniędzy.

Totalni oszuści, nie płaćcie im w kryptowalutach. Prawdziwe kancelarie prawnicze pracują wyłącznie na realnych walutach.

Powiedzieli mi, że mam dużą kwotę pieniędzy do zwrotu, wysyłali mi fałszywe maila z banku i rzekomo dotyczące karty kredytowej. Do tego jeszcze odbierałem jakieś telefony od rzekomych oszustów. Koszmar i totalna strata czasu i pieniędzy.

Zastanówmy się zatem, bazując na powyższych opiniach, co działoby się dalej. W kolejnych etapach oszustwa mogą pojawić się dodatkowe koszty, które musimy ponieść. Być może rozmówcy, chcąc nas przekonać, że odzyskali nasze pieniądze, podsyłaliby nam sfabrykowane maile bądź inne informacje. To wszystko miałoby wzbudzić w nas przekonanie, że jesteśmy o krok od odzyskania straconych pieniędzy. Ofiara pełna nadziei wpłaciłaby obwarowane umową 8% success fee, ale rzekomo odzyskanych pieniędzy by nie zobaczyła.

Jak zatem nie paść ofiarą oszustwa? Przede wszystkim:

• nie ufać wyskakującym reklamom na Facebooku
• jeśli się wahamy – szukać „czerwonych flag” (w opisywanym przypadku było ich sporo)
• potrzebujesz wsparcia prawnego po padnięciu ofiarą oszustwa – skontaktuj się z lokalną kancelarią, gdzie możesz porozmawiać z prawnikiem osobiście

A najlepiej budować świadomość zagrożeń w internecie i nie dać się oszukać za pierwszym razem. Na naszych łamach regularnie opisujemy sieciowe zagrożenia właśnie po to, byście wiedzieli, czego możecie się spodziewać.

The post „Jesteś ofiarą oszustwa?” – uważaj, by nie dać się złapać na kolejne appeared first on CERT Orange.

Future

„Chmury trudne są?” – nie dla LLMów

Zespół badawczy Sysdig Threat Research Team udokumentował incydent z 28 listopada 2025 r., który stanowi jeden z pierwszych dobrze opisanych przykładów w pełni zautomatyzowanego ataku na środowisko Amazon Web Services, wspieranego przez duże modele językowe. W ciągu zaledwie ośmiu minut napastnik uzyskał uprawnienia administracyjne, co znacząco skraca klasyczny łańcuch ataku w chmurze i pokazuje, że fazy rekonesansu, eskalacji uprawnień oraz podejmowania decyzji operacyjnych mogą być dziś realizowane niemal w czasie rzeczywistym. Kluczowym wyróżnikiem tego incydentu była nie tylko prędkość działania, lecz także wysoki poziom automatyzacji oraz liczne artefakty sugerujące aktywne użycie LLM do generowania kodu, analizy środowiska i wyboru kolejnych kroków ataku. 

Początkowy dostęp został uzyskany poprzez kradzież poświadczeń IAM przechowywanych w publicznie dostępnym bucketcie S3, który zawierał dane wykorzystywane w procesach RAG dla modeli AI. Ujawnione klucze należały do użytkownika posiadającego uprawnienia do usług Lambda oraz Bedrock, co już na starcie zapewniło atakującemu szeroką widoczność środowiska i możliwości dalszej eskalacji. Następnie przeprowadzono szybki rekonesans, obejmujący enumerację kluczowych usług, takich jak Secrets Manager, SSM, Bedrock czy SageMaker, co pozwoliło na precyzyjne dopasowanie kolejnych działań do rzeczywistej konfiguracji konta. 

Decydującym momentem ataku była eskalacja uprawnień zrealizowana poprzez wstrzyknięcie złośliwego kodu do funkcji Lambda o nazwie „EC2-init”. Kod ten, zawierający rozbudowaną obsługę wyjątków, timeout 30 sekund oraz komentarze w języku serbskim, automatycznie listował użytkowników IAM, generował nowe klucze dostępu dla konta administracyjnego „frick” oraz przeszukiwał kolejne buckety S3. Charakterystyka kodu, jego struktura oraz tempo przygotowania silnie sugerują, że został on wygenerowany lub co najmniej wspomagany przez LLM, co znacząco obniżyło barierę techniczną eskalacji. Już w pierwszych minutach ataku napastnik uzyskał trwały dostęp administracyjny, co w praktyce zakończyło fazę initial compromise. 

W dalszym etapie zaobserwowano intensywny ruch boczny pomiędzy kontami, realizowany poprzez wielokrotne wywołania mechanizmu AssumeRole, w tym roli OrganizationAccountAccessRole. Łącznie skompromitowano 19 principalów AWS, obejmujących zarówno użytkowników, jak i role, również w kontekstach cross-account. Co istotne, część prób wskazywała na typowe „halucynacje” modeli językowych, takie jak odwołania do nieistniejących identyfikatorów kont, co pośrednio potwierdza użycie automatycznego systemu decyzyjnego zamiast ręcznego operatora. Równolegle atakujący stosował rotację adresów IP, utrudniając korelację zdarzeń i obniżając skuteczność klasycznych mechanizmów detekcji. 

Szczególnie niepokojącym elementem incydentu było wykorzystanie usługi Bedrock do tzw. LLMjackingu. Napastnik wywoływał modele takie jak Claude 3.5 Sonnet czy Llama 4 Scout, jednocześnie weryfikując brak pełnego logowania oraz automatycznie akceptując umowy Marketplace. Działania te wskazują na motywację stricte ekonomiczną – nieautoryzowane użycie mocy obliczeniowej modeli językowych, zarówno w celu uniknięcia kosztów, jak i potencjalnej dalszej odsprzedaży dostępu. Zjawisko to wpisuje się w obserwowany od 2024 r. trend nadużyć usług AI w chmurze, gdzie dzienne koszty nielegalnego wykorzystania LLM mogą sięgać dziesiątek tysięcy dolarów. 

Kulminacją ataku było uruchomienie instancji GPU typu p4d.24xlarge, której koszt przekracza 30 dolarów za godzinę. Na instancji zainstalowano CUDA oraz PyTorch, a analiza artefaktów sugeruje przygotowanie środowiska do trenowania modeli uczenia maszynowego z użyciem publicznie wystawionego Jupytera. Choć instancja działała jedynie kilka minut, sam fakt jej uruchomienia potwierdza, że atakujący dążył do szybkiej monetyzacji przejętych zasobów, zanim incydent zostanie wykryty. 

Analizowany incydent można interpretować jako kolejny etap ewolucji ekosystemu ataków na chmurę, który wcześniej był reprezentowany przez kampanie przypisywane do TeamTNT oraz Kinsing, a dziś coraz częściej przybiera formę półautonomicznych lub w pełni autonomicznych botów przejmujących konta AWS. W przypadku TeamTNT obserwowano centralnie zarządzaną infrastrukturę C2, masowe skanowanie Internetu pod kątem źle zabezpieczonych środowisk Docker, Kubernetes i ECS oraz szybkie wdrażanie minerów kryptowalut i backdoorów opartych na prostych skryptach powłoki. Kinsing, choć operacyjnie mniej scentralizowany, wprowadził istotny krok naprzód poprzez natywne wykorzystanie API dostawców chmurowych, automatyczne zakładanie zasobów compute oraz dynamiczne pobieranie modułów zależnych od wykrytego środowiska. Obie te kampanie łączyła jednak fundamentalna cecha: ich logika decyzyjna była statyczna, a zachowanie – w dużej mierze przewidywalne po zidentyfikowaniu wzorców skanowania i sekwencji wywołań API. 

W analizowanym ataku widoczna jest jakościowa zmiana tego paradygmatu, polegająca na przeniesieniu części „inteligencji operacyjnej” z człowieka lub sztywnego skryptu do warstwy modelu językowego. LLM pełni tu rolę dynamicznego silnika decyzyjnego, który na bieżąco interpretuje wyniki rekonesansu, generuje kod dostosowany do aktualnych uprawnień IAM i wybiera kolejne wektory eskalacji, bez konieczności wcześniejszego zaprogramowania wszystkich możliwych scenariuszy. Podejście to tłumaczy zarówno niezwykle krótki czas przejścia od initial access do pełnych uprawnień administracyjnych, jak i obecność artefaktów typowych dla generatywnego kodu, takich jak rozbudowana obsługa wyjątków, nadmiarowe komentarze czy próby odwołań do nieistniejących zasobów. W tym sensie atak ten nie jest anomalią, lecz logiczną kontynuacją trendu zapoczątkowanego przez wcześniejsze „AWS takeover bots”, które od lat krążą w podziemnych kanałach dystrybucji, publikowane w postaci frameworków na GitHub, sprzedawane w zamkniętych grupach na Telegram lub oferowane jako usługa na forach cyberprzestępczych. 

Kluczowa różnica polega na tym, że wcześniejsze narzędzia wymagały od operatora szczegółowej znajomości architektury AWS i ręcznego dostosowywania parametrów ataku, podczas gdy obecna generacja botów może abstrahować tę wiedzę do poziomu wysokopoziomowych poleceń, delegując szczegóły implementacyjne do modelu językowego. W efekcie próg wejścia dla ataków na chmurę ulega dalszemu obniżeniu, a zdolności dotychczas zarezerwowane dla wyspecjalizowanych grup stają się dostępne dla szerokiego spektrum aktorów – od cyberprzestępców finansowych po podmioty działające na styku cyberprzestępczości i cyberwywiadu. Z perspektywy obronnej oznacza to, że klasyczna atrybucja oparta na TTP przestaje być jednoznaczna: te same sekwencje API, role IAM i usługi chmurowe mogą być wykorzystywane zarówno przez kampanie przypisywane do TeamTNT czy Kinsing, jak i przez w pełni zdecentralizowane, autonomiczne boty, których „podpis” operacyjny jest generowany dynamicznie. W dłuższej perspektywie sugeruje to przejście od rozpoznawania znanych rodzin zagrożeń do detekcji anomalii behawioralnych i ekonomicznych, takich jak nienaturalnie szybka eskalacja uprawnień, masowe wywołania usług AI czy krótkotrwałe, kosztowne alokacje zasobów GPU, które stają się nowym, wspólnym mianownikiem nowej generacji ataków na chmurę.

Na naszych oczach widoczny jest wyraźny sygnał zmiany paradygmatu zagrożeń chmurowych. Automatyzacja wspierana przez LLM skraca czas od kompromitacji do pełnej kontroli środowiska do minut, a nie dni czy tygodni, jak miało to miejsce w klasycznych kampaniach cloud intrusion. W praktyce oznacza to, że organizacje nie mogą już polegać wyłącznie na prewencji konfiguracyjnej, lecz muszą inwestować w ciągły monitoring runtime, korelację zdarzeń oraz aktywne wykrywanie anomalii. 

Więcej informacji: 
https://www.sysdig.com/blog/ai-assisted-cloud-intrusion-achieves-admin-access-in-8-minutes  

Zaawansowane zagrożenia

Notepad++, czyli jak uzyskać dostęp do cennych stacji roboczych.

Ataki na łańcuch dostaw nie bez powodu mrożą krew w żyłach analitykom ryzyka i cyberbezpieczeństwa. Funkcjonowanie wielu korporacji i firm w erze cyfrowej opiera się na długiej liście oprogramowania niezbędnego do realizacji podstawowych zadań. Nawet jeżeli wprowadzono listę oprogramowania akceptowanego w organizacji, ale aktualizacje są wdrażane automatycznie, każde zaufane narzędzie może stać się niebezpieczne przy pobraniu nowej wersji. W przypadku dobrze zewidencjonowanego rozwiązania obecnego na jednym lub dwóch dobrze znanych serwerach, problem jest zarządzalny. Ale co dzieje się w przypadku narzędzia, które jest niemalże wszędzie? 

Taka sytuacja wyszła na jaw częściowo już w grudniu 2025 roku, lecz pełnoprawne ogłoszenie incydentu wraz z szerszym opisem problemu pojawiło się na początku lutego tego roku. To właśnie wtedy Notepad++ w oficjalnym komunikacie poinformował o ataku na poziomie infrastruktury dostawcy hostingu. Umożliwił on atakującym przechwycenie i przekierowanie ruchu związanego z aktualizacjami kierowanego do oficjalnych zasobów N++. Atak był możliwy przez słabość mechanizmu aktualizacji, który nie wdrażał dostatecznej ochrony przed takim scenariuszem. Poprawka implementująca weryfikację podpisu i certyfikatu instalatora w czasie aktualizacji została wydana 9 grudnia 2025 roku. W komunikacie na temat incydentu zaznaczono, że przy współpracy z zewnętrznymi ekspertami przeanalizowano incydent i oceniono, że nieautoryzowany dostęp miał miejsce już w czerwcu i trwał z dużą dozą prawdopodobieństwa aż do 2 grudnia 2025 roku. Każda instalacja w tym zakresie czasowym była potencjalnie złośliwa. 

Warto podkreślić sformułowanie potencjalnie. Według komunikatu ruch był przekierowywany wybiórczo tak, by jedynie wyselekcjonowani przez atakujących użytkownicy otrzymali złośliwą aktualizację. Wybierane były jedynie strategicznie istotne cele. Z pewnością nieprzypadkowo przejęto akurat łańcuch dostaw Notepad++, w końcu jest to narzędzie wykorzystywane przez developerów, administratorów i analityków. Jest to grupa osób potencjalnie posiadających wysokie uprawnienia i szerokie dostępy, co z perspektywy atakujących jest szczególnie cenne.  W oparciu o analizę incydentu Rapid7 stwierdziło, że odpowiedzialna była za to grupa Lotus Blossom, chiński aktor klasy APT. Wnioski te zostały wyciągnięte między innymi na podstawie użycia charakterystycznego loadera, który był wyraźnie podobny do tego opisywanego przez Symantec i wiązanego z Lotus Blossom. Zaobserwowano także użycie podobnego łańcucha wykonania oraz tego samego klucza publicznego pozyskanego z wykorzystanego beacona Cobalt Strike, co dodatkowo potwierdza to przypisanie. Analizując metody wykorzystywane w trakcie ataku i łańcuchy wykonania złośliwego oprogramowania, Kaspersky także wskazuje na chińskiego threat actora. Lotus Blossom to grupa aktywna od 2009 roku i realizująca przede wszystkim celowane kampanie szpiegowskie głównie w Azji Południowo-Wschodniej i Ameryce Środkowej. Sektory znajdujące się w grupie ich szczególnego zainteresowania to telekomunikacja, lotnictwo, infrastruktura krytyczna, media i instytucje rządowe. Jak pokazał także ten incydent, nie uderzają w przypadkowe cele. 

Obraz uzyskanego przez atakującego dostępu, który wyłania się z analiz wskazuje na duży potencjał wykorzystania go do masowych infekcji. Mimo to, zainfekowany został jedynie mały zbiór celów, a dalsze obserwowane działania wskazywały na wykorzystanie personalizowanego malware oraz Cobalt Strike. Nietrudno sobie wyobrazić scenariusz, w którym taki dostęp jest wykorzystywany w pełni na szeroką skalę. Kradzież danych logowania i portfeli kryptowalutowych, stworzenie botnetu lub instalacja cryptominerów to tylko przykłady możliwych sposobów na monetyzację takich możliwości. Jednym z prawdopodobnych wyjaśnień ograniczenia tej aktywności do tak wąskiej grupy było zmniejszenie prawdopodobieństwa wykrycia i umożliwienie utrzymania długotrwałego dostępu bez zakłóceń. Wpisuje się to w metodykę gwarantującą szczególnie chińskim grupom APT tak dużą skuteczność działań cyberszpiegowskich. 

Miesiące lub lata pozostawania w infrastrukturze w uśpieniu i długotrwałe aktywne działania atakujących klasy APT to wyzwanie w analizie na wielu poziomach. Jednym z nich może być zasięg czasowy przechowywanych logów. Należy zadać sobie pytanie, czy mamy szansę potwierdzić taką aktywność lub jej brak, jeżeli miała ona miejsce w czerwcu minionego roku. Uczciwa odpowiedź na to pytanie wraz z rzeczową oceną, czy nasza firma leży w kręgu zainteresowań konkretnych grup APT może pozwolić lepiej przygotować się na tego typu ataki zanim nastąpią. W przypadku Notepad++ zalecana jest niezwłoczna aktualizacja wszystkich instalacji Notepad++ do najnowszej wersji. Ponadto, by wykluczyć lub potwierdzić aktywność Lotus Blossom w infrastrukturze należy zweryfikować obecność indykatorów sieciowych w logach i plikowych na stacjach, gdzie mogły one pozostać po ataku. 

Więcej informacji: 
https://notepad-plus-plus.org/news/hijacked-incident-info-update/ 
https://www.rapid7.com/blog/post/tr-chrysalis-backdoor-dive-into-lotus-blossoms-toolkit/ 
https://www.validin.com/blog/exploring_notepad_plus_plus_network_indicators/ 
https://securelist.com/notepad-supply-chain-attack/118708/ 
https://censys.com/blog/npp-infra 

Cybercrime

Błąd w Ivanti EPMM i jego skutki dla bezpieczeństwa rządów w Europie.

Ivanti Endpoint Manager Mobile (EPMM), dawniej znany jako MobileIron Core, platforma klasy MDM/UEM (Mobile Device Management/Unified Endpoint Management). Z punktu widzenia architektury bezpieczeństwa, system ten stanowi punkt centralny dla wszystkich mobilnych urządzeń organizacji— zarządza konfiguracją, dystrybucją aplikacji oraz, co najważniejsze, poświadczeniami dostępu do zasobów wewnętrznych. Przejęcie serwera MDM daje cyberprzestępcom dużo możliwości, co sprawia, że jest on celem o wysokim priorytecie. Uzyskanie dostępu do takiego systemu, pozwala nie tylko na kradzież danych z samego serwera, ale potencjalnie na infekcję tysięcy podłączonych do niego urządzeń (najczęściej telefonów komórkowych). Jednoczesne ujawnienie podatności CVE-2026-1281 oraz CVE-2026-1340, ich prawie natychmiastowe uwzględnienie w katalogu CISA KEV (Known Exploited Vulnerabilities Catalog) z zaleceniem 3-dniowej remediacji oraz potwierdzone włamania do systemów organów rządowych w Holandii i Finlandii obrazują sytuację, która wykracza poza ramy standardowego incydentu IT. 

Operacyjne znaczenie podatności wynika z możliwości zdalnego wykonania dowolnego kodu w systemie bez uwierzytelnienia. Podatność wynika z faktu, że Bash interpretuje zmienne w obliczeniach arytmetycznych jako wyrażenia, a nie zwykły tekst. Pozwala to atakującym podstawić pod parametr wejściowy nazwę innej zmiennej zawierającej ukryte polecenie systemowe, które zostanie automatycznie wykonane przez skrypt podczas przetwarzania. Aby oszukać filtry sprawdzające długość danych, cyberprzestępcy stosują dopełnienie ciągów znaków spacjami, co pozwala na skutecznie przeprowadzenie ataku. Uzyskany w ten sposób dostęp może zostać wykorzystany jako pierwszy krok do trwałego przejęcia systemu, na przykład przez instalację ukrytych mechanizmów utrzymania dostępu. 

Analiza wykazała wykorzystanie mechanizmu utrzymania dostępu (persistence) opartego na technice Sleeper Shell, która polega na osadzeniu w systemie skryptu pozostającego w uśpieniu przez większość czasu. Aktywacja złośliwego komponentu następuje dopiero po spełnieniu określonego warunku, otrzymaniu specjalnego parametru wejściowego, co skutecznie utrudnia detekcję ze względu na brak stałej komunikacji z infrastrukturą atakującego. W badanym przypadku wykorzystano ścieżkę sieciową /mifs/403.jsp do ładowania złośliwego kodu (shellcode) bezpośrednio do pamięci procesu serwera, co pozwala na ominięcie skanerów EDR i AV poprzez unikanie pozostawiania śladów w systemie plików. Istotnym wskaźnikiem tej aktywności jest obecność nagłówka Java CAFEBABE, zakodowanego w formacie Base64 jako yv66vg. Sam implant base.info nie działa samodzielnie, lecz oczekuje na specyficzny wyzwalacz dostarczający drugą część kodu, po czym przystępuje do zbierania informacji o hoście, takich jak katalog roboczy, system operacyjny czy nazwa użytkownika. Informacje te są przekazywane atakującemu jako argumenty, co pozwala dostosować dalsze działania do konkretnego celu. 

Przegląd globalnej telemetrii dostarcza dowodów na to, że eksploitacja przeprowadzana jest na masową skalę, a dynamika kampanii ewoluowała od fazy rozpoznania do infiltracji. Dane z systemów GreyNoise wskazują, że dominującym źródłem ataków, odpowiadającym za 83% zaobserwowanych prób, jest pojedynczy adres IP osadzony w rosyjskiej infrastrukturze bulletproof hostingu (PROSPERO OOO, AS200593). Trustwave SpiderLabs udokumentowało wcześniej powiązania między PROSPERO a siecią Proton66 (AS198953), łącząc obie z usługami hostingowymi typu bulletproof sprzedawanymi na rosyjskojęzycznych forach poświęconych cyberprzestępczości pod marką BEARHOST. Sieć ta była powiązana z infrastrukturą dystrybucyjną wielu rodzin złośliwego oprogramowani, takich jak GootLoader czy SpyNote. Wskazuje to na wykorzystanie współdzielonej infrastruktury, co uniemożliwia przeprowadzenie atrybucji do jednego threat aktora, a potwierdza jedynie korzystanie z zasobów o udokumentowanej historii hostowania różnorodnych złośliwych operacji. 

Istnieją podejrzenia, że kampania wymierzona w Ivanti EPMM jest prowadzona przez brokerów dostępu (Initial Access Brokers – IAB) ze względu na dwuetapowy modelu działania atakujących, który skupia się na budowaniu bazy wielu dostępów zamiast na natychmiastowej kradzieży danych. Analiza GreyNoise wykazała, że aż 85% zaobserwowanych ataków służy jedynie do weryfikacji podatności systemu za pomocą mechanizmu OAST (DNS callback), co pozwala cyberprzestępcom potwierdzić, że dany cel jest do przejęcia. Zamiast od razu podejmować dalsze działania, atakujący umieszczają opisywane wcześniej Sleeper Shells, które nie wykonują żadnych akcji i czekają na specjalny sygnał aktywujący. Taka strategia jest charakterystyczna dla brokerów, którzy przygotowują zweryfikowane dostępy do sieci organizacji, aby następnie odsprzedać je lub przekazać innym grupom przestępczym, które zajmą się np. eksfiltracją danych lub atakiem ransomware w późniejszym terminie. Co więcej, stosowane narzędzia są uniwersalne i zaprojektowane tak, by działały niezależnie od specyfiki konkretnego serwera, co sugeruje chęć masowego wykorzystania, a nie precyzyjny atak na jedną wybraną instytucję. 

Z drugiej strony profilowanie ofiar na podstawie incydentów w holenderskim organie ochrony danych (AP), Radzie Sądownictwa (Rvdr), Komisji Europejskiej oraz fińskim Valtori (rządowe centrum usług ICT) dostarcza dowodów na precyzyjny charakter kampanii celowany w europejskie organy państwowe. Skalę zagrożenia dobrze obrazuje sytuacja w Valtori, gdzie system zarządzania urządzeniami dla 50 000 zamiast trwale kasować dane pracowników, jedynie oznaczał je jako usunięte. Oznacza to, że skutki ataku obejmują nie tylko obecnych pracowników, ale potencjalnie całą historię cyklu życia usługi, eksponując dane kontaktowe i metadane urządzeń osób, które dawno opuściły struktury rządowe. Kradzież tych informacji stwarza bazę wiedzy o personelu kluczowych instytucji, co może stanowić fundament dla przyszłych operacji phishingowych i działań z zakresu inżynierii społecznej o wysokim stopniu personalizacji. 

Dla zespołów bezpieczeństwa kluczowe znaczenie ma zrozumienie, że samo usunięcie podatności systemu jest niewystarczające. Katalogowanie celów podatnych na ataki zamiast natychmiastowego dostarczania złośliwego oprogramowania oraz odkrycia dotyczące Sleeper Shell sugerują, że początkowe wykorzystanie jest jedynie pierwszą fazą. Jeśli kampania ta przebiega zgodnie z modelem IAB, zainfekowane instancje EPMM mogą nie wykazywać oczywistych oznak nadużycia przez tygodnie lub miesiące. Pojawienie się nieoczywistej ścieżki /mifs/403.jsp w instancjach EPMM wskazuje na naruszenie bezpieczeństwa, nawet jeśli nie są widoczne żadne dalsze złośliwe działania. 

Operacyjnie, po wdrożeniu poprawek, absolutnie krytyczne jest wykonanie restartu wszystkich serwerów aplikacji— jest to jedyna metoda na wyczyszczenie pamięci operacyjnej z ewentualnych implantów Sleeper Shell, które będąc w pamięci nie przetrwają restartu procesu. Zignorowanie tego kroku oznacza utrzymanie uśpionego dostępu, który w każdej chwili może zostać aktywowany do przeprowadzenia destrukcyjnych ataków typu ransomware lub długofalowego szpiegostwa.  

Więcej informacji: 
https://labs.watchtowr.com/someone-knows-bash-far-too-well-and-we-love-it-ivanti-epmm-pre-auth-rces-cve-2026-1281-cve-2026-1340/ 
https://defusedcyber.com/ivanti-epmm-sleeper-shells-403jsp 
https://www.greynoise.io/blog/active-ivanti-exploitation 
https://www.levelblue.com/blogs/spiderlabs-blog/proton66-part-1-mass-scanning-and-exploit-campaigns

The post Krajobraz zagrożeń 05-11/02/2026 appeared first on CERT Orange.

W ostatnich dniach CERT Orange Polska obserwuje wzmożony napływ ruchu SMS, podszywającego się pod źródła rządowe. Jako nadawca wiadomości początkowo pojawiały się nadpisy „GOV” i „MOF”, w późniejszym etapie oszuści przerzucili się na zwykłe numery. Można oczekiwać, że w miarę blokad konkretnych nadpisów będą próbowali wykorzystywać nazwy mniej lub bardziej przypominające te wymienione powyżej.

Domena bezpieczny-zwrot-podatku[.]com, do której przekierowują linki z wiadomości, została założona we wtorek 10 lutego. Po kliknięciu w link trafiamy na witrynę utrzymaną w stylistyce polskich stron rządowych. Jej część to wierna kopia serwisu Ministerstwa Finansów. Kluczowe jest jednak sama treść, a nie elementy wizualne:

Ostrzegając Was na co uważać, gdy strona wydaje się być phishingiem, kładziemy nacisk na dokładną lekturę jej treści. Zwrot

rząd Polski jest Ci winien pieniądze

jest zbyt potoczny, by znaleźć się na witrynie Ministerstwa Finansów. Co więcej – weryfikacja tożsamości obywatela nie następuje poprzez wpisanie danych, a za pośrednictwem serwisu login.gov.pl.

Gdy trafiasz na ekran logowania do serwisów rządowych ZAWSZE upewnij się, czy adres jest poprawny, a nie bliźniaczo podobny! Podając swoje dane, szczególnie pozwalające na dostęp do istotnych informacji, zawsze warto upewnić się co do autentyczności odwiedzonej strony.

Co wyłudzają oszuści pod pozorem zwrotu z e-PIT?

Tego dowiadujemy się się już w kolejnym kroku, gdy pojawia się okno z monitem o wybór naszego banku pod pozorem potwierdzenia tożsamości, niezbędnej do zwrotu rzekomej nadwyżki z e-PIT.

Ta socjotechniczna sztuczka może oszukać część internautów. Dlaczego? Wiele osób wie bowiem, że jedną z metod dostępu do serwisów rządowych jest zalogowanie się przy użyciu systemów e-bankowości! Dlatego trzeba pamiętać, by logując się do banku obowiązkowo upewnić się, czy w adres w pasku jest adresem naszego banku! W powyższym przypadku tak nie jest – graficzna nakładka podszywa się pod Bank Millenium, podczas gdy nie opuściliśmy domeny bezpieczny-zwrot-podatku[.]com.

Co stanie się, gdy nieopatrznie wpiszemy na takiej stronie nasz login i hasło? W kolejnym kroku zobaczymy monit o podanie kodu SMS opisany tak, by nie wzbudzić naszego niepokoju. Gdy go wpiszemy – przestępcy przejmą niemal pełną kontrolę nad naszym kontem. A ponieważ przy takich kampaniach oszuści zwykle obsługują je na bieżąco, ofiara po kilku minutach mogłaby już mieć wyczyszczone konto.

Co robić, by nie dać się oszukać?

Nie ufaj SMS-om o treści związanej z podatkami. Jeśli chcesz sprawdzić swoje zeznanie podatkowe – od 15 lutego zrobisz to w serwisie https://epit.podatki.gov.pl/. Wszelkie interakcje z serwisami rządowymi podejmuj wyłącznie na stronach, których adres kończy się na gov.pl.

A poza tym niezmiennie pamiętaj, by:

• do linków w SMS-ach podchodzić z bardzo ograniczonym zaufaniem
• im więcej emocji wywołuje treść wiadomości – tym dokładniej się jej przyjrzeć
• upewnić się co do adresu strony zawsze, gdy wpisujesz gdzieś login/hasło/dane karty płatniczej
• bardzo dokładnie czytać treści SMS-ów z kodami autoryzacyjnymi od banku (zazwyczaj szczegółowo opisują co potwierdzisz danym kodem)
• wysłuchać dokładnie komunikaty głosowe, prezentowane gdy dzwoni do Ciebie automat z banku (ostrzegają one, by nie podawać nikomu PIN-ów, które za chwilę usłyszymy)

Analogiczne zasady dotyczą wiadomości e-mail, oszuści często wybierają także ten kanał komunikacji.

The post e-PIT lada moment, uważaj na oszustwa! appeared first on CERT Orange.

W najnowszym Krajobrazie Zagrożeń skupiamy się na czterech tematach, którym przyjrzeliśmy się bliżej. Doświadczonych analityków na pewno nie zdziwi, że fenomen OpenClaw, asystenta AI naprawdę „robiącego rzeczy”, musi się wiązać z szeregiem zagrożeń, ale postanowiliśmy je przeanalizować i zebrać w jednym miejscu. Uważnie przestudiowaliśmy także Raport CERT Polska dotyczący grudniowych ataków na polską energetykę i podzieliliśmy się naszymi spostrzeżeniami o tym, czego może nas ten incydent nauczyć. W temacie globalnie interesujących kampanii znaleźliśmy miejsce na wątek lipcowej podatności w WinRAR, która dalej jest wykorzystywana w atakach realizowanych zarówno przez grupy APT, jak i te motywowane finansowo. Nie zabrakło także CVE Tygodnia, na które wybraliśmy podatność w Office.

Future

OpenClaw – asystent AI, który „robi rzeczy”. Czy bezpiecznie? 

Historia projektu OpenClaw to kwintesencja dzisiejszego tempa rozwoju technologii. Projekt w ciągu zaledwie tygodnia stał się fenomenem, zdobywając 98 000 gwiazdek na GitHubie. Przechodził on zmiany nazewnictwa w stosunkowo krótkim czasie – od Clawdbot, przez Moltbot do OpenClaw, która jest ostateczną nazwą, pod którą system zyskał ponad 350 000 pobrań NPM oraz ponad 370 współtwórców. 

Wizja osobistego asystenta, który dzięki integracjom MCP i API wyręcza w wysyłaniu wiadomości, e-maili, zarządzaniu kalendarzem czy operacjach finansowych, okazała się zbyt kusząca, by przejść obok niej obojętnie, co potwierdzają liczby. Na dzień 31 stycznia 2026 Censys zidentyfikował ponad 21 000 instancji wystawionych bezpośrednio do Internetu, z czego 1/3 hostowana w chmurze Alibaba Cloud. Za tą nagłą popularnością stoi filozofia vibe coding, często bez ścisłych procedur bezpieczeństwa. Stwarza to sytuację, w której kod projektu ma niską dojrzałość, a jednak codzienna użyteczność agenta AI wymaga wysokich uprawnień i niemal całkowitego zaufania od użytkownika. Aby OpenClaw działał zgodnie z przeznaczeniem, potrzebuje dostępu do plików systemowych, danych uwierzytelniających, zarówno haseł, jak i sekretów API, historii przeglądarki i plików cookie oraz wszystkich plików i folderów w systemie. 

Podatności i błędy architektury 

Priorytetyzacja szybkości dostarczania funkcji nad rygorem inżynierii bezpieczeństwa skończyła się błędami w konfiguracji i podatnościami. 23 stycznia zidentyfikowano błędną implementację mechanizmu zaufania w usłudze Moltbot Gateway. System domyślnie ufał połączeniom z adresu 127.0.0.1. W scenariuszach wykorzystujących reverse proxy, ruch zewnętrzny był identyfikowany jako lokalny, co umożliwiało nieautoryzowany dostęp z zewnątrz do panelu administracyjnego i eksfiltrację historii rozmów oraz kluczy API. W następnych dniach raporty wskazały na domyślny brak mechanizmów uwierzytelniania dla dostępu zdalnego. W połączeniu z uprawnieniami root, asystent stał się wektorem dla zdalnego wykonywania poleceń systemowych bez autoryzacji użytkownika. Dodatkowo wyszły błędy w obsłudze sekretów – klucze API i hasła były składowane w jawnym tekście w katalogu ~/.clawdbot. Co istotne, mechanizm redundancji danych powodował, że usunięte sekrety pozostawały aktywne w systemie plików (do pięciu kopii zapasowych .bak.X), co czyniło je podatnymi na ataki typu credential harvesting przez dedykowane infostealery. 

Dopełnieniem powyższych wad projektowych jest podatność CVE-2026-25253 (CVSS v3 8.8). Jest to błąd logiczny pozwalający na przeprowadzenie ataku typu 1-Click Remote Code Execution (RCE), co w praktyce oznacza możliwość przejęcia pełnej kontroli nad systemem użytkownika po zaledwie jednym kliknięciu w złośliwy link. Istota problemu tkwi w sposobie, w jaki aplikacja przetwarza parametry URL. Przed wprowadzeniem poprawki OpenClaw bez żadnego potwierdzenia ze strony użytkownika przyjmował parametr gatewayUrl i automatycznie nawiązywał połączenie WebSocket z podanym adresem, wysyłając token uwierzytelniający użytkownika (authToken) bezpośrednio na serwer kontrolowany przez atakującego. Dysponując skradzionym tokenem,  atakujący jest w stanie zdalnie wyłączyć mechanizmy obronne, a następnie wymusić wykonanie komend bezpośrednio na systemie operacyjnym hosta zamiast w izolowanym kontenerze Docker. 

Kampanie ClawHavoc i AuthTool

Podatności i błędy w architekturze OpenClaw stworzyły przestrzeń do przeprowadzenia masowych operacji wymierzonych w łańcuch dostaw rozszerzeń. Kluczowym wektorem infekcji stały się tzw. umiejętności (skills) czyli wtyczki mające w teorii rozszerzać funkcjonalność asystenta. W serwisie ClawHub zidentyfikowano atak na łańcuch dostaw obejmujący 341 złośliwych „umiejętności”. Większość z nich przypisuje się operacji oznaczonej kryptonimem ClawHavoc. Model ataku opierał się na manipulacji procesem instalacji, w którym każda zainfekowana wtyczka zawierała sekcję „Wymagania wstępne”, instruującą użytkownika do pobrania archiwum ZIP chronionego hasłem lub uruchomienia zaszyfrowanego skryptu powłoki. 

W ten sposób atakujący wdrażali m.in. infostealer AMOS przeznaczony na macOS. AMOS, dystrybuowany w modelu Malware-as-a-Service (MaaS), pozwala na kompleksową eksfiltrację danych wrażliwych, w tym: haseł i poświadczeń z pęku kluczy, danych z ponad 60 portfeli kryptowalutowych, sesji Telegrama i kluczy SSH oraz plików z katalogów użytkownika (Pulpit, Dokumenty). 

Równolegle zaobserwowano kampanię wykorzystującą spreparowane narzędzie AuthTool. Aby uwiarygodnić infekcję, złośliwe umiejętności posiadały rozbudowaną dokumentację, sugerującą, że AuthTool jest niezbędny do prawidłowego funkcjonowania bota. Do infekcji dochodzi, gdy ofiara postępuje zgodnie z instrukcjami zawartymi w dokumentacji.  Schemat ten jest zbliżony do technik typu ClickFix. W rzeczywistości AuthTool pełni rolę droppera, który w systemie macOS wykorzystuje zakodowane w Base64 polecenie powłoki pobierające wariant złośliwego oprogramowania NovaStealer. Oprogramowanie to skutecznie omija mechanizm Gatekeeper (używając polecenia xattr -c do usunięcia atrybutów kwarantanny) i żąda szerokiego dostępu do usług systemowych. Za to w systemie Windows AuthTool wdraża zaszyfrowane archiwum ZIP zawierające złośliwe oprogramowanie. Malware pozwala na kradzież m.in. kluczy API giełd kryptowalut, pliki portfeli, dane pęku kluczy, hasła przeglądarek, poświadczeń chmurowych (AWS/Azure), dane Git oraz – co szczególnie ryzykowne w kontekście deweloperskim – pliki konfiguracyjne .env. 

Shadow AI i rekomendacje

Sytuacja wokół OpenClaw rzuca światło na szerszy problem Shadow AI, gdzie nieautoryzowane wdrażanie narzędzi o wysokiej autonomii wyprzedza korporacyjne procesy oceny ryzyka. W kontekście Shadow AI, OpenClaw przestaje być tylko narzędziem, a staje się „wirtualnym pracownikiem” o wysokich uprawnieniach. Jeśli taki agent zostanie przejęty, atakujący zyskuje dostęp do wszystkich połączonych usług, takich jak Slack, poczta czy Discord. Mechanizm trwałej pamięci agenta pozwala na implementację zagrożeń typu logic bomb, które mogą zostać aktywowane długo po pierwotnej infekcji.  

Dla zespołów bezpieczeństwa możliwe jest wdrożenie blokady na poziomie ochrony sieciowej dla domen takich jak *.openclaw.ai oraz specyficznych skryptów instalacyjnych (np. openclaw.ai/install.sh). W przypadku stwierdzenia występowania podatności CVE-2026-25253 należy niezwłocznie zaktualizować OpenClaw do wersji v2026.1.24-1 lub nowszej oraz wygenerować nowy authToken dla instancji OpenClaw oraz zmiana wszystkich kluczy API połączonych usług. W kontekście umiejętności (skilli) OpenClaw użytkownik powinien zachować szczególną ostrożność wobec umiejętności wymagających wklejania komend do terminala, instalowania dodatkowych plików binarnych lub pobierania paczek ZIP z niezaufanych źródeł. 

Więcej informacji: 
https://www.koi.ai/blog/clawhavoc-341-malicious-clawedbot-skills-found-by-the-bot-they-were-targeting 
https://socradar.io/blog/cve-2026-25253-rce-openclaw-auth-token/ 
https://www.paloaltonetworks.com/blog/network-security/why-moltbot-may-signal-ai-crisis/ 

Zaawansowane zagrożenia

29.12.2025: Wipery walczą z wiatrakami  

Krajowy krajobraz zagrożeń pozostaje wyjątkowo zróżnicowany, jednak w ostatnich dniach debatę środowiska cyberbezpieczeństwa jednoznacznie zdominowała analiza incydentu, do którego doszło 29 grudnia 2025 roku i który dotknął polskiego sektora energetycznego. Było to zdarzenie bezprecedensowe w skali kraju – zarówno pod względem zakresu, jak i poziomu koordynacji działań. Do tej pory w Polsce nie obserwowaliśmy incydentu, który w tak spójny i jednoczesny sposób obejmowałby wiele podmiotów infrastruktury (niemal krytycznej; implicite te obiekty nie należały formalnie do IK), łącząc elementy środowisk IT i OT oraz jednoznacznie destrukcyjny cel operacyjny.

CERT Polska, w opublikowanym raporcie, szczegółowo opisał serię skoordynowanych cyberataków o charakterze dywersyjnym, wymierzonych w farmy wiatrowe i fotowoltaiczne, dużą elektrociepłownię oraz podmiot sektora produkcyjnego. Analiza pokazuje, że napastnicy konsekwentnie wykorzystywali słabości na styku dostępności i bezpieczeństwa – podatne urządzenia brzegowe, konta z domyślnymi lub współdzielonymi hasłami, brak uwierzytelniania wieloskładnikowego oraz ograniczony monitoring bezpieczeństwa. Celem tych działań nie była kradzież danych ani długotrwała infiltracja, lecz trwałe uszkodzenie systemów i paraliż procesów technologicznych przy użyciu wyspecjalizowanego złośliwego oprogramowania typu wiper (DynoWiper i LazyWiper). Szczegóły techniczne przebiegu ataku, wykorzystanych narzędzi i wektorów zostały bardzo dokładnie udokumentowane w Raporcie CERT Polska, do którego lektury zachęcamy. 

Z perspektywy analityka, incydent ten jest szczególnie interesujący nie tyle ze względu na sam fakt użycia wiperów, a na długą i konsekwentną fazę przygotowawczą, która wyraźnie poprzedzała działania destrukcyjne. Zidentyfikowane artefakty w trakcie analiz  postincydentalnych, pokazują, że atakujący nie działali w sposób chaotyczny ani impulsywny, lecz metodycznie mapowali środowisko ofiar, korzystając z narzędzi i technik, które w wielu organizacjach wciąż pozostają w tzw. „szarej strefie” detekcji. Już na etapie „discovery”  widoczna jest świadoma decyzja o wykorzystaniu narzędzi powszechnie używanych przez administratorów, takich jak Advanced IP Scanner czy Advanced Port Scanner, co znacząco utrudnia odróżnienie aktywności napastnika od legalnych działań operacyjnych. Z punktu widzenia analityka są to sygnały niskoszumowe, rozłożone w czasie, często wykonywane w godzinach pracy biurowej, a więc idealnie wpisujące się w normalny profil ruchu w sieci korporacyjnej. 

Kolejnym elementem, który zwraca uwagę, jest szerokie i bardzo świadome wykorzystanie pakietu Impacket. Narzędzia z tego zestawu pozwalają na lateral movement, zdalne wykonywanie poleceń oraz interakcję z usługami domenowymi przy użyciu standardowych protokołów, takich jak SMB czy RPC. Dla analityka oznacza to, że wiele kluczowych artefaktów incydentu nie pojawia się w postaci jednego wyraźnego „złośliwego procesu”, lecz jako sekwencja poprawnych technicznie operacji uwierzytelnienia, dostępu do zasobów i wykonywania poleceń. W praktyce różnica między atakiem a administracją sprowadza się do kontekstu, korelacji zdarzeń i ich nienaturalnej częstotliwości lub kolejności, co bez centralnej korelacji logów i dobrej widoczności środowiska jest niezwykle trudne do uchwycenia. 

Szczególnie istotnym sygnałem z perspektywy analitycznej jest użycie tuneli zwrotnych typu Reverse SOCKS Proxy. Mechanizm ten pozwala atakującemu na kierowanie ruchu do sieci wewnętrznej przez przejętą maszynę, omijając klasyczne mechanizmy filtracji ruchu przychodzącego. W analizowanym incydencie obecność narzędzi takich jak rsocx2 wskazuje na potrzebę utrzymania elastycznego, interaktywnego dostępu do środowiska ofiary, a jednocześnie na próbę minimalizacji liczby bezpośrednich połączeń z infrastruktury zewnętrznej. Dla analityka są to artefakty szczególnie cenne, ponieważ często pozostawiają ślady w postaci nietypowych procesów, połączeń wychodzących do rzadko spotykanych adresów IP lub anomalii w zachowaniu stacji roboczych, które nagle zaczynają pełnić rolę punktów pośredniczących w komunikacji sieciowej. 

Warto również zwrócić uwagę na konsekwentne unikanie dedykowanego malware w fazie przygotowawczej. Aż do momentu uruchomienia wipera atakujący niemal wyłącznie korzystał z narzędzi systemowych, przeglądarki internetowej, PowerShella oraz publicznie dostępnych narzędzi ofensywnych. Z analitycznego punktu widzenia jest to klasyczny przykład podejścia living-off-the-land, w którym kluczowe wskaźniki kompromitacji nie mają postaci sygnatur, lecz anomalii behawioralnych. Dopiero końcowa faza ataku – dystrybucja i uruchomienie wipera – generuje wyraźny sygnał bezpieczeństwa, jednak w tym momencie, co raport wyraźnie pokazuje, czas na skuteczną reakcję jest już skrajnie ograniczony. 

Z perspektywy zespołów SOC, zwłaszcza Inżynierii Detekcji oraz Threat Huntingu, warto również podkreślić, że sam raport CERT Polska stanowi wyjątkowo wartościowy materiał roboczy, który wykracza daleko poza klasyczną funkcję informacyjną. Opisane w nim techniki, narzędzia i sekwencje działań pozwalają na budowę bardzo konkretnych reguł detekcyjnych oraz scenariuszy huntingowych, opartych nie na pojedynczych wskaźnikach kompromitacji, lecz na zachowaniach i zależnościach czasowych. Rekonesans realizowany przy użyciu popularnych skanerów sieciowych, nienaturalne wzorce uwierzytelnień charakterystyczne dla narzędzi Impacket czy obecność mechanizmów tunelowania ruchu wychodzącego to elementy, które dają się stosunkowo dobrze odwzorować w logach, pod warunkiem, że organizacja dysponuje odpowiednią widocznością. Raport może więc służyć nie tylko jako opis incydentu, ale jako punkt wyjścia do testowania własnych zdolności detekcyjnych, weryfikacji luk w telemetrii oraz budowy hipotez huntingowych odnoszących się wprost do realnych, obserwowanych w Polsce technikach ataku. 

W tym miejscu wyraźnie ujawnia się problem atrybucji, który w omawianym przypadku został włączony do przestrzeni publicznej. Raport CERT Polska dostarcza wartościowego i szczegółowego materiału technicznego, jednocześnie pokazując ograniczenia procesu atrybucyjnego w sytuacji, gdy opiera się on głównie na analizie infrastruktury oraz wykorzystywanych narzędzi, bez pełnej syntezy wszystkich warstw incydentu w jeden spójny intrusion set. W przypadku operacji destrukcyjnych, gdzie część artefaktów ulega celowemu zniszczeniu, a ciągłość danych bywa przerwana, takie podejście naturalnie zwiększa poziom niepewności analitycznej. Atrybucja powinna w tym kontekście pozostawać hipotezą roboczą, podlegającą dalszej weryfikacji wraz z pojawianiem się nowych informacji, a nie być traktowana jako ostateczne domknięcie procesu analitycznego. Z perspektywy metodologii analitycznej warto również podkreślić, że podobieństwo technik, narzędzi czy elementów infrastruktury nie stanowi samo w sobie wystarczającej podstawy do jednoznacznej atrybucji. Bez wyraźnego powiązania celów operacyjnych, kontekstu strategicznego oraz obserwowanej ciągłości działań w czasie, wnioski atrybucyjne oparte wyłącznie na warstwie technicznej obarczone są istotnym marginesem niepewności. Incydent ten może więc stanowić użyteczny punkt odniesienia do dalszej dyskusji nad dojrzałością i granicami atrybucji w analizie incydentów o charakterze destrukcyjnym. 

Patrząc już nieco z perspektywy na incydent oraz przedstawione analizy, warto przywołać zasadę często powtarzaną w środowisku bezpieczeństwa: „nie pozwólmy zmarnować dobrego incydentu”. Mamy dostarczony rzadko spotykany, kompletny materiał analityczny – od długotrwałego rekonesansu, przez lateral movement i przygotowanie infrastruktury, aż po próbę fizycznie odczuwalnej destrukcji systemów. To moment, w którym sektor energetyczny i szerzej cała infrastruktura krytyczna mają realną szansę wyciągnąć wnioski nie tylko na poziomie deklaracji, lecz konkretnych zmian w podejściu do monitoringu, segmentacji, zarządzania tożsamością i widoczności środowisk OT. Jeżeli ten incydent zostanie potraktowany wyłącznie jako jednorazowy kryzys, a nie jako punkt odniesienia do budowy długofalowej odporności, ryzyko jego powtórzenia pozostanie jedynie kwestią czasu. Warto więc wykorzystać ten przypadek jako lekcję – dla analityków, architektów bezpieczeństwa i decydentów – zanim kolejny aktor przejdzie tę samą ścieżkę, być może już bez możliwości skutecznego ograniczenia skutków. 

Więcej informacji: 
https://cert.pl/posts/2026/01/raport-incydent-sektor-energii-2025/ 
https://www.welivesecurity.com/en/eset-research/dynowiper-update-technical-analysis-attribution/ 

Cybercrime

Kiedy exploity mają otwarte źródła, a aktualizacje są odkładane 

27 stycznia Google Threat Intelligence Group (GTIG) opublikowało analizę aktywnego wykorzystania w atakach podatności CVE-2025-8088. Jest to luka typu Path Traversal w WinRAR wyceniona na 8.4 w skali CVSS (v4.0). Mimo, iż jest „tylko” podatność typu path traversal, może ułatwiać atakującym wykonanie złośliwego oprogramowania w systemie ofiary. Luka polega na umieszczeniu w archiwum złośliwych alternatywnych strumieni danych (ADS), niewidocznych dla użytkownika, ale ekstrahowanych wraz z widocznym nieszkodliwym plikiem. Prowadzi to do możliwości wypakowania pliku w wybranej przez atakującego ścieżce. Dzięki tej luce, wypakowanie archiwum – powszechnie uważane za bezpieczną czynność – stało się sposobem na uruchomienie złośliwego oprogramowania przez nieświadomą ofiarę.  

Pierwsze przypadki wykorzystania podatności w atakach, według ESET, miały miejsce już 18 lipca 2025, a 30 lipca podatność doczekała się opublikowania poprawek. Według ich analizy, początkowo pojawiała się w działaniach powiązanej z Rosją grupy RomCom, lecz obserwowano już wtedy próby ze strony innych grup. Według GTIG, mimo pojawienia się łatki, ataki wciąż są powszechne. Z CVE-2025-8088 nadal korzystają grupy klasy state-sponsored skupiające się na poważnych celach, w tym militarnych, rządowych lub związanych z technologią. Może to świadczyć o skuteczności takich ataków wynikającej z niewystarczającej dbałości o szybkie aktualizacje oprogramowania lub pobłażliwego traktowania podatności typu Path Traversal.  

Wymienione przez GTIG grupy korzystające z CVE-2025-8088 to przede wszystkim rosyjscy threat actorzy atakujący Ukrainę. UNC4895 (RomCom), APT44, TEMP.Armageddon i Turla wykorzystywały w atakach tę podatność do umieszczenia w folderze Startup plików LNK i HTA, które następnie służyły do pobierania kolejnych payloadów. Ofiary do rozpakowania archiwum miały przekonać ukraińskie nazwy plików, w tym takie z motywem militarnym. Innym przypadkiem ataków klasy state-sponsored jest przykład wykorzystania tej luki przez chińskiego atakującego do umieszczenia w folderze Startup pliku BAT, który służył do pobrania droppera i ostatecznie dostarczenia malware POISONIVY. Poza APT z podatności korzystają także grupy motywowane finansowo, lecz ataki są bardzo podobne w metodach, a aktywność wydaje się być międzynarodowa. Dostarczane złośliwe oprogramowanie to RATy (XWorm oraz AsycRAT) i infostealery. Interesującym przypadkiem jest atak na brazylijskich użytkowników, który opierał się na dostarczenia złośliwego rozszerzenia do Chrome. Pozwalało to atakującym na wstrzyknięcie w strony brazylijskich banków skryptów phishingowych.  

W CERT Orange Polska stale monitorujemy złośliwe oprogramowanie atakujące polskich użytkowników i w ramach tych analiz także natrafiliśmy na wykorzystanie tej podatności. Atak opiera się umieszczeniu w folderze Startup pliku Built.exe, który jest infostealerem napisanym w Pythonie. „Przynętą” był nieszkodliwy plik także znajdujący się w archiwum Dokumentacja.rar – fałszywe wezwanie do stawienia się na komendę w Krakowie. Dostarczany malware kradnący dane został z dużą dozą pewności oparty na Blank Grabberze, na co pozwala jego otwarty kod źródłowy. Szerzej ten przypadek opisujemy w naszym artykule.

Według GTIG jeden z użytkowników forów ogłaszał możliwość zakupienia exploita tej podatności już w lipcu 2025 roku. Nie tłumaczy to jednak aż tak szerokiego wykorzystania podatności w zróżnicowanych atakach, które aktualnie obserwujemy. Z naszej perspektywy luka była dostatecznie łatwa w wykorzystaniu, a kody źródłowe exploitów można aktualnie znaleźć na GitHubie. Uważnie śledząc próbki można zauważyć bliźniacze wręcz zachowania i analogiczne (lub te same) nazwy plików payloadów mimo dostarczania różnego złośliwego oprogramowania. Tak podobne podejścia do wykorzystywania podatności dającej wiele możliwości mogą świadczyć o korzystaniu przez atakujących z tych samych instrukcji, poradników lub exploitów. Otwarte źródła zarówno złośliwego oprogramowania i exploitów umożliwiają zbudowanie własnego łańcucha ataku z ogólnodostępnych modułów. Dodając do tego odrobinę programowania z pomocą LLM (vibe coding) atakujący mogą uzyskać personalizowany atak bez konieczności posiadania specjalistycznych umiejętności lub środków na sfinansowanie zlecenia takich działań. Sprawia to, że ataki są łatwiejsze i tańsze w przeprowadzeniu, a zaawansowane techniki są obserwowane dużo szerzej.  

Przeszukując inne pliki RAR wykorzystujące lukę CVE-2025-8088 napotkaliśmy także takie, których celem byli analitycy OSINT. Świadczą o tym nazwy pliku jak na przykład Free 2026 Osint Tools.rar.  

Nawet analitycy cyberbezpieczeństwa czasem potrzebują przypomnienia o podstawach dobrych praktyk w zakresie obrony przed złośliwym oprogramowaniem:

• dbajmy o aktualizacje oprogramowania,
• nie korzystajmy z menadżera haseł wbudowanego w przeglądarkę,
• ostrożnie podchodźmy do narzędzi pobieranych z internetu,
• pamiętajmy, że z GitHuba korzystają także twórcy i dystrybutorzy złośliwego oprogramowania,
• analizując niezaufane oprogramowanie, realizujmy całość w odseparowanym środowisku.

Więcej informacji: 
https://cloud.google.com/blog/topics/threat-intelligence/exploiting-critical-winrar-vulnerability 
https://www.welivesecurity.com/en/eset-research/update-winrar-tools-now-romcom-and-others-exploiting-zero-day-vulnerability/  
https://cert.orange.pl/aktualnosci/podatnosc-w-winrar-i-infostealer-w-pythonie/  

CVE Tygodnia

CVE-2026-21509 – aktywnie wykorzystywana podatność w MS Office

Jednym z istotnych zagrożeń obserwowanych w ostatnim okresie jest podatność CVE-2026-21509 w pakiecie Microsoft Office, która ma szczególne znaczenie ze względu na bardzo szeroki zasięg oraz potwierdzone wykorzystanie w rzeczywistych atakach. Luka dotyczy mechanizmów obsługi obiektów OLE/COM i umożliwia obejście wbudowanych zabezpieczeń pakietu Office, w tym mechanizmów ostrzegających użytkownika przed potencjalnie niebezpieczną zawartością dokumentu. W praktyce oznacza to, że specjalnie spreparowany dokument – najczęściej w formacie RTF – może po otwarciu przez użytkownika uruchomić złośliwy kod bez wyraźnych sygnałów ostrzegawczych, co znacząco zwiększa skuteczność ataków phishingowych i spear-phishingowych. 

Skuteczna ochrona przed CVE-2026-21509 wymaga przede wszystkim natychmiastowego wdrożenia aktualizacji bezpieczeństwa Microsoft, szczególnie w środowiskach, w których aktualizacje Office nie są instalowane automatycznie. W przypadkach, gdzie patchowanie jest opóźnione, istotną rolę odgrywają środki kompensacyjne, takie jak ograniczenie obsługi obiektów OLE, blokowanie dokumentów RTF w poczcie elektronicznej, wzmocnione filtrowanie załączników oraz monitoring nietypowej aktywności procesów Office, zwłaszcza połączeń sieciowych inicjowanych bezpośrednio po otwarciu dokumentu. Ponieważ exploit wymaga interakcji użytkownika, kluczowym elementem obrony pozostaje także świadomość zagrożeń i odporność na kampanie phishingowe. 

Szczególne znaczenie tej podatności wynika z faktu jej wykorzystania przez APT28 (Fancy Bear, Sofacy) w kampanii opisanej przez badaczy Zscaler jako Operation Neusploit. W ramach tej operacji CVE-2026-21509 była używana jako element początkowego dostępu, głównie poprzez starannie przygotowane kampanie spear-phishingowe, w których ofiary otrzymywały dokumenty tematycznie dopasowane do ich profilu i bieżącej sytuacji geopolitycznej. Po otwarciu dokumentu exploit umożliwiał pobranie kolejnych komponentów z infrastruktury atakującego, często z wykorzystaniem mechanizmów WebDAV, co dodatkowo utrudniało detekcję na poziomie sieciowym. 

Analiza kampanii APT28 pokazuje, że wykorzystanie CVE-2026-21509 było częścią wieloetapowych łańcuchów ataku, prowadzących do instalacji backdoorów i loaderów umożliwiających długotrwałe utrzymanie dostępu do środowiska ofiary. W obserwowanych przypadkach celem działań było przede wszystkim szpiegostwo informacyjne, w tym kradzież korespondencji e-mailowej oraz danych wrażliwych, co wpisuje się w długofalowy profil operacyjny tej grupy. Kampania była ukierunkowana na organizacje rządowe, dyplomatyczne i instytucje o znaczeniu strategicznym, w tym w państwach Europy Środkowo-Wschodniej. 

Wiecej informacji:
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-21509 
https://www.zscaler.com/blogs/security-research/apt28-leverages-cve-2026-21509-operation-neusploit  

The post Krajobraz zagrożeń 28/01-04/02/2026 appeared first on CERT Orange.

W ramach stałego monitorowania zagrożeń zidentyfikowaliśmy plik Dokumentacja.rar, który zwrócił naszą uwagę ze względu na wykorzystanie podatności w oprogramowaniu WinRAR. Dalsza analiza wykazała, że po wypakowaniu archiwum z wykorzystaniem podatnej wersji następowała infekcja prowadząca do kradzieży danych z systemu. W dalszej części raportu spojrzymy bliżej na przebieg tego ataku – od otwarcia archiwum aż po wysyłkę danych na zewnętrzny serwer.

Podatność CVE-2025-8088

Podatność typu path traversal może z pozoru nie brzmieć groźnie. CVE-2025-8088 wyceniona została na 8.4 w skali CVSS (v4.0). To podatność o wadze określanej jako wysoka, lecz nie krytyczna. Mimo iż jest „tylko” podatność typu path traversal, może ułatwiać atakującym wykonanie złośliwego oprogramowania w systemie ofiary. Luka polega na umieszczeniu w archiwum złośliwych alternatywnych strumieni danych (ADS) niewidocznych dla użytkownika, ale ekstrahowanych wraz z widocznym nieszkodliwym plikiem. Prowadzi to do możliwości wypakowania pliku w wybranej przez atakującego ścieżce. Dzięki tej luce wypakowanie archiwum – powszechnie uważane za bezpieczną czynność – stało się sposobem na uruchomienie złośliwego oprogramowania przez nieświadomą ofiarę.

Podatność została odkryta przez analityków ESET w lipcu 2025 roku i została określona mianem zero-day – odkrycie wynikało z identyfikacji ataków z jej wykorzystaniem. W momencie publikacji wykorzystywana była przez rosyjską grupę RomCom realizującą zarówno ataki oportunistyczne, jak i celowane działania szpiegowskie.

Po publikacji ESET z czasem pojawiło się szersze wykorzystanie tej luki w atakach. Znaczącą rolę w ich upowszechnieniu mają z pewnością publicznie dostępne opatrzone szczegółowymi instrukcjami kody exploitów W analizowanych próbkach zaobserwowaliśmy powtarzające się nazwy plików oraz ścieżek, mimo iż na końcu dostarczane było inne złośliwe oprogramowanie.  To może wskazywać na korzystanie z tych samych „poradników” przez różnych atakujących. 

Więcej o zróżnicowanych grupach i atakujących korzystających z CVE-2025-8088 można przeczytać w raporcie Google Threat Intelligence Group . Nasza analiza skupiła się na próbce obserwowanej w Polsce oraz malware dostarczanym z wykorzystaniem tej podatności.

Archiwum Dokumentacja.rar, a w nim…

Nie wiadomo w jaki sposób plik archiwum Dokumentacja.rar trafiał do ofiar. Szersze obserwacje pokazują, że tego typu pliki najczęściej dostarczane są za pośrednictwem wiadomości e-mail lub – w ostatnim czasie – przez różne komunikatory. Otrzymana wiadomość ma na celu przekonać ofiarę do działań prowadzących do realizacji celów atakującego. W tym przypadku otwarcia i rozpakowania archiwum RAR.

Użytkownik, który otrzyma taki plik i otworzy go za pomocą podatnego wersji WinRAR, zobaczy w nim jeden plik PDF. Z błędnym założeniem, że samo rozpakowanie archiwum nie jest groźne, zrobi to, by poznać zawartość pliku.

Execution: Exploitation for Client Execution (T1203)

W tym momencie działa podatność Path Traversal CVE-2025-8088 sprawiająca, że użytkownik nie widzi ukrytego pliku, który doprowadza do uruchomienia payloadu w zaplanowanej przez atakującego lokalizacji. Może to być ścieżka gwarantująca atakującemu trwałość dostępu (persistence) (np. umieszczenie w folderze Startup) lub opóźnienie uruchomienia (harmonogram zadań).

Dla porównania, otwierając archiwum za pomocą 7-Zip widoczny będzie dodatkowy folder, w którym na samym końcu ścieżki znajduje się złośliwy plik Built.exe.

W tym przypadku po rozpakowaniu archiwum pojawia się wiele komunikatów błędów, wśród których trudno dostrzec próby utworzenia pliku w niepokojącej lokalizacji. Plik PDF znajdujący się w archiwum to wezwanie do stawienia się rzekomo pochodzące od „Komendy Miejskiej Policji w Krakowie”. Może to stanowić podpowiedź w jaki sposób adresat złośliwej wiadomości mógł być zachęcany do otwarcia archiwum. Gdy ofiara jest zajęta przypomnieniem sobie o jakie zdarzenie drogowe może chodzić w „wezwaniu”, w tle wykonuje się złośliwe oprogramowanie.

Rozpakowanie archiwum rozpoczyna sekwencję aktywności w pełni realizującej cele atakującego. Napisane w Pythonie złośliwe oprogramowanie wykorzystuje przede wszystkim cmd.exe i Powershella.

Defense Evasion: Impair Defenses (T1562)

Pierwszymi działaniami jest “odblokowanie” pliku Built.exe, by ominąć blokadę MOTW (Mark of The Web) mającą utrudnić uruchamianie plików pobranych z internetu.

powershell -Command "Unblock-File -Path \"C:\Users\admin\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\Built.exe\" -ErrorAction SilentlyContinue"

Następnie ścieżka na dysku do pliku jest dodawana do listy wykluczeń programu Microsoft Defender, a w kolejnym kroku wyłączany jest aktywny monitoring w czasie rzeczywistym.

powershell -Command Add-MpPreference -ExclusionPath 'C:\Users\admin\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\Built.exe'

powershell  Set-MpPreference -DisableIntrusionPreventionSystem $true -DisableIOAVProtection $true -DisableRealtimeMonitoring $true -DisableScriptScanning $true -EnableControlledFolderAccess Disabled -EnableNetworkProtection AuditMode -Force -MAPSReporting Disabled -SubmitSamplesConsent NeverSend

Discovery: System Information Discovery (T1082)

Pozbywając się potencjalnej przeszkody w postaci Defendera malware zaczyna zbierać informacje o systemie. Za pośrednictwem domeny ip-api.com sprawdzany jest publiczny adres IP ofiary wraz z lokalizacją. Zaobserwowano między innymi komendy, sprawdzające adres MAC, informacje o sieci Wi-Fi wraz z hasłem, listę procesów i zawartość schowka.

getmac
netsh wlan show profile
Get-Clipboard
tree /A /F
tasklist /FO LIST

Szczególnie rzucająca się w oczy komenda zawiera zakodowany w Base64 skrypt odpowiadający za zrobienie zrzutu ekranu na urządzeniu ofiary.

powershell.exe -NoProfile -ExecutionPolicy Bypass -EncodedCommand JABzAG8AdQByAGMAZQAgAD0AIABAACIADQAKAHUAcwBpAG4AZwAgAFMAeQBzAHQAZQBtADsADQAKAHUAcwBpAG[…]

Pewne szczególne zainteresowania atakujących można też zauważyć poprzez ich eksplorację kluczy rejestru powiązanych z grą Roblox. Taki dostęp może pozwolić na pozyskanie danych sesji i przejęcie konta użytkownika.

powershell Get-ItemPropertyValue -Path HKLM:SOFTWARE\Roblox\RobloxStudioBrowser\roblox.com -Name .ROBLOSECURITY

Zbierane są także dane z przeglądarek internetowych, informacje dotyczące portfeli kryptowalutowych i lista plików znajdujących się na urządzeniu w wybranych folderach.

Collection: Archive Collected Data (T1560)

Pozyskane dane zebrane są w archiwum RAR zabezpieczonym hasłem „vortexprosrdfhdf”.  Całość pogrupowana jest w foldery: 2FA Tokens, Credentials, Directories oraz System. Dodatkowo, znajduje się tam także plik PNG ze zrzutem ekranu zainfekowanego systemu.

W folderze System znajdziemy informacje o systemie ofiary zebrane przez atakującego, w tym posiadane rozwiązanie antywirusowe, zawartość schowka i klucz produktowy systemu.

Informacje zawarte w Directories to usystematyzowany wgląd w podstawowe foldery użytkownika i obecne w nich pliki.

Folder Credentials to w tym przypadku przede wszystkim ciasteczka oraz historie przeglądarek.

Exfiltration: Exfiltration Over Web Service (T1567)

Charakterystyczna dla tej infekcji jest eksfiltracja na dedykowaną domenę pliku RAR spakowanego z hasłem. Znajdujący się na stronie 5euv5g5fyjgjftft[.]xyz/staler/[nazwa pliku].rar plik można pobrać ze strony bez dodatkowej autoryzacji czy weryfikacji – do jego otwarcia konieczne jest jednak hasło. Można je pozyskać z logów z czasu wykonania złośliwego oprogramowania lub z dedykowanego powiadomienia na Telegramie.

Atakujący jest powiadamiany o każdej nowej ofierze za pośrednictwem wiadomości wysyłanej poprzez Telegram API do bota. Odpowiednio sformatowana wiadomość z kluczowymi dla operatora parametrami infekcji pojawia się na kanale Telegram wraz z linkiem oraz hasłem do pobrania pełnej paczki danych.

Automatyzacja oraz usprawnienie oceny wartości skradzionych danych wskazuje na dostosowanie obsługi do dynamicznych (i możliwe, że długotrwałych) kampanii.

Poza możliwością wysyłki wiadomości, bot realizuje także inne funkcje, które widoczne są w próbce. Pozostałe opcje pozwalają uzyskać informację o bocie, aktualizacjach i webhookach, ale także usunąć webhook i odrzucić przychodzące aktualizacje.

Wracając jednak do domeny 5euv5g5fyjgjftft[.]xyz wykorzystanej w procesie eksfiltracji danych, na głównej stronie można tam znaleźć niedopracowaną fałszywą bramkę płatności podszywającą się pod PayU. Może to świadczyć o podwójnym zastosowaniu domeny, współdzielonej infrastrukturze lub niedokończonym projekcie kampanii phishingowej.

Blank Python Vortex

Wstępna analiza zachowania złośliwego oprogramowania jednoznacznie wskazała, że próbka to stealer napisany w języku Python. Większość realizowanych funkcji zgadza się także z konkretną rodziną malware – Blank Grabberem. Wskazywałby na to także klucz licencyjny WinRAR znajdujący się w pliku rarreg.key ściśle związany z twórcą Blank Grabbera – Blank-c.

RAR registration data Blank-cStealer LicenseUID=e7ae0ee11c8703113d9564122122503d95ca34668bc2ffb72bcf8579be24bc20f3cd84baafafcf62e30badf158ad0c60feb872189f288e79eb40c28ca0ab64073a46f47624f80a44a0e4d71ef4224075bf9e28fce340a29099d28715690be6b591c3bb355e99d6d1b8ffcd69602cb8aaa6dedf268c8355c1fb90c384a926139625f6c0cbfc57a96996fdb04075bf9e28fce340a29067e9237e333577d2c7f3ed1d0f63287f74c9e50c60d76db5915ff59f78103d48e0826658d72ba8813da4a649711057613203

Standardowo jednak Blank Grabber charakteryzuje się eksfiltracją z wykorzystaniem Discorda lub Telegrama, tutaj dodatkowo pojawił się serwer w domenie pod kontrolą atakującego, na której umieszczany był plik ze skradzionymi danymi. Dokładniejsze porównanie wykazało kolejne różnice. Log błędów o charakterystycznej nazwie vortex_ssman_error.log, nie pojawia się w innych analizowanych próbkach tego złośliwego oprogramowania. Co więcej, ta sama nazwa widoczna jest także w pliku ze skradzioną historią przeglądarki Edge:

===================Vortex SsMaN===================

Dla porównania, w przypadku Blank Grabbera w takim pliku znajduje się analogiczny „nagłówek”:

==================Blank Grabber===================

Rebranding? Ambitny „fork”? Eksperymenty ze złośliwym oprogramowaniem? Firma Broadcom dwa lata temu opublikowała interesujące ostrzeżenie o „Vortex Stealerze”, którego opis jest zgodny z zaobserwowanym zachowaniem omawianego infostealera, a nazwa nie wydaje się przypadkowa. Nie opublikowano jednak bardziej szczegółowych informacji pozwalających ocenić, czy to rzeczywiście ten sam złodziej danych, co analizowana próbka.

Otwarte źródła, otwarte pytania

Na podstawie części reguł YARA oraz werdyktów sandboxów można byłoby jednoznacznie uznać dostarczane złośliwe oprogramowanie za Blank Grabbera. W przypadku braku pewności, co do rodziny malware pojawiało się także ogólne wskazanie na generycznego stealera napisanego w Pythonie. Dokładniejsza analiza zachowania, tworzonych plików i cech charakterystycznych prowadzi bliżej stwierdzenia, że jest to pewna odmiana Blank Grabbera, lecz ulepszona lub dostosowana do potrzeb aktualnego operatora.

Warto zauważyć, że pierwowzór to projekt open-source, którego rozwój zakończył się w 2023 roku. Repozytorium doczekało się kilku publicznych „forków”, co jest naturalną koleją rzeczy w przypadku tego typu oprogramowania o publicznym kodzie źródłowym. Blank Grabber cechuje się szeroką gamą możliwości personalizacji zachowania, celów i sposobu komunikacji, co z pewnością przyciąga przestępców mniej doświadczonych w tworzeniu własnego złośliwego oprogramowania. Jest on też interesującą alternatywą dla usług MaaS (Malware-as-a-Service), które cechują się dużą zależnością od operatorów malware, m.in. w zakresie powierzanych im danych i infrastruktury.

Przy analizie takiego ataku nasuwa się pytanie natury klasyfikacyjnej. Czy „fork” Blank Grabbera z kosmetycznymi zmianami w kodzie, to już inny malware? Tego typu zakończony projekt, wciąż publicznie dostępny, rozwija się w sposób kompletnie nieliniowy. Trudno w takim razie mówić o drugiej lub kolejnej jego wersji. Sama analiza behawioralna i ekstrakcja konfiguracji może się odbywać w niemalże taki sam sposób, jak w przypadku Blank Grabbera, co jest kluczową kwestią, jeżeli nadrzędnym celem jest pozyskanie i blokada adresów C2. Jednak dla celów śledzenia podobnych kampanii i rozwoju konkretnej gałęzi, wyodrębnienie i nazwanie tej odsłony może okazać się pomocne.

Z perspektywy analityków, publicznie dostępny kod źródłowy malware utrudnia wiązanie złośliwego oprogramowania z konkretnymi operatorami i developerami. W przypadku MaaS można rozgraniczyć grupy odpowiedzialne za wytwarzanie oprogramowania oraz za jego wykorzystywanie w kampaniach, ale z założeniem współpracy na zasadzie afiliant-operator. Rozwiązania open-source usuwają te powiązania i sprawiają, że z oprogramowania może skorzystać każdy, dowolnie je zmodyfikować i realizować swoje działania, które są kompletnie niezależne od twórcy.

Modułowy atak w myśl „DIY”

Rozwijanie oprogramowania stało się dużo łatwiejsze z pomocą agentów LLM, ale także usprawnionych funkcji proponowania ulepszeń lub poprawek w kodzie w środowiskach programistycznych. W połączeniu z szeroką dostępnością złośliwego oprogramowania open-source, stworzenie dopasowanego do własnych potrzeb, działającego stealera jest niebezpiecznie łatwe. W tym przypadku atakujący mógł skorzystać z projektów dostępnych na GitHubie, które pozwoliły mu na zbudowanie ataku z gotowych modułów na zasadzie „do it yourself”.

Publiczny exploit i otwartoźródłowy stealer, to połączenie pokazujące jedno z ciekawszych oblicz aktualnych zagrożeń. Niezależnie do tego, czy mamy styczność z Blank Grabberem, Vortex Stealerem, czy „generycznym złodziejem danych” napisanym w Pythonie, tego typu zagrożenia są wszędzie i nie znikną. Dostarczane na różne sposoby, lecz z jednym celem – ukraść dane i możliwie jak najszybciej je spieniężyć.

Rekomendacje

Dokumentacja.rar to jedno z wielu archiwów wykorzystujących podatność CVE-2025-8088. Niektóre z nich, wnioskując po nazwach pliku, miały uderzać w specjalistów z zakresu OSINT (np. Free 2026 Osint Tools.rar). Nawet analitycy cyberbezpieczeństwa czasem potrzebują przypomnienia o podstawach dobrych praktyk w zakresie obrony przed złośliwym oprogramowaniem:

• dbajmy o aktualizacje oprogramowania,
• nie korzystajmy z menadżera haseł wbudowanego w przeglądarkę,
• ostrożnie podchodźmy do narzędzi pobieranych z internetu,
• pamiętajmy, że z GitHuba korzystają także twórcy i dystrybutorzy złośliwego oprogramowania,
• analizując niezaufane oprogramowanie, realizujmy całość w odseparowanym środowisku.

Większość stealerów jest skutecznie wykrywana przez programy antywirusowe – o ile oczywiście nie zostaną uprzednio wyłączone. Nie zawsze jednak poznamy dokładną rodzinę malware lub ocenimy, czy złośliwe oprogramowanie dokonało już szkód na zainfekowanym systemie. Dlatego nie należy polegać na jednym rozwiązaniu i stworzyć reguły wykrywające złośliwą aktywność na każdym jej etapie, w tym powiadamiające o próbie wyłączenia antywirusa. Warto zwrócić uwagę na duże nagromadzenie działań mających na celu zebranie informacji o systemie i jego otoczeniu. Choć wykonywane za pośrednictwem natywnych usług w myśl polegania na LOLBins (Living-off-the-land Binaries). Ich nagromadzenie może wskazywać na aktywność wiążącą się z działalnością atakującego w systemie.

Indicators of Compromise (IoC)

Pliki

Dokumentacja.rar
SHA256: 336e78c28e49944b8297223669695b7560c1404c58b7b4fcd50f80cf6f69c89b

Wezwanie-krk4205342026.pdf:.._.._.._.._.._AppData_Roaming_Microsoft_Windows_Start Menu_Programs_Startup_Built.exe
SHA256: 832cf45712414b072a255bda128b9e248f344601cda550ed273bc43f32cdadd8

Wezwanie-krk4205342026.pdf
SHA256: 40cf48f8a78339d06eb6ad86bce442554163a78626692755b80c9466a571ceef

Domeny

5euv5g5fyjgjftft[.]xyz

Źródła i odniesienia

https://cloud.google.com/blog/topics/threat-intelligence/exploiting-critical-winrar-vulnerability
https://www.welivesecurity.com/en/eset-research/update-winrar-tools-now-romcom-and-others-exploiting-zero-day-vulnerability/
https://www.broadcom.com/support/security-center/protection-bulletin/vortex-stealer

The post Podatność w WinRAR i infostealer w Pythonie appeared first on CERT Orange.

Wektorem ataku w przypadku opisywanego oszustwa na fałszywe kasyna jest wiadomość SMS. W polu „nadawca” oszuści wpisują różne nadpisy, które mogą – ale nie muszą – kojarzyć się z hazardem. Treść zapowiada, że czeka na nas nagroda – wystarczy kliknąć w link (znakami „x” zastąpiliśmy 6-cyfrowy kod alfanumeryczny):

Niesamowite nagrody (wcale nie) czekają!

Gdy przejdziemy na docelową stronę trzeba „rozpocząć zakręcanie” jak proponuje wyskakujące okienko. Nie podajemy adresu konkretnej strony, bowiem nie miałoby to sensu. Po internecie krążą tysiące podobnych, nierzadko identycznych witryn. Jedne znikają, drugie się pojawiają.

Warto zwrócić uwagę na dziwną formę wykrzykników. To styl charakterystyczny dla języka hiszpańskiego. Może to dowodzić, że sprawcy są Hiszpanami, bądź używają szablonu przygotowanego pod kątem ofiar z Półwyspu Iberyjskiego. Dowodzi tego też ekran, który pojawia się wraz z kołem fortuny:

Treść na powyższym ekranie to – w wolnym tłumaczeniu – „Zakręć by wygrać”. Kwotą podana jest ponownie w sposób charakterystyczny dla kultury hiszpańskojęzycznej (poprzedzona symbolem waluty). Warto zwrócić uwagę na prawy dolny róg i „Piotra”, który zarobił powitalne 850 PLN. Gdy sami zakręcimy – za pierwszy razem się nie udaje (to standard w tego typu oszustwach), za drugim razem „wzbogaciliśmy się” o 200 „Darmowe Obroty”

by w następnym kroku trafić wymarzonego jackpota. Kolejna uwaga – polskie znaki diakrytyczne są małe, a reszta wielka. A nam zaproponowano odbiór naszego pakietu powitalnego.

Teoretycznie powinno wystarczyć kliknięcie w żółty przycisk na dole. Po kliknięciu jednak…

Przez Telegram na fałszywe kasyna

…trafiamy na komunikator Telegram. Witryna telegrambonuses[.]com jest pośrednikiem, który ma nam pozwolić dołączyć do kanału Królestwo Jackpotów.

Opis kanału mógłby sugerować, że jesteśmy o krok od wielkich pieniędzy. Dołączmy zatem do kanału.

Kolejna rzecz na którą warto zwrócić uwagę. Na wcześniejszym ekranie kanał miał mieć 3278 subskrybentów, tymczasem po wejściu okazuje się, że jest ich jednak zaledwie 63.

Gdy klikniemy łącze na końcu wpisu z telegramowego kanału, trafiamy na docelową stronę WWW:

Wybieramy kraj, podajemy dane rejestracyjne. I oczywiście wybieramy dostępną metodę płatności, musimy bowiem mieć za co zagrać w kasynie.

Co się stało z zapowiadaną premią 1500 złotych? Gdy weszliśmy na kanał na Telegramie, okazało się, że dostaniemy nie 1500 PLN tylko „do 2000€”. I nie tak po prostu (co sugerowałaby sytuacja z początku tego tekstu) tylko jako pomnożenie o 100% naszej pierwszej wpłaty.

Nie tak miało być? Prawda. Ale od początku piszemy, że to fałszywe kasyna. Nie prawdziwe.

BLIK pozwala na kolejny krok

Jaką formę wpłaty wybrać? Zdecydowaliśmy się na BLIK, bowiem specyfika Polskiego Standardu Płatności pozwala sprawdzić, dokąd miałyby trafić pieniądze zanim potwierdzimy transakcję. W przypadku karty – zobaczylibyśmy dane kontrahenta na wyciągu. Pierwszy ekran to operator płatności (Payment Gateway),

kolejny to serwis docelowy (voucherek[.]pl)

co potwierdza monit BLIK w aplikacji bankowej:

Vaallis sp. z o.o. to właściciel usługi Voucherek. Na głównej stronie serwisu czytamy o nim:

Kody i Doładowania w 30 sekund! Voucher, karty podarunkowe i doładowania GSM. Błyskawiczna dostawa po płatności.

Jak to czyta sieciowy oszust?

Idealna metoda na wypranie pieniędzy. Kupię kody/karty, sprzedam od razu w sieci za nieco taniej. Easy money!

W opisywanym modus operandi przestępcy nie próbują się nawet maskować, podstawiając np. wyglądającą na pierwszy rzut oka rzetelnie nazwę sklepu. Tak jak w przypadku BLIK-a, tak przy użyciu karty płatniczej ofiara na wyciągu zobaczy, że nie wpłacała pieniędzy na kasyno „Magius 1234”. Ona po prostu kupiła oszustom karty podarunkowe.

Jak nie dać się oszukać na fałszywe kasyna?

Przede wszystkim miej świadomość, że na końcu kasyno zawsze wygrywa. Pamiętaj, że na dzień publikacji tego materiału jedyne legalne kasyno online w rozumieniu prawa Rzeczypospolitej Polskiej prowadzi Totalizator Sportowy sp. z o.o. No i nie daj się złapać na SMS-a, że gdzieś czekają na Ciebie jakieś pieniądze! W miejscu, w którym nigdy Cię nie było, za linkiem, który wygląda jak losowy zlepek liter.

Orange Polska bierze udział w finansowanym przez Unię Europejską projekcie ThreatChase (ThreatChase – Open Platform for Protection against Phishing). Celem projektu jest stworzenie i wprowadzenie platformy wspomagającej strukturyzację danych w zakresie phishingowych adresów i domen oraz proaktywnie zapobiegającej skutkom ataków phishingowych. Obserwuj ThreatChase na LinkedIn.

The post Uważaj na fałszywe kasyna! Wyjaśniamy na czym polega oszustwo appeared first on CERT Orange.

Opracowanie obejmuje charakterystykę ekosystemu SpyNote, jego architekturę operacyjną, model dystrybucji oraz zaplecze operatorskie, ze szczególnym uwzględnieniem panelu administracyjnego i mechanizmu budowania spersonalizowanych plików APK.

Kontekst zagrożenia i ewolucja SpyNote

W ostatnich latach obserwuje się systematyczny wzrost zagrożeń wymierzonych w urządzenia mobilne, w szczególności w ekosystem Android. Smartfony, będące nośnikiem zarówno danych prywatnych, jak i służbowych, stały się atrakcyjnym celem dla cyberprzestępców oraz aktorów prowadzących operacje szpiegowskie. Jednym z przykładów długotrwałego i ewoluującego zagrożenia w tym obszarze jest malware SpyNote, znany również pod nazwami pochodnymi, takimi jak CypherRat czy SpyMax.

SpyNote jest rodziną złośliwego oprogramowania typu RAT, która od lat funkcjonuje w ekosystemie zagrożeń mobilnych. Pomimo publicznej dostępności kreatora oraz relatywnie długiej historii, SpyNote pozostaje aktywnie wykorzystywany w bieżących kampaniach, zarówno o charakterze masowym jak i ukierunkowanym. W ostatnim okresie zaobserwowano również jego użycie w operacjach przypisywanych grupom APT, co znacząco podnosi poziom ryzyka związanego z tą rodziną malware.

Celem niniejszego raportu jest przedstawienie ogólnej charakterystyki SpyNote, jego modelu operacyjnego oraz sposobów dystrybucji, a następnie przejście do analizy technicznej wybranych, najnowszych próbek wykorzystywanych w aktualnych kampaniach.

Charakterystyka SpyNote jako Android RAT

Złośliwe oprogramowanie klasy RAT stanowi jedno z najbardziej rozpowszechnionych i trwałych zagrożeń dla urządzeń mobilnych. W szczególności platforma Android – ze względu na swoją powszechność oraz otwartą architekturę dystrybucji aplikacji – jest celem licznych kampanii złośliwego oprogramowania, których celem jest kradzież danych, kontrola urządzeń końcowych oraz nadużycia finansowe. Wśród aktywnych rodzin złośliwego oprogramowania mobilnego szczególną pozycję zajmuje SpyNote – znany od kilku lat Android RAT, który stał się fundamentem dla kolejnych publicznie dostępnych narzędzi typu RAT oraz ich modyfikacji.

SpyNote (nazywany także w środowisku underground Spymax lub SpyNote/Spymax RAT) pojawił się pierwotnie jako komercyjny lub półkomercyjny Android RAT, oferujący pełną zdalną kontrolę nad zainfekowanym urządzeniem. Charakterystycznym momentem w historii tego oprogramowania był wyciek kodu źródłowego wersji 6.4 w 2020 roku, co spowodowało szerokie rozpowszechnienie narzędzia i umożliwiło tworzenie licznych pochodnych (tzw. forków) oraz wariantów przez różne grupy cyberprzestępcze i osoby trzecie. Dzięki temu kod SpyNote stał się punktem wyjścia dla szeregu nowszych narzędzi RAT budowanych przez społeczność hackerską, które następnie były dystrybuowane w modelu Malware-as-a-Service (MaaS) przez niezależnych operatorów.

W literaturze technicznej oraz raportach threat intelligence istnieją także odniesienia łączące SpyNote z innymi narzędziami o podobnym sposobie działania. Przykładem jest Craxs RAT, który w analizach branżowych [2], jest opisywany jako pochodna lub wariant SpyNote/SpyMax – wykorzystujący jego kod bazowy i rozbudowany o dodatkowe funkcje oraz mechanizmy sterowania. W tym przypadku kod SpyNote został użyty i rozbudowany przez autora o pseudonimie EVLF, który od 2022 roku rozwijał i dystrybuował Craxs RAT za pośrednictwem kanałów takich jak Telegram, reklamując funkcje rozbudowanego Android RAT o własnych możliwościach sterowania i kontroli urządzenia.

Z punktu widzenia zagrożeń SpyNote nie jest jednorodnym narzędziem o stałym zestawie możliwości. Znane są różne warianty tego RAT, oznaczane literowo i generacyjne (np. SpyNote.A, SpyNote.B, SpyNote.C), które w zależności od kampanii przyjmują odmienne taktyki działania i maskowania. Ich cechą wspólną jest szeroki zakres funkcji inwigilacyjnych i zdalnej kontroli, co czyni SpyNote poważnym narzędziem w arsenale operatorów malware.

Należy podkreślić, że użycie SpyNote i jego pochodnych nie ogranicza się wyłącznie do szeroko rozumianej cyberprzestępczości finansowej. Chociaż wiele kampanii związanych z tymi narzędziami ma charakter masowy i jest ukierunkowanych na kradzież danych, oszustwa finansowe lub phishing aplikacyjny, jego funkcjonalność pozwala na wykorzystywanie narzędzia do bardziej ukierunkowanych operacji inwigilacyjnych. Oznacza to, że zarówno grupy cyberprzestępcze, jak i potencjalnie threat aktorzy typu APT (Advanced Persistent Threat) lub inne grupy o motywacjach szpiegowskich mogą adaptować to oprogramowanie do własnych celów, rozszerzając jego moduły lub łącząc go z innymi komponentami malware w ramach bardziej złożonych kampanii. Z raportów threat intelligence wynika, że grupy takie jak OilRig (APT34), APT-C-37 (Pat-Bear) czy Kimsuky w swoim portfolio narzędziowym miały SpyNote w kampaniach przeciwko ważnym celom (tzw. High Value Asset).

Model dystrybucji i wykorzystanie operacyjne (MaaS)

Dystrybucja SpyNote oraz jego pochodnych (w tym Craxs RAT) opiera się w przeważającej mierze na modelu MaaS, który od lat stanowi jeden z kluczowych mechanizmów skalowania cyberprzestępczości. Model ten zakłada oddzielenie roli autora narzędzia od roli operatora kampanii – twórcy dostarczają gotowe oprogramowanie, buildery oraz infrastrukturę sterującą, natomiast użytkownicy końcowi odpowiadają za jego faktyczne wykorzystanie i dystrybucję.

Wspomniany już wcześniej wyciek kodów źródłowych umożliwił jego swobodną modyfikację, rozwój własnych forków oraz integrację z innymi komponentami złośliwego oprogramowania. W praktyce doprowadziło to do fragmentacji ekosystemu SpyNote, w którym funkcjonuje wiele wariantów różniących się detalami implementacyjnymi, lecz zachowujących wspólną architekturę i zestaw funkcji charakterystycznych dla tej rodziny RAT.

Narzędzie to było aktywnie promowane w zamkniętych i półotwartych kanałach komunikacyjnych, głównie w serwisach takich jak Telegram. Autorzy oferowali nie tylko sam malware ale również pełne zaplecze operatorskie, obejmujące kreator złośliwych aplikacji, panel administracyjny oraz instrukcje dotyczące omijania zabezpieczeń systemu Android. Takie podejście znacząco obniżało barierę wejścia dla nowych operatorów i umożliwiało szybkie uruchamianie kampanii infekcyjnych bez konieczności posiadania zaawansowanych kompetencji technicznych.

Z perspektywy technicznej dystrybucja złośliwych aplikacji opiera się głównie na trojanizowanych plikach APK (pakiet instalacyjny aplikacji dla systemu Android), które podszywają się pod legalne aplikacje mobilne. Najczęściej są to przeglądarki internetowe, aplikacje bankowe, kurierskie, komunikatory, narzędzia VPN lub aplikacje powiązane z aktualnymi wydarzeniami społecznymi i ekonomicznymi. Pliki te są rozpowszechniane poza oficjalnym sklepem Google Play, m.in. za pośrednictwem stron phishingowych, bezpośrednich linków do pobrania, fałszywych reklam oraz wiadomości SMS i e-mail zawierających odnośniki do instalatorów.

Istotnym elementem modelu dystrybucji jest wykorzystanie socjotechniki do nakłonienia użytkownika do ręcznego zainstalowania aplikacji oraz nadania jej szerokich uprawnień systemowych. Mechanizm ten jest kluczowy, ponieważ SpyNote nie posiada wektorów infekcji wykorzystujących exploity ani zdalne wykonanie kodu (RCE). Operatorzy kampanii często instruują ofiary, aby wyłączyły mechanizmy ochronne Androida, takie jak Google Play Protect, lub zezwoliły na instalację aplikacji z nieznanych źródeł. W niektórych kampaniach stosowane są również techniki bardziej zaawansowane, takie jak przekierowywanie do odpowiedniego pliku w zależności od typu urządzenia, ukrywanie linków z wykorzystaniem kodów QR czy wykorzystanie aplikacji-loaderów, które dopiero w drugim etapie pobierają lub odszyfrowują właściwy payload SpyNote.

Model MaaS sprzyja również decentralizacji infrastruktury sterującej. Każdy operator może wykorzystywać własne serwery C2, często hostowane u różnych dostawców lub ukryte za usługami dynamicznego DNS. Niektóre warianty wspierają również fallback C2 oraz dynamiczną zmianę adresów za pomocą DNS-over-HTTPS. W efekcie powstaje rozproszony ekosystem kampanii, które mogą wydawać się niezależne, mimo że korzystają z tego samego lub bardzo zbliżonego kodu malware. Taka fragmentacja znacząco utrudnia blokowanie zagrożenia na poziomie infrastruktury oraz przypisywanie aktywności do konkretnych aktorów.

Zaplecze operatorskie: panel administracyjny i builder

Integralnym elementem ekosystemu SpyNote jest publicznie dostępny panel administracyjny (C2 panel), oferowany za pośrednictwem oficjalnej strony projektu. Panel ten stanowi centralny punkt zarządzania zainfekowanymi urządzeniami i odgrywa kluczową rolę w operacyjnym wykorzystaniu tego narzędzia. Z perspektywy technicznej i funkcjonalnej jest to klasyczny interfejs C2, udostępniający operatorowi pełen wgląd w aktywność ofiar oraz możliwość wykonywania poleceń w czasie rzeczywistym.

Zacznijmy od witryny projektu. Panel administracyjny SpyNote prezentowany jest jako „zaawansowane narzędzie do zdalnej administracji Androida”, jednak zakres oferowanych funkcji jednoznacznie odpowiada charakterystyce złośliwego oprogramowania typu RAT. Deklarowanie narzędzia jako „remote admin tool” to standardowa technika marketingowa pomniejszająca potencjalne konsekwencje prawne dla autorów. Interfejs umożliwia operatorowi monitorowanie i kontrolę urządzeń z systemem Android w szerokim zakresie, obejmującym zarówno pasywne pozyskiwanie danych jak i aktywne oddziaływanie na system ofiary. Funkcje są dostępne z poziomu jednej konsoli zarządzającej i nie wymagają bezpośredniego dostępu fizycznego do urządzenia.

Rys. 1. Serwis „projektu SpyNote” – notka informacyjna.

Do kluczowych możliwości panelu administracyjnego należy zdalny podgląd ekranu urządzenia w czasie rzeczywistym, wraz z możliwością interakcji i sterowania interfejsem systemu. Funkcja ta pozwala operatorowi obserwować bieżącą aktywność użytkownika: w tym uruchamiane aplikacje, wprowadzane dane oraz wyświetlane treści. Panel umożliwia również zdalne odblokowanie ekranu urządzenia, co w praktyce pozwala na przejęcie kontroli nad telefonem nawet w sytuacji, gdy jest on zabezpieczony mechanizmami blokady (odblokowanie ekranu możliwe jest wyłącznie dzięki nadaniu uprawnień Accessibility Service, a nie przez przełamanie mechanizmu blokady).

Istotnym elementem funkcjonalnym jest zdalny dostęp do sensorów urządzenia, w tym mikrofonu i kamery. Panel umożliwia uruchamianie nagrywania dźwięku oraz obrazu bez wiedzy użytkownika, a także podgląd obrazu z kamery w czasie rzeczywistym. Funkcje te w połączeniu z mechanizmami ukrywania aktywności malware pozwalają na prowadzenie długotrwałej i dyskretnej inwigilacji.

Panel administracyjny oferuje również rozbudowane narzędzia do zarządzania danymi przechowywanymi na urządzeniu. Operator ma dostęp do eksploratora plików umożliwiającego przeglądanie, pobieranie oraz usuwanie danych, a także do modułów pozwalających na odczyt wiadomości SMS, historii połączeń, list kontaktów oraz zapisanych kont i haseł. Dodatkowo dostępny jest moduł keyloggera, umożliwiajcy przechwytywanie wprowadzanych danych, w tym potencjalnie danych uwierzytelniających do aplikacji bankowych i korporacyjnych.

Rys. 2. Serwis „projektu SpyNote” – funkcjonalności narzędzia

Jednym z bardziej zaawansowanych komponentów panelu administracyjnego jest moduł lokalizacji, oferujący śledzenie położenia urządzenia w czasie rzeczywistym z wykorzystaniem danych GPS. Funkcja ta prezentowana jest w formie interaktywnej mapy z trójwymiarową wizualizacją, umożliwiającą dokładne monitorowanie przemieszczania się ofiary. W połączeniu z innymi modułami pozwala to na korelację aktywności użytkownika z jego fizyczną lokalizacją. Stałe śledzenie urządzenia jest możliwe dzięki połączeniu uprawnień do lokalizacji oraz usługi działającej w tle, co oznacza, że użytkownik otrzymuje minimalne alerty systemowe lub nie otrzymuje żadnych.

Panel SpyNote zawiera również funkcje typowe dla narzędzi administracyjnych o charakterze ofensywnym, takie jak dostęp do terminala systemowego. Moduł ten umożliwia wykonywanie poleceń na zainfekowanym urządzeniu, uzyskiwanie informacji o konfiguracji systemu oraz potencjalne wdrażanie dodatkowych komponentów. Tego typu funkcjonalność znacząco zwiększa elastyczność operacyjną narzędzia i pozwala operatorowi na dynamiczne dostosowywanie działań do konkretnej ofiary.

Z punktu widzenia modelu biznesowego panel administracyjny SpyNote jest oferowany w ramach płatnych licencji czasowych oraz dożywotnich. Dostępne są pakiety obejmujące kilkumiesięczne licencje testowe, średnioterminowe oraz jednorazowy zakup zapewniający stały dostęp do narzędzia. Charakterystycznym elementem jest akceptowanie płatności wyłącznie w kryptowalutach, takich jak Bitcoin, Ethereum czy USDT, co jest typowym rozwiązaniem stosowanym w środowisku narzędzi o podwyższonym ryzyku prawnym i operacyjnym.

Rys. 3. Serwis „projektu SpyNote” – cennik

Operatorzy SpyNote deklarują możliwość sprzedaży niestandardowych wersji narzędzia, w tym modyfikacji kodu źródłowego oraz świadczenia „usług specjalnych” na żądanie klienta. Z perspektywy analitycznej wskazuje to na wysoki poziom elastyczności oraz gotowość do dostosowywania narzędzia do konkretnych scenariuszy użycia, w tym potencjalnie do operacji ukierunkowanych.

C2 oraz Builder

Opisany powyżej panel stanowi centralny element całego ekosystemu tego malware i odpowiada za zarządzanie cyklem życia infekcji, od generowania złośliwej aplikacji po bieżącą kontrolę nad zainfekowanymi urządzeniami. W zależności od wersji SpyNote oraz jego licznych forków interfejs panelu może różnić się wizualnie oraz funkcjonalnie. Jednak we wszystkich obserwowanych wariantach zachowany jest wspólny zestaw podstawowych mechanizmów operacyjnych. Różnice wynikają z faktu, iż narzędzie było wielokrotnie modyfikowane i adaptowane przez różne grupy hakerskie.

Rys. 4. Panel administracyjny SpyNote – zarządzanie infekcjami

Niezależnie od wariantu kluczowym komponentem panelu administracyjnego jest moduł buildera, który umożliwia generowanie dopasowanych i unikalnych próbek malware w postaci plików APK. Builder pozwala operatorowi zdefiniować podstawowe parametry złośliwej aplikacji, w tym nazwę wyświetlaną użytkownikowi, nazwę pakietu oraz identyfikatory komponentów, co umożliwia maskowanie malware jako legalnego oprogramowania. Na tym etapie określana jest również nazwa procesu oraz dane infrastruktury sterującej. W szczególności adres IP lub domena serwera C2 oraz port komunikacyjny, z którym aplikacja będzie się łączyć po uruchomieniu na urządzeniu ofiary. Niektóre wersje buildera wspierają generowanie wielu wariantów tej samej próbki (polimorfizm), co znacząco utrudnia klasyczne wykrywanie sygnaturowe.

Rys. 5. Panel administracyjny SpyNote – builder-konfiguracja

Istotnym elementem procesu budowania aplikacji jest możliwość wyboru funkcjonalności włączanych w wygenerowanej próbce. Panel udostępnia operatorowi zestaw przełączników odpowiadających poszczególnym modułom operacyjnym, takim jak dostęp do kamery, mikrofonu, lokalizacji, wiadomości SMS, kontaktów czy plików. Dodatkowo możliwe jest wymuszenie żądania uprawnień specjalnych, w tym uprawnień do wyświetlania nakładek ekranowych, ignorowania optymalizacji baterii oraz blokowania powiadomień systemowych. Szczególnie istotną opcją jest możliwość automatycznego uzyskiwania dodatkowych uprawnień po aktywacji usługi Accessibility, co w praktyce umożliwia dalszą eskalację kontroli nad systemem bez bezpośredniego udziału użytkownika.

Rys. 6. Panel administracyjny SpyNote – builder-konfiguracja

Z perspektywy technicznej panel administracyjny SpyNote jest aplikacją desktopową napisaną w technologii .NET. Do procesu budowy plików APK wykorzystywane są narzędzia zewnętrzne, w szczególności apktool, który służy do dekompilacji, modyfikacji oraz ponownej kompilacji pakietów Android. Integracja buildera z apktool pozwala operatorom generować nowe warianty bez znajomości programowania, automatyzując wstrzyknięcie konfiguracji oraz ukrycie kodu RAT.

Rys. 7. Panel administracyjny SpyNote – kompilacja pliku apk.

Po uruchomieniu panel administracyjny otwiera port nasłuchowy i oczekuje na połączenia przychodzące od zainfekowanych urządzeń. W momencie, gdy wygenerowana aplikacja zostanie zainstalowana na urządzeniu ofiary i uruchomiona, nawiązuje ona połączenie z serwerem C2 zdefiniowanym w procesie budowania. Po zestawieniu połączenia urządzenie jest rejestrowane w panelu jako nowa ofiara, a operator uzyskuje pełny wgląd w jej stan oraz możliwość zdalnego zarządzania jej funkcjonalnościami.

Panel umożliwia dynamiczne aktywowanie poszczególnych modułów malware w odpowiedzi na bieżące potrzeby operatora. Obejmuje to między innymi uruchamianie podglądu ekranu, przechwytywanie obrazu z kamery, nagrywanie dźwięku, śledzenie lokalizacji, przeglądanie plików oraz monitorowanie komunikacji. Funkcje te mogą być aktywowane w czasie rzeczywistym, co pozwala na elastyczne prowadzenie działań inwigilacyjnych oraz dostosowywanie ich do zachowania ofiary.

Analiza wygenerowanych aplikacji APK wskazuje, że proces budowania nie polega wyłącznie na prostym osadzeniu adresu C2. Obejmuje również selektywne włączanie lub wyłączanie komponentów manifestu oraz usług działających w tle. W rezultacie różne próbki SpyNote mogą znacząco różnić się zakresem żądanych uprawnień oraz zachowaniem w systemie, mimo że zostały wygenerowane z tego samego panelu administracyjnego. Mechanizm ten utrudnia detekcję sygnaturową oraz sprzyja powstawaniu dużej liczby wariantów tego samego malware.

Rys. 8. Panel administracyjny SpyNote – obsługa zainfekowanego urządzenia.

Z perspektywy operacyjnej panel administracyjny SpyNote pełni jednocześnie rolę narzędzia do generowania malware, serwera sterującego oraz konsoli operatorskiej. Taka konsolidacja funkcji w połączeniu z prostotą obsługi i szerokimi możliwościami konfiguracji czyni SpyNote narzędziem atrakcyjnym zarówno dla cyberprzestępców jak i dla aktorów prowadzących bardziej ukierunkowane operacje, w tym działania o charakterze szpiegowskim.

Analiza techniczna próbek SpyNote

Analiza techniczna została przeprowadzona na wybranych próbkach SpyNote pozyskanych w ramach bieżących kampanii oraz z publicznie dostępnych repozytoriów próbek złośliwego oprogramowania. Jej celem było określenie aktualnych mechanizmów infekcji, trwałości, komunikacji z infrastrukturą C2 oraz zakresu funkcji realizowanych na zainfekowanych urządzeniach z systemem Android.

Proces działania SpyNote rozpoczyna się na etapie instalacji aplikacji w postaci pakietu instalacyjnego APK. Już na tym etapie w pliku AndroidManifest.xml deklarowany jest szeroki zakres uprawnień, jednak ich faktyczne przyznanie i aktywacja następują stopniowo w trakcie dalszych faz infekcji, zgodnie z obowiązującym w systemie Android modelem runtime permissions.

Pierwsze uruchomienie aplikacji powoduje start głównej aktywności, odpowiedzialnej za przygotowanie środowiska operacyjnego malware. W ramach tego etapu inicjalizowane są komponenty zbierające kluczowe informacje o urządzeniu: wersja systemu Android, model sprzętu, identyfikatory systemowe oraz poziom zabezpieczeń. Informacje te stanowią podstawę doboru dalszych technik eskalacji uprawnień.

Rys. 9. Przykład ekranu – akceptacja Accessibility Service (na przykładzie aplikacji Roblox Modded.apk)

Kolejnym etapem działania malware jest stopniowa eskalacja uprawnień, realizowana poprzez sekwencję dedykowanych aktywności mających na celu skłonienie użytkownika do nadania aplikacji kolejnych uprawnień o krytycznym znaczeniu. Mechanizm ten opiera się na socjotechnice oraz wykorzystaniu systemowych okien typu overlay. W pierwszej kolejności użytkownik nakłaniany jest do przyznania dostępu do usług ułatwień dostępu (Accessibility Service), co stanowi punkt przełomowy w schemacie działania SpyNote. Uzyskanie tego uprawnienia umożliwia malware monitorowanie interakcji użytkownika z systemem oraz symulowanie zdarzeń wejścia, prowadząc do dalszej automatyzacji eskalacji uprawnień.

Posiadając już uprawnienia Accessibility Service SpyNote inicjuje kolejne etapy przejmowania kontroli nad systemem. W sposób półautomatyczny wymuszane jest nadanie uprawnień administratora urządzenia (Device Administrator), aktywacja własnej klawiatury systemowej (technika keyloggerów mobilnych) oraz zgoda na wykonywanie operacji w tle bez ograniczeń mechanizmów oszczędzania energii. W niektórych wariantach obserwuje się również próby uzyskania zgody na instalowanie oraz usuwanie pakietów aplikacji, co umożliwia dalszą rozbudowę funkcjonalności malware lub instalację dodatkowych komponentów.

Równolegle do procesu eskalacji uruchamiane są mechanizmy trwałości. SpyNote rejestruje komponenty typu BroadcastReceiver, skonfigurowane do obsługi wybranych zdarzeń systemowych: restart urządzenia (BOOT_COMPLETED), zmiana stanu ekranu, podłączenie zasilania oraz zdarzenie USER_PRESENT (sygnalizujące odblokowanie urządzenia przez użytkownika). Dzięki temu złośliwe usługi są automatycznie wznawiane po restarcie systemu lub aktywowane w momencie interakcji użytkownika z urządzeniem, co zwiększa niezawodność działania malware i ogranicza jego widoczność operacyjną.

Po uzyskaniu kluczowych uprawnień następuje inicjalizacja pełnego zestawu funkcji operacyjnych. Uruchamiane są usługi odpowiedzialne za monitorowanie lokalizacji, przechwytywanie dźwięku i obrazu, rejestrowanie wprowadzanych danych oraz zbieranie informacji o aktywności aplikacji. W zależności od konfiguracji malware część tych funkcji działa w trybie pasywnym, oczekując na polecenia z serwera sterującego, inne natomiast mogą być aktywowane automatycznie w odpowiedzi na określone zdarzenia systemowe.

Rys. 10. Zdekompilowana i zdekodowana klasa SpyNote – konfiguracja sieciowa

Ostatnim etapem schematu działania jest nawiązanie komunikacji z infrastrukturą C2 operatora kampanii. SpyNote inicjuje połączenie sieciowe z serwerem C2, przekazując wcześniej zgromadzone informacje identyfikujące urządzenie oraz potwierdzając gotowość do odbioru poleceń. Komunikacja realizowana jest cyklicznie lub zdarzeniowo, w zależności od konfiguracji, i służy zarówno do przesyłania danych wykradzionych z urządzenia jak i do odbierania instrukcji sterujących dalszym działaniem malware (wspólny kanał danych oraz zarządzania). W zaawansowanych wariantach komunikacja może być dodatkowo ukrywana poprzez mechanizmy szyfrowania lub wykorzystanie tunelu VPN, co utrudnia jej wykrywanie w warstwie sieciowej.

Całość schematu działania SpyNote wskazuje na przemyślaną, wieloetapową architekturę, której celem jest stopniowe przejmowanie kontroli nad urządzeniem ofiary przy jednoczesnym minimalizowaniu ryzyka wykrycia. Połączenie socjotechnik, nadużyć mechanizmów systemowych Androida oraz centralnego sterowania z poziomu C2 czyni SpyNote narzędziem zdolnym do długotrwałej i dyskretnej inwigilacji.

Komunikacja C2

Przeanalizowany komponent <package_name>.run.Socket odpowiada za pełną obsługę komunikacji sieciowej między zainfekowanym urządzeniem a serwerem sterującym SpyNote. Implementacja ta stanowi centralny element architektury komunikacji z C2 i została zaprojektowana w sposób umożliwiający stabilną, długotrwałą dwukierunkową komunikację przy jednoczesnym zachowaniu elastyczności w zakresie przesyłanych poleceń i danych. Długotrwałe utrzymywanie połączenia TCP odróżnia SpyNote od większości mobilnych RAT, które korzystają z krótkich połączeń typu “pull”.

Po stronie klienta komunikacja realizowana jest przy użyciu asynchronicznych kanałów sieciowych (AsyncChannel) opartych o Java NIO (Non-blocking IO), z wykorzystaniem gniazd TCP. Podczas inicjalizacji połączenia malware konfiguruje kluczowe opcje gniazd sieciowych, takie jak TCP_NODELAY oraz SO_KEEPALIVE, co wskazuje na dążenie do minimalizacji opóźnień oraz utrzymania sesji przez dłuższy czas. Adres serwera C2 oraz port pobierane są dynamicznie z klasy Support.SocketInfo, co potwierdza, że wartości te są wstrzykiwane na etapie budowania próbki przez panel administracyjny.

Proces zestawiania połączenia realizowany jest w klasie Client.Connect, która podejmuje wielokrotne próby połączenia, uwzględniając obsługę wyjątków sieciowych. W przypadku niepowodzenia malware wprowadza opóźnienie i podejmuje kolejne próby, co pozwala na przetrwanie czasowych problemów z dostępnością infrastruktury C2 lub sieci ofiary. Po pomyślnym zestawieniu połączenia zapisywany jest znacznik czasu, wykorzystywany następnie do monitorowania stanu sesji.

Bezpośrednio po połączeniu, klient wysyła do serwera pakiet inicjalizacyjny zawierający rozbudowany zestaw informacji identyfikacyjnych i telemetrycznych. Dane te obejmują unikalny identyfikator urządzenia, wersję malware, nazwę pakietu aplikacji, nazwy kluczowych klas, informacje o stanie baterii, lokalizacji, blokadzie ekranu oraz szczegóły dotyczące systemu operacyjnego i interfejsu producenta. Pakiet ten rejestruje nową ofiarę w panelu administracyjnym oraz umożliwia operatorowi natychmiastową ocenę wartości przejmowanego urządzenia.

Odbiór danych z serwera realizowany jest w klasie ReceiveData, która implementuje własny, niestandardowy protokół komunikacyjny. Dane przesyłane są w postaci strumienia bajtów, w którym długości poszczególnych segmentów oddzielane są bajtem zerowym. Po odebraniu pełnej ramki dane są dekodowane, opcjonalnie dekompresowane przy użyciu mechanizmu GZIP oraz przekazywane do dalszego przetwarzania. Zdekodowane pakiety trafiają do współdzielonej kolejki Socket.packets, co umożliwia ich asynchroniczną obsługę przez inne wątki. Przetwarzanie poleceń z serwera realizowane jest w klasie IncomingPackets, która cyklicznie pobiera pakiety z kolejki i przekazuje je do metody Client.Data. W tym miejscu następuje interpretacja poleceń na podstawie kluczy logicznych.

Istotnym elementem architektury jest obsługa operacji. SpyNote wykorzystuje równoległe zadania do przeszukiwania systemu plików, pobierania zawartości katalogów oraz wykonywania operacji na plikach multimedialnych, takich jak zrzuty ekranu o zadanych parametrach. Zastosowanie puli wątków umożliwia efektywne wykorzystanie zasobów urządzenia, a jednocześnie pozwala operatorowi na wykonywanie tych operacji w tle bez wyraźnych oznak aktywności dla użytkownika.

Komunikacja z serwerem C2 jest utrzymywana przez dedykowany mechanizm kontroli stanu połączenia zaimplementowany w klasie CheckConnection. Komponent ten cyklicznie wysyła pakiety typu „ping” oraz monitoruje czas bezczynności sesji. W przypadku braku odpowiedzi lub wykrycia problemów z dostępem do internetu malware samodzielnie inicjuje procedurę rozłączenia i ponownego zestawienia połączenia. Mechanizm ten umożliwia utrzymanie ciągłości kampanii nawet w warunkach niestabilnej sieci mobilnej. Dodatkowo okresowo przekazywane są aktualne informacje o stanie baterii, ładowaniu, lokalizacji oraz blokadzie ekranu, co umożliwia operatorowi bieżące monitorowanie kontekstu operacyjnego ofiary. Dane te mogą także służyć jako wyzwalacze operacyjne – np. aktywacja nagrywania po podłączeniu zasilania, co minimalizuje ryzyko wzrostu zużycia baterii i wykrycia przez użytkownika.

Całość logiki sterującej pracą poszczególnych komponentów komunikacyjnych została skupiona w klasie Controller, która koordynuje uruchamianie, zatrzymywanie oraz ponowne inicjalizowanie zadań odpowiedzialnych za połączenie, odbiór danych, przetwarzanie poleceń i kontrolę sesji. Mechanizm ten zapewnia wysoką odporność na błędy oraz pozwala na automatyczne odzyskiwanie połączenia w przypadku zakłóceń, co jest charakterystyczne dla dojrzałych rodzin złośliwego oprogramowania. W niektórych wariantach zaobserwowano dodatkowe mechanizmy ukrywania komunikacji, takie jak niestandardowe nagłówki, zaciemnione identyfikatory sesji lub wykorzystanie tunelowania przez HTTPS, co znacząco utrudnia monitoring ruchu sieciowego oraz korelację zdarzeń.

Analiza komponentu odpowiedzialnego za komunikację jednoznacznie wskazuje, że SpyNote wykorzystuje własny protokół C2 oparty o długotrwałe sesje TCP, z obsługą kompresji, dynamicznego kodu oraz wielowątkowego przetwarzania poleceń. Architektura ta została zaprojektowana z myślą o długotrwałej kontroli nad zainfekowanym urządzeniem, elastycznym rozszerzaniu funkcjonalności oraz minimalizowaniu ryzyka utraty sesji.

Techniki obfuskacji

SpyNote stosuje szereg wyrafinowanych technik obfuskacji i ochrony kodu, które ewoluowały od prostych metod do zaawansowanych mechanizmów mających na celu ominięcie nowoczesnych systemów zabezpieczeń. Podczas gdy najwcześniejsze wersje i publicznie dostępne kreatory (buildery) często nie posiadały żadnych zabezpieczeń, współczesne warianty (takie jak SpyNote.C czy V7) są wysoce skomplikowane.

Rys. 11. Konfiguracja widoczna w zdekompilowanym pliku (wersja kodowana)

Niektóre warianty działają jako droppery, gdzie pierwszy plik APK służy jedynie do zainstalowania drugiego payloadu ukrytego w pliku DEX wewnątrz zasobów aplikacji. Parametry połączenia z serwerem są często zaszyte wewnątrz plików DEX, co stanowi kolejną warstwę ukrycia. Przykładami stosowania takich technik są kampanie grup APT (np. grupy APT43), gdzie właściwy kod SpyNote ukryto w folderze /assets pod niepozornymi nazwami plików, jak security.dat czy search.db. Do jego odszyfrowania służy dedykowana biblioteka natywna SILENTKEY (np. libnative-lib.so), która zawiera funkcję decryptFile. Przejście z prostego szyfrowania XOR w języku Java na deszyfrowanie w bibliotece natywnej znacząco ogranicza skuteczność analizy statycznej z wykorzystaniem standardowych narzędzi do dekompilacji DEX.

Malware powszechnie wykorzystuje kodowanie do ukrywania kluczowych informacji konfiguracyjnych, w tym adresów IP serwerów C2, numerów portów oraz kluczy komunikacyjnych. Również dane wykradzione od ofiary (np. przechwycone znaki z klawiatury) są zapisywane i przesyłane w formie zakodowanej, a czasem zaszyfrowanej. W nowszych wariantach spotykane są wielopoziomowe łańcuchy dekodowania, gdzie stringi są deszyfrowane dopiero w momencie użycia. Utrudnia to statyczne mapowanie funkcji.

Najnowsze wersje SpyNote korzystają z komercyjnych pakerów oraz zaawansowanego zaciemniania ciągów znaków. Sprawia to, że kod aplikacji jest nieczytelny dla standardowych dekompilatorów, co utrudnia identyfikację złośliwych funkcji. Często używane są obfuskowane nazw klas i usług (np. klasy o nazwach C71 czy C38), by ukryć złośliwe procesy wśród legalnych usług systemowych. W wielu próbkach obserwuje się także sztuczne wypełniacze kodu (dead code), fałszywe klasy oraz zagnieżdżone bloki try/catch, które utrudniają analizę algorytmów.

Rys. 12. Drzewo klas i metod SpyNote – wersja bez obfuskacji

W zaawansowanych przypadkach kod malware jest deszyfrowany dopiero w momencie uruchomienia i ładowany bezpośrednio do pamięci urządzenia (in-memory execution). Dzięki temu złośliwe moduły nie są widoczne podczas zwykłego skanowania plików na dysku, co pozwala skutecznie omijać mechanizmy takie jak Google Play Protect. Tego typu technika jest stosowana głównie w wariantach wykorzystywanych w ukierunkowanych kampaniach lub tworzonych przez zaawansowanych operatorów – nie jest to funkcja standardowego buildera SpyNote dostępnego publicznie.

Zastosowanie powyższych technik znacząco utrudnia zarówno analizę statyczną, jak i detekcję behawioralną SpyNote.

Podsumowanie

SpyNote stanowi dojrzałe, wielokomponentowe złośliwe oprogramowanie klasy Android RAT. Zostało ono zaprojektowane jako spójny ekosystem obejmujący infrastrukturę C2, panel operatorski, mechanizm generowania spersonalizowanych próbek oraz modularną architekturę po stronie klienta. Taka konstrukcja umożliwia centralne zarządzanie kampaniami oraz precyzyjne dostosowanie zachowania poszczególnych instancji do założeń operacyjnych.

Z perspektywy funkcjonalnej SpyNote łączy mechanizmy pasywnej inwigilacji z aktywnym sterowaniem urządzeniem. Zakres jego możliwości obejmuje m.in. pozyskiwanie danych uwierzytelniających, monitorowanie aktywności użytkownika, dostęp do zasobów systemowych oraz wykonywanie zdalnych poleceń. Kluczowym elementem architektury jest systematyczne nadużywanie usług Accessibility, co umożliwia eskalację uprawnień logicznych oraz automatyzację interakcji z interfejsem systemu bez konieczności uzyskiwania uprawnień root. W praktyce czyni to SpyNote szczególnie efektywnym na współczesnych wersjach Androida, ponieważ omija on większość ograniczeń bezpieczeństwa dotyczących aplikacji bez dostępu do uprawnień systemowych. Cechą charakterystyczną jest również zdolność do utrzymywania stałych sesji TCP, co odróżnia SpyNote od większości mobilnych RAT i komplikuje analizę ruchu.

Model operacyjny SpyNote zakłada przeniesienie logiki konfiguracji na etap budowania próbki. Parametry komunikacji, zakres funkcjonalny oraz zachowanie aplikacji po instalacji definiowane są po stronie panelu operatorskiego, co skutkuje powstawaniem wariantów różniących się zachowaniem i artefaktami technicznymi. Takie podejście znacząco ogranicza skuteczność detekcji sygnaturowej i sprzyja długotrwałemu utrzymaniu dostępu do zainfekowanych urządzeń.

Z punktu widzenia detekcji i reagowania SpyNote reprezentuje klasę zagrożeń charakteryzującą się wysoką integracją z mechanizmami systemowymi Androida, odpornością na restart urządzenia oraz zdolnością do działania w tle w oparciu o zdarzenia systemowe. Zastosowanie własnego protokołu C2 oraz dynamicznego przetwarzania poleceń dodatkowo utrudnia identyfikację infrastruktury i blokowanie komunikacji na poziomie sieciowym.

W konsekwencji SpyNote należy traktować nie jako pojedynczą rodzinę malware w wąskim sensie, lecz elastyczne narzędzie operatorskie, zdolne do adaptacji i do zmian w modelu bezpieczeństwa platformy Android. Współcześnie termin SpyNote obejmuje de facto szeroką rodzinę forków i wariantów o różnym stopniu zaawansowania, z których część znacząco odbiega od oryginalnej wersji 6.4. Ma to istotne znaczenie dla analizy oraz atrybucji kampanii. Jego obecność w krajobrazie zagrożeń powinna być analizowana w kategoriach długofalowych, z naciskiem na detekcję behawioralną, korelację zdarzeń oraz monitorowanie nadużyć mechanizmów systemowych.

Indicators of Compromise (IoC)

Analizowane próbki

sonapk.apk
SHA256: 3cf8bd9828f8fe52867fcb09f3caa59f5ce0aa76ff20cf644807ae76b57c2c86
C2:          tcp://103.61.224[.]102:2323

Gmail.apk
SHA256: 8f09663836bef9fad23b34560dbcb0848e99d66e40787c37d498e7647792d5b6
C2         tcp://103.61.224[.]102:2323

inpost.apk
SHA56: 40d31617f45e8317e9d8fa6e42e67d587bdc546b50fd2197b26ac27b51d037de
C2:          tcp://103.61.224[.]102:3333

Roblox Modded.apk
SHA256: acf2d29c8c65ee2fe57445e672fbee01fa240b0039b66ea507f110468c6c8210
C2:          tcp://144.31.30[.]235:7771

Pozostałe (najnowsze) próbki
SHA256: 6fd37bbd31b52c6312a0c7972d7fe7242dade45f3d8faa2fc548bef2e3400ecd
C2:           tcp://20.82.176[.]195:7771

SHA256: 231b21251d16d17e564a2014765d1de553eb821abd92781b18c94889650a3bf7
C2:          tcp://91.92.251[.]105:12004

SHA256: b29b8bd2d47254de3d7bf21d7610209d3cc4db49cd3e7ba2fd1ea040f49cb6db
C2:          tcp://185.87.254[.]82:2305

SHA256: d9c47a7d7e42402c3ce2dd191ea09e9f7e29b1ee8d78d9aec0a47ed7b4bcdb80
C2:          tcp://mm-includes.gl.at.ply[.]gg:33004

SHA256: 5d4aa3800788f80d2a0b0460574ee3d3403c642b19e294941cd9e59b37aebae5
C2:          tcp://193.161.193[.]99:40920

SHA256: d14fb879a81e6c415146092d2aab8f8c69991828dbebc0ec27363248f9b260c0
C2:          tcp://83.217.209[.]142:1333

SHA256: e21f8722ab3d3557e7b0dda0faca39c517bbf0afd84bf4bbdc92687c9bd58aae
C2:          tcp://tcp.cloudpub[.]ru:48683

Źródła i materiały referencyjne:

1. https://www.mobile-hacker.com/2025/06/05/analysis-of-spyware-that-helped-to-compromise-a-syrian-army-from-within/
2. https://www.group-ib.com/blog/craxs-rat-malware/
3. https://malpedia.caad.fkie.fraunhofer.de/details/apk.spynote
4. https://hunt.io/malware-families/spynote
5. ThreatLabz 2025 Mobile, IoT & OT Threat Report
6. https://app.apkdetect.com/search/?malware=SpyNote

The post SpyNote: kompleksowa analiza złośliwego oprogramowania RAT dla systemu Android appeared first on CERT Orange.

Zastanawiasz się czasem jak to by było, gdyby ktoś mógł się pod Ciebie podszyć? Odbierać Twoje rozmowy i SMS, dostawać na swoje urządzenie Twoje wiadomości autoryzacyjne? Brzmi groźnie, więc jeśli ktoś Ci powie, że właśnie tak się dzieje – może to wywołać bardzo duży stres i spowodować, że dasz się złapać na socjotechniczną sztuczkę. To podstawa działania sieciowych oszustów. Chcą wywołać u nas nerwy tak wielkie, by nie przyszło nam do głowy zastanawiać się, czy to, co nam mówią, ma jakikolwiek sens.

Ostatnio wzrosła liczba zgłoszeń trafiających do CERT Orange Polska o sytuacjach, gdy oszuści „ostrzegają” o rzekomej próbie wymiany Twojej karty SIM. Co zrobić jeśli to do Ciebie trafi wiadomość, która budzi Twój niepokój/wydaje się podejrzana ? Możesz zgłosić ją bezpośrednio do nas, używając przycisku „Zgłoś zagrożenie” na stronie głównej. Poniżej pokażemy Wam schemat takiego przekrętu.

Zaczyna się od telefonu

Pani ze wschodnim akcentem, podając się za pracownika salonu Orange, poinformowała o próbie wymiany mojej karty SIM w salonie Orange

Przedstawiła się jako Anna Jakaś-tam z Orange. Dzwoniła, żeby zweryfikować podejrzaną transakcję na moim koncie polegającą na wydaniu duplikatu karty SIM w salonie Orange w Warszawie

Do klienta z numeru xxx xxx xxx dzwoniła osoba twierdząca, że jest pracownikiem Orange o nazwisku Xxxxxxx i informowała, że na numer klienta została zlecona wymiana karty SIM i teraz połączenia są przekierowania na ten duplikat

Z numeru +48 xxx xxx xxx dzwoni osoba która przedstawia się jako pracownik Orange i twierdzi że w salonie Orange został wydany duplikat karty SIM z wykorzystaniem e-dowodu

To tylko kilka przykładów zgłoszeń, które trafiły do CERT Orange Polska. Co je łączy?

• rozmowa telefoniczna przychodząca
• ostrzeżenie – z dużym naciskiem – o podejrzanej transakcji
• sprecyzowanie, że chodzi o duplikat karty
  • można założyć, że w kolejnym kroku następuje ostrzeżenie o konsekwencjach wpadnięcia Twojej karty SIM w ręce osób trzecich
• powołanie się na salon Orange

Umiejętna presja kluczem do sukcesu oszusta

Ten przekręt – podobnie jak podobne rozpoczynające się od rozmowy telefonicznej – ma niestety sporą szansę na sukces, jeśli oszust dobrze poprowadzi rozmowę. Dlaczego? Mamy tu bowiem:

• ostrzeżenie przed realnym zdarzeniem
• sytuację obiektywnie generującą wysokie ryzyko (przejęcie kontroli nad ruchem telefonicznym i SMS-owym)
• wsparcie się znaną marką (telekom, bank, dostawca prądu, etc.), a w efekcie uwiarygodnienie u ofiary
• często posługiwanie się prawdziwymi danymi ofiar, pozyskanymi z wycieków
• w opisywanym przypadku: powoływanie się na konkretny salon Orange (we analizowanych przypadkach oszuści podawali adres/nazwę nieistniejącego salonu, ale równie dobrze mogą podszyć się pod prawdziwy)

Zadaniem dla dobrze przygotowanego socjotechnika jest tylko poprowadzenie potencjalnej ofiary po ścieżce, odpowiednio dawkując emocje i nie przesadzając z presją. Oszust-specjalista potrafi nawet tak „zakręcić” ofiarą, że ta dojdzie do wniosku, że przestępcę uwiarygadnia nawet fakt, że… wie o jaki numer telefonu chodzi! No tak, wie – przecież właśnie na niego zadzwonił.

Czego chce oszust od Twojej karty SIM?

Twoja SIM-ka go nie interesuje. To tylko przynęta. W jednym ze zgłoszeń analizowanych przez CERT Orange Polska czytamy:

Następnie niby blokują ten duplikat. Twierdzą, że zostały wykradzione dane osobowe i pytają jakie instytucje w związku tym mają poinformować. Następnie z nr +48 xx xxx xx xx dzwoni osoba podająca się za przedstawiciela banku i próbuje wymusić instalację oprogramowania rzekomo do obsługi 2FA. Nie udało się ustalić o jaki program chodzi. Po zapowiedzi zgłoszenia sprawy na policję, dzwoniący stwierdził, że zadzwoni później i rozłączył się.

W innej sytuacji zorientowany klient zapowiedział, że nie zgadza się na wymianę. Od rozmówcy usłyszał, że sytuacja zostanie zgłoszona na policję, a dalsze informacje otrzyma mailem. Generalnie rozmówcy dopytywani o co chodzi, regularnie powtarzali, że to kwestia podejrzanej aktywności/transakcji. Naciskali też na werbalne potwierdzenie, że nie robiły tego ofiary.

Co mogłoby się dziać w kolejnych krokach? W potwierdzonym wariancie mamy próbę przekonania do instalacji nieznanej aplikacji po telefonie „z banku”. W innych, podobnych atakach, często pojawiają się próby wykradzenia poświadczeń logowania do systemu bankowości elektronicznej. Tutaj mogłoby być podobnie. Być może e-mail, którego przyjście oszust zapowiadał, kierowałby do fałszywej strony banku, korzystając z tego, że wcześniejsze aktywności uwiarygodniły przestępcę w oczach ofiary.

Jak wygląda wymiana Twojej karty SIM w Orange

Kartę SIM w Orange najlepiej wymienić samemu. Jeśli dotychczasowa jest aktywna i masz do niej dostęp, zrobisz to przez SMS lub w Mój Orange.

W przypadku gdyby ktoś faktycznie chciał uzyskać nieautoryzowany dostęp do treści związanych z Twoją kartą, zakładamy, że nie będzie miał do niej dostępu (nie będzie mógł np. otrzymać kodu autoryzacyjnego). Wtedy wymiana możliwa jest wyłącznie w salonie Orange. W celu jej wykonania musisz wylegitymować się ważnym dowodem osobistym bądź paszportem.

Ważna wiadomość to fakt, że w procesie wymagana jest weryfikacja PESEL. Dlatego:

• nie możesz wyrobić duplikatu Twojej karty SIM jeśli Twój PESEL jest zastrzeżony
• jeśli ktoś dzwoni do Ciebie i ostrzega, że ktoś taki duplikat właśnie wyrobił – kłamie
• nie zablokowałaś/eś jeszcze PESEL-u – to dobry moment, by zrobić to teraz

Jeśli ktoś do Ciebie dzwoni w takiej sprawie – najlepiej po prostu się rozłączyć. Tym bardziej, jeśli nie masz telefonu w Orange – oszuści mogą dzwonić na losowo wybrane numery. Co robić dalej?

• zadzwoń na nr *100 lub 510 100 100, przedstaw sprawę i poproś konsultanta o sprawdzenie, czy są zanotowane jakieś aktywności związane z Twoim kontem
• jeśli wolisz załatwić sprawę osobiście – tutaj znajdziesz adresy naszych salonów

A przede wszystkim – jak w przypadku wszystkich dotyczących Cię działań w sieci odbiegających od normy, pamiętaj, że:

Im więcej emocji wywołuje wiadomość, która do Ciebie dotarła i im bardziej są silne – tym większe prawdopodobieństwo, że ktoś próbuje Cię oszukać!

The post Uważaj na telefony od oszustów o próbie wymiany Twojej karty SIM appeared first on CERT Orange.

Za analizę tematu wzięliśmy się dzięki jednemu z klientów, który dał znak o podejrzanej aktywności za pośrednictwem formularza „Zgłoś zagrożenie” na naszej stronie. Dzięki za cynk, od razu zabraliśmy się do roboty!

Rzekoma rekruterka skontaktowała się z naszym klientem za pośrednictwem Messengera. Uwaga! Widoczny poniżej profil jest dalej aktywny w serwisie Facebook!

W następnym kroku pada pytanie, czy jest klientem Orange, a następnie prosi o odwiedzenie strony orange-praca[.]com. Ofiara jest zachęcana otrzymaniem kwoty 100 zł za zalogowanie na stronie, która okazuje się nieudolną kopią serwisu Mój Orange (stąd pytanie, czy oszust ma do czynienia z klientem naszych usług). Uzasadnieniem jest zarobek na zasadzie polecenia (tzw. referral). Co ciekawe, w naszym przypadku przestępca… pomylił adres strony! Dopiero po chwili wskazuje „prawidłowy” choć pamiętajmy, że prowadzący do oszustwa link.

Nasz klient zweryfikował te domenę, między innymi przy użyciu podpowiedzi Google Gemini. Czy jest to najlepsza metoda? Porady znajdziecie w podsumowaniu tego wpisu. Oszust zaniemówił, ale kilka godzin później wciąż nalegał aby zalogować się na wskazanej stronie.

Co skrywa fałszywa „praca w Orange”

Pod domeną orange-praca[.]com czekał formularz, w którym wyłudzane były dane dostępowe do konta Mój Orange. Ponieważ korzystając z niego mamy domyślnie włączane uwierzytelnianie dwuskładnikowe, w kolejnym kroku pojawia się prośba o przepisanie jednorazowego kodu z SMS-a. Jeśli to zrobimy – oddajemy dostęp do konta Mój Orange oszustowi. Ciekawostka – grafiki, które były wykorzystane na stronie pochodziły z prawdziwego serwisu rekrutacyjnego jednego z operatorów.

Gdy zajrzyjmy nieco głębiej, widać że dane z formularza za pośrednictwem aplikacji Telegram trafiają na kanał oszusta. Tam prawdopodobnie następuje ręczna weryfikacja i próba logowania na wyłudzone dane. Kolejna ciekawostka. Albo oszust poszedł na łatwiznę, bądź po prostu nie zwrócił na taki „drobiazg” uwagi, bowiem IP zarejestrowanej 5 stycznia 2026 domeny orange-praca[.]com prowadzi prosto do… Rosji.

Możemy Was zapewnić, że akurat ta „praca w Orange” już nikogo nie zainteresuje. Domena jeszcze w sobotni wieczór nie była już dostępna zarówno dla klientów Orange Polska (blokada na CyberTarczy), by niedługo później trafić również na listę CERT Polska.

Jakie było ryzyko i jak sobie z nim radzić?

Czym grozi przejęcie przez niepowołaną osobę konta Mój Orange? Największym ryzykiem wydaje się być – po dodatkowej weryfikacji – możliwość zamawiania usług i produktów w imieniu ofiary.

Jeśli chcesz pracować z nami – polecamy serwis https://orange.jobs, zaś w przypadku studentów – https://praktyki.orange.pl. Co do zasady – jeśli szukasz ofert pracy, sprawdzaj je na oficjalnych stronach pracodawców (szukaj zakładek takich jak „kariera”) lub serwisach z ogłoszeniami o pracę. I pamiętaj, że nikt i nigdy nie wymaga podczas procesu rekrutacyjnego logowania się w panelu klienta! No i nie płacimy za to 100 zł. Za pracę w Orange płacimy więcej. A już sam fakt próby rekrutacji przez Messengera warto traktować jako czerwoną flagę.

Wszędzie, gdzie wprowadzasz jakiekolwiek dane logowania, uprzednio zweryfikuj adres strony. Szukaj literówek. Zwróć uwagę na cały link. Oszuści wykorzystują tzw. subdomeny. Przykład: ogloszenie-stanowisko.nazwa-firmy-z-literowka.pl. Masz pewność, że to witryna firmy, agencji pośrednictwa lub portalu z ogłoszeniami? A może tylko ją przypomina? Ostatecznie poproś kogoś o pomoc.

No i wczytaj się w informacje i monity, które przychodzą do Ciebie SMS-em, czy w formie pusha w aplikacji. W naszym przypadku wiadomość z jednorazowym kodem szczegółowo informuje co autoryzujemy. Podobnie jest u większości usługodawców, więc przede wszystkim stanowczo zalecamy czytanie treści monitów.

Niezbędny w takiej sytuacji drugi krok daje nadzieję, iż potencjalna ofiara zorientuje się, że coś jest nie tak. I że logowanie do klienckiego serwisu operatora to nie jest praca w Orange. Dzięki konieczności wpisania kodu SMS oszust musi wykonać kolejne kroki, wyłudzać, czekać i wciągać ofiarę. To oznacza, większe ryzyko niepowodzenia. Zdobycie loginu i hasła to za mało.

The post Ktoś znów się pod nas podszywa. Tym razem wabikiem jest „praca w Orange” appeared first on CERT Orange.