Wojciech Ciemski, Autor w serwisie Security Bez Tabu - Strona 453 z 464

Autor: Wojciech Ciemski

Everest ransomware bierze na siebie odpowiedzialność za atak na Collins Aerospace. Co to oznacza dla lotnictwa w Europie?

Wprowadzenie do problemu / definicja luki

Grupa ransomware Everest ogłosiła, że to ona stoi za włamaniem do Collins Aerospace (spółka RTX), którego skutki odczuwalne były w całej Europie — od paraliżu odpraw po wielogodzinne opóźnienia. Nowa deklaracja na stronie wycieków grupy pojawiła się 17–18 października 2025 r., kilka tygodni po tym, jak Collins potwierdził incydent ransomware dotyczący oprogramowania do boardingu pasażerów. Wcześniej służby i media nie wskazywały jednoznacznie sprawców ataku.

W skrócie

  • Co się stało: Collins Aerospace padł ofiarą ataku ransomware, który zakłócił odprawy i nadawanie bagażu na lotniskach m.in. w Londynie (Heathrow), Brukseli, Dublinie i Berlinie. ENISA potwierdziła charakter ataku jako ransomware.
  • Nowy element: Grupa Everest publicznie przypisała sobie odpowiedzialność i zapowiedziała publikację wykradzionych danych.
  • Stan formalny: RTX w zgłoszeniu inwestorskim podał, że chodziło o oprogramowanie do boardingu pasażerów; spółka nie spodziewa się istotnego wpływu finansowego. Równolegle w Wielkiej Brytanii zatrzymano (warunkowo zwolniono) mężczyznę w związku ze sprawą, lecz śledztwo trwa.

Kontekst / historia / powiązania

Atak z września 2025 r. wymusił ręczną obsługę pasażerów na wielu lotniskach i spowodował odwołania lotów. W tamtym czasie nie było potwierdzonej identyfikacji grupy. Dopiero teraz Everest przypisuje sobie odpowiedzialność, ujawniając wpis na stronie wycieków i zapowiadając „transze” danych. Media branżowe i regionalne odnotowały ten zwrot, podkreślając związek ze wcześniejszym chaosem na lotniskach.

Analiza techniczna / szczegóły luki

  • Wektor uderzenia: RTX wskazał na „passenger boarding software” – klasę systemów krytycznych dla procesu odprawy i wejścia na pokład (CUTE/CUPPS), wdrażanych u wielu przewoźników i operatorów. Uderzenie w taką warstwę oprogramowania ma efekt kaskadowy (łańcuch dostaw).
  • Taktyki sprawców (TTPs) – wnioskowanie na podstawie znanych kampanii ransomware i deklaracji Everest: kradzież danych (double extortion), szyfrowanie zasobów produkcyjnych, groźba publikacji danych w razie braku okupu. Informacje z wpisów monitorujących leak-site Everest wskazują na publikację wpisu dotyczącego Collins/RTX w dniach 17–18 października.
  • Skala i propagacja zakłóceń: zakłócenia objęły wiele hubów (Heathrow, Bruksela, Berlin, Dublin), co potwierdza wrażliwość sektora lotniczego na jednopunktowe awarie po stronie dostawcy.

Praktyczne konsekwencje / ryzyko

  • Ryzyko operacyjne: przestoje w odprawach, ręczne procesy, korki w terminalach, utrata slotów, domino w siatce połączeń.
  • Ryzyko prawne i reputacyjne: potencjalny wyciek danych pasażerów lub partnerów, presja regulacyjna (NIS2, RODO), roszczenia kontraktowe. (Deklaracje publikacji danych przez Everest zwiększają ryzyko wtórnych nadużyć).
  • Ryzyko finansowe: choć RTX raportował brak „materialnego” wpływu, koszty incydentu po stronie linii i lotnisk (opóźnienia, personel, rekompensaty) mogą być znaczące – zwykle nieujmowane w raporcie dostawcy.

Rekomendacje operacyjne / co zrobić teraz

Dla operatorów lotnisk i linii lotniczych:

  1. Modelowanie ryzyka łańcucha dostaw (CUPPS/CUTE/MUSE i integracje) – klasyfikacja komponentów „single point of failure”, audyty i plany awaryjne z realnym RTO/RPO.
  2. Segmentacja i „blast radius” – oddzielenie sieci operacyjnych (airside/landsid e), kontrola lateral movement, tiered admin, „break-glass” konta offline.
  3. Kontrole tożsamości – phishing-resistant MFA dla kont uprzywilejowanych, rotacja kluczy API integrujących DCS/Departure Control.
  4. Telemetria i EDR/XDR – pełne logowanie na serwerach aplikacyjnych i brokerach integracyjnych (SITA/Amadeus itp.), korelacja zdarzeń z IOC/TTP grup ransomware.
  5. Kopie zapasowe i runbooki manualne – offline immutable backups + ćwiczenia tabletop z przejściem na manual check-in/boarding.
  6. Zarządzanie dostawcami – kontraktowe SLA bezpieczeństwa, SBOM, dowody testów backup/restore, regularne red team/supply chain ćwiczenia.

Dla dostawców oprogramowania lotniczego:

  1. Bezpieczny rozwój i hardening (CISA/ENISA good practices dla oprogramowania krytycznego), izolacja tenantów, kontrola aktualizacji.
  2. Detekcja exfiltracji – DLP na warstwie aplikacyjnej, egress filtering, honeytokens w danych PII.
  3. Plan odpowiedzialnej komunikacji – spójne advisory dla klientów (IOC, TTP, reguły detekcji, kroki naprawcze).

(Praktyki powyżej wynikają z dobrych praktyk dla incydentów ransomware w infrastrukturze krytycznej oraz z charakteru tego ataku potwierdzonego przez RTX/ENISA).

Różnice / porównania z innymi przypadkami

  • Wobec typowych ataków na linie lotnicze: tu głównym celem był dostawca oprogramowania, a nie pojedynczy przewoźnik. To tłumaczy szeroki, wielolotniskowy efekt.
  • Na tle „głośnych” kampanii (np. Scattered Spider): motywacja Everest wpisuje się w trend łączenia okupu z „prestiżem” w środowisku przestępczym – co podkreślali eksperci po wrześniowym chaosie.

Podsumowanie / kluczowe wnioski

  • Deklaracja Everest domyka najważniejszy znak zapytania: kto uderzył w Collins Aerospace. Formalnego potwierdzenia organów na razie brak, ale wpisy na leak-site i relacje branżowe są spójne czasowo.
  • Rdzeniem incydentu był atak ransomware na oprogramowanie do boardingu, co obnażyło kruchość łańcucha dostaw lotniczych.
  • Organizacje lotnicze powinny potraktować zdarzenie jako case study i wzmocnić segmentację, planowanie ciągłości działania oraz egzekwowanie wymagań bezpieczeństwa wobec dostawców.

Źródła / bibliografia

  • Cybersecurity Dive: „RTX confirms hack of passenger boarding software involved ransomware” (26 września 2025). (Cybersecurity Dive)
  • Reuters: „Airport chaos highlights rise in high-profile ransomware attacks…” (22 września 2025). (Reuters)
  • Reuters: „UK police arrest man over hack that affected European airports” (24 września 2025). (Reuters)
  • CyberNews: „Collins Aerospace attack claimed by Everest…” (18 października 2025). (Cybernews)
  • Security Affairs: „Everest Gang takes credit for Collins Aerospace breach” (18 października 2025). (Security Affairs)

Chiny oskarżają USA o włamania do Narodowego Centrum Czasu. Co wiemy i co to oznacza dla bezpieczeństwa krytycznej synchronizacji?

Wprowadzenie do problemu / definicja luki

19 października 2025 r. Ministerstwo Bezpieczeństwa Państwowego (MSS) ChRL oskarżyło amerykańską NSA o wieloletnie operacje cybernetyczne wymierzone w National Time Service Center (NTSC) – instytut Chińskiej Akademii Nauk odpowiedzialny za generowanie, utrzymanie i emisję czasu urzędowego. Zdaniem MSS ataki mogły zagrozić łączności, systemom finansowym, dostawom energii oraz nawet międzynarodowej synchronizacji czasu. Strona amerykańska nie skomentowała sprawy.

W skrócie

  • MSS twierdzi, że NSA od 2022 r. wykorzystywała podatność w komunikatorze „zagranicznej marki smartfonów” do szpiegowania pracowników NTSC i kradzieży danych/poświadczeń.
  • W latach 2023–2024 miały następować próby włamań do sieci wewnętrznych i wysokoprecyzyjnych naziemnych systemów czasu.
  • W osobnym materiale opisano użycie „42 wyspecjalizowanych narzędzi cyber” – to szczegół podany w relacjach agencyjnych, niepoparty publicznie dowodami technicznymi.
  • Ryzykiem objęte są systemy oparte na synchronizacji (telekomy, giełdy, energetyka, transport). CISA od lat ostrzega, że dokładny, zaufany czas to element krytycznej infrastruktury IT/OT.

Kontekst / historia / powiązania

Wzajemne oskarżenia USA–Chiny o cyberszpiegostwo są stałym elementem napięć geopolitycznych i handlowych. Najnowszy epizod pojawia się równolegle z tarciami handlowymi (m.in. nadzór nad eksportem metali ziem rzadkich i groźby wyższych ceł), co nadaje sprawie wymiar polityczny.

Analiza techniczna / szczegóły luki

Wejście początkowe (initial access). MSS twierdzi, że wektor stanowiła podatność w usłudze wiadomości SMS/IM na „zagranicznych” telefonach używanych przez personel NTSC. Kompromitacja urządzeń mobilnych pracowników to klasyczny sposób pozyskania poświadczeń i informacji o topologii sieci, które później służą do ruchu lateralnego. (Szczegółów CVE brak w domenie publicznej).

Eskalacja i rekonesans. Po kradzieży poświadczeń miały następować próby uzyskania dostępu do sieci wewnętrznej NTSC i komponentów „wysokoprecyzyjnego, naziemnego systemu czasu” – co sugeruje cel w warstwie dystrybucji sygnału (serwery NTP/PTP, koncentratory GNSS, zegary rubidowe/cezowe).

Dlaczego czas jest tak wrażliwy? W środowiskach ICS/OT centralne serwery czasu bywają w płaskich segmentach i nie zawsze są filtrowane wyłącznie do NTP/PTP; błędna konfiguracja może otwierać drogę do ingerencji w automatyzację i sterowanie. Badania z 2025 r. pokazują, jak „master clock” może stać się punktem awarii całych systemów.

Techniki ATT&CK. Operacje przeciwko infrastrukturze czasu typowo obejmują m.in. Credential Access, Lateral Movement, manipulację protokołami NTP/PTP oraz rozpoznanie czasu/systemu (T1124). Choć obecne doniesienia nie ujawniają TTP konkretnych narzędzi, wzorce te są zgodne z opisami w MITRE.

Praktyczne konsekwencje / ryzyko

Zakłócenie referencyjnych źródeł czasu może kaskadowo uderzyć w:

  • Telekomunikację: utrata synchronizacji w sieciach komórkowych (TDM/SyncE/PTP) powoduje degradację jakości i niedostępność usług.
  • Finanse: stemple czasowe w MIFID II/Reg NMS i systemach rozliczeniowych wymagają ścisłej tolerancji; dryft = niezgodność i ryzyko operacyjne.
  • Energetykę/OT: błędna korelacja zdarzeń i PMU, możliwe błędne działania automatyki zabezpieczeniowej.
  • Łańcuchy dostaw i transport: synchronizacja logów, SCADA, ITS.
    CISA podkreśla, że strategiczne ryzyko dotyczy zarówno dostępności, jak i integralności czasu.

Rekomendacje operacyjne / co zrobić teraz

  1. Segmentacja i zasada najmniejszych uprawnień dla domen NTP/PTP; ruch tylko z/do autoryzowanych IP, deny by default. (Wnioski z incydentów i analiz ICS).
  2. Model „zaufanego czasu”: wieloźródłowe referencje (GNSS + zegary lokalne), detekcja dryftu, quorum, monitorowanie integralności sygnału, reżimy holdover.
  3. Hardening i monitoring serwerów czasu: aktualizacje OS/firmware, TLS/ACL dla PTP (jeśli wspierane), secure NTP, auth keys, unikanie broadcast/anycast bez kontroli.
  4. Higiena mobilna dla personelu krytycznego: MDM, containerization, ograniczenia aplikacji IM/SMS, aktualne baseband/modemy; traktuj urządzenia mobilne jako potencjalne jump hosts. (Wniosek wynikający z opisanego wektora).
  5. Telemetria i korelacja: ścisłe logowanie i korelacja zdarzeń z czasem podpisanym kryptograficznie; detekcja anomalii (nagłe skoki offset/jitter, NTP KoD, zmiana serwera nadrzędnego).
  6. Ćwiczenia i plan ciągłości: testy time failover, scenariusze GPS spoofing/jamming, procedury ręcznego „holdover” dla OT.

Różnice / porównania z innymi przypadkami

  • Błędy vs. ataki: znane incydenty jak błąd GPSD (2021) również rozregulowywały czas i prowadziły do przestojów – tu jednak mówimy o celowanych operacjach i długotrwałej penetracji.
  • OT „master clock” jako KKO (kluczowy komponent operacyjny): badania ICS pokazują, że kompromitacja „zegara głównego” może zakłócić całe klastry sterowania, co odróżnia ten wektor od typowego IT.

Podsumowanie / kluczowe wnioski

  • Oskarżenia Pekinu wobec NSA – niezależnie od ich ostatecznej weryfikacji – zwracają uwagę na strategiczny charakter infrastruktury czasu.
  • Organizacje powinny traktować NTP/PTP, stacje GNSS i zegary jako zasoby wysokiej wartości (HVA) i utwardzać je na równi z PKI i AD.
  • Higiena urządzeń mobilnych personelu krytycznego oraz segmentacja domen czasu to dziś must-have w modelu zagrożeń APT.

Źródła / bibliografia

  • Reuters: „China accuses US of cyber breaches at national time centre” (19.10.2025). (Reuters)
  • AP News: „China accuses US of cyberattack on national time center” (19.10.2025). (AP News)
  • CISA: Time Guidance for Network Operators, CIOs, CISOs (PDF). (CISA)
  • DNV: Bad timing – how a master clock vulnerability could disrupt maritime control systems (24.06.2025). (DNV)
  • MITRE ATT&CK: System Time Discovery (T1124). (MITRE ATT&CK)

Silver Fox rozszerza ataki Winos 4.0 na Japonię i Malezję. Nowy łańcuch z HoldingHands RAT i zwinne obejście EDR

Wprowadzenie do problemu / definicja luki

18 października 2025 r. opisano nową fazę kampanii chińskojęzycznej grupy Silver Fox (znanej też jako SwimSnake, The Great Thief of Valley / Valley Thief, UTG-Q-1000, Void Arachne), która do tej pory intensywnie wykorzystywała framework Winos 4.0 (ValleyRAT). Najnowsze obserwacje pokazują rozszerzenie celów z Chin i Tajwanu na Japonię i Malezję, z wykorzystaniem HoldingHands RAT (Gh0stBins) dostarczanego przez wieloetapowe łańcuchy phishingowe oparte na PDF/ZIP/HTML. Atak kładzie nacisk na unikanie wykrycia i wyłączanie produktów bezpieczeństwa.

W skrócie

  • Wektor wejścia: e-maile phishingowe podszywające się pod ministerstwa finansów, faktury, rozporządzenia podatkowe (PDF z osadzonymi linkami → fałszywe strony pobierania → archiwa ZIP z loaderami).
  • Malware: Winos 4.0 / ValleyRAT oraz HoldingHands RAT (rodzina inspirowana Gh0st RAT).
  • Eskalacja i ukrywanie: m.in. BYOVD (wcześniejsza fala), sideloading DLL, łańcuch DLL/DAT wyzwalany przez Harmonogram zadań dla utrudnienia detekcji behawioralnej.
  • Nowość: możliwość zdalnej aktualizacji adresu C2 z poziomu rejestru (komenda 0x15), dojrzałe mechanizmy anty-VM i anty-AV (Norton/Avast/Kaspersky).
  • Zasięg geograficzny: Chiny → Tajwan → Japonia → Malezja (kampanie z I–X 2025).

Kontekst / historia / powiązania

Fortinet udokumentował styczniowe i lutowe 2025 ataki na Tajwan z Winos 4.0, następnie – w czerwcu – łańcuchy z HoldingHands i Gh0stCringe. We wrześniu potwierdzono falę SEO poisoning (fałszywe instalatory Chrome/Telegram/WPS/DeepL na stronach-klonach, wieloetapowe JSON-redirecty). Równolegle Check Point przypisał Silver Fox wykorzystanie podpisanego przez Microsoft podatnego sterownika WatchDog Anti-malware (amsdk.sys) w modelu BYOVD, do wyłączania EDR/AV i wdrażania ValleyRAT. Najnowszy wpis Fortinet z 17 października wiąże wszystkie te tropy, pokazując przejście kampanii na Japonie i Malezję.

Analiza techniczna / szczegóły luki

Łańcuch infekcji (wariant Malezja/Japonia, 2025-10):

  1. PDF/Word/HTML z odnośnikami (często do Tencent Cloud lub domen z prefiksem „tw*”) → strona pobrania w lokalnym języku (np. japoński) → ZIP z „audyt podatkowy” EXE.
  2. EXE ładuje złośliwy dokan2.dll (sideloading), który inicjuje sw.dat (loader z anty-VM, impersonacją TrustedInstaller, eskalacją uprawnień).
  3. sw.dat upuszcza w C:\Windows\System32\:
    svchost.ini (RVA VirtualAlloc), TimeBrokerClient.dll (przemianowany na BrokerClientCallback.dll), msvchost.dat (zaszyfrowany shellcode), system.dat (zaszyfrowany payload), opcj. wkscli.dll. Następnie zabija usługę Harmonogramu zadań, licząc na jej automatyczny restart po 1 minucie. Po restarcie svchost.exe wczytuje złośliwy TimeBrokerClient.dll – co utrudnia reguły behawioralne oparte na „uruchomieniu procesu przez użytkownika”.
  4. TimeBrokerClient.dll wylicza adres VirtualAlloc z svchost.ini, odszyfrowuje msvchost.dat, a z niego system.dat → końcowy HoldingHands ładowany w pamięci.
  5. Anty-AV: enumeracja procesów (Norton/Avast/Kaspersky) i próby ich ubicia; w razie wykrycia – modyfikacja przebiegu lub przerwanie działania.
  6. C2 i nowe komendy: heartbeat co 60 s, zrzuty ekranu/klawiatury, polecenia zdalne, dogrywanie modułów; aktualizacja adresu C2 przez rejestr HKCU\Software\HHClient\AdrrStrChar (komenda 0x15).

Starsze/alternatywne wektory Silver Fox (2025-05/09):

  • SEO poisoning + trojanizowane instalatory (EnumW.dll → vstdlib.dll → AIDE.dll; persistence przez skróty/COM hijacking), kradzież krypto, monitor ekranów.
  • BYOVD z podatnym, podpisanym sterownikiem WatchDog (amsdk.sys) – wyłączanie/terminowanie procesów AV/EDR na poziomie jądra, poza listą Microsoft Vulnerable Driver Blocklist w chwili odkrycia.

Praktyczne konsekwencje / ryzyko

  • Ucieczka przed EDR: wyzwalanie przez Harmonogram zadań po restarcie usługi sprawia, że nie widać „typowego” łańcucha procesów inicjowanego przez użytkownika.
  • Trwałość i sterowalność: zdalna zmiana C2 w rejestrze pozwala utrzymać dostęp mimo blokad sieci/infrastruktury.
  • Ryzyko sektorowe/regionalne: wysoka skuteczność socjotechniki w urzędach/finansach (tematy podatkowe), obecnie szczególnie Japonia i Malezja, wcześniej Tajwan i Chiny.

Rekomendacje operacyjne / co zrobić teraz

  1. E-mail & web: blokuj HTML/PDF z osadzonymi linkami w korespondencji finansowo-podatkowej; sandboxing plików ZIP/EXE; filtruj nowe/dziwne domeny z prefiksami „tw*”, hostingi chmurowe użyte w kampanii.
  2. EDR/telemetria: dodaj reguły na anomalię: restart usługi Schedule → natychmiastowe ładowanie TimeBrokerClient.dll przez svchost.exe, tworzenie plików svchost.ini / msvchost.dat / system.dat w System32. (Reguły behawioralne / Sigma/EDR custom).
  3. Rejestr & procesy: monitoruj klucz HKCU\Software\HHClient (wartość AdrrStrChar) oraz nietypowe instancje taskhostw.exe inicjowane przez CreateProcessAsUser z kontekstu svchost.exe –s Schedule.
  4. AV/EDR hardening: aktualizuj Microsoft Vulnerable Driver Blocklist i polityki blokowania sterowników; sprawdź obecność/ładowanie amsdk.sys (WatchDog) oraz artefaktów BYOVD wskazanych przez Check Point.
  5. Proxy/DNS/Netflow: alertuj na beacon 60 s do świeżych adresów C2; utrzymuj listy wskaźników z ostatnich raportów Fortinet/Seqrite.
  6. Edukacja użytkowników: kampanie uświadamiające wokół fałszywych pism ministerialnych i „audytów podatkowych”, w j. lokalnym (JP/MS).

Różnice / porównania z innymi przypadkami

  • Na tle klasycznych kampanii Gh0st-rodziny Silver Fox stosuje nietypowy trigger (restart usługi Schedule) oraz modułową aktualizację C2 z rejestru – to rzadziej spotykane w prostych klonach Gh0st RAT.
  • W porównaniu z wcześniejszą falą SEO-poisoning, obecne lury urzędowe (JP/MY) są bardziej ukierunkowane regionalnie i nie wymagają pozycjonowania wyszukiwarek.
  • BYOVD (WatchDog/Zemana) to technika na wyższym szczeblu uprzywilejowania niż typowe „userland” sideloadingi – pozwala agresywnie wyłączać ochronę przed dostarczeniem ValleyRAT/HoldingHands.

Podsumowanie / kluczowe wnioski

Silver Fox konsekwentnie iteruje taktyki: od phishingu podatkowego w Tajwanie (I–II 2025), przez SEO poisoning (VIII–IX 2025), aż po Japonie i Malezję (X 2025) z łańcuchem DLL/DAT wyzwalanym przez Harmonogram zadań i HoldingHands RAT jako finalnym payloadem. Nowo dodana aktualizacja C2 przez rejestr zwiększa odporność na blokady. Organizacje w regionie APAC (szczególnie finanse/administracja) powinny natychmiast wzmocnić kontrolę poczty, polityki sterowników oraz detekcje behawioralne wokół svchost.exe –s Schedule i artefaktów svchost.ini/msvchost.dat/system.dat.

Źródła / bibliografia

  • The Hacker News: „Silver Fox Expands Winos 4.0 Attacks to Japan and Malaysia via HoldingHands RAT” (18 października 2025). (The Hacker News)
  • Fortinet FortiGuard Labs: „Tracking Malware and Attack Expansion: A Hacker Group’s Journey across Asia” (17 października 2025). Główne źródło techniczne. (Fortinet)
  • Check Point Research: „Chasing the Silver Fox: Cat & Mouse in Kernel Shadows” – nadużycie sterownika WatchDog (BYOVD) (28 sierpnia 2025). (Check Point Research)
  • Seqrite Labs: „Operation Silk Lure: Scheduled Tasks Weaponized for DLL Side-Loading (drops ValleyRAT)” (ok. 16 października 2025). (Seqrite)
  • The Hacker News: „HiddenGh0st, Winos and kkRAT Exploit SEO, GitHub Pages in Chinese Malware Attacks” (15 września 2025). (The Hacker News)

Nowy backdoor .NET „CAPI” atakuje rosyjską motoryzację i e-commerce przez ZIP-y z LNK

Wprowadzenie do problemu / definicja luki

Badacze z Seqrite Labs opisali nową kampanię wymierzoną w rosyjski sektor motoryzacyjny i e-commerce, wykorzystującą dotychczas nieudokumentowane złośliwe oprogramowanie .NET nazwane CAPI Backdoor. Dystrybucja odbywa się przez spreparowane wiadomości e-mail z archiwum ZIP zawierającym skrót LNK i przynętę PDF dotyczącą zmian w podatku dochodowym. Pierwsze artefakty kampanii pojawiły się w VirusTotal 3 października 2025 r.; szczegóły publicznie opisano 17–18 października 2025 r.

W skrócie

  • Wektor wejścia: spear-phishing z archiwum ZIP zawierającym LNK, który uruchamia DLL backdoora przez rundll32.exe (living-off-the-land).
  • Zdolności CAPI: kradzież danych z przeglądarek (Chrome/Edge/Firefox), zrzuty katalogów, screenshoty, rozpoznanie systemu, anty-VM, persystencja (Startup LNK + zaplanowane zadanie).
  • Infrastruktura: domena podszywająca się pod carprice[.]ru (carprlce[.]ru) oraz C2 91.223.75[.]96.
  • Mapowanie do MITRE ATT&CK: T1566.001 (Spearphishing Attachment), T1218.011 (Signed Binary Proxy Execution: rundll32), T1113 (Screen Capture), T1555.003 (Credentials from Web Browsers) itd.

Kontekst / historia / powiązania

Zastosowanie rundll32.exe jako LOLBin jest od lat popularnym sposobem „proxy execution”, pozwalającym ukryć złośliwy kod za podpisanym binarium Microsoftu i obchodzić niektóre polityki kontroli aplikacji. Technika ta jest skatalogowana w MITRE ATT&CK jako T1218.011 i szeroko opisywana przez branżę (np. Red Canary).
O kampanii „CAPI Backdoor” jako pierwsi szczegółowo napisali badacze Seqrite; wątek podchwyciły media branżowe, m.in. The Hacker News.

Analiza techniczna / szczegóły luki

Łańcuch infekcji. ZIP o nazwie w języku rosyjskim (np. „Перерасчет заработной платы 01.10.2025”) zawiera:

  1. przynętę PDF o zmianach PIT, 2) skrót LNK o tej samej nazwie. Kliknięcie LNK uruchamia rundll32.exe z parametrami wskazującymi na export „config” w bibliotece adobe.dll (alias client6.dll), co inicjuje komunikację z C2.

Funkcje CAPI Backdoor (wybór):

  • IsAdmin – sprawdza uprawnienia administracyjne przez SID.
  • av – enumeracja zainstalowanych AV przy użyciu zapytań WMI.
  • OpenPdfFile – otwarcie przynęty PDF (kamuflaż).
  • Connect/ReceiveCommands/ExecuteCommand – połączenie TCP na porcie 443 z 91.223.75[.]96, odbiór i wykonywanie poleceń (m.in. listowanie katalogów, exfiltracja).
  • dmp1/dmp2/dmp3 – kradzież profili i kluczy przeglądarek Edge/Chrome/Firefox (pliki historii, zakładki, Local State/klucze).
  • screen – screenshot z oznaczeniem czasu.
  • IsLikelyVm – zestaw heurystyk anty-VM: hypervisor, rejestr, SMBIOS, PnP, OUI MAC, GPU/dostawcy dysków, bateria/chassis, OEM.
  • persist1/persist2 – kopiowanie DLL do AppData\Roaming\Microsoft i autostart przez Startup LNK; dodatkowo Scheduled Task „AdobePDF” (opóźnienie 1 h, cykliczność co godzinę przez 7 dni).

Techniki ATT&CK (mapowanie):

  • T1566.001 – spear-phishing z załącznikiem (ZIP/LNK/PDF).
  • T1218.011 – wykonanie DLL przez rundll32.exe (LOLBAS).
  • T1555.003 – wykradanie poświadczeń/prywatnych danych z przeglądarek. (opisane przez Seqrite w kontekście profili przeglądarek).
  • T1113 – przechwytywanie ekranu.

Praktyczne konsekwencje / ryzyko

  • Kradzież danych klientów i płatności przez eksfiltrację profili przeglądarek (ciasteczka, tokeny sesyjne, historię, hasła – jeśli możliwy dostęp do kluczy lokalnych).
  • Utrzymanie długotrwałego dostępu dzięki podwójnej persystencji (Startup + Scheduled Task).
  • Uwiarygodnienie phishingu przez lokalny kontekst podatkowy (dokument PIT w języku rosyjskim), co zwiększa współczynnik kliknięć.
  • Utrudnione wykrywanie z uwagi na abuse podpisanego binarium rundll32.exe (LOLBIN).

Rekomendacje operacyjne / co zrobić teraz

  1. E-mail & brama: blokowanie archiwów ZIP z plikami .lnk; sandboxing załączników; skan treści w języku lokalnym (ruleset dla słów kluczowych dot. „перерасчет”, „налог”). Mapować kontrole do T1566.001.
  2. EDR/telemetria: alerty na nietypowe wywołania rundll32.exe ładujące z katalogów użytkownika, z parametrem nazwy eksportu (np. config), połączone z komunikacją sieciową. Wspierają to reguły/Sigma i wytyczne LOLBAS.
  3. Kontrola przeglądarek: monitorowanie dostępu do plików profili (Chrome/Edge/Firefox) i nieoczekiwanej kompresji ZIP tych zasobów przez procesy spoza przeglądarek. (na podstawie opisu funkcji dmp1–dmp3).
  4. Persistence hunting: przegląd Startup (lnk) i zadań Harmonogramu (np. „AdobePDF”), w szczególności wpisów wskazujących na rundll32.exe z DLL w AppData\Roaming\Microsoft.
  5. Blokady sieciowe: tymczasowe denylisty dla carprlce[.]ru i 91.223.75[.]96; monitorowanie i blokowanie ruchu wychodzącego TLS do nietypowych hostów/ASN z hostów końcowych.
  6. Szkolenia i symulacje: kampanie uświadamiające o plikach LNK w archiwach ZIP; testy phishingowe imitujące lokalne komunikaty podatkowe. (praktyka zgodna z ATT&CK T1566.*).
  7. Twardnienie stacji roboczych: polityki, które uniemożliwiają uruchamianie DLL z profili użytkowników przez rundll32.exe (AppLocker/WDAC) oraz ograniczenie wykonywania LNK z katalogów tymczasowych. (zob. znane sposoby nadużycia rundll32 i zalecenia branżowe).

Różnice / porównania z innymi przypadkami

  • W odróżnieniu od typowych kampanii z makrami Office, tutaj wektor LNK → rundll32 → DLL minimalizuje zależności od pakietu Office i zwiększa skuteczność na zablokowanych makrach.
  • CAPI łączy stealer + backdoor (zbieranie profili przeglądarek + zadania zdalne), co nadaje mu większą elastyczność niż klasyczne „pure stealers”.

Podsumowanie / kluczowe wnioski

Kampania CAPI Backdoor jest kolejnym przypomnieniem, że LOLBIN-y (tu: rundll32.exe) pozostają skutecznym nośnikiem wykonania w łańcuchach phishingowych. Obrona powinna koncentrować się na telemetrii procesów, korelacji z ruchem sieciowym, łapaniu persystencji oraz higienie załączników (w szczególności ZIP + LNK). Wdrożenie detekcji mapowanych do T1566.001 i T1218.011 oraz regularne polowanie na artefakty Startup/Task Scheduler znacząco ograniczy okno zagrożeń.

Źródła / bibliografia

  1. Seqrite Labs: „Operation MotorBeacon: Threat Actor targets Russian Automotive Sector using .NET Implant”, 17 października 2025 r. (Seqrite)
  2. The Hacker News: „New .NET CAPI Backdoor Targets Russian Auto and E-Commerce Firms via Phishing ZIPs”, 18 października 2025 r. (The Hacker News)
  3. LOLBAS – rundll32.exe (opis nadużyć, ścieżki, przykłady) (lolbas-project.github.io)
  4. MITRE ATT&CK T1218.011 – Signed Binary Proxy Execution: rundll32 (MITRE ATT&CK)
  5. MITRE ATT&CK T1566.001 – Spearphishing Attachment (MITRE ATT&CK)

Google Ads podszywają się pod Homebrew i LogMeIn. Kampania malvertising atakuje deweloperów macOS infostealerami (AMOS, Odyssey)

Wprowadzenie do problemu / definicja luki

Badacze odnotowali nową falę malvertisingu w Google Ads, w której przestępcy podszywają się pod Homebrew, LogMeIn i TradingView, aby infekować użytkowników macOS – głównie deweloperów – kradnącym dane malware: Atomic macOS Stealer (AMOS) oraz Odyssey Stealer. Reklamy prowadzą do witryn-klonów z instrukcjami uruchomienia komend w Terminalu (“ClickFix”), które pobierają i uruchamiają złośliwe skrypty, omijając mechanizmy ochronne (Gatekeeper).

W skrócie

  • Wektor wejścia: sponsorowane wyniki Google kierujące do fałszywych serwisów (np. homebrewonline[.]org, homebrewupdate[.]org, fałszywe domeny LogMeIn/TradingView).
  • TTP: socjotechnika ClickFix – ofiara kopiuje do schowka i uruchamia w Terminalu polecenie curl | bash ukryte pod pozornie nieszkodliwym przyciskiem “Copy/Verify”.
  • Ładunki: AMOS (MaaS, ~1000 USD/mies.) i Odyssey (fork Poseidon/AMOS) – kradzież haseł, cookies, Keychain, portfeli krypto, plików; exfiltracja do C2.
  • Skala: zidentyfikowano >85 powiązanych domen i współdzieloną infrastrukturę (m.in. IP 93.152.230[.]79, 195.82.147[.]38, certyfikaty SSL reuse).
  • Google: wcześniejsze fale malvertisingu Homebrew potwierdzano już na początku 2025 r.; Google deklarowało zawieszanie kont reklamodawców i usuwanie reklam naruszających zasady.

Kontekst / historia / powiązania

Fałszywe reklamy prowadzące do klonów Homebrew obserwowano już w styczniu 2025 r. – ad prezentował prawidłowy URL brew.sh, ale przekierowywał na niemal identyczne brewe.sh, skąd serwowano AMOS. Google usuwało reklamy i zawieszało powiązane konta, lecz technika powraca w nowych wariantach.
Latem 2025 r. rozwinęła się technika ClickFix (fałszywe “naprawy” i poradniki), którą BleepingComputer i CrowdStrike wiązali m.in. z rodziną Shamos (wariant AMOS). Obecna kampania recyklinguje tę samą logikę nakłaniania do uruchamiania komend.

Analiza techniczna / szczegóły luki

Socjotechnika i interfejsy stron:

  • Strony-klony wyświetlają instrukcję instalacji (Homebrew/LogMeIn/TradingView) oraz przycisk “Copy”. Kliknięcie wrzuca do schowka zaszyfrowaną Base64 komendę, która po wklejeniu do Terminala pobiera install.sh i uruchamia binarkę; stronę utrudniającą zaznaczanie tekstu i podgląd zawartości schowka opisano w raportach threat-intel.

Łańcuch infekcji:

  1. Wejście przez reklamę Google → domena phishingowa (np. homebrewfaq[.]org, tradingviewen[.]com, sites-phantom[.]com).
  2. “Copy” → Base64-curl → pobranie install.sh → pobranie ładunku (AMOS/Odyssey).
  3. Skrypt usuwa atrybut com.apple.quarantine (xattr) i nadaje prawa (chmod), co ominie Gatekeeper.
  4. Malware uruchamia kontrole anti-VM/sandbox, podnosi uprawnienia (sudo), zabija wybrane usługi (np. OneDrive updater), korzysta z XPC, zbiera artefakty systemowe i przeglądarkowe, a następnie exfiltruje dane do C2.

Infrastruktura i IOCs (wybór):

  • Domeny: homebrewonline[.]org, homebrewupdate[.]org, homebrewclubs[.]org, homebrewfaq[.]org, tradingviewen[.]com, tradingvieweu[.]com, sites-phantom[.]com, filmoraus[.]com; warianty LogMeIn: m.in. logmeln[.]com, logmeeine[.]com.
  • IP: 93.152.230[.]79, 195.82.147[.]38; korelacja po re-use certyfikatów SSL (np. CN związany z trading.example.com).

Rodziny malware:

  • AMOS – MaaS udostępniany na abonament (~1000 USD/mies.), eksfiltruje hasła, cookies, Keychain, portfele, karty; niedawno otrzymał komponent backdoora (persistent remote access).
  • Odyssey – nowa rodzina powiązana rodowodem z Poseidon/AMOS, kradnie dane z Safari/Chrome/Firefox, ponad setki rozszerzeń portfeli i Keychain, pakuje do ZIP i wysyła do C2.

Praktyczne konsekwencje / ryzyko

  • Kompromitacja tożsamości deweloperskiej (tokeny, SSH keys, cookies sesyjne) → ryzyko supply-chain (publikacja złośliwych buildów, backdoor w repo).
  • Utrata środków z kryptowalut/portfeli przeglądarkowych.
  • Persistent access (komponenty backdoor) i lateral movement w urządzeniach BYOD/MDM, także w kontekstach firmowych korzystających z LogMeIn/TradingView.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i zespołów IT:

  1. Nie uruchamiaj w Terminalu poleceń znalezionych na stronach innych niż oficjalne – prawidłowe domeny to m.in. brew.sh (Homebrew), nie ich warianty typograficzne. Dodaj reguły DNS/URL Filtering blokujące znane typosquaty (lista wyżej).
  2. Instalacja Homebrew: korzystaj z oficjalnej instrukcji na brew.sh (weryfikuj URL i certyfikat). Zawsze czytaj skrypty instalacyjne przed pipowaniem do shella.
  3. EDR/AV na macOS z detekcją stealerów (AMOS/Odyssey) i monitorowaniem uruchomień curl → bash oraz modyfikacji xattr. (Por. wcześniejsze raporty o kampaniach Homebrew/AMOS).
  4. Twarde polityki przeglądarki: wyłącz automatyczne uruchamianie skryptów z niezaufanych źródeł, izoluj profile przeglądarki, wymuś passkey/2FA dla krytycznych usług.
  5. Higiena kluczy i tokenów: rotacja Keychain, haseł, tokenów CI/CD i logowań do chmur po incydencie; unieważnienie sesji (cookies).
  6. Monitoruj IOC: dodaj do blokad i SIEM/EDR (domeny/IP powyżej), filtruj ruch do nowo-zarejestrowanych domen i TLD spoza profilu.

Dla zespołów marketingu/reklam:
7. Zgłaszaj podejrzane reklamy i nadużycia brandu w Google Ads; praktyka z pocz. 2025 r. pokazuje, że zawieszenia kont i usuwanie reklam są wdrażane, ale atakujący szybko rotują infrastrukturą – konieczny jest brand monitoring i taksonomie słów kluczowych (wykluczenia, “exact match”).

Dla SOC/DFIR – wskazówki detekcyjne (starter):

  • Sygnatury zachowania: łańcuch browser → clipboard → Terminal; procesy: Terminal.app/iTerm2 uruchamiają bash/zsh z parametrem -c oraz curl -fsSL ... | base64 -d | bash. Wzorce xattr -d com.apple.quarantine, chmod +x tuż przed uruchomieniem binarki.
  • Telemetria sieciowa: żądania do domen typosquattingowych (Homebrew/LogMeIn/TradingView), korelacja z IP 93.152.230[.]79 i 195.82.147[.]38 oraz reuse certyfikatów.

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

  • GitHub-malspam (AMOS): wcześniej dystrybucja przez fałszywe repozytoria; obecnie wraca malvertising + ClickFix. Wspólny mianownik: socjotechnika i kradzież tożsamości dewelopera.
  • “Fake fixes” na macOS (Shamos/AMOS): ta sama technika ClickFix, ale pretekst inny (rzekome naprawy systemu). Obecna kampania udaje instalatory znanych narzędzi (Homebrew/LogMeIn/TradingView).

Podsumowanie / kluczowe wnioski

  • Atak łączy SEO+Ads z socjotechniką Terminalową – skuteczny wobec deweloperów przyzwyczajonych do skryptowych instalatorów.
  • AMOS/Odyssey pozostają jednymi z najbardziej aktywnych stealerów na macOS; ich operatorzy recyklingują infrastrukturę i domeny, przez co kampanie są długowieczne.
  • Higiena instalacji (weryfikacja domen, brak “curl | bash” z niezweryfikowanych źródeł), telemetria EDR i blokady DNS to najszybsze środki obniżające ryzyko.

Źródła / bibliografia

  1. BleepingComputer – Google ads for fake Homebrew, LogMeIn sites push infostealers (18 października 2025). (BleepingComputer)
  2. Hunt.io – Odyssey Stealer & AMOS Hit macOS Developers with Fake Homebrew Sites (16 października 2025). (hunt.io)
  3. SecurityWeek – Homebrew macOS Users Targeted With Information Stealer Malware (23 stycznia 2025). (SecurityWeek)
  4. Bitdefender – Criminals Use Fake Mac Homebrew Google Ads in New Malicious Campaign (22 stycznia 2025). (Bitdefender)
  5. BleepingComputer – Fake Mac fixes trick users into installing new Shamos infostealer (22 sierpnia 2025). (BleepingComputer)

Europol rozbija sieć „SIM farm”: 7 zatrzymanych, 1 200 urządzeń SIM-box i 49 mln fałszywych kont

Wprowadzenie do problemu / definicja luki

Europol (przy wsparciu Eurojustu i służb z Austrii, Estonii, Finlandii oraz Łotwy) rozbił międzynarodową infrastrukturę cybercrime-as-a-service o kryptonimie SIMCARTEL, która wynajmowała przestępcom numery telefoniczne z ponad 80 krajów do rejestracji i weryfikacji kont oraz prowadzenia oszustw. Zatrzymano 7 osób, przeprowadzono 26 przeszukań, zajęto 1 200 urządzeń SIM-box i 40 000 aktywnych kart SIM, a także pięć serwerów i dwie domeny wykorzystywane do świadczenia usługi. Według organów ścigania infrastruktura pomogła utworzyć blisko 50 mln fałszywych kont.

W skrócie

  • Skala: 3 200+ udokumentowanych przypadków oszustw, straty min. ~5 mln € (gł. Austria i Łotwa).
  • Modus operandi: hurtowy wynajem numerów (SIM-farmy/SIM-boxy) do obejścia weryfikacji SMS i ukrywania tożsamości.
  • Seizury: 1 200 SIM-box, 40 000 aktywnych SIM, setki tys. dodatkowych kart, 5 serwerów, mrożenie środków i konfiskata luksusowych aut.
  • Zastosowania przestępcze: phishing/smishing, fałszywe inwestycje, „na córkę/syna” w WhatsApp, podszywanie się pod policję, sklepy-widmo, a także przestępstwa pozatelekomunikacyjne.

Kontekst / historia / powiązania

Eurojust podaje, że platforma udostępniała numery z >80 krajów i była oferowana innym grupom w modelu CaaS (Crime-as-a-Service). Działania operacyjne przeprowadzono 10 października 2025 r., a komunikaty opublikowano 17 października.
Niezależne redakcje (BleepingComputer, CyberScoop, The Record) potwierdzają aresztowania i skalę zabezpieczeń, podając zbliżone szacunki strat: ok. 4,5 mln € w Austrii i ~420 tys. € na Łotwie.

Analiza techniczna / szczegóły luki

SIM-box/SIM-farmy to zestawy bramek GSM z dziesiątkami/setkami gniazd SIM, które automatycznie rotują karty i numery. Dzięki sterowaniu API można masowo:

  • odbierać kody SMS (OTP) do rejestracji kont i resetów haseł,
  • prowadzić smishing na dużą skalę,
  • omijać mechanizmy anty-fraudowe platform (np. limity na numer/urządzenie),
  • maskować geolokalizację i tożsamość operatora.

W sprawie SIMCARTEL infrastruktura działała jak profesjonalna usługa: panel online, automatyzacja, pozyskiwanie kart z wielu rynków, a nawet „oferta” na wynajem numerów i monetyzację cudzych kart. Organy przejęły m.in. serwisy ułatwiające pozyskanie numerów jednorazowych do kodów weryfikacyjnych.

Dlaczego to działa?
Ekosystem SMS-OTP i weryfikacji numeru telefonu jest podatny na nadużycia, bo:

  • SMS nie zapewnia silnego uwierzytelnienia i jest podatny na przekierowania/SS7/małe opóźnienia dostaw,
  • wiele serwisów ufnie traktuje numer jako tożsamość (KBA/„posiadanie”),
  • reputacja numeru jest słabo współdzielona między usługami.

Praktyczne konsekwencje / ryzyko

  • Platformy online: zalew botów i kont-widm (do 49 mln), spadek skuteczności AML/KYC light, nadużycia programów promocyjnych, większe koszty moderacji i ryzyka.
  • Instytucje finansowe: phishing inwestycyjny, podszywanie się, nadużycia „SCA via SMS”.
  • Użytkownicy: ataki „na córkę/syna” w komunikatorach, wyłudzenia danych i środków.
  • Telco: wykorzystanie ich sieci do generowania ruchu A2P, ryzyko reputacyjne i regulacyjne.

Rekomendacje operacyjne / co zrobić teraz

Dla platform i fintechów

  1. Ogranicz zaufanie do SMS-OTP: przejdź na passkeys/FIDO2 jako główny MFA; SMS zostaw jako fallback z dodatkowymi kontrolami ryzyka.
  2. Weryfikacja numeru ≠ weryfikacja tożsamości: zawsze łącz z innymi sygnałami (dokument/biometria, proof-of-personhood).
  3. Inteligencja numerów: HLR/MNP lookups, kontrola klasy usługi (pre-/post-paid), sprawdzanie nowości numeru, scoring reputacji (czy numer był widziany przy wielu rejestracjach).
  4. Anti-abuse na rejestrację: device fingerprinting, velocity rules (na IP/ASN/IMEI-like), limity per metoda płatności, weryfikacje „liveness” w KYC, dynamiczne CAPTCHy.
  5. Monitoring: reguły SIEM/FRM wychwytujące anomalię OTP (dużo SMS na ten sam numer/zakres), alerty na skoki rejestracji z jednego kraju/ASN.

Dla banków i e-commerce

  • Transaction-level MFA (push z bindingiem urządzenia, podpis kryptograficzny), detekcja „social engineering session”.
  • Predefiniowane ostrzeżenia UX i bloki słów kluczowych w komunikacji (np. wzorce „nowy numer dziecka”, „pilny przelew”).

Dla operatorów telekomunikacyjnych

  • Detekcja SIM-box: korelacja IMSI/IMEI, anomalia w TADIG/CellID (duża liczba MSISDN z jednego modemu), nietypowe profile SMS-MT/MO, hurtowa rotacja kart.
  • Współpraca z LEA/CSIRT oraz sinkhole numerów/domen powiązanych z farmami.

Dla użytkowników

  • Nie traktuj SMS jako dowodu tożsamości rozmówcy. Weryfikuj „nowe numery” bliskich innym kanałem. Blokuj linki z SMS/komunikatorów kierujące do płatności/logowania.

Różnice / porównania z innymi przypadkami

W USA we wrześniu 2025 r. tajne służby rozbiły dużą SIM farmę (ponad 300 serwerów i 100 000 kart SIM) wskazując na rosnące ryzyko dla infrastruktury krytycznej. Europa i USA notują więc zbliżoną taktykę, ale inne wektory nadużyć (w UE – silny nacisk na oszustwa konsumenckie i masowe rejestracje kont).

Podsumowanie / kluczowe wnioski

  • SIM-farmy komodytyzują nadużycia oparte na SMS-OTP i deprecjonują numer telefonu jako sygnał zaufania.
  • Organizacje powinny odejść od SMS-OTP jako głównego MFA i wzmocnić kontrole anty-abuse na etapie rejestracji/kontaktu.
  • Współpraca LEA (Europol/Eurojust) z podmiotami prywatnymi i operatorami pozostaje kluczowa do demontażu infrastruktury CaaS.

Źródła / bibliografia

  1. Eurojust: „Decisive action against various online scams in Austria and Latvia: seven arrests”, 17.10.2025. (szczegóły operacji, liczby: 1 200 SIM-box, 40 000 SIM, ~50 mln kont, 26 przeszukań). (Eurojust)
  2. Europol: „Cybercrime-as-a-service takedown: 7 arrested – Operation SIMCARTEL” (komunikat prasowy: aresztowania, przejęte serwisy). (Europol)
  3. BleepingComputer: „Europol dismantles SIM box operation renting numbers for cybercrime”, 17.10.2025 (szacunki strat, przejęte domeny). (BleepingComputer)
  4. CyberScoop: „Europol dismantles cybercrime network linked to $5.8M in financial losses”, 17.10.2025 (dodatkowe liczby, kontekst USA). (CyberScoop)
  5. The Record: „European police bust network selling thousands of phone numbers to scammers”, 17.10.2025 (tło śledztwa, cytaty, materiał wideo policji). (The Record from Recorded Future)

Gladinet łata aktywnie wykorzystywaną lukę zero-day w CentreStack. Co wiemy i co robić?

Wprowadzenie do problemu / definicja luki

Gladinet wydał poprawkę dla CentreStack usuwając wykorzystywaną w atakach lukę CVE-2025-11371 typu Local File Inclusion (LFI). Błąd pozwalał nieautoryzowanym napastnikom odczytać plik Web.config, wyekstrahować ASP.NET machineKey, a następnie zrealizować RCE (zdalne wykonanie kodu) poprzez wcześniej opisaną podatność na deserializację ViewState (CVE-2025-30406). Łatka jest dostępna w CentreStack 16.10.10408.56683.

W skrócie

  • CVE-2025-11371 (LFI) umożliwia odczyt wrażliwych plików (m.in. Web.config) na serwerze CentreStack/Triofox w domyślnej konfiguracji.
  • Ataki obserwowane od 27 września 2025 r. (zero-day).
  • Po pozyskaniu machineKey napastnik może sfałszować ViewState i osiągnąć RCE, łańcuchowo z CVE-2025-30406.
  • Poprawka wydana 14 października 2025 r. w CentreStack 16.10.10408.56683; zalecana natychmiastowa aktualizacja.
  • W okresie bez łatki rekomendowano tymczasową dezaktywizację handlera “temp” w UploadDownloadProxy.

Kontekst / historia / powiązania

W kwietniu 2025 r. naprawiono CVE-2025-30406 (twardo zakodowany machineKey i deserializacja ViewState), która była aktywnie wykorzystywana. Nowa luka LFI (CVE-2025-11371) pozwalała „odtworzyć” warunki do RCE – tym razem poprzez pozyskanie klucza z działającej, już zaktualizowanej instancji. Zależność między CVE-2025-11371 (LFI) i CVE-2025-30406 (RCE) stanowiła kluczowy łańcuch ataku.

Analiza techniczna / szczegóły luki

  • Wektor: niezabezpieczony punkt końcowy /storage/t.dn w komponencie GSUploadDownloadProxy.dll (klasa GladinetStorage.TempDownload). Parametr s= był podatny na directory traversal, umożliwiając odczyt dowolnych plików w kontekście NT AUTHORITY\SYSTEM (np. ...\root\Web.config).
  • Łańcuch do RCE: po odczycie Web.config napastnik uzyskiwał machineKey i mógł wygenerować złośliwy ViewState, aby wykonać komendy z uprawnieniami puli aplikacyjnej IIS (efektywnie przejęcie hosta).
  • Wersje podatne: wg NVD – wszystkie wersje do i włącznie z 16.7.10368.56560 w domyślnej instalacji/konfiguracji.
  • IoC / telemetria zaobserwowana przez Huntress:
    • Żądania GET do **/storage/t.dn?s=..\..\..\Program+Files+(x86)\Gladinet+Cloud+Enterprise\root\Web.config&sid=1**
    • Następnie POST-y z base64 (payload ViewState) i logi Event ID 1316 z komendami systemowymi (ipconfig /all > ...).

Praktyczne konsekwencje / ryzyko

  • Ekspozycja klucza kryptograficznego (machineKey) umożliwia podpisywanie złośliwych danych i omijanie zabezpieczeń ViewState → pełne przejęcie serwera.
  • Atak bez uwierzytelnienia, w domyślnej konfiguracji, na systemach często wystawionych do Internetu (MSP, wdrożenia samo-hostowane).
  • Ataki w toku (co najmniej kilku poszkodowanych) i obserwacje od końca września zwiększają pilność działań.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiast zaktualizuj CentreStack do 16.10.10408.56683 (lub nowszej). Zweryfikuj numer buildu po instalacji.
  2. Jeśli aktualizacja chwilowo niemożliwa: wyłącz handler „temp” w UploadDownloadProxy\Web.config (usunięcie mapowania do t.dn). Uwaga: ogranicza funkcjonalność, ale zamyka wektor LFI.
  3. Hunting/Monitoring:
    • Szukaj żądań do **/storage/t.dn** z ciągami ..\..\.. i odczytem Web.config.
    • Analizuj logi aplikacyjne (np. Event ID 1316) pod kątem nietypowych payloadów base64 i komend systemowych.
  4. Twardnij konfigurację ASP.NET: rotacja machineKey po incydencie, wymuszenie minimalnych uprawnień puli aplikacyjnej, kontrola dostępu do ścieżek tymczasowych. (Wniosek na podstawie analizy łańcucha ataku).
  5. Przegląd ekspozycji: potwierdź, czy interfejsy CentreStack/Triofox są dostępne z Internetu; jeśli tak, rozważ geofencing/VPN/WAF i reguły sygnaturowe na /storage/t.dn.
  6. Triofox: produkt był wskazany jako podatny w domyślnej konfiguracji; sprawdź komunikaty producenta i dostępność aktualizacji dla Twojej wersji Triofox (w artykułach potwierdzono patch publicznie dla CentreStack).

Różnice / porównania z innymi przypadkami

  • CVE-2025-11371 vs CVE-2025-30406:
    • 11371 = LFI (odczyt plików) → pośrednio umożliwia RCE przez 30406 (ViewState).
    • 30406 = krytyczna deserializacja możliwa przy znajomości machineKey (wcześniej twardo zakodowanego); naprawiona w kwietniu 2025 r. 11371 „odblokowała” 30406 na zaktualizowanych hostach przez ujawnienie klucza.

Podsumowanie / kluczowe wnioski

  • Zaktualizuj teraz do 16.10.10408.56683 – to jedyny trwały sposób zamknięcia LFI.
  • Sprawdź logi pod kątem odczytów Web.config przez /storage/t.dn i podejrzanych payloadów base64 – to typowy ślad tej kampanii.
  • Traktuj 11371 + 30406 jako łańcuch: sama „średnia” punktacja LFI (CVSS 6.2) jest myląca – w praktyce prowadzi do pełnego RCE.

Źródła / bibliografia

  1. BleepingComputer – „Gladinet fixes actively exploited zero-day in file-sharing software” (wydanie łatki, wersja 16.10.10408.56683, wektor /storage/t.dn). (BleepingComputer)
  2. Huntress – „Active Exploitation of Gladinet CentreStack and Triofox Local File Inclusion Flaw (CVE-2025-11371)” (timeline, IoC, technikalia, mitigacje, potwierdzenie daty wydania łatki). (Huntress)
  3. SecurityWeek – „Gladinet Patches Exploited CentreStack Vulnerability” (podsumowanie łańcucha LFI → ViewState RCE, potwierdzenie wersji z poprawką). (SecurityWeek)
  4. NVD – CVE-2025-11371 (opis wpływu i zakres wersji w domyślnej konfiguracji). (NVD)
  5. Field Effect – „Gladinet patches critical vulnerability exploited in the wild” (daty: obserwacje, publikacja mitigacji i wydanie poprawki). (fieldeffect.com)