Статья AI-Generated PowerShell Active Directory разведка: от промпта до карты домена

3 июня 2026 года аналитики Huntress задокументировали атаку на доменный Windows Server. Злоумышленник зашёл через RDP по украденным учёткам и за считанные минуты собрал полную карту Active Directory - пользователей, группы, OU, трасты, подсети - упаковал в ZIP для эксфильтрации. Инструмент - не BloodHound, не SharpHound, не PowerView. Одноразовый PowerShell-скрипт Untitled1.ps1 с заголовком "100% Working AD Information Gathering Script – FULLY FIXED". По всем признакам - сгенерирован через LLM. Первый публично задокументированный случай использования AI-generated PowerShell для AD-разведки в реальной атаке. И он показывает простую вещь: генеративный AI не изобретает новых техник, но убивает сигнатурный детект и радикально снижает порог входа для оператора.

Бизнес-логика атаки: зачем атакующему карта AD​

Разведка Active Directory - подготовительный этап, а не финальная цель. Полная карта домена нужна для трёх сценариев. Подробнее - в нашем обзоре безопасность llm атаки.

Первый - ransomware-деплой. Списки групп и трастов показывают, где Domain Admins, какие OU содержат критичные серверы, через какие trust-отношения можно перепрыгнуть на смежные домены. Второй - хищение данных: перечисление компьютеров плюс сетевые шары (в этом инциденте дополнительно запускался SharpShares) строят маршрут к чувствительным файлам. Третий - продажа доступа: для Initial Access Broker полная карта AD ощутимо поднимает цену "лота" на даркнет-маркете.

По данным CrowdStrike Global Threat Report 2025, 75% вторжений начинаются с действительных учётных данных. Среднее время до lateral movement - 62 минуты, рекорд - 51 секунда. Разведка AD занимает первые минуты этого окна. Согласно IBM X-Force Threat Intelligence Index 2025, рост атак через действительные учётные данные составил 71% год к году, а ежедневно в dark web появляется порядка шести тысяч свежих учёток. Карта AD - конвейер, превращающий одну утечку пароля в полноценную компрометацию домена.

[Применимо: внутренний пентест, grey box / компрометация учётных данных]

Инцидент Huntress: AI-скрипт в цепочке атаки на Active Directory​

Цепочка атаки в маппинге MITRE ATT&CK:

1. Resource Development - создание инструмента через LLM (T1588.007, Artificial Intelligence). Атакующий, судя по артефактам в коде, итеративно промптил модель до получения рабочего скрипта
2. Initial Access - скомпрометированные учётные данные плюс предположительно VPN -> RDP на доменный Windows Server
3. Execution - запуск Untitled1.ps1 через несколько минут после начала RDP-сессии (T1059.001, PowerShell). Скрипт лежал в C:\ProgramData\ - типичный каталог для стейджинга
4. Discovery - перечисление доменных пользователей (T1087.002), групп (T1069.002), трастов (T1482), компьютеров (T1018)
5. Collection - экспорт в CSV плюс HTML-отчёт, архивирование в ZIP в каталоге C:\AD_Reports_
6. Exfiltration - примерно через 30 минут запущен s5cmd.exe, легитимный CLI для Amazon S3, который Huntress регулярно фиксирует как инструмент кражи данных
7. Дополнительная Discovery - SharpShares.exe для поиска доступных сетевых шар

AI-генерированный скрипт - не метод initial access. Это инструмент пост-эксплуатации, развёрнутый после того, как атакующий уже оказался внутри. Блокировка скрипта полезна, но настоящая точка предотвращения - MFA на RDP/VPN и контроль учётных данных. Аналитики Huntress формулируют прямо: "AI не меняет правила игры. Базовая цепочка атаки по-прежнему выглядит как проверенный smash-and-grab, который мы наблюдаем годами. Методология осталась прежней, но теперь она выборочно усилена AI".

Признаки LLM-генерации в PowerShell-коде​

Huntress выделил конкретные маркеры, по которым скрипт классифицирован как AI-генерированный. Те же паттерны я наблюдаю при генерации AD-разведочных скриптов через ChatGPT и Claude на тестовых стендах.

Заголовок в стиле "наконец-то заработало". Строка "100% Working AD Information Gathering Script – FULLY FIXED" - артефакт итеративной отладки. Оператор копировал ошибки обратно в чат, модель правила код, заголовок финальной версии отражает этот цикл. В индустрии это называют "vibe coding" - описываешь задачу на естественном языке, получаешь код, скармливаешь ошибки обратно и так по кругу. Человек, который сам пишет инструмент, так файл не назовёт.

Избыточная цепочка фоллбэков для поиска DC. Скрипт последовательно применял пять методов обнаружения контроллера домена: DNS-запрос, nltest, модуль Active Directory PowerShell, переменные окружения и захардкоженный фоллбэк. Huntress формулирует прямо: "Пять различных методов поиска Domain Controller кричат об AI-генерации. Человек выбрал бы один-два надёжных метода. LLM при инструкции "make sure it doesn't fail" исчерпывающе генерирует каждый метод из своих обучающих данных". Пять способов найти DC - это как пять замков на одной двери. Паранойя, но не человеческая.

Плейсхолдер, переживший copy-paste. В фоллбэк-блоке обнаружения DC осталось значение $dc = "Server1.HR.local" - буквальный пример из обучающих данных модели. Оператор скопировал скрипт из чата без редактирования. Переменная сработала бы только при отказе всех четырёх предшествующих методов, поэтому, скорее всего, никогда не вызывалась. Но она осталась в деплое - яркий индикатор бездумного ctrl+c ctrl+v из AI-чата.

Радуга цветов в консоли. Избыточный цветной вывод через Write-Host - cyan, green, red, yellow - привычка LLM быть полезной. Аналитики Huntress иронизируют: "LLM обожают украшать консольный вывод. Общая черта AI, пытающегося выглядеть helpful для того, кто его промптит". Красиво, но в боевой операции никому не нужно.

Незапрошенный HTML-отчёт. Финальная фаза скрипта генерировала форматированный HTML-отчёт - с высокой вероятностью оператор этого не просил. Huntress прямо указывает: "Зачем атакующему красивый HTML-отчёт? Это helpful-инъекция LLM, с которой оператор просто согласился, вместо того чтобы удалить". На стендах я наблюдаю аналогичное: ChatGPT особенно склонен добавлять "полезные" визуализации и форматирование, которых никто не просил. Claude в этом плане компактнее. Локальные модели типа WizardCoder генерируют менее стабильный код, зато промпты не уходят в облачный сервис - для OPSEC это существенно.

AI-скрипты vs BloodHound и PowerView при разведке Active Directory​

На внутренних пентестах я параллельно использую BloodHound, SharpHound, PowerView, ADRecon и AI-генерацию одноразовых скриптов. Ниже - сравнение, основанное на практике и данных инцидента Huntress.

Критерий	AI-генерированный скрипт	BloodHound / SharpHound	PowerView
Сигнатурный детект	Нет хеша в базах, нет репутации файла	Бинарь детектируется CrowdStrike Falcon, SentinelOne, Elastic 8.x+	Частично - зависит от обфускации и версии
Поведенческий детект	Стандартные LDAP-запросы, Event ID 4104	Характерный LDAP-профиль к BloodHound-объектам	AD-cmdlets, менее уникальный профиль
Порог входа для оператора	Низкий: промпт на естественном языке	Средний: нужно понимать графовую модель AD	Средний-высокий: PS-синтаксис + AD-модель
Кастомизация	Высокая: новый промпт = новый скрипт	Низкая: фиксированный коллектор, custom queries	Высокая: модульный подход
Стабильность вывода	Нестабильная: LLM галлюцинирует параметры	Стабильная: детерминированный вывод	Стабильная: документированные cmdlets
OPSEC-профиль	Нет IoC на диске, но шумный (массовые запросы)	Высокий IoC-профиль бинарья	Средний: зависит от загрузки модуля
Анализ путей привилегий	Нет - плоские CSV	Да - shortest path to DA, визуализация	Нет - сырые данные без графа

Grey box сценарий - типичная ситуация на реальном пентесте: выданы учётные данные low-privileged пользователя домена. Классический подход: загрузить SharpHound, запустить Invoke-BloodHound -CollectionMethod All, проанализировать shortest path to DA в BloodHound GUI. С AI-подходом (vibe coding): описать задачу LLM на естественном языке, скопировать вывод на хост, запустить. AI экономит 15-20 минут на генерацию скрипта, но добавляет 5-10 минут на отладку - несуществующие параметры cmdlets, сломанные pipeline, неправильные типы объектов. А главное - BloodHound за те же 20 минут покажет визуализацию attack paths от текущего пользователя до Domain Admin. AI-скрипт выдаст плоские CSV, которые придётся разгребать вручную или скармливать другому инструменту.

Ограничения AI-генерированных скриптов разведки AD​

Работает если:

• Доступ к доменному хосту с учётными данными доменного пользователя
• PowerShell доступен (нет блокировки AppLocker/WDAC)
• LDAP-запросы к DC не ограничены сетевыми политиками или firewall

Не работает если:

• Constrained Language Mode включён - AD-cmdlets типа Get-ADUser, Get-ADGroup недоступны
• AMSI активен и не обойдён - CrowdStrike Falcon и Windows Defender анализируют скрипт до выполнения. AI-генерированный код без маркерных строк может пройти статический анализ AMSI, но поведенческие правила на массовое перечисление AD-объектов всё равно сработают
• Just Enough Administration (JEA) настроен - ограничивает набор доступных cmdlets до явно разрешённых
• Tiered administration model - с Tier 1 хоста нет прямого LDAP-доступа к DC
• EDR с поведенческими правилами - CrowdStrike Falcon и SentinelOne детектируют Get-ADUser -Filter * независимо от хеша скрипта. Elastic 8.x+ с kernel ETW-TI фиксирует аномальные LDAP-запросы на уровне ядра

Детект AI-генерированных скриптов: поведенческий анализ Active Directory​

Huntress формулирует чётко: "AI может изменять синтаксис кода, но не может изменить фундаментальную механику перечисления Active Directory". Механика - LDAP-запросы, вызовы PS-cmdlets, создание файлов на диске. Всё это логируется одинаково, независимо от авторства скрипта. Подход "попробовать опознать AI-генерированный код" - тупиковый. На уровне рантайма AI-скрипт и ручной скрипт неотличимы. Детектировать нужно не происхождение кода, а его поведение.

Event ID 4104 и правила SIEM​

Event ID 4104 из лога Microsoft-Windows-PowerShell/Operational - ключевой forensic-контроль в этом инциденте. Через PowerShell Script Block Logging Huntress полностью восстановил содержимое удалённого скрипта.

Требования к окружению для включения логирования:

• Windows Server 2016+ или Windows 10+
• GPO: Computer Configuration -> Administrative Templates -> Windows Components -> Windows PowerShell -> Turn on PowerShell Script Block Logging -> Enabled
• Дополнительно: включить Module Logging и PowerShell Transcription
• Логи направлены в SIEM из Microsoft-Windows-PowerShell/Operational

Если Script Block Logging не включён - forensic-данные инцидента теряются полностью. Huntress смог восстановить скрипт только потому, что логирование было активным. Без него - дыра.

Поведенческие индикаторы, единые для AI-генерированных и ручных скриптов разведки AD:

1. Массовые AD-запросы - Get-ADUser -Filter [I], Get-ADComputer -Filter [/I], Get-ADGroup -Filter * в промежутке 2-5 минут. В штатном административном workflow такие запросы не появляются пачкой
2. Массовый экспорт в CSV - создание CSV с данными пользователей, групп, OU в нетипичном каталоге (C:\ProgramData\, C:\AD_Reports_)
3. Архивирование после разведки - вызов Compress-Archive или System.IO.Compression непосредственно после AD-запросов
4. Цепочка Event ID - 4104 (Script Block) -> 4688 (Process Creation для дочерних процессов) → возможно 5145 (доступ к сетевым шарам, если следом запускается SharpShares)

# Пример для демонстрации концепции - адаптировать под конкретный SIEM
# Условие: 3+ AD-enumeration cmdlets за 5 мин от одного пользователя
EventID = 4104
ScriptBlock contains ANY OF (
  "Get-ADUser", "Get-ADComputer", "Get-ADGroup",
  "Get-ADTrust", "Get-ADOrganizationalUnit"
)
COUNT(distinct cmdlet) >= 3 WITHIN 5min
GROUP BY SourceHostname, UserName -> ALERT

Вендор-специфика детекта:

• CrowdStrike Falcon - стандартные IOA-правила покрывают массовое AD-перечисление через PS-cmdlets. Поведенческий профиль срабатывает независимо от имени файла или хеша
• SentinelOne - Deep Visibility позволяет построить query по EventType = "Script Block Logged" с фильтрацией по AD-cmdlets и подсчётом уникальных вызовов за окно
• Elastic 8.x+ - EQL-правила модулей windows.discovery.* перехватывают паттерны LDAP-разведки, включая нестандартные скрипты без известных сигнатур

Чеклист: защита Active Directory от AI-автоматизированных скриптов​

Формат для передачи сисадмину или включения в отчёт по результатам пентеста:

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Пункт 4 - не рекомендация, а обязательный контроль. По данным Verizon DBIR 2025, 38% утечек данных связаны с кражей учётных данных.

На каждом втором внутреннем пентесте я генерирую через LLM одноразовые PowerShell-скрипты для AI-автоматизации разведки AD - параллельно с BloodHound. Честный вывод за полтора года экспериментов: AI экономит 15-20 минут на создание кастомного скрипта, но добавляет время на отладку LLM-галлюцинаций (несуществующие параметры, сломанные pipeline - каждый раз). И каждый раз, когда смотрю на сгенерированный Write-Host с радугой цветов, думаю: Defender детектирует этот скрипт не потому, что он AI-генерированный, а потому что Get-ADUser -Filter * в Event ID 4104 - тот же алерт, что и при ручном скрипте, что и при SharpHound.

Индустрия сейчас увлечена нарративом "AI-угрозы", но реальная проблема уровнем ниже - 75% вторжений начинаются с украденных учётных данных при отсутствии MFA на RDP. Скрипт Untitled1.ps1 не оказался бы на сервере, если бы сессия требовала второй фактор и conditional access. Не AI делает атаки успешными - базовые гигиенические контроли по-прежнему отсутствуют в половине корпоративных сред, и генеративный AI просто ускоряет последствия этого отсутствия. По данным CrowdStrike, вредоносное использование GenAI удвоилось за 2024 год - удвоилось количество попыток, не количество принципиально новых TTP. Vibe coding снижает порог входа для оператора, но не меняет механику, а значит, поведенческий детект работает ровно так же, как и до эпохи LLM. Если хотите не разбирать такие цепочки в чужих отчётах, а проходить их на стенде от разведки до контроля домена - курс "Анализ защищённости Active Directory" на codeby.academy (Codeby Academy — Академия Кодебай это сильнейшая команда по информационной безопасности в России.) построен именно на grey box сценариях с актуальными средствами детекта.