A Microsoft Threat Intelligence relatou em 5 de novembro de 2026 que agentes que usavam o framework ARTEX buscaram credenciais expostas em repositórios públicos do GitHub e depois usaram credenciais válidas de aplicativos para acessar ambientes de nuvem de algumas organizações. A Microsoft diz ter observado buscas desde agosto e logins relacionados a partir de 28 de outubro. Em um caso, a sequência entre a varredura no GitHub e a extração de dados do Azure Key Vault levou cinco minutos. Leia o relato da Microsoft.
O que a Microsoft relata sobre o ARTEX
Segundo a Microsoft, as buscas combinavam nomes de organizações com termos relacionados a segredos, nuvem e provedores de IA. Os agentes analisavam os resultados e podiam avançar para ações com credenciais de aplicativos encontradas. O caso dos cinco minutos é uma observação específica, não uma medida do tempo típico da atividade.
A NeoTeo já abordou os riscos mais amplos de agentes autônomos. O relato da Microsoft descreve um caminho mais concreto: uma credencial válida pode permitir que uma identidade de aplicativo acesse recursos de nuvem.
A Microsoft relata logins de service principals, identidades usadas por aplicativos para se autenticar, a partir de 28 de outubro. A atividade envolveu dezenas de aplicações e vários tenants, ambientes de identidade de organizações. Em um dos cenários descritos, uma credencial de aplicativo multitenant comprometida em sua origem foi usada contra ambientes de outros clientes.
Entre os alvos mencionados estão chaves de contas de armazenamento, configurações e credenciais do App Service, sequências de conexão, conexões e repositórios de dados de IA e aprendizado de máquina, além de credenciais de usuário do Azure Kubernetes Service. A Microsoft também relata acessos a Azure Key Vault, Storage Accounts, serviços Azure AI, Azure DevOps, SharePoint e OneDrive. Em alguns casos, houve downloads de arquivos e acesso a itens de caixas de correio; solicitações ao Microsoft Graph buscaram principalmente conteúdo de interesse. Depois da autenticação, os agentes também procuraram segredos no Azure DevOps.
Três novas tentativas distintas nas APIs do Azure
A Microsoft descreve três sequências separadas: uma consulta de metadados do Key Vault, uma solicitação sobre regras de firewall do Azure SQL e uma consulta do Application Insights. Em cada caso, uma solicitação inicial retornou HTTP 400; uma nova solicitação, modificada, retornou HTTP 200.
| Solicitação | Intervalo aproximado até a nova tentativa | Resposta inicial | Resposta da nova tentativa |
| Metadados do Azure Key Vault | 28 segundos | HTTP 400 | HTTP 200 |
| Regras de firewall do Azure SQL | 60 segundos | HTTP 400 | HTTP 200 |
| Consulta do Application Insights | 80 segundos | HTTP 400 | HTTP 200 |
Na sequência do Key Vault, a nova tentativa usou a versão 2023-07-01 da API do Azure Resource Manager. A Microsoft relata que a solicitação inicial usou uma versão da API de dados do Key Vault contra um endpoint do plano de controle do Resource Manager.
Como as equipes podem responder a uma credencial exposta
Apagar o arquivo público não revoga a credencial. A Microsoft recomenda revogar ou trocar imediatamente a credencial exposta e revisar seu uso anterior. As equipes também devem investigar se alguém adicionou segredos, certificados ou credenciais federadas a aplicativos e trocar os segredos de cofres do Key Vault que esses aplicativos poderiam acessar.
Se uma credencial apareceu em público, revogue-a ou troque-a e investigue o uso anterior. Remover o arquivo não corta, por si só, o acesso.
Para a investigação, a Microsoft recomenda revisar registros de login de service principals e de acessos não interativos, Azure Activity, diagnósticos de Key Vault e Storage, auditoria do Entra e do Azure DevOps e os logs unificados de auditoria do Microsoft 365. Também aconselha limitar cada identidade de aplicativo às permissões necessárias.
Endereços IP e identificadores de navegador podem mudar, então a Microsoft orienta procurar comportamentos além de indicadores de rede. Um endereço autenticando-se em três ou mais service principals, com tentativas bem-sucedidas e malsucedidas, é um padrão a investigar, não uma confirmação de invasão. Também vale examinar pedidos rápidos e modificados a APIs e um aplicativo solicitando tokens para vários serviços de nuvem em pouco tempo. Os erros AADSTS7000215 e AADSTS7000222 podem indicar que alguém tem uma credencial de aplicativo; por si sós, não provam atividade maliciosa.
A Microsoft cita 199.19.77[.]84 e 199.19.77[.]18 como principais origens dos logins observados. A segunda também é um nó de saída do Tor e pode estar associada a atividade sem relação com o caso. Para bloquear 199.19.77[.]84/32 por Acesso Condicional de identidade de carga de trabalho, a orientação exige Workload ID Premium e se aplica a aplicativos de tenant único registrados no próprio tenant. A Microsoft recomenda bloquear o endereço específico, não todo o sistema autônomo. Mesmo após a remoção de credenciais, tokens já emitidos continuam válidos até expirarem.
Um caso separado: configurações locais do Claude Code
Em um vídeo em inglês publicado em 7 de novembro, SavvyNik descreve outro caminho de exposição: comandos com senhas ou chaves de API aprovados no Claude Code podiam ser salvos em arquivos locais de configuração JSON e depois publicados em repositórios públicos. SavvyNik atribui à pesquisa da Apiiro mais de 1.100 cópias públicas de um arquivo de configuração com pelo menos um segredo e 2.539 segredos reais em cerca de 2.000 repositórios do GitHub. Esse mecanismo envolve a publicação de arquivos locais de configuração, diferente da busca por credenciais já expostas descrita pela Microsoft.
