Если в вашей компании активно используется домен Windows, рано или поздно перед вами встанет задача повысить безопасность используемых паролей. Штатных средств (кроме тривиальной групповой парольной политики) тут нет, нормальных продуктов тоже нет. Пароли хранятся в виде хэшей, которые ещё и достаточно сложно достать, поэтому прямой анализ безопасности не возможен. Я попытался построить процесс, который, при нужной сноровке, не займет у вас больше нескольких часов и будет прекрасно повторяем. Можно будет напрямую отслеживать, как ваши усилия увеличивают стойкость паролей в компании, а это всегда приятно.

Атаки на пароли

Все атаки на пароли можно разделить на 2 большие группы: онлайн и офлайн. Если злоумышленнику удалось получить хэши паролей – он может использовать офлайн атаку перебором (брутфорс). Нужно сказать, что если злоумышленник смог получить NT хэш в корпоративной сети – что-то уже пошло не так. Возможно, у вас есть проблемы по-серьезней, чем стойкость хэшей. Да и защита от брутфорса – дело, в основном, разработчика: нужно выбирать правильные (медленные) алгоритмы хэширования. Поэтому брутфорс я обычно оставляю за бортом.

Из онлайн атак у нас есть password spay и password replay.

По данным Майкрософт password spraying – самая распространенная атака на пароли, ответственная за ~40% успешных взломов аккаунтов М365. Злоумышленники пробуют одинаковый пароль сразу на нескольких аккаунтах (тысячах). Это обеспечивает высокую скорость подбора пароля, при этом политика временной блокировки аккаунта при многократном вводе неправильного пароля не срабатывает.

Password replay – вторая по частоте атака. Злоумышленники используют базы данных слитых учётных записей, пробуя их на ваших системах. Если сотрудник использует тот же самый пароль, который был у его аккаунта LinkedIn в 2012 году – двери открыты. Это, действительно, проблема нашего времени. Средний пользователь помнит 8 разных паролей, но использует более 40 аккаунтов (включая личные), следовательно пароли используются повторно, и задача корпоративной ИБ убедить пользователя выделить драгоценное место в своей памяти под уникальный пароль для корпоративного аккаунта. Самая дорогая память в ИТ – это память пользователя.

Проверить свой пароль на наличие/отсутствие в утечках можно тут (но лучше не надо).

Требования к паролям

Собственно, теперь у нас есть основные требования к корпоративным паролям:

• Пароль не должен быть частью какой-либо утечки

• Пароль должен быть уникальным

К слову сказать, это действительно единственные требования, которые имеет смысл предъявлять к паролям. Если вы по-прежнему требуете периодической смены пароля или наличия спецсимволов – прочитайте-ка рекомендации Майкрософт. “Запоминаемость” пароля ничуть не менее важна, чем спецсимволы или чехарда с его сменой.

Оба этих требования достаточно легко проверить без каких-либо серьезных затрат времени и ресурсов, и я покажу как.

Достать хэши

Хэши хранит любой контроллер домена в файле ntds.dit. Ключи шифрования, необходимые для извлечения хэшей, хранятся в ветке SYSTEM реестра контроллера домена.

Чтобы извлечь ntds.dit нужно:

• Открыть на контроллере домена консоль PowerShell

• Создать теневую копию с помощью команды

vssadmin.exe create shadow /for=C:

• Зайти в папку Windows и выбрать “Properties” у папки NTDS

• Скопировать теневую копию папки из вкладки “Previous versions”

• (Не обязательно) удалить теневую копию

Vssadmin.exe list shadows
Vssadmin.exe delete shadows /shadow=”<тут идентификатор копии>”

Скопировать ветку SYSTEM реестра контроллера домена:

reg SAVE HKLM\SYSTEM C:\temp\SYSTEM

Всё. Контролер домена больше не нужен. Кстати если за это время вы не получили ни одного оповещения от средств безопасности – вам стоит присмотреться к нормальному EDR решению.

Все дальнейшие операции имеет смысл проводить на отдельной системе, которую можно даже отключить от сети и потом полностью очистить. Файл NTDS.DIT + SYSTEM – это, по сути, ключи от вашего домена. Не стоит их хранить на рабочем компьютере.

Я уже привык работать в WSL (windows subsystem for linux, Ubuntu встроенная в консоль Windows 10). Поэтому первым шагом рекомендую установить WSL (вручную или через магазин приложений) и RSAT (включает PowerShell модуль для работы с доменом) для вашей версии windows 10.

Запускаем WSL из консоли PowerShell командой bash.

Устанавливаем Python 3 и хакерскую утилиту impacket. Она нужна для вытаскивания NTLM хэшей из ntds.dit

sudo apt install python3
sudo apt install python3-pip
python3 -m pip install impacket

Из пакета Impacket нам нужен файл secretsdump.py. Его можно найти внутри Python модуля или скачать с Гитхаба

wget https://github.com/SecureAuthCorp/impacket/releases/download/impacket_0_9_22/impacket-0.9.22.tar.gz
tar -xvzf impacket-0.9.22.tar.gz
cd impacket-0.9.22/examples

извлекаем хэши

python3 secretsdump.py  -system /mnt/c/Temp/SYSTEM -ntds /mnt/c/Temp/ntds.dit LOCAL -outputfile /mnt/c/Temp/hashes.lst

Сразу проверяем наличие и содержимое файла hashes.lst.ntds.cleartext. Это пароли от тех аккаунтов, в свойствах которых стоит галка “Store password using reversible encryption”. Стоит проверить, что это действительно необходимость.
В файле много мусора. Убрать лишнее можно так:

cat hashes.lst.ntds | cut -d":" -f 1,4 | sort > hashes_sorted.lst

получится список вида:

domain\sam_account_name:ntlm_hash

Заглянем на секунду ещё раз в исходный файл. У каждого аккаунта указано по 2 хэша – LM и NTLM. Вместо первого LM хэша вы везде должны видеть “aad3b435b51404eeaad3b435b51404ee”. Если там что-то другое – аудит можно останавливать и переключить все силы на апгрейд домена.

Любимые пароли

Дальше лично я предпочитаю работать в Экселе. Вот тут мой шаблон файла , хотя, конечно, разобраться без подсказок в нём сложновато, и вам вероятно придётся создать свой.
Первое, что я обычно делаю – ищу аккаунты с одинаковым хэшем (т.е. те аккаунты, где используется одинаковый пароль). Если один и тот же хэш встречается больше 2х раз – пароль придётся сменить.
Но перед этим ещё стоит отфильтровать неактивные аккаунты. Для этого можно использовать командлет Get-ADUser (часть RSAT, я импортирую результат в свой эксель файл). Сразу можно собрать почтовые ящики - понадобится в будущем для рассылки предупреждений о сбросе пароля. В некоторых компаниях старые аккаунты не выключают, но устанавливают “ExpirationDate”. Так лучше не делать, но я собирают и эти данные тоже.

Get-ADUser -Filter * -Properties mail, AccountExpirationDate | Where { $_.Enabled -eq $True} | Select Name,samaccountname,mail,AccountExpirationDate | Export-csv C:\Temp\enabled_accounts.csv -NoTypeInformation

Половина работы сделана – теперь вы знаете, кто устанавливает тот же самый пароль на все свои аккаунты. У вас есть список таких активных аккаунтов с почтовыми адресами.

Слабые пароли

Теперь давайте взглянем, какие из наших паролей известны плохим парням. Т.к. мы играем за защиту (в России, кстати, нас правильно называть red team) – то мы не будем пробовать эти хэши подобрать (для этого нужно время и хорошее железо), а просто сравним наши хэши с базой данных утекших хэшей, любезно предоставленной Троем Хантом.

Если какой-либо из наших хэшей находится в этой базе – значит он “утёк”, и соответствующий пароль мы будем называть слабым. Наша цель – принудить пользователей использовать уникальный пароль для рабочего аккаунта.

Качаем и распаковываем базу (сегодня это ~22 Гб, но она растёт). Первое, что нужно сделать – перевести все хэши в низкий регистр и избавится от счетчика (т.е. было так: 0717B19E4348445872D8BB57D5E562B7:14, станет так: 0717b19e4348445872d8bb57d5e562b7)

cat pwned-passwords-ntlm-ordered-by-hash-v7.txt | cut -d":" -f 1 | awk '{print tolower($0)}' > hash_db.lst 

Через 5-7 минут вы должны получить отсортированный файл хэшей в нужном формате.
Из дампа нужно тоже оставить одни отсортированные уникальные хэши:

cat hashes_sorted.lst | cut -d":" -f 2 | sort -u > hashes_only_sorted.lst

Теперь нам нужно сравнить два массива хэшей, один из которых занимает ~20 Гб.

На моем ноутбуке это оказалось непосильной задачей. Питон съел всю память и ничего не сделал. Тогда мне пришлось разбить hash_db на части по 3-5 Гб и дело сдвинулось с мертвой точки.
Т.е. теперь алгоритм выглядит так: разбиваем 20Гб файл на части по 3-5 Гб (кратно 33 байта, чтобы все хэши остались целыми). Сравниваем попарно каждый кусок с массивом хэшей из дампа с помощью питоновского set.intersection. На выходе будет файл с пересечением множеств хэшей из дампа и базы данных утекших паролей.

Небольшой скрипт на питоне, который делает всё вышеперечисленное, вы можете увидеть тут.
Работает он 5-20 минут на среднем компьютере. Можно, кончено, оптимизировать, но зачем?
Получившийся файл я забираю в свою эксельку и фильтрую по флагу enabled_account. Для наглядности, я беру несколько популярных в компании слитых хэшей и перегоняю их в пароли через сайты типа hashes.com или crackstation.net. Это нужно для наглядности и хорошо смотрится на слайдах, но не является целью всей затеи. Мы – хорошие парни, хэшей нам уже достаточно.
Вторая половина тоже готова. Теперь начинается самое интересное...

Что будем считать?

Если мы внимательно посмотрим на получившийся файл, то увидим прекрасный КПИ для отдела ИБ – процент аккаунтов со стойким паролем. Вычислить его просто:

P = 1 –  enabled_accounts_with_weak_password /  total_enabled_accounts

Где enabled_accounts_with_weak_password – активные аккаунты, пароль которых принадлежит множеству утекших или повторяющихся паролей (или обоим множествам одновременно)
Задача отдела ИБ теперь в том, чтобы этот процент неуклонно рос до, скажем, 95%.
Я так же считаю другой показатель – количество пользователей, которые сменили один слабый пароль на другой слабый пароль после предупреждения службы ИБ. Эта та аудитория, с которой нужно работать. Внутри компании мы договорились о 3х предупреждениях, и если не помогло - беседе с HR.

Прежде чем начинать аудит, нужно подготовить материалы по повышению осведомленности пользователей. Иначе смысл всей затеи пропадёт.

Подготовьте страничку с описанием того, как правильно выбрать хороший пароль. Хорошо бы развесить по офису постеры (вот пример бесплатных) и сделать тематическую корпоративную рассылку. Важный этап – запланировать встречи с ИТ техподдержкой и убедить в важности выбора хороших паролей, в первую очередь, их. Обычно самый повторяющийся в компании пароль – как раз тот, который ИТ присваивает новым аккаунтам по умолчанию.

Самая тяжёлая часть – это сервис-аккаунты. Многие из них могут быть созданы подрядчиками, и пароль “India12345” с чекбоксом “never expired” тут обыденность. Менять такие пароли нужно аккуратно, ибо чёрт знает в каком продакшн скрипте их закодили.

Если вам удастся правильно построить работу службы ИБ, то на плечи красной команды ляжет только мониторинг. Самая тяжелая часть уйдет в ИТ.

Вот, пожалуй, и всё. Пишите комментарии и задавайте вопросы!