Defending against CVE-2024-21413 Outlook MonikerLink Bug Abuse
On 13 Feb (Patch Tuesday) Microsoft released a security update for Microsoft Office to address a critical vulnerability in Outlook (CVE-2024-21413). This vulnerability could allow an attacker to execute remote code on your system by sending you a malicious link that bypasses the Protected View feature.
On 14 Feb Check Point published the #MonikerLink bug/attack vector on the latest Windows 10/11 + Microsoft 365 (Office 2021) environments which they submit to Microsoft.
On 16 Feb SecurityOnline.info share the release of the PoC Exploit
These days most corporate have few hundreds to few hundred thousands of endpoints to patch, with patching automation on average most corporate would still require weeks of patching to fix the vulnerability. Now that PoC exploit is released, the race against time to patch endpoint has started! Adversary would probably starting to spray corporate with millions of emails trying to get the corporate user password hash.
Unfortunately Defender for Office 365 safe links only support http and ftp URI scheme 😥 so there is no way to detect abuse from there! However the game is not over yet with Defender for Endpoint and Defender KQL Advanced Hunting, SecOps can still create custom detection rule to check for this abuse and here's how can you do it.
First I created my own crafted email which abuse the Monikerlink bug.
For testing I used a non-existence private IP address so that my own NTLM password hash would not leak out 😅 When I clicked the file URI link. I received the below Outlook error and matches the Check Point article description. It was not block and system attempted to connect via SMB to 192.168.50.1 to get the file Monikerlink.rtf and attempted to used my NTLM password hash for challenge.
Recommended by LinkedIn
Now let's analyze with Defender KQL Advance Hunting with the SMB connection to IP 192.168.50.1
Adversary is going to send abuse link with IP that is on public internet so that they are able to collect the password hash. With this in mind if we create a custom KQL detection rule that runs near realtime or hourly with the below KQL, we should be able to have a good high detection rate to check for this abuse. Also most endpoint would not make SMB connection to public internet IP so this detection will not get falsely trigger.
DeviceProcessEvents
| where FileName=="OUTLOOK.EXE"
| join DeviceNetworkEvents on DeviceId
| where RemotePort == 445
| where RemoteIPType=="Public"
| where ActionType1=="ConnectionSuccess"
| project Timestamp, DeviceName, AccountUpn, ActionType1, RemoteIP
Updated 19 Feb 2024 - Added new KQL to exclude those endpoints that are already patched and reduce the false positive.
let VulnerableEndpoints =
DeviceTvmSoftwareVulnerabilities
| where CveId == "CVE-2024-21413"
| project DeviceId;
DeviceProcessEvents
| where FileName=="OUTLOOK.EXE"
| join DeviceNetworkEvents on DeviceId
| where DeviceId has_any(VulnerableEndpoints)
| where RemotePort == 445
| where RemoteIPType=="Public"
| where ActionType1=="ConnectionSuccess"
| project Timestamp, DeviceName, AccountUpn, ActionType1, RemoteIP
At least run this custom detection for weeks until all your endpoints are patched and you are more or less home free.☺️ KEEP CALM AND DEFEND !
#Microsoft #DefenderXDR #MDE #OutlookVulnerability #MonikerLinkBug #cybersecurity #cyberdefend
Chief Information Security Officer
10moIt turns out that almost any infected email can compromise the calendar sharing feature in Outlook by inserting two headers “Content-Class” and “x-sharing-config-url” (with specially crafted values). This forces Outlook to connect to the hacker's server and provide them with an NTLM hash for authentication.
I've just made an enhancement. FYI Steven Lim see if this is any good. I thought to only check for endpoints where the software version is vulnerable < 16.0.5435.1001 here's the query DeviceProcessEvents | where FileName=="OUTLOOK.EXE" | join DeviceNetworkEvents on DeviceId | where RemotePort == 445 | where RemoteIPType=="Public" | where ActionType1=="ConnectionSuccess" |join (DeviceTvmSoftwareInventory | where SoftwareName == "Microsoft Outlook" | where SoftwareVersion !startswith "16.0.5435.100") on DeviceName | project Timestamp, DeviceName, AccountUpn, ActionType1, RemoteIP I clubbed DeviceTvmSoftwareInventory with DeviceProcessEvents to come up with this
Thanks for the share, Steven! Looking at the KQL, is there a way to correlate the outlook process event with the network event, besides them being on the same device? Does the join connect the events that were generated on the same second? Or is this looking for a device that had a public SMB connection on a device also running outlook?
Manager, Cyber Response | DFIR & Threat Hunting at KPMG-Egyde
11moI just tested that query in a pretty decent Defender tenant and I had over 400 events in the last 7 days. Even more of them, going all the way back to last year. So that query may be good for Threat Hunting, but it is most likely not enough refined to be a detection as suggested in the post. Also, sadly, a lot of endpoints make SMB connections to the Internet for wtv reason there is. Try it yourself and you'll see: DeviceNetworkEvents | where RemotePort == 445 | where RemoteIPType == "Public" One day I'll set some time to fully investigate that stupid behavior.
Lead IT-Security bei KPT Krankenkasse AG
11momight be interesting to ommit the "ConnectionSuccess" clause, especially for folks who block SMB/microsoft-ds at their perimeter/local firewall, who wanna now nonetheless, if there are any attacks.