Falso suporte de TI no Teams e depois certificados do domínio: Microsoft detalha duas invasões por meio do AD CS

A Microsoft investigou duas invasões que começaram com falsos técnicos no Teams e continuaram com o abuso do Active Directory Certificate Services. Em um dos casos, certificados de contas privilegiadas levaram ao roubo de dados de um servidor de arquivos. Nenhuma vulnerabilidade do Teams foi explorada: bastaram um funcionário convencido e uma configuração insegura do AD CS.

O que aconteceu

Em um relatório de 30 de outubro de 2026, a Microsoft Threat Intelligence descreve duas invasões conduzidas por operadores humanos em organizações não identificadas. As duas começaram da mesma forma: mensagens e chamadas no Teams de contas que se passavam pela equipe de suporte, para convencer funcionários a abrir uma sessão de Assistência Rápida (Quick Assist) ou semelhante. A Microsoft afirma que nenhuma vulnerabilidade do Teams foi explorada e não atribui a atividade a um ator específico.

Como os atacantes entraram

Primeiro caso (ESC1). Uma primeira onda visou três usuários e comprometeu uma estação de trabalho. Um modelo de certificado mal configurado deu então ao atacante certificados para três contas com privilégios elevados. Cerca de 90 minutos depois da interrupção da primeira sessão, uma segunda onda visou 16 usuários e rendeu certificados para outras oito contas privilegiadas. Segundos depois de obter um deles, o atacante se autenticou em um controlador de domínio e iniciou um DCSync. Uma conta privilegiada havia sido excluída da resposta automática: com ela, o atacante chegou a um servidor de arquivos, de onde uma cópia renomeada do Rclone enviou dados a um destino SFTP externo.

Segundo caso (ESC8). O PetitPotam forçou um controlador de domínio a se autenticar em um sistema controlado pelo atacante. Essa autenticação foi retransmitida ao registro via web do AD CS, o que gerou um certificado e depois um tíquete Kerberos para a conta do controlador. O cliente isolou a estação após os alertas, e a Microsoft não observou mais avanços.

O que fazer agora

1. Controle o Teams e o suporte remoto: limite os domínios externos, permita apenas ferramentas de suporte aprovadas e confirme qualquer pedido de suporte não solicitado por um canal interno conhecido.
2. Audite os modelos de certificado: execute certutil -v -template e procure CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT nos modelos que permitem autenticação. Desative a opção Fornecer na solicitação, restrinja os direitos de registro ou exija a aprovação de um gerente.
3. Proteja o registro via web: faça o inventário dos endpoints Web Enrollment e Certificate Enrollment Web Service e remova os desnecessários. Nos demais, exija HTTPS e defina a proteção estendida para autenticação (EPA) como “Obrigatória”, conforme o KB5005413, e depois execute iisreset /restart.
4. Ative a auditoria da autoridade de certificação para solicitações e emissões. Revogue certificados ilegítimos e verifique também os tíquetes Kerberos: a revogação não invalida os já emitidos.
5. Revise as exclusões de contenção: toda conta fora da resposta automática precisa de um responsável designado e de uma ação manual.

Nossa opinião

O phishing explica a entrada, mas as configurações de certificados explicam a velocidade: uma única estação bastou para chegar a contas de nível de domínio. O AD CS costuma ser instalado uma vez e esquecido, embora mereça a mesma proteção de um controlador de domínio.

Fontes

• Microsoft Security Blog — From help desk impersonation to AD CS abuse: Investigating ESC1 and ESC8 intrusion paths
• Microsoft Support — KB5005413: Mitigating NTLM relay attacks on Active Directory Certificate Services
• Microsoft Learn — Certificates security posture assessment in Defender for Identity
• SpecterOps — Certified Pre-Owned
• The Hacker News — Attackers Pose as IT Support on Microsoft Teams, Abuse AD CS to Steal Company Data

Como escolhemos, verificamos e escrevemos nossas análises →