Одинокий зловмисник зламав AWS за 72 години за допомогою агентного ШІ

Кожен, хто хоч раз вів «воєнну кімнату» при хмарному інциденті, знає, як виглядають ці три доби: витягувати логи IAM, ротувати ключі, сперечатися про масштаб ураження, замовляти каву. А тепер уявіть, що зловмисник на іншому боці завершує всю кампанію за той самий час — поодинці, поки LLM виконує всю важку роботу. Саме таку картину описала Sygnia, і це має змусити переглянути кожне поточне припущення в інцидент-плейбуках для AWS.

Один фінансово мотивований зловмисник зламав великий AWS-середовище приблизно за 72 години та вимагав гроші у невідомого глобального підприємства. Без zero-day, без інсайдера, без команди. Лише ланцюжок вразливостей та агентний ШІ.

Що сталося

Як повідомляє Dark Reading, Sygnia опублікувала дослідження, в якому описала фінансово мотивоване вторгнення з використанням агентних ШІ-робочих процесів для «прискорення розвідки жертви, розробки інструментів атаки, формування команд та адаптації до конкретного середовища». Ціллю був великий клієнт AWS. Результат — вимагання.

Первинне проникнення було банальним. Зловмисник отримав ключ доступу AWS через вразливість в інтернет-орієнтованому застосунку. Далі все перестало виглядати банально. Цей єдиний ключ було передано через чотири паралельні робочі процеси, спрямовані на систематичну крадіжку секретів, створення бекдорів і ексфільтрацію даних. Кожен новий здобутий обліковий запис знову потрапляв до тих самих чотирьох процесів, розширюючи доступ.

За оцінкою Sygnia, вторгнення «не експлуатувало жодної окремої хибної конфігурації». Натомість воно ланцюжком пов'язувало вразливості застосунків, ресурсів AWS, репозиторіїв вихідного коду, CI/CD-пайплайнів, компонентів середовища виконання та сховищ даних. Виявлення облікових даних, збір секретів, перелік хмарних ресурсів, зловживання пайплайнами розгортання, модифікація середовища виконання, доступ до баз даних та операційні порушення — все це відбувалося паралельно, а не послідовно.

Щоб примусити до оплати, зловмисник застосував оборотні дії впливу як демонстрацію можливостей: заборону доступу до S3-бакетів, встановлення нульової місткості для ECS-сервісів або контейнерів, створення ACL-правил для блокування мережевого доступу та очищення SQS-черг. Оборотно, але гучно. Послання жертві було простим: платіть зараз, або наступний раунд буде руйнівним.

До висновку про використання ШІ дослідники дійшли, вивчивши створені зловмисником скрипти, артефакти звітності та надзвичайний паралелізм операції. За словами Sygnia, це була робота, яка мала б тривати тижні, але одна людина стиснула її до трьох днів.

Технічна анатомія

Якщо прибрати ШІ-обгортку, методи атаки знайомі кожному, хто картографував хмарні вторгнення за MITRE ATT&CK. Первинний доступ через відкритий вебзастосунок. Доступ до облікових даних. Розвідка. Горизонтальне переміщення через CI/CD. Закріплення через бекдори. Вплив через порушення роботи сервісів. Нічого нового в цьому списку немає.

Новим є темп та коефіцієнт розгалуження. Людина-пентестер, що працює самостійно, обирає один шлях, тестує його, повертається назад у разі невдачі й рухається далі. Агентний робочий процес не потребує такого вибору. Він може запустити чотири процеси проти одного ключа доступу, паралельно оцінювати результати та адаптувати скрипти до того, що виявить у середовищі, на льоту. Sygnia особливо виділила «адаптацію до конкретного середовища» — саме ця частина раніше вимагала досвідченого оператора, який вручну читав логи та переписував пейлоади.

Важливий також патерн ланцюжка вразливостей. Більшість хмарних засобів виявлення досі орієнтуються на аномалії з одним сигналом: один неможливий вхід з незвичного місця, одна нетипова зміна IAM-політики, один S3-бакет, що став публічним. Інженерія виявлення припускає, що дії зловмисника розділені хвилинами або годинами, бо людина думає між кроками. Коли LLM оркеструє кампанію, збір облікових даних, зловживання пайплайном і підготовка даних можуть відбутися в одному вікні алертів, тому логіка кореляції, яка розраховує на часовий інтервал, пропускає всю картину.

Дії впливу заслуговують окремої уваги. Встановлення бажаного числа ECS на нуль, очищення SQS-черг, накладання заборонних ACL на підмережі — все це легітимні операційні команди. Вони знаходяться в межах нормального API. Вони не спрацьовують на сигнатурах шкідливого ПЗ. Вони виглядають зловмисно лише в сукупності, і тільки якщо хтось стежить за сукупністю.

Аві Даян, VP з реагування на інциденти у Sygnia, чітко сформулював операційну суть для Dark Reading: «Якщо ШІ-інструмент може здійснити прорив або ексфільтрувати дані менш ніж за хвилину, команда безпеки, що покладається на тріаж SIEM-алертів із участю людини, завжди програватиме». Він стверджує, що MTTD та MTTR «мають суттєво скоротитися», коли LLM залучені до атаки. Мій висновок: більшість SOC, які я бачив у сферах iGaming та фінтех, мають цикли тріажу хмарних алертів від 15 до 45 хвилин. Це вже виходить за межі вікна, яке описує Даян.

Хто постраждає

Під загрозою знаходиться будь-яка команда, що керує великою AWS-інфраструктурою з інтернет-орієнтованим прикладним рівнем, але деякі категорії є більш вразливими. Оператори iGaming, платіжні процесори та криптобіржі мають однаковий некомфортний профіль: розгалужені AWS-акаунти, агресивний CI/CD, сховища даних із високою цінністю та бізнес, який буквально не може терпіти збоїв S3 або очищення SQS у пікові години. Тактика тиску, описана Sygnia — оборотний вплив як інструмент вимагання, — найболісніше б'є по бізнесу, де година простою вимірюється шестизначними сумами.

Фінтех-платформи несуть додаткову проблему. Регулятори не цікавляться, чи заблокував ваш S3-бакет зловмисник чи ваша власна команда. Інцидент конфіденційності або доступності все одно є звітним у більшості європейських нормативних актів. Команди з реагування на інциденти, з якими я працював, вже зараз ледь встигають із збором доказів за DORA. Додайте зловмисника, який стискає тижні активності до 72 годин, і форензична часова шкала стає майже неможливою для відновлення після факту.

Оператори Ad-tech та SaaS із великою кількістю даних знаходяться в іншому квадранті болю. Ексфільтрація є основною загрозою, а звіт Sygnia описує систематичну ексфільтрацію як один із чотирьох процесів. Якщо ваша бізнес-модель спирається на пропрієтарні набори даних або власні аудиторні графи, зловмисник, який може перелічити, підготувати та витягти дані в одному безперервному спалаху, зруйнував припущення, що ексфільтрація є досить повільною, щоб перехопити її на льоту.

Некомфортний висновок: ця атака була справою однієї людини. Не держави, не здирницького угруповання з HR-відділом. Якщо бар'єр для запуску цього плейбука тепер — «доступ до потужного LLM та помірні знання AWS», кількість реальних потенційних зловмисників щойно зросла на порядок. Кожна середня компанія, яка вважала себе надто нецікавою для цільової атаки, має переглянути цю математику.

Плейбук для команд безпеки

Власні рекомендації Sygnia є правильною відправною точкою: підтримувати вичерпну видимість активів та ідентифікаторів, посилювати засоби контролю безпеки ідентифікації, захищати хмарні та девелопмент-середовища, впроваджувати багаторівневі засоби захисту, автоматизувати критичні процеси виявлення та реагування, а також встановлювати наперед визначені процедури стримування, які виконуються негайно після виявлення зловмисної активності. Прочитайте останнє двічі. «Негайно» означає відсутність кроку погодження з людиною для першої дії стримування.

Конкретні кроки на цього тижня:

• Перевірте кожен інтернет-орієнтований застосунок на наявність шляхів, які можуть витікати ключ доступу AWS. Первинне проникнення в цьому випадку здійснено через ключ, відкритий через вразливість вебзастосунку, що безпосередньо відповідає категоріям у OWASP Top Ten. Вважайте, що будь-який довгоживучий статичний ключ AWS, доступний з периметру, вже скомпрометований.
• Усуньте довгоживучі ключі там, де це можливо. Перейдіть на короткоживучі облікові дані через IAM Roles Anywhere, IRSA або федерацію ідентифікаторів навантаження. Якщо ключ не може існувати, його не можна ексфільтрувати.
• Інструментуйте CI/CD як першокласну поверхню атаки. Зловживання пайплайном було однією з ланцюжкових вразливостей. Ставтеся до збірочних раннерів як до продакшну та логуйте кожен запит облікових даних.
• Пишіть детектори для сукупних дій впливу, а не лише для окремих подій. Зміна IAM-політики плюс масштабування ECS до нуля плюс очищення SQS протягом однієї години — це сигнатура кампанії, а не три окремих тікети.
• Наперед авторизуйте стримування. Якщо у вашому рунбуку написано «повідом чергового, потім відключи IAM-користувача», усуньте проміжний крок для сигналів із високою достовірністю. Аргумент Даяна про менш ніж хвилину — це весь доказ.
• Окремо відпрацьовуйте сценарій вимагання. Програйте момент, коли хтось блокує ваші S3-бакети та вимагає криптовалюту. Юридична служба, PR та інженерія — всі мають напрацювати м'язову пам'ять.

Нічого екзотичного тут немає. Це нудна версія хмарної безпеки, виконана належним чином. Проблема в тому, що «належним чином» тепер має набагато коротший дедлайн.

Ключові висновки

• Одинокий зловмисник зламав великий AWS-середовище приблизно за 72 години, використовуючи агентні ШІ-процеси, за даними Sygnia, і успішно вимагав гроші у глобального підприємства.
• Вторгнення ланцюжком пов'язувало вразливості застосунків, ресурсів AWS, репозиторіїв, CI/CD, середовища виконання та сховищ даних, а не експлуатувало одну хибну конфігурацію.
• Оборотні дії впливу (блокування S3, масштабування ECS до нуля, ACL-блоки, очищення SQS) використовувалися як інструмент вимагання без спрацьовування сигнатур шкідливого ПЗ.
• Вікна MTTD та MTTR, побудовані навколо тріажу SIEM-алертів людиною, структурно надто повільні, коли LLM оркеструють сторону атаки.
• Пріоритетні захисні кроки: усунути довгоживучі ключі AWS, зміцнити CI/CD, корелювати сукупні сигнали впливу та наперед авторизувати дії стримування.