ИИ-агенты похитили тысячи учётных данных — атаке хватило шести часов

8 сентября 2026 года Google Threat Intelligence Group опубликовала отчёт об атаке, которую Mandiant наблюдала во втором квартале: предполагаемый финансово мотивированный злоумышленник захватил облачную инфраструктуру неназванной организации и развернул там автономную многоагентную систему. В отчёте Google Threat Intelligence Group сказано, что на планирование, сборку и запуск массового сбора учётных данных ушло менее шести часов, а система скомпрометировала тысячи сторонних учётных данных.

ИИ-агенты автоматически управляли сканированием уязвимостей, устраняли рабочие ошибки в реальном времени и меняли IP-адреса без ручного вмешательства. При этом начальный доступ уже был получен до запуска системы: Google не утверждает, что ИИ самостоятельно выполнил всю атаку от первого проникновения до кражи данных.

Как развивалась шестичасовая атака

Плацдармом стала уже захваченная облачная среда организации. Она дала атакующему вычислительные ресурсы и позволила направлять вредоносный трафик через легитимные IP-адреса жертвы, затрудняя отделение атаки от обычной облачной активности по одному лишь происхождению соединений.

Для создания системы злоумышленник использовал чат-бота для написания кода, исходный запрос и набор инструкций для агентов. Как уточняет технический разбор The Hacker News, заранее подготовленные файлы Markdown служили рабочими сценариями для автоматического сканирования и сбора учётных данных.

1. Злоумышленник получает контроль над облачной инфраструктурой организации.
2. В захваченной среде собирается многоагентная система с инструкциями и операционными сценариями.
3. Агенты запускают массовое сканирование сторонних систем и поиск учётных данных.
4. Система обрабатывает ошибки, повторяет операции и меняет используемые IP-адреса.
5. Обнаруженные учётные данные собираются для дальнейшего использования.

В том же отчёте описан отдельный комплекс Recon с панелью для управления более чем 23 800 собранными секретами. Google не связывает это число напрямую с шестичасовой кампанией, поэтому для неё корректна более широкая формулировка: скомпрометированы тысячи сторонних учётных данных.

Почему ручное реагирование оказалось слишком медленным

Автоматическое сканирование само по себе не ново. Отличие этой кампании — в способности агентов поддерживать работу конвейера при изменении условий: исправлять сбои, повторять неудачные операции и переключать сетевые адреса, не дожидаясь решения оператора.

Для защитников задержки складываются последовательно: оповещение попадает в очередь, аналитик проверяет контекст, находит владельца ресурса и согласует изоляцию. Атакующая система в это время может параллельно продолжать сканирование. публикация SiliconANGLE подтверждает, что устранение ошибок и ротация IP-адресов шли без оператора, а трафик исходил из инфраструктуры самой жертвы.

Шесть часов — продолжительность конкретного наблюдавшегося развёртывания, а не универсальный норматив для будущих атак. Однако эпизод показывает, что проверка сигнала в следующую смену уже может начаться после массового сбора данных. Для критичных событий необходимы заранее утверждённые способы временной изоляции, не требующие полного расследования и окончательной атрибуции.

Какие признаки искать в облачных журналах

Отдельной записи с пометкой «ИИ-агент» в журналах не появится. Автономность проявляется через сочетание скорости, параллельных действий, повторных запусков после ошибок и быстрой смены сетевого поведения. Поэтому события уровня управления облаком, рабочих нагрузок, сети и доступа к секретам нужно сопоставлять в общей временной последовательности.

• Управление облаком: нетипичный вход, за которым следуют запуск вычислительных ресурсов, создание служебных учётных записей, выдача ролей, выпуск ключей или изменение сетевых правил.
• Сетевая телеметрия: резкий рост исходящих соединений к множеству внешних узлов, однотипные короткие запросы, смена адресов и быстрое возобновление активности после блокировок.
• Журналы рабочих нагрузок: незнакомые процессы и файлы инструкций, параллельные задания сканирования, серии ошибок и немедленные повторные запуски с изменёнными параметрами.
• IAM и хранилища секретов: массовое чтение токенов, ключей и переменных окружения новой рабочей нагрузкой, а затем применение одного секрета из нескольких необычных сред.
• Конвейеры разработки: новые задания, неожиданные обращения к секретам сборки и действия с репозиториями или артефактами от имени ранее не использовавшейся учётной записи.

Наиболее показателен не одиночный порог, а цепочка событий: новая роль или ключ, запуск ресурса, широкий исходящий трафик и чтение секретов в коротком интервале. Пороговые значения следует сравнивать с обычным профилем конкретной учётной записи и нагрузки, иначе интенсивный легитимный процесс будет неотличим от атаки.

Что можно остановить до завершения расследования

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

Минимальные права сокращают возможный масштаб даже после захвата нагрузки. Если её функция не требует иного, одна учётная запись не должна одновременно создавать ресурсы, читать секреты и изменять сетевые настройки. Краткоживущие секреты, привязанные к конкретному заданию конвейера, также уменьшают ценность похищенного ключа вне исходного контекста.

Название пострадавшей организации, способ первоначального проникновения, конкретный облачный провайдер и типы похищенных учётных данных публично не раскрыты. Также не подтверждён полностью автономный конвейер, самостоятельно выполняющий все стадии реального вторжения: наблюдавшаяся система получила автономность после захвата облачного ресурса. Но именно этого оказалось достаточно, чтобы провести массовую операцию за несколько часов и резко сократить доступное защитникам окно реакции.

Читайте также:

• Аналитика больших данных: Почему это важно и как это работает?
• Какие вакансии аналитика данных являются самыми высокооплачиваемыми?
• Чем занимаются аналитики данных и почему они не останутся без работы