Скажи "друг" и войди: как находить слабые пароли в Active Directory
Фраза "Ennyn Durin Aran Moria: pedo mellon a minno" переводится как "Врата Дурина, Владыки Мории. Скажи "друг" и войди". Эльфийское слово *mellon* открывало путь каждому, кто мог прочитать надпись над воротами. В корпоративной инфраструктуре похожая ситуация возникает тогда, когда пароль формально соответствует требованиям, но легко угадывается или уже опубликован в украденных базах.
Почему пароль остаётся главным слабым местом
Даже строгая политика Active Directory не гарантирует, что пользователь выберет действительно надёжную комбинацию. Требования вроде "не менее 12 символов, цифра, заглавная буква и специальный знак" легко обходятся паролями наподобие `Zima2025!`, `Qwerty123!` или `P@ssw0rd`. Они выглядят сложными для формальной проверки, но входят в первые позиции популярных словарей.
Политика домена контролирует длину, состав и историю пароля, однако не понимает его смысл. Она не знает, что название компании с текущим годом подбирается почти мгновенно, а замена буквы на символ не превращает распространённое слово в секрет.
Проблема усугубляется повторным использованием паролей. Сотрудник может применить одну и ту же комбинацию для корпоративной учётной записи, интернет-магазина и личной почты. Утечка стороннего сервиса в таком случае становится прямой угрозой домену.
Скомпрометированный пароль позволяет войти под настоящей учётной записью. Для систем мониторинга такой вход нередко выглядит легитимным: правильный логин, правильный пароль, знакомое устройство или VPN. Поэтому обнаружить атаку после компрометации бывает значительно сложнее, чем предотвратить её.
Что происходит внутри Active Directory
В базе контроллера домена `ntds.dit` пароли хранятся не в открытом виде, а в виде производных значений - хешей и ключей. Классический NT-хеш строится на основе MD4 без соли. Это означает, что одинаковые пароли дают одинаковый результат. Если у десяти пользователей пароль совпадает, их NT-хеши также будут идентичны.
Отсутствие соли делает массовую проверку особенно удобной для атакующего. Можно заранее вычислить хеши для большого словаря и затем быстро сопоставить их со значениями из домена.
LM-хеш считается устаревшим механизмом, однако в старых средах и при совместимости с наследуемыми системами он иногда всё ещё встречается. Его наличие следует расценивать как отдельный признак слабой конфигурации.
В Kerberos ситуация сложнее: ключи формируются с использованием соли и параметров учетной записи или протокола. Однако это не отменяет риска плохого пароля. Если исходный секрет легко угадывается, даже более современная схема хранения не делает его надёжным.
Отдельное внимание нужно уделять обратимо шифруемым паролям. Такая настройка фактически позволяет получать данные, пригодные для восстановления исходного секрета. Она требуется лишь отдельным устаревшим сценариям и без веской причины не должна применяться в домене.
Проверять утечки или подбирать пароль
На практике разумно сочетать два подхода.
Первый - сравнение хешей с каталогами ранее скомпрометированных паролей. Этот метод помогает находить секреты, которые уже попали в публичные или криминальные базы. Он не требует раскрывать исходный пароль и обычно выполняется быстро.
Второй - проверка по словарям и правилам генерации. В корпоративный словарь включают название организации, бренды, города присутствия, имена проектов, названия продуктов, сезоны, годы и типичные шаблоны вроде `слово+год+символ`. Это позволяет обнаружить пароли, которых ещё нет в известных утечках, но которые предсказуемы.
Цель аудита - не получить доступ к чужим учетным записям, а определить, какие комбинации необходимо принудительно заменить.
Безопасная схема аудита
Работу следует проводить только с письменным разрешением владельца инфраструктуры и в заранее согласованные сроки. Для лабораторной проверки можно развернуть отдельный тестовый домен с искусственными пользователями.
1. Подготовьте инструменты. Используйте проверенные средства аудита Active Directory, например модули, способные анализировать экспортированные хеши. Инструмент должен запускаться с выделенной административной машины и не сохранять результаты в общедоступных каталогах.
2. Создайте локальную базу проверок. Вместо отправки хешей во внешние сервисы лучше использовать заранее загруженный набор известных паролей и их NTLM-представлений. Так снижается риск раскрытия информации о пользователях.
3. Сформируйте словарь организации. Добавьте доменные имена, названия филиалов, продукты, внутренние сокращения, популярные русские и английские слова, а также варианты с годами и символами. Не включайте в отчёты исходные пароли.
4. Получите данные с контроллера домена. Операции уровня DCSync допустимы только для специально выделенной учетной записи аудита. Её права должны быть минимальными и временными. После завершения проверки доступ необходимо отозвать, а действия - сопоставить с журналами событий.
5. Сопоставьте значения. Проверяйте хеши локально, не передавая их третьим сторонам. Для каждой найденной записи фиксируйте только идентификатор учетной записи, категорию проблемы и приоритет исправления.
6. Подготовьте отчёт. Разделите результаты на критические и менее опасные: пароль найден в утечке, совпадает с корпоративным словарём, используется у привилегированной учетной записи или повторяется у нескольких сотрудников.
Типичные ошибки
Одна из распространённых проблем - проверка только длины пароля. Длинная фраза из очевидных слов может подбираться быстрее, чем короткая случайная комбинация.
Нельзя ограничиваться одной выгрузкой. Состав пользователей и их секретов меняется, поэтому аудит стоит повторять регулярно: после крупных утечек, кадровых изменений, миграции домена и появления новых сервисных учетных записей.
Опасно хранить дампы и отчёты без защиты. Даже хеши являются чувствительными данными: их можно использовать для офлайн-проверок и атак. Файлы следует шифровать, ограничивать доступ и удалять после завершения работ.
Ещё одна ошибка - принудительно менять все пароли без объяснения причин. Это провоцирует сотрудников записывать новые комбинации на бумаге или использовать предсказуемые варианты. Пользователям нужно сообщить о риске и предложить удобный менеджер паролей.
Что делать после обнаружения слабых паролей
Для обычных учетных записей следует потребовать немедленную смену пароля и проверить активные сессии, токены, VPN-подключения и историю входов. Если пароль использовался на сторонних сайтах, его необходимо заменить и там.
Привилегированные аккаунты требуют отдельного порядка: смены секрета, проверки делегированных прав, анализа событий входа и поиска подозрительных действий. Для администраторов желательно применять отдельные учетные записи, аппаратные ключи и многофакторную аутентификацию.
Сервисные учетные записи нельзя оставлять без контроля. Им следует назначать длинные случайные секреты, использовать управляемые сервисные аккаунты, ограничивать интерактивный вход и регулярно пересматривать разрешения.
Как снизить риск в дальнейшем
Эффективная защита строится не на одном правиле, а на нескольких слоях:
- запретить старые протоколы и LM-хеши;
- отключить обратимое шифрование без доказанной необходимости;
- внедрить многофакторную аутентификацию для удалённого доступа и администраторов;
- использовать фильтр запрещённых паролей;
- запретить комбинации с названием компании, продуктами и массовыми шаблонами;
- применять менеджеры паролей;
- регулярно проверять доменные учетные записи и группы с повышенными правами;
- контролировать события аутентификации и признаки массовой смены или подбора паролей;
- минимизировать права учетных записей по принципу наименьших привилегий.
Многофакторная аутентификация не отменяет аудит паролей, а дополняет его. Если пароль утёк, второй фактор значительно снижает вероятность входа, но не защищает от всех сценариев: фишинга, кражи сессии, социальной инженерии и атак на восстановление доступа.
Главный вывод прост: пароль, который легко угадать или найти в утечке, нельзя считать защищённым только потому, что он содержит цифру и специальный символ. В Active Directory необходимо проверять не соответствие формальным правилам, а реальную предсказуемость секретов. Иначе корпоративные "ворота" могут открыться любому, кто знает очевидное слово.