Ostatnie tygodnie pokazują, że cyberprzestępcy nieustannie szukają nowych sposobów na zwiększenie skuteczności swoich kampanii. Sztuczna inteligencja coraz częściej wspiera autorów złośliwego oprogramowania, legalne strony internetowe stają się elementem łańcucha infekcji, a socjotechnika skutecznie zastępuje klasyczne exploity. W tym wydaniu Krajobrazu Zagrożeń przyglądamy się zarówno praktycznemu wykorzystaniu LLM-ów przez twórców botnetu TuxBot, nowemu stealerowi ClickLock dla macOS wykorzystującemu technikę ClickFix, jak i rosnącemu trendowi przejmowania zaufanych witryn internetowych do dystrybucji złośliwego oprogramowania.

Future

Botnet TuxBot, czyli dlaczego warto weryfikować wygenerowany kod

• Analitycy Unit42 przeanalizowali botnet IoT TuxBot v3 Evolution i przedstawili szczegółowy opis funkcji, możliwości i niedociągnięć w złośliwym oprogramowaniu.
• Według analityków TuxBot został stworzony z pomocą agentów AI i twórcy niedostatecznie zweryfikowali wygenerowany kod.
• Jest to jeden z przypadków obrazujących alternatywną perspektywę na wykorzystanie AI i LLM-ów w atakach — nie zawsze są to przejawy rewolucji jakościowej i ilościowej.

Analiza botnetu TuxBot v3 Evolution opublikowana przez zespół Unit 42 stanowi interesujący przykład ewolucji narzędzi wykorzystywanych do ataków na urządzenia IoT, jednocześnie dostarczając praktycznych obserwacji dotyczących wykorzystania dużych modeli językowych (LLM) w procesie tworzenia złośliwego oprogramowania. Badacze wskazują, że znaczna część kodu nosi wyraźne ślady wygenerowania przez model AI, czego dowodem są pozostawione komentarze i standardowe klauzule ograniczające odpowiedzialność, charakterystyczne dla odpowiedzi generowanych przez komercyjne modele językowe. Ich obecność w finalnym kodzie sugeruje, że autor nie przeprowadził pełnej weryfikacji ani redakcji wygenerowanych fragmentów przed ich wykorzystaniem. 

Sam framework nie odbiega jednak zasadniczo od znanych rodzin botnetów IoT. TuxBot v3 Evolution wykorzystuje modułową architekturę obejmującą agenta napisanego w języku C, serwer command & control opracowany w Go, mechanizmy automatycznej kompilacji dla wielu architektur procesorów oraz (w teorii) zestaw exploitów umożliwiających infekowanie urządzeń. Wsparcie dla licznych platform sprzętowych, obejmujących między innymi ARM, MIPS, PowerPC czy RISC-V, zwiększa potencjalny zasięg kampanii. W założeniach mechanizmy komunikacji uwzględniają szyfrowane połączenia z serwerem C2 oraz alternatywne kanały utrzymania łączności, a proces infekcji wykorzystuje zarówno ataki słownikowe na usługi Telnet, jak i znane podatności w urządzeniach IoT. W konstrukcji projektu widoczne są również powiązania z wcześniejszymi rodzinami botnetów, w tym Mirai, AISURU oraz narzędziami wykorzystywanymi w środowisku Keksec. W tym przypadku jednak założenia różnią się od wdrożenia. Jak ocenili analitycy Unit42, jedynie około 70% frameworka działa. 

Kluczowym elementem analizy pozostaje jakość kodu wygenerowanego przy wsparciu LLM. Badacze zidentyfikowali liczne błędy implementacyjne, niekompletne funkcje oraz fragmenty, które w praktyce nie działały zgodnie z zamierzeniem. Może i model językowy znacząco przyspieszył przygotowanie obszernego zestawu funkcji i kodu, lecz nie zastąpił wiedzy programistycznej koniecznej do ich poprawnego zintegrowania, przetestowania i wdrożenia. Ręczna lub przynajmniej drobiazgowa automatyczna analiza kodu jak widać nadal nie jest w pełni pomijalna. 

Analiza Unit 42 wskazuje, że wraz z dojrzewaniem modeli oraz lepszą integracją ich wyników z procesami programistycznymi można spodziewać się stopniowego wzrostu jakości podobnych projektów. W opracowaniu pojawiają się nawet stwierdzenia, że bardziej dopracowane wersje TuxBot z naprawionymi błędami mogą już być w użytku, lecz nie zostały przez analityków odkryte. 

Patrząc szerzej

Przypadek TuxBot v3 Evolution dobrze ilustruje szerszy kierunek zmian obserwowanych w cyberprzestępczości. Modele LLM mogą wspierać autorów złośliwego oprogramowania na wielu etapach działalności: od generowania fragmentów kodu, przez tworzenie dokumentacji technicznej, aż po przygotowywanie kampanii phishingowych. AI może również przyspieszać analizę publicznie dostępnych exploitów i adaptację istniejących narzędzi do nowych środowisk, nawet w czasie rzeczywistym jak wynika z innych doniesień.  

Jednocześnie przykład TuxBot pokazuje obecne ograniczenia tej technologii. Modele językowe nie gwarantują poprawności technicznej generowanego kodu, mogą wprowadzać błędy logiczne, nieefektywne rozwiązania lub pozostawiać charakterystyczne artefakty wskazujące na ich wykorzystanie. W przypadku rozbudowanego oprogramowania o zaawansowanych funkcjach niezbędna pozostaje wiedza specjalistyczna oraz wnikliwe testowanie. Z tego względu AI należy postrzegać przede wszystkim jako narzędzie usprawniające działania twórców złośliwego oprogramowania, a nie autonomicznego autora zaawansowanych kampanii. 

Więcej informacji:  
https://unit42.paloaltonetworks.com/tuxbot-v3-evolution-iot-botnet/ 

Malware

ClickLock: stealer, locker i kradzież danych chronionych przez system

• ClickLock to modularny stealer dla macOS, który wpisuje się w rozwijający się po ClickFix trend kampanii opartych na socjotechnice i instrukcjach wykonywanych przez użytkownika. 
• Najbardziej charakterystyczną funkcją malware jest locker, który po uruchomieniu blokuje urządzenie ofiary ubijając w pętli po kolei widoczne procesy.
• Zakres kradzionych danych jest szeroki i wyraźnie ukierunkowany na szybkie przejęcie dostępu. ClickLock zbiera dane z przeglądarek, rozszerzeń portfeli kryptowalut, rozszerzeń menedżerów haseł, aplikacji desktop wallet, a także hasło logowania do macOS i dane z Keychain.

ClickLock to nowy, modularny malware dla macOS, wykryty na podstawie złośliwego skryptu shellowego przesłanego do VirusTotal 9 czerwca 2026 r. W chwili analizy próbka nie miała żadnych detekcji. Badacze oceniają z wysoką pewnością, że malware jest powiązany z techniką ClickFix i wykorzystuje przejęte domeny WordPress oraz infrastrukturę opartą o Telegram. Według telemetryki kampania działa co najmniej od maja 2026 r. i objęła przynajmniej 100 ofiar w 33 krajach, z przewagą Europy. 

Punkt wejścia wygląda znajomo dla każdego, kto śledził wcześniejsze kampanie ClickFix. W analizie Goup-IB nie podano konkretnej strony phishingowej używanej do tej operacji, ale zachowanie skryptu i jego struktura mają wyraźnie wskazywać właśnie na ten model dystrybucji. 

Właściwy łańcuch infekcji zaczyna się w chwili wklejenia komendy do Terminala. Po uruchomieniu komendy malware nie ogranicza się do pobrania jednego pliku, co wskazuje na konstrukcję modułową. Główny skrypt od razu wyłącza keyboard interrupt, wyświetla w Terminalu fałszywą animację postępu stylizowaną na Cloudflare i w tle pobiera cztery kolejne komponenty. Trzy z nich – stealer poświadczeń, moduł kradnący dane z Keychain  i moduł ukierunkowany na kryptowaluty  – pochodzą z przejętej infrastruktury WordPress. Czwarty komponent jest instalatorem backdoora opartego o GSocket. 

W tym miejscu zaczyna się element, który odróżnia ClickLock od wielu innych stealerów dla macOS. Mechanizm locker wymusza interakcję z systemowym promptem Keychain, a równolegle utrudnia normalne korzystanie z komputera przez zamykanie widocznych procesów, w tym elementów interfejsu, przeglądarki czy narzędzi, które mogłyby pomóc użytkownikowi przerwać działanie złośliwego kodu. Ofiara zostaje doprowadzona do momentu, w którym podanie hasła wydaje się jedynym sposobem na odzyskanie kontroli nad systemem.  

Ten etap ma duże znaczenie operacyjne. Przejęcie hasła do konta użytkownika otwiera drogę do dalszego pobierania danych chronionych przez systemowe mechanizmy macOS. Malware sprawdza również, czy używane moduły mają odpowiednie uprawnienia do dostępu do chronionych zasobów, a jeśli nie, prowadzi użytkownika do nadania takich uprawnień ręcznie.  

ClickLock interesuje się danymi z przeglądarek, informacjami przechowywanymi w Keychain, historią poleceń powłoki, zapisanymi danymi uwierzytelniającymi oraz artefaktami związanymi z portfelami kryptowalut i menedżerami haseł. Widać, że malware został przygotowany z myślą o szybkim pozyskaniu danych, które można bezpośrednio wykorzystać do przejęcia kont, sesji lub dostępu do aktywów cyfrowych. 

Warto zwrócić uwagę, że kampania nie kończy się na samej kradzieży danych. Jednym z komponentów ClickLocka jest także mechanizm zapewniający trwały zdalny dostęp do urządzenia – backdoor oparty na GSocket. Mechanizmy persistence obejmują m.in. crontab, modyfikację plików RC powłoki i LaunchAgent. Zainfekowany host może być nie tylko źródłem poświadczeń, ale również punktem dalszych działań po zakończeniu pierwszego etapu kradzieży.  

Na poziomie infrastruktury kampania jest dość oszczędna. Group-IB nie zaobserwowało dedykowanego C2 w klasycznym rozumieniu. Dane są eksfiltrowane do przejętych domen i do trzech botów Telegrama, a do ustalenia publicznego IP wykorzystywana jest legalna usługa ifconfig.me. Taki model upraszcza operację, ogranicza potrzebę utrzymywania własnego zaplecza i utrudnia odróżnienie części ruchu od normalnej aktywności sieciowej. 

Sam malware wygląda przy tym na projekt nadal rozwijany.  Wniosek ten wynika ze struktury kodu i obserwowanych artefaktów. To ważny szczegół, bo sugeruje, że obecna forma ClickLock może nie być końcowa, a kolejne warianty mogą jeszcze lepiej łączyć socjotechnikę ClickFix z mechanizmami kradzieży danych i trwałego dostępu. rania znajdującym się w opisie. Jednak pod wskazanym adresem zamiast oczekiwanego oprogramowania, znajduje się malware

Patrząc szerzej

ClickLock ma dobrze ułożoną logikę działania. Duże znaczenie ma tu przejęcie hasła użytkownika i sięgnięcie do zasobów chronionych przez macOS, w czym pomaga mechanizm locker. Nie działa jak klasyczna blokada kojarzona z ransomware. Zamiast tego pomaga utrzymać presję, ograniczyć pole manewru i doprowadzić proces do momentu, w którym ofiara sama potwierdzi dostęp do wrażliwych danych. 

W kontekście bezpieczeństwa użytkownika powinny szczególnie alarmować wszelkie strony proszące o wklejenie polecenia do Terminala lub o nadanie Terminalowi dodatkowych uprawnień. Dla zespołów bezpieczeństwa to z kolei dobry przykład kampanii, w której warto patrzeć nie tylko na IOC, ale też na zachowania takie jak niestandardowe użycie osascript, odwołania do Keychain z poziomu skryptów, masowe sięganie do profili przeglądarek i gwałtowne killall.

Więcej informacji:  
https://www.group-ib.com/blog/clicklock-stealer-macos-malware/

Cybercrime

Od zatrutej strony do ClickFixa  

• Legalne strony internetowe coraz częściej stają się pierwszym etapem łańcucha infekcji. Atakujący kompromitują zaufane serwisy i wykorzystują je do wyświetlania fałszywych komunikatów ClickFix zamiast klasycznych exploitów.
• Łańcuch dostarczania złośliwego kodu staje się coraz bardziej wieloetapowy i odporny na analizę. W nowych kampaniach obserwowane jest wykorzystanie blockchaina, wielofazowych loaderów oraz technik DLL sideloading. 
• Krytyczne podatności w WordPress Core mogą znacząco zwiększyć skalę tego typu kampanii. Przejęcie legalnych witryn może w najbliższych dniach przełożyć się na wzrost liczby ataków typu watering hole oraz ClickFix.

Jeszcze kilka lat temu kompromitacja legalnej strony internetowej najczęściej kończyła się prostym przekierowaniem użytkownika na stronę phishingową lub próbą wykorzystania exploita w przeglądarce. Obecnie obserwujemy wyraźną zmianę tego modelu. Coraz częściej przejęte witryny pełnią jedynie rolę pierwszego etapu ataku, którego celem jest przekonanie użytkownika do samodzielnego uruchomienia złośliwego kodu przy wykorzystaniu techniki ClickFix. 

Schemat działania jest stosunkowo prosty. Po wejściu na zaufaną stronę użytkownik otrzymuje komunikat o rzekomym błędzie przeglądarki, problemie z weryfikacją CAPTCHA lub konieczności wykonania czynności naprawczych. Następnie proszony jest o skopiowanie przygotowanego polecenia, uruchomienie okna Uruchom lub PowerShell i wklejenie komendy. W praktyce to użytkownik wykonuje działania, które omijają wiele klasycznych mechanizmów zabezpieczeń. 

Kompromitacja legalnych serwisów pozwala przy tym ominąć jedną z największych przeszkód współczesnych kampanii phishingowych – konieczność przekonania użytkownika do odwiedzenia nieznanej domeny. Ofiara trafia bowiem na stronę, której ufa i którą często odwiedza od lat. To właśnie dlatego metoda watering hole ponownie zyskuje na znaczeniu i coraz częściej stanowi pierwszy etap bardziej rozbudowanych kampanii malware. 

Równolegle zmienia się sposób dostarczania właściwego ładunku. Widoczny jest trend budowania znacznie bardziej rozbudowanych łańcuchów infekcji niż jeszcze kilka miesięcy temu. 

Jednym z najbardziej charakterystycznych trendów ostatnich miesięcy jest wykorzystanie publicznych sieci blockchain jako elementu infrastruktury Command and Control (C2). Obserwujemy kampanie ClickFix, w których operatorzy nie umieszczali adresów serwerów ani domen bezpośrednio w kodzie JavaScript czy loaderze. Zamiast tego skrypt komunikował się z publicznymi węzłami sieci Polygon, odczytując dane zapisane w dedykowanym smart kontrakcie. To właśnie tam przechowywana była zaszyfrowana konfiguracja zawierająca aktualne adresy infrastruktury wykorzystywanej w kolejnych etapach ataku. 

Z perspektywy analityków CTI rozwiązanie daje dodatkowe możłiwości analityczne. Blockchain jest publicznym rejestrem, dzięki czemu możliwe jest śledzenie historii zmian konfiguracji, identyfikowanie nowych domen wykorzystywanych przez operatorów oraz korelowanie pozornie niezależnych kampanii.  

Obserwujemy także, iż zmienia się sposób budowania wieloetapowych loaderów odpowiedzialnych za dostarczenie końcowego ładunku. Coraz częściej pierwszy etap infekcji ogranicza się jedynie do przygotowania środowiska dla kolejnych faz ataku. W jednej z analizowanych kampanii PowerShell nie pobierał bezpośrednio złośliwego oprogramowania. Zamiast tego pobierał z oficjalnej strony python.org przenośną wersję interpretera Python oraz niewielkie archiwum z serwera kontrolowanego przez atakujących. Następnie uruchamiany był jedynie skrypt Captcha.py, którego zawartość na pierwszy rzut oka nie zdradzała złośliwego charakteru. Sam PowerShell pełnił jedynie rolę instalatora środowiska uruchomieniowego, pozostawiając właściwą logikę działania kolejnym etapom. 

Dopiero analiza kolejnych faz ujawniła pełny mechanizm infekcji. Skrypt pobierał następne komponenty z infrastruktury C2, odszyfrowywał je i przygotowywał środowisko do uruchomienia końcowego ładunku. W finalnej fazie wykorzystywana była technika DLL sideloading, dzięki której złośliwa biblioteka była ładowana przez legalny i zaufany proces. Taki podział funkcjonalności sprawia, że pierwszy etap kampanii wygląda niemal niewinnie – pobranie oficjalnego interpretera Python i uruchomienie prostego skryptu nie wzbudza zwykle podejrzeń użytkownika ani części rozwiązań bezpieczeństwa. W praktyce jednak jest to jedynie początek znacznie bardziej rozbudowanego łańcucha infekcji. 

Znaczenie opisanych technik dodatkowo zwiększają opublikowane w ostatnich dniach krytyczne podatności w WordPress Core. Luka CVE-2026-63030 umożliwia zdalne wykonanie kodu (RCE), natomiast CVE-2026-60137 pozwala na przeprowadzenie ataku SQL Injection. Obie podatności nie wymagają uwierzytelnienia ani obecności dodatkowych wtyczek, a skuteczne wykorzystanie umożliwia przejęcie kontroli nad podatną witryną. 

Przejęcie popularnych stron internetowych może stać się idealnym punktem startowym dla kampanii typu watering hole. Wystarczy niewielka modyfikacja kodu strony lub dodanie kilku linii JavaScript, aby każdy odwiedzający został przekierowany do mechanizmu ClickFix lub kolejnego etapu łańcucha infekcji. Biorąc pod uwagę skalę wykorzystania WordPressa oraz fakt, że ataki nie wymagają uwierzytelnienia, można spodziewać się wzrostu liczby tego typu incydentów w najbliższych dniach i tygodniach. 

Patrząc szerzej

Przez wiele lat największą uwagę poświęcaliśmy samemu malware. Dziś coraz częściej najciekawsza część operacji znajduje się przed jego uruchomieniem. To właśnie sposób dostarczenia użytkownika do momentu wykonania pierwszego polecenia staje się głównym polem innowacji cyberprzestępców. 

ClickFix jest tego najlepszym przykładem. Nie wykorzystuje podatności systemowej ani zaawansowanego exploita. Wykorzystuje zaufanie użytkownika. Jednocześnie obserwujemy coraz większą kreatywność w ukrywaniu infrastruktury – od blockchaina, przez wieloetapowe loadery, po techniki utrudniające analizę i wykrywanie. Każdy z tych elementów z osobna nie jest przełomowy, ale ich połączenie tworzy wyjątkowo skuteczny model ataku. 

Naszym zdaniem w najbliższych miesiącach będziemy obserwować coraz więcej kampanii, w których przejęte legalne strony internetowe staną się podstawowym kanałem dystrybucji ClickFix. Krytyczne podatności w popularnych systemach CMS, takich jak WordPress, mogą dodatkowo przyspieszyć ten trend. Dlatego monitorowanie integralności własnych serwisów internetowych oraz szybkie wdrażanie aktualizacji bezpieczeństwa powinno być dziś traktowane nie tylko jako element administracji systemem, ale jako jeden z podstawowych mechanizmów ochrony przed współczesnymi kampaniami malware. 

Więcej informacji:
https://www.elastic.co/security-labs/telepuz-maas-malware-clickfix