As campanhas de phishing com IA generativa chegaram a um ponto de inflexão preocupante em 2026. Diferente dos ataques tradicionais que dependiam da instalação de malware no dispositivo da vítima, a nova geração de phishing orientado por inteligência artificial agora rouba sessões ativas diretamente no navegador, sem entregar payload algum. É exatamente este o alerta que a Dolutech traz neste artigo do Blog Dolutech: o phishing sem malware já é a realidade dominante no cenário de ameaças, e a sua empresa pode estar completamente exposta sem saber.
O Fim da Era do Malware no Phishing
Durante mais de duas décadas, o phishing seguiu um roteiro previsível: uma mensagem fraudulenta levava a vítima a clicar num link, um ficheiro malicioso era descarregado, um antivírus eventualmente detectava a assinatura, e o ataque era contido. O ecossistema de defesa foi construído em torno deste modelo: sandboxing, detecção baseada em assinaturas, análise comportamental de executáveis e bloqueio de downloads suspeitos.
Em 2026, este paradigma ruiu. As campanhas de phishing com IA generativa já não precisam de entregar um ficheiro malicioso. Em vez disso, utilizam páginas de autenticação falsas que funcionam como proxies inversos entre a vítima e o serviço legítimo. O utilizador vê o ecossistema real da Microsoft ou Google, introduz as suas credenciais reais, aprova o MFA no seu telemóvel, e a sessão é estabelecida com sucesso. Mas no caminho, o servidor do atacante intercepta o token de sessão e ganha acesso completo à conta. Este ataque chama-se Adversary-in-the-Middle, ou AiTM.
Como Funciona o Ataque de Roubo de Sessão
O Token de Sessão Como Chave Mestra
Quando um utilizador faz login no Microsoft 365, Google Workspace, Salesforce ou qualquer aplicação SaaS moderna, o serviço não exige palavra-passe e MFA a cada clique. Após a autenticação inicial bem-sucedida, o servidor entrega ao navegador um token de sessão, uma cadeia de caracteres que funciona como um cartão de acesso temporário. Durante horas ou até dias, o navegador apresenta esse token e o serviço confia nele implicitamente.
O problema é que qualquer pessoa que tenha esse token tem o mesmo nível de acesso que o utilizador legítimo, sem precisar do nome de utilizador, da palavra-passe ou do segundo fator. O token é a prova de que a autenticação já aconteceu. Para o serviço, o atacante é indistinguível do utilizador real.
Adversary-in-the-Middle: O Proxy Que Tudo Vê
No ataque AiTM, o atacante posiciona um servidor de proxy reverso entre a vítima e o site legítimo. O fluxo é simples e devastador:
- A vítima recebe um email de phishing convincente, frequentemente gerado por IA com tom empresarial impecável e urgencia calculada, com um link para um domínio controlado pelo atacante.
- O site falso não armazena credenciais. Em vez disso, atua como um espelho em tempo real: cada campo que a vítima preenche é retransmitido para o site real da Microsoft ou Google.
- Quando o site real solicita o segundo fator, o proxy encaminha o pedido para a vítima, que aprova a notificação no seu telemóvel.
- No momento em que a autenticação é concluída, o servidor legítimo emite um token de sessão válido. O proxy do atacante intercepta-o em trânsito.
- O atacante importa o token para o seu próprio navegador e acede à conta como se fosse o utilizador, com todos os privilégios, sem disparar qualquer alarme.
A vítima vê o dashboard normal, a sessão parece legítima, e não há qualquer indício de comprometimento. Não há malware para o EDR detectar. Não há ficheiro suspeito para a sandbox analisar. Há apenas um token que foi desviado em pleno voo.
Phishing as a Service: A Industrialização do AiTM
O que torna este cenário particularmente alarmante em 2026 é que a barreira de entrada colapsou. Kits de phishing AiTM como Evilginx, Tycoon 2FA e Mamba 2FA estão disponíveis como serviço de subscrição na economia do cibercrime por menos de trezentos dólares por mês. O Tycoon 2FA, operado pelo grupo Storm-1747, chegou a ser responsável por 44,5% de todos os ataques de roubo de credenciais e 89% do mercado de Phishing as a Service (PhaaS) AiTM em 2025. Uma operação conjunta da Microsoft, Europol, Cloudflare e Intel 471 desmantelou parte da sua infraestrutura em março de 2026, mas o ecossistema redistribuiu-se em vez de desaparecer.
A segunda via de ataque é o malware infostealer. Ferramentas como LummaC2, RedLine e StealC são distribuídas através de downloads falsos, atualizações de browser fraudulentas ou anexos maliciosos. Executam durante trinta segundos, recolhem todos os cookies de sessão e credenciais guardadas de cada navegador no dispositivo, enviam para um servidor de comando e controlo, e autoeliminam-se. Um dump completo de browser de um portátil corporativo é vendido em fóruns criminais por quinze a cinquenta dólares.
Em maio de 2026, o Google Threat Intelligence Group reportou o primeiro caso documentado de um cibercriminoso a utilizar um agente de IA autónomo para conduzir uma campanha completa de AiTM, desde a geração do email de phishing até à exfiltração do token, em menos de sessenta segundos após a interação da vítima.
Tabela MITRE ATT&CK
| Tática | Técnica | ID | Descrição |
|---|---|---|---|
| Initial Access | Phishing | T1566 | Email de phishing gerado por IA como vetor inicial |
| Credential Access | Adversary-in-the-Middle | T1557 | Proxy reverso intercepta credenciais e tokens em tempo real |
| Credential Access | Steal Web Session Cookie | T1539 | Captura de cookies de sessão pós-autenticação MFA |
| Credential Access | Token Impersonation/Theft | T1134.001 | Reutilização de token de acesso para impersonação |
| Defense Evasion | Proxy: Multi-hop Proxy | T1090.003 | Infraestrutura de proxy reverso para ofuscar origem |
| Execution | User Execution: Malicious Link | T1204.001 | Vítima clica em link de phishing convincente |
| Collection | Data from Information Repositories | T1213 | Acesso a emails, ficheiros e dados após roubo de sessão |
Indicadores de Comprometimento (IoCs)
| Tipo | Indicador | Contexto |
|---|---|---|
| Comportamento | Login bem-sucedido com localização geográfica anómala | Token importado de região diferente da vítima |
| Comportamento | Sessão iniciada com user-agent diferente | Atacante usa navegador distinto do original |
| Comportamento | Criação de regra de inbox forwarding | Pós-comprometimento para manter persistência |
| Comportamento | Vários logins de IPs distintos em segundos | Automação de importação de tokens |
| Rede | User-Agent: Evilginx/3.0 | Assinatura do proxy AiTM |
| Rede | Domínios com typosquatting de portais Microsoft/Google | Ex: micr0soft.com, g00gle.com |
| Regras de encaminhamento automático criadas | Persistência pós-roubo de sessão |
Nota: Os IoCs acima são indicadores genéricos baseados em padrões de ataque documentados. IoCs oficiais de campanhas específicas devem ser obtidos junto dos fornecedores de segurança e agências como CISA e CERT.PT.
Por Que o MFA Já Não Chega
O MFA foi concebido para bloquear ataques de password guessing e credential stuffing, e nisso continua a ser extremamente eficaz. Mas o AiTM e o roubo de tokens atacam o que acontece depois da autenticação, e o MFA nunca foi desenhado para proteger o pós-login. O token de sessão já contém a prova de que o MFA foi satisfeito. Uma vez roubado, o atacante herda essa prova.
Segundo a Cisco Talos, quase metade dos incidentes de segurança a que a sua equipa respondeu já em 2024 envolviam fragilidades relacionadas com MFA, desde fadiga de push notifications até ao roubo de sessões autenticadas em tempo real. Em 2026, o token theft é o vetor de ataque à identidade mais comum contra ambientes cloud empresariais, ultrapassando o tradicional roubo de credenciais.
Uma campanha documentada pela Microsoft em maio de 2026 utilizou mais de 13.000 domínios de atacante e visou dezenas de milhares de utilizadores em 26 países. O tema era um falso código de conduta empresarial. As vítimas passavam por múltiplas etapas, incluindo CAPTCHAs reais e páginas intermediárias que filtravam bots de segurança, ate chegarem ao fluxo AiTM onde o token era capturado.
Comandos de Mitigação Práticos
Microsoft 365: Detetar Regras de Encaminhamento Ocultas
# Listar regras de encaminhamento externo em todas as caixas de correio
Get-Mailbox -ResultSize Unlimited | ForEach-Object {
$rules = Get-InboxRule -Mailbox $_.Identity | Where-Object { $_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo }
if ($rules) { Write-Host "$($_.Identity): $($rules.Name)" }
}Auditar Logins com Token Anómalo (Azure AD)
# Detetar sessões onde o user-agent mudou subitamente
SigninLogs
| where ResultType == 0
| project UserPrincipalName, IPAddress, UserAgent, CreatedDateTime, Location
| order by CreatedDateTime descBloquear Navegadores Desatualizados em Acesso Condicional
# Exigir browser moderno com suporte a FIDO2
New-AzureADMSConditionalAccessPolicy -DisplayName "Require Modern Browser" `
-Conditions @{ClientAppTypes = @("Browser"); Browser = @{SupportedBrowsers = @("Edge","Chrome","Firefox")}}Mitigações Recomendadas
A defesa contra o phishing sem malware exige uma abordagem em camadas que vai além do MFA tradicional:
- Adotar MFA resistente a phishing (FIDO2/WebAuthn). Passkeys e chaves de segurança como YubiKeys vinculam criptograficamente a autenticação ao domínio legítimo. Um proxy AiTM num domínio falso não consegue retransmitir o desafio FIDO2 porque a chave privada está vinculada à origem. Este é o padrão ouro definido pela CISA.
- Implementar políticas de Acesso Condicional. Exigir dispositivos conformes, bloquear logins de localizações de risco e forçar reautenticação quando o risco de sessão é elevado. O token roubado perde utilidade se o acesso for bloqueado por políticas baseadas em contexto.
- Ativar proteção de rede e SmartScreen. O Microsoft Defender SmartScreen bloqueia proxies AiTM conhecidos ao nível do browser, impedindo que a vítima complete o fluxo de autenticação no site falso.
- Monitorizar ativamente tokens de sessão anómalos. Soluções como Microsoft Defender for Identity e Azure AD Identity Protection detectam quando um token é utilizado a partir de uma localização ou dispositivo inconsistente com o comportamento habitual do utilizador.
- Eliminar MFA baseado em push e SMS. Notificações push, códigos SMS e TOTP (aplicações autenticadoras) não têm vinculação de origem e são vulneráveis a AiTM. A migração para FIDO2 deve ser uma prioridade em 2026.
- Implementar session binding estrito. Vincular tokens de sessão ao endereço IP, user-agent e impressão digital do dispositivo que iniciou a sessão. Se um token for importado para outro dispositivo, a sessão é invalidada.
Impacto Regulatório
O roubo de sessões e o comprometimento de contas cloud têm implicações diretas em múltiplos regimes regulatórios. Na União Europeia, a diretiva NIS2 classifica os serviços cloud como infraestrutura crítica e exige notificação de incidentes significativos em 24 horas. O DORA, aplicável ao setor financeiro, impõe testes de resiliência operacional que devem contemplar cenários de AiTM contra sistemas de autenticação. O RGPD, por sua vez, aplica-se sempre que dados pessoais são acedidos através de uma sessão comprometida, com coimas que podem atingir 20 milhões de euros ou 4% do volume de negócios global. Em Portugal, o CERT.PT e o CNCS coordenam a resposta a incidentes e disponibilizam orientações técnicas para mitigação de ataques de token theft.
No Brasil, a LGPD exige que o controlador notifique a ANPD e os titulares em caso de incidente de segurança que possa acarretar risco ou dano relevante. Um acesso indevido via sessão comprometida que exponha dados pessoais é um incidente notificável. A ANPD tem intensificado a fiscalização sobre medidas de segurança proporcionais ao risco, e a ausência de MFA resistente a phishing pode ser considerada uma falha de diligência em setores regulados.
Conclusão
O phishing em 2026 já não é um ataque de malware. É um ataque de engenharia social aumentada por IA que rouba a sessão depois de a vítima fazer tudo certo, incluindo o MFA. A Dolutech recomenda que as organizações tratem o token de sessão como o novo perímetro de segurança: tão importante quanto a palavra-passe, e frequentemente mais valioso para o atacante. A adoção de MFA resistente a phishing, políticas de acesso condicional e monitorização contínua de sessões são os três pilares da defesa moderna contra esta ameaça invisível que já não deixa rasto de malware.
