Out of Band NTLM Relay Using Outlook CVE-2023–23397 Vulnerability
In this article we will be focusing on an out-of-band lateral movement attack chain with the help of recent Outlook vulnerability CVE-2023–23397
What is the vulnerability ?
Briefly, on March 14th Microsoft has released a patch for a vulnerability in Outlook that allows an attacker to trigger NTLM authentication towards an untrusted system. While Microsoft has not disclosed the details on exploiting the vulnerability, they have initially provided an auditing script to check for mail items that could take advantage of the issue. MDsec team inspected the the script and discussed their findings in a blog post. The released script was checking for the PidLidReminderFileParameter property that controls the notification sound file name that the Outlook client plays a reminder. This property was able to receive a filename that is a UNC path to trigger NTLM authentication. It was detected that when this property is used together with the PidLidReminderOverride property, an attacker can send a crafted email item and cause Outlook to parse a malicious UNC path inside PidLidReminderFileParameter, triggering NTLM authentication towards the given system.
Brief Background on NTLM Relay
Before getting into the discussion of how this vulnerability could be extended further for lateral movement, let’s talk about NTLM relay and what can be relayed where for a second.
It is a common knowledge that after Microsoft had patched MS08–68, It was not possible to relay NTLM authentication back to the source machine anymore. However, as long as SMB signing is not enforced it is still practically possible to relay the NTLM authentication for one SMB server to a different server:
✔️ Victim → (Attacker Controlled)-SMB → (Target)-SMB,
As for the cross protocol NTLM relay, mainly the NetNTLMv2 authentication on different protocols with their default settings can be successfully relayed to SMB. Some examples are shared below:
✔️ Victim → (Attacker Controlled)-HTTP → (Target)-SMB,
✔️ Victim → (Attacker Controlled)-SMTP → (Target)-SMB,
✔️ Victim → (Attacker Controlled)-IMAP → (Target)-SMB,
✔️ Victim → (Attacker Controlled)-POP3 → (Target)-SMB
Lateral movement you said ?..
This vulnerability, when combined with a foothold in a target environment can increase chances of successful lateral movement drastically. For large enterprise environments that consist of thousands of endpoints, it is always a possibility that attackers achieve command execution on an edge system. These edge systems may not always hold high privilege users or credentials that can help the attacker advance in the target network and the target systems may not contain any vulnerabilities for the attacker to abuse from their initial foothold. By abusing this vulnerability, the attacker may have the ability to relay NTLM authentication of specifically chosen users through its own C2 channel to other target systems in the network. The below graph can summarise the generic traffic flow in this attack:
The proof of concept videos I have come across in the last few weeks were showing the Outlook triggered NTLM authentication over SMB protocol. In secure enterprise environments it is not very practical to expect endpoint systems to make outbound SMB traffic (Port 445) towards the internet. There is a higher chance that such egress traffic attempts from endpoints would directly be blocked at the perimeter firewalls. However, this vulnerability also allows the attacker to feed a WebDAV address for Victim outlook to attempt connection. As WebDAVtraffic will go through HTTP (80) and HTTPS (443) protocols, there is much higher chance that such traffic could be allowed egress through the perimeter. Of course nowadays, in many enterprise environments the endpoints cannot directly communicate with the internet and use of a Web proxy has become a standard. As the WebDAV communication started by Outlook application is also proxy aware, the attack flow may still continue unbroken through the endpoint assigned Web Proxy server.
Let’s talk about feasibility and practicality:
As good as this sounds, there is a caveat: In my tests I have seen that for victim system to attempt access via WebDAV protocol, it needs to have the WebClient service in running state. It is important to note that WebClient service is by default enabled but not running after boot. However, all is not lost for the attackers because many regular activities that enterprise users do on a Windows system (an example would be mapping of a network drive or as simple as typing a random word to the explorer address bar) can trigger start of this service in the background.This is demonstrated in the recording below:
Keeping in mind that most users do not shutdown their computers at all during the business week, there is a pretty good chance that at the time of such attack, the WebClient service could already be running on the targeted endpoint.
Demo time…
For demonstration purposes, I have provisioned a lab environment in which the attacker has already had a foothold within the target network on a system called BETADKTP05. Attacker’s beacon is active on BETADKTP05 and it is beaconing back to the C2 server “attacker.wan” over HTTPS. In our scenario, the attacker aims to use the credential of testuser01 who is actively using his Outlook on BETADKTP01 to achieve command execution on the server BETASRV01. testuser01 has administrator privileges on the system BETASRV01.
In the below recording you can see the initial step of the attack where once testuser01 receives the malicious email with attacker controlled UNC WebDAV path, the Outlook of testuser01 on BETADKTP01 automatically communicates with the company proxy server and the proxy server proxies this traffic to the attacker controlled WebDAV server on “attacker.wan”:
The WebDAV traffic coming from victim Outlook goes through the web proxy without an issue, we can continue building the attack chain. Instead of a dummy WebDAV server, we (as the attacker) plan on setting up ntlmrelayx, configuring socks proxy and forwarding the relayed NTLM authentication traffic to BETASRV01 through our beacon C2 communication on BETADKTP05. When we try to force NTLM authentication for this WebDAV communication however, we quickly discover that even though the victim system reaches out to the WebDAV server, it still does not attempt NTLM authentication, thus not allowing the attacker to capture or relay NTLM challenge response. When SMB protocol (port 445) is used, Outlook successfully attempts NTLM authentication to the remote “attacker.wan” system without any issue. In my tests with different Outlook versions, when WebDAV protocol is used, I did not see the vulnerability causing NTLM authentication to be attempted to a server outside the trusted zone. You can see the comparison of SMB and WebDAV based attacks in the below screen recording:
So… Does the attack chain fail then?
Not really… No. For this scenario, since we already have an active beacon inside the network and we have control of a regular domain user on BETADKTP05 we may still be able to quickly get around this limitation by creating a fake computer account using to the good old ms-ds-Machine-Account-Quota. Shortly, this is a setting that defines the number of computer accounts any regular domain user can add to an Active Directory domain and by default has a value of 10. Thus, we as the attacker can abuse this default AD setting and add a new fake computer account and a respective DNS record. You can see the computer account being created and a DNS record being added to the Active Directory in the below screenshots:
Complete Attack Chain Demo:
As we now have a DNS record in the trusted zone pointing towards our attacker system, this time the victim Outlook answers the “401 Unauthorized, NTLM Authentication required” message and starts NTLM authentication with the attacker’s WebDAV server over the Internet. A final touch is setting up of a socks proxy to tunnel relayed NTLM authentication traffic through the beacon on BETADKTP05. This can be done with a SOCKS capable C2 framework and a quick proxychains configuration on the attacker system. The end-to-end attack is presented in the following screen capture. At the end, the attacker is able to execute command on the target system BETASRV01 with system rights using the relayed NTLM credentials.
