Uma conversa aparentemente banal no Microsoft Teams, iniciada por uma conta externa com um nome que soa a departamento de informática, seguida de uma chamada de voz em segundos. É este o guião de uma operação coordenada de voice phishing (vishing) documentada pela equipa de inteligência de ameaças Unit 42, da Palo Alto Networks, que a batizou de Spring Ring. Segundo a investigação, entre janeiro e abril de 2026 os atacantes usaram contas externas do Microsoft Teams para se fazerem passar por pessoal de help desk, atingindo mais de 150 colaboradores em pelo menos 10 empresas de vários setores; durante as chamadas tentavam levar as vítimas a executar ferramentas de gestão e monitorização remota (RMM) ou malware personalizado, e numa variante mais avançada evoluíram para um ataque de relay NTLM dirigido ao controlador de domínio da organização.
Resposta rápida: A campanha Spring Ring usou contas externas do Microsoft Teams, alojadas em tenants .onmicrosoft.com controlados pelos atacantes, para simular equipas internas de suporte informático e convencer trabalhadores a dar acesso remoto aos seus computadores. Não houve exploração de qualquer vulnerabilidade do Teams: o abuso incide sobre a funcionalidade de conversa com utilizadores externos, ativa por predefinição em muitas organizações. A ação recomendada é restringir o acesso externo no Teams, bloquear ferramentas RMM não aprovadas (incluindo o Quick Assist) e definir um canal único e verificável de contacto do suporte interno.
Identidades credíveis, sem uma única falha de software
O ponto mais desconfortável desta operação é a simplicidade. Não há CVE associado, não há exploração de memória nem zero-day: há um humano ao telefone. As contas usadas estavam alojadas em tenants .onmicrosoft[.]com controlados pelos adversários, com designações que incluíam termos de sabor corporativo como «internal», «network», «certified» e «infrastructure», e a Unit 42 sublinhou que a atividade não resultou de qualquer vulnerabilidade ou compromisso do próprio Microsoft Teams. Entre os nomes de tenant observados constam exemplos como «ITProtectionDepartment» ou «MandatoryNetworkMonitoring», construídos para se assemelharem a departamentos internos de TI.
O padrão de contacto é reconhecível: um dos principais indicadores é a transição rápida de um pedido de conversa individual para uma chamada de áudio não solicitada. Depois de iniciar o chat, os atacantes telefonavam às vítimas fazendo-se passar por técnicos, usando a conversa em tempo real para criar confiança e persuadir os trabalhadores a executar ações no computador — algumas chamadas duraram 10 a 15 minutos, outras foram curtas ou terminaram em correio de voz. A Unit 42 identificou 26 identidades distintas de atacante associadas à campanha.
Dois caminhos depois da chamada
A investigação separa a atividade em duas campanhas com objetivos técnicos diferentes. Na Campanha A, o atacante seguiu uma abordagem de «traz a tua própria ferramenta», orientando o colaborador a lançar utilitários nativos do Windows como o Quick Assist ou a instalar software RMM de terceiros; obtido o controlo remoto, executava comandos básicos de enumeração do sistema e do domínio e, depois de confirmar o valor do ambiente, usava a linha de comandos do PowerShell para descarregar um trojan de acesso remoto ofuscado a partir do domínio san-sid[.]com, com manipulação de variáveis e ofuscação aritmética para evadir análise automática e sandboxes.
A Campanha B foi mais elaborada. As vítimas eram encaminhadas para executáveis alojados na cloud cujos nomes de ficheiro incluíam o nome da empresa e do colaborador visado; após a execução, o malware copiava-se para o diretório temporário, criava cópias adicionais para persistência, lançava uma instância oculta do Microsoft Edge, carregava lateralmente uma extensão de browser e recorria a um executável Python empacotado, gerando depois tráfego SMB para sistemas internos e tentativas de autenticação NTLM contra o controlador de domínio. O passo final foi uma tentativa de ataque PetitPotam para coagir o controlador de domínio a autenticar-se numa máquina controlada pelo atacante — um relay NTLM concebido para obter privilégios ao nível do domínio —, tentativa que foi bloqueada pelo serviço de deteção e resposta geridas da Unit 42.
| Elemento | Campanha A | Campanha B |
|---|---|---|
| Acesso inicial | Chamada Teams a partir de conta externa | Chamada Teams a partir de conta externa |
| Execução | Quick Assist ou RMM de terceiros | Executável personalizado alojado na cloud |
| Segunda fase | RAT em PowerShell ofuscado (evasão de AMSI) | Edge oculto, extensão carregada lateralmente, componente Python |
| Objetivo observado | Persistência e comunicação com C2 | Relay NTLM via PetitPotam contra o controlador de domínio |
| Desfecho nos casos observados | Execução bloqueada | Tentativa de tomada do domínio bloqueada |
Indicadores: poucos artefactos, muito comportamento
Ao contrário de campanhas de malware clássicas, esta operação oferece poucos indicadores atómicos publicamente úteis. O domínio san-sid[.]com é o artefacto de rede mais concreto divulgado. A deteção terá, por isso, de ser sobretudo comportamental. Entre os sinais apontados estão conversas não solicitadas de utilizadores externos no Teams, transições rápidas de chat para chamada de voz, execução invulgar de ferramentas RMM, descarregamentos inesperados a partir de armazenamento na cloud, extensões de browser raras e atividade anómala de SMB ou NTLM.
- Correlacionar metadados de chamadas do Teams com arranque de RMM, execução de PowerShell e tráfego SMB para o mesmo utilizador, em vez de tratar cada alerta isoladamente.
- Vigiar contas externas em tenants
.onmicrosoft.comdesconhecidos que contactem vários colaboradores em pouco tempo. - Alertar para autenticações NTLM anómalas dirigidas a controladores de domínio, típicas de coerção do tipo PetitPotam.
- Sinalizar execuções de
Quick Assistou de RMM por utilizadores sem função de suporte técnico.
O Teams passou a ser porta de entrada preferida
Spring Ring não é um caso isolado, mas sim mais um sintoma de uma migração do phishing do correio eletrónico para as plataformas de colaboração. A Unit 42 refere que os alertas envolvendo ferramentas de colaboração representaram 42% de todos os alertas de phishing na sua telemetria Cortex nos primeiros quatro meses de 2026, contra 30% no período de quatro meses anterior.
Os dados do próprio fabricante apontam no mesmo sentido. A Microsoft indicou que o vishing através do Teams registou o crescimento mais acentuado de todas as categorias de ameaça acompanhadas no segundo trimestre de 2026, com uma subida de 31% nas tentativas semanais de abril para maio e mais 27% em junho, e com o volume semanal a atingir cerca de dez vezes a linha de base de meados de 2025. A empresa observou ainda que as chamadas são cronometradas para os períodos de maior atividade dos alvos, sobretudo entre as 14:00 e as 20:00 UTC, de segunda a sexta-feira.
O risco real fica claro quando se olha para campanhas paralelas. A Sophos documentou um cluster distinto, rastreado como STAC4749: uma campanha de vishing no Teams que usou domínios e personas com temática de TI para obter acesso remoto e que, entre fevereiro e junho de 2026, visou dezenas de organizações norte-americanas, culminando em vários incidentes na implantação de ransomware Chaos. Num dos ataques, o percurso entre o acesso inicial e a cifragem dos ficheiros demorou menos de 17 horas. Nesse caso, os operadores privilegiaram inicialmente o Quick Assist, recorrendo à ferramenta RMM em cloud RemSupp quando o primeiro estava bloqueado, e a partir de abril passaram a preferir a RemSupp, provavelmente por ser menos frequente em listas de bloqueio de aplicações.
A técnica também não é nova. Desde meados de abril de 2024 que a Microsoft Threat Intelligence observa o grupo Storm-1811, financeiramente motivado e associado ao ransomware Black Basta, a abusar do Quick Assist em ataques de engenharia social, usando o Teams para enviar mensagens e iniciar chamadas fazendo-se passar por pessoal de TI. O que mudou foi a escala, a profissionalização das personas e a rapidez com que o acesso obtido é convertido em extorsão — ou vendido a quem a pratica.
Medidas concretas de mitigação
- Restringir o acesso externo no Teams. Limitar a comunicação externa a domínios explicitamente autorizados, em vez de manter a conversa aberta a qualquer tenant.
- Controlar as ferramentas de acesso remoto. Bloquear ou restringir o
Quick Assiste manter uma lista de permissões de RMM aprovados, com alertas para tudo o resto. - Definir um canal oficial de suporte. Regra simples e comunicada a toda a organização: o suporte interno nunca contacta por chamada Teams de uma conta externa nem pede a instalação de software durante a chamada.
- Endurecer o Active Directory contra relay NTLM. Assinatura SMB e LDAP, Extended Protection for Authentication e redução da exposição de serviços suscetíveis a coerção de autenticação.
- Formar com simulações realistas. Incluir vishing e cenários de falso help desk nos exercícios de sensibilização, não apenas e-mails fraudulentos.
- Preparar a resposta. Um procedimento claro para o colaborador que já concedeu acesso remoto — isolar o posto, revogar sessões e credenciais, notificar a equipa de segurança.
Porque é que isto importa em Portugal
O Microsoft 365 é omnipresente na administração pública e no tecido empresarial português, e a funcionalidade de comunicação externa do Teams está frequentemente ativa por predefinição. Não é preciso ser alvo de uma campanha norte-americana para estar exposto: a técnica é replicável em qualquer idioma e a barreira de entrada é baixa.
O sinal nacional já existe. No relatório «Riscos & Conflitos» do Observatório de Cibersegurança do CNCS, o vishing surge como a técnica de engenharia social mais observada pelo CERT.PT, identificada em 170 incidentes, ou 18,31% do total, o que representou um aumento de 136%. O CNCS mantém orientações públicas sobre phishing, smishing e vishing, recomendando às organizações a realização de simulações de ataque e a denúncia junto dos responsáveis de segurança, e o CERT.PT pede que as campanhas lhe sejam reportadas para acompanhamento e indicação de medidas de mitigação.
Do ponto de vista regulatório, um incidente com acesso remoto interativo a postos de trabalho e tentativa de comprometimento do controlador de domínio é exatamente o tipo de evento que o novo Regime Jurídico da Cibersegurança, aprovado pelo Decreto-Lei n.º 125/2025 que transpõe a Diretiva NIS2, obriga as entidades abrangidas a gerir e a notificar dentro de prazos apertados. As obrigações de gestão de risco cobrem precisamente domínios como a segurança dos recursos humanos, o controlo de acessos e a formação em cibersegurança — os pontos exatos que uma campanha como a Spring Ring põe à prova. Se, no decurso do incidente, forem acedidos ou exfiltrados dados pessoais, acresce o dever de notificação à CNPD ao abrigo do RGPD, com o prazo de 72 horas a partir do conhecimento da violação.
Para as PME, a conclusão prática é sóbria: nenhuma solução tecnológica substitui uma regra organizacional clara sobre como o suporte informático contacta os colaboradores. É essa regra — e não o antivírus — que quebra o guião do atacante ao segundo minuto da chamada.
Perguntas frequentes
A campanha Spring Ring explorou alguma vulnerabilidade do Microsoft Teams?
Não. A Unit 42 sublinhou que a atividade não resultou de uma vulnerabilidade nem de um compromisso do próprio Microsoft Teams. Os atacantes abusaram da funcionalidade legítima de conversa com utilizadores externos e da confiança dos colaboradores.
Quantas organizações foram afetadas e durante quanto tempo?
De acordo com a telemetria da Unit 42, a operação decorreu entre janeiro e abril de 2026 e visou mais de 150 colaboradores em pelo menos 10 empresas de vários setores. Foram identificadas 26 identidades distintas de atacante.
O que devo fazer se receber uma chamada suspeita no Teams?
Não aceite instalar software nem conceda controlo remoto durante a chamada. Termine o contacto e valide o pedido pelo canal oficial de suporte da sua organização. Se já concedeu acesso, isole o equipamento e avise imediatamente a equipa de segurança; em Portugal, o incidente pode também ser reportado ao CERT.PT.
Que controlo técnico tem maior impacto imediato?
Restringir a comunicação externa no Teams a domínios autorizados e bloquear ferramentas de acesso remoto não aprovadas, incluindo o Quick Assist. Em campanhas semelhantes, os atacantes recorreram ao Quick Assist e, em alternativa, a RMM em cloud quando o primeiro estava bloqueado, pelo que a lista de permissões deve ser abrangente.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Unit 42 (Palo Alto Networks), pela Sophos, pela Microsoft Threat Intelligence e pelo CNCS/CERT.PT.