O ataque de nove etapas que morre na primeira
A Microsoft documentou uma cadeia de ransomware em nove etapas que começa com uma mensagem externa no Teams a fazer-se passar pelo helpdesk e termina com o Rclone a exfiltrar silenciosamente a partilha de rede. Oito dessas nove etapas precisam do sistema operativo anfitrião. Nenhuma delas consegue correr contra um separador.
Esta semana, a Microsoft publicou uma cadeia de ataque em nove etapas: uma mensagem no Teams vinda de um falso helpdesk, uma sessão de Quick Assist, um DLL side-load através de um binário de fornecedor assinado, WinRM através da rede, Rclone a sair para armazenamento na cloud do atacante. Oito das nove etapas precisam que o sistema operativo anfitrião seja um verdadeiro computador pessoal. Um separador de navegador a correr dentro de uma VM descartável não é isso.
A 20 de abril de 2026, a equipa de análise de ameaças da Microsoft publicou uma descrição detalhada de uma cadeia de ataque em nove etapas que vários afiliados de ransomware estão agora a usar em produção. A jogada de abertura é social: uma mensagem chega ao Microsoft Teams a partir de um tenant externo, de alguém que afirma ser do departamento de TI, e pede ao alvo para iniciar uma sessão de suporte remoto para resolver «um problema de conta» ou «instalar uma atualização de segurança». A jogada final é financeira: o Rclone, um utilitário legítimo de sincronização na cloud, a transmitir o servidor de ficheiros para armazenamento de objetos controlado pelo atacante enquanto o ransomware cifra o que fica para trás.
Vale a pena citar diretamente as palavras da Microsoft: «os atores de ameaça estão cada vez mais a abusar da colaboração externa no Microsoft Teams para se fazerem passar por pessoal de TI ou de helpdesk e convencer os utilizadores a conceder acesso de assistência remota». A novidade aqui não é a engenharia social — fingir ser do helpdesk é tão antigo como o próprio helpdesk —, é a superfície de entrega. O Teams é o cliente de colaboração que está em cada computador pessoal corporativo, com sessão sempre iniciada, a arrancar automaticamente no boot, com uma API de notificações que faz com que uma mensagem externa pareça idêntica a uma interna. É, em 2026, um canal de phishing melhor do que o email.
A cadeia, do início ao fim.
Eis o que as nove etapas fazem realmente numa máquina Windows. Os números são os da Microsoft; as descrições em linguagem comum são as nossas.
A cadeia é eficiente e aborrecida, que é o aspeto que o bom ofício de ransomware tem em 2026. Nada aqui é um zero-day. O Quick Assist é uma ferramenta de suporte remoto da Microsoft, de primeira parte, que vem com o Windows. O PowerShell é uma shell administrativa de primeira parte. O DLL side-loading — largar uma biblioteca controlada pelo atacante junto a um programa legitimamente assinado para que o programa assinado carregue o código malicioso — tem duas décadas de idade. O WinRM é a forma como os administradores de domínio devem gerir frotas Windows. O Rclone é um utilitário open-source de sincronização na cloud que se pode instalar a partir do Homebrew. O ataque é feito de primitivas suportadas, assinadas e abençoadas pela TI. É isso que o torna difícil de detetar com ferramentas tradicionais de endpoint: cada passo individual parece algo que a equipa de TI faz de propósito.
A tese positiva: decapitar a cadeia na primeira etapa.
Considere agora o que essa mesma cadeia parece se a primeira etapa não for uma notificação a aparecer num cliente nativo de Windows, mas uma notificação a aparecer dentro de um separador de navegador. Dentro de um separador da Bromure. Dentro de uma VM Linux descartável que não tem disco persistente, não está associada a um domínio, não tem binários Windows, não tem listener de WinRM, não tem Rclone, não tem Adobe Reader onde fazer side-load, não partilha sistema de ficheiros com o anfitrião, e que será destruída quando a janela fechar.
A etapa 1 continua a aterrar. O tenant externo de Teams continua a poder enviar a DM. O utilizador continua a ver a mensagem. A pressão de engenharia social continua lá. Nada na Bromure impede que um estranho que afirma ser do helpdesk escreva «preciso de instalar uma atualização de segurança na sua máquina, deixe-me iniciar uma sessão de Quick Assist» numa janela de conversa.
Mas é na etapa 2 que tudo pára. O separador de navegador não pode lançar o Quick Assist, porque o Quick Assist é um binário nativo do Windows e o separador é uma janela do Chromium dentro de uma VM Linux que não tem Quick Assist instalado, não tem forma de o instalar, e não tem canal IPC para a máquina Windows do outro lado, seja qual for o dispositivo que esteja a correr a Bromure. E como a cadeia é estritamente sequencial — cada etapa subsequente precisa do artefacto da etapa anterior —, decapitar na etapa dois significa que as etapas 3 a 9 nunca chegam a acontecer.
Há uma leitura tentadora deste diagrama que é demasiado forte: «use a Bromure, fique imune a ransomware». Não é essa a afirmação. A afirmação é mais estreita, e a versão mais estreita é mais honesta e mais útil.
Qual é, realmente, a fronteira.
O que está a fazer o trabalho aqui não é um filtro específico para o Teams. É uma propriedade estrutural da forma como a Bromure executa conteúdo web. Cada separador na Bromure corre dentro da sua própria VM Linux descartável no seu Mac. O navegador que o utilizador vê é o Chromium, a correr dentro desse sistema convidado Linux. O separador está limitado pela VM. O anfitrião está limitado pelo hipervisor. Quando fecha o separador, a VM é destruída. Quando abre um novo separador, é criada uma nova VM a partir de uma imagem de disco limpa.
Quando o atacante na etapa 2 diz aceite a minha sessão de Quick Assist, o mecanismo que pede para invocar não existe do outro lado da fronteira. Não há Quick Assist num sistema convidado Linux. Não há forma de uma página web, mesmo uma em que o utilizador confie totalmente, sair do sistema convidado para o anfitrião a fim de lançar um binário nativo de macOS ou Windows. Não há ponte para isso; iria anular todo o propósito da arquitetura. A cadeia do atacante depende de um conjunto de capacidades — lançar app nativa, escrever num sistema de ficheiros persistente, carregar um DLL junto a um binário de fornecedor assinado, abrir uma sessão WinRM, ler credenciais do anfitrião — e a VM do separador não tem nenhuma delas, por construção.
Isto não é uma funcionalidade que adicionámos especificamente para a ameaça do helpdesk no Teams. É a mesma propriedade que torna a Bromure útil contra zero-days de navegador, extensões maliciosas e infostealers em geral. A etapa 1 é a única parte da cadeia que se interessa pelo que o utilizador clicou. Cada etapa seguinte precisa do computador pessoal do utilizador. Ponha o navegador num computador diferente do computador pessoal e a cadeia deixa de ser sobre as decisões do utilizador e passa a ser sobre a arquitetura da máquina.
O que isto não resolve.
Se o mesmo utilizador tem o Microsoft Teams instalado como cliente
nativo de computador pessoal — o Microsoft Teams.app no macOS, ou o
cliente para computador pessoal do Windows, ambos a correr fora da
Bromure, ambos com sessão iniciada na mesma conta de utilizador —,
então a DM do tenant externo aterra no anfitrião. Nesse momento,
estamos de volta à linha A do diagrama. A etapa 1 é uma notificação
nativa. A etapa 2 é o utilizador a aceitar uma sessão de Quick Assist
no seu computador pessoal real. A VM do separador nunca entra na
história. A Bromure não consegue proteger o que não corre dentro da
Bromure.
Do mesmo modo: se a política de TI da organização é bloquear as DMs externas do Teams ao nível do tenant — o que a descrição da Microsoft recomenda —, a etapa 1 nunca chega ao utilizador em nenhum dos dois mundos, e a discussão sobre arquitetura fica prejudicada. Essa é a primeira correção certa. A Bromure é uma defesa para o caso em que a primeira correção não foi aplicada, ou em que o utilizador está num dispositivo pessoal, ou em que a política tem uma exceção, ou em que o atacante encontrou um tenant que não a impunha.
O que o hábito de navegador muda
Abrir o Teams em teams.microsoft.com dentro de um separador da
Bromure move a primeira etapa para uma VM Linux efémera no seu
Mac. Se clicar no link «aceitar suporte» que o impostor envia, a
ferramenta que ele queria não está onde o clique aterra. O pedido
falha porque a capacidade não está presente.
O que o cliente nativo não faz
Se já tem a aplicação Teams para computador pessoal instalada e com sessão iniciada, a DM chega lá e o anfitrião fica exposto exatamente como a Microsoft descreve. Remover o cliente para computador pessoal, ou relegá-lo para uma máquina de trabalho dedicada, é a mudança de comportamento que a Bromure permite — não uma que ela imponha.
O que a Bromure não impede
Um utilizador convencido a escrever a palavra-passe corporativa num formulário dentro do separador da Bromure continua a perder essa palavra-passe. A varredura anti-phishing do navegador vai tentar apanhar o formulário, mas um alvo de engenharia social determinado consegue derrotar qualquer guarda desse tipo. Phishing de credenciais e defesa da fronteira da VM são problemas diferentes.
A forma honesta da afirmação
Para um utilizador cujo hábito de trabalho é o Teams no navegador, a Bromure transforma uma intrusão de nove etapas numa conversa de uma etapa. Para um utilizador cujo hábito de trabalho é o cliente nativo, a Bromure não muda nada neste ataque. É esse o propósito inteiro de publicar este artigo em vez de um mais curto e mais barulhento.
Porque é que o hábito de navegador vale a pena defender.
A maioria dos clientes de conversa corporativos — Teams, Slack, Discord, Zoom — é entregue como app nativa para computador pessoal e como app web ao mesmo tempo, no mesmo URL. A versão web está completa em termos de funcionalidades para a grande maioria daquilo que as pessoas fazem nelas: ler mensagens, escrever mensagens, pesquisar, anexar ficheiros, fazer chamadas. A versão web não arranca automaticamente no boot. A versão web não mantém um processo persistente no anfitrião que os atacantes possam sondar. A versão web não fornece um canal de atualização que, no passado, foi vetor para os seus próprios incidentes de cadeia de fornecimento. E, de forma única se o navegador em questão for a Bromure, a versão web vive dentro de um computador que não partilha o sistema de ficheiros com a máquina real do utilizador.
A proposta aqui não é que todos os utilizadores desinstalem amanhã a aplicação Teams para computador pessoal. É que a opção primeiro-na-web existe, é silenciosamente aceitável há anos e — à luz daquilo que a Microsoft descreveu a 20 de abril — é agora materialmente a mais segura para qualquer utilizador que não precise especificamente de uma funcionalidade que só o cliente para computador pessoal oferece. A Bromure torna esta escolha significativa. Uma sessão de Teams web dentro de uma janela normal do Chrome continua a ser uma sessão que partilha sistema de ficheiros com todos os outros programas no seu Mac. Uma sessão de Teams web dentro de um separador da Bromure não.
Uma história, e o que ela muda.
A descrição em nove etapas da Microsoft não será a última do seu género. A forma — canal social externo → ferramenta de acesso remoto → reconhecimento → persistência em binário assinado → movimento lateral → exfiltração — é a forma que a maioria das intrusões de ransomware operadas por humanos tomam hoje, independentemente do cliente de conversa em que começam. O cliente de colaboração é a nova caixa de entrada de email. O «clique para aceitar a sessão de suporte» é o novo «clique para ativar macros». O trabalho subsequente com as mãos no teclado é o ataque em si.
Se o trabalho diário do utilizador acontece numa máquina em que o cliente de conversa e o servidor de ficheiros partilham sistema operativo, o atacante só precisa de meter um pé dentro desse sistema operativo para fazer as outras oito etapas. Se o trabalho diário do utilizador acontece num navegador que corre dentro de uma VM da qual o cliente de conversa não consegue escapar, o atacante precisa de um conjunto totalmente diferente de primitivas para terminar o trabalho, primitivas que a geração atual de manuais de ransomware não possui.
Isto não é imunidade. É decapitação na primeira etapa. Instale a
Bromure, use teams.microsoft.com dentro dela em vez do cliente
nativo para as partes da sua conversa de trabalho em que o puder
fazer, e deixe que a próxima cadeia de nove etapas seja problema do
atacante.