Злоумышленник использовал ИИ-агентов при вторжении в корпоративную инфраструктуру и менее чем за десять часов прошел путь от первоначального доступа до получения root-прав, компрометации среды разработки и кражи ключей к облачным сервисам. Исследователи Palo Alto Networks оценивают сопоставимый объем работы обычных операторов примерно в две недели.
Инцидент описан в отчете Unit 42, опубликованном 2 сентября 2026 года. Человек не исчез из цепочки атаки: он ставил задачи и принимал решения, которые могли серьезно повлиять на ход операции. Специализированные агенты выполняли технические действия, обменивались результатами и перестраивали дальнейшую работу после каждого нового результата.
Всего исследователи сопоставили действия злоумышленника более чем с 50 техниками MITRE ATT&CK. Неизвестные уязвимости или принципиально новые методы взлома для атаки не потребовались. Главным отличием стала скорость: отдельные этапы, которые обычно выполняются последовательно, были связаны в автоматизированный цикл.
Первоначально публикация описывала происшествие как ransomware-атаку. 3 сентября авторы изменили формулировку: расследовалось вторжение с требованием выкупа, а не атака программы-шифровальщика. В отчете нет подтверждения, что злоумышленник шифровал корпоративные данные.
Точкой входа стал доступный из интернета веб-сервис. После его компрометации злоумышленник получил возможность проложить туннель во внутреннюю сеть и запустил автоматизированную разведку.
Один из агентов занялся внутренними микросервисами: находил доступные узлы, изучал устройство среды и передавал результаты дальше. Схема была построена так, что агенты могли получать вывод инструментов, анализировать его, выбирать следующее действие и корректировать план без необходимости каждый раз ждать новой команды от человека.
Исследователи нашли сразу несколько признаков такой организации работы. Во время атаки выполнялись обращения к нескольким передовым ИИ-агентам, между отдельными сеансами передавались структурированные Markdown-файлы, а для управления операциями использовались собственные скрипты, которые эксперты с высокой уверенностью считают сгенерированными ИИ.
Конкретные модели и агентные платформы в отчете не названы. Сам злоумышленник во время переговоров заявил, что использовал передовые ИИ-модели и специализированные агентные системы для атак. Поэтому приписывать этот инцидент Claude, ChatGPT, Gemini или какой-либо другой конкретной модели оснований нет.
После разведки агенты начали просматривать корпоративные репозитории исходного кода. Их целью стали секреты, оставленные непосредственно в файлах: встроенные токены и пароли сервисных учетных записей.
Дальше атака развивалась без необходимости искать новую уязвимость. Полученные токены позволили добраться до корпоративной системы управления секретами. Из нее злоумышленник извлек административные учетные данные и получил root-доступ к системам.
Этот этап хорошо показывает, почему утечки секретов из репозиториев остаются опасными даже при защищенном внешнем периметре. Один действующий токен может стать промежуточной точкой между исходным кодом и системой хранения более привилегированных учетных данных.
В MITRE ATT&CK такие действия соответствуют, в частности, поиску учетных данных в файлах и извлечению учетных данных из хранилищ паролей. Само по себе это давно известная техника. В этом случае ИИ ускорял поиск и переход от одного найденного секрета к следующему уровню доступа.
Получив расширенные права, злоумышленник добрался до инфраструктуры разработки. Агенты запускали несанкционированные операции непрерывной интеграции и доставки, то есть CI/CD. Через специально созданные рабочие процессы атакующий смог вывести ключи доступа к облачной инфраструктуре.
Затем была предпринята попытка внедрить бэкдоры в конфигурации Terraform. Terraform позволяет описывать облачную инфраструктуру в виде кода, поэтому изменение таких файлов может затронуть серверы, сети, права доступа и другие ресурсы. Эта часть атаки не удалась. Правила защиты веток репозитория заблокировали вредоносные изменения.
Полученные через среду разработки облачные ключи использовали еще для одной задачи: доступа к принадлежащей жертве ИИ-инфраструктуре. Атакующий обращался к облачным ИИ-моделям компании с украденными ключами и фактически превратил ее вычислительные ресурсы в часть собственной инфраструктуры после взлома. Исследователи отдельно выделяют этот прием как один из новых рисков для компаний, которые разворачивают корпоративные модели и агентные системы.
Для атакующего это удобно сразу по нескольким причинам. Запросы идут через действующие корпоративные учетные данные, активность может смешиваться с обычным трафиком компании, а затраты на вычисления ложатся на владельца инфраструктуры.
Авторы исследования поэтому предлагают учитывать ИИ-сервисы наравне с другими важными элементами корпоративной среды: вести учет точек доступа к моделям, API-ключей, интеграций с инструментами и шлюзов MCP, ограничивать права и сохранять подробные журналы событий.
MCP, или Model Context Protocol, — протокол, через который ИИ-приложения могут получать доступ к внешним данным и инструментам. Если такая интеграция имеет широкие полномочия, украденная учетная запись или ключ способны открыть атакующему дополнительные возможности уже после первоначального проникновения.
Автоматизация использовалась и для закрепления в инфраструктуре. Во время расследования обнаружились пересекающиеся механизмы сохранения доступа через SSH-ключи, бессерверные функции, политики перезапуска контейнеров, облачные учетные записи и CI/CD. Агенты позволяли проверять и поддерживать несколько таких направлений одновременно. Блокировка одного токена или сервиса еще не означает завершение атаки, если система уже успела создать несколько независимых точек входа.
Unit 42 поэтому рекомендует при подобных инцидентах проводить изоляцию синхронно: одновременно отзывать учетные данные, завершать OAuth-сеансы, останавливать подозрительные CI/CD-процессы и изолировать связанные облачные учетные записи.
Самая необычная деталь расследования появилась в конце операции. По команде злоумышленника агент составил примерно 80-страничный технический отчет о состоянии защиты компании. В него вошли десятки проблем, которые удалось использовать во время вторжения.
Получился своеобразный отчет о тестировании на проникновение, только его подготовила та же система, которая участвовала во взломе.
Есть новость? Станьте автором.
Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.
