A ligação vinha de dentro do helpdesk

Em 24 de abril, a BleepingComputer reportou um cluster motivado financeiramente que a Unit 42 da Palo Alto rastreia como CL-CRI-1116, também conhecido como BlackFile, também conhecido como UNC6671, e que a CrowdStrike (separadamente, mas provavelmente a mesma gente, ou pelo menos primos) chama de Cordial Spider. A taxonomia é uma bagunça. O comportamento, não.

Eis o comportamento, na ordem em que ele acontece com você:

1. Você recebe uma ligação. O identificador de chamadas diz que é o IT interno, ou algo parecido — VoIP forjado, ou um CNAM fraudulento (o nome legível para humanos que a rede telefônica exibe ao lado de um número, e que, descobre-se, não é especialmente bem autenticado). A pessoa do outro lado é amigável e levemente pedinte de desculpas. Lamenta muito incomodar. Há um pequeno problema com a sua conta.
2. Para resolver o pequeno problema da sua conta, ela gostaria que você fizesse login em uma página corporativa cujo link ela vai te enviar por SMS, ou às vezes apenas conduz você até lá. A página parece correta. Tem o logotipo da empresa. Tem o texto certo. Não é a página certa.
3. Você digita sua senha. A página pede o código de uso único do seu app autenticador. Você digita também.
4. A página agradece e possivelmente exibe um spinner. Você desliga.
5. O atacante, no seu próprio laptop, em outro lugar, pega a sua senha recém-digitada e o seu código de seis dígitos recém-digitado, faz login no seu portal SSO real nos noventa segundos seguintes, e — esta é a parte elegante — registra o próprio dispositivo MFA na sua conta.
6. Ele agora é você. Tem um segundo fator permanente que mora no bolso dele. O seu segundo fator também ainda funciona, motivo pelo qual ninguém percebe.
7. Vão ao Salesforce, vão ao SharePoint, procuram arquivos com as palavras "confidential" ou "SSN" neles, baixam tudo que conseguirem, e uma semana depois o seu CEO recebe um e-mail de resgate de sete dígitos de um endereço Gmail. Às vezes, segundo o relato da BleepingComputer, funcionários também recebem ameaças de swatting, um nível de atendimento ao cliente que a maioria das gangues de extorsão nem se dá ao trabalho de oferecer.

Enfim.

Onde, exatamente, o ataque acontece

Vale a pena ser preciso sobre que parte dessa cadeia roda onde, porque a cadeia inteira não está no mesmo lugar.

A ligação corre pelo telefone. A ligação tem formato de telefone. Nenhum navegador, nenhum laptop, nenhum sistema operacional que se possa atualizar consegue fazer alguma coisa quanto à ligação em si, porque a ligação não está no laptop. (Você pode treinar pessoas, pode pôr cartazes na sala de descanso, pode pedir que o helpdesk real envie um e-mail de acompanhamento depois de cada ligação legítima, e tudo isso ajuda, mas a ligação é, como dizem na área, um problema com formato de gente.)

A página falsa de login roda em um navegador. Especificamente, roda em qualquer navegador que a funcionária por acaso tenha aberto no laptop de trabalho, em qualquer perfil que estivesse usando por último, com quaisquer sessões, cookies e senhas de preenchimento automático que ela esteja a carregar. Esta parte é um problema com formato de computador.

O registro de MFA na conta real roda no laptop do atacante, no navegador dele, contra o portal SSO legítimo. Isso não é, em absoluto, um problema no navegador do usuário; é um problema de como o portal SSO trata o cadastramento de MFA quando alguém tem a senha e um OTP atual. O seu IdP (o provedor de identidade que opera o SSO — Okta, Entra ID, Google Workspace, qualquer um que tenha decidido que sua senha está correta) trata "tenho a senha e um OTP fresco" como prova suficiente para adicionar mais um fator. Isso é uma decisão de política, e é a política com que a maioria das empresas vem por padrão, porque a alternativa é que os usuários se tranquem para fora quando trocam de telefone.

A exfiltração no Salesforce e no SharePoint roda também no laptop do atacante, contra o seu SaaS real, com o segundo fator recém-cunhado dele. Esta parte, no sentido estrito, não é "um ataque ao navegador da funcionária". É o atacante fazendo login como uma pessoa normal, porque a esta altura ele é uma pessoa normal. O navegador da sua funcionária ficou de fora dos últimos três passos.

Portanto, se você está procurando uma única alavanca tecnológica para puxar a fim de prevenir o BlackFile do início ao fim, não existe. O ataque está distribuído entre um telefone, uma página falsa, uma política de IdP e o laptop de um atacante.

O que existe — e esta é a única parte da cadeia sobre a qual um fabricante de navegador pode dizer algo de forma crível — é o segundo passo, a página falsa de login. A página tem que renderizar em algum lugar. Onde quer que renderize, a funcionária digita credenciais reais e um OTP real nela. A pergunta, portanto, é só: em que tipo de container você quer que esse evento em particular aconteça?

A página tem que renderizar em algum lugar

Certo. Então a página renderiza em um navegador. Em qual?

Se você não fizer nada, ela renderiza em qualquer navegador que a funcionária estivesse usando — Chrome em um laptop pessoal, Edge em um laptop corporativo, Safari no iPad que estava por perto. Seja qual for o navegador, ele já está em uso há algum tempo. Tem um perfil que está em uso há algum tempo. Esse perfil provavelmente já tem cookies do portal SSO corporativo real, porque a funcionária faz login no trabalho toda manhã. Tem senhas salvas. Tem uma sugestão de preenchimento automático que é, prestativamente, a senha corporativa real — só que o preenchimento automático corretamente não dispara em domínio de phishing (os navegadores são bons nisso), de modo que a usuária digita manualmente, o que ela também faz bem, porque já fez dez mil vezes.

A página falsa não precisa de nenhum desses cookies. A página falsa só precisa que os dedos do usuário continuem fazendo o que os dedos fazem quando uma página pede uma senha. A página falsa recolhe a senha. A página falsa recolhe o OTP. A página falsa acabou.

Mas eis a pergunta que vem me incomodando. Por que o navegador pessoal da funcionária, com o perfil de longa data e a coleção de todos os sites em que ela já fez login, foi o lugar onde a página falsa de login corporativo renderizou em primeiro lugar? A página alega ser corporativa. A usuária está no trabalho. A usuária está, no que lhe diz respeito, fazendo coisas de trabalho. Por que "a página de login corporativa" renderiza no mesmo ambiente de software que "o link compartilhado de Spotify da prima" e "uma conta de Etsy de 2018"?

Esta é, eu acho, a pergunta.

O argumento do navegador gerenciado, em pequena escala

Eis a versão pequena, estreita e honesta do argumento do Bromure para este ataque.

Um departamento de IT pode entregar o Bromure como o navegador corporativo autorizado. Não o único navegador no laptop — a usuária ainda pode ter Chrome e Safari para navegação pessoal — mas o único navegador que está configurado, inscrito e marcado de maneira visível como o lugar onde o SaaS corporativo deve viver. O Bromure tem uma aba Enterprise nas configurações, cuja única tarefa é exatamente esta: um campo de proxy HTTP, e um espaço para certificados raiz internos. Duas configurações. É só isso que ele faz, e é intencionalmente só isso que ele faz. Uma organização configura essas duas coisas uma vez, entrega aos funcionários um perfil Bromure pré-configurado para confiar na CA corporativa e rotear pelo proxy corporativo, e deixa o perfil ser visivelmente o lugar onde o SaaS corporativo vive.

(Não estamos afirmando que a aba Enterprise seja um plano de controle MDM completo. São duas caixas de texto. Duas caixas de texto bem escolhidas às vezes bastam.)

Dentro do Bromure, cada aba é a sua própria VM Linux descartável, com o seu próprio perfil efêmero. Então quando a aba do Salesforce corporativo abre, ela abre numa VM gerenciada que conhece o proxy corporativo e confia na CA corporativa. Quando a funcionária abre, em separado, o link compartilhado de Spotify da prima, isso abre numa VM diferente com um perfil diferente que não tem nada disso.

Agora bem, a ligação telefônica continua acontecendo exatamente da mesma forma. A usuária ainda é conduzida a um link. Eis o que muda:

• O link, quando clicado, abre em alguma VM do Bromure. Não, por padrão, na mesma VM da sessão real do Salesforce da funcionária. (Perfis no Bromure não se fundem em silêncio. A página que carrega num perfil de "link descartável" não consegue ler cookies do perfil "Salesforce corporativo", porque vivem em VMs diferentes, com pilhas de rede diferentes e discos diferentes.)
• A usuária, possivelmente, digita mesmo assim credenciais corporativas reais e um OTP real na página. O Bromure não impede a digitação. Esta é a parte honesta.
• O token de sessão (ou, dependendo do kit, às vezes só os cookies) que a página captura vive dentro de um perfil que a usuária está prestes a fechar, em uma VM que está prestes a ser apagada, sem qualquer relação privilegiada com nada corporativo. O token capturado é, nesse sentido, de baixa qualidade — é uma lembrancinha de aba.

Sobre este último ponto, quero ter cuidado, porque é exatamente o tipo de coisa em que é fácil prometer demais.

Na cadeia do BlackFile como documentada, o token capturado não chega a ser usado para fazer login no Salesforce real — o atacante usa as credenciais e o OTP para fazer login no portal SSO real a partir do próprio laptop, e registra o próprio dispositivo MFA. Os cookies capturados nunca iam mesmo ser reutilizados contra a sessão corporativa real, porque são cookies para um domínio de phishing, não para o domínio real. Onde o isolamento por VM do Bromure importa é na perna atrás da página falsa: qualquer travessura no lado da aba (exfiltração de token para um endpoint do atacante, script de continuação que tenta ler outros cookies, correntes de redirecionamento que soltam payloads adicionais) fica contida dentro de uma VM cujo sistema de arquivos, rede e árvore de processos estão selados em relação ao resto do laptop e à sessão real do navegador corporativo. A página falsa é uma página falsa. Ela só pode ser uma página falsa dentro de uma caixa.

A pista, em particular, está fazendo bastante trabalho neste diagrama, e vale a pena dizer em voz alta. Uma implantação de navegador gerenciado cuja única função é "a aba corporativa de Salesforce / SharePoint / Workday parece visivelmente diferente da aba de um link qualquer" é, por si só, uma defesa nada trivial, porque a vítima canônica do BlackFile é uma pessoa cansada que recebeu uma ligação às 16h45 de uma quinta-feira. A distinção visível não é firula de UI; é o jogo inteiro.

O que isso não resolve

Quero continuar sendo honesto sobre isso, porque o modo de falha aqui é um fornecedor que explica como o produto dele teria prevenido um ataque e, quando você lê com atenção, está descrevendo um ataque diferente.

Não interrompe a ligação. A ligação está no telefone. O Bromure não roda no telefone, não vê o telefone, não tem opinião sobre o telefone. Se a usuária atender e for convencida por uma voz amistosa de que há um pequeno problema com a conta dela, a usuária vai olhar para uma página falsa de login. Podemos mudar em qual navegador a página é renderizada. Não podemos mudar se a usuária a olha.

Não interrompe a digitação. Se a usuária digita credenciais reais e um OTP real na página falsa, essas credenciais e esse OTP agora estão em poder do atacante, independentemente de onde a página tenha sido renderizada. O fato de a página estar numa VM descartável não desfaz o que a usuária acabou de digitar.

Não interrompe o cadastramento de MFA. A perna do cadastramento de MFA acontece no laptop do atacante, contra o IdP legítimo. O Bromure não roda no laptop do atacante, e o Bromure não é o IdP. A mitigação aqui está do lado do IdP, e é a chata: ative "exigir autenticação reforçada para novo cadastramento de MFA", restrinja cadastramentos à rede corporativa ou a um dispositivo gerenciado, alerte quando um novo fator for registrado, e aceite que a alternativa é os usuários se trancarem para fora ao trocar de telefone. Esta é uma escolha de configuração que qualquer admin de Okta e Entra ID pode fazer hoje, e muitos não fizeram, e essa é — para dizer com gentileza — a parte desta história que deveria tirar o sono dos CISOs mais do que a parte do navegador.

Não interrompe, no sentido estrito, um ataque de proxy AiTM em tempo real. Uma classe distinta de kit de phishing (Evilginx, Modlishka, Caffeine, os aluguéis de AiTM-as-a-service a US$ 2.500 por unidade que se tornaram o padrão dominante de ataque ao Microsoft 365) faz relay em tempo real: a usuária digita numa página que faz proxy, em tempo real, para o IdP legítimo. O cookie de sessão que o IdP emite vai para o proxy; o proxy entrega-o ao atacante. Se você imaginar uma ligação ao estilo BlackFile direcionando a usuária para esse tipo de página — o que não é o que se descreve atualmente o BlackFile fazendo, mas é para onde a categoria está indo — então o cookie capturado é um cookie de sessão real do IdP legítimo, e a pergunta passa a ser se ele pode ser reproduzido a partir de outro lugar. Esse é outro post, e mais difícil, e a resposta honesta envolve controles de vinculação de sessão (DBSC, tokens vinculados por mTLS) que pertencem em sua maioria ao IdP e só em parte ao navegador. Não vamos passar uma varinha mágica nisso.

O que o Bromure gerenciado faz, de forma estreita: faz com que a página falsa renderize em um lugar não gerenciado, efêmero e visivelmente distinto do ambiente corporativo gerenciado. Restringe o raio de explosão de quaisquer truques pós-página que o kit possa puxar (instalações de extensão, escritas no sistema de arquivos do host, persistência) a uma VM que vai sumir. E, na cadeia do BlackFile como descrita, não impede sozinho que o atacante prossiga e registre o próprio dispositivo MFA — esse é o trabalho do IdP. Estamos mitigando uma das quatro máquinas da cadeia, que é a única em que rodamos.

Por que este, no fim, é o único caminho

Enfim. Olhe. Dê um passo atrás.

A coisa sobre o BlackFile é que é um negócio extraordinariamente eficiente. Eles escolheram varejo e hospitalidade porque varejo e hospitalidade têm muitos funcionários, turnos distribuídos, horários fora do expediente, equipes reais de helpdesk de IT que ligam legitimamente para funcionários, e uma folha de pagamento de pessoas muito estressadas que realmente não querem ser o motivo de os caixas estarem fora do ar. Escolheram vishing porque vishing escala (uma pessoa ao telefone consegue ligar para uma dúzia de alvos em uma hora, e a taxa de sucesso é, pelos padrões dessa indústria, incrível) e porque a ligação é a parte da cadeia que não dá para corrigir. Colhem credenciais e OTPs porque credenciais e OTPs são a parte da cadeia que, em 2026, ainda é a porta de entrada da maioria das empresas, apesar de uma década de apresentações explicando que não deveriam ser.

A parte da cadeia que um navegador pode afetar é pequena. É uma máquina entre quatro. Você não deveria comprar um navegador porque ele afirma derrotar o BlackFile do início ao fim. Deveria comprar um navegador porque ele faz bem a única coisa que pode fazer bem — manter a sessão corporativa em um lugar gerenciado e identificável, e manter a sessão de link qualquer em um lugar que deixa de existir quando você o fecha — e em seguida deveria acoplá-lo aos controles chatos e nada glamorosos do lado do IdP que de fato fecham o laço.

O telefone vai continuar tocando. A página vai continuar carregando. A pergunta é só onde, exatamente, ela carrega, e o que está em torno quando carrega. Acontece que isso dá para mudar.

Fontes:

• BleepingComputer — New BlackFile extortion gang targets retail and hospitality orgs (2026-04-24)
• CrowdStrike — Cordial Spider adversary profile
• Help Net Security — Attackers use AiTM phishing kit, typosquatted domains to hijack AWS accounts (2026-03-10) (referenciado pelo contexto mais amplo do mercado de AiTM-as-a-service, não especificamente pelo BlackFile)