Пятница, 18:00: сотрудники одной достаточно крупной компании спокойно заканчивают работу. Понедельник, 08:00: все рабочие компьютеры показывают экран восстановления BitLocker, контроллер домена скомпрометирован, а ключи у злоумышленника. Между этими точками четыре шага, и ни один из них не был сложным.
Ни одна из уязвимостей не была чем-то необычным. Вы почти наверняка видели каждую из них в какой-нибудь инфраструктуре. Но здесь они сложились в цепочку, и никто не заметил, пока она не отработала до конца.
Меня зовут Виктор Иевлев, я руковожу отделом информационной безопасности в компании «Гарда». Сегодня вместе с вами буду расследовать этот инцидент и делиться мыслями о том, как компании можно было избежать печального финала.
Всё началось с MikroTik
На границе сети стоял MikroTik. Админку оставили открытой в интернет, чтобы можно было зайти снаружи без VPN. Удобно, спору нет, но только пока кто-то посторонний не заинтересуется этим устройством.
Злоумышленник проэксплуатировал уязвимость CVE-2024-54772 в RouterOS. Важно тут даже не конкретная CVE, а сам факт: наружу торчал интерфейс управления устройством на границе сети. Это значит, что рано или поздно подходящая уязвимость обязательно бы нашлась.
После эксплуатации атакующий получил контроль над роутером и превратил его в точку опоры внутри периметра. Через роутер он поднял туннель, и дальнейший трафик пошёл уже как будто изнутри. Для внутренних узлов источник выглядел «своим». Злоумышленник виртуально сел внутри офиса и начал разведку.
Внутри сети ему никто не мешал
Атакующий прошёлся по сети с помощью nmap и быстро собрал базовую карту: какие хосты активны, и какие сервисы отвечают. Почти сразу он нашёл удобную цель — Linux-сервер с открытым SSH.
В корпоративных инфраструктурах основное внимание почти всегда съедает Windows: домен, политики, терминалки, Exchange, файловые серверы, а Linux-хосты остаются без внимания. Именно на них часто стоят старые версии ПО и отсутствует нормальный EDR.
Здесь всё оказалось совсем грустно: у root был слабый пароль без защиты от перебора. Так злоумышленник и получил полноценный внутренний хост, с которого можно работать дальше тихо и без шума.
Если бы на сервере был антивирус, то теоретически он мог бы что-нибудь заметить.
Злоумышленник занёс Impacket на Linux, а Impacket — набор вполне легитимных Python-инструментов для работы с SMB, NTLM, Kerberos и другими протоколами Windows. Для сигнатурного антивируса они выглядят как обычные скрипты. Контекст он не понимает, файл как файл.
Основная проблема в AD CS
Дальше атака перешла в самую интересную фазу — к инфраструктуре сертификации Microsoft. Во многих компаниях используется AD CS — центр сертификации, который выдаёт цифровые сертификаты пользователям, серверам, сервисам, иногда контроллерам домена. Очень часто он настроен по принципу «когда-то подняли, вроде работает, трогать страшно».
В таких конфигурациях есть одна особенно неприятная штука — Web Enrollment. Это веб-интерфейс для запроса сертификатов из браузера. Сам по себе он не зло. Проблема в том, что в реальных инфраструктурах не все умеют его правильно настраивать: часто оставляют включённым без ограничений и без ручного подтверждения выпуска.
Механика эксплуатации уязвимости такая. Злоумышленник, уже сидя на внутреннем Linux-хосте, запускает ntlmrelayx.py из Impacket и готовится ловить NTLM-аутентификацию. Потом провоцирует контроллер домена аутентифицироваться на свой хост.
Контроллер домена отправляет свой NTLM challenge-response, но злоумышленник этот ответ не ломает и не подбирает. Он делает хуже: мгновенно пересылает его на Web Enrollment центра сертификации. А тот смотрит на запрос и говорит: «О, это же контроллер домена. Заходи» — и выдаёт сертификат на машинную учётную запись контроллера, условный DomainControllerName$.
Почему так произошло? Опция CA certificate manager approval не была активирована. Без неё CA штампует сертификат автоматически. Для атакующего — идеальный сценарий: никаких ручных действий администратора, никакой точки, где его могли бы остановить.
После сертификата домен был уже почти потерян
Как только у злоумышленника на руках оказывается сертификат контроллера домена, дальше начинается почти легитимная работа от имени доверенного узла. Следующий шаг — DCSync.
Смысл DCSync в том, что атакующий имитирует нормальное поведение контроллера домена, который просит у другого контроллера данные репликации. Active Directory считает, что перед ним свой, и отдаёт хэши учётных записей, включая привилегированные.
После этого вопрос «а есть ли у злоумышленника доменный админ?» отпал.
И дальше — финальный, самый обидный этап. Никаких зрелищных шифровальщиков, никаких экзотических malware-фреймворков. Имея права доменного администратора, атакующий использует обычный штатный механизм — Group Policy Object. Через GPO по сети распространяется команда на шифрование средствами BitLocker.
Утром сотрудники включают компьютеры и машины легитимно, по доменной политике, начинают шифровать себя. На этом этапе остаются только последствия.
Почему угрозу не заметили раньше
Потому что замечать было нечем. Сеть была плоской — попав внутрь, злоумышленник не упёрся ни в один внятный сегмент. East-West трафик никто не контролировал, внутренний nmap прошёл как фоновый шум. Linux-хост с простым паролем жил отдельной тихой жизнью — не ключевой узел, а забытый сервис. Антивирус стоял, но реагировать на происходящее не умел. Deception-ловушек не было, NDR не было, правил на аномальное движение внутри сети тоже не было.
Тут дело не в одном пропущенном алерте. Это театр безопасности: какие-то средства вроде бы есть, а злонамеренную активность они не останавливают и даже толком не видят.
Что было корневой причиной потери домена
Свалить всё на один Web Enrollment и успокоиться — соблазнительно, но неправильно. Да, AD CS сыграл ключевую роль в кульминации. Но компрометация стала возможной, потому что совпало сразу несколько грубых нарушений.
Периметр. Наружу торчал интерфейс управления MikroTik, уязвимость не была закрыта вовремя.
Внутренняя гигиена. Linux-сервер с простым root-паролем, плоская сеть без сегментации, файрвол не ограничивал доступ к критичным портам (22, 135, 139, 445, 3389, 5985, 5986) по белым спискам, PKI настроена без жёстких ограничений, NTLM жил слишком вольготно.
Мониторинг практически отсутствовал.
Классический эффект швейцарского сыра: каждая отдельная дырка неприятна, но не смертельна. Когда они выстраиваются в линию — вы теряете домен за выходные.
Где можно было остановить атаку
Каждый шаг этой цепочки был предотвратим. Не теоретически, а конкретной мерой, которую можно было внедрить до атаки.
Шаг атаки | Что было не так | Как можно защитить |
Вход через MikroTik | Админка открыта в интернет, прошивка с известной уязвимостью | VPN или jump-host для управления, патч-менеджмент на периметре |
Разведка и перемещение по сети | Плоская сеть, east-west трафик без контроля | Сегментация, ACL на критичные порты (22, 135, 445, 3389, 5985) по белым спискам |
Захват Linux-хоста | Простой root-пароль, нет защиты от перебора, нет EDR | Парольная политика, fail2ban/аналог, EDR на всех хостах, включая «вспомогательные» |
NTLM Relay на AD CS (ESC8) | Web Enrollment без ограничений, автовыпуск сертификатов, NTLM разрешён на CA | Отключить Web Enrollment или включить CA manager approval, Deny All на NTLM, мониторинг 4624 на CA |
DCSync и GPO | Следствие предыдущих шагов — к этому моменту уже поздно | — |
Последняя строка намеренно пустая. Если атака дошла до DCSync, технических мер уже нет. Остаётся восстановление из бэкапов и разбор последствий.
Несколько пояснений к таблице, потому что дьявол именно в деталях.
Начнём с AD CS. Машинные учётные записи домена запрашивают сертификаты по RPC, веб-интерфейс им в принципе не нужен. Но если Web Enrollment всё же используется, без включённой опции CA certificate manager approval, центр сертификации штампует сертификаты автоматически. Поэтому ESC8 и смогла отработать без единого ручного действия администратора.
С NTLM история похожая по духу: одна настройка могла бы закрыть всю механику. Политика «Network security: Restrict NTLM: Incoming NTLM traffic» в значении Deny All Accounts убирает саму возможность relay-атаки — атакующему нечего перехватывать и некуда пересылать.
Отдельно стоит сказать про мониторинг. Event ID 4624 на центре сертификации — не самое очевидное место для алертов, но именно там появился бы первый след. Когда машинная учётная запись аутентифицируется нетипичным способом — это уже повод разбираться.
Про Linux-хосты и говорить неловко: простой пароль у root в 2026 году — не технический долг, а открытая дверь. Парольная политика, fail2ban, обновления, EDR — базовый минимум, который регулярно отсутствует на «вспомогательных» серверах, до которых у всех не доходят руки.
И наконец, сегментация. Если бы SSH на тот Linux-хост был открыт только с конкретных админских узлов, злоумышленник с захваченного роутера туда бы не дошёл и весь дальнейший сценарий просто не случился.
Большинство перечисленных мер не требуют коммерческих продуктов. Так, IDPS на базе snort и Suricata на периметре подсветила бы туннель. Кстати, их можно установить, как модули на фаервол OPNsense или pfSense CE (Community Edition).
В качестве SIEM или XDR со встроенным модулем EDR можно было бы посмотреть в сторону Wazuh. Установленный на Linux-хосте, он сразу указал бы ИБ на перебор SSH и появление Impacket, а настроенные правила в SIEM — на нетипичную аутентификацию на CA.
Но Open Source не значит «само заработает»: без инженера, который понимает, что он ловит, это ещё один слой театра безопасности.
К сожалению, открытые админки, забытые Linux-хосты, PKI (Public Key Infrastructure) на дефолтах, плоская сеть встречаются где угодно. Вопрос не в том, возможна ли такая цепочка у вас. Вопрос в том, в какой строке этой таблицы вы её прервёте.
