На початку червня 2025 року дослідники Huntress зафіксували інцидент, у якому невідомий зловмисник застосував імовірно згенерований за допомогою великої мовної моделі (LLM) PowerShell-скрипт для систематичної розвідки середовища Active Directory. Паралельно компанія Sygnia опублікувала звіт про хмарну атаку на велику інфраструктуру Amazon Web Services, де ШІ, за оцінкою дослідників, дозволив атакувальнику пройти шлях від початкового доступу до масштабної компрометації за 72 години. Обидва випадки демонструють одну тенденцію: ШІ не створює принципово нових технік, але суттєво пришвидшує виконання вже відомих сценаріїв атак.
Анатомія атаки: від RDP до ексфільтрації
За даними Huntress, ланцюжок атаки розпочався з підключення за протоколом Remote Desktop Protocol (RDP) до доменного сервера Windows із використанням раніше скомпрометованих облікових даних. Зловмисник розмістив інструменти в каталозі C:\ProgramData\ — типовий вибір для маскування, оскільки цей каталог прихований за замовчуванням і доступний для запису.
Центральним елементом став PowerShell-скрипт із характерною назвою «100% Working AD Information Gathering Script – FULLY FIXED», яка сама по собі вказує на ітеративну взаємодію з мовною моделлю. Дослідники Huntress виокремили кілька ознак, що дають підстави припускати генерацію коду за допомогою ШІ:
- Заголовок у стилі ітерацій промптів
- Наявність рядків-заглушок (placeholder strings)
- Надмірно ускладнений код із кількома методами виявлення контролера домену
- Стилізований консольний вивід із використанням кольорів (cyan, green, red, yellow)
- П’ятиступеневий каскадний механізм відкату для забезпечення розвідки
Скрипт охарактеризували як «надзвичайно агресивний» і «шумний». Після виявлення основного контролера домену він збирав дані про користувачів, комп’ютери, групи, організаційні одиниці (OU) та довірчі відносини, зберігаючи результати в проміжний каталог. Показово, що скрипт автоматично генерував файл AD_Report.html — HTML-звіт з інвентаризації Active Directory. На думку Huntress, ця функціональність, найімовірніше, була «корисним доповненням» від LLM, яке атакувальник просто не став видаляти.
Інструменти постексплуатації
Приблизно через 30 хвилин після запуску скрипта розвідки зловмисник перейшов до розгортання додаткових інструментів. Було використано s5cmd — легітимну утиліту для масових файлових операцій — та SharpShares, інструмент на C# для перелічення мережевих ресурсів спільного доступу. Мета — виявлення доступних користувачеві сховищ даних.
На фінальному етапі зібрані дані експортувалися у CSV-файли, архівувалися та надсилалися на віддалений сервер. Увесь процес — від розвідки до ексфільтрації — відповідав класичній схемі «швидкого захоплення» (smash-and-grab), але з прискоренням за рахунок ШІ на етапі створення інструментарію.
Паралельний кейс: хмарна атака на AWS за 72 години
Звіт Sygnia описує окремий інцидент, у якому, за оцінкою дослідників, ШІ-асистована атака на велику середу AWS пройшла шлях від початкового доступу до масштабної компрометації приблизно за 72 години. Мотивацію зловмисника оцінюють як фінансову — доступ до хмарної інфраструктури жертви планувалося використати як важіль для вимагання.
Початковий доступ було отримано через вразливість в інтернет-доступному застосунку, що дозволило витягти ключ доступу до одного з акаунтів AWS. Далі атакувальник діяв за циклічною схемою: кожен новий набір облікових даних запускав повторну розвідку, збір секретів, спроби закріплення (створення ключів доступу та користувачів IAM) й ексфільтрацію. Частину артефактів маскували під пентест або вправу «червоної команди».
Для тиску на жертву застосовувалися деструктивні дії:
- Блокування доступу до кошиків S3
- Встановлення нульової місткості для сервісів і контейнерів ECS
- Створення правил ACL для блокування мережевого доступу
- Очищення черг SQS
Sygnia наголошує: атакувальник не використовував ані нових шкідливих програм, ані вразливостей нульового дня. Усі спостережувані дії відповідали давно відомим технікам. Ключова відмінність — швидкість, із якою кожен новий доступ конвертувався в цілеспрямовані дії: визначення дозволів, доступних ресурсів та оптимальних наступних кроків.
Оцінка впливу: ШІ як мультиплікатор сили
Обидва інциденти об’єднує спільний висновок: ШІ не породжує нових класів атак, але радикально знижує поріг входу та пришвидшує виконання. У випадку з PowerShell-скриптом зловмисник із мінімальними навичками програмування отримав функціональний інструмент розвідки AD, хай навіть і «шумний». У хмарному кейсі швидкість адаптації до нових облікових даних і ресурсів вказує на автоматизацію аналітичних етапів атаки.
Найбільшому ризику піддаються організації з недостатнім моніторингом Active Directory та хмарних середовищ, особливо ті, де:
- RDP-доступ відкритий без багатофакторної автентифікації
- Відсутній моніторинг масових LDAP-запитів до контролерів домену
- Хмарні ключі доступу не ротуються й не обмежені за привілеями
- Немає оповіщень про створення нових користувачів IAM або ключів доступу
Практичні рекомендації
Для захисту Active Directory:
- Налаштувати оповіщення на масові запити перелічення об’єктів AD (користувачі, групи, OU, довірчі відносини) за короткий проміжок часу
- Відстежувати виконання PowerShell-скриптів із нетипових каталогів, зокрема
C:\ProgramData\ - Моніторити появу HTML- та CSV-файлів із характерними назвами (AD_Report, Inventory) у каталогах стейджингу
- Обмежити RDP-доступ із обов’язковим використанням MFA та мережевої сегментації
Для захисту хмарних середовищ AWS:
- Запровадити оповіщення про створення нових користувачів IAM і ключів доступу через CloudTrail
- Налаштувати виявлення аномальних патернів API-викликів: масове перелічення ресурсів, швидка зміна контексту між сервісами
- Застосовувати принцип мінімальних привілеїв до ключів доступу та ролей
- Регулярно перевіряти інтернет-доступні застосунки на предмет витоку секретів і ключів
Обидва розглянуті інциденти показують, що командам захисту необхідно переглянути часові очікування під час реагування: якщо раніше на розвідку та підготовку інструментів у зловмисника йшли дні, то з ШІ-асистуванням цей етап стискається до хвилин. Пріоритетна дія — упевнитися, що правила детектування для масового перелічення об’єктів AD та аномальної активності в хмарних API налаштовані й працюють, а час реагування на відповідні алерти не перевищує 30 хвилин.
