CVE-2023-23397 Addresses NTLM Vulnerability
Updated 16 March 2023
Patch Tuesday brought news of an Outlook Elevation of Privilege Vulnerability (CVE-2023-23397). The issue is also described in the EHLO blog under an “Awareness” heading. The problem is serious enough for Microsoft to issue a bunch of security updates covering everything from Microsoft 365 apps for enterprise (subscription-based Outlook) to Outlook 2013 SP1. The bottom line is that “an attacker who successfully exploited this vulnerability could access a user’s Net-NTLMv2 hash which could be used as a basis of an NTLM Relay attack against another service to authenticate as the user.”
Microsoft also issued a PowerShell script (CVE-2023-23397.PS1) to run against on-premises and cloud servers to check if items contain a property that’s populated with a UNC path. The audit mode of the script reports what it finds in a CSV file that administrators can check to decide which of the reported items to remove from mailboxes. Running the script in clean-up mode permanently removes the offending items.
A good analysis of the Outlook vulnerability by MDSEC reveals details of what the script looks for and describes how the vulnerability works. Essentially, an Outlook item can populate the PidLidReminderFileParameter property, described in Microsoft documentation as specifying “the filename of the sound that a client should play when the reminder for that object becomes overdue.”
An attacker can exploit the vulnerability by sending a specially-formatted appointment to a user. The appointment is already expired and its PidLidReminderFileParameter property points to a UNC path, which provokes Windows to send the user’s login name and their NTLM password hash (a technique used in other attacks like this example). When Outlook processes the message, the attacker gets the user credentials and can use them to compromise the account. Because the message is an appointment, Outlook doesn’t open it in its preview pane and processes the calendar item behind the scenes, so the user might not even be aware that they received a malicious appointment.
Cybersecurity Risk Management for Active Directory
Discover how to prevent and recover from AD attacks through these Cybersecurity Risk Management Solutions.
Outlook’s Old Properties
I’ve no idea why Outlook has such a property. Being able to play a bespoke sound when an item becomes overdue seems like one of those cute ideas that made sense when computer systems were under less threat than today. I’ve never used the feature and I can’t recall ever knowing of an application that sets its own reminder overdue sound by pointing to a sound file stored somewhere.
But Outlook for Windows is a very old program, and its code base is convoluted. That’s one of the reasons why Microsoft is developing the Monarch client (or “One Outlook”) to replace today’s Windows client. The Monarch client is basically an enhanced version of the OWA client that runs in Exchange Online. According to message center notification MC526128 (11 March), users of the Current Channel for Microsoft 365 apps for enterprise will be able to try out the new client in early April, while those who use the Monthly Enterprise Channel will see it in May.
Because the browser clients don’t support NTLM, OWA and Monarch don’t have the vulnerability. However, there are many Outlook for Windows clients in use in on-premises and cloud environments that attackers might be tempted to target by sending a message in an attempt to capture log-in credentials.
Mitigations
The following mitigations exist (in order of priority):
- Blocking TCP 445/SMB outbound from your network to stop the NTLM traffic.
- Patch Outlook with the security updates available from Microsoft. If a security update isn’t available for a version of Outlook running in your organization, update Outlook to a supported version. This action is your number 1 priority. If vulnerable Outlook clients remain active, your organization is open to exploitation.
- Microsoft recommends that you consider adding on-premises accounts to the Protected Users Security Group. Windows 2012 R2 and newer domain controllers support this group, which prevents the use of NTLM as an authentication method by group members. Microsoft warns that adding everybody to the group might impact applications that require NTLM, so this is a tactic best used for selected high-profile accounts. Be sure that you read the documentation for the Protected Users Security Group before you use this tactic.
- Run the PowerShell script developed by Microsoft to find and remove suspicious items. This action isn’t a mitigation for the vulnerability. It merely finds items that might contain a payload. The script is not fast. There’s no good way to filter on the PidLidReminderFileParameter property, so the script uses Exchange Web Services (EWS) to examine the properties of individual mailbox items. Depending on mailbox sizes and the number of items in the mailboxes, this script will take hours rather than minutes to run. It’s not a snappy process. Several problems have been reported with running the script, so check this page to see the known issues.
Update March 21: Microsoft has released an update for the script that includes a preview mode that’s designed to make the script run faster. The script is self-updating and should download the new version the next time you run it. If you have problems with the script, send email to ExToolsFeedback@microsoft.com.
Time to Update
Let’s be clear: this is an Outlook for Windows vulnerability and not a problem with Exchange Server or Exchange Online. The issue can appear in vulnerable Outlook clients connected to pure on-premises, hybrid, or cloud environments. The fact that Microsoft lists more points of mitigation for the on-premises environment might lead people to think otherwise, but to me their focus is simply because:
- There are many old and badly maintained Exchange Server environments. We know this from the experience of dealing with recent attacks (going back to Hafnium in 2021). If the server environment runs without updates, it’s likely that the client environment is also in a poor state.
- Perhaps because they’re aware of the first point, attackers continue to focus on Exchange Server as a target.
- The recent project to eliminate basic authentication from Exchange Online forced many tenants to review how they connect clients to Exchange. Generally, Exchange Online deployments are in better shape than on-premises deployments when it comes to resisting attack.
- Multi-factor authentication can protect Exchange Online (Azure AD) accounts. Even if an attacker gets hold of user and password credentials via NTLM diversion to a UNC target, the won’t be able to compromise the Azure AD account unless they work around the MFA challenge. This is yet another reminder to Microsoft 365 tenants that they should make it a priority to deploy MFA for all accounts. Attackers could use retrieved password information to sign into services that are not MFA-protected, including those outside Microsoft 365 if people use the same username and password combination there.
- The version of OWA available for Exchange Online is much better than that available for any version of Exchange Server. Those that ran Outlook for Windows in the past might now use OWA when connected to Exchange Online.
Some will say that this vulnerability is another example of Microsoft not protecting the on-premises community. A more pragmatic view might be that old software is always more liable to have issues lurking in the code. If your organization remains committed to running on-premises Exchange, the only safe way to operate is to keep all parts of your on-premises infrastructure updated, including Outlook.
Hey Tony. As of 2/29 this post is still misleading in saying that 365 outlook client is not vulnerable because it doesnt use ntlm.
Here is how I understand that it works:
-If you are using Any windows outlook client you are vulnerable including the 365 apps
-Once the outlook client is exploited, your NTLM Hashes get dumped to the remote attacker
-Once the hashes are cracked (or are they plaintext credentials? I dont remember and it doesnt matter in this explanation) then the attacker can use your credentials for anything that you use your credentials for which includes things like RPC if its enabled.
So it doesnt matter if the 365 client doesnt use NTLM or not, they get dumped regardless and can be used in any way the attacker wants. Please forgive me if this is incorrect, but thats how I currently understand how it works
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
Hi Sheldon,
I’ve checked the text and can’t find anything that says that the Outlook subscription client is not vulnerable. Could you point me to the words that you are worried about? Given the dynamic nature of this incident, I applied several updates to the text as new information emerged. There was some confusion initially about if Office 365 was exposed and I added a chunk of text to explain why I think the issue is less likely to appear there, but there’s no doubt that someone could be exposed if they used an old client and their credentials were transmitted to an attacker. Even if their account was protected by MFA, the attacker might be able to use the credentials to access a service that doesn’t use MFA.
Good afternoon, all.
Tom, I received a list of 20 servers from the security team at the company I do consulting and they are Server 2016 (64-bits). They all have Office 2016 Standard installed and I downloaded (KB5002254) to start the installation tests on a Test server. When I run setup, I get a message like this: “There are no products affected by this package installed on this system”.
Even if I have Outlook 2016 installed, can I say that this server is safe from the CVE-2023-23397 threat?
Best Regards and thanks for the excellent article!
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
Why is Office installed on a server? Generally speaking, this is a bad idea.
In any case, AFAIK, all Outlook versions are vulnerable unless patched. Perhaps you’re using an incorrect patch OR the patch doesn’t run on a Windows server.
Correct, the patch was wrong and I was trying to install the 64-bit one. I installed the 32-bit and it worked, thanks. I questioned this to the customer and he said he uses it for RPA automation, but I totally agree with you Tony. We shouldn’t have Office installed on servers. Now, I have a problem that 3 servers on the list are using Microsoft Apps 365 and, from what I’ve seen, we don’t have a patch for that version, is it correct?
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
No, there is a patch listed for Microsoft 365 apps on the CVE page. I must say that I didn’t use it because the version of the Microsoft 365 apps I use is version 2303 and the fix is in that.
Microsoft 365 Windows Outlook app is vulnerable, but so far I cannot find an actual PATCH to apply for it.
https://msrc.microsoft.com/update-guide/en-us/vulnerability/CVE-2023-23397
This article just goes in circles.
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
The updates are available in the Security Updates section of the page. There are links to the individual Knowledge Base articles for each version of Outlook.
I also looked in the section where we have the KB’s, but there´s no link to download the patch, it just forwards to the link: https://learn.microsoft.com/en-us/officeupdates/microsoft365-apps-security-updates
So does this attack ultimately steals your Windows Active Directory username and password?
If you are running a local domain controller, what can the threat actor do by having your username and password?
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
If an attacker has your username and password, they can sign in as you – but only to systems that are accessible via the internet.
Hi Tony,
So they really cannot access my local Windows domain (hosted on a local onprem server) even if they have the username and password, is that correct? Is there anything else that they can do from this exploit?
A well configured firewall in most large enterprises would I hope prevent any Hashes being exchanged over port 445 so may but time for patching but obviously not with home workers. I think all bases need to be covered to avoid a disaster
Si tengo un ambiente hibrido; todos mis usuario migrados a Exchange Online, y mis clientes de Outlook en Windows 10 se actualizan a través de la paquetería de Office 365. Pero veo que en la pagina de Microsoft no existe un parche de descarga de manera explicita para Office 365. ¿En este caso como puedo actualizar mis clientes para mitigar la vulnerabilidad; tendria que descargar e instalar la ultima versión de la paquetería de Office 365?
good day
It is possible in some way to know or generate a report to identify if the organization has already been attacked taking advantage of the reported vulnerability, if possible you can share this information with me to review.
thank you so much
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
I don’t think this information is available. Running the script provided by Microsoft is the only way to find any evidence that an organization might have problem items, some of which might indicate an attack.
Buen dia
Es posible de alguna manera saber o generar un reporte para identificar si la orgnizacion ya fue atacada aprovechando la vulnerabilidad reportada, si es posible me puedan compartir esta informacion para revisar.
Muchas gracias.
Running the script (after patching) and I am seeing it flag some very old emails from 2012. Do you have any insight as to if this might be a false positive or if the manipulated email is able to drop the payload on old emails?
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
Possibly caused by an add-in that actually did want to add its own sound file for an expired item. I think we’re concerned about relatively new messages. Items from 2012 should be safe. To be sure, you could examine them with MFCMAPI to check what the property contains.
Thanks, this article and the discussion below has clarified what exactly the risk is. We have done some mitigation as a result and issued internal advice too (and we have MFA in place already) so now we are just waiting for the M365 click-to-run client patches to roll out.
If the question “Is your comment based on the old text or the new?” is @ me, it’s the current text. Admittedly, I read it last night and was more concerned, so I appreciate your update.
My remaining concern with the current verbiage “Even though Exchange Online doesn’t support NTLM, the possibility exists that an Exchange Online user could forward an infected item to an Exchange on-premises account and create an open vector for attack. For that reason, the script can process Exchange Online mailboxes.”
The issue can still present itself if a cloud mailbox user is sitting in front of their workstation on their physical, corporate network, using their AD account. No need to forward an email to anyone – as soon as that reminder goes off it’s time for pwnies.
The video demonstration from MDSec shows how it works; there’s not prompt to login, be it an old-fashioned username/password pop-up nor a modern auth challenge – it simply dumps the data because Outlook was happily sending it across (without the patch or the mitigations, I mean).
I am curious about your note on MFA – how does MFA protect an account if the exploit shares NTLM hashes? If there is no prompt for auth, and if there is no way to shoehorn MFA into NTLM (to my knowledge there isn’t but will happily be told I’m wrong), then how would MFA help here? It’s not like the endpoint in the reminder (e.g., an unfamiliar IP address) is going to see if you have a preferred IDP configured.
And while the internet always has a sense of “finger-pointing arguments” in comments, I’m not doing that here; I want to make sure we’re on the same page on the former item, and I’m brought up to speed on anything I’m missing on the latter.
And sorry the comment is at the “root” now; we went too far deep with “reply to”, I believe.
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
No issues. The purpose here is to share experience and make sure that the right thing is done.
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
MFA protects because although the attacker has the user account and password, they won’t be able to authenticate without being able to respond to the MFA challenge. So even if the exploit is successfully in dumping credentials into the UNC, the attacker can’t use the credentials. That’s my point. MFA is an post-exploit protector.
Another thing that strikes me, if we find problem items in Exchange Online mailboxes, it’s a good idea to force a password change to make sure that accounts that don’t use MFA are secured again. But use MFA!
Ah, if the attacker is able to decrypt/use the hash in an attempt to access the victim’s resources. I’m with you now. 🙂 That does make sense with cloud-based systems/resources using an IDP.
The only other consideration in my mind now is if the attacker already has access to the network; perhaps as part of a multistage attack. Obviously, the use of hashes themselves won’t work on M365 resources, and MFA/conditional access can help with a decrypted hash, but if they are already in the network, the hashes are all they need. That’s where my initial thoughts were; the traditional “pass-the-hash” type of attack.
This exploit honestly feels like part of something bigger; not a simple credential gathering to try and breach services.
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
If attackers are in your network, your day has just got a lot worse and the complexity of disinfection is long past updating Outlook clients…
lol, for sure! I think back to Solarigate, specifically. The intruders got into SolarWinds network but didn’t execute for six months. 😐
We have all mailboxes hosted in Exchange Online and are licensed to use M365 Defender. Is it safe to assume that M365 Defender is now actively blocking incoming emails containing the exploit? I haven’t seen that mentioned anywhere.
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
I do not know if Microsoft Defender is blocking these messages. One would hope that they are, but I can’t say. Microsoft might not make a definitive statement because they are always cautious about making absolute pronouncements. I anticipate that they are blocking the issue given that it is now a well-known threat.
We are hybrid, with all mailboxes in exchange online, modern authentication activated.
Is it then possible to exploit the vulnerability at all?
We just have, some scanner etc. With SMTP auth left (cloudmailboxes)
Are there any special parameters that should be utilized in the script when scanning Exchange Online? We have 30,000 mailboxes and at its current rate, will take over a week to complete…
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
I would not take the guidance to simply do a Get-Mailbox and process everything. Break the processing up into smaller chunks by applying a filter to the Get-ExoMailbox cmdlet and start with the highest priority mailboxes first.
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
Hybrid mailboxes left on-premises that aren’t accessed by Outlook for Windows clients are fine.
Why do you mention on Premises Community here? Cloud Mailboxes are affected the same way as it‘s a vulnerability in the Client, right?
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
Exchange Online doesn’t support NTLM and while credentials could go to a UNC they’ll be useless if the account is protected by MFA, which it should be.
It’s true that the leaked credentials can be used against Exchange Server but can’t be used against Exchange Online or other Microsoft cloud services.
But this is not just an on-premises issue. It doesn’t matter where your mailbox is; because it is an Outlook vulnerability, users in both Exchange Online and Exchange Server can leak NTLM creds. That’s why we developed a script that can scan both Exchange Server and Exchange Online mailboxes for potential malicious messages.
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
Exchange Online doesn’t support NTLM.
The obvious way you’re going to leak credentials is to send email from EXO to an on-premises recipient. This can happen, and it’s of concern. I guess that an Exchange Online recipient might receive email from an attacker that ends up with their credentials going to a UNC, but hopefully their account is protected by MFA.
However, before anyone starts to run a script (that might take a very long time to complete), update the vulnerable Outlook clients. That’s the first and most important step to take. If you don’t update Outlook, you’re open to exploitation.
I am really confused why you so strongly believe Exchange Online’s not supporting NTLM _AUTHENTICATION_ protects bugged Outlook client users whose mailboxes are on Exchange Online?
Why wouldn’t the bugged Outlook _CLIENT_ send NTLM hashes to that UNC path when it parses email item containing malicious PidLidReminderFileParameter?
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
Right. An Exchange Online recipient could get one of the specially formatted messages from an attacker that pumps their credentials to the UNC. However, my hope is that the account is protected by MFA and so the basic username/password combination wouldn’t work for the attacker. There’s a lot more MFA in the cloud (still not enough) than exists on-premises and I guess that was in my mind. I have updated the text of the article to reflect this.
Tony, are you fundamentally misunderstanding the problem? Scott, a Microsoft employee that works on Exchange is saying that this isn’t an EXCHANGE issue, it’s an outlook client issue, and that the vuln is that the NTLM hash isn’t leaked from exchange to the adversarial remote server, it’s leaked from the CLIENT to the remote adversarial server. MS needs to hurry up and clarify this on official channels because this is confusing a lot of people that it should NOT be confusing right now.
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
I don’t misunderstand the problem. The text makes it clear that this is an Outlook problem. What I didn’t make clear is why I think it is more applicable to the on-premises environment. I’ve fixed that problem now. Mind you, given that Microsoft listed a bunch of mitigations that only apply to on-premises deployments, others might have also gone down that path.
Let me also clarify the comment about Scott. I’ve known Scott for a long time and we don’t always agree with how to communicate issues. His job is to represent the Exchange development group. Mine is to give independent commentary. As it happens, I passed my text past several Microsoft employees before I posted and no one reacted in a bad way. But situations like develop as more knowledge becomes available and more people think about the problem. That’s the phase we are in now and that’s why I was happy to add further text to clarify why I think this is mostly a problem for those running on-premises deployments. Badly managed Exchange Online tenants are also vulnerable. In fact, anyone who runs outdated Outlook is vulnerable unless they know otherwise.
Thanks for the clarification Tony. I hope that MS can also update their article: https://msrc.microsoft.com/blog/2023/03/microsoft-mitigates-outlook-elevation-of-privilege-vulnerability/
which has the line: “Online services such as Microsoft 365 do not support NTLM authentication and are not vulnerable to being attacked by these messages.”
I believe that line should be re-worded. They bolded the line, and there are people believing “oh, I have my mailbox in “Microsoft 365”, so therefore I am not vulnerable. That is NOT true.
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
To be fair, documenting these furballs can be a nightmare. That’s why we all need to use our experience and common sense to interpret what we hear and learn and put that into context for the organizations we represent.
Users with Exchange Online mailboxes can still be impacted. It’s a theft of the NTLM hashes in the user’s profile on the workstation, not the mailbox or the connection to the mailbox. So if I receive one of these emails, and I’m sitting on my corporate network (or VPNed into my corporate network) and I have an AD account then the hashes available in my session can get taken by this because the connection is via SMB.
I would think the only instance where someone isn’t impacted would be if they were “cloud only” with an Azure AD account, their workstation is managed by Intune, and they have no need to connect to the corporate network or use any SMB/UNC paths whatsoever.
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
Or Outlook is updated…
Or their account is protected by MFA…
I attempted to clarify the situation with new text in the article. Is your comment based on the old text or the new?
Scott, where is the NTLM hash being pulled from? Outlook? If so, why would Outlook contain this hash if the user’s mailbox is in Exchange online?
Or is the NTLM hash being pulled from elsewhere in Windows?
CVE-2023-23397 allows a threat actor to send a specially crafted email with a malicious payload that will cause the victim’s Outlook client to automatically connect to a Universal Naming Convention (UNC) location under the actor’s control to receive the Net-NTLMv2 user’s password hash. This disclosure of credentials would permit further methods of exploitation.
So nothing is PULLING creds. The flaw is that outlook happily tries to SEND your creds (username and hash) to a server under a threat actors control.
This is why those thinking they’re safe if their mailbox is hosted in 365 is wrong. The client is the problem here.
The Real Person!
Author Tony Redmond acts as a real person and passed all tests against spambots. Anti-Spam by CleanTalk.
Right. This is an Outlook for Windows vulnerability. However, if the user and password credentials end up with an attacker, the Azure AD account can still be protected by MFA.