Исследователи Threat Research Unit компании Acronis описали кампанию, в которой предполагаемый оператор использовал ИИ-агентов BOSSAI против сотен организаций. Наиболее серьезные подтвержденные последствия пришлись на Тайвань: агенты получили записи вызовов службы 119 в семи районах Тайбэя и обнаружили открытую платформу пожарной службы с медицинскими данными пациентов.
По оценке Acronis, кампанию вел один человек, вероятно находящийся в Хуаляне на Тайване. Он направлял агентов против организаций как минимум в 11 странах, включая экстренные службы, банки, университеты и военные системы. Исследователи подтвердили сбор данных или доступ к системам примерно десяти организаций на Тайване, в Мексике и Таиланде.
Данные экстренных служб Тайбэя
Записи вызовов были извлечены через API городской системы 119 — тайваньского номера экстренной помощи для пожарной службы и скорой помощи. В массивах содержались время происшествий, тип реагирования, статус дел и данные о местоположении с точностью до улицы. Речь не идет о мониторинге машин скорой помощи в реальном времени: это записи об обращениях.
Агенты также обнаружили доступную без аутентификации платформу пожарной службы Тайбэя. На ней размещались данные пациентов за 2018 год, включая показатели ЭКГ и видеоматериалы, связанные со скорой помощью. В кратком изложении исследования Acronis эпизоды с экстренными службами и университетами охарактеризованы как кража медицинских и персональных данных. Однако подробное описание платформы с данными пациентов говорит о раскрытии записей, но не подтверждает их выгрузку оператором.
Помимо этих двух эпизодов, оператор действовал еще против пяти связанных с экстренными службами целей на Тайване. У поставщика технологий диспетчеризации пожарных служб он вошел в административную панель базы данных с учетными данными root по умолчанию и получил доступ как минимум к 18 таблицам. Попытка развернуть веб-оболочку через известную CVE успеха не принесла.
В информационной системе управления чрезвычайными ситуациями агенты нашли жестко заданный AES-256-ключ в JavaScript-коде интерфейса. Он позволял расшифровывать содержимое сессионных cookie, включая идентификаторы администратора, однако подтверждения проникновения в систему нет. Сканер также сообщил о критической уязвимости Apache с возможностью удаленного выполнения кода в Национальном центре реагирования на чрезвычайные ситуации. Этот вывод оказался ошибочным: указанной уязвимости не существовало.
Против портала единого входа Национального агентства по пожарной охране предпринималась попытка подбора учетных данных, но доступ не подтвержден. Системы пожарных служб в пяти городах лишь сканировались для определения используемого ПО — признаков взлома Acronis не приводит. Исследование не отвечает, были ли уведомлены затронутые организации и власти Тайваня, а также остаются ли раскрытые данные доступными.
Подтвержденные эпизоды вне экстренных служб
На Тайване агенты использовали SQL-инъекцию против таблицы учетных записей кредитной компании. В Таиланде тем же методом были собраны данные из трех университетов: до атаки оператор отобрал 489 потенциальных целей в 45 учреждениях.
В Мексике агенты собрали около 206 800 записей о домашних телефонных номерах вместе с именами и адресами. Для этого использовались государственная статистика, перечни почтовых индексов и данные телекоммуникационного регулятора.
Еще около 15 организаций подверглись атакам, но компрометацию исследователи не подтвердили. По меньшей мере в восьми других странах цели только сканировались либо были отложены для последующих действий, которые на момент проверки не начались. За операцией наблюдали 12 дней; один из сохраненных диалогов фиксирует работу оператора 25 июля.
Проверять IOC в такой ситуации имеет смысл вместе с телеметрией: источники событий должны позволять отличить простое совпадение индикатора от подтвержденной активности на конкретном узле. Для сопоставления этих требований с возможностями системы можно использовать официальную страницу Security Capsule SIEM для оценки применимости к требованиям инфраструктуры. Сам перечень индикаторов без контекста, в частности без данных о роли IP-адреса или домена в атакующей инфраструктуре, не доказывает компрометацию.
Как работала BOSSAI
BOSSAI включала 12 ИИ-агентов, девять из которых были задействованы в этой операции. Часть агентов создавала и обслуживала серверы и инструменты оператора, другие сканировали и атаковали выбранные цели. Результатами между собой агенты напрямую не обменивались: оператор вручную переносил вывод одного агента в запросы к другому и оставался связующим звеном всей схемы.
Новости информационной безопасности, технологий и государственного регулирования, а также анонсы новых исследований Tech Threat Lab.
Смежный кейс применения ИИ-агентов при сетевом тестировании описан в материале «CERT-In: ИИ-агенты получили доступ к системам при сетевом тестировании». В кампании, описанной Acronis, оператор не ограничился проверкой: он использовал агентов для параллельного поиска целей и действий против доступных извне систем.
Построение инфраструктуры в основном велось с использованием коммерческих облачных моделей; заметную роль играл Grok. Когда оператор прямо запрашивал проведение атаки, Grok и MiniMax M3 в большинстве случаев отказывались и требовали письменного подтверждения санкционированного характера работ. Исследователи отдельно отмечают, что неизвестно, сработало бы поддельное разрешение.
Исключением стал случай, когда Grok исправил неработающий скрипт для проверки концепции. Затем оператор передал исправленный код атакующему агенту. Агентов-разработчиков Claude Code и Codex он также переключал на модели с ослабленными ограничениями безопасности, хотя те преимущественно выполняли инфраструктурные задачи. Агент Cursor, работавший на такой модели, атаковал сайт экстренных служб Тайваня.
Непосредственно атакующие агенты почти исключительно использовали локально запущенные версии DeepSeek, GLM и Qwen с удаленными или ослабленными ограничениями безопасности. Коммерческие модели в большинстве случаев не содействовали непосредственно атакующим действиям.
Ошибки агентов и пределы автоматизации
ИИ не сделал кампанию безошибочной. Один из сканеров генерировал сведения о CVE, которых в действительности не существовало: более половины результатов с уровнями риска «высокий» и «критический» оказались ложными срабатываниями либо были неверно классифицированы. Основной атакующий агент также сообщал о результатах, которые фактически не были достигнуты.
По наблюдениям Acronis, агенты преимущественно находили уже плохо защищенные ресурсы: открытую платформу с медицинскими данными, доступные через публичный API записи диспетчерской службы, кредитную организацию с 16 точками для SQL-инъекций и университеты с непропатченными базами данных Oracle.
Операция не давала результата там, где требовалась аутентификация, доступ к платным ресурсам был возможен только при действующей сессии, а конечные точки корректно фильтровались. ИИ позволил с небольшими затратами параллельно искать и атаковать множество целей, но не смог обойти надлежащим образом выстроенную защиту.
Атрибуция и мотив
Вывод о предполагаемом операторе Acronis сделала на основании его ошибок при сокрытии личности и открытых данных. По данным исследователей, он использовал одну и ту же идентификацию для легальных компаний и атакующей инфраструктуры: профиль GitHub, логотип, имя SSH-ключа и адрес электронной почты. Домашний IP-адрес также оказался виден в SSH-сеансе, попавшем в один из его диалогов с Grok.
Мотивы оператора не установлены. Часть действий против правительственных, аварийно-спасательных и военных объектов напоминала операции групп, поддерживаемых государствами, тогда как другие эпизоды были похожи на обычную киберпреступность. Исследователи считают финансовую мотивацию вероятной, но не знают, работал ли оператор на кого-либо.
В приложенном к исследованию перечне IOC приведены девять IP-адресов и девять доменов инфраструктуры оператора. Для большинства индикаторов не указано назначение, а сами они не помечены как активные или неактивные.
Что проверить российским организациям
В исходных данных не указаны подтвержденные атаки на российские организации. Однако описанный механизм применим к любым доступным из интернета системам: ИИ-агенты ускоряют массовый поиск слабых конфигураций, публичных API, учетных данных по умолчанию, SQL-инъекций и непропатченных компонентов, даже если регулярно ошибаются в оценке результатов.
Практический вывод — проверить внешние интерфейсы, прежде всего системы с медицинскими, персональными и диспетчерскими данными. Следует исключить анонимный доступ к API и административным панелям, заменить учетные данные по умолчанию, устранить известные уязвимости, закрыть неиспользуемые сетевые сервисы и убедиться, что чувствительные конечные точки фильтруются и требуют корректной аутентификации.
Отдельно не стоит считать автоматически сгенерированный результат сканирования подтвержденным инцидентом без верификации. Значительная часть «критических» находок агентов в этой кампании была ложной, но подтвержденные эпизоды показывают: ошибки автоматизации не мешают использовать ее для поиска давно доступных извне слабых точек.