[Информационная безопасность] Аудит паролей Активной Директории Windows
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Если в вашей компании активно используется домен Windows, рано или поздно перед вами встанет задача повысить безопасность используемых паролей. Штатных средств (кроме тривиальной групповой парольной политики) тут нет, нормальных продуктов тоже нет. Пароли хранятся в виде хэшей, которые ещё и достаточно сложно достать, поэтому прямой анализ безопасности не возможен. Я попытался построить процесс, который, при нужной сноровке, не займет у вас больше нескольких часов и будет прекрасно повторяем. Можно будет напрямую отслеживать, как ваши усилия увеличивают стойкость паролей в компании, а это всегда приятно. Атаки на паролиВсе атаки на пароли можно разделить на 2 большие группы: онлайн и офлайн. Если злоумышленнику удалось получить хэши паролей – он может использовать офлайн атаку перебором (брутфорс). Нужно сказать, что если злоумышленник смог получить NT хэш в корпоративной сети – что-то уже пошло не так. Возможно, у вас есть проблемы по-серьезней, чем стойкость хэшей. Да и защита от брутфорса – дело, в основном, разработчика: нужно выбирать правильные (медленные) алгоритмы хэширования. Поэтому брутфорс я обычно оставляю за бортом.Из онлайн атак у нас есть password spay и password replay. По данным Майкрософт password spraying – самая распространенная атака на пароли, ответственная за ~40% успешных взломов аккаунтов М365. Злоумышленники пробуют одинаковый пароль сразу на нескольких аккаунтах (тысячах). Это обеспечивает высокую скорость подбора пароля, при этом политика временной блокировки аккаунта при многократном вводе неправильного пароля не срабатывает. Password replay – вторая по частоте атака. Злоумышленники используют базы данных слитых учётных записей, пробуя их на ваших системах. Если сотрудник использует тот же самый пароль, который был у его аккаунта LinkedIn в 2012 году – двери открыты. Это, действительно, проблема нашего времени. Средний пользователь помнит 8 разных паролей, но использует более 40 аккаунтов (включая личные), следовательно пароли используются повторно, и задача корпоративной ИБ убедить пользователя выделить драгоценное место в своей памяти под уникальный пароль для корпоративного аккаунта. Самая дорогая память в ИТ – это память пользователя.Проверить свой пароль на наличие/отсутствие в утечках можно тут(но лучше не надо).
haveibeenpwned.comТребования к паролямСобственно, теперь у нас есть основные требования к корпоративным паролям:
- Пароль не должен быть частью какой-либо утечки
- Пароль должен быть уникальным
К слову сказать, это действительно единственные требования, которые имеет смысл предъявлять к паролям. Если вы по-прежнему требуете периодической смены пароля или наличия спецсимволов – прочитайте-ка рекомендации Майкрософт. “Запоминаемость” пароля ничуть не менее важна, чем спецсимволы или чехарда с его сменой. Оба этих требования достаточно легко проверить без каких-либо серьезных затрат времени и ресурсов, и я покажу как.Достать хэшиХэши хранит любой контроллер домена в файле 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” тут обыденность. Менять такие пароли нужно аккуратно, ибо чёрт знает в каком продакшн скрипте их закодили.
Если вам удастся правильно построить работу службы ИБ, то на плечи красной команды ляжет только мониторинг. Самая тяжелая часть уйдет в ИТ.
Вот, пожалуй, и всё. Пишите комментарии и задавайте вопросы!
===========
Источник:
habr.com
===========
Похожие новости:
- [Разработка веб-сайтов, Python, API] Как я сделал веб-фреймворк без MVC — Pipe Framework
- [Информационная безопасность, Разработка под iOS, Монетизация мобильных приложений] Google ввела ярлыки конфиденциальности в сервис Gmail для iOS
- [Информационная безопасность, Big Data, Браузеры, Социальные сети и сообщества] Brave new world
- [Программирование, Анализ и проектирование систем, Проектирование и рефакторинг] Эффективная конструкция агрегата. Заставляем агрегаты работать вместе (перевод)
- [Информационная безопасность, Антивирусная защита, Разработка под MacOS] На 30 тысячах компьютеров с macOS нашли странный зловред, который ждёт команду
- [C, Программирование микроконтроллеров] АЦП преобразования в указанные моменты времени на STM32
- [Информационная безопасность] Security Week 08: спам в 2020 году
- [Системное администрирование, Python, *nix, Серверное администрирование, DevOps] Improving Ansible (перевод)
- [Информационная безопасность, Системное администрирование, IT-инфраструктура, Серверное администрирование] Аудит событий Active Directory и других решений Microsoft в Quest Change Auditor — анонс вебинара
- Доступна двадцать четвёртая альфа-версия открытой игры 0 A.D.
Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_ib (ИБ), #_paroli (Пароли), #_aktivnaja_direktorija (Активная директория), #_ad, #_domen (домен), #_informatsionnaja_bezopasnost (
Информационная безопасность
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 00:00
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Если в вашей компании активно используется домен Windows, рано или поздно перед вами встанет задача повысить безопасность используемых паролей. Штатных средств (кроме тривиальной групповой парольной политики) тут нет, нормальных продуктов тоже нет. Пароли хранятся в виде хэшей, которые ещё и достаточно сложно достать, поэтому прямой анализ безопасности не возможен. Я попытался построить процесс, который, при нужной сноровке, не займет у вас больше нескольких часов и будет прекрасно повторяем. Можно будет напрямую отслеживать, как ваши усилия увеличивают стойкость паролей в компании, а это всегда приятно. Атаки на паролиВсе атаки на пароли можно разделить на 2 большие группы: онлайн и офлайн. Если злоумышленнику удалось получить хэши паролей – он может использовать офлайн атаку перебором (брутфорс). Нужно сказать, что если злоумышленник смог получить NT хэш в корпоративной сети – что-то уже пошло не так. Возможно, у вас есть проблемы по-серьезней, чем стойкость хэшей. Да и защита от брутфорса – дело, в основном, разработчика: нужно выбирать правильные (медленные) алгоритмы хэширования. Поэтому брутфорс я обычно оставляю за бортом.Из онлайн атак у нас есть password spay и password replay. По данным Майкрософт password spraying – самая распространенная атака на пароли, ответственная за ~40% успешных взломов аккаунтов М365. Злоумышленники пробуют одинаковый пароль сразу на нескольких аккаунтах (тысячах). Это обеспечивает высокую скорость подбора пароля, при этом политика временной блокировки аккаунта при многократном вводе неправильного пароля не срабатывает. Password replay – вторая по частоте атака. Злоумышленники используют базы данных слитых учётных записей, пробуя их на ваших системах. Если сотрудник использует тот же самый пароль, который был у его аккаунта LinkedIn в 2012 году – двери открыты. Это, действительно, проблема нашего времени. Средний пользователь помнит 8 разных паролей, но использует более 40 аккаунтов (включая личные), следовательно пароли используются повторно, и задача корпоративной ИБ убедить пользователя выделить драгоценное место в своей памяти под уникальный пароль для корпоративного аккаунта. Самая дорогая память в ИТ – это память пользователя.Проверить свой пароль на наличие/отсутствие в утечках можно тут(но лучше не надо).  haveibeenpwned.comТребования к паролямСобственно, теперь у нас есть основные требования к корпоративным паролям:
vssadmin.exe create shadow /for=C:
Vssadmin.exe list shadows
Vssadmin.exe delete shadows /shadow=”<тут идентификатор копии>” reg SAVE HKLM\SYSTEM C:\temp\SYSTEM
sudo apt install python3
sudo apt install python3-pip python3 -m pip install impacket 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
В файле много мусора. Убрать лишнее можно так: cat hashes.lst.ntds | cut -d":" -f 1,4 | sort > hashes_sorted.lst
domain\sam_account_name:ntlm_hash
Первое, что я обычно делаю – ищу аккаунты с одинаковым хэшем (т.е. те аккаунты, где используется одинаковый пароль). Если один и тот же хэш встречается больше 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
 Если какой-либо из наших хэшей находится в этой базе – значит он “утёк”, и соответствующий пароль мы будем называть слабым. Наша цель – принудить пользователей использовать уникальный пароль для рабочего аккаунта. Качаем и распаковываем базу (сегодня это ~22 Гб, но она растёт). Первое, что нужно сделать – перевести все хэши в низкий регистр и избавится от счетчика (т.е. было так: 0717B19E4348445872D8BB57D5E562B7:14, станет так: 0717b19e4348445872d8bb57d5e562b7) cat pwned-passwords-ntlm-ordered-by-hash-v7.txt | cut -d":" -f 1 | awk '{print tolower($0)}' > hash_db.lst
Из дампа нужно тоже оставить одни отсортированные уникальные хэши: cat hashes_sorted.lst | cut -d":" -f 2 | sort -u > hashes_only_sorted.lst
На моем ноутбуке это оказалось непосильной задачей. Питон съел всю память и ничего не сделал. Тогда мне пришлось разбить 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” тут обыденность. Менять такие пароли нужно аккуратно, ибо чёрт знает в каком продакшн скрипте их закодили. Если вам удастся правильно построить работу службы ИБ, то на плечи красной команды ляжет только мониторинг. Самая тяжелая часть уйдет в ИТ. Вот, пожалуй, и всё. Пишите комментарии и задавайте вопросы! =========== Источник: habr.com =========== Похожие новости:
Информационная безопасность ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 00:00
Часовой пояс: UTC + 5