Одиночный хакер взломал AWS за 72 часа с помощью агентного ИИ

Любой технический руководитель, который участвовал в разборе облачного инцидента, знает, как выглядит трёхдневный военный штаб: анализ IAM-логов, ротация ключей, споры о радиусе поражения, заказ очередной порции кофе. А теперь представьте, что атакующий на другой стороне завершает всю кампанию за то же самое время — в одиночку, пока LLM делает всю тяжёлую работу. Именно такой сценарий только что описала компания Sygnia, и он должен пересмотреть все допущения, лежащие в основе текущих AWS-плейбуков реагирования на инциденты.

Единственный финансово мотивированный злоумышленник взломал крупную среду AWS примерно за 72 часа и вымогал деньги у неназванной глобальной компании. Без эксплойтов нулевого дня, без инсайдера, без команды. Только связанные уязвимости и агентный ИИ.

Что произошло

Как сообщило Dark Reading, Sygnia опубликовала исследование, описывающее финансово мотивированное вторжение с использованием агентных ИИ-рабочих процессов для «ускорения разведки жертвы, разработки инструментов атаки, формирования команд и адаптации к конкретной среде». Целью являлся крупный клиент AWS. Результатом стало вымогательство.

Первоначальный плацдарм был банальным. Злоумышленник получил ключ доступа AWS через уязвимость в интернет-приложении. Дальше всё перестало быть банальным. Этот единственный ключ был пропущен через четыре параллельных рабочих процесса, направленных на систематическую кражу секретов, создание бэкдоров и эксфильтрацию данных. Каждый новый обнаруженный credential возвращался через те же четыре процесса, наращивая доступ.

Оценка Sygnia: вторжение «не эксплуатировало единственную неправильную конфигурацию». Вместо этого оно объединяло уязвимости в сервисах приложений, ресурсах AWS, репозиториях исходного кода, CI/CD-конвейерах, компонентах времени выполнения и хранилищах данных. Обнаружение учётных данных, сбор секретов, перечисление облачных ресурсов, злоупотребление deployment-конвейерами, модификация runtime, доступ к базам данных и операционный ущерб — всё это происходило параллельно, а не последовательно.

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

Исследователи пришли к выводу об использовании ИИ, изучив созданные злоумышленником скрипты, артефакты отчётности и колоссальный параллелизм операции. По словам Sygnia, это была работа, которая должна была занять недели, но была сжата до трёх дней одним человеком.

Техническая анатомия

Если убрать ИИ-обёртку, тактика будет знакома всем, кто сопоставлял облачные вторжения с MITRE ATT&CK. Первоначальный доступ через открытое веб-приложение. Доступ к учётным данным. Разведка. Горизонтальное перемещение через CI/CD. Закрепление через бэкдоры. Воздействие через нарушение работы сервисов. Ничего нового в этом списке нет.

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

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

Особого внимания заслуживают воздействующие действия. Установка желаемого количества ECS в ноль, очистка SQS-очередей, навешивание deny ACL на подсети — всё это легитимные операционные команды. Они находятся в рамках стандартной поверхности API. Они не сработают на сигнатуре вредоносного ПО. Они выглядят вредоносными только в совокупности — и только если кто-то следит за совокупностью.

Ави Даян, вице-президент по реагированию на инциденты в 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 как полноценную поверхность атаки. Злоупотребление конвейером было одной из связанных уязвимостей. Относитесь к build-раннерам как к продакшену и логируйте каждое получение учётных данных.
• Создавайте детекты для совокупных воздействующих действий, а не только для отдельных событий. Изменение IAM-политики плюс масштабирование ECS до нуля плюс очистка SQS в течение одного часа — это сигнатура кампании, а не три отдельных тикета.
• Заранее авторизуйте сдерживание. Если ваш runbook говорит «уведомить дежурного, затем отключить IAM-пользователя», уберите промежуточный шаг для сигналов высокой достоверности. Тезис Даяна о менее чем минуте — это и есть весь аргумент.
• Специально отрабатывайте сценарий вымогательства. Проведите tabletop-учение для момента, когда кто-то блокирует ваши S3-бакеты и требует криптовалюту. Юридическая служба, PR и инженеры — все должны иметь мышечную память.

Ничего из этого не является экзотикой. Это скучная версия правильно выстроенной облачной безопасности. Проблема в том, что «правильно» теперь имеет значительно более короткий дедлайн.

Ключевые выводы

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