W świecie cyberzagrożeń każdy tydzień przynosi nowe interesujące techniki ataków, przed którymi należy nauczyć się bronić, ale także przypomnienia o tych dobrze znanych, których nie należy bagatelizować. Tym razem przyjrzeliśmy się procesowi tworzenia kampanii i rozwijania arsenału przez atakujących, zarówno w zakresie budowania wielkiego botnetu oraz korzystania z gotowych modułowych phishing-kitów. Nie zabrakło również nowego złośliwego oprogramowania oraz wykorzystania narzędzi bezpieczeństwa w złych celach. DDoSy, chmurowe incydenty i kradzież wypłat pracowników, to tylko niektóre z tematów, które postanowiliśmy poruszyć w naszym aktualnym Krajobrazie Zagrożeń, co jeszcze działo się w minionym tygodniu?

Na skróty:

1. Temat tygodnia: Incydent SonicWall – gdy kopie zapasowe stają się celem ataku.
2. Zaawansowane zagrożenia: Payroll pirate, czyli kradzież wypłat pracowników uczelni wyższych.
3. Cybercrime: Velociraptor w służbie ransomware: lekcja o cienkiej granicy między obroną a ofensywą.
4. Telco: Skąd się biorą DDoSy o mocy 30 Tbps?
5. Oszustwa i podszycia: IUAM ClickFix Generator, czyli automatyzacja kampanii ClickFix.
6. Złośliwe oprogramowanie: ClayRat – gliniany spyware na solidnych podstawach.
7. CVE Tygodnia: Redishell – podatnośc w Redis.

Temat tygodnia

Incydent SonicWall – gdy kopie zapasowe stają się celem ataku.

We wrześniu 2025 roku firma SonicWall ogłosiła poważny incydent bezpieczeństwa dotyczący usługi MySonicWall Cloud Backup – odkryto nieautoryzowaną aktywność w środowisku chmurowym, w którym przechowywano kopie zapasowe konfiguracji urządzeń klientów. Początkowo wskazywano, że zagrożony został tylko niewielki wycinek środowiska – mniej niż 5 % plików backupowych – oraz podkreślano, że dane uwierzytelniające użytkowników i klucze licencyjne nie zostały naruszone w sposób jawny (choć część plików konfiguracji mogła zostać pobrana). W kolejnych dniach SonicWall regularnie uaktualniał swoje komunikaty, przekazując nowe ustalenia oraz narzędzia wspierające klientów w ocenie ryzyka i remediacji.

Do chwili zakończenia dochodzenia firma SonicWall współpracowała z Mandiant – zespołem ds. reagowania na incydenty bezpieczeństwa (IR) działającym w ramach Google Cloud. W październiku 2025 ogłoszono wyniki tej wspólnej analizy, które diametralnie zmieniają pierwotny obraz zdarzenia. Według ustaleń Mandiant, atakujący uzyskali dostęp do środowiska kopii zapasowych i byli w stanie pobrać pliki .EXP (pełne zrzuty konfiguracji urządzeń) dla wszystkich klientów korzystających z usługi MySonicWall Cloud Backup, a to oznacza, że zakres incydentu objął 100 % backupów konfiguracyjnych usług w chmurze, a nie tylko wybraną ich część, jak sugerowano na początku.

Mandiant ustalił, że chociaż same dane uwierzytelniające i hasła oraz tokeny konfiguracyjne znajdujące się w backupach były szyfrowane (w urządzeniach Gen 7 i nowszych przy użyciu AES-256, a w Gen 6 z użyciem 3DES), dostępność zaszyfrowanych plików umożliwia napastnikom prowadzenie działań rekonesansowych i planowanie precyzyjnych ataków. Szczególnie groźne jest to, że część danych konfiguracyjnych (np. struktura reguł, ustawienia NAT, VPN, polityki dostępu) nie była w pełni szyfrowana – były zakodowane (np. za pomocą Base64 lub innych metod kodowania), co ułatwia ich analizę.

Końcowy raport wskazuje, że atakujący mogli wykorzystać podatności w API usługi backupu lub mechanizmy uwierzytelnienia, w szczególności poprzez ataki siłowe (brute force) na interfejs backupu w chmurze, co umożliwiło im pobranie plików – a następnie analiza i rekonstrukcja topologii sieci, polityk bezpieczeństwa czy ustawień VPN. SonicWall, w komunikacie po zakończeniu dochodzenia, potwierdził, że wszystkie urządzenia, które korzystały z backupów w chmurze, zostały uwzględnione w “finalnej liście urządzeń objętych incydentem”, publikowanej w portalu MySonicWall.

W reakcji na wnioski Mandiant, SonicWall wdrożył dodatkowe środki zabezpieczeń dla swojej infrastruktury chmurowej oraz wzbogacił monitoring i mechanizmy wykrywania anomalnej aktywności w środowisku backupowym. Firma współpracuje nadal z Mandiant celem przeprowadzenia testów red-teamingowych i symulacji ataków na zmodernizowaną infrastrukturę, by zweryfikować odporność systemu.

Z technicznego punktu widzenia incydent ten uwidacznia jeden z kluczowych problemów współczesnego modelu bezpieczeństwa – zaufanie do chmury jako miejsca składowania danych wrażliwych. Backupy konfiguracyjne, które z założenia mają służyć odtwarzaniu działania infrastruktury po awarii, w sytuacji wycieku stają się gotową mapą sieci organizacji. Zawarte w nich informacje o adresach IP, regułach routingu, strefach bezpieczeństwa czy integracjach z systemami zewnętrznymi pozwalają cyberprzestępcom lepiej zrozumieć architekturę celu i planować dalsze ataki. W tym sensie incydent SonicWall pokazuje, że utrata kopii zapasowej jest równie groźna jak utrata danych produkcyjnych.

Ryzyko związane z przechowywaniem backupów w chmurze ma charakter zarówno techniczny, jak i proceduralny. Po stronie technicznej istotne jest właściwe szyfrowanie kopii oraz segmentacja środowisk – tak, by potencjalne przełamanie zabezpieczeń jednego komponentu nie dawał możliwości dostępu do całego ekosystemu. Jednak w praktyce często to właśnie środowiska backupowe są słabiej chronione, bo postrzega się je jako pasywne i mało atrakcyjne cele. Tymczasem stanowią one repozytorium pełnej wiedzy o konfiguracji, procesach i danych organizacji. Po stronie proceduralnej kluczowym błędem bywa także nadmierne zaufanie do dostawcy chmurowego – w myśl założenia, że skoro usługa jest zarządzana, to odpowiedzialność za bezpieczeństwo spoczywa wyłącznie po stronie operatora. Incydent SonicWall pokazał, że model współodpowiedzialności w chmurze jest realny: to użytkownik powinien dbać o kontrolę nad tym, co i w jakiej formie trafia do chmury, oraz czy dane są szyfrowane jeszcze przed wysyłką.

Analiza tego przypadku wskazuje, że bezpieczeństwo backupów powinno być traktowane na równi z ochroną danych operacyjnych. Organizacje powinny nie tylko szyfrować swoje kopie zapasowe, lecz także regularnie testować mechanizmy ich przywracania i przeglądać konfiguracje systemów, by minimalizować ilość informacji potencjalnie dostępnych w razie wycieku. W kontekście incydentu SonicWall można uznać, że głównym zagrożeniem nie była sama utrata dostępności, lecz ujawnienie wiedzy o wewnętrznych strukturach sieciowych klientów.

Sprawa ta stanowi ważny sygnał ostrzegawczy dla całej branży bezpieczeństwa IT. W świecie, w którym coraz więcej danych – w tym kopii zapasowych – trafia do chmury, tradycyjne rozumienie bezpieczeństwa infrastruktury musi ewoluować. Backup przestaje być tylko kopią bezpieczeństwa – staje się potencjalnym wektorem ataku, który może posłużyć do precyzyjnego planowania działań ofensywnych. Incydent SonicWall przypomina, że w erze chmury każda warstwa zabezpieczeń, łącznie z warstwą kopii zapasowych, musi być traktowana jako element krytyczny całego łańcucha bezpieczeństwa.

Więcej informacji:
https://www.sonicwall.com/support/knowledge-base/mysonicwall-cloud-backup-file-incident/250915160910330
https://kapitanhack.pl/backup-czy-luka-jak-atak-na-kopie-zapasowe-sonicwall-otworzyl-drzwi-cyberprzestepcom/

Wybrane zagrożenia tygodnia

Zaawansowane zagrożenia

Payroll Pirate, czyli kradzież wypłat pracowników uczelni wyższych.

Zespół Microsoft Threat Intelligence opisał ataki nazywane „payroll pirate”, które mają na celu wyłudzenie poświadczeń pracowników i dzięki uzyskanym dostępom przekierowanie wypłat na konta kontrolowane przez atakujących. Celami motywowanego finansowo threat actora śledzonego przez Microsoft jako Storm-2657 są organizacje w Stanach Zjednoczonych, szczególnie pracownicy uczelni wyższych. Najcenniejszy dla atakujących jest dostęp do kadrowych platform SaaS takich jak Workday, lecz analitycy wskazują, że podobne ataki mogłyby zostać wykorzystane do przejęcia profili z dostępem do danych związanych z płatnościami i kontami bankowymi na innych platformach. Kluczowe dla atakujących było pozyskanie dostępu umożliwiającego szybkie spieniężenie ataku – nie interesowała ich kradzież danych wewnętrznych lub dostępowych.

Kampania polegała na wysyłce maili phishingowych stworzonych tak, by wyłudzać także kody MFA za pomocą metodą AITM (adversary-in-the-middle) i uzyskać dostęp do Exchange Online. Dostęp pozwalał im na stworzenie odpowiednich reguł pocztowych usuwających powiadomienia z ostrzeżeniami o zmianach na profilu Workday. Po logowaniu za pośrednictwem SSO do Workday atakujący zmieniali dane konta bankowego, na które miała być wysyłana wypłata pracownika na takie, znajdujące się pod ich kontrolą. W celu zachowania trwałego dostępu do kont, Storm-2657 podmieniało numery telefonów służące do obsługi MFA na swoje.

Rys. Łańcuch ataku ”payroll pirate”. Źródło: Microsoft.

Scenariusze mające działać jako „przynęta” i zachęcać do kliknięcia w odnośnik w mailu, to między innymi raporty z zachorowań na COVID lub inną chorobę zakaźną pozwalające sprawdzić, czy miało się kontakt z chorym, powiadomienia o złamaniu zasad uczelni oraz dokumenty do przeglądu pochodzące z któregoś z uczelnianych pionów (na przykład kadrowego). Na podstawie motywów przewodnich phishingu można zauważyć, że wyraźnym celem atakujących było szkolnictwo wyższe. Może to wynikać z mniej restrykcyjnego lub niewdrożonego filtrowania poczty, braku wymogu korzystania z 2FA dla wszystkich kont oraz przyzwyczajenia pracowników do korzystania z usług chmurowych (takich jak wykorzystywane także w tym ataku Google Docs) do otwierania współdzielonych dokumentów.

Uchronienie się przed atakami payroll pirate wymaga przede wszystkim implementacji wieloskładnikowego uwierzytelniania odpornego na phishing. Jeżeli opieramy MFA na kodach przepisywanych z urządzenia mobilnego lub akceptacji logowania w aplikacji, należy liczyć się z tym, że wprawny atakujący wyłudzi także ten czynnik. Tokeny fizyczne, które nie zadziałają na stronie fałszywej i wymagają podłączenia ich do urządzenia, na którym odbywa się logowanie są znacznie pewniejszym rozwiązaniem gwarantującym zabezpieczenie akurat przed atakami socjotechnicznymi. Jeżeli podobny atak już miał miejsce w naszym środowisku, konieczny jest reset haseł dotkniętych atakiem użytkowników, ponowna rejestracja urządzeń służących do MFA (i usunięcie poprzednich) oraz cofnięcie zmian przeprowadzonych przez atakujących, w tym usunięcie reguł pocztowych i poprawienie danych w systemach kadrowych.

Więcej informacji:
https://www.microsoft.com/en-us/security/blog/2025/10/09/investigating-targeted-payroll-pirate-attacks-affecting-us-universities/

Telco

Skąd się biorą DDoSy o mocy 30 Tbps?

Według analiz botnet Aisuru nieustannie zwiększa swoje możliwości realizacji rekordowych wolumetrycznie ataków DDoS. Przejęte urządzenia IoT są głównym źródłem mocy botnetu – konsumenckie routery, kamery monitoringu, rejestratory i inne urządzenia z nieaktualnym oprogramowaniem oraz niezmienionymi domyślnymi ustawieniami fabrycznymi. Właściciele Aisuru skanują sieć w poszukiwaniu podatnych urządzeń i przejmują je na cele późniejszego wykorzystania w atakach DDoS.
W maju 2025 strona KrebsOnSecurity została zaatakowana przez Aisuru poważnym DDoSem o mocy 6.35 Tbps bliskiej ówczesnemu rekordowi, ale już kilka dni później atakujący pochwalili się możliwością wygenerowania 11 Tbps ruchu. Pod koniec września były to już 22 Tbps, a 6 października miał miejsce pokaz umiejętności, który choć trwał tylko kilka sekund i nie był atakiem, pobił rekord wartością wynoszącą 29,6 Tbps. W ostatnim czasie celami ataków z wykorzystaniem botnetu Aisuru byli dostawcy hostujący popularne gry, jak chociażby Minecraft, ale ataki miały zauważalny wpływ wykraczający poza świat gier online. Rozwiązanie anty-DDoS TCPShield, chroniące ponad 50 tysięcy serwerów Minecraft nie udźwignęło ataku DDoS, który sprowadził na infrastrukturę ponad 15 terabitów szkodliwego ruchu i spowodował chwilową niedostępność 28 września. Australijski ISP Global Secure Layer przejął pełną ochronę nad TCPShield po tym, jak OVH zrezygnowało ze świadczenia im usług w związku z utrzymującymi się kilka tygodni zakłóceniami normalnej działalności firmy.

Według eksperta z firmy GSL – Stevena Fergusona – botnet jest w coraz większym stopniu zbudowany z urządzeń hostowanych u amerykańskich ISP (AT&T, Charter Communications, Comcast, T-Mobile i Verizon). Może to utrudniać mitygację ataków DDoS z takich źródeł, ale także wpływać na jakość usług świadczonych nawet klientom, których urządzenia nie były zainfekowane botnetem Aisuru. Roland Dobbins z Netscout wskazał z kolei na rosnące zagrożenie wynikające z ruchu wychodzącego z zainfekowanych urządzeń znajdujących się w sieci, mogący wynosić nawet terabit na sekundę, co może wpływać na przepustowość i wywoływać awarie. Pokazuje to też konieczność zatrzymywania ataków DDoS nie tylko w momencie, kiedy docierają do sieci ofiary, lecz już na etapie, kiedy ruch wychodzi z przejętych urządzeń. Wykrywanie i przeciwdziałanie infekcjom złośliwym oprogramowaniem typu botnet to duże wyzwanie dla operatorów, którzy muszą bacznie obserwować anomalie w ruchu i zachowania charakterystyczne dla przejętych urządzeń.

Aisuru to botnet zbudowany na podstawie upublicznionego w 2016 roku kodu Mirai. Według firmy XLab, 15 września miał około 300 tysięcy aktywnych węzłów na całym świecie. Nieoczekiwaną korzyścią dla jego twórców okazało się między innymi osłabienie kluczowej konkurencji na rynku botnetów IoT – RapperBot, którego właściciel znalazł się w sierpniu na celowniku Departamentu Sprawiedliwości Stanów Zjednoczonych. Umożliwiło to przejęcie przez Aisuru uwolnionych spod wpływu RapperBota podatnych urządzeń i tym samym zwiększenie swojego DDoSowego potencjału. Jednym z groźniejszych działań Aisuru był opisany przez XLab atak wykorzystujący metodę zatrutego wodopoju. Przejęcie serwera aktualizacyjnego Totolink umożliwiło dystrybucję złośliwego skryptu bezpośrednio na wszystkie urządzenia próbujące się zaktualizować. To skuteczna metoda o szerokim zasięgu, która doprowadziła do szybkiego przyrostu urządzeń znajdujących się pod kontrolą Aisuru.

Błyskawiczny rozwój botnetu i skupienie się na pozyskiwaniu infrastruktury zlokalizowanej w Stanach Zjednoczonych to istotne ruchy wskazujące na dostosowanie się atakujących do coraz lepszych oraz powszechniejszych rozwiązań ochrony anty-DDoS. Ataki wolumetryczne, które można byłoby uznać za łatwiejsze w mitygacji w porównaniu do zaawansowanych ataków aplikacyjnych, wciąż pozostają poważnym zagrożeniem mogącym wpłynąć na funkcjonowanie operatorów i dużych dostawców usług cyfrowych. Nie należy bagatelizować zagrożenia jakie niosą za sobą ataki DDoS, szczególnie w obliczu dynamicznie rozwijających się grup dysponujących tak dużym botnetem, realizujących ataki dobierając cele w sposób nieprzewidywalny i oferujących swoje usługi na wynajem.

Więcej informacji:
https://krebsonsecurity.com/2025/10/ddos-botnet-aisuru-blankets-us-isps-in-record-ddos/
https://blog.xlab.qianxin.com/super-large-scale-botnet-aisuru-en/

Cybercrime

Velociraptor w służbie ransomware: lekcja o cienkiej granicy między obroną a ofensywą

Velociraptor to narzędzie stworzone z myślą o zabezpieczeniu danych i analizie post incydentalnej. Jego architektura pozwala zespołom bezpieczeństwa na pozyskiwanie artefaktów z urządzeń końcowych, uruchamianie zapytań i zdalne reagowanie na incydenty bezpieczeństwa. Zespół Cisco Talos, analizując aktywność motywowanego finansowo aktora zagrożeń Storm-2603, zilustrował brutalną ironię, w której operatorzy ransomware wykorzystali nieaktualną wersję Velociraptora w swoich atakach.

Początkowy etap ataku rozpoczynał się od wykorzystania krytycznych podatności w serwerach Microsoft Sharepoint, w tym podatności znanej jako ToolShell. Po uzyskaniu pierwotnego dostępu Storm-2603 wdrażał Velociraptora w infrastrukturze ofiary, nadając mu rolę agenta kontrolującego stacje robocze i serwery. W praktyce pozwalało to na pobieranie artefaktów, wykonanie poleceń systemowych oraz uruchamianie dodatkowego oprogramowania bez konieczności stosowania złośliwego oprogramowania. Narzędzie pełniło więc rolę platformy C2 zbudowanej na zaufanym komponencie, co znacząco podnosiło skuteczność ukrycia obecności w środowisku ofiary.

Kolejne fazy kampanii obejmowały lateralne poruszanie się w środowisku i eskalację uprawnień. Dzięki Velociraptorowi atakujący mogli zdalnie wywoływać komendy administracyjne i egzekwować polityki systemowe, które sprzyjały wdrożeniu ransomware. Zaobserwowano wykorzystanie tego narzędzia do przygotowania środowiska pod szyfrowanie zasobów, w tym serwerów Hyper-V oraz usług kluczowych dla działania infrastruktury ofiary. W finalnym etapie wdrażano kilka rodzin ransomware, między innymi LockBit, Warlock i wariant Babuk, co miało na celu maksymalizację skutków incydentu oraz presję na ofiary w negocjacjach okupu.

Techniczna analiza Talosa potwierdziła, że wykorzystana wersja Velociraptora była podatna na eskalację uprawnień, umożliwiając nawet użytkownikom z ograniczonymi rolami wykonanie działań o poziomie administratora. Luka oznaczona jako CVE-2025-6264 sprawiała, że Velociraptor wdrożony przez atakujących mógł działać w środowisku ofiary bez konieczności obejścia dodatkowych zabezpieczeń i w praktyce zapewniał pełną kontrolę nad zainfekowanymi hostami. Ponadto obserwacje z różnych zespołów badawczych potwierdziły, że Velociraptor był używany nie tylko jako mechanizm utrwalenia dostępu, ale również jako platforma pomocnicza do tworzenia tuneli i uruchamiania dodatkowego oprogramowania. W jednym z opisanych przypadków narzędzie posłużyło do pobrania i uruchomienia Visual Studio Code co najpewniej miało na celu zainicjowanie połączenia do zdalnego serwera C2 i ustanowienie trwałego kanału komunikacji.

Zjawisko utylizacji Velociraptora w kampaniach ransomware podkreśla fundamentalny problem – narzędzia stworzone do celów obronnych mogą być równie skutecznie wykorzystywane ofensywnie, jeśli zostaną wdrożone w niekontrolowany sposób. Ich otwartość, popularność i bogata funkcjonalność czynią je atrakcyjnymi dla aktorów zagrożeń. W tym przypadku narzędzie do analizy i reagowania na incydenty zostało przekształcone w element ataku, umożliwiając zdalne sterowanie środowiskiem ofiary i przygotowanie gruntu pod wdrożenie ransomware. Wnioski płynące z analizy mogą zabrzmieć prosto, ale konsekwencje są poważne. Po pierwsze, sama obecność narzędzia DFIR w środowisku nie gwarantuje bezpieczeństwa, a może stać się środkiem ułatwiającym atak, jeśli nie jest właściwie zarządzane. Po drugie, polityki i mechanizmy kontroli dostępu muszą być zaprojektowane z założeniem, że narzędzia administracyjne muszą mieć najmniejsze niezbędne uprawnienia oraz że ich aktualizacje i konfiguracje są krytycznym elementem higieny bezpieczeństwa. Po trzecie, monitoring nie powinien opierać się wyłącznie na znanych sygnaturach, lecz na anomaliach w zachowaniu procesów i użyciu uprawnień, bo w ten sposób legalne narzędzie wykorzystane w sposób nienadzorowany stanie się wykrywalne. Raporty analityczne z 2024 i 2025 roku odnotowały rosnącą liczbę incydentów, w których atakujący korzystali z komercyjnych i open source narzędzi w celu uniknięcia wykrycia a jednocześnie osiągnięcia zaawansowanych celów takich jak eskalacja uprawnień i eksfiltracja danych.

Więcej informacji:
https://blog.talosintelligence.com/velociraptor-leveraged-in-ransomware-attacks/
https://news.sophos.com/en-us/2025/08/26/velociraptor-incident-response-tool-abused-for-remote-access

Oszustwa i podszycia

IUAM ClickFix Generator, czyli automatyzacja kampanii ClickFix.

W trakcie codziennej analizy zagrożeń, od kilku miesięcy, identyfikowaliśmy liczne ataki (strony WWW, kampanie reklamowe, inne socjotechniki) wykorzystujące mechanizm „ClickFix”. Jak on działa i dlaczego jest taki skuteczny pisaliśmy już wielokrotnie w naszych krajobrazach zagrożeń. Ataki trwały i trwają nieustannie. Budowane są nowe strony phishingowe, ale atakujący również „wstrzykują” złośliwy kod do legalnych i często popularnych stron. Obserwowaliśmy te ataki, kategoryzowaliśmy i szukaliśmy cech wspólnych. W toku analiz natrafiliśmy na zestaw kampanii, które różniły się detalami (np. domeną, formatem ukrytego polecenia, czy metodą zaciemnienia kodu) – ale niemal co do bitu odzwierciedlały tę samą logikę działania. To skojarzenie sugerowało, że cały mechanizm jest dostarczany jako gotowy kit (malware-kit albo phishing-kit), a różnice wynikają głównie z różnej infrastruktury wykorzystywanej w dalszych etapach ataku.
IUAM ClickFix Generator to nowy, wyraźnie modułowy phishing-kit ujawniony przez Unit 42, który przemienia technikę „ClickFix” – polegającą na zmuszeniu ofiary do ręcznego wklejenia i uruchomienia komendy – w gotowy do natychmiastowego użycia generator z szeroką konfiguracją parametrów strony i ładunku; narzędzie automatyzuje tworzenie wabików (ang. lure) zawierających mechanizm kopiowania do schowka, detekcję systemu operacyjnego i wybór odpowiedniego payloadu (PowerShell dla Windows lub base64|sh dla macOS), co w badanych kampaniach poskutkowało dostarczaniem złośliwego oprogramowania typu infostealer.

Generator działa jako aplikacja webowa z panelem konfiguracyjnym pozwalającym określić tytuł dokumentu HTML, teksty przycisków i komunikatów, komendę kopiowaną do schowka, ustawienia blokady urządzeń mobilnych oraz zaawansowane opcje (obfuskacja JS, segmentacja logiki kopiowania, automatyczne przełączanie poleceń według wykrytego OS), a wygenerowane strony wykazują spójny szkielet DOM i charakterystyczne funkcje JavaScript (np. elementy kopiujące i walidujące „human check”), co umożliwia korelację wariantów jako jedna rodzina narzędzi.

Centralny mechanizm ataku to:

1. Wyświetlenie fałszywego procesu „weryfikacji” z przyciskiem uruchamiającym kopiowanie komendy do schowka.
2. Instrukcja dla użytkownika – otwórz terminal/PowerShell → wklej → uruchom – dzięki czemu to użytkownik dostarcza wykonanie złośliwego kodu, co omija wiele tradycyjnych zabezpieczeń na atakowanych komputerach, jak i sandboxów.
3. Dynamiczne pobieranie finalnego ładunku z adresów C2. W praktyce obserwowano zarówno domeny rejestrowane pod kampanie, jak i wstrzykiwanie złośliwych wywołań (snippety javascript) do legalnych stron.

W warstwie technicznej generator udostępnia opcje obfuskacji JavaScript (przez przemapowanie nazw funkcji, kodowanie ciągów znaków i rozbijanie logiki na asynchroniczne wywołania), możliwość „packaged builds” do hostingu na zewnętrznych serwerach lub CDN oraz mechanizmy śledzenia i logowania konfiguracji (w tym treści schowka i metadanych tworzenia instancji), co upraszcza masową dystrybucję i rotację stron phishingowych.

Konsekwencje pojawienia się takiego narzędzia dla ClickFix są wielowymiarowe: obniżenie progu wejścia technicznego powoduje rozszerzenie grona potencjalnych operatorów (phishing-as-a-service), szybka generacja wariantów i rotacja domen utrudnia sygnaturowe wykrywanie, a kombinacja i dopasowywanie payloadów do środowiska ofiary (m.in systemu operacyjnego) zwiększa zasięg ataku (w analizowanych przypadkach zarówno Windows, jak i macOS były celami) – dodatkowo techniki pokrewne (cache-smuggling, wstrzykiwanie do motywów WordPress) pozwalają na ukryte serwowanie złośliwych wabików z pozornie zaufanych źródeł.

W dłuższej perspektywie spodziewać się należy dalszej integracji modułów ClickFix w ofertach PhaaS, ewolucji technik obfuskacji i dostosowania payloadów do kolejnych platform oraz nasycenia krajobrazu dużą liczbą krótkotrwałych, wysoce spersonalizowanych kampanii – co wymaga od obrońców przejścia od reaktywnej sygnaturowej obrony ku adaptacyjnej ochronie łączącej telemetrię sieciową, silne reguły EDR i obowiązkowe mechanizmy ograniczające możliwości „ręcznego wykonywania” kodu przez nieuprzywilejowanych użytkowników.

Więcej informacji:
https://unit42.paloaltonetworks.com/clickfix-generator-first-of-its-kind/

ClayRat – gliniany spyware na solidnych podstawach.

ClayRat to złośliwe oprogramowanie wymierzone w użytkowników systemu Android, które to opisali badacze Zimperium. W odróżnieniu od prostych trojanów dystrybuowanych przez jeden wektor, mamy do czynienia z rozwiniętym ekosystemem, który łączy fałszywe strony z popularnymi aplikacjami, dystrybucję przez komunikatory oraz zaawansowane mechanizmy ładowania payloadów w trakcie instalacji. W efekcie użytkownik instaluje aplikacje wyglądającą jak niewinna aktualizacja, podczas gdy w tle uruchamiany jest zaszyfrowany moduł spyware, którego niezwykle trudno wykryć przy użyciu sygnaturowej detekcji.

Pierwszy etap infekcji wykorzystuje phishing i zaufane kanały dystrybucji. Użytkownik trafia na stronę stylizowaną na oficjalny portal popularnej aplikacji, takiej jak YouTube, WhatsApp czy TikTok, albo otrzymuje link przez Telegram. W obu przypadkach instalator APK zawiera dwie warstwy: widoczną aplikację, która często pełni jedynie rolę atrapy, oraz ukryty w zasobach zaszyfrowany moduł spyware. Payload ten jest odszyfrowywany i aktywowany dopiero podczas procesu instalacji – to tak zwany model session-based, który pozwala atakującym ominąć systemowe zabezpieczenia i utrudnia analizę statyczną plików. Zabezpieczenia Androida w nowszych wersjach wymuszają dodatkowe potwierdzenia dla aplikacji spoza sklepu, jednak operatorzy ClayRat obchodzą to, instruując użytkowników krok po kroku, jak włączyć instalację z „nieznanych źródeł”.

Po uruchomieniu zainfekowanej aplikacji użytkownik jest proszony o ustawienie jej jako domyślnego programu do obsługi SMS. Ten pojedynczy krok otwiera niezwykle szerokie możliwości. Aplikacja zyskuje kontrolę nad całą warstwą komunikacyjną urządzenia: może odczytywać wiadomości i kody jednorazowe wysyłane przez banki i serwisy internetowe, przechwytywać przychodzące powiadomienia, edytować bazę SMS, a także wysyłać wiadomości w imieniu ofiary. Z perspektywy operatora złośliwego oprogramowania oznacza to zarówno możliwość kradzieży danych uwierzytelniających i przejęcia kont, jak i stworzenie kanału automatycznej propagacji – każda infekcja generuje kolejne, gdy z urządzenia ofiary rozsyłane są wiadomości do całej książki kontaktowej. Z pozostałych funkcjonalności, malware potrafi zbierać metadane o urządzeniu, przeglądać listę zainstalowanych aplikacji, a także używać aparatu do wykonywania zdjęć, które następnie trafiają na serwery C2. Dane przesyłane są przez protokół HTTP, lecz nie w postaci jawnej. Starsze wersje wykorzystywały znaczniki tekstowe, takie jak np. fraza „apezdolskynet”, aby synchronizować komunikację i odróżniać właściwe odpowiedzi C2. W nowszych wariantach operatorzy stosują szyfrowanie AEAD, w tym AES-GCM, co zapewnia zarówno poufność, jak i integralność przesyłanych danych. Infrastruktura ClayRat jest rozproszona i stale rotowana. Domeny kontrolowane przez operatorów działają w krótkich cyklach, często w oparciu o serwery fast-flux i różne TLD, co pozwala na szybkie przemieszczanie hostów stagingowych bez przerywania kampanii. Charakterystyczne są krótkie okresy TTL w rekordach DNS, co ułatwia operatorom natychmiastową zmianę wskazań infrastruktury w przypadku wykrycia.

Cechą charakterystyczną jest także dynamika rozwoju kampanii. Odnotowano ponad 600 próbek w ciągu zaledwie trzech miesięcy, a towarzyszyło im około 50 unikalnych dropperów. Taka skala świadczy o dużych zasobach przeznaczonych na automatyzację procesu kompilacji i testowania. W praktyce każde wykrycie nowego wariantu przez rozwiązania antywirusowe szybko skutkuje wypuszczeniem kolejnego, z nowym sposobem zaciemniania lub nieco inną logiką ładowania zasobów. W efekcie skuteczne wykrywanie opiera się na analizie behawioralnej i monitorowaniu nietypowych aktywności, a nie na prostych sygnaturach. Warte odnotowania są również techniki używane do maskowania obecności w systemie. ClayRat potrafi rejestrować broadcast receivers, które zapewniają mu utrzymanie działalności w tle nawet po zamknięciu aplikacji, a także stosuje mechanizmy opóźnionego startu, aby uniknąć natychmiastowego wykrycia tuż po instalacji. Niektóre warianty korzystają z modularnej architektury – dopiero po wstępnej komunikacji z serwerem C2 pobierane są dodatkowe moduły odpowiedzialne za bardziej agresywne funkcje szpiegowskie. Dzięki temu na wielu urządzeniach malware może pozostawać w trybie uśpienia, czekając na komendę operatora.

ClayRat pokazuje, jak daleko posunęła się ewolucja mobilnego malware. Łańcuch infekcji łączy socjotechnikę, zaawansowane techniki ukrywania payloadu i nadużycia kluczowych uprawnień systemowych, tworząc środowisko trudne do wykrycia i jeszcze trudniejsze do wyeliminowania prostymi metodami. To przykład operacji, w której każde urządzenie staje się jednocześnie źródłem cennych danych i narzędziem propagacji kolejnych infekcji, a odporność całej kampanii wynika z kombinacji szybkiej rotacji wariantów, modularnej architektury i elastycznej infrastruktury C2. Kluczowe znaczenie ma ograniczenie instalacji aplikacji spoza oficjalnego sklepu i stosowanie systemów MDM lub UEM, które wymuszają polityki bezpieczeństwa, a także monitorowanie logów urządzeń pod kątem masowych wysyłek SMS lub połączeń do nieznanych numerów.

Więcej informacji:
https://zimperium.com/blog/clayrat-a-new-android-spyware-targeting-russia

CVE tygodnia

Redishell – podatność w Redis.

W poprzednim tygodniu opublikowana została podatność w Redis, nazwana Redishell. Jak sama nazwa wskazuje, luka CVE-2025-49844 pozwala na zdalne wykonanie kodu (RCE), poprzez wykorzystanie podatności use-after-free w silniku LUA i została wyceniona na 10.0 w skali CVSS. Redis wydał oficjalne oświadczenie z opisem problemu i wersjami zawierającymi poprawki.

W praktyce wykorzystanie tej podatności umożliwia atakującemu, który uzyskał uprzednio dostęp autoryzowany do instancji Redis, eskapadę z piaskownicy interpretera Lua i uruchomienie dowolnych poleceń na hoście, co może prowadzić do pełnego przejęcia systemu, eksfiltracji danych, wdrożenia ransomware lub wykorzystania zasobów do dalszego ruchu bocznego w chmurze. Luka ma szczególnie duże znaczenie, ponieważ Redis jest powszechnie wykorzystywany w środowiskach chmurowych do cache’owania, zarządzania sesjami i jako warstwa pośrednia w architekturze aplikacji co w naturalny sposób poszerza dostępną powierzchnie ataku.

Z punktu widzenia ekspozycji problem ma dwie krytyczne cechy, które należy traktować łącznie. Po pierwsze: oficjalne rekomendacje Redis przypominają, że wykorzystanie podatności wymaga uprzedniego dostępu z autoryzacją do instancji. Po drugie: analiza Wiz ujawnia, że w praktyce setki tysięcy instancji Redis pozostają wystawione do internetu, a znaczący procent tych wdrożeń nie ma skonfigurowanej autoryzacji lub korzysta z kontenerów uruchamianych bez odpowiedniego hardeningu. To połączenie niskiego progu wejścia dla źle skonfigurowanych systemów i wyjątkowo wysokiego potencjału destrukcyjnego sprawia, że należy traktować CVE-2025-49844 jako pilny problem operacyjny.

Natychmiastowe działania, które powinny podjąć zespoły operacyjne, obejmują w pierwszej kolejności jak najszybszą aktualizację wszystkich podatnych instancji Redis do wersji zawierających poprawki wymienione w advisory Redis. W środowiskach zarządzanych przez dostawcę (Redis Cloud) aktualizacje zostały już rozpropagowane, natomiast w środowiskach self-managed konieczne jest natychmiastowe wdrożenie wydanych poprawek bądź tymczasowe ograniczenie ekspozycji sieciowej, w tym całkowite zablokowanie publicznego dostępu do instancji Redis, jeśli taki dostęp istnieje. Redis dodatkowo rekomenduje włączenie trybu protected-mode oraz wymuszenie uwierzytelniania i ograniczenie uprawnień do wykonywania skryptów Lua jedynie do zaufanych tożsamości.

Równolegle do zastosowania poprawek należy wdrożyć praktyki minimalizujące ryzyko ponownego wykorzystania luki: natychmiastowe zablokowanie dostępu sieciowego do instancji Redis z nieznanych adresów, wymuszenie reguł zaporowych i polityk sieciowych ograniczających połączenia jedynie do konkretnych aplikacji lub warstw platformy, audyt konfiguracji kontenerów oraz przywrócenie zasad bezpieczeństwa obrazu (image hardening). Ze względu na powszechne użycie obrazu oficjalnego Dockera, który domyślnie nie wymaga autoryzacji, trzeba priorytetowo traktować kontenery uruchomione bez właściwych mechanizmów uwierzytelnienia.
Warto przeszukać logi pod kątem połączeń z nieautoryzowanych źródeł, wystąpień nieoczekiwanych lub podejrzanych poleceń skryptowych (EVAL, EVALSHA, SCRIPT LOAD), obecności niespodziewanych lub zmodyfikowanych skryptów w bazie danych, nagłych awarii serwera Redis z backtrace’ami wskazującymi na silnik Lua oraz nietypowego ruchu sieciowego wychodzącego z hosta lub zmian w systemie plików dotyczącym katalogów z danymi i konfiguracją Redis.

Dodatkowo zaleca się rotację poświadczeń i kluczy w systemach, które mogły być dostępne z kompromitowanych instancji oraz przegląd polityk backupów, ponieważ pełne przejęcie hosta może skutkować modyfikacją kopii zapasowych.

Więcej informacji:
https://redis.io/blog/security-advisory-cve-2025-49844/
https://www.wiz.io/blog/wiz-research-redis-rce-cve-2025-49844