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: realizowane są 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ł, iż 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, iż 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 iż 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, iż 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ń: choćby jeżeli 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żeli 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), ale konsekwencje kompromitacji usługi kopii zapasowej i/lub wtórnego nadużycia poświadczeń — dlatego najważniejsze 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 / najważniejsze 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