Um atacante liga pelo Teams se passando pelo suporte técnico e pede para o funcionário abrir o Quick Assist. Minutos depois, o problema já não é um computador: é o Active Directory inteiro. Esse golpe no Teams foi documentado pela Microsoft Threat Intelligence em duas intrusões operadas por humanos, descritas no blog oficial da Microsoft.

Em nenhum dos casos houve falha explorada no Teams. A porta de entrada foi engenharia social. O que transformou um golpe comum em comprometimento de domínio foi o AD CS (Active Directory Certificate Services) mal configurado.

Resumo para quem decide

• Os dois ataques começaram igual: contato pelo Teams fingindo ser a TI e acesso remoto concedido pela vítima via Quick Assist.
• Nos dois ambientes, a configuração do AD CS permitiu ao atacante obter certificados de contas privilegiadas, incluindo a de um controlador de domínio.
• Certificado de autenticação funciona independente da senha. Resetar a senha ou reinstalar a máquina não revoga o certificado nem invalida tickets Kerberos já emitidos.
• No primeiro caso, dados de um servidor de arquivos foram levados para fora. No segundo, o cliente isolou a estação após o alerta e o ataque parou.
• Não há patch: ESC1 e ESC8 são problemas de configuração, e a correção depende de como cada empresa implantou o AD CS.

Como funciona o golpe no Teams

O atacante usa um tenant externo no domínio onmicrosoft.com com nome parecido com o da empresa-alvo e um nome de exibição de “suporte”. A vítima recebe mensagem ou chamada que parece vir do help desk.

O Teams mostrou os avisos “External” e “Scam suspected” nas chamadas, e mesmo assim os usuários seguiram as instruções. Aviso visual não substitui processo de verificação, o mesmo princípio que vale para spear phishing.

Com o controle remoto liberado, o atacante colocou um arquivo compactado na pasta Downloads, criou uma pasta com prefixo “KB” no perfil do usuário, extraiu o conteúdo ali e iniciou a carga com um runtime portátil: Python, JavaScript via Bun ou Java. Como o binário é um interpretador legítimo, bloqueio por nome ou assinatura de arquivo não pega. Em seguida vieram a descoberta de host e de rede e a análise do AD CS, com conexões LDAPS e SMB à infraestrutura do domínio.

Caso 1: ESC1 e o custo de uma exceção

ESC1 é um template de certificado em que o próprio solicitante informa a identidade que o certificado vai representar, e o certificado serve para autenticação. Somado a direitos amplos de enrollment e pouca validação na emissão, permite que uma conta comum peça um certificado em nome de um administrador.

Na primeira onda, o golpe no Teams mirou três funcionários e comprometeu uma estação. A partir dela, o atacante achou um template vulnerável a ESC1 e emitiu certificados para três contas altamente privilegiadas, que não eram as dos funcionários enganados.

O attack disruption do Microsoft Defender restringiu o usuário comprometido e essas três identidades: bloqueou logons remotos e acesso SMB e derrubou as sessões. Mas uma das contas privilegiadas estava configurada como exceção à resposta automática, e a contenção não valeu para ela.

Cerca de 90 minutos depois, uma segunda onda mirou 16 usuários e comprometeu outra estação. Pelo mesmo template, saíram certificados para mais oito contas privilegiadas. O Defender bloqueou mais de 1.000 tentativas de acesso SMB e de logon, mas segundos após obter um certificado o atacante executou DCSync contra um controlador de domínio e extraiu hashes de senha enquanto a contenção ainda acontecia.

A conta que estava na exceção seguiu utilizável. Com ela, o atacante chegou a um servidor de arquivos e rodou uma cópia do Rclone renomeada como SearchApp.exe. O comando copiou um compartilhamento para um servidor SFTP externo, com 20 transferências simultâneas, só arquivos de até três anos e excluindo executáveis, bancos de dados, discos virtuais, mídia, temporários e logs. Foi uma exfiltração escolhida a dedo para levar documentos de negócio.

Caso 2: PetitPotam e ESC8

No segundo ambiente não havia template ESC1 disponível. O atacante usou PetitPotam, via EFSRPC, para forçar o controlador de domínio a se autenticar numa máquina sob seu controle com a conta de máquina do próprio controlador.

Essa autenticação NTLM foi retransmitida (relay) para o AD CS Web Enrollment, que a aceitou mesmo vindo de outro dispositivo. Isso é ESC8. O atacante pediu um certificado com o template “Domain Controller” pelos endpoints em /certsrv e, com ele, usou Kerberos PKINIT para obter um TGT como o controlador de domínio. É o padrão de movimento lateral levado ao extremo: de uma estação comum à identidade do servidor mais sensível da rede.

Aqui o Defender gerou alertas de ESC8, o cliente isolou a estação envolvida e não houve avanço.

A diferença não foi a detecção, foi uma exceção na política de resposta automática.

Por que trocar a senha não resolve

Quando há CVE com patch, como na vulnerabilidade do Microsoft Exchange que já tratamos aqui, o caminho é aplicar a correção e validar. ESC1 e ESC8 não têm CVE nem patch: dependem de como os templates e os endpoints de enrollment foram configurados.

E o certificado emitido continua válido depois que a causa é corrigida. A Microsoft é direta: resetar a senha ou reinstalar a estação inicial não revoga certificados nem invalida tickets Kerberos. A resposta ao incidente precisa revogar explicitamente cada certificado emitido no período e revisar os tickets ativos.

O que fazer

No Teams e no suporte remoto
– Tratar todo contato de suporte não solicitado como suspeito até confirmação por um canal interno conhecido, antes de chamada, compartilhamento de tela ou controle remoto.
– Revisar as políticas de acesso externo e federação do Teams, limitando quem de fora pode iniciar contato.
– Restringir ferramentas de suporte remoto a produtos e operadores aprovados, e alertar quando elas extraem arquivos, sobem interpretadores ou rodam scripts de pastas do usuário.

No AD CS
– Auditar os templates habilitados para autenticação: identidade informada pelo solicitante, enrollment amplo, emissão sem aprovação e propósito maior que o necessário. Remover direitos desnecessários.
– Inventariar os endpoints de Web Enrollment e do Certificate Enrollment Web Service e desligar os que não são usados.
– Exigir HTTPS com Extended Protection for Authentication (EPA), que impede o relay usado no Caso 2, e desabilitar NTLM onde for viável, seguindo a orientação da Microsoft contra NTLM relay no AD CS.
– Ativar a auditoria “Certification Services” (sucesso e falha) e o filtro de auditoria da CA. Sem isso, não dá para reconstruir quem pediu qual certificado.
– Quem usa Defender for Identity tem avaliações de postura específicas para AD CS, que apontam ESC1 e endpoints expostos a ESC8.

Nos endpoints
– Usar controle de aplicação (como App Control for Business) para barrar runtimes não aprovados e scripts em pastas graváveis pelo usuário.
– Testar se as regras ASR cobrem esse tipo de execução. Uma regra pensada para Windows Script Host não necessariamente pega JavaScript via Bun.
– Revisar as exceções da resposta automática. Toda conta privilegiada fora da contenção é um caminho aberto.

Perguntas frequentes

O que são ESC1 e ESC8?
São más configurações do AD CS. Na ESC1, um template deixa o solicitante escolher a identidade do certificado, e uma conta comum consegue um certificado de administrador. Na ESC8, o Web Enrollment aceita NTLM sem proteção contra relay, e o atacante usa uma autenticação capturada para emitir um certificado em nome da vítima, como um controlador de domínio.

O Teams tem uma vulnerabilidade que permite esse golpe?
Não. A Microsoft afirma que não houve exploração de falha no Teams. O golpe no Teams depende de engenharia social e de AD CS mal configurado.

Resetar a senha do usuário comprometido basta?
Não. Certificados emitidos continuam funcionando, e tickets Kerberos já obtidos continuam válidos. É preciso revogar os certificados e revisar os tickets.

Como saber se minha empresa está exposta?
Revise os templates de autenticação (identidade informada pelo solicitante e enrollment amplo indicam ESC1) e os endpoints de Web Enrollment (sem HTTPS, sem EPA e com NTLM indicam ESC8). Esse é um ponto obrigatório de qualquer pentest de Active Directory: as duas falhas são conhecidas há anos e continuam aparecendo em ambientes reais.