A página de phishing que se construiu sozinha

O relatório de tendências de resposta a incidentes do primeiro trimestre de 2026 da Talos foi publicado em 22 de abril, e a manchete é o tipo de coisa que os defensores leem como um termômetro. O phishing voltou a ser o vetor de acesso inicial mais observado — mais de um terço dos engajamentos em que o vetor pôde ser determinado — pela primeira vez desde o segundo trimestre de 2025. Fragilidades de MFA apareceram em trinta e cinco por cento dos engajamentos, alta em relação ao quarto trimestre. Administração pública e saúde empataram como os setores mais visados, com vinte e quatro por cento cada. Nada disso é especialmente surpreendente em si.

A parte surpreendente é um estudo de caso no meio do relatório. A Talos documenta o que classifica, com confiança moderada, como a primeira observação de um aplicativo de IA específico — o Softr, um construtor de aplicativos no-code de "vibe-coding" — usado para hospedar uma página de coleta de credenciais ao vivo. A página imitava o Microsoft Exchange e o Outlook Web Access. Capturava as credenciais enviadas numa planilha descartável do Google Sheets. Enviava um e-mail ao operador a cada nova captura. A Talos avalia que o padrão remonta a pelo menos maio de 2023, mas vinha acelerando ao longo do final de 2025 e já no primeiro trimestre. O monitoramento paralelo da Trend Micro mostra a mesma técnica no Lovable, Netlify e Vercel: páginas de CAPTCHA falsos erguidas em subdomínios de construtores de IA, com o formulário real de credenciais carregado por trás do desafio.

A página em si não tem nada de extraordinário. A hospedagem é que é a história.

Como a cadeia realmente se parece.

Um construtor no-code como o Softr é, por design, uma distância muito curta entre um prompt e uma aplicação web ao vivo. Você descreve o que quer, ele gera o HTML e o JavaScript, implanta o resultado na sua própria infraestrutura e te dá um subdomínio gratuito. Esse subdomínio é irmão do subdomínio de todo outro cliente do Softr: alguma-coisa.softr.app. O Softr cuida da hospedagem, do certificado TLS, do CDN, do tempo de atividade. Se você é um atacante que quer rodar uma página de coleta de credenciais e não quer registrar um domínio, comprar um certificado, alugar um VPS, nem explicar a ninguém o que está hospedando, essa é uma proposta de valor extraordinária.

O que torna essa cadeia em particular interessante é que cada elo dela, com exceção do prompt do próprio atacante e da caixa de entrada do próprio atacante, é um produto SaaS mainstream fazendo exatamente o que anuncia fazer. O Softr monta a página. O softr.app a hospeda sob um subdomínio. O Google Sheets armazena as credenciais coletadas. O Gmail notifica o operador. Um defensor automatizado que percorre essa cadeia de cima a baixo só enxerga terceiros respeitáveis. A cadeia não está se escondendo. Está vestindo uma camuflagem que a defesa foi construída para classificar como benigna.

O ponto cego na reputação de URL.

A maioria dos sistemas de reputação de URL — aqueles que classificam um link como "seguro", "suspeito" ou "malicioso" antes mesmo de seu navegador terminar o handshake TLS — funciona da mesma forma que um birô de crédito. Eles montam um perfil do domínio: qual é a idade, o quanto ele é conhecido, se o certificado TLS dele tem um longo histórico ou se é um novinho do Let's Encrypt, se já foi observado em alguma blocklist, se a empresa-mãe está em boa situação. O perfil produz um número, o número produz um veredicto, o veredicto produz uma cor.

Rode alguma-coisa.softr.app por esse pipeline.

Todo sinal em que a camada de reputação se apoia é uma propriedade do softr.app, o domínio pai, e toda resposta que o pai dá é a resposta certa. Ele tem seis anos. O certificado dele é válido. Ele não está em nenhuma blocklist. Ele serve HTTPS. Ele é uma categoria que o scorer já classificou. O subdomínio não muda significativamente nenhum desses sinais. A página no subdomínio poderia ser um cartão de aniversário ou um formulário de coleta de credenciais — o scorer não tem como saber e, estruturalmente, dentro do design da reputação de URL, nenhum motivo para olhar.

A observação da Talos é que os atacantes descobriram isso faz tempo e agora estão operacionalizando: monte a página num SaaS respeitável, colete as credenciais num SaaS respeitável, roteie os alertas por um SaaS respeitável. Dê ao defensor nada para recusar.

A camada certa é a página, não a URL.

A defesa precisa descer na pilha. O único sinal que permanece confiável uma vez que a hospedagem foi lavada é o que a página em si afirma ser e o que ela realmente é. Um formulário de login do Outlook em onboarding-portal-8xq.softr.app é phishing. Um formulário de login do Outlook em login.microsoftonline.com não é. Mesmo formulário, origem diferente, veredicto diferente. Um sistema que consegue ler o formulário e compará-lo com a origem tem algo a dizer sobre essa página; um sistema que só lê a URL não tem.

Esta é a camada em que o inspetor antiphishing do Bromure já trabalha. Dentro de cada aba do Bromure, um content script observa a página enquanto ela carrega, extrai os sinais que um humano usaria para decidir o que a página afirma ser — o texto visível, o título, a origem do logotipo, o formato dos formulários, os campos solicitados — e envia esse pacote por um canal vsock até um modelo pequeno que emite um veredicto em linguagem simples. "Esta página afirma ser o Microsoft Outlook mas está hospedada em softr.app" é o tipo de frase em que um leitor treinado chega em fração de segundo. O modelo chega lá também, e o banner que o usuário vê diz isso numa frase só, na cor que combina com o veredicto.

O inspetor de conteúdo não é mágica e não é uma prova. É uma segunda opinião treinada que responde a uma pergunta que a reputação de URL, por construção, é incapaz de responder: o que esta página afirma ser? Essa pergunta tem uma borda mais afiada num softr.app ou num vercel.app ou num lovable.app do que em quase qualquer outro lugar da web, porque nesses subdomínios o conteúdo da página é quase o único sinal que sobrevive. Todo o resto foi lavado pelo pai.

O que o Bromure ainda não consegue impedir.

O inspetor de conteúdo, o banner que ele pinta e o bloqueio que ele pode impor são a primeira linha. A primeira linha nem sempre segura. Um usuário que foi preparado por um e-mail convincente, que está no meio do expediente, que está acostumado a clicar por telas de login do Outlook como questão de hábito, consegue passar por cima de um banner de aviso. Um usuário também pode cair numa página que o inspetor ainda não avaliou, ou numa que ele avalia como suspeita em vez de phishing declarado, e decidir que suspeita é perto o suficiente de provavelmente tudo bem.

Quando isso acontece, o usuário digita uma senha num formulário e o formulário captura a senha. Nenhuma arquitetura de navegador no mundo desativa a digitação. Essa é a ressalva mais básica e mais importante deste post. O Bromure não impede um usuário de digitar uma senha real no formulário de um atacante. O que ele consegue moldar é o que acontece depois, e o que acontece depois depende de onde está o resto do trabalho do usuário.

O que a postura de hábito de navegador muda, e o que ela não muda.

Algumas coisas a arquitetura do Bromure muda, honestamente, se um phishing de credenciais passar pelo banner:

• Sem autofill do gerenciador de senhas na origem errada. Os gerenciadores de senhas combinam credenciais salvas com a origem, e a origem aqui é softr.app, um domínio que o cofre do usuário nunca viu. O autofill não dispara. O usuário tem que digitar. Essa é uma defesa real, barata, chata — e funciona tão bem no Chrome quanto no Bromure; vale nomeá-la apenas porque é uma defesa que não depende de julgamento, e é justamente julgamento que o phishing derrota.
• Sem perfil persistente na aba do phishing. A aba que abrigou o phishing é uma VM Linux efêmera. Quando ela fecha, nada do que foi carregado nela — cookies, armazenamento, caches, fingerprints — persiste. Isso não desvaza as credenciais que o usuário digitou. Significa, sim, que a página não consegue discretamente plantar um marcador num perfil de longa duração para seguir o usuário entre sessões.
• Uma página que tenta alcançar o host não o encontra. O estudo de caso da Talos é uma captura direta de credenciais. O padrão mais amplo que a Trend Micro acompanha no Lovable e no Vercel inclui páginas que também encenam uma etapa seguinte — um paste ClickFix, um "execute este instalador", um CAPTCHA falso que resolve para um prompt de aplicativo nativo. Se a página de phishing tenta passar o bastão para o sistema operacional do host, a VM de aba corta esse repasse na fronteira do hypervisor. Mesmo motivo arquitetural de todo outro post deste blog.

E algumas coisas o Bromure não muda:

• Replay de credenciais a partir da infraestrutura do atacante. Depois que o atacante tem um nome de usuário e uma senha, ele pode fazer login no Outlook de verdade a partir da própria infraestrutura. Nada na máquina da vítima, incluindo o Bromure, participa dessa sessão. MFA ajuda. MFA resistente a phishing — chaves de hardware, passkeys — ajuda mais. Política em nível de tenant que proíbe autenticação legada ajuda mais ainda. Estas são as correções para essa perna do ataque, e este blog não vai fingir que uma arquitetura de navegador substitui essas correções.
• Kits de adversário-no-meio que retransmitem sessões ao vivo. O caso Softr que a Talos documenta é uma página estática de captura de credenciais, não um proxy reverso AiTM. A classe de kit mais sofisticada — Tycoon, Evilproxy e sua linhagem — captura um cookie de sessão ao vivo retransmitindo o desafio de MFA da vítima pelo phishing até o provedor real. Esse cookie de sessão vive na infraestrutura do atacante a partir do momento em que é capturado. Descartabilidade no lado do navegador ajuda com a higiene de sessão daí em diante; não invalida retroativamente um cookie que já saiu do prédio. Vinculação de cookie no lado do servidor — DBSC e seus pares — é a correção que faz isso.

Por que isto é um divisor de águas e não um modismo.

O enquadramento de "primeira atribuição" da Talos é cauteloso, e a avaliação de confiança moderada de que o padrão remonta a maio de 2023 sugere que ele vinha acelerando em silêncio por perto de dois anos antes que alguém lhe desse um nome. É assim que as melhores técnicas de atacante chegam — não como um anúncio, mas como uma curva que você percebe num gráfico que alguém finalmente desenhou. O texto da Trend Micro de setembro de 2025 sobre phishing hospedado em construtores de IA traçou a mesma curva pela direção oposta. O ponto de cruzamento é agora. Qualquer defensor que assuma que seus usuários nunca vão clicar num link para *.softr.app, *.vercel.app, *.lovable.app ou *.netlify.app está assumindo um mundo que já terminou no trimestre passado.

A estrutura de custos é o motivo. Há uma década, montar uma página de phishing crível exigia ou competência ou dinheiro: um domínio, um certificado, um servidor, uma página que não denunciasse na hora sua procedência. Hoje, um construtor no-code cuida dos quatro em troca de um cadastro no plano gratuito. O custo marginal de mais um site de imitação se mede em minutos de prompting. O custo marginal de um takedown — porque cada página vive num subdomínio de um provedor respeitável, não no próprio domínio — é maior do que era antes. Essas duas curvas apontam no sentido errado para a defesa, e a resposta mainstream de "treinar os usuários para detectar URLs ruins" é, a esta altura, centro de custo, não controle.

A posição honesta para um navegador que afirma proteger usuários é que ele tem que fazer trabalho que os sistemas de reputação de URL não fazem. Ele tem que de fato ler a página. Tem que decidir, para cada formulário com cara de login num domínio sem cara de login, se o formulário combina com o domínio ou mente sobre ele. Tem que dizer isso numa frase que um humano consiga ler, e tem que acertar com frequência suficiente para que a frase valha a leitura.

Uma história, e o que ela prediz.

A Talos escreveu sobre uma página. A página foi construída num SaaS, coletou credenciais em outro, avisou o operador por um terceiro. Cada elo dessa cadeia é, para um scorer de reputação, um bom vizinho. A história que a Talos conta vai deixar de ser exceção antes do fim deste ano. "Phishing vibe-coded" não é um rótulo para uma novidade; é o nome para o jeito padrão pelo qual atacantes de credenciais vão construir páginas de ataque daqui para frente, porque é o mais barato e o mais indulgente.

Se a única resposta do seu navegador para phishing é uma pontuação de reputação de URL, o seu navegador não tem resposta para isto. A pontuação de reputação vai estar verde. A página vai estar vermelha. Instale o Bromure — e ponha o segundo par de olhos na página onde a incompatibilidade de fato mora.