Em 5 de novembro de 2026, a Microsoft Threat Intelligence publicou um relatório sobre um tipo de ataque que depende de um descuido antigo: credenciais deixadas dentro do código. A novidade não é a falha, é a velocidade. Segundo a Microsoft, agentes de inteligência artificial passaram a varrer repositórios públicos do GitHub em busca de segredos expostos e a usar o que encontram sem esperar por um operador humano. Em um dos casos observados, o agente foi da busca por uma chave no GitHub até a extração de dados de um cofre de chaves do Azure em cinco minutos.
Para uma consultoria, esse é um risco de rotina, não de exceção. Integrações entre sistemas, automações, painéis de indicadores e ferramentas de IA costumam ser montados com chaves de aplicativo e cadeias de conexão escritas direto em arquivos de configuração. Este artigo organiza o que revisar, em que ordem, e o que isso significa na prática para a TI para consultorias.
O que a Microsoft observou
O relatório descreve duas etapas encadeadas. A partir de agosto de 2026, a Microsoft registrou um grande volume de consultas automatizadas ao GitHub, combinando o nome da organização alvo com palavras ligadas a segredos, a serviços de nuvem e a provedores de IA. O objetivo era localizar credenciais de aplicativo, cadeias de conexão e chaves de API de serviços de inteligência artificial.
A segunda etapa começou a ser observada a partir de 28 de outubro de 2026: autenticações bem-sucedidas de entidades de serviço (as identidades que aplicativos usam para acessar recursos sem intervenção humana) partindo de um endereço de internet único, atingindo dezenas de aplicativos em vários ambientes. Em parte dos casos, a credencial comprometida era de um aplicativo multilocatário, isto é, pertencente a um fornecedor, e foi usada para alcançar os ambientes dos clientes desse fornecedor.
Uma vez dentro, o invasor buscou exatamente o que abre outras portas: chaves de contas de armazenamento, configurações de serviços de aplicativo, cadeias de conexão, credenciais de publicação e conexões de serviços de dados. Em seguida, acessou SharePoint e OneDrive dos ambientes afetados, com cópia de arquivos e leitura de itens de caixa postal, e mapeou assinaturas, grupos de recursos e permissões.
Por que a consultoria é um alvo conveniente
Consultoria é um negócio de acesso. O escritório mantém dados de clientes, propostas, modelos financeiros, pareceres e, com frequência, credenciais de sistemas de terceiros para trabalhar dentro do ambiente de quem contratou. Um único segredo exposto pode abrir uma cadeia que vai muito além da própria empresa.
Há três características que tornam o problema comum nesse mercado:
- Integrações construídas sob pressão de prazo. Uma automação que precisa funcionar até sexta-feira nasce com a chave escrita no arquivo de configuração, e fica assim.
- Rotação alta de colaboradores e de parceiros. Scripts e repositórios herdados de projetos antigos permanecem com credenciais válidas que ninguém assume como responsabilidade.
- Adoção rápida de ferramentas de IA. Chaves de API de provedores de IA circulam por planilhas, mensagens e arquivos locais antes de qualquer política de uso existir.
Esse último ponto é importante: o relatório da Microsoft registra que os agentes demonstraram foco específico em credenciais de serviços de inteligência artificial. O tema se conecta ao que já tratamos sobre agentes de IA precisarem de identidade própria e sobre o risco de fornecedor nas permissões de aplicativos.
Onde os segredos costumam estar guardados
Antes de rotacionar qualquer coisa, é preciso saber o que existe. Na prática, um inventário razoável em uma empresa de serviços profissionais encontra credenciais nestes lugares:
- Arquivos de configuração de aplicações internas e de automações.
- Repositórios de código, incluindo repositórios privados que já foram públicos e o histórico de alterações.
- Scripts de rotina em servidores e estações de trabalho.
- Planilhas e documentos compartilhados usados para "guardar" chaves de API.
- Conectores e fluxos de automação entre sistemas, com credenciais salvas no próprio fluxo.
- Ferramentas de relatórios e painéis que leem bancos de dados por cadeia de conexão fixa.
- Mensagens trocadas em canais de chat durante a implantação de uma integração.
Um detalhe do relatório merece atenção: uma credencial exposta publicamente continua válida até ser revogada ou trocada. Apagar o arquivo não resolve. O conteúdo permanece em históricos de alteração, em cópias e em registros intermediários.
O que fazer nos primeiros dias
A sequência abaixo é a que recomendamos quando assumimos um ambiente nesse estado. Ela segue a mesma lógica de priorização do relatório da Microsoft.
- Varrer o código em busca de segredos. O GitHub oferece varredura de segredos e bloqueio no envio, que impede que determinados tipos de credencial sejam enviados ao repositório.
- Tratar como comprometido tudo que foi exposto. Revogue e troque a credencial, mesmo que o arquivo já tenha sido corrigido.
- Listar os aplicativos registrados no ambiente de identidade e identificar quem é o responsável por cada um. Aplicativo sem dono é aplicativo sem revisão.
- Reduzir permissões. Entidade de serviço deve ter acesso apenas aos recursos e às operações de que o aplicativo precisa.
- Restringir quem pode registrar novos aplicativos no ambiente, em vez de deixar essa permissão aberta a qualquer usuário.
- Revisar os registros de autenticação não interativa, que é onde a atividade de aplicativos aparece.
- Proteger o backup com credenciais isoladas do restante do ambiente, como tratamos no artigo sobre backup contra ransomware.
Sinais de que alguém já tem uma credencial sua
O relatório aponta dois códigos de erro de autenticação do Microsoft Entra que funcionam como alerta direto: AADSTS7000215, que indica segredo inválido, e AADSTS7000222, que indica segredo expirado. Em volume, eles significam que alguém está tentando usar uma credencial do seu aplicativo. Uma falha seguida de sucesso é o cenário mais urgente.
Há também padrões de comportamento que valem uma verificação, segundo a Microsoft: um mesmo endereço autenticando em três ou mais entidades de serviço com resultados mistos, ou um mesmo aplicativo pedindo acesso a serviços de gerenciamento, cofre de chaves, armazenamento e API de dados em um intervalo curto. Esse tipo de leitura exige que os registros estejam habilitados e retidos, o que é parte do serviço de monitoramento em TI gerenciada.
Como reduzir a dependência de segredos de longa duração
Rotacionar chaves resolve o incidente. Não resolve a causa. A recomendação da Microsoft é migrar aplicativos para mecanismos que dispensem segredos armazenados, com uso de identidades gerenciadas para autenticação entre serviços. Nesse modelo, a credencial não existe em formato que possa ser copiado para um arquivo, e o ciclo de troca deixa de ser uma tarefa manual.
Para o que não pode ser migrado no curto prazo, valem três controles: prazo de validade curto com troca programada, armazenamento em cofre de chaves com registro de leitura, e política de acesso condicional aplicada a identidades de carga de trabalho. Vale registrar uma limitação apontada no próprio relatório: essa política de acesso condicional exige licenciamento específico e cobre apenas aplicativos registrados no próprio ambiente.
O mesmo raciocínio de ciclo de vida se aplica a certificados. Quem já montou um inventário de certificados digitais tem metade do caminho pronto, porque o controle é o mesmo: saber o que existe, quem é o responsável e quando vence.
O que pedir ao fornecedor de TI e aos integradores
O caso do aplicativo multilocatário mostra que o problema pode não nascer dentro da sua empresa. Se um fornecedor tem um aplicativo com acesso ao seu ambiente e a credencial desse aplicativo vaza, o acesso é legítimo aos olhos do sistema. Perguntas razoáveis de se fazer em contrato e em revisão periódica:
- Quais aplicativos de terceiros têm acesso ao nosso ambiente e com quais permissões?
- Qual é o prazo de troca das credenciais desses aplicativos?
- Quem é notificado, e em quanto tempo, se o fornecedor identificar comprometimento?
- Os registros de acesso desses aplicativos ficam disponíveis para a nossa auditoria?
Para quem presta serviço com acesso delegado a ambientes de clientes, a Microsoft recomenda revisar as relações de administração delegada e comunicar os clientes afetados conforme o contrato. É uma obrigação de mão dupla.
Como a Diversa trata esse controle
A Diversa atua há mais de 20 anos no Rio de Janeiro, com mais de 2.500 dispositivos monitorados e SLA de 99,8%. Em incidentes críticos, a primeira resposta humana ocorre em menos de 30 minutos. Como parceira Microsoft e Acronis Platinum, tratamos inventário de identidades de aplicativo, ciclo de vida de credenciais e revisão de permissões como rotina de governança, não como projeto isolado.
Na prática, isso significa manter a lista de aplicativos e entidades de serviço com dono definido, acompanhar os registros de autenticação não interativa, revisar permissões concedidas a terceiros e garantir que o backup tenha credenciais separadas do restante do ambiente. É um trabalho pouco visível, que aparece justamente quando um relatório como esse é publicado e a pergunta do sócio é se a empresa está exposta. Se esse controle ainda não existe no seu escritório, o nosso trabalho de TI para consultorias começa por esse inventário.