Krajobraz zagrożeń 25-31/08/25

cert.orange.pl 1 dzień temu

Koniec sierpnia przyniósł głośne analizy ataków, które wzbudziły wiele emocji, więc postanowiliśmy przyjrzeć się publikacjom i realnemu lub potencjalnemu wpływowi opisywanych zagrożeń. Skupiliśmy się na ataku na łańcuch dostaw opisanym przez analityków GTIG oraz Salesloft, który pokazał jak groźne mogą być ataki bez wykorzystania złośliwego oprogramowania. W naszym Krajobrazie nie zabrakło jednak tematu malware, a konkretnie ransomware, którego rozwój przyjmuje różne oblicza. Szczególnie istotnym dla nas okazał się temat rekomendacji w sprawie chińskich ataków na sieci telekomunikacyjne. O tym, co jeszcze działo się w minionym tygodniu przeczytacie poniżej.

Na skróty:

  1. Temat tygodnia: Atak na łańcuch dostaw Salesforce.
  2. Zaawansowane zagrożenia: Ransomware dostosowało się do chmurowej rzeczywistości.
  3. Future: Czy AI-powered ransomware zaszyfruje nas wszystkich?
  4. Telco: Analiza i rekomendacje w obliczu chińskich ataków na sieci telekomunikacyjne.
  5. Cybercrime: Kampania ShadowCaptcha.
  6. CVE Tygodnia: CVE-2025-7775 – Krytyczna podatność RCE w Citrix NetScaler.

Temat tygodnia

Atak na łańcuch dostaw Salesforce.

Pod koniec tygodnia 2025 Google Threat Intelligence Group (GTIG) oraz Salesloft ujawnili masową kampanię prowadzoną przez grupę UNC6395, która przy użyciu integracji Salesloft Drift uzyskiwała dostęp do danych przechowywanych w instancjach Salesforce. Atakujący wykorzystywali skompromitowane tokeny OAuth, które umożliwiały im wykonywanie zapytań do Salesforce, najczęściej ukierunkowanych na pozyskiwanie poświadczeń (np. klucze AWS – AKIA, tokeny do Snowflake, hasła).
Grupa UNC6395 to relatywnie nowy, ale już zauważalny gracz na scenie zagrożeń związanych z bezpieczeństwem środowisk SaaS. W centrum operacji UNC6395 znalazła się platforma CRM Salesforce, a wektor wejścia stanowiła zintegrowana aplikacja Drift – narzędzie wykorzystywane do automatyzacji komunikacji sprzedażowej. Integracja ta została użyta przez grupę do pozyskiwania tokenów OAuth z rozszerzonym zakresem uprawnień. Dzięki nim aktor uzyskał pełen dostęp do danych przechowywanych w Salesforce, a w późniejszym etapie – także do skrzynek pocztowych Google Workspace (wyłącznie tych, które były specjalnie skonfigurowane do integracji z Drift Email).

Warto zaznaczyć, iż kampania nie bazowała na klasycznych exploitach czy phishingu – była to operacja niemal wyłącznie oparta o legalne uprawnienia, co znacznie utrudniło detekcję i klasyfikację działań jako złośliwych. Tokeny OAuth były używane do wysyłania dużej liczby zapytań API typu UniqueQuery, zawężanych do terminów takich jak AKIA, password, secret, snowflake, co sugeruje ukierunkowanie na pozyskiwanie danych uwierzytelniających i kluczy dostępowych do środowisk chmurowych ofiar (np. AWS, Snowflake). Po wykonaniu zapytań atakujący usuwał zadania zapytań, ale logi nie zostały całkowicie skasowane i przez cały czas umożliwiały analizę incydentu.

Rys. Zapytania wykorzystywane w ataku do pozyskiwania danych użytkowników, źródło: Google Threat Intelligence Group

Struktura kampanii przypominała typowe działania APT – z wyraźnym podziałem na fazę rekonesansu, eksfiltracji oraz zacierania śladów. Cechą szczególną, choć występującą coraz częściej był brak wykorzystania złośliwego systemu – cały atak opierał się wyłącznie na nadużyciu zaufania i lukach w polityce zarządzania dostępem zintegrowanych aplikacji firm trzecich. Analiza ujawniła, iż Drift Email – komponent integracji z Gmailem, umożliwił uzyskanie dostępu do danych z kont Google Workspace, kiedy to atakujący wykorzystał tokeny OAuth na bardzo ograniczonej liczbie kont.

Po stronie ofiar – zarówno Salesforce, jak i Salesloft – zareagowały 20 sierpnia 2025 roku, wycofując aplikację Drift z AppExchange i unieważniając wszystkie tokeny OAuth powiązane z tą integracją. 28 sierpnia Google również zareagowało, resetując tokeny i wyłączając rozszerzenie Drift Email.

Choć dotychczasowe ustalenia wskazują, iż bezpośrednio dotknięci zostali głównie klienci wykorzystujący integrację Drift, posiadacze instancji Salesforce, którzy nie korzystają z tego rozwiązania, również powinni zachować wzmożoną czujność. Kampania UNC6395 unaoczniła, iż tokeny OAuth i polityki dostępowe stanowią szczególnie wrażliwy obszar, który może zostać nadużyty także w innych scenariuszach. Dlatego rekomendowane jest przeprowadzenie audytu wszystkich zintegrowanych aplikacji trzecich, ograniczenie ich uprawnień do absolutnego minimum, wprowadzenie restrykcji IP oraz krótszych czasów życia sesji. Niezbędne jest także regularne monitorowanie logów Salesforce (w tym Event Monitoring i zapytań UniqueQuery) pod kątem nietypowych działań, a także przeszukanie obiektów pod kątem obecności sekretów takich jak klucze AWS, tokeny Snowflake czy hasła. Organizacje powinny być przygotowane na natychmiastową rewokację i rotację tokenów OAuth oraz kluczy API w przypadku wykrycia anomalii, a zespoły bezpieczeństwa – posiadać wypracowane procedury reakcji na tego rodzaju incydent.
UNC6395 nie wykorzystuje zaawansowanych exploitów czy malware’u – zamiast tego polega na niedoskonałości polityk bezpieczeństwa, socjotechnice integracyjnej oraz błędach konfiguracyjnych. W długofalowej perspektywie kampania ta może być wstępem do kolejnych ataków, wykorzystujących pozyskane poświadczenia w środowiskach produkcyjnych ofiar. W szczególności zalecana jest analiza obecności tokenów Drift, rewokacja kluczy API i weryfikacja logów pod kątem nietypowych zapytań oraz aktywności pochodzącej z adresów IP powiązanych z infrastrukturą Tor.

Więcej informacji:
https://cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift/

Wybrane zagrożenia tygodnia

Zaawansowane zagrożenia

Ransomware dostosowało się do chmurowej rzeczywistości.

Zespół Microsoft Threat Intelligence obserwując rozwój motywowanego finansowo threat actora Storm-0501 dostrzegł ewolucję technik wykorzystywanych w kampaniach, ze szczególnym naciskiem na środowiska chmurowe i związane z nimi TTP (taktykach, technikach i procedurach). Zauważono przesunięcie głównego celu ataków z infrastruktury on-premise na środowisko chmurowe i przyjęcie taktyk adekwatnych do zaktualizowanego podejścia. Nowe metody eliminują konieczność wykorzystania standardowego złośliwego systemu instalowanego na stacjach roboczych, umożliwiając efektywną eksfiltrację danych, ich niszczenie, a także odcięcie ofiar od kopii zapasowych, przy wykorzystaniu natywnych funkcjonalności platformy Azure.

W artykule opisano poszczególne etapy ataku, które nastąpiły już po uzyskaniu uprawnień administratora domeny, od działań prowadzonych lokalnie, aż po przejęcie kont z odpowiednimi dostępami do przeniesienia operacji do chmury. W części on-premise wskazano na potwierdzanie obecności Windows Defender na systemie i następnie wybieranie do dalszych działań stacji nieobjętych ochroną. Zaobserwowano użycie Evil-WinRM do zdobycia dostępu do innych zasobów oraz atak DCSync do pozyskania poświadczeń i następnie dalszy rekonesans z wykorzystaniem AzureHound. Gdyby nie polityki ograniczonego dostępu i wieloskładnikowe uwierzytelniane już w tym miejscu działania mogłyby przenieść się do chmury, ale konieczne było przejście do innej domeny AD i przejęcie kolejnego serwera Entra Connect. Atakujący poszukiwali kont typu non-human identity (NHI) z przypisaną rolą Global Administrator oraz bez wymogu MFA, co umożliwiało resetowanie haseł i ich synchronizację do chmury. Po uzyskaniu dostępu do portalu Azure, przejmowali role User Access Administrator i Owner, a następnie konfigurowali złośliwą domenę federacyjną, co pozwalało im na utrzymanie stałego, ukrytego dostępu do środowiska chmurowego.

Rys. Część lokalna łańcucha ataku Storm-0501. Źródło: Microsoft

Kolejny etap obejmował eskalację uprawnień, eksfiltrację danych oraz ich usuwanie. Dla danych, których nie dało się trwale usunąć, wykorzystywano natywne mechanizmy szyfrowania Azure, a następnie usuwano klucze szyfrujące z Key Vault, co miało uniemożliwić ich odzyskanie. Analitycy Microsoft zwrócili uwagę, iż w przypadku tych ostatnich działań, skuteczność może być niska ze względu na mechanizm Soft-Delete dla kluczy umożliwiający ich odzyskanie w ciągu 90 dni od usunięcia. Większość działań wykorzystywała natywne rozwiązania i funkcje dostępne w chmurze Azure zarówno w zakresie usuwania danych, ich szyfrowania oraz eksfiltracji (funkcja AZCopy). Ostatnim etapem ataku było żądanie okupu, które zostało przekazane poprzez Microsoft Teams dzięki przejętego konta użytkownika.

Rys. Część chmurowa łańcucha ataku Storm-0501. Źródło: Microsoft

Łańcuch ataku na pewno będzie rozwijany i ulepszany, więc już teraz warto przyjrzeć się zabezpieczeniom w swojej infrastrukturze chmurowej. Cele Storm-0501 są określane jako oportunistyczne, więc zagrożenie może czyhać na każdą firmę lub organizację, która okaże się dla atakujących osiągalna. Grupy motywowane finansowo nie muszą uderzać w strategicznie istotną infrastrukturę ani duże korporacje, ponieważ liczy się dla nich potencjalna skuteczność szantażu i w efekcie otrzymanie okupu za przywrócenie dostępu do danych. Do fundamentalnych działań do podjęcia w wykorzystywanym środowisku chmurowym można zaliczyć przygotowanie oraz testowanie procedur reagowania na incydenty w chmurze i weryfikacja lub implementacja konfiguracji gwarantującej widoczność niepożądanych działań. Ponadto, Microsoft przygotował obszerne rekomendacje dotyczące wykrywania opisywanych w artykule ataków i zapobiegania im, z którymi polecamy się zapoznać.

Więcej informacji:
https://www.microsoft.com/en-us/security/blog/2025/08/27/storm-0501s-evolving-techniques-lead-to-cloud-based-ransomware/

Future

Czy AI-powered ransomware zaszyfruje nas wszystkich?

Wykorzystanie sztucznej inteligencji i dużych modeli językowych w działalności cyberprzestępców to temat, który budzi zarówno ciekawość, jak i niepokój. Analitycy ESET poinformowali o odkryciu pierwszego znanego ransomware napędzanego AI nazwanego przez nich PromptLock. Ale czy to odkrycie zwiastuje rewolucję w tym jak działają twórcy i operatorzy złośliwego systemu szyfrującego? PromptLock nie został jeszcze zaobserwowany w prawdziwych atakach, a odkryta próbka to prawdopodobnie Proof-of-Concept lub przez cały czas rozwijany eksperyment.

Według artykułu to złośliwe oprogramowanie napisane w języku Go wykorzystuje lokalnie model OpenAI gpt-oss-20b poprzez API Ollama do wygenerowania skryptów Lua. Skrypty są generowane z promptów wpisanych w kod PromptLocka. Po wykonaniu złośliwe oprogramowanie enumeruje pliki w lokalnym systemie i je analizuje, eksfiltruje wybrane i szyfruje dane. Analitycy zaobserwowali w bazie VirusTotal próbki działająca zarówno na systemach Windows, jak i Linux.

Poza krótkim opisem działania tego złośliwego systemu w artykule znalazły się także hashe próbek zidentyfikowanych jako PromptLock. Mogą się one przydać szczególnie badaczom zainteresowanym trendami w złośliwym oprogramowaniu. Szczególnie interesujące dla nas okazały się wykorzystywane przez twórców prompty widoczne w kodzie PromptLocka. Polecenia są stosowane między innymi do:

    1. analizy plików i ich zawartości,

      Rys. Prompt służący do generowania kodu identyfikującego pliki z wrażliwymi lub istotnymi informacjami. Źródło: jedna z próbek dostępna na VirusTotal.

    2. wykrywania parametrów systemowych,
    3. generowania listy plików, ich wielokrotnego nadpisywania i usunięcia,

      Rys. Prompt generujący kod usuwający pliki. Źródło: jedna z próbek dostępna na VirusTotal.

    4. potwierdzania poprawności wygenerowanego kodu,

      Rys. Prompt z użyciem sformułowania „jesteś walidatorem kodu Lua, sprawdź, czy kod działa prawidłowo”. Źródło: jedna z próbek dostępna na VirusTotal.

    5. generowania treści tzw. ransom note.

      Rys. Instrukcje generowania notatki zależnej od wcześniej stworzonego payloadu i plików dotkniętych atakiem. Źródło: jedna z próbek dostępna na VirusTotal.

Dynamiczne generowanie skryptów za każdym wykonaniem złośliwego systemu może utrudnić wykrywanie dzięki unikalnych hashy, ale reguły behawioralne bazujące na zachowaniu ransomware i anomaliach na stacjach roboczych powinny być niezmiennie skuteczne. Dostępność LLM-ów sprawia, iż atakującym łatwiej jest stworzyć złośliwe oprogramowanie, strony lub wiadomości phishingowe i komunikować się z ofiarami, ale zbyt duże poleganie na takich narzędziach może się wiązać z niedociągnięciami i błędami. W efekcie taki malware może być mniej skuteczny i bardziej nieprzewidywalny.

Otwartą kwestią pozostaje, czy zaobserwujemy to złośliwe oprogramowanie w atakach. Przypominamy, iż malware z funkcją generowania fragmentów kodu z pomocą dużego modelu językowego został już zaobserwowany w atakach i opisany przez CERT UA w lipcu tego roku o czym pisaliśmy w naszym krajobrazie
https://cert.orange.pl/cyber-threat-intelligence/krajobraz-zagrozen-14-20-07-25/#future.

Więcej informacji:
https://www.welivesecurity.com/en/ransomware/first-known-ai-powered-ransomware-uncovered-eset-research/

Telco

Analiza i rekomendacje w obliczu chińskich ataków na sieci telekomunikacyjne.

W ostatnich dniach sierpnia koalicja służb USA oraz ich sojuszników opublikowała wspólną analizę, rekomendacje i techniczny poradnik (Joint Cybersecurity Advisory) mający na celu zwiększenie możliwości przeciwdziałania zaawansowanym atakom ze strony chińskich grup APT. Dokument opisuje skoordynowaną, wieloletnią kampanię chińskich aktorów APT wymierzoną w globalną instrastrukturę sieciową na całym świecie, ze szczególnym naciskiem na telekomunikacyjne urządzenia brzegowe i szkieletowe, w celu budowy globalnego systemu szpiegowskiego opartego na stałym, trudnym do wykrycia dostępie do ruterów i łączy międzyoperatorskich. Ataki obserwowano m.in. w USA, Australii, Kanadzie, Nowej Zelandii, Wielkiej Brytanii i innych regionach. W stworzeniu raportu i rekomendacji udział brały również polskie służby: Służba Kontrwywiadu Wojskowego oraz Agencja Wywiadu.

W opisywanych atakach, threat aktorzy koncentrowali się na ruterach szkieletowych operatorów, urządzeniach PE (Provider Edge) oraz CE (Customer Edge) i wykorzystują zaufane relacje między sieciami, aby przemieszczać się do kolejnych środowisk. Ich celem jest utrzymanie długotrwałej obecności, przechwytywanie ruchu i wykradanie danych bez wzbudzania alarmów.

Urządzenia PE i CE to pojęcia z architektury sieci operatorskich – zwłaszcza tam, gdzie używa się technologii MPLS (Multi-Protocol Label Switching). PE – Provider Edge router – to router znajdujący się na brzegu sieci operatora (ISP, telco). Łączy sieć szkieletową operatora (tzw. core) z siecią klienta. Jest odpowiedzialny m.in. za obsługę protokołów routingu z klientem (np. BGP), nakładanie i zdejmowanie etykiet MPLS oraz separację ruchu (np. w VPN MPLS). CE – Customer Edge router – to router po stronie klienta, który łączy jego sieć wewnętrzną (LAN, data center, oddziały) z siecią operatora. CE wymienia trasy tylko z routerem PE, nie ma wglądu w całą sieć operatorską. W praktyce PE pozostaje pod kontrolą operatora, natomiast CE należy do klienta i jest przez niego zarządzany. Właśnie te punkty styku – PE i CE – są bardzo atrakcyjne dla APT, ponieważ ich kompromitacja umożliwia przechwytywanie ruchu między klientem a operatorem lub pivotowanie do innych sieci w oparciu o zaufane relacje routingu.

Tło operacji wskazuje na powiązania z chińskimi podmiotami komercyjnymi wspierającymi służby wywiadowcze, w tym co najmniej Sichuan Juxinhe Network Technology, Beijing Huanyu Tianqiong Information Technology i Sichuan Zhixin Ruijie Network Technology. Dane pozyskiwane w telekomach/ISP oraz wtargnięcia w sektor zakwaterowania i transportu mają umożliwiać identyfikację i śledzenie komunikacji i ruchów wybranych celów na całym świecie. Kampania częściowo pokrywa się z nazwami używanymi przez firmy analityczne (m.in. Salt Typhoon, OPERATOR PANDA, RedMike, UNC5807, GhostEmperor), choć autorzy raportu zaznaczają, iż opisywane ataki to nie koniecznie jedna grupa i doradzają traktowanie ich łącznie jako klastra aktywności.

Profil techniczny zagrożenia wskazuje, iż początkowy dostęp uzyskiwany jest przede wszystkim poprzez powszechnie znane, publiczne CVE i inne uchybienia konfiguracyjne – nie odnotowano konieczności użycia zero-day. Warto wyróżnić łańcuch nadużyć interfejsu Web UI w Cisco IOS XE: autoryzację obchodzono przez WSMA (/webui_wsma_Http/Https) z charakterystycznym „podwójnym kodowaniem” ścieżki, po czym następowała eskalacja uprawnień (CVE-2023-20198 łączony z CVE-2023-20273). Równolegle nadużywane były luki w Ivanti Connect/Policy Secure (CVE-2024-21887 połączone z CVE-2023-46805) i PAN-OS GlobalProtect (CVE-2024-3400), a także starszy Smart Install w Cisco (CVE-2018-0171). Aktorzy chętnie wykorzystują też relacje zaufania między dostawcami (pivoting przez interkonekty provider-to-provider / provider-to-customer). W nomenklaturze MITRE ATT&CK najważniejsze są m.in. T1190 (Exploit Public-Facing Application) oraz T1199 (Trusted Relationship).

Utrzymywanie dostępu realizowane jest przez zestaw działań rekonfiguracyjnych na urządzeniach sieciowych, które dodatkowo utrudniają atrybucję, bo w logach operacje wyglądają jak pochodzące z adresów lokalnych. W praktyce obserwowano dodawanie wpisów do ACL (często listy nazwane „access-list 20”, a gdy zajęta – „50” lub „10”), otwieranie usług na standardowych i niestandardowych portach (SSH/SFTP/RDP/FTP/HTTP/HTTPS), w tym SSH na wysokich portach o wzorcu 22×22 lub xxx22 oraz włączanie HTTP/HTTPS management na portach 18xxx; dodawanie kluczy do istniejących usług SSH, a także tworzenie lokalnych kont uprzywilejowanych. Polecenia wykonywano przez SNMP, SSH i żądania HTTP GET/POST do ścieżek uprzywilejowanych (np. /level/15/exec/-/*). W wielu incydentach nadużyto kontenerów linuksowych na urządzeniach Cisco (Guest Shell/IOx) do ładowania narzędzi, lokalnego przetwarzania artefaktów i ruchu bocznego; uruchamiano Python (np. siet.py do Smart Install), skrypty Tcl (tclsh: TCLproxy.tcl, map.tcl), a inwentaryzację i zmiany w sąsiednich urządzeniach realizowano przez SNMP GET/WALK/SET. W MITRE odpowiada to m.in. T1562.004 (modyfikacje zasad), T1071/T1571 (usługi i porty niestandardowe), T1021.004/T1059.008/T1569 (zdalne wykonanie poleceń), T1610/T1059.006/T1588.002/.005 (kontenery i pozyskanie narzędzi).

Ruch poziomy (Lateral Movement) i pozyskiwanie danych opierają się na modyfikacji routingu, kopiowaniu (mirroring) ruchu sieciowego (SPAN/RSPAN/ERSPAN) oraz zestawianiu tuneli GRE/IPsec i tras statycznych, co pozwala prowadzić komunikację C2 i eksfiltrację w kanałach łatwo mieszających się z ruchem tła. Przez zaufane łącza operatorskie APT przechodzą do sieci klientów lub innych dostawców, choćby jeżeli pierwotny cel nie jest obiektem zainteresowania. W efekcie pojedyncza kompromitacja rutera może stać się węzłem obserwacyjno-tranzytowym dla dużych wolumenów ruchu. Technicznie odpowiada to technika MITRE T1095/T1572 (tunneling), przy jednoczesnym wykorzystaniu T1199 (pivot przez relacje zaufania).

Szczególnie wymowny jest opis pozyskiwania poświadczeń przez natywne przechwytywanie pakietów na ruterach (Cisco Embedded Packet Capture). Aktorzy konfigurowali selektywne PCAP-y pod TACACS+ na porcie TCP 49, eksportowali pliki na pamięć urządzenia (np. bootflash: tac.pcap) i pobierali je przez FTP/TFTP. o ile w konfiguracji znajdował się współdzielony sekret TACACS+ zapisany słabym mechanizmem Cisco Type 7, możliwy był do odszyfrowania i przejęcia kont administracyjnych. Uzupełniająco modyfikowano konfigurację AAA/TACACS+/RADIUS, aby kierować uwierzytelnienie do infrastruktury APT lub wymuszać mniej bezpieczne metody. Pozyskane w ten sposób dane ułatwiały ruch poziomy i rozszerzanie kompromitacji. Eksfiltracja i C2 prowadzone były często przez oddzielne kanały tunelowane (GRE/IPsec), tak aby wtopić się w NAT-y, pule proxy i węzły o dużym natężeniu ruchu.

Warte odnotowania są dedykowane, pisane w Go klienty SFTP (cmd1, cmd3, new2, sft), które służyły do przenoszenia zaszyfrowanych archiwów z sieci ofiary na hosty pośrednie. „cmd1” posiadał dodatkowo wbudowaną logikę zbierania PCAP (komendy „monitor capture … export …”), co łączyło funkcje kolekcji i transportu w jednym pliku binarnym. Dokument zawiera wskaźniki kompromitacji i ataku (IoC/IoA) oraz reguły YARA ułatwiające ich detekcję.

W wymiarze sektorowym kampania uderza przede wszystkim w telekomunikację i operatorów usług internetowych, ale również w administrację publiczną, transport, usługi hotelarskie oraz infrastrukturę wojskową, przy czym atakowane są zarówno środowiska wewnętrzne organizacji, jak i te świadczące usługi bezpośrednio dla klientów. Wnioski autorów są jednoznaczne: poprzez długotrwałe osadzenie w urządzeniach routujących przeciwnik uzyskuje zdolność systematycznego śledzenia komunikacji i ruchów osób oraz podmiotów, co ma duże znacznie strategiczne (w znaczeniu wywiadowczym).

Tożsamościowo mamy do czynienia z klastrem aktorów sponsorowanych przez państwo chińskie, powiązanych z jednostkami PLA/MSS i ekosystemem firm dostarczających „produkty i usługi cyber” na potrzeby służb. Część kampanii mapuje się na znane etykiety branżowe (Salt Typhoon, OPERATOR PANDA, RedMike, UNC5807, GhostEmperor), jednak wnioski z wielu dochodzeń sugerują współdzielenie TTP i infrastruktury. W warstwie C2 obserwowano korzystanie z VPS-ów, łańcuchowych proxy i narzędzi do wieloskokowego routingu operatora, co wspiera ukrywanie oraz redundancję kanałów komunikacji.

Z perspektywy obronnej autorzy akcentują, iż skuteczność aktorów wynika nie z zaawansowanych 0-day, ale z szybkiego wykorzystywania publicznych podatności, luk konfiguracyjnych i „wysp” słabego nadzoru na urządzeniach sieciowych. Priorytetem jest więc ścisłe zarządzanie poprawkami dla brzegowych komponentów sieciowych, rygorystyczne AAA (SNMPv3/USM+VACM, kontrola kont lokalnych i kluczy), monitoring zmian konfiguracji, tras i tuneli, rejestrowanie aktywności kontenerów i usług zarządczych oraz uważne sekwencjonowanie działań w Incident Response, aby nie ujawniać częściowych prób „wybijania” przeciwnika i nie tracić pełnego obrazu dostępu.

Dokument zawiera obszerną listę technicznych zaleceń i wskaźników (IoC/IoA). Jednak zasadniczo można wyciągnąć wniosek, iż z operacyjnego punktu widzenia, kluczowym elementem jest panowanie nad routerami – kto ma dostęp i panuje nad konfiguracją, ten panuje nad ruchem sieciowym.

Więcej informacji:
https://media.defense.gov/2025/Aug/22/2003786665/-1/-1/0/CSA_COUNTERING_CHINA_STATE_ACTORS_COMPROMISE_OF_NETWORKS.PDF
https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4287371/nsa-and-others-provide-guidance-to-counter-china-state-sponsored-actors-targeti/

Cybercrime

Kampania ShadowCaptcha.

W sierpniu 2025 roku, badacze z Israel National Digital Agency odkryli trwającą na masową skalę kampanię ClickFix’ową, którą nazwali „ShadowCaptcha”. Kampania wykorzystuje fałszywe strony z weryfikacją CAPTCHA, podszywające się pod Google lub Cloudflare i próbuje wymusić na użytkowniku wykonanie złośliwych komend na swoim systemie. Ostatecznie atak może prowadzić do instalacji systemu ransomware, infostealer czy cryptominer. Analiza wskazała na ponad 100 skompromitowanych stron na WordPress, na całym świecie. Są to tylko witryny zgłoszone do VirusTotal, przewiduje się, iż w rzeczywistości skala zainfekowanych stron jest dużo większa.

Atak rozpoczyna się od infekcji witryny WordPress złośliwym skryptem JavaScript, który przekierowuje użytkownika do domeny kontrolowanej przez threat actora. Ta pośrednia strona analizuje ruch oraz skuteczność infekcji i dopiero wtedy przekierowuje do adekwatnej strony ClickFix. Zaimplementowano również mechanizmy ograniczające dostęp do ClickFix, mające na celu blokowanie skanerów, crawlerów i analityków.

Rys. I wariant, ClickFIx podszywający się pod CAPTCHA Google; Źródło: Raport Israel National Digital Agency „ShadowCaptcha”
Rys. I wariant, ClickFIx podszywający się pod Cloudflare; Źródło: Raport Israel National Digital Agency „ShadowCaptcha”

W kampanii wyróżniono dwa warianty ClickFixów. W pierwszym, ofiara zostaje poinstruowana do naciśnięcia Windows+R i wklejenia zawartości schowka, jednak w schowku znajduje się złośliwy payload, który został tam umieszczony dzięki skryptu zawartego na stronie, bez żadnej interakcji użytkownika. W drugim wariancie użytkownik dostaje polecenie zapisania strony jako plik .hta. Następnie wykonanie tego pliku dzięki Microsoft HTML Application Host (mshta.exe).

Rys. II wariant, zapisanie strony jako plik .hta i wykonanie go dzięki mshta.exe; Źródło: Raport Israel National Digital Agency „ShadowCaptcha”

Dalej w przypadku I wariantu, wykorzystywany jest DLL sideloading, czyli wykorzystanie zweryfikowanego oprogramowania, i ładowania do niego złośliwych bibliotek DLL. Atakujący sprytnie wykorzystali Windows DLL search order, umieszczając w tym samym folderze zweryfikowaną i złośliwą bibliotekę DLL, co skutkowało załadowaniem złośliwej biblioteki. II wariant korzystał ze swoich większych uprawnień, więc pobierał i wykonywał pliki .exe bezpośrednio dzięki Powershella. Po zainfekowaniu systemu, zaobserwowano różne wykorzystanie dostępu do hosta.

W przypadku I wariantu, na hoście następowało ulokowanie infostealera lub kombinacji infostealer i cryptominer. W przypadku infostealerów, zaobserwowano użycie wariantów Lumma Stealer i Rhadamanthys Stealer (RadThief). Co interesujące Lumma Stealer może zainstalować złośliwe rozszerzenie do przeglądarki Chrome, podszywające się pod „Save to Google Drive”, służy do utrzymania trwałego dostępu i zbierania informacji z aktywności w przeglądarce. Natomiast do kopania kryptowalut, ulokowywane są: Monero Miner (jako WidgetService.exe) i WinRing0x64. Koparka jest ustawiona na agresywne kopanie, i łączy się przez TLS do infrastruktury atakującego. Niektóre warianty koparki pobierają konfigurację z Pastebin, co pozwala na rotację portfelami czy zmienianie parametrów kopania.

W II wariancie instalowany był ransomware Epsilon Red – znany z wykorzystywania PowerShell i plików HTA. Szyfrował pliki zarówno na dysku lokalnym, jak i dyskach sieciowych, oraz wyłączał usługi bezpieczeństwa. Po zakończeniu ataku wyświetlana była notatka z żądaniem okupu.

W opisywanej kampanii zauważono użycie wielu warstw persystencji i technik unikania wykrycia, między innymi: zaplanowane zadania, podszywanie się pod prawdziwe procesy, DLL Side-loading, zaciemnianie skryptów Powershell, wykorzystywanie podatności w sterownikach, wyłączenie usług bezpieczeństwa/przywracania i wyłączenie logów oraz powiadomień.

Rys. Schemat ataku, z różnymi możliwymi wariantami;
Źródło: Raport Israel National Digital Agency „ShadowCaptcha”

ShadowCaptcha to przykład modelu Malware-as-a-Service, gdzie operatorzy infrastruktury skupiają odpowiadają za dystrybucję złośliwego systemu poprzez strony ClickFix i zainfekowane WordPressy. Afilianci uzyskują dostęp do platformy, która umożliwia im przesyłanie własnych ładunków — najczęściej infostealerów, cryptominerów lub ransomware. Kampania pokazuje, jak daleko posunęła się ewolucja socjotechnicznych wektorów ataku, które dziś funkcjonują jako złożone, wielowarstwowe operacje cyberprzestępcze z globalnym zasięgiem i skutecznym wykorzystaniem technik maskujących.

Więcej informacji:
https://www.gov.il/BlobFolder/news/shadowcaptch-campaign/he/From%20CAPTCHA%20to%20Full-System%20Compromise%20Inside%20the%20ShadowCaptcha%20Global%20Cybercrime%20Campaign.pdf

CVE tygodnia

CVE-2025-7775 – Krytyczna podatność RCE w Citrix NetScaler.

26 sierpnia 2025 firma Citrix ujawniła krytyczną lukę CVE‑2025‑7775 (CVSS 3.1: 9.8), dotyczącą przepełnienia pamięci w urządzeniach NetScaler ADC i NetScaler Gateway. Luka umożliwia zdalne wykonanie kodu (RCE) lub wywołanie Denial-of-Service (DoS), bez potrzeby uwierzytelnienia. Wykorzystanie podatności możliwe jest tylko pod konkretnymi warunkami konfiguracyjnymi:

  • NetScaler skonfigurowany jako Gateway (VPN virtual server, ICA Proxy, CVPN, RDP Proxy),
  • NetScaler skonfigurowany jako AAA virutal server,
  • NetScaler ADC/Gateway w wersjach 13.1, 14.1, 13.1-FIPS, NDcPP skonfigurowany jako LB virtual server typu HTTP/SSL/HTTP_QUIC powiązanych z usługami lub serwisami IPv6 (także DBS IPv6),
  • NetScaler skonfigurowany jako CR virutal server typu HDX.

Citrix poinformował, iż obserwowane były próby wykorzystania podatności CVE-2025-7775 na niezabezpieczonych urządzeniach, a CISA gwałtownie dodała ją do katalogu Known Exploited Vulnerabilities (KEV), co potwierdza realne zagrożenie jej aktywnym wykorzystaniem.

Ponadto, badacze bezpieczeństwa wskazują, iż atakujący mogli wykorzystywać tę lukę do instalacji webshelli, co świadczy o zaawansowanej kampanii z elementem utrzymania dostępu.

Od 28 sierpnia 2025 dostępne są także publiczne Proof‑of‑Concept (PoC) opublikowane w repozytorium w Githubie, co znacząco podnosi ryzyko masowych skanów i ataków.

Podatnością dotknięte są urządzenia:

  • NetScaler ADC/Gateway 14.1 przed 14.1-47.48,
  • NetScaler ADC/Gateway 13.1 przed 13.1-59.22,
  • NetScaler ADC 13.1-FIPS / NDcPP przed 13.1-37.241,
  • NetScaler ADC 12.1-FIPS / NDcPP przed 12.1-55.330.

Producent zaleca natychmiastową aktualizację systemu do niepodatnej wersji.

Więcej informacji:
https://support.citrix.com/support-home/kbsearch/article?articleNumber=CTX694938&articleTitle=NetScaler_ADC_and_NetScaler_Gateway_Security_Bulletin_for_CVE_2025_7775_CVE_2025_7776_and_CVE_2025_8424
https://www.cisa.gov/known-exploited-vulnerabilities-catalog
https://cyberplace.social/@GossiTheDog/115095063936712306
https://github.com/projectdiscovery/nuclei-templates/issues/13025

Idź do oryginalnego materiału