BlueKeep в Metasploit: провели финальный скан и закрыли историю для заказчиков

BlueKeep дожил до Metasploit. Публичный модуль появился в репозитории Framework - это означает, что для атаки на уязвимый Windows Server 2008 или Windows 7 с открытым RDP теперь достаточно знать, как набрать use exploit/windows/rdp/cve_2019_0708_bluekeep_rce в консоли. Квалификация атакующего только что упала на несколько порядков.

Для нас это был сигнал: время закрывать историю.

Что изменилось с появлением Metasploit-модуля

До этого момента рабочий эксплойт для BlueKeep существовал в виде лабораторных прототипов у исследователей безопасности. Опубликованные технические детали были подробными, но путь от «понимаю механику» до «запускаю атаку» требовал реальной квалификации. Это не значило, что угрозы нет - это значило, что массовая автоматизированная эксплуатация была сложнее.

С Metasploit ситуация другая. Модуль в Framework - это готовый инструмент с документацией, опциями и поддерживаемой кодовой базой. Сканеры уязвимостей давно умеют детектировать незакрытый BlueKeep - теперь за детектом сразу идёт эксплуатация в несколько команд. Порог для скриптовой атаки по диапазону адресов опустился до минимума.

CVSS 9.8 эта цифра не изменила. Но практический риск стал существенно реальнее.

Финальный скан

Мы отработали BlueKeep в три волны, начиная с апреля: сначала аудит периметра и выявление уязвимых хостов, потом экстренный патчинг, потом ретроспектива с анализом состояния реестров и WSUS. Появление Metasploit-модуля стало поводом сделать четвёртый, финальный проход - уже с конкретной целью: убедиться, что ни один из ранее найденных хостов не остался открытым.

Сканировали по спискам, которые сформировали ещё в апреле. Несколько заказчиков за три месяца успели что-то изменить в инфраструктуре - добавить хосты, переконфигурировать сети. Там проходили повторно с нуля.

Картина по итогу финального скана:

• Все ранее выявленные хосты с открытым 3389/tcp и отсутствующим патчем закрыты или изолированы. Ни одного уязвимого хоста в выборке, которую мы отработали с апреля, не осталось в прежнем состоянии.
• Несколько хостов исчезли с периметра не через патчинг, а через изоляцию - либо закрыли порт на firewall, либо машины перестали быть доступны извне по другим причинам. Это тоже результат, пусть и менее чистый.
• Один хост вернулся в видимость - оказалось, что в ходе технических работ на сети правило было временно открыто и не закрыто обратно. Поймали, закрыли, зафиксировали.

Новых уязвимых хостов по сравнению с апрельским срезом не появилось - это, пожалуй, главный результат. Инфраструктура не расширилась в сторону RDP без патчей.

Журнал работ заказчикам

Параллельно со сканом подготовили и передали журнал работ по BlueKeep для каждого заказчика, у которого проводили митигацию. Документ несложный: что нашли в апреле, что сделали, что проверили сейчас, текущий статус каждого хоста из исходного списка.

Зачем это нужно - вопрос практический. Часть заказчиков работает в регулируемых отраслях, где реакция на критические уязвимости должна быть задокументирована. Часть просто хочет иметь подтверждение, что работа сделана - не устную договорённость, а файл с датами и результатами. Третьи используют это для внутренних ИБ-отчётов.

Конкретный формат журнала работ здесь менее важен, чем сам факт его существования. Когда через полгода кто-нибудь спросит «а мы точно закрыли BlueKeep?» - ответ есть, и он с деталями.

Это часть того, что делает аудит безопасности чем-то большим, чем разовое сканирование: не просто «запустили nmap и ушли», а трекинг состояния от выявления до закрытия с документированием каждого шага.

Что дальше

BlueKeep как активная история для нас закрыта - в том смысле, что выявленное отработано и проверено. Это не значит, что уязвимость перестала существовать в мировой инфраструктуре: счётчики незакрытых хостов в интернете всё ещё показывают десятки тысяч машин с открытым RDP на уязвимых версиях Windows. Это уже не наши хосты - но они существуют, и Metasploit-модуль для них теперь общедоступен.

Внутри периметра заказчиков, с которыми работаем, история другая. Финальный скан это подтвердил.

Следующий критический CVE в Windows-компонентах - не вопрос «если», а вопрос «когда». Методика, которую отработали на BlueKeep - быстрый аудит периметра, приоритизация по NLA и версии ОС, экстренный патчинг с документированием - теперь есть как готовый процесс, а не как что-то, что нужно придумывать под давлением.