Uma operação de phishing operada por humanos está a usar páginas que imitam produtos publicitários de marcas de inteligência artificial — ChatGPT, Gemini, Claude, Perplexity, Manus e, mais recentemente, o Muse da Meta — para roubar credenciais e códigos de autenticação multifator a quem gere contas de publicidade digital. A investigação é da Island, empresa de segurança de browsers empresariais, e foi publicada a 6 de outubro de 2026.
Resposta rápida: Sites falsos que se apresentam como ferramentas de IA para gestão de campanhas publicitárias atraem gestores de contas, agências e media buyers. Ao clicar em “Connect”, a página desenha uma janela de login falsa dentro do próprio separador (ataque Browser-in-the-Browser), com uma barra de endereço que simula accounts.google.com ou um portal Okta. Um operador humano decide em tempo real que desafio de MFA mostrar à vítima. A defesa mais eficaz é migrar para autenticação resistente a phishing (passkeys/FIDO2) e nunca introduzir credenciais em janelas de login abertas dentro de uma página.
Produtos de IA que nunca existiram
Os investigadores Oleg Zaytsev e Ofek Ronen descrevem o que chamam uma plataforma de phishing operada por humanos, disfarçada de portefólio de produtos publicitários de IA, com ofertas que iam da otimização de campanhas às auditorias de investimento e à ligação de contas de negócio. Cada marca tinha o seu próprio discurso comercial e o seu próprio fluxo de autenticação, mas todas convergiam para a mesma ação: um botão Connect.
O detalhe mais revelador da operação é a velocidade com que acompanha a atualidade. A Meta apresentou o Muse, um agente de IA pessoal, a 8 de setembro de 2026. Oito dias depois, a 16 de setembro, surgia no domínio museads.ai um alegado “Muse Ads”, descrito pelos atacantes como um gestor de anúncios de IA para fluxos de paid media. A Meta não anunciou qualquer produto com esse nome nem posicionou o Muse como ferramenta de gestão de contas publicitárias — a marca foi inventada pelos operadores para encaixar na expectativa do mercado.
O público-alvo é específico e de elevado valor: equipas de agência, compradores de media e administradores cujas contas dão acesso, em cascata, a múltiplos clientes. Quem controla uma conta destas pode gastar saldos disponíveis em campanhas fraudulentas, adicionar utilizadores ao gestor de negócio ou revender o acesso a outros criminosos.
Browser-in-the-Browser: a barra de endereço que mente
A técnica central é o Browser-in-the-Browser (BitB), documentada publicamente desde 2022. Em vez de abrir uma verdadeira janela de autenticação do fornecedor de identidade, a página desenha em HTML e CSS uma réplica de janela de browser dentro do próprio separador. Essa janela falsa mostra separadores, cadeado e uma barra de endereço com origens de confiança como accounts.google.com ou um domínio Okta — enquanto o browser real nunca sai do domínio controlado pelo atacante.
Segundo a Island, a imitação adapta-se ao sistema operativo da vítima (Windows, macOS, iOS e Android) e reproduz pormenores como a apresentação do URL no Safari, os Chrome Custom Tabs e o modo escuro. O objetivo é anular precisamente o conselho de segurança mais repetido ao utilizador comum: “verifique o endereço antes de escrever a palavra-passe”.
Há ainda uma diferença técnica relevante face aos kits de phishing mais comuns. Não se trata de um proxy reverso transparente do tipo adversary-in-the-middle: a plataforma reconstrói localmente a interface do fornecedor e recolhe credenciais e estado de MFA através das suas próprias APIs. Na prática, o tráfego parece um produto de IA a falar com um backend aplicacional sem relação com a Google, a Meta ou a Okta — o que dificulta deteções assentes em padrões de proxy.
Um operador humano a conduzir o ataque em tempo real
O que torna a campanha particularmente eficaz é a presença de uma pessoa do outro lado. O dispositivo da vítima é identificado (fingerprinting) e os dados são enviados para o endpoint /api/send/ip através de Socket.IO. A partir daí, a página recebe instruções por dois eventos — operator-command e telegram-command — que determinam o ecrã seguinte, enquanto o atacante tenta autenticar-se na conta real em simultâneo.
Entre os comandos identificados na análise constam /password, /2fa, /authApp, /googlePrompt, /oktaApprove e /wrong2fa. Isto permite pedir a palavra-passe várias vezes, solicitar um código SMS ou de aplicação autenticadora, simular pedidos de aprovação push da Okta ou da Google, apresentar um código QR, rejeitar códigos submetidos, manter a vítima num ecrã de espera e encerrar ou suprimir o fluxo a qualquer momento. Os fluxos cobertos incluem Google, Meta, TikTok e Okta.
A Island conseguiu reconstituir o modelo de funcionamento porque os próprios operadores expuseram código-fonte de versões anteriores da plataforma em repositórios GitHub públicos mal configurados. Durante o acompanhamento, os investigadores observaram centenas de submissões de vítimas, com a atividade ainda em curso à data do relatório. Importa sublinhar que o número de submissões não equivale a autenticações bem-sucedidas: a própria Island distingue a capacidade de recolha dos resultados efetivamente obtidos.
Cronologia conhecida
| Data (2026) | Acontecimento |
|---|---|
| 27 de maio a 20 de junho | Um mesmo servidor de backend surge em 73 análises arquivadas, associado a 25 domínios de páginas |
| 8 de setembro | A Meta anuncia o Muse, agente de IA pessoal |
| 16 de setembro | Aparece o falso produto “Muse Ads” em museads.ai |
| 6 de outubro | A Island publica a investigação; campanha descrita como ativa |
Indicadores de comprometimento divulgados
A operação não se limita ao tema da IA. A mesma infraestrutura — assente em Next.js e Socket.IO, com frontends na Vercel e backends em Railway e Render — serve também iscos de falsos reembolsos e de falsos processos de recrutamento. A ligação mais clara é um servidor partilhado que respondia tanto a páginas de anúncios de IA como a um falso site de carreiras de uma marca de luxo.
| Tipo | Indicador (exemplos publicados) |
|---|---|
| Domínio (isco de IA/anúncios) | museads.ai |
| Backend | backend-production-6d75.up.railway.app |
| Domínios (isco de recrutamento) | adeccohr-jobs.com, adeccohr-calendly.com, apple-career.com, nikehr-jobs.com, talent-louisvuitton.com |
| Infraestrutura adicional | nikear.onrender.com, zero39172-391920.onrender.com |
| Artefactos de deteção | Eventos operator-command e telegram-command; endpoint /api/send/ip; múltiplos campos de palavra-passe na mesma página |
Esta é uma amostra ilustrativa: as equipas de segurança devem utilizar a lista completa de indicadores publicada pela Island e não apenas estes exemplos, uma vez que os operadores reciclam domínios e republicam infraestrutura com frequência. Não existe aqui qualquer CVE associado — não se explora uma vulnerabilidade de software, mas sim a confiança visual do utilizador no browser.
Como reduzir o risco
- Adotar autenticação resistente a phishing (passkeys/FIDO2) nas contas Google, Meta, TikTok e Okta usadas para gestão publicitária. Códigos OTP e aprovações push são exatamente o que esta plataforma foi desenhada para capturar.
- Testar a janela de login: uma janela verdadeira pode ser arrastada para fora do browser e maximizada; uma janela BitB fica sempre presa dentro da página.
- Nunca autenticar a partir de uma ligação: abrir o fornecedor de identidade manualmente, num separador novo, e só depois autorizar integrações.
- Rever permissões nas contas de negócio: administradores, utilizadores de sistema, métodos de pagamento, contas de cliente ligadas e aplicações com acesso via OAuth.
- Monitorizar anomalias de despesa e correlacionar visitas a domínios recém-registados com novos início de sessão a partir de IP desconhecidos e alterações em contas de anúncios.
- Em caso de suspeita: revogar sessões ativas, repor palavras-passe, remover chaves de MFA desconhecidas e verificar o histórico de alterações do gestor de negócio.
Porque é que isto importa em Portugal
O tecido empresarial português tem milhares de agências de marketing, consultoras digitais e PME que gerem contas publicitárias próprias e de clientes. Uma conta comprometida não é apenas um problema financeiro imediato: dá acesso a listas de contactos, públicos personalizados e dados de clientes. Se houver dados pessoais envolvidos, aplica-se o RGPD, com o dever de avaliar a notificação à CNPD no prazo de 72 horas e, quando o risco for elevado, de comunicar aos titulares.
Há também uma dimensão de cadeia de abastecimento. Uma agência que seja fornecedora de uma entidade abrangida pelo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2) passa a ser escrutinada ao abrigo dos requisitos de segurança da cadeia de fornecedores. O diploma foi publicado a 4 de dezembro de 2025 e entrou em vigor a 3 de abril de 2026, tendo sido operacionalizado pelo Regulamento n.º 756/2026 do CNCS, que define registo, comunicação de incidentes e medidas mínimas de segurança. Entre essas medidas figura expressamente a autenticação multifator — e esta campanha demonstra que nem toda a MFA tem o mesmo valor defensivo.
Organizações e cidadãos em Portugal podem reportar incidentes e tentativas de fraude ao CNCS/CERT.PT, que funciona como ponto de contacto nacional para o tratamento de incidentes. Para as entidades abrangidas pelo novo regime, a comunicação ao CNCS deixou de ser facultativa e passou a ter prazos definidos.
Perguntas frequentes
O que é um ataque Browser-in-the-Browser?
É uma técnica em que uma página maliciosa desenha, com HTML e CSS, uma falsa janela de browser dentro do próprio separador, incluindo barra de endereço e cadeado. O utilizador julga estar numa janela de autenticação legítima da Google ou da Okta, mas o browser real nunca saiu do site do atacante.
A autenticação multifator protege contra esta campanha?
Depende do tipo. Códigos SMS, códigos de aplicação autenticadora e aprovações push podem ser pedidos e reencaminhados em tempo real por um operador humano. Já as passkeys e as chaves FIDO2 estão ligadas à origem legítima e não funcionam num domínio de phishing, pelo que travam este tipo de ataque.
Como distinguir uma janela de login falsa de uma verdadeira?
Tente arrastar a janela para fora dos limites do browser ou maximizá-la. Uma janela verdadeira é independente; uma janela falsa fica sempre confinada ao interior da página. Em caso de dúvida, feche tudo e inicie sessão escrevendo o endereço do fornecedor manualmente num separador novo.
A minha conta de anúncios foi comprometida. O que devo fazer primeiro?
Revogue todas as sessões ativas, altere a palavra-passe a partir de um dispositivo de confiança, remova métodos de MFA e utilizadores desconhecidos, verifique métodos de pagamento e campanhas criadas, e avalie se houve acesso a dados pessoais para efeitos de RGPD. Reporte o incidente ao CNCS/CERT.PT e, se aplicável, às autoridades policiais.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Island Security Research, pela Meta, pelo Centro Nacional de Cibersegurança e em legislação publicada em Diário da República.