O malware que transforma o seu Teams e SharePoint em centro de comando

Investigadores descreveram um novo framework de malware escrito em Python que praticamente não precisa de infraestrutura própria: todo o comando e controlo (C2) assenta em serviços da Microsoft que as equipas de segurança estão habituadas a considerar legítimos. O Cyber Defense Center da Ontinue descobriu o implante durante a investigação de uma campanha ativa em julho e passou a segui-lo como TWINLOOT, tendo observado a utilização do SharePoint Online como dead drop de ficheiros, a infraestrutura TURN do Microsoft Teams para comunicações interativas e uma instância headless do próprio browser Edge da vítima para enviar pedidos à API Microsoft Graph. Segundo a Ontinue, o tráfego principal de C2 pode terminar em espaço de endereçamento IP da Microsoft, e não num domínio controlado pelo atacante.

Dois canais paralelos dentro da nuvem da Microsoft

A arquitetura do TWINLOOT separa as tarefas de rotina do acesso interativo: o canal SharePoint consulta uma drive aproximadamente de 15 em 15 segundos à procura de comandos, devolvendo resultados e exfiltrando credenciais roubadas e dados de reconhecimento. É um modelo clássico de dead drop: ninguém “liga” ao atacante, apenas se escreve e lê ficheiros num sítio onde ninguém desconfia.

O segundo canal serve para o operador trabalhar em tempo real. Para acesso interativo, o malware consegue estabelecer um túnel SOCKS5 reverso e encaminhá-lo pela infraestrutura TURN do Teams, permitindo que o operador use o posto comprometido para alcançar a rede interna, com ligações a serviços como SMB, RDP e WinRM a parecerem originadas na máquina da vítima; a Ontinue indica ainda que este é apenas o segundo caso observado de abuso do TURN do Teams em ambiente real e o primeiro a recorrer efetivamente a WebRTC DataChannels.

Segundo o relatório da Ontinue, divulgado a 18 de agosto de 2026, o acesso inicial terá sido conseguido por engenharia social através do próprio Microsoft Teams, com o atacante a fazer-se passar por suporte informático e a convencer o utilizador a executar um comando PowerShell que descarrega um arquivo com o runtime de Python e um payload compilado que funciona como carregador do implante. O padrão é conhecido — é a mesma receita de vishing e falso helpdesk que tem alimentado intrusões em grandes organizações — mas aqui serve para instalar um implante desenhado de raiz para viver dentro do Microsoft 365.

Porque é que os registos do Entra ID podem não mostrar nada

O detalhe mais incómodo para quem investiga incidentes é a ausência de rasto no sítio onde normalmente se procura. De acordo com a Ontinue, o implante autentica-se num tenant Azure controlado pelo atacante e não no ambiente Microsoft 365 da vítima, pelo que não produz eventos de autenticação ou de auditoria nos registos do Entra ID da organização afetada. Na prática, a organização é atravessada por um canal de C2 que “pertence” a outra subscrição.

A camada de transporte reforça o disfarce. O implante lança o Microsoft Edge em modo headless, liga-se através do Chrome DevTools Protocol e emite chamadas à Graph API como pedidos fetch() de mesma origem, feitos a partir do interior do browser — na telemetria de rede, o que se vê é um processo Edge legítimo a comunicar com a Microsoft. Como resumiu o responsável de segurança da informação da Keeper Security citado pela imprensa especializada, o método funciona porque não existe qualquer domínio do atacante na cadeia e o tráfego tem exatamente o aspeto que deveria ter, escapando à maioria das ferramentas de deteção.

Ecrãs de bloqueio falsos para roubar credenciais

Depois de instalado, o implante procura credenciais de forma direta e eficaz. A pedido do operador, o TWINLOOT apresenta um ecrã de bloqueio do Windows 10 ou do Windows 11 preenchido com a informação real da conta da vítima. O utilizador vê o seu nome e a sua fotografia, assume que a sessão expirou e escreve a palavra-passe — que segue depois pelo canal SharePoint, juntamente com o resto dos dados recolhidos.

Não existe, para já, atribuição pública consolidada a um grupo concreto. A Ontinue descreve o operador como conhecedor de tradecraft ofensivo e da arquitetura da nuvem Microsoft, e nota semelhanças operacionais com atividade previamente documentada de vishing via Teams — uma associação que deve ser lida como hipótese de investigação e não como atribuição definitiva.

O que as equipas de segurança podem fazer

Comentando as dificuldades de deteção introduzidas pelo TWINLOOT, um responsável de threat intelligence da Black Duck sublinhou que os atacantes se escondem cada vez mais dentro de serviços cloud de confiança em vez de usarem infraestrutura própria, recomendando foco em deteção comportamental, monitorização de identidade e deteção de anomalias — incluindo atividade invulgar na Graph API, aplicações OAuth e concessões de consentimento, e comportamento anómalo em SharePoint e Teams. Em concreto, vale a pena verificar:

• Processos msedge.exe lançados em modo headless ou com porta de depuração remota, sobretudo quando não têm origem em ações do utilizador.
• Execução de powershell.exe a partir do cliente Teams ou imediatamente após conversas com contactos externos.
• Presença inesperada de runtimes Python e ficheiros .pyc de grande dimensão em pastas de perfil de utilizador.
• Persistência em chaves Run do registo (HKCU) a apontar para intérpretes ou scripts.
• Restrição de mensagens e chamadas de Teams provenientes de tenants externos, com política explícita de que o suporte informático nunca pede a execução de comandos.
• Revisão periódica de consentimentos OAuth e de service principals com permissões elevadas na Graph API.

Porque é que isto importa em Portugal

Grande parte do tecido empresarial português — da administração pública às PME — vive dentro do Microsoft 365. Um implante que usa SharePoint, Teams e Graph como transporte ataca precisamente o pressuposto de confiança que sustenta muitas arquiteturas de deteção: se o destino é a Microsoft, não se olha duas vezes. Para organizações com equipas pequenas, ou que dependem de fornecedores geridos, a lição prática é que a monitorização de identidade e de comportamento na cloud deixou de ser um extra e passou a ser o núcleo da deteção.

Há também implicações regulatórias. Com a entrada em vigor do Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a diretiva NIS2), as entidades abrangidas têm de manter medidas de gestão de risco proporcionais e de notificar incidentes significativos ao CNCS, que opera o CERT.PT enquanto equipa nacional de resposta a incidentes. Um cenário como o descrito — acesso interativo à rede interna, roubo de credenciais e exfiltração silenciosa — cai facilmente nesse limiar. E se entre os dados exfiltrados houver informação pessoal, aplica-se ainda o dever de notificação à CNPD previsto no RGPD, com o prazo de 72 horas a contar do conhecimento da violação.

Do lado defensivo, o TWINLOOT reforça três prioridades pouco glamorosas mas decisivas: reduzir a superfície de engenharia social no Teams, garantir que os registos de auditoria do Microsoft 365 e do endpoint são recolhidos e correlacionados, e ensaiar a resposta a um cenário em que o C2 não tem um domínio malicioso para bloquear. Quando o indicador de comprometimento deixa de ser um endereço e passa a ser um comportamento, a deteção depende de saber o que é normal na própria organização.

Perguntas frequentes

O que é o TWINLOOT?

É um framework de implante em Python identificado pela Ontinue durante a investigação de uma campanha ativa em julho de 2026, que executa o comando e controlo dentro de serviços da Microsoft, nomeadamente SharePoint Online, Microsoft Graph e a infraestrutura TURN do Teams.

Porque é tão difícil de detetar?

Porque não usa domínios do atacante: o tráfego termina em espaço IP da Microsoft, é gerado pelo Edge da própria vítima em modo headless e a autenticação ocorre num tenant Azure do atacante, não gerando eventos nos registos do Entra ID da organização visada.

Como começa o ataque?

Segundo a Ontinue, o vetor avaliado é engenharia social via Microsoft Teams, com o atacante a fazer-se passar por suporte informático e a persuadir o utilizador a executar um comando PowerShell que descarrega o carregador do implante.

Que medidas imediatas deve tomar uma PME?

Restringir mensagens de Teams de organizações externas, formar utilizadores para nunca executarem comandos pedidos por terceiros, vigiar execuções de PowerShell e de Edge em modo headless, rever consentimentos OAuth e assegurar que os registos de auditoria do Microsoft 365 são recolhidos e analisados.

Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Ontinue e em reportagem especializada sobre o relatório.