Uma campanha de intrusão operada por humanos transformou o Microsoft Teams em porta de entrada corporativa: atacantes partindo de um tenant externo se passam por equipe de suporte de TI em contatos externos pelo Microsoft Teams, convencem o funcionário a abrir uma sessão remota e, em seguida, instalam em silêncio um loader MSI que estadia um backdoor em Node.js. A Microsoft detalhou a cadeia completa do ataque em 2 de setembro de 2026, e a Expel documentou de forma independente a família de malware batizada SynkLoader, ligada ao mesmo padrão de golpe. Organizações que mantêm a federação externa do Teams liberada para qualquer domínio são o alvo direto. A ação prioritária é restringir a colaboração externa a domínios confiáveis e monitorar toda sessão de suporte remoto iniciada após um contato não solicitado.
Como o ataque começa
O contato inicial chega por chat ou chamada de um tenant externo com persona de TI ou helpdesk. A isca varia — “Microsoft Security Update”, “Spam Filter Update”, “Account Verification” ou uma tarefa urgente para evitar a desativação da conta —, mas o objetivo é constante: fazer o usuário ignorar os avisos de contato externo, abrir uma sessão de gerenciamento remoto e aceitar a elevação de privilégio. Em parte dos casos, os operadores adicionam voice phishing para conduzir a vítima por voz e manter instruções e URLs fora dos registros do chat.
A entrega do controle é simples: o usuário aprova um “request control” durante um compartilhamento de tela ou abre o Quick Assist e lê o código de conexão em voz alta. A Microsoft ressalta que não existe falha no Teams sendo explorada — a rotulagem de tenant externo, os prompts de aceitação e os indicadores de phishing estão presentes. A cadeia depende de o usuário ignorar essas barreiras de forma voluntária, o que desloca o ponto de falha para o processo humano de verificação de suporte.
O padrão tem parentesco com outras frentes recentes de engenharia social que apostam em confiança e ferramenta legítima: o kit EvilTokens que driblava MFA e os instaladores falsos do Silver Fox seguiram a mesma lógica de se abrigar dentro de fluxos que o usuário considera rotineiros.
Do MSI ao backdoor Node.js
Com o controle interativo estabelecido por ferramenta de suporte remoto, o operador executa PowerShell para baixar um pacote MSI malicioso hospedado em armazenamento em nuvem controlado pelos atacantes e o instala de forma silenciosa com msiexec. O instalador adota nomes benignos como “devfix” ou “Hotfix”, reforçando o pretexto de manutenção técnica.
O MSI grava um loader baseado em script e um implante criptografado no diretório LocalAppData do usuário. Se o Node.js não estiver presente, o bootstrap baixa o runtime portátil oficial da distribuição Node.js — um binário assinado e legítimo — e o extrai em um diretório com nome aleatório. O loader então descriptografa o implante em memória ou em um arquivo JavaScript temporário e o executa sob node.exe. O resultado é um canal de comando e controle com polling HTTPS randomizado, capaz de receber tarefas em JavaScript diretamente do servidor dos atacantes. As detecções associadas incluem as assinaturas Trojan:JS/SynkLoader.SA e Trojan:JS/EtherRatz, além de alertas comportamentais como processos Node.js suspeitos.
A Expel chegou a uma variante dessa cadeia por caminho próprio, ao investigar um incidente em rede de cliente em 18 de agosto. O ataque começou com mensagem de Teams de um remetente @onmicrosoft.com identificado como IT Service Desk, que convenceu a vítima a instalar um MSI hospedado em endpoint de armazenamento Azure da Microsoft e apresentado como “PowerShell Cleaner”. O pacote extraía um script PowerShell, um ambiente Python embutido, bibliotecas pré-compiladas e DLLs falsas de runtime Microsoft. Entre os módulos recuperados estão o PhishLocker, uma tela de bloqueio falsa praticamente idêntica à do Windows que captura a senha de login da vítima, um túnel reverso que permite alcançar serviços internos a partir da máquina infectada, um RAT PowerShell e um módulo VNC com streaming de área de trabalho. Segundo a análise, os carimbos de tempo dos arquivos indicam que a família foi compilada e distribuída pela primeira vez por volta de 28 de julho de 2026. O interesse do malware em medir o tamanho do ambiente Active Directory sugere preparação para operações de ransomware.
Reconhecimento e movimento lateral
Depois do implante ativo, o operador executa reconhecimento extenso do host e do Active Directory com comandos nativos e buscas ADSI, incluindo a coleta de atributos de descrição de usuários, que podem conter notas operacionais e contexto de contas privilegiadas. Capturas periódicas de tela acompanham a sessão e orientam os próximos passos do atacante.
O pivô interno vem em seguida: o backdoor dispara conexões WinRM na porta TCP 5985 contra um grande conjunto de sistemas do domínio. A lista de alvos observada pela Microsoft inclui servidores de arquivos, servidores de banco de dados e de aplicação e, de forma crítica, controladores de domínio e autoridades de certificação. Payloads adicionais entram por rundll32 carregando DLLs fornecidas pelo atacante, mantendo a execução dentro de binários assinados e confiáveis do Windows.
Sinais para caçar agora
| Sinal | Onde procurar | Leitura |
|---|---|---|
| Quick Assist ou assistência remota seguida de cmd.exe ou PowerShell na mesma área de trabalho | Telemetria de processos no EDR | Sessão de suporte convertida em execução de comandos |
| Instalação silenciosa de MSI com /qn tendo PowerShell como processo pai | Logs de processo e eventos MSI | Staging do loader malicioso |
| node.exe executando de LocalAppData ou de caminho fora do padrão | EDR e políticas WDAC/AppLocker | Backdoor JavaScript sobre runtime legítimo |
| WinRM iniciado por processo em contexto de usuário | Eventos WinRM e firewall | Movimento lateral credenciado |
| Tarefa agendada criada via interface COM | Detecção comportamental no EDR | Persistência característica do SynkLoader |
| Chat externo do Teams com persona de TI após rajada de e-mails | Logs de colaboração e gateway de e-mail | Prelúdio clássico do golpe de helpdesk |
Defesas prioritárias P1 e P2
Ações P1 para esta semana:
- Restringir o acesso externo do Teams a uma lista de domínios parceiros confiáveis e tratar qualquer contato de suporte não solicitado como suspeito, verificado por canal interno conhecido antes de qualquer sessão remota.
- Instituir frase de autenticação verbal entre helpdesk e funcionários e treinar o reconhecimento dos indicadores de remetente externo no Teams.
- Bloquear node.exe fora de caminhos aprovados com WDAC ou AppLocker e ativar regras ASR que impeçam conteúdo executável vindo de interpretadores de script.
- Diante de confirmação de comprometimento, isolar o host, forçar reset de senha, revogar tokens e sessões no Entra ID e reemitir fatores MFA.
Ações P2 para o ciclo seguinte:
- Limitar o WinRM a estações de gerenciamento autorizadas e gerar alerta para WinRM iniciado de contexto de usuário.
- Monitorar a iniciação de chats externos por domínios recém-registrados ou typosquatados e auditar ferramentas RMM instaladas contra o inventário aprovado.
- Estender o treinamento anti-phishing para além do e-mail, com cenários reais de mensagem de suporte não solicitada e pedido de aprovação de MFA.