Пятница, 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 жил слишком вольготно.

Мониторинг практически отсутствовал.

Классический эффект швейцарского сыра: каждая отдельная дырка неприятна, но не смертельна. Когда они выстраиваются в линию — вы теряете домен за выходные.

Где можно было остановить атаку

Каждый шаг этой цепочки был предотвратим. Не теоретически, а конкретной мерой, которую можно было внедрить до атаки.

Последняя строка намеренно пустая. Если атака дошла до 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) на дефолтах, плоская сеть встречаются где угодно. Вопрос не в том, возможна ли такая цепочка у вас. Вопрос в том, в какой строке этой таблицы вы её прервёте.

Гарда

t.me/garda_ai — создаем решения для защиты корпоративных данных и сетевой безопасности