A Microsoft relatou duas intrusões que começaram com pessoas se passando por profissionais de suporte no Microsoft Teams e avançaram para o abuso do Active Directory Certificate Services (AD CS), serviço que emite certificados digitais. O Teams foi usado como canal de engenharia social; a Microsoft não descreveu uma falha de software do aplicativo. O relato foi publicado em 30 de outubro de 2026. (Microsoft)
Nos dois casos, os invasores convenceram funcionários a conceder acesso remoto, principalmente pelo Quick Assist. Depois, seguiram caminhos diferentes para obter certificados capazes de autenticar contas privilegiadas. As respostas também tiveram resultados distintos.
Do contato no Teams ao acesso remoto
Os contatos vinham de fora das organizações e podiam usar nomes que pareciam ligados à empresa ou ao suporte técnico. Após iniciar uma conversa ou chamada no Teams, os invasores persuadiam os funcionários a abrir uma sessão de assistência remota. Isso fez do contato externo e da sessão autorizada pelo usuário partes importantes da sequência investigada.
Dois caminhos diferentes pelo AD CS
No primeiro caso, uma configuração insegura de um modelo de certificado, chamada ESC1, permitia que solicitantes fornecessem informações de identidade e obtivessem certificados em nome de contas privilegiadas. A primeira onda envolveu três usuários e um computador, e gerou certificados para três contas privilegiadas. Cerca de 90 minutos depois, uma segunda onda atingiu 16 usuários e outro computador, e resultou em certificados para mais oito contas privilegiadas.
A Microsoft relatou que uma atividade DCSync, usada para replicação de dados do diretório, começou segundos depois da emissão de um certificado privilegiado. A contenção automática bloqueou mais de mil tentativas posteriores de acesso a arquivos por SMB e de logon. Mas uma conta privilegiada estava excluída desse processo e continuou utilizável. Os invasores a usaram para acessar um servidor de arquivos e transferir dados para um destino SFTP externo.
No segundo caso, o PetitPotam usou solicitações EFSRPC para induzir um controlador de domínio a se autenticar por NTLM. Os invasores retransmitiram essa autenticação ao serviço de inscrição na Web do AD CS, uma técnica conhecida como ESC8, e obtiveram um certificado para a conta do controlador. Em seguida, usaram autenticação Kerberos baseada em certificado, chamada PKINIT, para solicitar um TGT, ou tíquete de concessão de tíquete. A Microsoft informou que o cliente isolou o computador associado e que, depois disso, não observou nova progressão do ataque.
| Caso | Caminho de certificados | Resposta e resultado relatados |
| ESC1 | Modelo de certificado mal configurado permitiu certificados para contas privilegiadas. | A contenção bloqueou mais de mil tentativas posteriores, mas uma conta excluída da contenção foi usada para acessar um servidor e transferir dados. |
| PetitPotam e ESC8 | Autenticação NTLM do controlador de domínio foi retransmitida ao serviço de inscrição na Web do AD CS; o certificado foi usado em uma solicitação Kerberos por PKINIT. | O cliente isolou o computador associado; a Microsoft não observou progressão adicional depois disso. |
Sinais para investigar em conjunto
A Microsoft descreveu quatro categorias de consultas de hunting, isto é, buscas por atividade suspeita nos registros de segurança: contatos externos e sinais de falsa identidade no Teams; execução de Bun ou Java em diretórios de preparação cujo nome começa com “KB”; atividade de rede iniciada por esses runtimes; e alertas ligados a retransmissão NTLM, Certificate Services, PKINIT ou solicitações de tíquetes Kerberos. As consultas de rede consideram tráfego nas portas 80, 445, 636 e 88.
Esses sinais ganham contexto quando relacionados à sessão remota, à sequência de processos no computador e à emissão de certificados. A Microsoft recomenda ajustar as consultas ao ambiente e investigar as correspondências; um alerta isolado não confirma uma invasão. Arquivos compactados e runtimes portáteis de Python, Bun ou Java também apareceram na atividade relatada. O nome de um arquivo, por si só, não basta: caminho, processos que o iniciaram, sessão remota e atividade posterior ajudam a contextualizar o achado.
A Microsoft também publicou três hashes SHA-256 de scripts associados ao acesso inicial:
- JavaScript:
85b6c424117494d3056e88689dbc94c75e9afdb187a339714043aec0da109f17 - Python:
f326201269f1ee2f803ae435317507263bb6e0dbfdeb70bd1bb5446e2e46f001 - Python:
06c5c14f043aee3bcc5843b5f50909623d5c9a6239a7c1fba9cddad4111469e7
Os hashes são indicadores para investigação, não prova isolada de comprometimento.
Resposta a contatos e certificados suspeitos
A Microsoft recomenda que funcionários confirmem pedidos inesperados de suporte por canais internos conhecidos, que as organizações revisem a necessidade de aceitar contatos externos no Teams e que o acesso remoto siga fluxos aprovados.
Para o AD CS, as medidas incluem revisar modelos de certificado que aceitam informações de identidade fornecidas pelo solicitante, permissões de inscrição amplas ou controles de emissão fracos. A Microsoft também recomenda remover serviços de inscrição na Web desnecessários, exigir HTTPS e Extended Protection for Authentication (EPA), desabilitar NTLM nesses serviços quando viável e habilitar auditoria de certificados. (Orientação da Microsoft sobre relay NTLM no AD CS; avaliação de certificados do Microsoft Defender for Identity)
Trocar uma senha ou reimaginar o computador inicial não revoga um certificado já emitido nem invalida tíquetes Kerberos emitidos anteriormente. A resposta precisa incluir a identificação e revogação do certificado não autorizado, a atualização das informações de revogação e a análise dos tíquetes ativos. Contas ou dispositivos excluídos da contenção automática também precisam de uma ação manual compensatória.
