Microsoft Tier Model: административные рабочие станции как ответ на Mimikatz-вектор NotPetya

NotPetya наглядно показал, как выглядит lateral movement в реальной корпоративной сети. Первый хост заражён через MeDoc, Mimikatz извлекает хеши из LSASS - и дальше по сети идёт не эксплойт, а легитимный PsExec с валидными доменными кредами. SIEM это не отличит от нормального администрирования, IDS не заметит ничего подозрительного.

Когда разбор механики NotPetya стал понятен, мы вернулись к документу, который Microsoft опубликовал ещё в 2014-2015 годах и который большинство читало по диагонали: Privileged Access Workstation и Tiered Administration Model для Active Directory. В нынешнем контексте это уже не академическая рекомендация из best practices - это описание конкретной контрмеры против конкретного вектора атаки.

Что такое Tier Model и зачем она нужна

Модель делит инфраструктуру на три уровня изоляции.

Tier 0 - сам Active Directory: контроллеры домена, служебные учётные записи с правами на AD, системы управления PKI и IdM. Администраторы Tier 0 - самые привилегированные учётки в среде.

Tier 1 - серверы и приложения: файловые серверы, серверы баз данных, почтовые серверы, серверы приложений. Администраторы этого уровня имеют права на конкретные серверы, но не на домен целиком.

Tier 2 - рабочие станции и устройства конечных пользователей: ноутбуки, десктопы, принтеры, мобильные устройства. Helpdesk и tier-2 поддержка работают именно здесь.

Ключевое правило модели: учётные записи вышестоящего уровня не должны интерактивно логиниться на объекты нижестоящего уровня. Domain Admin не логинится на рабочую станцию пользователя. Никогда. Не потому что так написано в политике, а потому что это технически запрещено через GPO.

Именно это правило ломает механику Mimikatz. Если domain admin ни разу не логинился на хост - в LSASS нет его кешированных кредов, и Mimikatz там ничего не найдёт.

Privileged Access Workstation

Параллельно с тиринговой моделью идёт концепция PAW - выделенных рабочих станций для привилегированных операций. Логика простая: доменный администратор выполняет привилегированные задачи только с выделенного хоста, на котором нет браузера, почты и прочего вектора первичного заражения. Этот хост не ходит в интернет, не получает произвольные GPO с доменом нижнего уровня, управляется по отдельным политикам.

Это кажется избыточным до тех пор, пока не видишь, как работает NotPetya. После 27 июня разговор с клиентами об отдельной машине для доменного администрирования стал заметно короче.

Как мы это внедряем

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

Первое - инвентаризация текущей картины логинов. Прежде чем запрещать, нужно понять, что реально происходит сейчас. Выгрузка событий 4624/4648/4672 из Security Event Log даёт полную картину: какие учётки с какими привилегиями куда логинятся. В типичной среде это выглядит предсказуемо неприятно: доменные администраторы логинятся на рядовые рабочие станции для устранения проблем, на серверы приложений - по привычке со своим основным аккаунтом. Иногда domain admin используется как сервисная учётка для запуска scheduled tasks. Всё это нужно зафиксировать до того, как начать что-то менять.

Второе - GPO-запрет интерактивного логина. Настраиваем через User Rights Assignment: "Deny log on locally" и "Deny log on through Remote Desktop Services" для domain admin групп применяются на всех объектах, кроме контроллеров домена и выделенных PAW. Это делается в несколько этапов - сначала audit mode через логирование, потом применение на непродуктивные OU, потом на всё. Поспешить здесь легко, но восстанавливать сломанные сервисные учётки потом долго.

Третье - отдельные учётки для каждого уровня. Один человек-администратор получает три учётки: обычную пользовательскую для работы, учётку с правами на рабочие станции (Tier 2), учётку с правами на серверы (Tier 1). Domain admin - только если реально нужен, и только для операций на контроллерах домена. Психологически это воспринимается как усложнение жизни, и это правда. Но это именно тот компромисс, который делает lateral movement нетривиальным.

Четвёртое - Protected Users Security Group. В Windows Server 2012 R2 и выше Microsoft добавил группу Protected Users, членство в которой автоматически запрещает кеширование учётки в LSASS, запрещает NTLM-аутентификацию и требует Kerberos. Это прямая контрмера против pass-the-hash. Domain admins туда добавляются в первую очередь.

Где сейчас

Результатов по внедрению пока немного - работа идёт. Главное наблюдение на этом этапе: сопротивление идёт не от технических ограничений, а от привычек. Администраторы годами работали с одной учёткой на всё. Переключение на «взял PAW, открыл RDP на DC, сделал дело, закрыл» требует изменения рабочего процесса, а не только конфигурации GPO.

Самое неприятное открытие в одной из сред: несколько сервисных служб работали под domain admin - не потому что это кто-то сознательно настроил, а потому что при первоначальной установке кто-то выбрал domain admin «чтобы точно хватило прав» и так и оставил. Таких мест оказалось больше, чем ожидалось. Аудит логинов нашёл их раньше, чем Mimikatz.

Tier Model - это не защита от первоначального заражения. Это ограничение радиуса взрыва после того, как заражение случилось. NotPetya прошёлся бы по Tier 2 полностью в любом случае. Но без доменных кредов в LSASS рабочих станций - он бы там и остался.