Взлом корпоративной сети за 13 минут: разбор PT

На внутреннем пентесте крупного ритейлера - 12 тысяч хостов в домене, два контроллера, сегментация "на бумаге" - от запуска Responder до DCSync прошло 11 минут. NTLMv2-хеш перехвачен через LLMNR, CrackMapExec показал reuse на файловом сервере, BloodHound нарисовал путь до Domain Admin через одну сервисную учётку с SPN. Rubeus, hashcat, secretsdump.py - готово. Когда Positive Technologies опубликовали данные PT Dephaze по ~100 организациям и медианное время компрометации оказалось 13 минут - удивления не было. Удивило другое: в 56% случаев хватило действующих учётных данных, а программные уязвимости стали основным вектором лишь в 6% сценариев. Не zero-day, не RCE - банальные пароли.

Статистика пентеста PT Dephaze: 100 организаций за два года​

PT Dephaze - автоматизированная платформа Positive Technologies для тестирования на проникновение. Исследование охватило пилотные проекты в ~100 организациях в 2025-2026 годах. Цифры из отчёта: Подробнее - в нашем руководстве по валидация безопасности.

• 60% компаний скомпрометированы - захвачен хост, получен доступ к критическим данным, либо взята под контроль служба управления учётными записями.
• 13 минут - медианное время до реализации угрозы в половине успешных сценариев.
• 56% путей к компрометации построены на использовании действующих учётных данных.
• 35% - на перенаправлении аутентификации (relay-атаки).
• 6% - эксплуатация программных уязвимостей как преобладающий механизм.
• 96% организаций - обнаружены логины в инфраструктуре.
• 77% проверок - пароли в открытом виде.
• Ошибки конфигурации встречались более чем вдвое чаще уязвимостей.

Русскоязычные источники (Коммерсант, SecurityMedia) подали эти данные как новость в два абзаца. Ни один не разобрал, какой kill chain укладывается в 13 минут и почему 56% - это про credentials, а не про CVE. Зарубежные vendor-отчёты дают контекст: по данным IBM X-Force Threat Intelligence Index 2025, infostealers (32%) стали самым распространённым типом malware, опередив ransomware. Украденные учётки - главная валюта на рынке первичного доступа. И это объясняет, почему AD ломается не через дыры в софте, а через то, что валяется в инфраструктуре открытым текстом.

Зачем атакующему Domain Admin: бизнес-логика атаки​

Контроль над Active Directory - это не абстрактный "полный доступ". Это конкретные сценарии монетизации:

Ransomware deployment. Группы вроде Play (по данным ransomware.live - активны в текущем квартале с жертвами в технологическом и сервисном секторах) используют захват AD для массовой раскатки шифровальщика через GPO. Один объект групповой политики - и все хосты в OU получают payload.

Data exfiltration. Файловые серверы, SQL-базы, почтовые ящики Exchange - всё привязано к доменной аутентификации. Domain Admin = доступ ко всему.

Persistence. Golden Ticket после компрометации krbtgt живёт до двойной ротации пароля этой учётки. На практике - месяцы, потому что ротацию krbtgt мало кто делает вообще. Я видел домены, где krbtgt не менялся с момента миграции на 2012 R2.

Supply chain pivot. Через domain trusts или VPN-туннели - в инфраструктуру партнёров и подрядчиков.

По данным IBM X-Force, 70% атак в 2024 году затронули критическую инфраструктуру. AD-домен - ключ к ней. Понимание этой мотивации важно для оценки того, почему 13 минут - это не артефакт автоматизации, а реальное время перехода от "я в сети" к "я владею сетью".

Kill chain от первого пакета до Domain Admin​

Типовой сценарий, который укладывается в 13 минут. Не теоретическая модель - хронология, которая воспроизводится на внутренних engagement-ах с минимальными вариациями. Оговорка: сценарий характерен для сетей без зрелого EDR и с дефолтной конфигурацией Windows. В среде с включённым Credential Guard, отключённым LLMNR и enforced SMB signing - цепочка ломается на первых шагах. Но таких сред - меньшинство.

Минуты 0-4: fingerprinting и credential harvesting​

Атакующий подключён к корпоративному сегменту. Первое действие - не сканирование портов. Nmap на /24 генерирует десятки тысяч пакетов и поднимает алерты даже в примитивном SIEM. Вместо этого - пассивный перехват и точечный fingerprinting.

LLMNR/NBT-NS poisoning. Когда Windows-хост не может разрешить имя через DNS, он рассылает multicast-запрос по LLMNR или NBT-NS. Responder перехватывает эти запросы, представляется целевым ресурсом и получает NTLMv2-хеш аутентификации. Первый хеш приходит обычно через 30-90 секунд - достаточно, чтобы кто-то обратился к несуществующей share или опечатался в имени сервера. С точки зрения OPSEC: Responder в режиме --analyze позволяет сначала посмотреть, какие запросы летят в сегменте, и только потом включить отравление для конкретных целей. На практике я всегда начинаю с --analyze - минута пассивного наблюдения экономит часы на разгребание последствий.

Параллельно - Password Spraying (T1110.003, Credential Access). Один пароль (Company2026!, Welcome1, Qwerty123) по всем обнаруженным учёткам. По данным PT Dephaze, логины нашлись у 96% компаний - имена пользователей лежат в LDAP, в SMB-сессиях, в перечислении через enum4linux или Kerbrute. Порог блокировки обычно 5 попыток - spray делается по одному паролю с интервалом, ниже порога. Atomic Red Team предлагает три теста для T1110.003: через cmd, DomainPasswordSpray (PowerShell) и LDAP-запросы к DC. На реальном engagement PowerShell-модуль DomainPasswordSpray удобнее - он автоматически учитывает lockout policy.

AS-REP Roasting. Учётки с флагом DONT_REQUIRE_PREAUTH позволяют запросить зашифрованный AS-REP без знания пароля. Встречается реже, чем Kerberoastable SPN, но проверяется GetNPUsers.py за секунды - грех не попробовать.

Минуты 4–9: Kerberoasting и privilege escalation​

Имея любую доменную учётку - даже с правами обычного пользователя - атакующий переходит к Kerberoasting (T1558.003, Credential Access). Суть: запрос Kerberos TGS-тикета для учёток с зарегистрированным ServicePrincipalName. Тикет зашифрован хешем пароля сервисной учётки и ломается оффлайн без единого события failed logon.
Atomic Red Team для T1558.003 включает три теста: через setspn -T [I] -Q [/I]/* (cmd), Rubeus (PowerShell) и запрос сервисных тикетов через стандартный PowerShell. На engagement-е setspn даёт быстрый fingerprinting Kerberoastable-учёток без загрузки стороннего тулинга - работает из коробки, не палится.

Почему это до сих пор работает? Сервисные учётки - вечная боль AD. Пароли не ротируются годами (часто со времени создания учётки), сложность минимальная - "а вдруг сервис сломается при смене", - и нередко эти учётки имеют привилегии Domain Admin или входят в группы с расширенными правами. По данным PT Dephaze, пароли в открытом виде обнаружены в 77% организаций. Для сервисных учёток ситуация, как правило, ещё хуже.

Evasion-нюанс: Kerberoasting с запросом RC4-тикета (etype 0x17) - классика, которую ловят Sigma-правила. Запрос AES-тикета снижает детектируемость, но взлом занимает значительно дольше. На engagement-е с 13-минутным таймером - RC4, потому что скорость важнее скрытности.

Если пароль сервисной учётки 8-12 символов без спецсимволов - hashcat с GPU справляется за минуты. gMSA (Group Managed Service Account) с автоматической 120-символьной ротацией делает Kerberoasting бессмысленным, но gMSA в реальных инфраструктурах встречается значительно реже, чем должна. На одном проекте из пятнадцати, если повезёт.

Минуты 9–13: lateral movement и захват домена​

Скомпрометированная сервисная учётка с привилегиями открывает путь к Pass the Hash (T1550.002, Lateral Movement). NTLM-хеш используется для аутентификации на других хостах без знания пароля в открытом виде.
Atomic Red Team для T1550.002: тесты через Mimikatz (sekurlsa::pth), CrackMapExec и Invoke-WMIExec. CrackMapExec удобнее для массовой проверки - одна команда показывает, где хеш принимается и какие share доступны. Зелёненькие строчки с (Pwn3d!) в выводе - лучшее зрелище на engagement-е.

Если SMB signing не enforced (а это ошибка конфигурации, которая по данным PT встречается вдвое чаще уязвимостей ПО) - relay-атаки через ntlmrelayx открывают путь вообще без взлома хеша. Тупо пробросить аутентификацию на другой хост.

Финальный шаг - DCSync. Учётка с правами Directory Replication (DS-Replication-Get-Changes + DS-Replication-Get-Changes-All) запрашивает репликацию у контроллера домена. DC штатно отвечает хешами всех учёток, включая krbtgt. Такие права часто оказываются у сервисных учёток SCCM, Exchange, бэкап-агентов - и получаются через ACL abuse (GenericAll, WriteDACL) или напрямую через компрометацию этих сервисов.

Дальше - Golden Ticket через krbtgt-хеш, полная persistent-компрометация домена. 13 минут истекли.

Почему конфигурации убивают быстрее уязвимостей​

Отчёт PT Dephaze фиксирует контринтуитивное соотношение: организации вкладываются в vulnerability management и patching, но 56% компрометаций строятся на действующих учётных данных, а не на CVE.


Positive Technologies формулируют прямо: "Потенциально полезные для атакующего данные сохраняются в разных компонентах инфраструктуры: в конфигурациях, служебных файлах, системных хранилищах, памяти процессов». Microsoft в документации по защите AD (Windows Server security best practices) описывает ту же проблему: permanently privileged accounts, signing in to privileged accounts on unsecured computers, configuring local privileged accounts with the same credentials across all systems - и рекомендует least-privilege administrative model. Рекомендациям много лет. 60% компаний по-прежнему компрометируются.

По данным Lepide (State of Identity Data Security 2026), 80% организаций имели административные привилегии, назначенные через непрямое или унаследованное членство в группах. Это не уязвимость ПО - это архитектурная проблема, которую не закрывает ни один сканер. BloodHound покажет эти пути за минуту, а вот чистить их - работа на месяцы.

Время обнаружения атаки: Sigma-правила для ключевых TTPs​

(Impacket) может не генерировать стандартный Logon Type 9. Рабочая стратегия - корреляция нескольких слабых сигналов в окне 5-10 минут: LDAP-запрос на перечисление SPN + TGS-запрос с нетипичным etype + lateral auth с нового IP на хост, к которому учётка раньше не обращалась. Если SIEM умеет строить такие цепочки - 13 минут превращаются в детект на 5-й минуте.

Ручной разбор алертов в 13-минутном окне не работает. Пока аналитик дочитает первый тикет - домен уже сдан. Нужна автоматическая корреляция и response. PT Dephaze и подобные платформы воспроизводят человеческий kill chain за минуты - детект тоже должен работать на этой скорости.

Отчёт PT Dephaze подтверждает то, что любой пентестер знает из практики: AD ломается не через zero-day, а через то, что разбросано по инфраструктуре в открытом виде. Пароли в SYSVOL, сервисные учётки с Domain Admin и паролем из 8 символов, LLMNR в дефолте. 13 минут - скорость сбора того, что лежит на поверхности, а не скорость сложной многоэтапной атаки.

Для red team-оператора отсюда практический вывод: первые 15 минут внутреннего engagement - Responder, BloodHound и setspn -T [I] -Q [/I]/*. В половине случаев этого хватает для Domain Admin.

Автоматизация меняет расклад. PT Dephaze и аналогичные платформы воспроизводят этот kill chain без участия человека. Для пентестера это не угроза - это сдвиг фокуса. Автопентест закроет то, что находится за 13 минут. Ценность ручного red team - в сценариях с evasion мимо EDR, в кастомных payload-ах, в цепочках через trust boundaries и cloud-гибриды. То, что автоматика пока не умеет.

Кто до сих пор сдаёт отчёты с "обнаружен LLMNR, рекомендуем отключить" без демонстрации полного kill chain от initial access до domain dominance - конкурирует уже не с другими пентестерами, а с автоматизированным сканером. И проигрывает ему по скорости и стоимости. Если хочешь отработать эту цепочку - на HackerLab (ХакерЛаб) есть лаба с этой связкой без EDR в дефолте.