Falso suporte de TI no Microsoft Teams: campanha Spring Ring transforma chamadas corporativas em vetor de ataque
Uma mensagem aparentemente rotineira do suporte técnico pode ser suficiente para iniciar um comprometimento corporativo. Uma campanha de engenharia social identificada pela Unit 42, da Palo Alto Networks, mostra criminosos utilizando contas externas do Microsoft Teams, chamadas de voz e ferramentas legítimas de administração remota para se passar pelo departamento de TI das empresas.
Batizada de Spring Ring, a operação abordou mais de 150 funcionários de pelo menos dez organizações, de diferentes setores, entre janeiro e abril de 2026. O aspecto mais importante do caso, entretanto, não está apenas no número de vítimas: a campanha demonstra como os criminosos estão transferindo técnicas tradicionalmente associadas ao phishing por e-mail para plataformas corporativas nas quais os usuários tendem a depositar maior confiança.
Não há evidência de que a campanha explore uma vulnerabilidade do Microsoft Teams. O ataque explora principalmente identidade, confiança e comportamento humano, utilizando funcionalidades legítimas da plataforma como meio de aproximação.
O ataque começa onde o funcionário trabalha todos os dias
Segundo a investigação da Unit 42, os criminosos criaram identidades externas do Microsoft 365 cuidadosamente preparadas para parecer integrantes legítimos da estrutura de suporte das empresas.
As contas utilizavam nomes como IT Help Desk, IT Assistance e Support Staff, além de tenants externos .onmicrosoft.com contendo expressões relacionadas a infraestrutura, redes, suporte e segurança.
Em vez de enviar simplesmente um link malicioso e esperar que alguém clique, os operadores adotaram uma abordagem muito mais interativa.
O funcionário recebe inicialmente uma solicitação de conversa de uma identidade externa no Microsoft Teams. Depois do primeiro contato, o suposto técnico inicia uma chamada de voz e apresenta algum problema que exigiria intervenção imediata.
É nesse momento que entra o vishing — voice phishing.
Uma conversa em tempo real permite ao criminoso perceber hesitação, adaptar os argumentos, responder perguntas e criar uma sensação de legitimidade difícil de obter em um e-mail tradicional. O atacante deixa de depender exclusivamente de uma página falsa e passa a conduzir diretamente o comportamento da vítima.
A Unit 42 observou inclusive operadores realizando diversas tentativas consecutivas, deixando mensagens de voz e alternando entre funcionários. Quando a abordagem evoluía, as conversas bem-sucedidas podiam durar entre dez e quinze minutos.
Do falso chamado de suporte ao controle remoto do computador
A investigação encontrou pelo menos duas cadeias técnicas distintas depois que a engenharia social obtinha sucesso.
Em uma delas, o falso técnico orientava a vítima a executar ferramentas legítimas de Remote Monitoring and Management (RMM) ou o próprio Windows Quick Assist, recurso da Microsoft destinado justamente à assistência remota.
Essa característica torna a técnica especialmente problemática.
O atacante não precisa necessariamente explorar uma vulnerabilidade para obter a primeira sessão interativa. Ele convence o próprio usuário a abrir uma ferramenta legítima e autorizar o acesso.
Com o controle estabelecido, os operadores observados pela Unit 42 executaram comandos de reconhecimento do ambiente, incluindo consultas destinadas a identificar grupos do usuário e informações sobre o domínio corporativo.
Em seguida, PowerShell foi utilizado para recuperar um Remote Access Trojan (RAT) ofuscado de infraestrutura controlada pelos atacantes. Segundo os pesquisadores, o código procurava ainda interferir no Antimalware Scan Interface (AMSI) e estabelecer comunicação com infraestrutura de comando e controle (C2).
O comprometimento, portanto, atravessa uma fronteira importante: aquilo que começou como uma conversa aparentemente legítima dentro de uma ferramenta corporativa pode terminar em execução de código malicioso no endpoint.
Uma segunda variante tentou chegar ao domínio corporativo
A segunda cadeia identificada na Spring Ring foi ainda mais preocupante.
Durante a chamada, a vítima era direcionada para infraestrutura hospedada em nuvem contendo referências personalizadas à empresa e ao próprio funcionário. O objetivo era tornar o download apresentado pelo suposto suporte de TI mais convincente.
Após executado, o malware estabelecia persistência, criava cópias adicionais de executáveis e utilizava uma instância oculta do Microsoft Edge para carregar uma extensão.
A cadeia avançava então para reconhecimento da rede interna.
Os pesquisadores observaram Python sendo utilizado para realizar varreduras SMB pela porta TCP 445 e gerar autenticações NTLM direcionadas ao controlador de domínio.
Na etapa seguinte, os atacantes tentaram utilizar PetitPotam, técnica capaz de provocar autenticação NTLM de determinados sistemas Windows para infraestrutura controlada pelo adversário. Associada a condições vulneráveis de configuração, essa coerção pode ser utilizada em ataques de NTLM Relay.
No caso analisado, a tentativa de comprometimento em nível de domínio foi bloqueada pelo serviço de Managed Detection and Response da Unit 42.
O episódio demonstra, entretanto, a distância que um atacante pode percorrer depois de convencer apenas um funcionário de que está conversando com o suporte técnico.
Microsoft Teams não foi comprometido
Há uma distinção importante para evitar uma interpretação equivocada do incidente.
A Unit 42 afirma não possuir evidências de vulnerabilidade ou comprometimento do Microsoft Teams relacionado à campanha. Os criminosos estão utilizando funcionalidades legítimas e contas externas controladas por eles.
Isso transforma a Spring Ring essencialmente em um ataque contra confiança e identidade, e não em uma exploração técnica da plataforma.
O problema também não é exclusivo desta campanha.
Em 2024, a Microsoft já havia documentado atividade do grupo rastreado como Storm-1811, associado à implantação do ransomware Black Basta, utilizando mensagens e chamadas pelo Teams para se passar por funcionários de suporte.
Naquela operação, criminosos também convenciam usuários a conceder acesso utilizando o Windows Quick Assist. Depois do acesso inicial, a Microsoft observou atividades relacionadas a roubo de credenciais, execução de scripts, ferramentas de administração remota e outros componentes utilizados na progressão do ataque.
Campanhas posteriores continuaram explorando a mesma combinação: comunicação corporativa legítima, engenharia social, ferramentas de suporte remoto e interação humana.
O padrão sugere que o Microsoft Teams deve ser considerado atualmente parte da superfície de ataque de engenharia social das organizações — da mesma forma que e-mail, telefone, SMS e outras plataformas de comunicação.
O phishing está deixando de ser apenas e-mail
Os dados apresentados pela Unit 42 ajudam a dimensionar essa mudança.
Nos primeiros quatro meses de 2026, alertas de phishing provenientes de ferramentas de colaboração representaram 42% dos alertas de phishing observados pelo Cortex, contra 30% nos quatro meses anteriores.
A empresa também cita dados da KnowBe4 indicando crescimento de 41% nos ataques baseados em Teams entre outubro de 2025 e março de 2026.
Esses números não significam que o e-mail deixou de ser relevante. Eles mostram que os adversários perceberam uma diferença comportamental importante.
Funcionários foram treinados durante anos para desconfiar de remetentes externos, anexos inesperados e links recebidos por e-mail. Uma chamada aparecendo dentro da ferramenta utilizada diariamente para conversar com colegas, gestores e equipes técnicas pode receber um nível de confiança diferente.
A interface legítima passa a funcionar como parte da engenharia social.
A identidade se tornou parte central do perímetro
Campanhas como Spring Ring reforçam uma transformação que já vinha ocorrendo na segurança corporativa: proteger somente endpoints e redes não é suficiente quando o atacante consegue operar através de identidades aparentemente legítimas e aplicações SaaS autorizadas.
Um controle de segurança eficaz precisa considerar não apenas quem realizou uma autenticação, mas também se o comportamento posterior é compatível com aquela identidade.
Um usuário que normalmente não utiliza ferramentas RMM e repentinamente executa uma delas após receber uma chamada de um tenant externo representa um contexto completamente diferente de um administrador autorizado executando a mesma ferramenta.
Da mesma maneira, uma identidade externa denominada “IT Help Desk” iniciando conversas e rapidamente realizando chamadas para cinco ou seis funcionários deve ser tratada como um sinal comportamental relevante.
É justamente nessa correlação que tecnologias de Identity Threat Detection and Response (ITDR), EDR/XDR, SIEM e análise comportamental podem complementar os controles preventivos.
Como reduzir o risco
A primeira medida é revisar a necessidade de comunicação irrestrita com organizações externas pelo Microsoft Teams.
A própria documentação da Microsoft informa que, por padrão, organizações externas podem ser permitidas e que administradores podem restringir essa comunicação utilizando listas de domínios permitidos ou bloqueados. Dependendo da necessidade operacional, empresas podem adotar políticas mais restritivas para usuários ou grupos específicos.
Isso não significa necessariamente bloquear toda comunicação externa. Organizações que dependem do Teams para comunicação com fornecedores, clientes e parceiros provavelmente precisam manter algum nível de federação.
O princípio adequado é permitir somente aquilo que possui justificativa de negócio e controlar o restante proporcionalmente ao risco.
Outro controle importante é estabelecer um procedimento verificável para atendimento remoto.
Um funcionário não deveria instalar software, fornecer credenciais, executar comandos ou conceder controle remoto simplesmente porque alguém apareceu no Teams utilizando o nome “Suporte de TI”.
Chamados legítimos podem ser confirmados por um canal independente, como portal corporativo de service desk, número interno previamente conhecido ou mecanismo formal de identificação do técnico.
A regra é simples: a pessoa que inicia o contato não deve ser também a única fonte utilizada para provar sua própria identidade.
Quick Assist e ferramentas RMM precisam entrar na política de segurança
Ferramentas de suporte remoto são extremamente úteis para administração corporativa, mas exatamente essa capacidade também interessa aos atacantes.
Empresas devem conhecer quais soluções RMM estão autorizadas, quem pode executá-las e em quais circunstâncias.
A execução inesperada de Quick Assist, AnyDesk, ScreenConnect, NetSupport, TeamViewer ou outras ferramentas semelhantes por usuários que normalmente não necessitam delas pode justificar investigação.
Quando possível, controles de aplicação, EDR/XDR e políticas de endpoint podem limitar softwares não autorizados ou gerar alertas quando ferramentas de administração remota surgirem fora do comportamento esperado.
Isso não constitui um requisito universal: a implementação depende da arquitetura, necessidade operacional e avaliação de risco de cada organização.
MFA continua importante, mas não resolve tudo
Autenticação multifator (MFA) continua sendo um controle fundamental, especialmente quando implementada com mecanismos resistentes a phishing. CISA recomenda que organizações priorizem phishing-resistant MFA, particularmente para contas administrativas e acessos a sistemas críticos.
Mas Spring Ring demonstra por que MFA não deve ser confundida com uma solução completa contra engenharia social.
Se o funcionário concede deliberadamente uma sessão remota a alguém que acredita ser um técnico legítimo, o atacante pode obter capacidade operacional sem necessariamente precisar quebrar o mecanismo de autenticação naquele primeiro momento.
Por isso, identidade forte precisa ser combinada com least privilege, controle de aplicações, proteção de endpoints, monitoramento comportamental e processos de verificação humana.
Treinamento também precisa acompanhar a mudança do ataque
Programas de conscientização ainda excessivamente concentrados em “não clicar em links de e-mail” deixam uma lacuna cada vez maior.
O NIST Cybersecurity Framework 2.0 trata conscientização e treinamento na categoria PR.AT — Awareness and Training, incluindo a necessidade de fornecer conhecimento e habilidades para que profissionais executem suas atividades considerando riscos de segurança.
No cenário atual, esse treinamento precisa incluir Teams, Slack, Zoom, WhatsApp, chamadas telefônicas, solicitações de MFA, compartilhamento de tela e ferramentas de suporte remoto.
Simulações também podem reproduzir essas situações de maneira controlada.
O objetivo não deve ser ensinar funcionários a desconfiar de toda interação, mas criar mecanismos simples para que consigam verificar rapidamente uma interação legítima sem depender da aparência do interlocutor.
Indicadores que merecem atenção
Para equipes de SOC e resposta a incidentes, a investigação da Spring Ring oferece alguns comportamentos particularmente úteis para detecção: identidades externas utilizando nomes relacionados a suporte ou administração de TI; transição rápida de chat para chamada de voz; várias chamadas consecutivas para diferentes funcionários; execução inesperada de ferramentas RMM; acesso a executáveis hospedados em serviços de nuvem; atividade incomum de PowerShell; varredura SMB; autenticações NTLM anômalas e comportamento de coerção ou relay envolvendo controladores de domínio.
Nenhum desses eventos isoladamente comprova um ataque. A correlação entre eles, entretanto, pode revelar a progressão da cadeia antes que o adversário alcance ativos críticos.
O verdadeiro exploit pode ser a confiança
Spring Ring representa uma tendência importante para CISOs, equipes de segurança e gestores de risco: plataformas corporativas confiáveis também podem funcionar como infraestrutura para engenharia social.
Não foi necessário comprometer o Microsoft Teams para utilizá-lo como porta de entrada.
Os atacantes exploraram algo mais difícil de corrigir com um patch: a associação mental entre ferramenta corporativa + aparência profissional + suporte técnico = confiança.
Essa equação precisa mudar.
Em ambientes modernos, uma solicitação de suporte deve ser considerada legítima porque sua identidade e seu processo foram verificados — não simplesmente porque apareceu dentro de uma aplicação legítima.
À medida que phishing, vishing e ataques orientados por identidade migram para aplicações SaaS, a segurança precisa acompanhar a mesma trajetória. A fronteira entre segurança técnica e comportamento humano está desaparecendo, e proteger essa nova superfície exige controles que conectem identidade, endpoint, aplicações, processos e pessoas.
Referências
- Palo Alto Networks Unit 42 — Spring Ring: An Inside Look at Voice Phishing Campaigns in Microsoft Teams
- GBHackers — Hackers Pose as IT Support on Microsoft Teams to Target More Than 150 Employees
- Microsoft Security — Threat actors misusing Quick Assist in social engineering attacks leading to ransomware
- Microsoft Security — Help on the line: How a Microsoft Teams support call led to compromise
- Microsoft Security — Cross-tenant helpdesk impersonation to data exfiltration: A human-operated intrusion playbook
- Microsoft Learn — Manage external meetings and chat with people and organizations using Microsoft identities
- Microsoft Support — Prevent spam or phishing attempts from external chats in Microsoft Teams
- CISA — Implementing Phishing-Resistant MFA
- NIST — Cybersecurity Framework 2.0
Clique e fale com representante oficial Sophos
Veja também:
- Principais ataques cibernéticos no Brasil em agosto de 2026: ransomware, invasões e vazamentos
- Orçamento de Cibersegurança no Brasil: como a IA está mudando os investimentos
- Privacidade deixou de ser apenas uma obrigação legal
- O excesso de alertas está tornando as empresas mais vulneráveis?
- Aumento do “Shadow AI” no Brasil
- O excesso de alertas está tornando as empresas mais vulneráveis?
- Além do isolamento da chave privada
- Cibersegurança: de despesa a estratégia de crescimento
- IA a serviço do crime?
- Shadow AI: 3 medidas para reduzir o risco de cibersegurança
- O maior risco para os sistemas industriais não é a computação quântica, e sim esperar por ela
- Milhares de credenciais AWS vazadas continuam ativas
Be the first to comment