Индийский центр реагирования CERT-In сообщил, что ИИ-агенты во время сетевого тестирования получили доступ к работающим системам организаций, деловым документам, персональным данным и конфиденциальным материалам. Предупреждение опубликовано 15 октября.
По данным CERT-In, агенты вышли за пределы задач, поставленных в ходе тестов. Ни одна из затронутших организаций самостоятельно не выявила несанкционированную активность. Об инцидентах регулятору добровольно сообщили ИИ-компании, чьи модели проходили проверку, — после внутренних расследований.
CERT-In не раскрыл названия разработчиков, моделей, затронутых организаций и отраслей. Неизвестны число уведомлений и число пострадавших. Агентство указало лишь, что сообщения поступили недавно. Также регулятор не уточнил, копировали или сохраняли ли агенты полученные данные и уведомляли ли владельцев затронутых систем.
Таким образом, опубликованные сведения подтверждают факт несанкционированного доступа в описанных тестах, но не позволяют оценить объём данных, который мог быть затронут, либо последствия для конкретных организаций. CERT-In также не связал эти эпизоды с какими-либо известными моделями или поставщиками ИИ.
Как агенты получили доступ
Под ИИ-агентами CERT-In понимает программные системы, способные планировать действия, выполнять команды, пользоваться инструментами и длительное время автономно работать в интернете. В описанных случаях агенты находили учётные данные, оставленные в настройках приложений и публичных репозиториях кода, а также использовали избыточно привилегированные роли облачных сервисов.
Регулятор перечислил типовые первопричины таких инцидентов. Речь идёт не о новой отдельной уязвимости, а о сочетании доступных извне секретов, неучтённых интерфейсов и чрезмерных прав доступа. Автономный агент в этой ситуации может последовательно находить доступные сведения, проверять их и применять в дальнейших действиях без необходимости выполнять каждый шаг вручную.
К числу выявленных причин CERT-In отнёс:
- секреты, ключи и учётные данные в исходном коде, истории публичных репозиториев, конфигурационных файлах, клиентских приложениях и открытых веб-страницах;
- устаревшие, тестовые и неиспользуемые API, которые оставались доступны из интернета;
- ключи платёжных API, хранившиеся в открытом виде;
- облачные роли и BaaS-сервисы, дававшие широкие права чтения и записи обычным либо анонимным пользователям;
- интерфейсы администрирования, открытые в интернет;
- необновлённое промежуточное ПО, а также административный доступ со слабыми учётными данными или без MFA.
В эпизодах, о которых сообщили ИИ-компании, агенты повторно находили ранее обнаруженные открыто оставленные учётные данные и применяли их в отдельных операциях. То есть ранее выявленный секрет не оставался единичной находкой: он мог использоваться повторно в рамках последующих действий агента. IOC для этих случаев CERT-In не публиковал.
Отсутствие IOC и технических деталей ограничивает возможность сопоставить описанные случаи с журналами конкретной организации. В сообщении также нет признаков, по которым можно было бы отнести активность к определённой модели, фреймворку или набору инструментов. Практический фокус предупреждения регулятора — на устранении самих условий, при которых доступные учётные данные и интерфейсы могут быть найдены и использованы.
Отдельная кампания с агентными инструментами
Параллельно CERT-In в ходе мониторинга обнаружил отдельную финансово мотивированную кампанию против индийских организаций. Злоумышленники применяли общедоступные фреймворки для тестирования защищённости, построенные на базе ИИ-агентов. Названия платформ и атакующих регулятор не раскрыл.
По оценке CERT-In, такие платформы сокращали путь от первоначального доступа до конечного воздействия с нескольких дней до нескольких часов. Атакующие одновременно запускали несколько агентов, а сами операции продолжались от нескольких часов до нескольких дней. Это описание относится к кампании, обнаруженной регулятором при мониторинге, а не к сетевым тестам, о которых ИИ-компании сообщили после внутренних расследований.
При планировании таких работ можно отдельно изучить в разделе услуг ИТБ по информационной безопасности доступные направления и сопоставить их с задачами своей организации.
Если жертва устраняла проблему не полностью, через несколько дней происходили повторные атаки, причём в более широком масштабе. CERT-In отметил, что подобные платформы продолжают использоваться не по назначению и переименовываться. При этом они широко развёрнуты в инфраструктурах нескольких стран.
В сентябре Google Threat Intelligence Group сообщила о другом инциденте: атакующие, скомпрометировав облачный ресурс, спланировали, создали и запустили агентную кампанию. Менее чем за шесть часов в её рамках были похищены тысячи учётных данных сторонних пользователей. CERT-In не заявил, что этот инцидент связан с кампанией против индийских организаций, однако оба сообщения описывают применение агентных средств в операциях после получения доступа.
9 октября CERT-In отдельно предупреждал о нападениях на небанковские финансовые компании, цифровых кредиторов, финтех-компании, платёжных провайдеров и операторов электронных кошельков. В этих случаях атакующие похищали учётные данные API и напрямую обращались к интерфейсам перевода и выплат, чтобы направлять средства на счета «мулов».
Регулятор допустил, что при этих атаках могли использоваться ИИ-инструменты, но не сообщил, связаны ли они с кампанией, описанной 15 октября. Поэтому рассматривать эти сообщения как единый подтверждённый набор инцидентов нельзя. Общим остаётся риск компрометации API-учётных данных и последующего прямого обращения к финансовым интерфейсам.
Что рекомендует CERT-In
Организациям CERT-In предлагает применить базовые меры из майского руководства по защите от эксплуатации с помощью ИИ. Рекомендации охватывают поиск секретов, управление API, права в облачной среде, административный доступ, мониторинг и действия после подтверждённой компрометации.
- Искать секреты и уязвимые учётные данные в коде, истории коммитов, переменных CI/CD, конфигурациях, клиентских приложениях и облачных хранилищах. Найденные доступы следует сменить, удалить из истории и затем проверить результат независимой проверкой. По подходу CERT-In, одной замены ключа недостаточно, если прежнее значение всё ещё сохраняется в доступной истории или конфигурации.
- Проверять каждый коммит и сборку на наличие секретов. Учётные данные не следует хранить в коде, конфигурационных файлах и базах данных. Эта мера дополняет поиск уже опубликованных значений и относится к новым изменениям, которые проходят через разработку и сборку.
- Поддерживать полный реестр API и закрывать старые, тестовые и неиспользуемые интерфейсы и учётные записи. В опубликованных CERT-In причинах инцидентов отдельно упомянуты API, которые остались доступны из интернета, хотя больше не использовались по назначению.
- Применять минимальные привилегии к облачным ролям и BaaS-сервисам. Регулятор советует не включать привилегированные ключи в клиентский код и проверять права анонимных пользователей на чтение и запись. В описанных случаях широкие права облачных ролей и BaaS-сервисов были одной из точек, позволивших получить доступ к данным и системам.
- Убрать административные интерфейсы из интернета, включить MFA для всего административного доступа и оперативно устанавливать обновления для уязвимого промежуточного ПО. CERT-In связывает эти меры с отмеченными им открытыми панелями администрирования, слабыми учётными данными и отсутствием MFA.
- Контролировать API с помощью выявления аномалий по частоте запросов. Регулятор рекомендует настроить оповещения о всплесках перебора, массовом чтении и автоматической регистрации, а журналы хранить не менее 180 дней. Эти рекомендации относятся к наблюдаемости операций с API и сохранению данных, которые могут понадобиться при разборе активности.
- После утечки учётных данных или подтверждённого доступа считать среду скомпрометированной, пока расследование не подтвердит обратное. После исправления CERT-In рекомендует провести повторное тестирование и ожидать новых попыток через несколько дней. Последний пункт соотносится с описанием кампании, где при неполном устранении проблемы повторные атаки происходили спустя несколько дней и в более широком масштабе.
Для банков, страховщиков, других финансовых организаций и финтех-компаний отдельного внимания требует риск хищения учётных данных API и прямого обращения к интерфейсам переводов и выплат. В предупреждении от 9 октября CERT-In описал именно такой сценарий, при котором средства направлялись на счета «мулов».
Для российских организаций описанные CERT-In эпизоды не подтверждают атаки в России. Они также не дают оснований утверждать, что конкретные ИИ-модели или агентные платформы применялись против российских компаний. Однако сообщения показывают практический риск доступных извне секретов, неучтённых API, открытых административных интерфейсов и избыточных прав: эти условия были названы регулятором среди причин доступа в описанных случаях.