Уязвимость SonicWall VPN оказалась неприятнее, чем выглядела на бумаге: хакеры обходили MFA на устройствах Gen6 SSL-VPN даже после установки обновления прошивки. На практике это означало, что администратор мог честно поставить патч, закрыть тикет и все равно оставить дыру, через которую злоумышленник за 30–60 минут заходил в сеть, проверял повторное использование паролей и готовил площадку под вымогателей.
О такой схеме, как пишет BleepingComputer, рассказали исследователи ReliaQuest, которые с февраля по март 2026 года реагировали на несколько инцидентов в разных средах. По их оценке, это, вероятно, первое зафиксированное использование в реальных атаках уязвимости CVE-2024-12802. Проблема затрагивает SonicWall Gen6 SSL-VPN: одной только новой прошивки там недостаточно, потому что для полного закрытия риска нужна еще ручная перенастройка LDAP.
Сама уязвимость связана с тем, что на уровне проверки входа не принудительно применялась MFA-защита для формата логина UPN. Иными словами, если у атакующего уже есть валидные учетные данные, он может аутентифицироваться так, чтобы обойти второй фактор. В наблюдавшихся атаках, по данным ReliaQuest, злоумышленники сначала перебирали VPN-учетки, а затем использовали этот механизм для входа внутрь. Дальше все шло по знакомому сценарию: разведка, проверка повторного использования учетных данных на внутренних системах и аккуратный выход из сети, чтобы вернуться позже.
Один из эпизодов особенно показателен. Исследователи зафиксировали, что атакующий менее чем за полчаса добрался до внутренней сети и вышел на файловый сервер, присоединенный к домену. После этого он поднял RDP-сессию, используя общий пароль локального администратора. Это уже не «шум на периметре», а вполне рабочий доступ внутрь инфраструктуры. Дальше злоумышленник попытался развернуть Cobalt Strike Beacon для командного управления и уязвимый драйвер, вероятно, чтобы отключить защитные средства по схеме BYOVD — Bring Your Own Vulnerable Driver. В этом конкретном случае сработало EDR: и beacon, и загрузка драйвера были заблокированы.
Почему патч не спас
Самая неприятная часть истории не в баге как таковом, а в том, как легко его было недозакрыть. SonicWall отдельно предупредила: на Gen6 после обновления нужно вручную убрать старую LDAP-конфигурацию, где в поле Qualified login name использовался userPrincipalName, очистить локально закэшированных или перечисленных LDAP-пользователей, удалить настроенный SSL VPN User Domain, перезагрузить межсетевой экран, заново создать LDAP-конфигурацию уже без userPrincipalName и затем сделать свежий бэкап. Если эти шаги не выполнены, устройство может оставаться уязвимым для обхода MFA.
Именно это, судя по наблюдениям ReliaQuest, и произошло в ряде атакованных компаний. Устройства выглядели обновленными: они работали на новой версии прошивки. Но по сути защита не была доведена до конца. Для ИБ-команд это знакомый и довольно дорогой сценарий: патч-менеджмент формально закрыт, а реальная поверхность атаки — нет. В корпоративной жизни такие истории потом обычно оформляются в виде двух неприятных вопросов. Первый: кто проверял не только версию ПО, но и постпатчевые действия? Второй: есть ли вообще процесс валидации, что средство защиты после обновления работает так, как задумано.
На Gen7 и Gen8, по данным SonicWall, ситуация проще: там достаточно обновить прошивку, и риск эксплуатации CVE-2024-12802 снимается без дополнительной ручной хирургии. Но именно Gen6 сейчас выглядит самым неудобным наследием. Эти устройства достигли статуса end-of-life 16 апреля 2026 года и больше не получают обновления безопасности. Если компания все еще держит их в проде, то она уже играет в классическую корпоративную игру «еще один квартал протянем», только ставка здесь — периметр.
Что видно защитникам и что это значит для бизнеса
Отдельный сюрприз для SOC-команд: вредоносные входы в расследованных случаях выглядели в логах как нормальный MFA-процесс. То есть следы были, но они создавали ощущение, что второй фактор сработал корректно. Именно из-за этого такие атаки опасны не только уязвимостью, но и качеством ложного успокоения. ReliaQuest советует искать признак sess="CLI", который указывает на скриптованный или автоматизированный VPN-вход. Также стоит обратить внимание на события с идентификаторами 238 и 1080 и на подключения с подозрительной VPS- или VPN-инфраструктуры.
По поведению атакующего исследователи предполагают, что за частью эпизодов стоит не финальный оператор шифровальщика, а брокер начального доступа. Логика простая: злоумышленник входил, осматривался, выходил, а через несколько дней возвращался, иногда уже под другой учетной записью. Такой стиль больше похож на подготовку «товара к продаже», чем на немедленный запуск вымогателя. Для бизнеса это плохая новость сразу в двух смыслах. Во-первых, окно между первым компромиссом и ударом по инфраструктуре может быть длиннее, чем кажется. Во-вторых, факт «ничего не зашифровали» в первые сутки не означает, что инцидент был неопасным.
Есть и более широкий контекст. В 2025 году группа Akira уже атаковала SonicWall SSL VPN и входила в системы даже при включенной MFA, хотя тогда точный механизм подтвержден не был. Новые данные складывают картину: пограничные устройства и средства удаленного доступа по-прежнему остаются одним из самых удобных входов для атакующих, особенно если в инфраструктуре живут устаревшие модели, общий пароль локального администратора и уверенность, что «патч поставили, значит все хорошо». Для разработчиков и продуктовых команд это косвенный, но важный сигнал: безопасность удаленного доступа давно перестала быть задачей только сетевых админов. Если через VPN можно быстро дойти до файлового сервера и начать двигаться дальше, то вопрос уже не в одном баге, а в сегментации сети, управлении учетными записями и качестве детекта на конечных точках.
История с CVE-2024-12802 хорошо показывает старую проблему в новом исполнении: между «обновлено» и «защищено» нередко лежит еще несколько ручных шагов, которые никто не любит, но именно они отделяют обычный change request от входа вымогателей в инфраструктуру. И чем дольше компании держат на периметре устройства с истекшей поддержкой, тем чаще такие «полупатчи» будут превращаться из технической оговорки в вполне коммерческий риск.