Jeśli Twoja firma korzysta z zapory sieciowej SonicWall albo zlecasz obsługę IT dostawcy usług zarządzanych (MSP), który loguje się zdalnie, aby na bieżąco instalować poprawki i wykonywać kopie zapasowe systemów, masz w tym tygodniu dwa niezależne powody, by wykonać telefon. W obu przypadkach chodzi o luki, które atakujący wykorzystują właśnie teraz, a nie o teoretyczne zagrożenia opisane w biuletynie dostawcy, którego nikt nie czyta. W żadnym z tych przypadków nie musisz zostać ekspertem ds. bezpieczeństwa. Musisz zadać konkretne pytania i oczekiwać konkretnych odpowiedzi — dat, numerów wersji, potwierdzeń — a nie zapewnień.

Oto, co dzieje się w obu przypadkach, oraz lista kontrolna, którą możesz skopiować, wkleić i wysłać osobie zarządzającej Twoją siecią.

Problem 1: Twoja zapora SonicWall (CVE-2026-15409 i CVE-2026-15410)

SonicWall ujawnił informacje o dwóch lukach i udostępnił poprawki 14 lipca 2026 r. — jednak zgodnie z własną chronologią firmy atakujący wykorzystywali je już przez około trzy tygodnie przed publicznym ujawnieniem. Oznacza to, że w przypadku urządzenia wystawionego na internet w tym okresie „załatane teraz” i „bezpieczne teraz” nie są automatycznie tym samym.

Najczęściej wymienianym w związku z tym łańcuchem luk podmiotem zagrażającym jest INC, grupa oferująca ransomware jako usługę, którą badacze z Rapid7 opisują jako jedną z obecnie najbardziej aktywnych na świecie grup tego rodzaju (choć nie każdy atak wykorzystujący te luki został jednoznacznie przypisany konkretnie grupie INC — niemal na pewno zaangażowani są również inni atakujący oportunistyczni). Niezależnie od tego firma Huntress zajmująca się bezpieczeństwem poinformowała o szybko postępującej serii ataków, w której w ciągu niespełna dwóch dni zaatakowano 30 klientów SonicWall. To nie jest zagrożenie, które narasta powoli.

Istnieje tu również istotna historia: SonicWall wcześniej ujawnił incydent, podczas którego grupa sponsorowana przez państwo wykradła pliki konfiguracyjne zapór sieciowych od każdego klienta SonicWall korzystającego z funkcji tworzenia kopii zapasowych w chmurze. Skradziony plik konfiguracyjny może zawierać dane uwierzytelniające kont lokalnych i ustawienia VPN. Jeśli konfiguracja Twojej zapory została kiedykolwiek zarchiwizowana w usłudze chmurowej SonicWall przed opanowaniem tamtego incydentu, załatanie obecnych luk nie cofnie tego, co zostało już ujawnione — dane uwierzytelniające z tej konfiguracji mogą nadal wymagać zmiany.

Lista kontrolna do wysłania dostawcy usług IT lub MSP:

  • „Jaki model SonicWall i jaka wersja oprogramowania sprzętowego są obecnie używane oraz czy ta wersja usuwa luki CVE-2026-15409 i CVE-2026-15410?” (Poproś o potwierdzenie na podstawie własnego komunikatu bezpieczeństwa SonicWall — nie akceptuj odpowiedzi „mamy najnowszą wersję” bez podania numeru wersji).
  • „Kiedy zainstalowaliśmy poprawkę?” Jeśli nastąpiło to po 14 lipca 2026 r., poproś o sprawdzenie logów z kilku wcześniejszych tygodni pod kątem oznak nieautoryzowanego dostępu — nieoczekiwanych logowań administratorów, nowych kont lokalnych lub sesji SSLVPN z nieznanych adresów IP.
  • „Czy nasz portal SSLVPN lub portal zdalnego dostępu był w tym okresie wystawiony na internet?” Jeśli tak, poproś o wymuszenie resetu hasła dla każdego konta, które uwierzytelnia się za jego pośrednictwem, a nie tylko o zainstalowanie poprawki.
  • „Czy konfiguracja naszej zapory była kiedykolwiek archiwizowana w usłudze chmurowej SonicWall, a jeśli tak, czy dane uwierzytelniające zawarte w tym pliku konfiguracyjnym zostały od tego czasu zmienione?”
  • „Czy uwierzytelnianie wieloskładnikowe jest włączone dla wszystkich kont zdalnego dostępu przez zaporę?” Jeśli nie, poproś o włączenie go jeszcze w tym tygodniu.

Problem 2: Narzędzie zdalnego zarządzania Twojego MSP (CVE-2026-18577 w N-able N-central)

Ten przypadek jest inny, ponieważ nie chodzi o Twój sprzęt — chodzi o narzędzie, którego dostawca IT może używać do zarządzania dziesiątkami lub setkami firm klienckich, w tym być może Twoją, z jednej centralnej konsoli. N-able N-central to jedna z takich platform, a CISA (amerykańska Agencja ds. Cyberbezpieczeństwa i Bezpieczeństwa Infrastruktury) dodała lukę w tym produkcie — CVE-2026-18577, której poziom dotkliwości oceniono na 8,2 w skali 10 — do swojego katalogu znanych wykorzystywanych luk po potwierdzeniu aktywnego wykorzystywania od 31 lipca 2026 r. Luka ma podobno umożliwiać atakującemu uzyskanie pełnego dostępu administracyjnego do samej konsoli N-central.

Ma to znaczenie ze względu na to, co atakujący może stamtąd zrobić. Huntress poinformował, że udane ataki przenosiły się ze zainfekowanej konsoli do punktów końcowych zarządzanych za jej pośrednictwem — oznacza to, że naruszenie narzędzia MSP może stać się naruszeniem Twoich systemów, nawet jeśli atakujący nigdy nie zaatakował Cię bezpośrednio. Huntress wykrył również, że atakujący tworzyli tunele Cloudflare na zaatakowanych systemach — technikę zapewniającą im trwały, szyfrowany sposób ponownego dostępu, który dla zapory może wyglądać jak zwykły ruch internetowy.

Nie musisz wiedzieć, czy konkretny dostawca korzysta z N-central. Musisz zapytać — i zadać pytanie szerzej, nie ograniczając się tylko do nazwy tego jednego produktu.

Lista kontrolna do wysłania dostawcy usług IT lub MSP:

  • „Czy używacie N-able N-central lub innego produktu N-able do zarządzania naszymi systemami?” Jeśli tak: „Czy jest on zabezpieczony poprawką usuwającą CVE-2026-18577 i z jaką datą to potwierdzacie?”
  • „Czy od 31 lipca 2026 r. przeprowadziliście audyt aktywności kont administracyjnych i logów dostępu na konsoli zarządzania pod kątem czegokolwiek, czego nie potraficie wyjaśnić?”
  • „Czy sprawdziliście nasze systemy pod kątem nieoczekiwanych połączeń wychodzących — w szczególności procesów tuneli Cloudflare (czasami wyświetlanych jako „cloudflared”) lub domen tunelowych, których nie skonfigurowaliśmy?”
  • „Czy na naszych systemach pojawiły się nowe lokalne konta administratorów, zaplanowane zadania lub zasady zdalnego zarządzania, których nie możecie przypisać własnemu zespołowi?”
  • „Jeśli nie używacie N-central, jakiego narzędzia zdalnego zarządzania używacie zamiast niego i czy w ostatnim czasie nie dodano luk w tym narzędziu do katalogu znanych wykorzystywanych luk CISA?”

Co zrobić z odpowiedziami

Dobry dostawca IT odpowie na te pytania, podając daty i szczegóły, często w ciągu jednego dnia, ponieważ powinien już znać te informacje albo móc szybko wyciągnąć je z logów. Wymijająca odpowiedź — „panujemy nad sytuacją”, „nasze systemy są bezpieczne”, bez podania dat — sama w sobie jest cenną informacją: mówi Ci, że tę rozmowę trzeba powtórzyć, na piśmie, z wyznaczonym terminem.

Jeśli samodzielnie zarządzasz SonicWall bez MSP, powyższa lista kontrolna nadal ma zastosowanie — zaloguj się do konsoli zarządzania, samodzielnie sprawdź wersję oprogramowania sprzętowego i sprawdź stronę z komunikatami bezpieczeństwa SonicWall, aby znaleźć wersję usuwającą obie luki CVE.

Żadna z tych wad nie wymaga odłączania dostawcy ani zwalniania usługodawcy. Wymagają one potwierdzenia, że konkretna luka została zamknięta i że nic nie przedostało się przez nią, gdy pozostawała otwarta. Zadaj pytania, zdobądź daty i ustaw w kalendarzu przypomnienie, by zapytać ponownie, gdy następnym razem dostawca ujawni, że coś jest „aktywnie wykorzystywane”. To się powtórzy.