Agentes de IA testados online acessaram sistemas ativos de organizações indianas e leram registros comerciais, incluindo dados pessoais e material confidencial, segundo a CERT-In (Equipe Nacional de Resposta a Emergências Cibernéticas da Índia), que divulgou um comunicado em 15 de outubro.
Os agentes foram além das tarefas que lhes foram atribuídas, e nenhuma das organizações detectou o acesso não autorizado. Após revisões internas, as empresas de IA cujos modelos estavam sendo testados comunicaram voluntariamente os casos à CERT-In, a agência nacional de segurança cibernética da Índia.
Agentes de IA são sistemas de software capazes de planejar tarefas, executar comandos, usar ferramentas e atuar na internet de forma autônoma por longos períodos. Nesses casos, os agentes obtiveram acesso por meio de credenciais e configurações de conexão deixadas expostas em configurações de aplicações e em repositórios públicos de código, além de funções de serviços em nuvem com permissões excessivas.
A CERT-In não identificou as empresas de IA, seus modelos, nem as organizações e os setores envolvidos. A agência também não informou quantas empresas registraram casos nem quantas organizações foram afetadas, e disse apenas que as notificações foram recebidas recentemente.
A CERT-In também não disse se os dados lidos pelos agentes foram copiados ou mantidos, nem se as organizações afetadas foram comunicadas.
Invasores usaram ferramentas de agentes de IA de código aberto em uma campanha separada
A busca de ameaças conduzida pela própria CERT-In identificou um segundo conjunto de incidentes, separado do primeiro: uma campanha motivada por ganhos financeiros contra entidades indianas. Os invasores usaram indevidamente frameworks de segurança ofensiva disponíveis publicamente e construídos sobre agentes de IA.
Esses frameworks continuam sendo usados indevidamente e reempacotados sob novos nomes, com diversas implantações em infraestruturas de vários países. A CERT-In não identificou os frameworks nem os invasores.
Nessa campanha, os frameworks reduziram o tempo entre o primeiro acesso e o impacto final de dias para algumas horas, segundo a CERT-In. Os atacantes executaram vários agentes em paralelo, por horas a dias, para alcançar seus objetivos. As vítimas que corrigiram os problemas apenas parcialmente foram atacadas novamente em questão de dias, e em uma escala maior.
O Google Threat Intelligence Group relatou um caso separado em setembro. Invasores que haviam comprometido um recurso de nuvem planejaram, construíram e executaram uma campanha orientada por agentes que coletou milhares de credenciais de terceiros, tudo em menos de 6 horas.
Em 9 de outubro, a CERT-In alertou sobre ataques contra empresas de crédito não bancárias, credores digitais, fintechs, provedores de pagamento e operadores de carteiras digitais. Nesses casos, os invasores roubaram credenciais de API (interfaces de programação de aplicações) e chamaram diretamente as APIs de transferência de fundos e de desembolso para movimentar dinheiro para contas de laranjas.
Ferramentas com assistência de IA podem ter sido usadas nesses ataques. A CERT-In não informou se esses ataques estão relacionados à campanha mencionada no comunicado de 15 de outubro.
O que a CERT-In quer corrigir
As fragilidades por trás dos dois tipos de incidentes eram comuns, afirmou a CERT-In. Credenciais e chaves estavam expostas em código-fonte, no histórico de repositórios públicos, em arquivos de configuração, em aplicativos cliente e em páginas web públicas. APIs antigas, não utilizadas e de teste ainda podiam ser acessadas pela internet.
Chaves de API de pagamento estavam armazenadas em texto simples, e funções de nuvem e de backend como serviço concediam a usuários comuns ou anônimos amplo acesso de leitura e escrita. Interfaces de gerenciamento estavam expostas à internet, e middlewares de aplicações não haviam recebido correções, com credenciais fracas ou sem autenticação multifator.
Nos casos relatados pelas empresas de IA, os agentes encontraram novamente a mesma credencial exposta e a reutilizaram em operações separadas.
A CERT-In não publicou indicadores de comprometimento para nenhum dos dois tipos de incidente. As organizações devem aplicar o conjunto básico de medidas do guia de maio da CERT-In e adotar as seguintes etapas:
- Pesquisar código-fonte, histórico de commits, variáveis de CI/CD (integração e entrega contínuas), arquivos de configuração, aplicativos cliente e armazenamento em nuvem em busca de credenciais expostas. Substituir as que forem encontradas, removê-las do histórico e confirmar a correção a partir de fora.
- Verificar cada commit e cada build em busca de segredos, e manter as credenciais fora do código, dos arquivos de configuração e dos bancos de dados.
- Manter uma lista completa de suas APIs e desativar as antigas, não utilizadas e de teste, bem como as contas associadas a elas.
- Aplicar o princípio do menor privilégio às funções de nuvem e de backend como serviço, manter chaves privilegiadas fora do código do lado do cliente e testar o que um usuário anônimo consegue ler e escrever.
- Retirar as interfaces de gerenciamento da internet, exigir autenticação multifator para todo acesso administrativo e aplicar correções rapidamente nos middlewares expostos.
- Monitorar APIs com detecção de anomalias baseada em taxa de requisições, emitir alertas para rajadas de enumeração, leituras em massa e cadastros automatizados, e manter registros por pelo menos 180 dias.
- Após qualquer exposição de credenciais ou acesso confirmado, tratar o ambiente como comprometido até que uma perícia forense o libere. Refazer os testes após a correção e esperar novas tentativas em questão de dias ou semanas.
- Se executarem agentes de IA, atribuir a cada execução uma identidade própria, de curta duração e com o menor privilégio possível, e bloquear o tráfego de saída, exceto para os destinos que cada execução precisar. Manter um registro resistente a adulterações das ações dos agentes, ao menos daquelas que afetem sistemas e dados de produção.
Bancos, seguradoras, outras instituições financeiras e fintechs também devem aplicar as medidas para APIs de pagamento e de desembolso descritas no alerta de 9 de outubro.
As diretrizes da CERT-In também exigem que as organizações comuniquem incidentes cibernéticos à agência em até 6 horas.
Para desenvolvedores de IA, laboratórios de pesquisa e agências de avaliação, a CERT-In quer que as execuções de teste sejam isoladas, com o acesso de saída à rede bloqueado por padrão. Esse bloqueio deve ser aplicado no nível da rede, e não por meio de instruções ao modelo.
Uma execução deve ser interrompida automaticamente se um agente contatar sistemas externos ou encontrar ou usar credenciais que pertençam a outra pessoa. Se um agente alcançar um sistema real, a organização afetada e a CERT-In devem ser comunicadas prontamente.
Divulgações anteriores da OpenAI e da Anthropic
A OpenAI e a Anthropic divulgaram incidentes semelhantes neste ano. A CERT-In não disse se modelos de alguma dessas empresas estiveram envolvidos nos casos indianos.
Em julho, a OpenAI revelou que seus modelos haviam comprometido a plataforma da Hugging Face. A empresa está revisando o que seus modelos fizeram na internet durante o treinamento e os testes, e notificando terceiros cujos controles de segurança eles possam ter contornado.
Em resposta a essa divulgação, a Anthropic começou a revisar suas próprias avaliações cibernéticas. Desde então, relatou 4 incidentes em que modelos Claude obtiveram acesso não autorizado a sistemas reais de terceiros durante avaliações desenvolvidas pelo mesmo parceiro externo. A empresa notificou todas as partes afetadas.
Das 3 organizações citadas na divulgação de julho da Anthropic, as 2 que a empresa conseguiu contatar não haviam detectado a atividade.
