Em 2 de setembro de 2026, a Microsoft, empresa de tecnologia dos Estados Unidos, publicou pesquisa sobre uma campanha que simulava atendimento de TI dentro do Microsoft Teams. Contatos externos se apresentavam como pessoal de suporte ou de help desk e levavam o usuário a iniciar uma sessão interativa por software legítimo de assistência remota. A partir desse acesso, os operadores executaram comandos e avançaram pelo ambiente.
O pedido de sessão concentra a decisão. O operador precisava que a pessoa abrisse a ferramenta, informasse um código e aceitasse as permissões solicitadas. O software fazia exatamente o trabalho para o qual foi feito.
O pretexto usava assunto de rotina
Os contatos observados falavam de atualização de segurança, de filtro de spam, de verificação de conta ou de risco de desativação. A conversa acontecia em uma plataforma corporativa e podia ser reforçada por uma chamada de voz. Essa combinação reduz o estranhamento que a mesma abordagem provoca em um e-mail desconhecido.
O Teams marca o contato externo na conversa. A campanha dependia de a pessoa atravessar esse aviso sob pressão de tempo. Um alerta de interface sustenta a decisão quando a operação já ensinou qual é o passo seguinte.
A sessão autorizada entregou capacidade operacional
Depois de obter o controle interativo, segundo o relato, os operadores usaram o PowerShell para baixar e instalar em silêncio um pacote MSI malicioso. A cadeia preparou um runtime Node.js portátil e um implante ofuscado em JavaScript. Em seguida vieram o reconhecimento do host e do Active Directory e capturas periódicas de tela. Cargas adicionais rodaram por componentes nativos do Windows, e conexões WinRM seguiram em direção a servidores e à infraestrutura de identidade.
As ferramentas que transportaram essa cadeia existem em operação comum: Teams, assistência remota, PowerShell, Windows Installer, Node.js e WinRM. O conteúdo malicioso viajou dentro delas, no pacote instalado, no implante e nas cargas seguintes. Segundo a pesquisa, esse caminho permitiu que a atividade se misturasse à operação esperada da empresa em quase todas as etapas.
A pesquisa trata de uma campanha específica. Ela não afirma que toda sessão de assistência remota termine nesse ponto.
O canal de verificação precisa existir antes do pedido
A regra para o usuário é uma frase. Ele mesmo abre o canal interno e confirma o atendimento antes de autorizar qualquer acesso. A frase funciona quando o canal tem endereço conhecido e responde no horário em que o pedido chega.
A empresa sustenta essa regra com um aviso publicado pelo dono da plataforma de suporte, com o canal de confirmação e as ferramentas autorizadas. O aviso precisa estar alcançável fora da rede corporativa, inclusive pelo celular.
O meio de verificação nunca vem do contato que pede a sessão. Um telefone ou um endereço oferecido pelo próprio solicitante devolve a confirmação a quem pode estar conduzindo a fraude.
Leitura NowCy: quem pede, quem aprova e quem define a lista
Uma sessão de assistência remota é um pedido de acesso privilegiado a um dispositivo gerenciado. A NowCy aplica a ela o rito de qualquer elevação: solicitante identificado, aprovador nomeado e prazo curto.
O desenho separa três papéis. O solicitante aparece identificado em um chamado aberto antes da conexão. O aprovador responde pela elevação de privilégio, quando o atendimento depende dela, e o nome dele fica no registro. O dono da plataforma de suporte decide quais ferramentas de acesso remoto a empresa permite e revisa essa lista em prazo definido.
Com os três papéis atribuídos, a decisão sai do julgamento individual sobre a aparência de uma conversa. O funcionário passa a seguir um procedimento, e um argumento plausível pesa menos na decisão.
A janela de correlação do lado técnico
A NowCy propõe uma janela curta de correlação para a sequência relatada. Cinco eventos no mesmo dispositivo e no mesmo dia formam, nessa leitura, um conjunto que merece investigação. São eles o contato externo em ferramenta de colaboração, o início de uma sessão de assistência remota, a execução de PowerShell, uma instalação silenciosa e atividade de reconhecimento.
A Microsoft recomenda tratar como suspeito todo contato externo de suporte que ninguém solicitou. A orientação também pede restringir o acesso externo do Teams a domínios confiáveis, controlar as ferramentas de assistência remota permitidas e aplicar defesas em camadas de identidade, endpoint e colaboração. A própria Microsoft orienta que cada organização ajuste as janelas de tempo ao seu ambiente. O padrão real de suporte entra nesse ajuste, porque uma equipe que atende por assistência remota todos os dias produz o mesmo sinal de forma legítima.
Fontes e limites
A fonte descreve uma campanha observada pela Microsoft. A pesquisa traz só a data de publicação, 2 de setembro de 2026. Os episódios da campanha aparecem sem data. A janela de correlação de cinco eventos é leitura da NowCy. A pesquisa registra que a atividade não decorre de fraqueza no Microsoft Teams e descreve o abuso de recursos legítimos de colaboração. Ela não classifica o Teams, as ferramentas de assistência remota, o Node.js ou o WinRM como software malicioso. A presença de uma ferramenta legítima no pedido também não prova que o atendimento é legítimo. As medidas de restrição precisam respeitar o modelo de colaboração e de suporte de cada empresa.