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”:
- 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.
- 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).
- 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ń.
- Włącz/Mandatuj MFA dla wszystkich kont administracyjnych i zdalnych; zrewiduj role i zasady najmniejszych uprawnień.
- Zwiększ logowanie i retencję: przeanalizuj nietypowe logowania, zmiany konfiguracji, zestawienia tuneli; zachowaj logi do analizy powłamaniowej.
- Stopniowo przywracaj usługi po rotacji haseł, monitorując, czy nie powracają nieautoryzowane logowania.
- 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
- SecurityWeek — SonicWall SSL VPN Accounts in Attacker Crosshairs, 13 paź 2025. SecurityWeek
- Huntress — Threat Advisory: Widespread SonicWall SSLVPN Compromise, 10 paź 2025. Huntress
- SonicWall — MySonicWall Cloud Backup File Incident (aktualizacja 8 paź 2025). SonicWall
- CISA — SonicWall releases advisory… (22 wrz 2025). CISA
- SecurityWeek — All SonicWall Cloud Backup Users Had Firewall Configurations Stolen, 9 paź 2025. SecurityWeek
