October Exchange Zero Day - Everything You Need to Know and Do

Early August 2022, the Vietnamese organization GTSC Cyber Security noticed anomalies in their SOC and they discovered their Exchange servers were under attack. They quickly determined the attack utilized an unpublished Exchange security vulnerability. Due to earlier Exchange attacks GTSC quickly uncovered the vulnerability and Microsoft was informed about the vulnerability at this time. Microsoft needed some time as well for investigation and remediation, but the Exchange world was made aware of potential 0-day vulnerabilities this Thursday (09/29) through the following tweet by security researcher Kevin Beaumont:

🚨 There’s reports emerging that a new zero day exists in Microsoft Exchange, and is being actively exploited in the wild 🚨

I can confirm significant numbers of Exchange servers have been backdoored - including a honeypot.

Thread to track issue follows:

— Kevin Beaumont (@GossiTheDog) September 29, 2022

The write-up referenced a Vietnamese website of vendor GTSC Cyber Security, which published their discovery on a what looked like a variation on ProxyShell., allowing for Remote code execution. The Zero Day Initiative (ZDI) verified the vulnerabilities by ZDI-CAN-18333 (rated CVSS 8.8) and ZDI-CAN-18802 (CVSS 6.3), adding credibility to the publication while the world was trying to find out what was going on. The vulnerabilities have been registered by the Common Vulnerabilities and Exposures program, and they are now also known as CVE-2022-41040 (ZDI-CAN-18333) and CVE-2022-41082 (ZDI-CAN-18802).

Vulnerability

The 0-day impacts current versions of Exchange Server 2019, Exchange Server 2016 as well as Exchange Server 2013 when published externally. If you have Exchange Hybrid deployed only for recipient management or mail-flow, or you allow only access to your Exchange servers after connecting to the corporate VPN, you should not be impacted.

Like ProxyShell, the vulnerability consists of sending manufactured requests to Exchange server, e.g.

https://mail.contoso.com/autodiscover/autodiscover.json?@fabrikam.com/<Exchange-backend-endpoint>&Email=autodiscover/autodiscover.json%3f@fabrikam.com

<Exchange-backend-endpoint> is the endpoint where the backdoor could be implemented if PowerShell is available to the bad actor on the Exchange server. In case of GTSC, a backdoor was used mimicking Exchange Web Services.

The published vulnerability consists of two elements:

• The first part -or stage - is a way to pass manufactured requests to Exchange server (CVE-2022-41040)
• The second part is installing a backdoor through PowerShell, which can respond to these manufactured requests (CVE-2022-41082).

While related, these elements can operate independently of each other. Note that the manufactured requests need to be authenticated, but that does not make organizations less vulnerable, as the requestor only needs to be a regular user, and given all the weaknesses around Basic Authentication method. And to be clear, the authenticated user only needs to be a regular user.

Mitigation

In their publication, GTSC also mention measures to mitigate the issue. This essentially consists of adding URL rewrite rules to IIS to the FrontEnd site, blocking requests to {REQUEST_URI} path:

.*autodiscover\.json.*\@.*Powershell.*

After GTSC published their findings, Microsoft remained rather silent on the subject, except for a confirmation that the reports where being investigated and a note to say that Exchange Online is not impacted. A blog appeared shortly after Microsoft Security Response Center.

Many were expecting that Microsoft would quickly push a rule through their Exchange Emergency Mitigation Service (EEMS), a service which became available in Cumulative Updates of September 2021 for Exchange 2019 (CU11) and Exchange Server 2016 (CU22) or later versions. The Emergency Mitigation Service can look for and implement emergency changes to its URL Rewrite ruleset, as published by Microsoft.

That didn’t happen initially, and Microsoft published information on how to mitigate the issue by configuration changes to URL Rewrite. Unfortunately, the initial information was discovered to be flawed. This has been corrected now, and the following information and tools are available for organizations running Exchange on-premises, apart from 3rd party initiatives:

1. There's a Security blog containing an analysis and (corrected) steps for implementing manual mitigation measures.
2. An update for the Exchange On-Premises Mitigation Tool (v2). This tool can be used to implement the URL Rewrite rule needed to mitigate CVE-2022-41040. This can be useful for organizations where the Exchange servers are not leveraging EEMS.
3. Exchange Servers which use EEMS will receive an update to mitigate CVE-2022-41040. The update will add the needed URL Rewrite rule to IIS. To inspect this rule, have a look the XML published for EEMS updates, i.e. https://officeclient.microsoft.com/getexchangemitigations:
   <RewriteConfiguration> <type>Web</type> <path>IIS:/sites/Default Web Site</path> <section>system.webServer/rewrite/rules</section> <rules> <rule name="EEMS M1.1 PowerShell - inbound" stopProcessing="true"> <match url=".*" /> <conditions> <add input="{REQUEST_URI}" pattern=".*autodiscover\.json.*\@.*Powershell.*" /> </conditions> <action type="AbortRequest" /> </rule> </rules> </RewriteConfiguration>

To check if your server is configured correctly using EEMS, execute the following commands in Exchange PowerShell:

Get-OrganizationConfig | select MitigationsEnabled

It should return a value of true.

And to check if the mitigation service is actually running and if the endpoint is accessible, you can run the following two commands:

CD $Exscripts
.\Test-MitigationServiceConnectivity.ps1

This should return a successful result and that the Microsoft endpoint is accessible.

So how do you know the mitigation is successfully applied to your Exchange server? In Exchange PowerShell, execute the following command and check the results. It should return this:

[PS] C:\>Get-ExchangeServer -Identity EXCH01 | Format-List Name,MitigationsApplied
Name : EXCH01
MitigationsApplied : {M1.1, PING1}
[PS] C:\>

The mitigation M1.1 is the same as mentioned in bullet number 3 earlier in this blog. Are you still not convinced, then you check IIS Manager, navigate to Default Web Site and select URL Rewrite. You should see something like the following screenshot:

Instead of blocking the malicous URLs on the Exchange server, it is also possible to block them on your load balancer or application delivery controller. For example, the following vendors published articles on how to block CVE-202241040 using their products:

• https://support.kemptechnologies.com/hc/en-us/articles/9548819650701
• https://support.f5.com/csp/article/K54470807
• https://success.trendmicro.com/dcx/s/solution/000291651

Detection

To check if your Exchange server might be compromised, you have a few options.

First, you can use the tool GTSC published on GitHub here. In the same publication as the discovery, they also state what Indicators of Compromise to look for. This is however 3rd party executable, so organizations should decide for themselves if they want to use this tool or not.

Second, you could manually inspect the IIS log files on your Exchange servers, and look for the requests containing autodiscover/PowerShell in their URI, e.g.

Get-ChildItem -Recurse -Path <Path_IIS_Logs> -Filter '*.log' | Select-String -Pattern 'powershell.*autodiscover\\.json.*\\@.*200'

If it shows up any successful requests (hence the 200), you should investigate further. Note that crawling IIS log files.

Organizations running Microsoft Defender Antivirus or Microsoft Defender for Endpoint on their Exchange servers should know that the backdoor and activities related to this vulnerability are detected, provided they have been configured correctly to receive updates and for example EDR is in block mode; see the Mitigation section in the Security blog.

(Update on October 3, 2022): The (original) filter to mitigate the situation, specified by the GTSC as well as various websites, is too specific. The filter can easily be circumvented by variations - but effectively identical – of the manufactured request. This also applies to the URL Rewrite Rule that is currently being pushed through the Exchange Emergency Mitigation Service (EEMS). A more broad rule to filter requests is:

*.autodiscover\.json.*Powershell.*

(Update on October 4, 2022): Microsoft has updated the filter expressions mentioned throughout their articles with the more broad expression listed above. The IIS URL Rewrite Rules published through EEMS also received an update (EOCS 1.0.7), correcting the situation (not the @ omission in the detection pattern):

<Action type="UrlRewrite" id="1" scope="Server" desc="Mitigation of CVE-2022-41040 via a URL Rewrite configuration.">
<Value>
<RewriteConfiguration> <type>Web</type> <path>IIS:/sites/Default Web Site</path> <section>system.webServer/rewrite/rules</section> <rules> <rule name="EEMS M1.1 PowerShell - inbound" stopProcessing="true"> <match url=".*" /> <conditions> <add input="{REQUEST_URI}" pattern=".*autodiscover\.json.*Powershell.*" /> </conditions> <action type="AbortRequest" /> </rule> </rules> </RewriteConfiguration>
</Value>
</Action>

Microsoft also updated their advisory, and is now also recommending organizations to disable Remote PowerShell for non-administrator roles (instructions here). Sample queries were also added to the Security blog which can be used to hunt for indicators of compromise.

(Update on October 5th, 2022): The filter when specified works against the pre-URL decoded request, meaning that it is ineffective when specifying the URL using URL encoded characters. For example, you can use %20 for spaces or %61 for 'a'. Solution is to explicitly state that you want to filter against the URL decoded URI by changing the condition input to {UrlDecode:{REQUEST_URI}}. The latest updates for EEMS will also configure this rule on your Exchange servers.

At the time of writing, Microsoft has not publish a security fix yet.

Want to learn more about Exchange Monitoring & Reporting?

With email being one of the most mission-critical tools for organizations today, how do you ensure vital business communication stays up and running? How do you demonstrate to senior management that additional resources are needed to meet growing demand or that service levels are being met?

Developed by Exchange architects with direct product input from Exchange MVPs, ENow's Mailscape makes your job easier by putting everything you need into a single, concise OneLook dashboard, instead of forcing you to use fragmented and complicated tools for monitoring and reporting. Easy to deploy and intuitive to use, get started with Mailscape in minutes rather than days.

ACCESS YOUR FREE 14-DAY TRIAL and combine all key elements for your Exchange monitoring and reporting to keep your messaging infrastructure up and running like a pro!

PRODUCT HIGHLIGHTS

• Consolidated dashboard view of messaging environments health
• Automatically verify external Mail flow, OWA, ActiveSync, Outlook Anywhere
• Mail flow queue monitoring
• DAG configuration and failover monitoring
• Microsoft Security Patch verification
• 200+ built-in, customizable reports, including: Mailbox size, Mail Traffic, Quota, Storage, Distribution Lists, Public Folders, Database size, OWA, Outlook version, permissions, SLA and mobile device reports