Скажи "друг" и войди: как находить слабые пароли в Active Directory
"Ennyn Durin Aran Moria: pedo mellon a minno" - "Врата Дурина, Владыки Мории. Скажи "друг" и войди". В легендарной истории пароль *mellon*, то есть "друг", открывал Западные врата Мории любому, кто мог прочитать надпись над входом. Решение было удобным для союзников, но столь же удобным для любого постороннего.
В корпоративных сетях аналогичная ситуация встречается гораздо чаще, чем хотелось бы. Пароли пользователей Active Directory нередко строятся на названии компании, времени года, текущем годе или простых шаблонах вроде `Qwerty123!`, `P@ssw0rd` и `Zima2025!`. Формально такие комбинации могут соответствовать требованиям политики: содержать прописные и строчные буквы, цифры, специальные символы и иметь достаточную длину. Однако для атакующего они остаются предсказуемыми.
Почему стандартная политика паролей не решает проблему
Администратор может установить минимальную длину пароля, обязательное использование нескольких классов символов, запрет повторного применения и блокировку после серии неудачных попыток. Но сама доменная политика обычно не оценивает смысл пароля. Она не понимает, что комбинация из названия организации и текущего года угадывается за несколько попыток, а замена буквы на символ в слове `Password` давно стала общеизвестным приёмом.
Именно поэтому необходима проверка паролей в Active Directory, учитывающая не только формальные правила, но и присутствие комбинаций в словарях, публичных утечках и наборах наиболее популярных паролей. Такой подход позволяет обнаружить проблему до того, как ей воспользуется внешний злоумышленник.
В многочисленных инцидентах первопричиной становится не уникальная уязвимость и не сложная вредоносная программа, а действующая учётная запись с украденным или подобранным паролем. Если сотрудник повторно использовал один и тот же пароль на рабочем портале и стороннем сервисе, утечка последнего способна открыть путь во внутреннюю инфраструктуру.
Даже при внедрении MFA, PAM, сегментации и принципов Zero Trust пароль остаётся важной частью защиты. Скомпрометированная доменная учётная запись может использоваться для перемещения по сети, доступа к файловым ресурсам, повышения привилегий и дальнейшего захвата инфраструктуры.
По данным Verizon DBIR за 2025 год, украденные учётные данные остаются ведущим способом первоначального доступа: в атаках на веб-приложения они фигурируют в 88% случаев, тогда как базовым требованиям сложности соответствовали лишь 3% скомпрометированных паролей. В отчёте IBM Cost of a Data Breach 2024 компрометация учётных данных названа причиной 16% утечек. Такие инциденты в среднем обнаруживаются и локализуются за 292 дня, а средняя стоимость последствий достигает 4,9 млн долларов. В России, по данным Positive Technologies, в первой половине 2024 года кража учётных данных встречалась в 21% успешных атак на организации - на девять процентных пунктов больше, чем годом ранее.
Что происходит внутри Active Directory
Для оценки рисков важно понимать, как домен хранит сведения об учётных записях. В базе контроллера домена `ntds.dit` находятся производные значения паролей, а не открытые строки. Однако это не означает, что данные бесполезны для проверки.
Классический NT-хеш строится на основе алгоритма MD4 и не использует соль. Поэтому одинаковые пароли дают одинаковые значения. Если один и тот же пароль применяют несколько пользователей, это можно выявить по совпадающим хешам. Кроме того, NT-хеши могут использоваться в атаках типа Pass-the-Hash, когда злоумышленнику не требуется знать исходную строку.
LM-хеш относится к устаревшему механизму, который в современных средах желательно полностью отключать. Несмотря на архаичность, следы поддержки LM иногда сохраняются в старых конфигурациях и совместимых системах.
В Kerberos применяются ключи, производные от пароля с использованием дополнительных параметров, включая соль. Это повышает устойчивость к массовому сравнению готовых таблиц, однако не делает слабый пароль сильным. Если комбинация популярна или уже присутствует в словаре, её всё равно можно проверить.
Для практического анализа используют специализированные инструменты аудита Active Directory. Они позволяют сопоставлять данные домена с локальными словарями, базами известных утечек и корпоративными шаблонами - без необходимости раскрывать пароли в открытом виде.
Как организуют аудит
Полноценный аудит безопасности Active Directory следует проводить в контролируемой среде и с официального разрешения владельца инфраструктуры. Обычно процесс включает несколько этапов.
Сначала подготавливают рабочую машину и устанавливают инструменты для чтения доменных данных, например DSInternals. Затем загружают локальную базу скомпрометированных паролей Have I Been Pwned в формате NTLM. Важно заранее проверить происхождение базы, её целостность и порядок безопасного хранения.
Следующий этап - формирование собственного словаря организации. В него могут входить варианты названия компании, бренды, имена продуктов, названия филиалов, городов, внутренних проектов и типовые сезонные комбинации. При этом не следует собирать лишние персональные данные: задача проверки - выявить шаблоны, а не создать дополнительный риск.
После этого уполномоченный администратор получает хеши доменных учётных записей с контроллера, например посредством DCSync в рамках согласованной процедуры. Доступ к такой операции должен быть строго ограничен: тот, кто способен извлечь хеши, фактически получает крайне чувствительный уровень контроля над доменом.
Затем выполняется сопоставление с базами утечек и словарями. В отчёте полезно разделять как минимум несколько категорий: пароли, замеченные в публичных утечках; совпадения с популярными словарными значениями; корпоративные шаблоны; повторное использование одной комбинации несколькими пользователями; потенциально опасные настройки вроде обратимого шифрования паролей.
Подробнее о методике и технической стороне процесса можно прочитать в материале о поиске легко угадываемых паролей в Active Directory. Практическая ценность такого анализа заключается не в составлении рейтинга сотрудников, а в снижении вероятности компрометации домена.
Что может пойти не так
Одна из распространённых ошибок - считать отсутствие совпадения с базой утечек доказательством безопасности. Уникальный пароль может быть слабым, если он основан на предсказуемом шаблоне. Другая проблема - проверка только активных пользователей без учёта сервисных, технических и резервных учётных записей. Именно такие аккаунты нередко имеют расширенные права и долго не меняют пароль.
Нельзя забывать и о ложных выводах. Совпадение хеша с записью в базе показывает, что пароль известен или уже встречался, но не раскрывает личность виновного и не доказывает факт атаки. Результаты необходимо рассматривать как основание для корректирующих мер, а не как повод для наказания пользователя.
Отдельного внимания требуют обратимо шифруемые пароли. Включение этой опции создаёт повышенный риск, поскольку в некоторых сценариях становится возможным восстановление исходного значения. Если такая настройка не нужна конкретному приложению или протоколу, её следует отключить, а затронутые пароли принудительно заменить.
Как реагировать на результаты
Найденные слабые пароли нужно менять по приоритету. В первую очередь - у привилегированных пользователей, администраторов, сервисных аккаунтов и сотрудников с доступом к критическим системам. Одновременно стоит проверить, не используется ли та же комбинация на внешних сервисах.
Полезным дополнением становится запрет известных скомпрометированных паролей при создании и смене учётной записи. В современных версиях Windows и Azure AD/Entra ID для этого применяются кастомные списки запрещённых паролей и встроенные механизмы защиты от популярных комбинаций. Важно также внедрять многофакторную аутентификацию там, где это возможно, особенно для удалённого доступа и административных операций.
Проверку следует проводить регулярно: после крупных утечек, изменения доменной политики, реорганизации компании и появления новых сервисов. Так поиск слабых паролей в Active Directory превращается из разовой акции в постоянный процесс управления рисками.
Итоговая цель - не просто выявить несколько комбинаций вроде `Company2025!`, а построить устойчивую систему. Она должна включать контроль привилегий, мониторинг подозрительных входов, своевременную ротацию секретов, обучение сотрудников и регулярный аудит безопасности Active Directory. Такая комплексная защита Active Directory от атак существенно снижает вероятность того, что одна предсказуемая строка станет для злоумышленника тем самым словом "друг", открывающим ворота всей корпоративной сети.
