Archiwa: Admin - Security Bez Tabu

Tag: Admin

Adobe AEM Forms (CVE-2025-54253) już wykorzystywana w atakach: co muszą zrobić zespoły bezpieczeństwa

Wprowadzenie do problemu / definicja luki

CISA ostrzegła, że krytyczna podatność w Adobe Experience Manager (AEM) Forms na JEE, śledzona jako CVE-2025-54253, jest aktywnie wykorzystywana. To błąd konfiguracji prowadzący do zdalnego wykonania kodu (RCE), oceniony na CVSS 10.0. Adobe załatało problem w trybie out-of-band na początku sierpnia 2025 r., ale w obiegu znajdował się już publiczny PoC, co ułatwiło atakującym przygotowanie kampanii.

W skrócie

  • Produkt / wersje: AEM Forms na JEE w wersjach 6.5.23.0 i starszych są podatne. Wydanie naprawcze: 6.5.0-0108. Wpływ: zdalne wykonanie kodu bez uwierzytelnienia.
  • Status: CISA dodała lukę do KEV (Known Exploited Vulnerabilities) – potwierdzona eksploatacja „in the wild”. Federalne agencje USA muszą załatać systemy do 5 listopada 2025 r.
  • Powiązana luka: CVE-2025-54254 (XXE, CVSS 8.6) również naprawiona w tym samym pakiecie, ale na razie nie jest na liście KEV.

Kontekst / historia / powiązania

Adobe opublikowało biuletyn APSB25-82 5 sierpnia 2025 r., rekomendując pilną aktualizację do AEM Forms na JEE 6.5.0-0108. W notatce zaznaczono, że dla CVE-2025-54253 i CVE-2025-54254 istniał publiczny PoC. 16 października 2025 r. niezależne serwisy (SecurityWeek, HNS) wskazały, że CISA dodała CVE-2025-54253 do KEV, co oznacza obserwowaną eksploatację w realnych atakach.

Analiza techniczna / szczegóły luki

Istota problemu to błędna konfiguracja pozostawiająca w interfejsie administracyjnym AEM Forms włączony Apache Struts „devMode” oraz łańcuch z ominięciem uwierzytelnienia, co razem umożliwia atakującemu wykonanie wyrażeń OGNL i eskalację do RCE – i to bez interakcji użytkownika. Wektor jest prosty (niska złożoność), a atak może był kierowany na endpoint związany z debugowaniem (np. /adminui/debug).

W biuletynie Adobe potwierdzono:

  • CVE-2025-54253 – „Incorrect Authorization”, RCE, CVSS 10.0
  • CVE-2025-54254 – XXE, odczyt plików, CVSS 8.6
    Patch docelowy: AEM Forms na JEE 6.5.0-0108; wersje dotknięte: 6.5.23.0 i starsze.

Dodatkowa dokumentacja Adobe dla administratorów precyzuje, które warianty nie są podatne (Forms na OSGi, Workbench, Cloud Service) i opisuje ścieżki aktualizacji/hotfixów dla Service Packów 18–23 oraz starszych.

Praktyczne konsekwencje / ryzyko

  • Pre-auth RCE na serwerze aplikacyjnym, często z uprawnieniami usługi AEM Forms (np. JBoss/WebLogic/WebSphere), daje napastnikowi trwały foot-hold.
  • Niska złożoność i brak interakcji użytkownika zwiększają prawdopodobieństwo automatycznych skanów i masowej eksploatacji.
  • Publiczny PoC plus wpis w KEV → realne ryzyko ransomware, web-shelli i pivotu do sieci wewnętrznej.

Rekomendacje operacyjne / co zrobić teraz

  1. Aktualizuj natychmiast: do AEM Forms na JEE 6.5.0-0108 (APSB25-82). Jeżeli używasz SP 18–22, zastosuj odpowiednie hotfixy zgodnie z instrukcją Adobe; dla 6.5.23.0 dostępny jest hotfix zbiorczy.
  2. Zweryfikuj ekspozycję: AEM Forms na JEE nie powinien być dostępny z Internetu (zwłaszcza /adminui/*). Ogranicz dostęp do panelu admina do zaufanych sieci/VPN i wymuś MFA.
  3. Tymczasowe środki twardnienia (jeśli patchowanie wymaga okna):
    • Zablokuj na WAF/proxy /adminui/debug i inne endpointy admin UI; odfiltruj wzorce OGNL.
    • Upewnij się, że Struts devMode jest wyłączony w środowiskach produkcyjnych.
  4. Higiena uprawnień i segmentacja: uruchamiaj AEM Forms z minimalnymi uprawnieniami i odseparuj serwer w strefie DMZ z ograniczonym egress. (Wniosek operacyjny na bazie wektora RCE).
  5. Detekcja i reagowanie:
    • Sprawdź logi aplikacyjne i reverse proxy pod kątem żądań do /adminui/debug oraz ładunków OGNL.
    • Szukaj nietypowych procesów dziecka (np. cmd, powershell, /bin/sh) uruchamianych przez proces aplikacyjny AEM/JEE.
    • Wdroż reguły EDR/NDR/WAF na znane ciągi OGNL oraz nienaturalne nagłówki/parametry. (Wniosek techniczny na podstawie opisu wektora).
  6. Walidacja naprawy: po aktualizacji zweryfikuj wersję i komponenty zgodnie z poradnikiem Adobe (Service Pack + wymienione EAR/WAR/JAR).
  7. Termin krytyczny (USA): jeżeli podlegasz BOD 22-01, termin remediacji to 5 listopada 2025 r.

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

  • CVE-2025-54253 (CVSS 10.0) – błąd konfiguracji (Struts devMode + auth bypass), RCE bez uwierzytelnienia; KEV → potwierdzona eksploatacja.
  • CVE-2025-54254 (CVSS 8.6) – XXE w usługach webowych AEM Forms (odczyt plików), naprawiona w tym samym wydaniu, obecnie brak potwierdzenia eksploatacji w KEV.
  • CVE-2025-49533 – dodatkowe RCE w GetDocumentServlet, również ujęte w dokumentacji łagodzenia Adobe dla AEM Forms 6.5. (Warto uwzględnić w pełnym cyklu patchowania).

Podsumowanie / kluczowe wnioski

  • To jest incydent „patch-now”: publiczny PoC + wpis w KEV + niska złożoność ataku.
  • Aktualizacja do 6.5.0-0108 i twardnienie dostępu do admin UI to minimum operacyjne.
  • Zespoły powinny przeprowadzić threat hunting po wzorcach OGNL i śladach RCE oraz zablokować ekspozycję AEM Forms na Internet.

Źródła / bibliografia

  • SecurityWeek: ostrzeżenie o wykorzystywaniu CVE-2025-54253 i kontekst KEV/BOD. (SecurityWeek)
  • Adobe APSB25-82: wersje podatne, wersja naprawcza 6.5.0-0108, oceny CVSS. (Adobe Help Center)
  • Adobe Experience League: przewodnik łagodzenia, zakres dotkniętych/wyłączonych wariantów, kroki hotfix. (Experience League)
  • Help Net Security: szczegóły techniczne (Struts devMode, OGNL, /adminui/debug), status KEV i terminy. (Help Net Security)
  • The Hacker News: podsumowanie wpływu, wersje, termin remediacji dla agencji federalnych. (The Hacker News)

Fortinet i Ivanti łatają luki o wysokiej istotności – październik 2025

Wprowadzenie do problemu / definicja luki

15 października 2025 r. Fortinet i Ivanti opublikowały październikowe biuletyny bezpieczeństwa, w których zaadresowano szereg podatności – w tym kilka o istotności „high”. Fortinet udostępnił łącznie 29 nowych porad, m.in. dla FortiOS, FortiPAM/FortiSwitchManager, FortiDLP i FortiIsolator. Ivanti wydało poprawki dla EPMM i Neurons for MDM oraz wskazówki do Endpoint Manager (EPM).

W skrócie

  • FortiOS (CVE-2025-58325, High, CVSS 7.8): lokalny uwierzytelniony użytkownik może zyskać możliwość wykonania komend systemowych przez obejście ograniczeń CLI. Łata dostępna; dotyczy wielu gałęzi 6.4–7.6.
  • FortiPAM / FortiSwitchManager (CVE-2025-49201, High): słabe uwierzytelnianie (CWE-1390) umożliwia zdalne obejście autoryzacji i wykonanie nieautoryzowanych poleceń przez spreparowane żądania HTTP.
  • FortiDLP (m.in. zależność Apache Tika): ryzyko ujawnienia danych/SSRF wynikające z podatności w bibliotece Tika używanej przez FortiDLP; dodatkowo luki podnoszące uprawnienia.
  • Ivanti EPMM & Neurons for MDM: kilka luk o wysokiej istotności, m.in. zdalne wykonanie kodu (po stronie uprzywilejowanego admina), obejście MFA i możliwość „unenroll” urządzeń; producent nie notuje exploitów „in the wild”.

Kontekst / historia / powiązania

Urządzenia Fortinet i platformy Ivanti były wielokrotnie na celowniku atakujących – część wcześniejszych luk trafiała do katalogu KEV CISA i była wykorzystywana w łańcuchach ataku na sieci brzegowe. Obecny pakiet poprawek wpisuje się w comiesięczny cykl łatania producentów i ma ograniczyć możliwość pivotowania przez kompromitację urządzeń zarządzających i filtrujących ruch. Przegląd i liczby dla października podał m.in. SecurityWeek.

Analiza techniczna / szczegóły luki

FortiOS – CVE-2025-58325 (High)

  • Wada: „Incorrect Provision of Specified Functionality” (CWE-684) w obsłudze CLI; pozwala lokalnemu, uwierzytelnionemu użytkownikowi na wykonanie komend systemowych z podwyższonymi uprawnieniami (eskalacja).
  • Zakres wersji: 7.6.0; 7.4.0–7.4.5; 7.2.5–7.2.10; 7.0.0–7.0.15; wszystkie 6.4.* (wg NVD).
  • Ocena ryzyka: CVSS 3.1: 7.8 (AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H).
  • Status: poprawki dostępne; Fortinet opublikował poradę PSIRT (FG-IR-24-361).

FortiPAM / FortiSwitchManager – CVE-2025-49201 (High)

  • Wada: słabe mechanizmy uwierzytelniania (CWE-1390) umożliwiające brute force/obejście logowania i wykonanie nieautoryzowanych poleceń.
  • Zakres wersji: FortiPAM 1.5.0; 1.4.0–1.4.2; 1.3.0–1.3.1; 1.2.0; 1.1.0–1.1.2; 1.0.0–1.0.3; FortiSwitchManager 7.2.0–7.2.4.
  • Wpływ: potencjalny RCE/komendy w kontekście aplikacji.
  • Status: łatki i porada PSIRT (FG-IR-25-010).

FortiDLP / FortiIsolator i inne komponenty

  • FortiDLP: podatności, w tym wynikające z użycia Apache Tika, mogą prowadzić do ujawnienia danych lub SSRF; dodatkowo dwa wewnętrzne EoP do LocalService/Root.
  • FortiIsolator (CVE-2024-33507, High): manipulacja ciasteczkami umożliwia deautoryzację adminów (bez uwierzytelnienia) lub nadanie uprawnień zapisu (po uwierzytelnieniu).
  • Inne produkty: aktualizacje m.in. FortiProxy, FortiManager, FortiAnalyzer, FortiWeb, FortiSOAR, FortiSIEM, FortiSASE. (Szczegółowe listy w biuletynach Fortinet).

Ivanti – EPMM i Neurons for MDM (październik 2025)

  • EPMM: trzy luki o „high severity” umożliwiające wykonanie kodu przez uwierzytelnionego admina; jedna luka „medium” (zapis na dysk).
  • Neurons for MDM: dwie luki „high” – jedna pozwala adminowi „unenroll” dowolne urządzenie (znika z UEM UI), druga to obejście MFA; dodatkowo luka „medium” w API ujawniająca wrażliwe dane bez uwierzytelnienia.
  • Status: poprawki dostępne; brak informacji o aktywnej eksploatacji.

Praktyczne konsekwencje / ryzyko

  • Ryzyko lateral movement: przejęcie urządzeń brzegowych/UEM ułatwia pivotowanie w sieci i eskalację uprawnień w domenie.
  • Zakłócenie widoczności i kontroli: „unenroll” urządzeń w MDM odcina je od polityk, co zwiększa powierzchnię ataku w mobilnym ekosystemie.
  • Utrata poufności: luki w FortiDLP/Apache Tika mogą odsłonić dane i/lub umożliwić SSRF do zasobów wewnętrznych.
  • Uprzywilejowany dostęp: obejście uwierzytelniania (FortiPAM/FortiSwitchManager) lub wykonanie komend przez CLI (FortiOS) może skutkować trwałym umocnieniem się atakującego.

Rekomendacje operacyjne / co zrobić teraz

  1. Zaktualizuj natychmiast FortiOS, FortiPAM/FortiSwitchManager, FortiDLP/FortiIsolator oraz Ivanti EPMM i Neurons for MDM do wersji wskazanych w najnowszych poradach producentów. Priorytet: systemy z dostępem administracyjnym z sieci i komponenty brzegowe.
  2. Zweryfikuj ekspozycję usług (GUI/API/SSO/CLI) – ogranicz dostęp administracyjny do sieci zarządzającej/VPN, wprowadź allow-listy IP i MFA.
  3. Rotacja haseł i kluczy dla kont serwisowych/adminów na urządzeniach Fortinet/Ivanti; sprawdź, czy nie doszło do nieautoryzowanych logowań.
  4. Przejrzyj logi pod kątem IOC: nieudane/masowe próby logowania (FortiPAM/FortiSwitchManager), nietypowe komendy w CLI (FortiOS), niespodziewane unenrolle w MDM, błędy API i anomalie ruchu wychodzącego (potencjalny SSRF).
  5. Segmentacja i least privilege: minimalizuj wpływ ewentualnego naruszenia; rozdziel płaszczyzny zarządzania od ruchu użytkowników.
  6. Zarządzanie zależnościami: jeśli używasz funkcji zależnych od bibliotek typu Apache Tika, monitoruj wersje i politykę aktualizacji.

Różnice / porównania z innymi przypadkami

  • Lokalne vs. zdalne wektory: CVE-2025-58325 wymaga konta lokalnego (AV:L), ale daje wysoki wpływ i może połączyć się z innymi błędami do pełnego przejęcia. Z kolei CVE-2025-49201 ma wektor sieciowy (AV:N), co podnosi priorytet twardego ograniczenia ekspozycji usług HTTP/GUI.
  • UEM/MDM jako cel: luki w Ivanti nie wymagają zero-day do masowego nadużycia – wystarczy skompromitowane konto admina lub błędy konfiguracji, by wyłączyć ochronę urządzeń mobilnych (unenroll) lub ominąć MFA.

Podsumowanie / kluczowe wnioski

  • Październikowe poprawki Fortinet i Ivanti zamykają istotne luki, które w złych rękach mogą stać się elementem skutecznych łańcuchów ataku.
  • Administratorzy powinni niezwłocznie aktualizować wskazane produkty, ograniczyć powierzchnię ataku (ekspozycja GUI/API/CLI), włączyć ścisłe monitorowanie i przeprowadzić przegląd logów pod kątem anomalii.
  • Brak doniesień o aktywnej eksploatacji to okno możliwości na bezpieczne wdrożenie łatek, zanim pojawią się publiczne PoC lub masowe skanowanie.

Źródła / bibliografia

  1. SecurityWeek: „High-Severity Vulnerabilities Patched by Fortinet and Ivanti” (15.10.2025). (SecurityWeek)
  2. Fortinet PSIRT (FG-IR-24-361): Restricted CLI command bypass – CVE-2025-58325 (14.10.2025). (fortiguard.fortinet.com)
  3. NVD: CVE-2025-58325 – FortiOS CLI command bypass (14.10.2025). (NVD)
  4. Fortinet PSIRT (FG-IR-25-010): Weak authentication in FortiPAM/FortiSwitchManager – CVE-2025-49201 (14.10.2025). (fortiguard.fortinet.com)
  5. Ivanti: „October 2025 Security Advisory – Neurons for MDM / EPMM” (październik 2025). (forums.ivanti.com)

F5 obwinia „aktorów państwowych” o kradzież kodu źródłowego i danych o podatnościach BIG-IP

Wprowadzenie do problemu / definicja incydentu

15 października 2025 r. F5 ujawniło w raporcie Form 8-K oraz komunikacie do klientów, że wysoce zaawansowany, prawdopodobnie sponsorowany przez państwo napastnik utrzymywał długotrwały dostęp do wybranych systemów firmy, m.in. do środowiska rozwoju BIG-IP i platform wiedzy inżynierskiej. Z systemów tych wyeksfiltrowano pliki zawierające fragmenty kodu źródłowego BIG-IP oraz informacje o niewydanych jeszcze podatnościach (niepublicznych). F5 twierdzi, że nie ma dowodów na modyfikację łańcucha dostaw (pipeline’y build/release), ani na dostęp do środowisk NGINX, Distributed Cloud czy Silverline.

O sprawie jako pierwsze szeroko doniosły branżowe media, wskazując także, że profil ataku może wskazywać na Chiny.

W skrócie

  • Kiedy wykryto: 9 sierpnia 2025 r.; ujawnienie odroczono za zgodą DOJ (Item 1.05(c) 8-K).
  • Co ukradziono: pliki z częściami kodu BIG-IP i informacjami o niewydanych podatnościach; częściowo także konfiguracje/implementacje niewielkiego odsetka klientów.
  • Czego nie stwierdzono: brak dowodów na modyfikację supply chain, brak dostępu do CRM/finansów/iHealth/wsparcia; brak oznak aktywnego wykorzystywania „nieujawnionych krytycznych/ RCE” podatności F5.
  • Aktualizacje/łagodzenie: opublikowano zbiorcze biuletyny/aktualizacje październikowe dla BIG-IP, F5OS, BIG-IP Next, BIG-IQ i APM; F5 zaleca natychmiastowe wdrożenie.
  • Potwierdzenia zewnętrzne: media i niezależne serwisy powtórzyły główne tezy; NCSC wydało krótką notę z zaleceniem pilnych aktualizacji.

Kontekst / historia / powiązania

Urządzenia i oprogramowanie F5 BIG-IP od lat znajdują się w centrum uwagi APT i cyberprzestępców (m.in. fale exploitacji CVE-2020-5902, CVE-2022-1388 czy pary CVE-2023-46747/-46748). Trwałe utrzymanie się napastników w środowiskach wykorzystujących BIG-IP bywało wcześniej wiązane z chińsko-języcznymi grupami (np. kampania „Velvet Ant” z wykorzystaniem starszych urządzeń F5 dla utrzymania persystencji). Dzisiejszy incydent wpisuje się w ten trend polowania na źródła i wiedzę o 0-day u producentów.

Analiza techniczna / szczegóły luki

Z udostępnionego klientom oświadczenia (Exhibit 99.1 do 8-K) wynika, że:

  • Atakujący posiadali długoterminową persystencję w sieci F5, obejmującą repozytoria kodu i systemy KM.
  • Eksfiltracja objęła m.in. fragmenty kodu BIG-IP oraz opisy/artefakty podatności będących „w toku” (nieopublikowanych).
  • F5 nie zidentyfikowało dowodów na naruszenie łańcucha dostaw (źródła, build’y, pipeline’y), co potwierdziły niezależne audyty NCC Group i IOActive.
  • Brak dowodów na dostęp do NGINX oraz usług chmurowych F5, co ogranicza bezpośredni wektor supply-chain dla tych linii.

Choć firma podkreśla brak wiedzy o krytycznych/RCE nieujawnionych błędach, sama kradzież wiedzy o lukach zwiększa prawdopodobieństwo samodzielnego opracowania exploitów przez APT przed publikacją biuletynów („pre-disclosure weaponization”). To klasyczny wyścig z czasem: jeżeli opis podatności/patch różnicowy trafił do przeciwnika, okno narażenia dla klientów może się skrócić do tygodni lub dni.

Praktyczne konsekwencje / ryzyko

  • Ryzyko exploitów „day-(-1)” – użycie informacji o nieopublikowanych lukach F5 do cichych, ukierunkowanych wejść (szczególnie tam, gdzie konfiguracja BIG-IP bywa złożona i historycznie zaniedbana).
  • Rozpoznanie środowisk klientów – wyciek konfiguracji/implementacji części organizacji ułatwia lateral movement i selektywne omijanie WAF/ASM/AFM/APM.
  • Reputacyjne i regulacyjne – formalne ujawnienie w 8-K oznacza „material event” z potencjalnym wpływem na decyzje użytkowników i rynków; samo F5 ocenia na dziś brak istotnego wpływu operacyjnego.
  • Fala skanowania i prób dostępu – po medialnym nagłośnieniu zwykle rośnie aktywność botnetów i „copy-cats”.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiastowe aktualizacje: wdrożyć październikowe wydania dla BIG-IP/F5OS/BIG-IP Next/BIG-IQ/APM zgodnie z biuletynem F5. Zaplanuj rolling upgrade i weryfikację po-update’ową.
  2. Threat hunting pod kątem F5:
    • Przejrzeć logi TMOS/ASM/APM oraz syslog z event streaming do SIEM (zgodnie z KB F5 – wzorce: logowania admin, nieudane auth, zmiany uprawnień/konfiguracji).
    • Użyć zaleceń F5 dot. twardnienia (hardening checks w iHealth) i porównać z własnymi benchmarkami.
  3. Segmentacja i kontrola dostępu: odseparować interfejsy zarządcze BIG-IP (Mgmt/SSH/TMU) od sieci produkcyjnych, wymusić MFA i listy dozwolonych.
  4. Repozytoria i tajemnice: skontrolować własne integracje CI/CD z BIG-IP (np. AS3/DO/FAST). Zmienić poświadczenia, tokeny API, klucze iControl REST.
  5. Atesty konfiguracji klientów: jeśli korzystasz z partnerów/Integratorów, zażądaj potwierdzenia, że nie używali artefaktów/fragmentów konfigów podatnych na wyciek.
  6. Monitoring exploitów: śledzić biuletyny CISA KEV i krajowe CERT-y; NCSC rekomenduje pilne wdrożenie poprawek F5.
  7. Plan awaryjny: przygotować playbook „virtual patching” na F5 (np. tymczasowe iRules/policy WAF) w razie pojawienia się PoC przed pełnym patchem.

Różnice / porównania z innymi przypadkami

  • SolarWinds/3CX – głęboka manipulacja supply chain; tutaj F5 i niezależne audyty raportują brak modyfikacji pipeline’ów i artefaktów wydań, co zmniejsza ryzyko „zatrutych” aktualizacji.
  • Wycieki „knowledge-base” u dostawców (np. przypadki wiązane z MAPP/SharePoint) – wspólny motyw to pozyskanie wiedzy o 0-day przed publikacją, a niekoniecznie natychmiastowe uderzenie supply-chain. W doniesieniach prasowych o incydencie F5 przewija się hipoteza o aktorze z Chin, spójna z wcześniejszymi kampaniami przeciw producentom infrastruktury.

Podsumowanie / kluczowe wnioski

  • Incydent nie wygląda na kompromitację łańcucha dostaw, ale na wyciek kodu i „researchu” o lukach – co nadal jest poważnym zagrożeniem.
  • Czas działa na korzyść obrońców tylko wtedy, gdy szybko wdrożą aktualizacje i wymuszą twardnienie/monitoring zgodnie z zaleceniami F5.
  • Organizacje z krytycznymi wdrożeniami BIG-IP powinny traktować najbliższe tygodnie jako okres podwyższonego czuwania i aktywnie polować na anomalie.

Źródła / bibliografia

  1. F5 – Security Incident: Disclosure Statement (Exhibit 99.1 do 8-K, 15.10.2025) – szczegóły o eksfiltracji, produktach i zaleceniach. (SEC)
  2. SEC EDGAR – F5, Inc. Form 8-K (15.10.2025) – formalne zgłoszenie incydentu (Item 1.05). (SEC)
  3. SecurityWeek (15.10.2025) – przegląd incydentu i wskazanie na profil ataku sugerujący Chiny. (SecurityWeek)
  4. BleepingComputer (15.10.2025) – streszczenie zakresu eksfiltracji i harmonogramu wykrycia. (BleepingComputer)
  5. NCSC (UK) – nota potwierdzająca kompromitację i zalecająca wdrożenie aktualizacji. (NCSC)

CISA dodaje 5 nowych luk do katalogu KEV (14 października 2025) — co to oznacza dla Twojej organizacji

Wprowadzenie do problemu / definicja luki

14 października 2025 r. amerykańska CISA dodała pięć nowych, aktywnie wykorzystywanych luk do katalogu Known Exploited Vulnerabilities (KEV). Dodanie do KEV oznacza, że istnieją wiarygodne dowody nadużyć „in the wild”, a dla agencji federalnych wyznaczany jest twardy termin remediacji zgodnie z dyrektywą BOD 22-01. W praktyce to także sygnał „patch now” dla sektora prywatnego.

W skrócie

  • Nowe CVE w KEV (5):
    • CVE-2025-24990 — Windows (sterownik Agere Modem, „untrusted pointer dereference”).
    • CVE-2025-47827 — IGEL OS 10 (obejście Secure Boot przez użycie klucza po dacie ważności).
    • CVE-2025-59230 — Windows Remote Access Connection Manager (podniesienie uprawnień).
    • CVE-2016-7836 — SKYSEA Client View (zdalne wykonanie kodu, CVSS 9.8).
    • CVE-2025-6264 — Rapid7 Velociraptor (błędne domyślne uprawnienia → wykonanie poleceń).
  • Dlaczego teraz? Fala wpisów koreluje z październikowym Patch Tuesday (Microsoft) i świeżymi obserwacjami nadużyć (m.in. Velociraptor w incydentach ransomware).
  • Termin (FCEB): dla nowych pozycji z 14.10.2025 CISA wyznacza deadline 4 listopada 2025. To dobra praktyka także dla firm prywatnych.

Kontekst / historia / powiązania

Katalog KEV to „lista wstydu” produktów z lukami, które naprawdę są wykorzystywane. Wpis do KEV wymusza na podmiotach federalnych priorytetową remediację (zwykle w 21 dni), a w wyjątkowych sytuacjach — szybciej. W 2025 r. KEV był wielokrotnie uzupełniany falami po Patch Tuesday oraz po publicznych raportach o nadużyciach (np. ransomware wykorzystujący Velociraptor).

Analiza techniczna / szczegóły luki

1) CVE-2025-24990 — Microsoft Windows (sterownik Agere Modem)

  • Typ/efekt: dereferencja niezaufanego wskaźnika w sterowniku, potencjalne EoP/RCE w zależności od kontekstu wywołania.
  • Kontekst: sterownik jest dostarczany z wieloma wersjami Windows; Microsoft oznaczył problem jako eksploatowany.
  • Działania: usuń/wyłącz sterownik tam, gdzie niepotrzebny; zastosuj poprawki Microsoftu.

2) CVE-2025-47827 — IGEL OS 10 (Secure Boot bypass)

  • Typ/efekt: bypass Secure Boot — użycie klucza po dacie ważności w module igel-flash-driver umożliwia podmianę obrazu rootfs (SquashFS) i uruchomienie niepodpisanego systemu.
  • Wpływ: fizyczny napastnik może osiągnąć trwałą, wczesną persystencję (bootkit).
  • Termin KEV: dodane 14.10 → due 04.11.2025 (wpis CISA odnotowany w NVD).
  • Działania: aktualizacja do IGEL OS v11+; wymuszenie poprawnego łańcucha zaufania i weryfikacji podpisów.

3) CVE-2025-59230 — Windows RASMAN (Elevation of Privilege)

  • Typ/efekt: Improper Access Control → lokalne EoP do SYSTEM.
  • Wektor: lokalny, niski poziom złożoności (AC:L).
  • Działania: wdrożyć poprawki z październikowego Patch Tuesday; uzupełnić detekcje na nietypowe użycia usług RAS.

4) CVE-2016-7836 — SKYSEA Client View (RCE)

  • Typ/efekt: Improper Authentication w połączeniu TCP z konsolą zarządzającą → RCE bez uwierzytelnienia; CVSS 3.x: 9.8 (CRITICAL).
  • Status KEV: dodane 14.10.2025 z terminem 04.11.2025.
  • Działania: aktualizacja powyżej wersji 11.221.03; segmentacja sieci, ograniczenie dostępu do portów zarządzania.

5) CVE-2025-6264 — Rapid7 Velociraptor (default permissions)

  • Typ/efekt: artefakt Admin.Client.UpdateClientConfig nie wymagał dodatkowego uprawnienia; użytkownik z rolą Investigator mógł zdalnie zaktualizować konfigurację klienta i wykonać polecenia → przejęcie endpointu.
  • Kontekst nadużyć: wykorzystywane w realnych atakach (m.in. kampanie ransomware); wpis do KEV z terminem 04.11.2025.
  • Działania: aktualizacja do wersji z łatką; przegląd ról/uprawnień i artefaktów; telemetria na „nietypowe” aktualizacje konfiguracji klienta.

Praktyczne konsekwencje / ryzyko

  • Łańcuchy ataków mieszanych: lokalne EoP w Windows (CVE-2025-59230, CVE-2025-24990) świetnie łączą się z ucieczkami z przeglądarek/aplikacji jako etap 2 eskalacji.
  • Uderzenie w kontrolę rozruchu: obejście Secure Boot (IGEL) umożliwia „pre-EDR” trwałość — klasyczne narzędzie APT i operatorów ransomware.
  • Nadużywanie narzędzi „dobrych”: Velociraptor w rękach napastnika zmniejsza szanse detekcji (Living-off-the-Land Tooling).
  • Dziedzictwo w środowisku: stary SKYSEA (2016) pokazuje, że legacy potrafi wrócić jako „nowo” eksploatowane, jeśli pozostało w ekosystemie.

Rekomendacje operacyjne / co zrobić teraz

  1. Priorytet łatania do 4 listopada 2025 (lub szybciej w środowiskach wysokiego ryzyka):
    • Windows: wdrożyć pełny zestaw poprawek z Patch Tuesday (X.2025); osobno usunąć/wyłączyć sterownik Agere tam, gdzie niepotrzebny.
    • IGEL OS: aktualizacja do v11+, weryfikacja implementacji Secure Boot, odświeżenie kluczy.
    • Velociraptor: aktualizacja do wersji z łatką; przegląd ról (odebranie zbędnego COLLECT_CLIENT), ograniczenie artefaktów administracyjnych; monitorowanie nietypowych update’ów konfiguracji.
    • SKYSEA: aktualizacja powyżej 11.221.03; izolacja hostów zarządzania; wymuszenie TLS i list ACL na portach zarządzania.
  2. Detekcja i hunting (propozycje szybkich use-case’ów):
    • Windows EoP: nietypowe uruchomienia/usługi RAS, anomalie w sterownikach, ładowanie ltmdm64.sys (Agere).
    • IGEL: integralność łańcucha rozruchu, zmiany w partycji rozruchowej, niestandardowe obrazy SquashFS.
    • Velociraptor: zdarzenia „UpdateClientConfig”, modyfikacje polityk klienta, uruchomienia powłoki/VS Code z procesu agenta.
  3. Higiena uprawnień i ekspozycji: minimalizacja ról „Investigator” w Velociraptorze; ograniczenie dostępu do konsol (SKYSEA) sieciowo i VPN; app allow-listing dla narzędzi z uprawnieniami systemowymi.
  4. Zarządzanie ryzykiem dostawców/OT: jeśli używasz IGEL lub SKYSEA w środowiskach kiosków/terminali/OT, zaplanuj okno serwisowe i rollback plan — obejście Secure Boot w terminalach może zniweczyć kontrolę zaufania na brzegu.

Różnice / porównania z innymi przypadkami

  • Stara luka, nowe nadużycia: CVE-2016-7836 (SKYSEA) przypomina inne „archeologiczne” wpisy KEV — podatności latami „znane”, ale wciąż wykorzystywane tam, gdzie oprogramowanie przetrwało w niszach.
  • LOLBIN vs. LOTool: w 2024–2025 dużo mówiliśmy o LOLBIN-ach; przypadek Velociraptora to LOTool — legalne narzędzie admina użyte jako wektor ataku (podobnie jak nadużycia RMM/EDR).

Podsumowanie / kluczowe wnioski

  • KEV = kolejka „MUST-DO”: pięć nowych pozycji to czytelny backlog na najbliższe dni.
  • Zwróć uwagę na łańcuch startowy i narzędzia admina (IGEL, Velociraptor) — to wektory o wysokiej wartości dla napastników.
  • Nie zapominaj o legacy: nawet „odległe” CVE (SKYSEA 2016) wracają, jeśli produkt nadal żyje w środowisku.
  • Termin dla FCEB: 4 listopada 2025 — rozsądny SLA także dla sektora prywatnego.

Źródła / bibliografia

  1. CISA — Strona główna (zapowiedź alertu z 14.10.2025). (CISA)
  2. NVD (NIST) — CVE-2016-7836 (SKYSEA) — opis, CVSS 9.8, wpis do KEV z terminem 04.11.2025. (NVD)
  3. NVD (NIST) — CVE-2025-59230 (Windows RASMAN) — opis EoP. (NVD)
  4. NVD (NIST) — CVE-2025-6264 (Rapid7 Velociraptor) — opis błędnych uprawnień. (NVD)
  5. NVD/CVE.org / analizy Patch Tuesday — CVE-2025-24990 (Agere driver) — rekord CVE; dodatkowy kontekst eksploatacji i rekomendacji z przeglądu Patch Tuesday (Tenable). (CVE)

RMPocalypse: nowy atak łamie gwarancje „confidential computing” AMD (CVE-2025-0033)

Wprowadzenie do problemu / definicja luki

Badacze z ETH Zürich opisali atak RMPocalypse pozwalający obejść gwarancje integralności AMD SEV-SNP (Secure Encrypted Virtualization – Secure Nested Paging). Błąd oznaczony jako CVE-2025-0033 wynika z warunku wyścigu podczas inicjalizacji RMP (Reverse Map Table) przez AMD Secure Processor (ASP/PSP) i umożliwia uprzywilejowanemu hipernadzorcy zapis do pamięci RMP, co unieważnia kontrolę własności stron i łamie integralność gościa. AMD potwierdziło problem w biuletynie AMD-SB-3020 (opublikowany 13 października 2025 r.).

W skrócie

  • Identyfikator: CVE-2025-0033 (CVSS v3.1: 6.0 / v4.0: 5.9 – „Medium”).
  • Wpływ: utrata integralności pamięci gościa SEV-SNP; w praktyce może prowadzić także do utraty poufności (atakujący kontroluje RMP).
  • Wymogi ataku: uprawnienia admin/host (złośliwy lub przejęty hipernadzorca).
  • Zasięg: procesory EPYC generacji 7003/8004/9004/9005 (w tym nowe Turin); warianty Embedded – część z poprawkami planowanymi na późniejsze terminy.
  • Mitigacje: aktualizacje SEV firmware/µcode lub nowe AGESA/PI (dostarczane do OEM/CSP; wymagane aktualizacje BIOS/hostów).
  • Dostępność exploita: badania akademickie; brak informacji o atakach w naturze w momencie publikacji, ale ryzyko jest realne dla modeli zagrożeń „złośliwy operator hosta/hipernadzorcy”.

Kontekst / historia / powiązania

SEV-SNP to fundament wielu ofert Confidential Computing dla VM-ów w chmurach publicznych – zapewnia szyfrowanie pamięci i integralność mapowań poprzez RMP. ETH od lat analizuje powierzchnię ataku na SEV-SNP (np. WeSee, Heracles); RMPocalypse to kolejny dowód, że „root w hypervisorze” pozostaje krytycznym przeciwnikiem nawet dla TEE opartych o CPU. Artykuł naukowy został zaprezentowany na ACM CCS 2025.

Analiza techniczna / szczegóły luki

Reverse Map Table (RMP) przechowuje metadane bezpieczeństwa dla wszystkich stron DRAM i egzekwuje własność stron (host vs. konkretna CVM). Aby uniknąć „kurczak-i-jajko”, inicjalizację RMP wykonuje ASP, a x86-rdzenie i hypervisor nie powinny móc modyfikować RMP.

Badacze wykazali, że podczas inicjalizacji RMP istnieje okno czasowe (race), w którym ASP nie chroni wystarczająco buforów RMP w DRAM. Uprzywilejowany hypervisor może wstrzyknąć zanieczyszczone linie cache/jednorazowy zapis w RMP, a następnie wymusić ich spłukanie – skutkuje to dowolnym nadpisaniem wpisów RMP. Jedno 8-bajtowe nadpisanie może skompromitować całą tabelę, ponieważ kolejne kontrole integralności opierają się na już zanieczyszczonym RMP.

W efekcie możliwe są demonstracje: fałszowanie atestacji, włączenie debug na CVM produkcyjnym, replay VMSA, wstrzyknięcia kodu. Zespół zreprodukował atak na Zen 3/Zen 4/Zen 5.

Praktyczne konsekwencje / ryzyko

  • Modele chmurowe: w modelu zaufania „CSP=możliwy przeciwnik”, przejęcie warstwy hosta/hipernadzorcy (lub złośliwy insider) może obejść integralność SEV-SNP dla uruchomionych CVM, co otwiera drogę do eskalacji do poufności (np. wycieki kluczy/sekretów po wstrzyknięciu kodu).
  • Multi-tenant/on-prem: ryzyko dotyczy też operatorów HCI/virtualizacji z zaufaniem dzielonym; separacja tenantów może zostać podkopana, jeśli host jest podatny i uprzywilejowany użytkownik jest złośliwy/skompr.
  • Ryzyko operacyjne: możliwe restarty hostów/CVM w oknach serwisowych CSP podczas wdrażania firmware (wpływ na SLA). Microsoft zapowiedział mitygacje w klastrach Azure Confidential Computing.

Rekomendacje operacyjne / co zrobić teraz

Dla dostawców chmury i operatorów (CSP/hosting):

  1. Inwentaryzacja generacji EPYC i statusu SEV-SNP na hostach.
  2. Wdrożenie poprawek AMD-SB-3020:
    • aktualizacja SEV FW + µcode lub ścieżka AGESA/PI zgodnie z tabelami w biuletynie (np. Milan: SEV FW 1.37.23 + µcode 0x0A0011DE; Genoa: SEV FW 1.37.31 + µcode 0x0A101156; Turin: SEV FW 1.37.41 itd.). Planowanie okien zgodnie z datami dla OEM.
  3. CIS/Hardening hypervisora: minimalizacja powierzchni uprzywilejowanego kodu, wzmocnienie ścieżek administracyjnych i audytu (least privilege, JIT/JEA, PAM).
  4. Monitorowanie anomalii CVM: polityki wykrywania nietypowych resetów/zmian w atestacji i włączenia debug.

Dla klientów korzystających z Confidential VM (Azure/GCP/AWS na AMD):

  1. Sprawdź komunikaty CSP – aktualizacje/rekonfiguracje mogą wymagać restartów zasobów. (Azure ACC zapowiedział działania; analogicznych komunikatów oczekuj w innych chmurach).
  2. Weryfikuj atestację CVM po każdym restarcie/rotacji – automatycznie egzekwuj polityki „fail-closed”, jeśli atestacja nie spełnia profilu (TCB wersje/firmware).
  3. Segmentacja i minimal trust: klucze o najwyższej wrażliwości trzymaj w HSM/KMS z ograniczeniem ekspozycji w CVM (np. podpisy „off-box”).
  4. Plan awaryjny: jeśli workload ma rygorystyczne wymagania integralności, rozważ czasowe wyłączenie SNP-CVM na hostach bez patchy lub migrację do hostów zweryfikowanych przez CSP.

Różnice / porównania z innymi przypadkami

  • WeSee (2024) uderzał w mechanizm #VC i interakcje VM–hypervisor; RMPocalypse celuje w inicjalizację RMP i jest bardziej deterministyczny przy uprawnieniach hosta.
  • Heracles (2025) – atak wybranej wiadomości na SEV-SNP; RMPocalypse łamie rdzeń integralności mapowań i w konsekwencji może umożliwić podobne efekty (np. spoofing atestacji), lecz inną drogą.
  • W odróżnieniu od pobocznych kanałów (np. ciphertext SC), tutaj jednorazowy zapis 8 bajtów w RMP podczas okna inicjalizacji wystarcza do „rozsypania” gwarancji.

Podsumowanie / kluczowe wnioski

  • RMPocalypse obnaża podatność „chwili zerowej” – jeśli RMP nie jest w pełni chronione w trakcie inicjalizacji, cały łańcuch zaufania SEV-SNP może zostać trwale podważony dla danej instancji.
  • Działaj teraz: operatorzy i CSP powinni wdrożyć firmware wg AMD-SB-3020, a klienci wymuszać atestację i obserwować komunikaty CSP o oknach serwisowych.
  • Długofalowo: redukcja zaufania do hipernadzorcy musi mieć odbicie w projektach TEE – inicjalizacja krytycznych struktur (jak RMP) nie może w żadnym momencie polegać na założeniu, że host jest „uczciwy”.

Źródła / bibliografia

  1. SecurityWeek – RMPocalypse: New Attack Breaks AMD Confidential Computing (14 października 2025). (SecurityWeek)
  2. AMD – AMD-SB-3020: SEV-SNP RMP Initialization Vulnerability (13 października 2025) – detale CVE, produkty i wersje FW/µcode/AGESA. (AMD)
  3. Schlüter B., Shinde S. – RMPocalypse: How a Catch-22 Breaks AMD SEV-SNP (CCS 2025, preprint PDF). (shwetashinde.org)
  4. ETH Zürich – ETH researchers uncover vulnerability in confidential cloud environments (artykuł uczelni, 2 dni temu). (ETH Zürich)
  5. The Hacker News – RMPocalypse: Single 8-Byte Write Shatters AMD’s SEV-SNP Security (14 października 2025). (The Hacker News)

SonicWall: masowe przejęcia kont SSL VPN po incydencie z kopią zapasową konfiguracji — co wiemy i co robić

Wprowadzenie do problemu / definicja luki

10 października 2025 r. firma Huntress ostrzegła przed szeroko zakrojoną kampanią przejęć kont SonicWall SSL VPN, w której napastnicy logowali się „lawinowo” na wiele kont, najpewniej używając prawidłowych poświadczeń, a nie siłowego łamania haseł. Do 10 października skompromitowano ponad 100 kont w 16 środowiskach, a znaczna część aktywności zaczęła się 4 października. SecurityWeek potwierdził skalę zjawiska, powołując się na dane Huntress.

W skrócie

  • Co się stało: trwają ataki polegające na poprawnym logowaniu do kont SSL VPN w urządzeniach SonicWall (bez brute force). Jedno ze źródeł logowań wskazuje na adres 202.155.8[.]73.
  • Kontekst: kilka dni wcześniej SonicWall ujawnił, że nieuprawniony dostęp do usługi MySonicWall Cloud Backup objął wszystkich klientów przechowujących kopie konfiguracji firewalli (pierwotnie szacowano <5%).
  • Czy sprawy są powiązane? Huntress nie ma dowodów na bezpośrednie powiązanie, ale go nie wyklucza.
  • Ryzyko: wyciek zaszyfrowanych poświadczeń i danych konfiguracyjnych może ułatwić ataki ukierunkowane; obserwowane są także skanowania sieci i próby dostępu do kont w domenie.

Kontekst / historia / powiązania

8 października 2025 r. SonicWall zaktualizował poradnik incydentowy, kończąc dochodzenie (z Mandiant) i potwierdzając, że wszystkie kopie konfiguracji przechowywane w chmurze były dostępne dla atakującego. CISA z kolei opublikowała ostrzeżenie i wskazówki dla klientów SonicWall w związku z tym zdarzeniem.

W lipcu–wrześniu obserwowano równolegle aktywność związaną z ransomware Akira i urządzeniami SonicWall/SMA/SSL VPN; mimo że to inna oś narracji, podkreśla ona rosnącą atrakcyjność ekosystemu SonicWall dla grup przestępczych.

Analiza techniczna / szczegóły luki

  • Wektor dostępu w bieżącej kampanii: logowania z prawidłowymi poświadczeniami do SSL VPN (szybkie serie logowań; brak oznak bruteforce). Część sesji kończy się natychmiastowym rozłączeniem, w innych przypadkach stwierdzono działania potexploitacyjne (skanowanie, próby dostępu do lokalnych kont Windows).
  • Incydent chmurowy MySonicWall: napastnik uzyskał dostęp do plików kopii konfiguracji (zawierających m.in. zaszyfrowane hasła/sekrety, reguły, ustawienia VPN, integracje LDAP/RADIUS/TACACS+, SNMP, itp.). SonicWall udostępnił klientom listy dotkniętych urządzeń i klasyfikację priorytetów (Active High/Low/Inactive).
  • Status powiązania zdarzeń: Huntress podkreśla brak dowodu, że masowe logowania są bezpośrednim skutkiem incydentu kopii zapasowej — ale taka możliwość istnieje (np. odtworzenie haseł/sekretów, korelacja konfiguracji).

Praktyczne konsekwencje / ryzyko

  • Ryzyko nadużyć poświadczeń: nawet jeśli dane w kopiach były zaszyfrowane, metadane i konfiguracje mogą obniżyć koszt rekonesansu i ułatwić obejście zabezpieczeń perymetrowych.
  • Ryzyko lateral movement: potwierdzone skanowanie sieci i próby kompromitacji kont AD wskazują na możliwość szybkiej eskalacji uprawnień po wejściu przez SSL VPN.
  • Ryzyko „cichego” dostępu: część aktorów kończy sesję bez dalszych działań — możliwe przygotowanie do późniejszych kampanii lub testy ważności poświadczeń. (Wniosek na podstawie obserwacji Huntress).

Rekomendacje operacyjne / co zrobić teraz

Poniższe kroki zbierają zalecenia SonicWall, Huntress i CISA — w kolejności „od teraz do stabilizacji”:

  1. Natychmiast ogranicz zdalne zarządzanie i dostęp WAN (HTTP/HTTPS/SSH/SSL VPN), aż do pełnej rotacji sekretów; jeśli to możliwe, odetnij zarządzanie z Internetu.
  2. Wymuś pełną rotację wszystkich sekretów powiązanych z firewallami/SSL VPN: hasła lokalnych adminów, pre-shared keys VPN, klucze/hasła do LDAP/RADIUS/TACACS+, PSK Wi-Fi, SNMP, API (DDNS, SMTP/FTP, automatyzacje).
  3. Zmień hasła w MySonicWall i wszystkich zewnętrznych integracjach; usuń stare kopie w chmurze, wykonaj nowe lokalne (po rotacji). Sprawdź portal MySonicWall → Product Management → Issue List i priorytety urządzeń.
  4. Włącz/Mandatuj MFA dla wszystkich kont administracyjnych i zdalnych; zrewiduj role i zasady najmniejszych uprawnień.
  5. Zwiększ logowanie i retencję: przeanalizuj nietypowe logowania, zmiany konfiguracji, zestawienia tuneli; zachowaj logi do analizy powłamaniowej.
  6. Stopniowo przywracaj usługi po rotacji haseł, monitorując, czy nie powracają nieautoryzowane logowania.
  7. Zastosuj wskazówki CISA/SonicWall z aktualnych poradników dot. incydentu chmurowego i twardnienia konfiguracji.

Różnice / porównania z innymi przypadkami

  • Nie jest to klasyczna luka „do załatania” w firmware (jak CVE-2024-40766 w przeszłości), lecz konsekwencje kompromitacji usługi kopii zapasowej i/lub wtórnego nadużycia poświadczeń — dlatego kluczowe są rotacja sekretów i hardening, a nie patch.
  • Kampania logowań (październik 2025) różni się od wcześniejszych fal, gdzie wykorzystywano podatności SMA/SSL VPN lub 0-daye; tutaj dominują poprawne logowania i „masowe” użycie jednego adresu źródłowego.

Podsumowanie / kluczowe wnioski

  • 8–10 października 2025 r.: SonicWall finalizuje dochodzenie (z Mandiant) i potwierdza pełny zakres incydentu kopii konfiguracyjnych w chmurze; niemal równolegle Huntress sygnalizuje masowe przejęcia kont SSL VPN z użyciem prawidłowych poświadczeń.
  • Brak twardego dowodu na związek, ale ryzyko wtórnych nadużyć jest wysokie.
  • Priorytetem jest szybka rotacja wszystkich sekretów, ograniczenie ekspozycji usług i wzmożony monitoring.

Źródła / bibliografia

  1. SecurityWeek — SonicWall SSL VPN Accounts in Attacker Crosshairs, 13 paź 2025. SecurityWeek
  2. Huntress — Threat Advisory: Widespread SonicWall SSLVPN Compromise, 10 paź 2025. Huntress
  3. SonicWall — MySonicWall Cloud Backup File Incident (aktualizacja 8 paź 2025). SonicWall
  4. CISA — SonicWall releases advisory… (22 wrz 2025). CISA
  5. SecurityWeek — All SonicWall Cloud Backup Users Had Firewall Configurations Stolen, 9 paź 2025. SecurityWeek

Hiszpania rozbija syndykat „GXC Team”. Zatrzymano 25-letniego lidera „GoogleXcoder”

Wprowadzenie do problemu

Hiszpańska Guardia Civil rozbiła działający na Telegramie i rosyjskojęzycznych forach syndykat cyberprzestępczy „GXC Team”, aresztując jego domniemanego lidera — 25-letniego Brazylijczyka znanego jako „GoogleXcoder”. Grupa sprzedawała w modelu Crime-as-a-Service (CaaS) zestawy phishingowe z funkcjami AI, złośliwe aplikacje na Androida do przechwytywania SMS/OTP oraz narzędzia do scamów głosowych. Celem były m.in. banki, firmy transportowe i e-commerce w Hiszpanii oraz innych krajach.

Czytaj dalej „Hiszpania rozbija syndykat „GXC Team”. Zatrzymano 25-letniego lidera „GoogleXcoder””