Translate to English

A ultima vez que escrevi, foi sobre a forma como campanhas de phishing estavam a ser usadas para ultrapassar o MFA nas contas Microsoft.

Vamos agora fazer um deepdive, e perceber como são feitos esses ataques e também, uma forma simples de os detectar.

Os primeiros websites de phishing eram inicialmente clones estáticos do HTML/CSS e Javascript do site alvo. Eram desenhados para capturar e armazenar as credenciais inseridas por utilizadores desatentos.

Em certos casos, após obterem estas credenciais, esses sites redirecionavam o utilizador para o website legítimo real. No entanto, estes clones estáticos, enfrentam desafios na gestão de processos dinâmicos de login e de pedidos de autenticação multifator (MFA).

Com ferramentas como EvilGinx e Modlishka, os atacantes agora estabelecem um servidor proxy reverso, posicionado entre o utilizador e o website alvo. Esta configuração permite a alteração dinâmica de Javascript para espelhar o domínio de phishing, o qual pode ser ajustado para impedir a ativação de um HoneyToken não ofuscado.

Também facilita uma transição suave do utilizador para o site real após o roubo da sessão. Como o atacante atua como um proxy, o site legítimo é dinamicamente exibido ao utilizador. Esta abordagem permite ao atacante contornar várias formas de Autenticação Multifator (MFA), pois o utilizador, acredita que está a interagir com o site genuíno, respondendo assim aos pedidos de MFA, tais como aceitar uma notificação push ou introduzir um código SMS/TOTP.

Esta imagem demonstra como estes ataques funcionam, a Microsoft tem uma página que fala em detalhe.

Lamentavelmente, apenas a Microsoft pode implementar uma solução técnica que restrinja o ecrã de login a aparecer apenas quando o URL não corresponde ao esperado.

Podemos combinar esta técnica com políticas de Conditional Access, forçar MFA com FIDO, etc mas também, podemos implantar um HoneyToken, aproveitando a nossa capacidade de modificar o CSS da nossa página de login do EntraID. Este token, embutido no CSS, é projetado para verificar se o URL é o esperada. Se o referrer header corresponder ao esperado, a função termina retornando um GIF transparente de 1×1, caso contrário, emite um Redirecionamento HTTP para o servidor com o ID analisado.

Podemos depois com o serviço da CanaryTokens, gerar o token e escolher se queremos receber um alerta por email, ou então usar um webhook.

Com um webhook, pode-se depois, começar diversas automações, como criar alertas, bloquear o URL detectado no vosso filtro DNS, AntiSpam, ou outra solução que tenham na vossa empresa e que permita bloquear URLs - é importante bloquear na stack completa, ou seja, AntiSpam, Endpoint, Acesso, Core, etc.

Adicionalmente, este sistema nos fornece informações valiosas sobre a prevalência de tais ataques. Utilizando esses dados, podemos responder proativamente e melhorar nossas medidas de segurança e alertar os utilizadores.

O phishing continua a ser um método extremamente potente para comprometer os utilizadores. Com a evolução das ferramentas, quase todas as formas de Autenticação Multi-Fator (MFA), exceto FIDO2/Passkeys, são suscetíveis ao phishing Man-in-the-Middle (MitM) e ao roubo das sessões.

Embora esta solução não acabe completamente com o problema, continua a ser crucial manter um foco no treino e formação dos utilizadores, mas a culpa não é do end user.  Nós temos de continuar a passar a mensagem, e explicar, até à exaustão se for necessário!