Archiwa: Security News - Strona 289 z 289 - Security Bez Tabu

Kategoria: Security 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

Microsoft uszczelnia IE Mode w Edge po atakach z wykorzystaniem 0-day w Chakra

Wprowadzenie do problemu / definicja luki

Microsoft przebudował sposób uruchamiania Internet Explorer (IE) mode w przeglądarce Edge po „wiarygodnych doniesieniach” o realnych atakach z sierpnia 2025 r., w których napastnicy przekształcali tę funkcję kompatybilności w furtkę do przejęcia systemu. W odpowiedzi usunięto szybkie „wejścia” do IE mode (przycisk na pasku, opcje w menu kontekstowym i hamburger menu), pozostawiając włączanie trybu wyłącznie przez ustawienia i listy witryn.

W skrócie

  • Ataki wykorzystywały 0-day w silniku JavaScript IE (Chakra) oraz drugi exploit do eskalacji uprawnień poza przeglądarkę.
  • Microsoft nie ujawnił CVE ani atrybucji, ale usztywnił IE mode: zniknęły szybkie przełączniki; uruchamianie wymaga dodania domeny do listy w ustawieniach/Politykach.
  • IE jest oficjalnie wycofany od 15 czerwca 2022 r., a IE mode w Edge istnieje dla zachowania zgodności z dziedzictwem — i to on bywa dziś „duchem IE” w środowiskach korporacyjnych.

Kontekst / historia / powiązania

IE 11 został formalnie wycofany, lecz IE mode pozwala na renderowanie starszych aplikacji (ActiveX, BHO itd.) w Edge przy użyciu silnika Trident/MSHTML właśnie po to, by przedsiębiorstwa nie musiały utrzymywać dwóch przeglądarek. Ta funkcja była i jest zależna od obecności komponentów IE w systemie i — zgodnie z dokumentacją — jest wspierana w środowiskach organizacji poprzez Enterprise Site List.

Analiza techniczna / szczegóły luki

Z opisu zespołu Microsoft Browser Vulnerability Research wynika, że łańcuch ataku wyglądał następująco:

  1. ofiara trafia na pozornie legalną stronę; 2) interfejs strony (np. flyout) nakłania do „przeładowania w IE mode”; 3) po przełączeniu, atakujący odpala 0-day w Chakra i uzyskuje RCE; 4) następnie wykorzystuje drugi exploit do EoP, przejmując pełną kontrolę nad urządzeniem. Krytycznym elementem jest opuszczenie piaskownicy Chromium poprzez wymuszenie starszego środowiska wykonawczego IE.

Zmiany w Edge obejmują usunięcie:

  • dedykowanego przycisku paska narzędzi „Otwórz w IE mode”,
  • pozycji w menu kontekstowym i w menu głównym,
    co zmniejsza powierzchnię nadużyć przez proste socjotechniczne „kliknij tutaj, by działało”. W praktyce IE mode uruchomisz teraz tylko przez Ustawienia → Default Browser oraz dopisanie danej domeny do IE mode pages list / firmowego Enterprise Site List.

Praktyczne konsekwencje / ryzyko

  • Ryzyko przejęcia stacji roboczej po wymuszeniu IE mode (RCE+EoP) — zwłaszcza tam, gdzie stacje użytkowników mogą same „przełączać” tryb dla dowolnych stron.
  • Obejście nowoczesnych mechanizmów Edge/Chromium (site isolation, nowocześniejsze mitigacje) przez cofnięcie się do modelu bezpieczeństwa IE.
  • Wpływ na user experience: zniknięcie przycisków/skrótów może chwilowo utrudnić pracę zespołom korzystającym ze starych aplikacji, dopóki admini nie skonfigurują list witryn.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów IT / SecOps

  1. Audyt użycia IE mode — sprawdź, które aplikacje naprawdę go wymagają; zinwentaryzuj domeny i dopisz tylko te niezbędne do Enterprise Site List (Intune/GPO).
  2. Wyłącz „Allow sites to be reloaded in Internet Explorer mode” dla użytkowników, jeśli nie ma krytycznej potrzeby; zezwolenia nadawaj wyłącznie przez polityki oraz centralną listę.
  3. Twarde filtrowanie: proxy/NGFW/DNS — blokuj nieautoryzowane domeny próbujące wymuszać IE mode; monitoruj wzorce „przełączenia” (np. nietypowe żądania MSHTML/Trident).
  4. Detekcja: alertuj na łańcuch zdarzeń Edge → IE mode → procesy potomne/LOLBins → eskalacja/EoP; koreluj z telemetrią EDR (uruchomienie iexplore.exe nie powinno występować, ale komponenty MSHTML/Chakra mogą być ładowane).
  5. Segmentacja i zasada najmniejszych uprawnień na stacjach z zależnościami legacy; rozważ VDA/VDI lub izolację aplikacji (App-V, Windows Sandbox, IE-dependent app w kontenerze) jako pomost migracyjny.
  6. Plan migracji: wyznacz deadliny na usunięcie zależności od ActiveX/BHO; przypominamy — IE 11 jest EoL od 15 czerwca 2022.

Dla użytkowników końcowych

  • Nie „klikaj w flyouty” sugerujące przeładowanie w IE mode, chyba że to zatwierdzona aplikacja firmowa z listy.
  • Zgłaszaj wszelkie prośby o relaunch w IE mode spoza znanych serwisów (może to być socjotechnika).
  • Aktualizuj Edge do najnowszej wersji i stosuj polityki firmowe.

Różnice / porównania z innymi przypadkami

W przeciwieństwie do dawnych kampanii wykorzystujących MSHTML (np. ataki na kontrolki ActiveX lub luki w renderowaniu dokumentów), obecny wektor nadużywał samego przejścia do IE mode w Edge, a następnie 0-day w Chakra. Microsoft zareagował zmianą UX/punktów wejścia (hardening funkcji), a nie publikacją konkretnego CVE, co jasno pokazuje, że czynnik użytkownika (łatwość przełączenia) był krytyczną częścią łańcucha.

Podsumowanie / kluczowe wnioski

  • IE mode to konieczne zło dla części organizacji — i dlatego musi być ściśle kontrolowany listami witryn i politykami.
  • Microsoft usunął szybkie przełączniki do IE mode; teraz wejście w tryb jest działaniem intencjonalnym i audytowalnym.
  • Priorytetem powinno być wyeliminowanie zależności legacy oraz zabezpieczenie ścieżek migracji; do tego czasu — maksymalnie ograniczaj miejsca, gdzie IE mode może się w ogóle uruchomić.

Źródła / bibliografia

  1. Microsoft Browser Vulnerability Research — Securing the Future: Changes to Internet Explorer Mode in Microsoft Edge (08.10.2025). (microsoftedge.github.io)
  2. Microsoft Learn — What is Internet Explorer (IE) mode? (ostatnia aktualizacja: 18.07.2024). (Microsoft Learn)
  3. The Hacker News — Microsoft Locks Down IE Mode After Hackers Turned Legacy Feature Into Backdoor (13.10.2025). (The Hacker News)
  4. Microsoft Lifecycle — Internet Explorer 11 desktop application ended support… (15.06.2022). (Microsoft Learn)
  5. Microsoft Support — Internet Explorer mode in Microsoft Edge (instrukcje użytkowe). (Microsoft Support)

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””

CVE-2025-11371: aktywnie wykorzystywana luka (0-day) w Gladinet CentreStack i Triofox — od LFI do RCE

Wprowadzenie do problemu / definicja luki

W produktach Gladinet CentreStack i Triofox wykryto podatność CVE-2025-11371, którą napastnicy aktywnie wykorzystują. Błąd to nieautoryzowany Local File Inclusion (LFI) w domyślnej instalacji i konfiguracji, umożliwiający zdalne odczytywanie plików systemowych bez logowania.

Czytaj dalej „CVE-2025-11371: aktywnie wykorzystywana luka (0-day) w Gladinet CentreStack i Triofox — od LFI do RCE”

Oracle publikuje Security Alert dla CVE-2025-61884 w E-Business Suite

Nieuwierzytelnione obejście dostępu w Oracle Configurator

Data publikacji alertu: 11 października 2025 r. (Rev. 1)
Produkty dotknięte: Oracle E-Business Suite 12.2.3–12.2.14 (komponent: Oracle Configurator – Runtime UI)
CVSS v3.1: 7.5 (High) – łatwo podatne, zdalnie wykorzystywane bez uwierzytelnienia przez HTTP; główny wpływ: poufność danych.

Czytaj dalej „Oracle publikuje Security Alert dla CVE-2025-61884 w E-Business Suite”