Риск не сводится к «непропатченному VPN»#
Злоумышленники, по данным исследователей, обходили многофакторную аутентификацию на SonicWall Gen6 SSL-VPN даже после того, как организации установили обновления прошивки, но не выполнили обязательные ручные шаги по исправлению конфигурации.
BleepingComputer со ссылкой на исследование ReliaQuest и бюллетень SonicWall по CVE-2024-12802 пишет, что атакующие подбирали учетные данные VPN, а затем проходили аутентификацию способом, при котором MFA не применялась. Активность наблюдали в нескольких инцидентах с февраля по март. ReliaQuest с умеренной уверенностью оценила эти случаи как первую эксплуатацию CVE-2024-12802 in-the-wild сразу в нескольких средах.
Ключевая деталь здесь операционная. В средах, которые изучала ReliaQuest, устройства SonicWall выглядели исправленными: на них стояла обновленная прошивка. Но для Gen6 одного обновления прошивки недостаточно, чтобы полностью убрать риск. SonicWall указывает, что администраторам нужно вручную изменить настройки LDAP. Если этот шаг пропустить, возможность обхода MFA может остаться.
Это типичный сбой, который красиво выглядит в отчете о патчах, но плохо заканчивается в реальном инциденте.
Что на практике меняет CVE-2024-12802#
CVE-2024-12802 связана с отсутствием принудительного применения MFA для входа в формате UPN. Проще говоря, злоумышленник с действительными учетными данными может пройти аутентификацию напрямую, не вызвав ожидаемую проверку MFA.
Это особенно опасно для VPN-аккаунтов, потому что они часто подвергаются атакам на учетные данные. Повторное использование паролей, слабые пароли, ранее украденные учетные данные и brute-force становятся намного опаснее, если MFA можно обойти через конкретный путь входа.
ReliaQuest сообщила, что расследованные вторжения шли по быстрому, но контролируемому сценарию. В отдельных случаях атакующему хватало 30–60 минут, чтобы войти, провести разведку сети, проверить повторное использование учетных данных на внутренних системах и выйти. В одном инциденте злоумышленник примерно за полчаса добрался до файлового сервера в домене, а затем установил RDP-соединение, используя общий пароль локального администратора.
Исследователи также видели попытки развернуть инструменты, характерные для ransomware-инцидентов. Среди них были Cobalt Strike beacon для command-and-control и уязвимый драйвер, вероятно предназначенный для техники Bring Your Own Vulnerable Driver, чтобы мешать работе защиты конечных точек. В описанном случае EDR заблокировал и beacon, и загрузку драйвера.
Это не доказывает, что каждое связанное вторжение дошло до развертывания ransomware. Но показывает, почему обход MFA в VPN нужно считать риском первичного доступа, а не узкой ошибкой аутентификации.
Где возникает разрыв в исправлении Gen6#
Сценарий исправления зависит от поколения SonicWall.
Для устройств Gen7 и Gen8, по данным BleepingComputer, достаточно обновиться до новой версии прошивки, чтобы устранить риск эксплуатации CVE-2024-12802.
Для Gen6 обновление прошивки — только часть исправления. Бюллетень SonicWall требует обновить прошивку, а затем выполнить шаги по исправлению LDAP. По исходным материалам, эти шаги включают:
- Удалить существующую конфигурацию LDAP, где userPrincipalName используется в поле “Qualified login name”.
- Удалить локально кэшированных или перечисленных LDAP-пользователей.
- Удалить настроенный SSL VPN “User Domain”, чтобы он вернулся к LocalDomain.
- Создать конфигурацию LDAP заново, без userPrincipalName в поле “Qualified login name”.
- Создать свежую резервную копию, чтобы уязвимая LDAP-конфигурация не была восстановлена позже.
Последний пункт легко пропустить. Устройство можно исправить, а затем снова сделать уязвимым, если старая резервная копия вернет прежнюю LDAP-конфигурацию.
Есть и проблема жизненного цикла. По данным отчета, Gen6 SSL-VPN appliances достигли end of life 16 апреля этого года. Инфраструктура удаленного доступа с истекшей поддержкой — плохое место для неустраненных пограничных случаев аутентификации. Даже если ручное смягчение риска доступно, переход на поддерживаемое оборудование стоит считать более чистой долгосрочной мерой.
Почему защитники могут это не заметить#
ReliaQuest отметила проблему с логированием, которая делает ситуацию опаснее. В расследованных инцидентах вредоносные попытки входа все равно отображались в журналах как обычный MFA-поток. Из-за этого защитники могли решить, что MFA сработала, хотя этого не произошло.
Главный урок шире. Команды безопасности часто проверяют, что контроль включен, но не проверяют, что он корректно применился для каждого пути аутентификации. Панель с надписью «MFA включена» не отвечает на главный вопрос: этот конкретный вход действительно потребовал MFA и успешно ее прошел?
ReliaQuest указала несколько сигналов, которые администраторы могут проверить. Один из ключевых индикаторов — sess="CLI", он может указывать на скриптовую или автоматизированную аутентификацию VPN. Другие сильные сигналы: event IDs 238 и 1080, а также входы в VPN из подозрительной VPS- или VPN-инфраструктуры.
Ни один из этих индикаторов сам по себе не стоит считать доказательством. Но они дают защитникам практичный маршрут для поиска, особенно там, где SonicWall Gen6 SSL-VPN обновили без подтвержденной перенастройки LDAP.
Что проверить сейчас#
Организациям, использующим SonicWall SSL-VPN, сначала нужно определить поколение устройства и состояние прошивки. Действия зависят от того, используется Gen6, Gen7 или Gen8.
Для сред Gen6 не останавливайтесь на отметке «установлена последняя прошивка». Проверьте, что LDAP-конфигурация изменена по бюллетеню SonicWall. Также проверьте, могут ли резервные копии, созданные до исправления, восстановить уязвимую конфигурацию.
Командам безопасности стоит пересмотреть VPN-журналы на предмет необычных потоков входа и инфраструктурных паттернов. Ищите:
sess="CLI"в релевантных журналах аутентификации VPN.- Event IDs 238 и 1080.
- Успешные входы в VPN из необычной VPS-инфраструктуры, proxy или инфраструктуры VPN-провайдеров.
- Входы с разных аккаунтов из похожей исходной инфраструктуры.
- Последующую RDP-активность, особенно с использованием общих учетных данных локального администратора.
- Попытки подготовить Cobalt Strike, уязвимые драйверы или другие инструменты постэксплуатации.
Гигиена учетных данных здесь важна. В описанных вторжениях фигурировали brute-force учетных данных и проверка повторного использования паролей. Если есть признаки подозрительного VPN-доступа, сброс паролей не должен ограничиваться одним аккаунтом, с которого был выполнен вход. Проверьте соседние учетные записи, привилегированных пользователей, общие пароли локального администратора и все системы, к которым обращались после VPN-доступа.
Защита конечных точек тоже важна, но это не первая линия обороны. В инциденте, описанном ReliaQuest, EDR заблокировал попытку запуска Cobalt Strike beacon и загрузку уязвимого драйвера. Это полезный страховочный слой. Но это не повод терпеть точку входа в VPN, где MFA можно обойти.
Чего не стоит утверждать сверх фактов#
Исходные материалы не доказывают, что сейчас эксплуатируется каждое устройство SonicWall Gen6. Они также не доказывают, что каждое наблюдавшееся вторжение привело к развертыванию ransomware.
ReliaQuest с умеренной уверенностью оценила расследованную активность как первую эксплуатацию CVE-2024-12802 in-the-wild. Исследователи также считают, что злоумышленник может быть initial access broker — на это указывает поведение вроде намеренных выходов из системы и последующих входов под другими учетными записями. Это оценка, а не судебно установленный факт и не точная атрибуция.
BleepingComputer также упоминает прежнюю активность Akira ransomware против SonicWall SSL VPN, где входы происходили несмотря на включенную MFA, но метод не был подтвержден. Эту деталь стоит воспринимать как контекст риска, а не как доказательство использования той же техники.
Надежный вывод уже достаточно серьезен: для SonicWall Gen6 SSL-VPN одно обновление прошивки может оставить возможность обхода MFA, если не выполнено исправление LDAP. Защитникам нужно проверять состояние конфигурации, а не только статус патча.