SonicWall офіційно повідомила, що несанкціонований доступ до хмарних резервних копій конфігурацій у порталі MySonicWall охопив усіх клієнтів, які користувалися відповідним сервісом бекапу. Розслідування проведено спільно з IR-командою Mandiant, ідентифіковано доступ до файлів конфігурацій у форматі .EXP, які зберігалися в хмарній інфраструктурі. Компанія заявляє, що доступ заблоковано та триває взаємодія з правоохоронними органами.
Масштаб інциденту та хронологія подій
У середині вересня 2025 року SonicWall попередила про атаку на облікові записи MySonicWall та рекомендувала термінову зміну облікових даних. Тоді йшлося, що хмарним бекапом користуються близько 5% клієнтів і «порушення стосуються окремих акаунтів». Оновлений бюлетень уточнює: доступ отримано до резервних конфігурацій усіх клієнтів, які застосовували хмарний сервіс. Це суттєво розширює попередню оцінку впливу на екосистему SonicWall.
Які дані могли бути скомпрометовані і чому це важливо
Резервні конфігурації файрволів відображають повну мережеву політику: об’єкти та зони, правила доступу, NAT, маршрутизацію, налаштування VPN, адміністративні облікові записи й інтеграції. SonicWall зазначає, що облікові та конфігураційні дані в бекапах захищені шифруванням AES‑256. Однак навіть метадані (топологія, підмережі, опубліковані сервіси, міжмережеві з’єднання) дають зловмисникам «карту мережі», знижуючи невизначеність під час планування таргетованих атак.
Ключові ризики для організацій
Наявність конфігурації спрощує пошук зовнішніх керівних інтерфейсів, підбір експлойтів під конкретні моделі та версії, прицільні атаки на VPN і міжсегментні з’єднання, а також підготовку правдоподібного фішингу з технічними деталями середовища. За спостереженнями галузевих звітів на кшталт Verizon DBIR, скомпрометовані облікові дані та «людський фактор» стабільно входять до топ-векторів порушень, а знання внутрішньої архітектури істотно підвищує шанси успішної експлуатації.
Як перевірити вплив і мінімізувати наслідки
Перевірка статусу в MySonicWall
Авторизуйтеся в MySonicWall і перейдіть до Product Management → Issue List. Якщо вказано пункти, що потребують дій, виконайте процедуру Essential Credential Reset, починаючи з активних файрволів з виходом в інтернет.
Негайна ротація секретів і посилення периметра
Рекомендується без зволікань: змінити паролі адміністраторів, видалити неактивні чи підозрілі облікові записи, увімкнути MFA для всіх доступів; перегенерувати VPN-секрети (PSK), сертифікати та приватні ключі, за потреби оновити довірені корені; оновити секрети інтеграцій (RADIUS/TACACS+/LDAP, API-ключі, SNMP community/USM); обмежити доступ до керівних інтерфейсів за IP/мережами, застосувати jump-host/VPN та заборонити управління з недовірених сегментів; встановити актуальні прошивки, перевірити журнали на нетипові входи, зміни політик та відновлення конфігурацій, увімкнути моніторинг і сповіщення в SIEM.
Стійкість у середньостроковій перспективі
Перегляньте політику резервного копіювання: сегрегація сховищ, принцип найменших привілеїв, роздільне управління ключами шифрування. За можливості зберігайте конфігурації у зашифрованому вигляді поза публічними хмарними контурами з незалежним KMS. Регулярно тестуйте план реагування на інциденти, автоматизуйте ротацію секретів і інвентаризацію експонованих сервісів, включно з перевірками управлінських портів та зовнішніх IP.
Інцидент із MySonicWall підкреслює критичність керування конфігураціями та секретами в хмарі: навіть за сильного шифрування витік конфігураційних даних збільшує поверхню атаки. Організаціям варто оперативно виконати ротацію ключових секретів, дотриматися рекомендацій SonicWall і Mandiant, посилити моніторинг і перевірити архітектурні припущення. Чим швидше будуть прийняті технічні та процесні заходи, тим нижчою буде ймовірність успішної експлуатації наслідків інциденту та наступних компрометацій.
