Ligou-se ao Wi-Fi do hotel? O ataque começa antes de abrir o browser

Uma campanha de espionagem que se apoia numa peça de infraestrutura banal — o equipamento que gere o portal de acesso ao Wi-Fi de hotéis e centros de congressos — está a comprometer contas Microsoft 365 de profissionais em viagem. Em vez de enviar e-mails de phishing, os atacantes tomam o controlo administrativo do gateway que atribui as respostas de DNS a todos os hóspedes e, a partir daí, encaminham o tráfego para servidores próprios. O caso foi documentado pela equipa de investigação da ReliaQuest a 23 de julho de 2026 e, poucos dias depois, a Microsoft Threat Intelligence publicou uma análise mais ampla da mesma família de atividade, batizada CaptiveCrunch, com atribuição a um agente ligado à Rússia. O tema voltou à discussão pública depois de ter sido destacado no blogue de Bruce Schneier.

Um só equipamento, todos os hóspedes

O elemento central deste esquema é o gateway de portal cativo, o aparelho que apresenta a página de boas-vindas e autoriza o acesso à Internet dos visitantes. Segundo a ReliaQuest, estes equipamentos ficam no perímetro da rede de todos os hóspedes, pelo que o comprometimento de um único dispositivo permite ao atacante redirecionar o tráfego de todos os utilizadores que se autentiquem naquela rede num determinado dia, sem tocar em nenhum posto de trabalho. Como estes aparelhos controlam a resolução de DNS dos utilizadores ligados, quem os domina consegue manipular a navegação de todos os convidados.

Sobre a forma de entrada, os investigadores são prudentes. A ReliaQuest indicou, com confiança «baixa a média», que o acesso inicial foi provavelmente obtido através de interfaces de gestão expostas combinadas com credenciais de administração fracas ou reutilizadas. Entre os serviços de administração apontados estão SSH, SNMP e painéis web de gestão. Não há, até agora, um identificador CVE público associado a esta campanha: o problema descrito é de exposição e higiene de credenciais, não de uma falha específica de um fabricante. A Microsoft afirma que a investigação sobre o vetor inicial continua, mas nota semelhanças no equipamento e nos sistemas de gestão das várias redes afetadas, o que sugere que a atividade pode não se limitar a comprometimentos isolados de cada local e refletir acesso a serviços partilhados dentro do ecossistema de portais cativos.

Duas investigações, uma atribuição contestada

A ReliaQuest descreveu atividade em curso desde pelo menos junho de 2026 e avaliou que as táticas se assemelham às do APT28 — também conhecido por Fancy Bear e Forest Blizzard —, grupo da inteligência militar russa anteriormente ligado a campanhas contra routers para comprometer contas Microsoft 365. A própria empresa sublinhou, contudo, que o ataque a equipamentos de portal cativo não constava dos relatórios anteriores sobre a campanha FrostArmada e que os registos de domínios e endereços IP usados não coincidem com infraestrutura antes associada ao APT28.

A Microsoft chegou a uma conclusão diferente. Refere ter observado, desde o início de maio de 2026, ataques de manipulação de tráfego generalizados mas direcionados em redes do setor da hotelaria servidas por portais cativos em todo o mundo e, apesar de algumas semelhanças de táticas com a operação de hijacking de DNS do Forest Blizzard divulgada em abril de 2026, atribui a campanha CaptiveCrunch ao Storm-2945. O Storm-2945 é descrito como um subgrupo operacional do Midnight Blizzard, também conhecido por APT29, the Dukes ou Cozy Bear, que os governos norte-americano e britânico já atribuíram ao serviço de informações externas russo, o SVR.

Quanto ao alcance geográfico, a ReliaQuest identificou equipamentos de portal cativo comprometidos em hotéis e locais de congressos de várias cidades norte-americanas, além da Índia e da Arábia Saudita, com tráfego para a infraestrutura maliciosa proveniente de organizações de setores como finanças, saúde, serviços jurídicos, energia, retalho e serviços profissionais — sinal de que o alvo são os funcionários em viagem e não um setor concreto.

Cronologia conhecida

A campanha FrostArmada, ligada ao grupo russo Forest Blizzard, alterava configurações de DNS em routers comprometidos para desviar tráfego de autenticação e roubar credenciais Microsoft e tokens OAuth, tendo sido perturbada em abril de 2026 numa operação conjunta com autoridades e parceiros privados. Já as páginas do CaptiveCrunch começaram, a partir de 16 de julho, a encaminhar utilizadores para fluxos de autenticação por código de dispositivo, instruindo-os a introduzir um código fornecido pelo atacante numa página de login genuína da Microsoft.

Como corre o ataque, passo a passo

Do ponto de vista do utilizador, nada parece fora do normal: liga-se ao Wi-Fi do hotel, vê o habitual portal de acesso e, eventualmente, uma mensagem familiar sobre a necessidade de atualizar algo antes de poder navegar — enquanto, nos bastidores, o grupo manipula o tráfego de DNS e HTTP da rede. A partir daí, o desfecho pode seguir dois caminhos.

• Roubo de credenciais e tokens. Parte da atividade recorre a domínios sósias que imitam serviços online da Microsoft para operações de phishing do tipo adversário-no-meio (AitM) que abusam do fluxo de autenticação por código de dispositivo do Microsoft Entra ID.
• Entrega de malware. As páginas de aterragem usaram técnicas ClickFix, apresentando falhas de verificação falsas com instruções para copiar e executar comandos, e algumas serviram também um ficheiro APK, o que indica possível interesse em dispositivos Android.

Um detalhe importante: a Microsoft observou que a técnica do código de dispositivo não é nova, mas que inseri-la num portal cativo torna o pedido mais credível aos olhos do utilizador. É esta camada de contexto — estou num hotel, o Wi-Fi pede-me algo — que faz cair pessoas habitualmente atentas a e-mails suspeitos.

CornFlake, ChocoShell e FruitStone

O implante principal é o CornFlake, um trojan de acesso remoto escrito em Go que mostra uma janela de progresso falsa enquanto se instala e se registra como serviço do Windows com o nome de exibição «Cloud Sync Service». Segundo a Microsoft, o CornFlake expõe ainda um servidor de API HTTP em localhost (/upload, /reload, /status) que o transforma numa plataforma modular, permitindo a cargas seguintes pedir exfiltração de ficheiros, recarregar configurações ou verificar a ligação ao servidor de comando e controlo.

O ChocoShell é o infostealer da campanha, baseado em PowerShell e executado inteiramente em memória, com o objetivo de roubar em volume cookies de sessão do navegador, palavras-passe guardadas, tokens de single sign-on do Microsoft 365 e credenciais de Wi-Fi; onde o CornFlake garante persistência, o ChocoShell extrai as credenciais mais valiosas e abre a porta aos ambientes de nuvem da vítima. A gestão de tudo isto é feita através do FruitStone, um painel de comando e controlo baseado na web que centraliza a administração de máquinas comprometidas, a construção de novas cargas e a consulta dos dados recolhidos, como capturas de ecrã, teclas premidas e credenciais de navegador — com todas as funcionalidades expostas sem autenticação. O painel apresenta-se como «CloudSync Console», com um rodapé que imita um produto empresarial legítimo, para não levantar suspeitas caso o URL seja descoberto por defensores ou pelo alojamento.

A investigação da Zscaler resume o efeito estratégico: ao manipular DNS e HTTP na camada de rede, montar phishing AitM fora do perímetro corporativo e abusar do fluxo de código de dispositivo, o Storm-2945 contorna defesas que dependem da localização de rede e da autenticação multifator convencional.

Artefactos técnicos a procurar

As listas completas de domínios e endereços IP foram publicadas pelas equipas de investigação nos respetivos relatórios; recomenda-se que as equipas de segurança as consultem diretamente na fonte, já que a infraestrutura deste tipo de campanha é rotativa.

O que fazer: medidas concretas

• Impor VPN sempre ativa em modo full-tunnel nos dispositivos corporativos: encaminha todo o tráfego, incluindo DNS, pela rede da organização antes de chegar ao gateway do hotel, travando efetivamente o ataque.
• Tratar o Wi-Fi de hotéis, congressos e aeroportos como não fiável, preferir ligações móveis ou eSIM, nunca instalar software oferecido por um portal cativo, bloquear o fluxo de código de dispositivo quando não é necessário e adotar passkeys.
• Desativar o WPAD onde não é necessário e treinar os colaboradores para validar o URL e o certificado de qualquer página que peça credenciais, em especial em redes públicas.
• Em caso de suspeita, investigar tarefas agendadas e registos de serviços anómalos, autenticações não autorizadas por código de dispositivo e comportamento invulgar de PowerShell, incluindo tentativas de manipular o AMSI ou de contornar o UAC.
• Para quem opera redes de visitantes (hotelaria, congressos, universidades, saúde): retirar interfaces de gestão da Internet, substituir credenciais de administração reutilizadas, ativar autenticação forte no equipamento e manter o firmware atualizado.

Porque é que isto importa em Portugal

Portugal recebe milhões de visitantes de negócios e um calendário denso de congressos, o que coloca o setor da hotelaria e dos espaços de eventos exatamente na superfície de ataque descrita. A ReliaQuest avisa que qualquer organização que preste serviços de Wi-Fi com portal cativo — incluindo aeroportos, centros de congressos, unidades de saúde, universidades e recintos de eventos — enfrenta uma exposição semelhante. Para quem gere estas redes, o equipamento de portal cativo deixa de ser um detalhe de conforto do cliente e passa a ser um ativo crítico de segurança.

Há também um enquadramento legal a considerar. Com o novo Regime Jurídico da Cibersegurança, que transpõe a diretiva NIS2, as entidades abrangidas têm de gerir riscos de segurança das redes e notificar incidentes significativos, e a gestão de acessos privilegiados a equipamento de rede é precisamente uma dessas medidas basilares. Se do incidente resultar acesso a dados pessoais de hóspedes ou de colaboradores, aplicam-se ainda as obrigações do RGPD quanto à avaliação e eventual notificação da violação de dados. No plano operacional, o CERT.PT, integrado no CNCS, é o ponto de contacto para reportar e coordenar a resposta a incidentes no ciberespaço nacional. O CNCS já alertava, nos seus conselhos a viajantes, que em locais públicos como cafés, hotéis, portos e aeroportos não existe garantia de confidencialidade e que atacantes podem montar pontos de acesso aparentemente fiáveis para roubar informação.

Para as PME, a lição prática é económica antes de ser técnica: um portátil comprometido num hotel pode custar o acesso a toda a caixa de correio e ao armazenamento em nuvem da empresa. E a mitigação principal — VPN obrigatória, bloqueio do fluxo de código de dispositivo, autenticação resistente a phishing — usa controlos que, na maioria dos casos, já estão incluídos nas licenças que a organização paga.

Perguntas frequentes

Fico infetado só por me ligar ao Wi-Fi do hotel?

Não. A infeção exige uma ação do utilizador, como instalar uma falsa atualização, executar um comando ClickFix ou introduzir credenciais numa página falsa. No entanto, a manipulação de DNS começa no momento em que o dispositivo se liga à rede comprometida, pelo que a exposição é imediata.

A autenticação multifator protege-me nestes ataques?

A MFA clássica pode não bastar. O abuso do fluxo de código de dispositivo e o roubo de tokens permitem sessões já validadas. A recomendação é usar métodos resistentes a phishing, como passkeys, e restringir o fluxo de código de dispositivo por política de acesso condicional.

Existe algum CVE associado a esta campanha?

Até à data não foi divulgado um CVE específico. Os investigadores apontam, com confiança baixa a média, para interfaces de gestão expostas e credenciais de administração fracas ou reutilizadas nos equipamentos de portal cativo como via provável de acesso inicial.

O que devem fazer os hotéis e centros de congressos em Portugal?

Retirar da Internet as interfaces de administração dos equipamentos de Wi-Fi, trocar credenciais reutilizadas, ativar autenticação forte, manter o firmware atualizado e monitorizar alterações às configurações de DNS. Havendo suspeita de incidente, devem contactar o CERT.PT e avaliar as obrigações de notificação aplicáveis.

Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Microsoft Threat Intelligence, pela ReliaQuest, pela Zscaler ThreatLabz e pelo CNCS.