Привет, Хабр! Меня зовут Дмитрий Федосов, я руковожу отделом наступательной безопасности в Positive Technologies. В этой статье мы с ведущим специалистом нашего отдела Владиславом Дриевым поделимся опытом автоматизации рутины в пентесте, который мы также используем в нашем продукте PT Dephaze.
Вообще, автоматизация рутины пентеста — довольно очевидная идея, но на пути от замысла до работающего средства стоит множество подводных камней: от неочевидных багов популярных инструментов до проблем с масштабированием и конкуренцией за сетевые ресурсы.
В статье речь пойдёт о том, как автоматизация меняет сам подход к оценке защищенности инфраструктуры. Разберем, с каких атак начать исследователю, как избежать скрытых проблем с Masscan, Kerbrute, Impacket, и почему на рынке до сих пор так мало готовых решений.
Почему вы захотите начать использовать автоматизацию в пентестах
Пентест был и остается одним из самых убедительных способов проверки защиты. Его сила — в наглядности: вместо абстрактных угроз отчет показывает реальный сценарий, как атакующий проникает внутрь и добивается своих целей. Но у классического подхода есть три фундаментальные особенности.
Первая — кадровая. Специалисты, способные проводить такие проверки, на вес золота, и их труд невозможно масштабировать. По нашей статистике, лишь каждая пятая компания может позволить себе регулярные полноценные пентесты.
Вторая — большое количество хор��шо известных уязвимостей. Большинство успешных атак эксплуатируют давно известные проблемы безопасности: небезопасные конфигурации и уязвимости ADCS, атаки на Kerberos (Kerberoasting, ASREPRoasting и т.д.), популярные уязвимости (PrintNightmare, ZeroLogon, NoPAC и т.д.), слабые пароли или пароли по умолчанию и множество других. Эти проблемы массово встречаются в инфраструктурах, и они идеально подходят для автоматических проверок.
Третья — потребности защитников. Им нужна не разовая проверка, а инструмент под рукой. После любого изменения — введения новых сервисов в эксплуатациюили обновления СЗИ — должна быть возможность быстро проверить, видна ли атака в логах и срабатывают ли детекты.
Именно эти три особенности делают автоматизацию не просто удобным инструментом, а стратегическим шагом для развития наступательной безопасности.
С каких атак начать
Выбор атак для автоматизации логично начинать с наиболее типовых и воспроизводимых векторов, таких как отравление мульти-адресного трафика и перехват различных учетных данных.
В первую очередь это NetNTLMv1/v2, clear-text пароли через WebDAV, LDAP, FTP — их можно как сразу переиспользовать в пентесте, так и передать на брутфорс, если речь о хэшах или извлеченных с помощью Kerberoasting билетах. Сюда же относятся NTLM Relay-атаки на SMB, где подготовка целей предсказуема, при этом сохраняется широкая вариативность сценариев.
Для аудита парольных политик важным является перечисление учетных записей и попытка подбора пароля из списка часто используемых (он же спреинг) в домене Active Directory. Для различных сервисов также важна проверка на заданные по умолчанию учетные данные типа вроде postgres/postgres для PostgreSQL, почти гарантированно дает результат в крупной инфраструктуре. Это же касается атак на ADCS (ESC1, ESC8, ESC15) и классических техник вроде уже упомянутой Kerberoasting или ASREPRoasting.
Отдельный пласт — дамп учетных данных: Security Accounts Manager (SAM), LSA (Local Security Authority), LSASS (Local Security Authority Subsystem Service) и NTDS.dit, которые можно переиспользовать. Если у вас возникает резонный вопрос: насколько дамп учётных данных из LSASS, вообще, работает в 2025 году, то короткий ответ — крайне редко. Однако наш опыт проверки 50 реальных инфраструктур показал, что примерно в 6% случаев находится конечная точка, где EPP/EDR отключен или вовсе не развернут, и учётные данные из LSASS могут быть получены штатными утилитами, например, через netexec.
Архитектурно мы также заложили механизм повторного использования ранее собранных учетных данных. На практике этот подход стабильно показывает высокую эффективность, замыкая цикл автоматизированного пентеста.
Как тестировать: больше GOAD’ов хороших и разных
За основу нашей тестовой среды мы взяли GOAD — известную лабораторию Active Directory с заранее настроенными доменами и типовыми уязвимостями. Однако одного GOAD оказалось недостаточно, поэтому мы создали множество специализированных стендов для разных задач.
Для каждого нового сценария мы разворачиваем отдельную лабораторию. Например, домен с интегрированным GitLab для проверки аутентификации, стенд с отечественным или классическим Linux. Это позволяет писать и проверять тест-кейсы, убеждаясь в корректной отработке всех векторов.
Также мы добавили высоконагруженные сетевые тесты — поскольку GOAD идеален для отладки логики лишь на небольшой инфраструктуре, состоящей из нескольких машин. Но реальность такова, что инфраструктура заказчика может быть огромной и включать десятки тысяч хостов.
Инструменты автопентеста и некоторые неочевидные проблемы
Казалось бы, методика есть, стенды готовы — можно запускать автоматизацию и пожинать плоды. Но как только мы углубились в разработку, жизнь сразу подкинула нам целый ворох нетривиальных проблем. Оказалось, что многие популярные инструменты, которые могут отлично работать в руках пентестера, в автотестах ведут себя непредсказуемо, а то и просто отказываются работать. Мы расскажем о самых показательных проблемах и о том, как нам удалось их решить.
Сканирование портов и недостатки Masscan
Первым этапом любого пентеста часто является сканирование портов. Классический выбор для этой задачи — Nmap, универсальный и проверенный инструмент. Однако в поисках максимальной скорости мы обратились к более современному решению — masscan. Его хвалят за производительность, но, как оказалось, за этой скоростью скрываются существенные компромиссы.
Однажды в ходе тестирования мы столкнулись с неочевидной проблемой: в идентичных условиях разные сканеры показывали разные результаты.
Начав с изучения документации, мы обнаружили ключевое отличие. Masscan использует собственный стек TCP/IP, в то время как Nmap полагается на ресурсы операционной системы.
Этот факт заставил нас проанализировать сетевой трафик. На сетевом уровне картина в Wireshark была идентичной для обоих инструментов.
Тогда мы спустились на канальный уровень и нашли разгадку — оказалось, что Masscan по умолчанию посылает все отправляемые пакеты на шлюз. В то же время Nmap, если целевой узел находится в локальной сети, обращается к нему напрямую — как и должно быть в классическом случае сетевого взаимодействия.
Masscan:
Nmap:
Проблема возникает из-за того, что некоторые шлюзы не разрешают обратный редирект пакетов в локальную сеть. В таких случаях Masscan не показывает результатов. Если шлюз разрешает такую маршрутизацию, сканирование работает корректно.
Решение
Мы рассматривали несколько путей:
Разместить Masscan за NAT — плохой вариант, искажающий реальную картину сети.
Использовать стандартный Nmap — надежно, но слишком медленно.
Разогнать Nmap с помощью тонкой настройки параметров — оптимальное решение.
Для промышленной автоматизации нам требовался стабильный результат. Поэтому мы отказались от Masscan для внутренних сетей, оставив его лишь для внешнего сканирования, где трафик всегда проходит через NAT. Внутреннее сканирование теперь выполняет кастомизированный Nmap, который мы настроили на скорость, сопоставимую с Masscan, без потери точности.
Начальный доступ в домен — Kerbrute и двойная аутентификация
После сканирования портов и обнаружения ключевых сервисов следующая задача — получение начального доступа в домен. Одна из самых распространенных методик для этого — перечисление пользователей через особенности протокола Kerberos с последующим спреем популярных паролей.
Для этих целей существует известный инструмент Kerbrute, получивший широкое признание на GitHub. Его базовое использование интуитивно понятно: при успешном подборе пароля аутентификация проходит, а при неудаче возвращается ошибка.
Однако здесь кроются серьезные риски, поскольку при агрессивном использовании инструмент может заблокировать множество учетных записей из-за срабатывания систем защиты от перебора. Казалось бы, решение очевидно: уточнить у заказчика парольную политику и настроить инструмент под её лимиты, например, не более 3 попыток в течение 5 минут. Это безопасно, хотя и растягивает проверку по времени.
Но даже с такими настройками инструмент вел себя странно. Оказалось, в Kerbrute есть критический баг: некоторые версии тратят две попытки аутентификации на один пароль, что резко повышает риск блокировки учетных записей при спреинге.
Причина кроется в исходном коде. При неудачной аутентификации с шифром AES-128 инструмент автоматически повторяет попытку с AES-256, независимо от причины первоначальной ошибки.
Ситуация усугубляется несоответствием между официальными релизами и исходным кодом на GitHub. Скомпилированные версии из релизов работают корректно (1 пароль = 1 попытка), тогда как сборка из текущего кода воспроизводит проблему.
Решение
Пришлось патчить исходный код, чтобы убрать двойную аутентификацию. После этого Kerbrute стал работать предсказуемо и перестал создавать лишние риски для инфраструктуры заказчика.
Разведка в LDAP в условиях усиленной безопасности
Следующая задача пентеста после получения доступа в домен— разведка через LDAP. Для этого традиционно использу��тся инструменты на Python-библиотеке impacket, такие как BloodHound.py, Certipy, dnstool.py, ldapdomaindump и другие техники.
Проблема возникает при включении на контроллерах домена строгих настроек безопасности. Когда активированы LDAP Signing и Channel Binding, стандартный impacket завершает работу с ошибкой, срывая всю дальнейшую разведку.
Пример с безопасными настройками, получаем ошибку:
Пример с настройками по умолчанию, получаем успешное выполнение:
Теоретически можно поставить кастомную версию библиотеки с поддержкой этих настроек.
Однако это работает только если в коде есть соответствующие возможности, например, в BloodHound.py для этого достаточно добавить специальный флаг.
Но многие утилиты вроде dnstool.py не имеют таких опций и в принципе не работают в защищенных средах.
Стало ясно, что мы имеем дело с системной проблемой, и нужен был не временный костыль, а принципиально иной инструмент, изначально заточенный под современные стандарты безопасности.
Решение
Таким инструментом для нас стал msldap. Его ключевое преимущество — стабильная работа как со стандартными, так и с усиленными настройками безопасности LDAP. При этом он поддерживает весь спектр атак и техник, доступных в impacket, поскольку в нем есть свои версии тех же популярных утилит вроде Certipy и BloodHound. Это позволяет беспрепятственно проводить разведку в защищенных доменах: находить небезопасные конфигурации, анализировать шаблоны сертификатов и готовить данные для дальнейшей эксплуатации.
При проверке msldap успешно прошел аутентификацию и извлек информацию о шаблонах сертификатов даже при включенных Signing и Channel Binding. Аналогично, реализация BloodHound в msldap стабильно собирает данные для построения графа атак, которые затем можно импортировать и анализировать на предмет ошибок в конфигурации домена.
Конкуренция за 445/TCP
Еще одна проблема, с которой мы столкнулись при разработке системы автоматизации — конкуренции за сетевые ресурсы. Многие угрозы, такие как NTLM Relay или атаки на ADCS, требуют доступа к SMB-порту 445/TCP. Когда несколько инструментов пытаются одновременно использовать один порт, возникает конфлик��, нарушающий работу всей цепочки.
Проблема проявляется в хаотичном потоке аутентификационных запросов. NBNS спуфинг, NTLM Relay с Coerce и другие техники генерируют трафик, который должен быть точно направлен в нужную утилиту в определенный момент времени. Без четкого управления этот трафик обрабатывается некорректно, и атаки не срабатывают.
Решение
Здесь нам помог кастомный прокси на базе socat, который маршрутизирует трафик по заданной логике. Первым шагом мы упростили Responder, оставив только функцию спуфинга (NBNS/LLMNR), а механизм захвата хэшей исключили, так как эту задачу выполняют другие инструменты, например, ntlmrelayx.
Ключевым элементом системы стала логика приоритизации. Критичные векторы, такие как атака ESC8 на центр сертификации, получают высший ранг и обрабатываются в первую очередь. Более простые или менее важные задачи, вроде стандартного Relay, выполняются позже. Такой подход позволяет гибко распределять ресурсы и гарантировать выполнение наиболее важных этапов компрометации.
Почему автоматизированный пентест всё ещё редкость
Вернемся к главному вопросу: если автоматизация так хороша, почему ей до сих пор мало кто занимается? Изначальная сложность задачи — это только начало. Основная трудность в том, чтобы формализовать и воспроизвести экспертные решения, которые живой специалист порой принимает интуитивно.
На выбор векторов атаки влияет всё: от навыков и насмотренности пентестера до его личных предпочтений. Мы не пытаемся копировать человеческое мышление и создаем архитектуру, способную методично проверять максимальное количество векторов на основе детерминированной логики, а не на архитектуре AI-агентов. При этом мы, конечно, полностью не отказываемся от использования ML для решения отдельных задач автоматизации.
Практическую ценность подхода лучше всего показывает пример из реальной инфраструктуры. После классического сканирования наше решение проверило SSH-серверы, где вместо стандартного admin/admin использовался расширенный список паролей, включая комбинации слабых паролей, в том числе keyboard walk. Это позволило скомпрометировать учетную запись unix_user.
Архитектура системы поддерживает переиспользование учетных данных. Эти же логин и пароль оказались действительны в домене Active Directory, который был в рамках скоупа проверки. В итоге, начав со случайного Linux-сервера, мы автоматически получили начальный доступ в домен.
Далее система провела разведку домена и обнаружила на одном из Windows-хостов свежую уязвимость для повышения привилегий (Reflection Relay, CVE-2025-33073). Это позволило получить права локального администратора, через добавление локального администратора dphz_adm_1337. Хотя Endpoint Protection заблокировал прямой дамп LSASS, нам удалось извлечь хэш встроенного локального администратора (Administrator).
С помощью переиспользования найденных учетных данных нашли другой компьютер, на который они успешно подошли. Захватив его, автоматика снова попыталась извлечь учётные данные из LSASS, но Endpoint Protection опять не дал нам этого сделать. В то же время, мы смогли на этом компьютере успешно извлечь локальные секреты из LSA (Local Security Authority), среди которых был обнаружен пароль доменного администратора (service_user@contoso.com) в открытом виде.
Эти учетные данные были использованы для подключения к контроллеру домена. Успех операции был зафиксирован созданием пользователя в группе доменных администраторов. Нам кажется, этот пример наглядно демонстрирует, что даже детерминированный подход с грамотной архитектурой позволяет автоматически отрабатывать сложные, неочевидные векторы, типичные для ручного пентеста, и доводить атаку до полного контроля над доменом.
Что это меняет на практике
Правильная автоматизация рутинных задач в пентесте — это не просто набор скриптов и хакерских утилит, а принципиально иной уровень экспертизы, который стоит отдельного продукта. Мы на своём опыте добавления экспертизы в продукт PT Dephaze убедились, что решая множество задач, часть из которых рассмотрена в настоящей статье, делаем пентест более доступным для компаний. Это масштабирует наш опыт пентестов, превращает разовые проверки в непрерывный процесс, закрывает «серую зону» между плановыми ручными пентестами. Выявление часто встречающихся уязвимостей и небезопасных конфигураций из реальных векторов компрометации упрощает процесс приоритизации исправлений. Это позволяет поддерживать высокий уровень защищенности инфраструктуры в течение года, даже если в организации нет внутренней команды пентестеров. А если есть, то такие системы снимают рутину со специалистов и освобождают время для креативных задач, повышая общую эффективность команды.