A Microsoft Threat Intelligence apresenta uma análise abrangente de ataques que tiveram como alvo três ambientes associados à operação de inteligência artificial: o gateway LiteLLM, a plataforma RAGFlow para processamento de documentos e geração aumentada por recuperação, e o ambiente Kestra para orquestração de fluxos de trabalho. Apesar das diferenças entre os percursos de comprometimento, os objetivos foram praticamente os mesmos: roubar credenciais, instalar mecanismos de acesso persistente e aceder a recursos computacionais para os utilizar na mineração de criptomoedas.
A importância dos três casos reside no facto de os atacantes não terem tratado estas ferramentas apenas como aplicações separadas, mas de as terem visado enquanto pontos de controlo onde se concentram credenciais, ligações a fornecedores de modelos, capacidades de execução de comandos e acesso a bases de dados ou contentores. Segundo a Microsoft, este foco torna os gateways de IA e as plataformas de gestão e orquestração alvos de alto valor nos ambientes empresariais.
Três percursos de comprometimento e um único padrão de resultados
No caso do LiteLLM, a Microsoft avalia com elevada confiança que o acesso inicial ocorreu através da exploração de uma interface exposta do gateway. O artigo refere percursos associados a vulnerabilidades públicas, incluindo a CVE-2026-42271, relacionada com a execução autenticada de comandos nos pontos de teste LiteLLM MCP stdio, e um percurso de investigação que a relaciona com a CVE-2026-48710, uma vulnerabilidade de desvio da validação do cabeçalho Host no Starlette. Esta combinação pode, em configurações afetadas, tornar a execução remota de comandos possível sem credenciais válidas.
Após o comprometimento, o payload leu o ambiente do processo principal dentro do contentor, incluindo /proc/1/environ, em busca de chaves de fornecedores de modelos, da chave principal do LiteLLM, de cadeias de ligação a bases de dados, palavras-passe e tokens. Em seguida, foram descarregados ficheiros executáveis disfarçados de serviços Linux, e o host, as portas e os processos foram analisados, com preparação de mineração baseada em XMRig ou RandomX. A cadeia de ligação do PostgreSQL também foi utilizada para aceder às tabelas do LiteLLM, que podem conter configurações de modelos, chaves de fornecedores e chaves virtuais emitidas pelo proxy. Os mecanismos de persistência incluíram a alteração do ficheiro authorized_keys de uma conta de serviço, a modificação de tarefas cron e o uso de ficheiros ocultos e nomes de serviços disfarçados.
No RAGFlow, a atividade observada centrou-se na interceção das credenciais dos modelos de linguagem adicionadas ou modificadas pelos inquilinos. A Microsoft detetou inicialmente um comportamento semelhante a pedidos SSRF, seguido da execução de comandos no contexto do serviço Flask e da alteração do percurso de arranque da aplicação para carregar um hook oculto. O hook capturava o tipo de fornecedor, o nome do modelo, o material da chave API e os dados do endpoint, enviando-os para o exterior. O artigo salienta que a Microsoft não identifica com elevada confiança a vulnerabilidade que causou a execução; menciona as CVE-2026-45312, CVE-2026-28797, CVE-2026-24770 e CVE-2025-68700 como contexto técnico possível, e não como causa confirmada deste caso.
No Kestra, a Microsoft avalia com elevada confiança que a exploração esteve associada à vulnerabilidade crítica CVE-2026-49869, que pode permitir contornar a autenticação, definir um fluxo de trabalho malicioso que utiliza o Process runner e, em seguida, executar comandos shell no worker. Este percurso foi utilizado para aceder ao socket do Docker, analisar o ambiente dos contentores, implementar um minerador e executar operações para ocultar ficheiros. Posteriormente, as tarefas do fluxo de trabalho também foram utilizadas para obter scripts remotos e executá-los diretamente, armazenando depois os resultados cifrados através da API de valores-chave do Kestra.
O que muda, na prática, para as equipas de defesa?
A conclusão mais importante é que a avaliação dos riscos deve partir da função que o ambiente de IA desempenha na organização. O gateway pode ser um repositório de chaves de fornecedores de modelos e uma base de dados de chaves virtuais, enquanto a plataforma RAG pode conter configurações dos inquilinos, e o motor de fluxos de trabalho pode ter permissões para executar comandos e interagir com serviços externos. Por isso, não basta aplicar indicadores de deteção específicos de cada produto de forma isolada.
A Microsoft recomenda tratar os gateways de IA como repositórios de segredos de nível superior, atualizar o LiteLLM e ferramentas semelhantes, exigir autenticação nas APIs e interfaces de administração, restringir as portas de administração e não as expor diretamente à Internet. Recomenda também utilizar chaves virtuais separadas para cada equipa, com limites de despesa, armazenar as chaves dos fornecedores num repositório de segredos gerido em vez de variáveis de ambiente do processo e efetuar a rotação das chaves que possam ter sido expostas.
Entre os restantes controlos estão a aplicação do princípio do menor privilégio ao gateway e à base de dados, a colocação da base de dados atrás de um endpoint privado e de uma firewall restritiva, e a imposição de regras de saída de rede que neguem as ligações por predefinição e permitam apenas os endpoints necessários. Deve ser monitorizado o acesso a /proc/1/environ, a execução de shell, Python ou ferramentas de transferência a partir de um processo do gateway, a alteração de cron ou de ficheiros SSH, a utilização do socket do Docker e a execução a partir de diretórios temporários graváveis.
Limites das conclusões e questões de revisão
Os três casos não provam que todas as implementações de LiteLLM, RAGFlow ou Kestra estejam expostas da mesma forma, e a Microsoft distingue claramente entre vulnerabilidades confirmadas em alguns percursos e vulnerabilidades possíveis no caso do RAGFlow. Além disso, a presença, em alguns payloads, de características que sugerem o uso de ferramentas auxiliares ou generativas não constitui prova da sua origem nem da identidade dos seus criadores. Assim, estes resultados devem ser utilizados para construir hipóteses de deteção e rever configurações, e não para atribuir um ataque a uma entidade específica.
A Microsoft disponibiliza consultas de Advanced hunting para detetar sequências de comportamento, como a execução, pelo gateway, de interpretadores ou ferramentas de transferência, a leitura de variáveis de ambiente do processo principal, o acesso às tabelas do LiteLLM, tentativas de carregar o módulo MSR com a escrita ativada e a alteração de chaves SSH ou de cron. O valor prático destas consultas surge quando são associadas numa única linha temporal; um processo shell isolado pode ser administrativo, mas a sua combinação com a leitura de segredos, uma ligação externa e a execução de um ficheiro a partir de um diretório temporário aumenta significativamente o nível de suspeita.