Skip to main content

Security researchers from GTSC Network Security firm have found a new zero-day vulnerability in Microsoft Exchange Server 2013/2016/2019, which is exploited in the wild. According to the GTSC report, at the beginning of August 2022, they discovered a critical infrastructure was being attacked, specifically their Microsoft Exchange application. On investigating the incident, they found that the attack utilized an unpublished Exchange security vulnerability, i.e., a 0-day vulnerability on Microsoft Exchange Server. The researcher noted that the vulnerability turns out to be so critical that it allows the attacker to execute code remotely (RCE) on the compromised system.

While providing SOC service to a customer, GTSC blue team detected exploit requests in IIS logs with the same format as ProxyShell vulnerability:

autodiscover/autodiscover.json?@evil.com/<Exchange-backend-endpoint>&Email=autodiscover/autodiscover.json%3f@evil.com

Checking other logs, they saw that the attacker can execute commands on the attacked system. The version number of these Exchange servers showed that the latest update had already installed, so an exploitation using Proxyshell vulnerability was impossible.

The GTSC blue team analysts can confirm that it was a new 0-day RCE vulnerability. This information was sent to the GTSC red team members, and conducted research to answer these questions:

  • Why were the exploit requests similar to those of ProxyShell bug?
  • How is the RCE implemented?

GTSC red team successfully figured out how to use the above path to access a component in the Exchange backend and perform RCE. However at this time, they would like NOT to release technical details of the vulnerability yet.

Note: These vulnerabilities affect Microsoft Exchange Server. Exchange Online is not affected.

Upcoming advisories

Checking the Zero Day Initiative upcoming advisories shows two vulnerabilities from GTSC Team.

0-day vulnerability Microsoft Exchange upcoming advisories

Temporary mitigation

GTSC’s direct incident response process recorded more than 1 organization being the victims of an attack campaign exploiting this 0-day vulnerability. In addition, they are also concerned that there may be many other organizations that have been exploited but have not been discovered.

While waiting for the official patch from Microsoft, GTSC provides a temporary remedy to reduce the vulnerability of attacks by adding a rule to block requests with indicators of attack through the URL Rewrite Rule module on IIS server and disabling remote PowerShell for non-admins.

Follow the below steps to mitigate both CVEs:

Important: It is strongly recommended all organizations/enterprises that are using Microsoft Exchange Server to check, review, and apply the below temporary remedy as soon as possible to avoid potential serious damages.

Mitigate CVE-2022-41040

Go through the below steps to block known attack patterns on the Exchange Server and mitigate CVE-2022-41040.

Option 1: Block known attack patterns (manual)

Step 1. Start IIS Manager. Click on Default Web Site and double-click on URL Rewrite.

If URL Rewrite is unavailable, it means that it’s not installed on the Exchange Server 2013/2016/2019, and you need to install IIS URL Rewrite module.

Note: There is no known impact on Exchange functionality if the URL Rewrite module is installed as recommended.

Note: The IIS URL Rewrite Module is required with Exchange Server 2016 CU22 and Exchange Server 2019 CU11 or later. It’s recommended to keep the Exchange Server up to date with the latest Exchange Server Cumulative Update and Exchange Server Security Update.

Suppose you have Exchange Server 2013 running, install the module (IIS will restart, and Outlook clients will lose connection to Exchange Server).

0-day vulnerability Microsoft Exchange IIS 1

Step 2. In the Actions pane on the right-hand side, click Add Rules.

0-day vulnerability Microsoft Exchange IIS 2

Step 3. Select Request Blocking and click OK.

0-day vulnerability Microsoft Exchange IIS 3

Step 4. Ensure URL Path is selected, add the below string, choose Regular Expressions, choose Abort Request, and click OK.

(?=.*autodiscover)(?=.*powershell)
0-day vulnerability Microsoft Exchange IIS 4

Step 5. Expand the rule and select the rule with the pattern you created in the previous step. Click Edit.

0-day vulnerability Microsoft Exchange IIS 5

Step 6. Change the condition input from {URL} to {UrlDecode:{REQUEST_URI}} and click OK.

0-day vulnerability Microsoft Exchange IIS 6

Option 2: Block known attack patterns (script)

What if you want to speed up the process because you have multiple Exchange Servers running?

Download EOMTv2.ps1 PowerShell script and place it in the C:\scripts\ folder.

Start Windows PowerShell as administrator and run the script.

C:\scripts\EOMTv2.ps1

Note: Run the script on every Exchange Server.

The output shows that the migration completes on the Exchange Server.

VERBOSE: Checking if EOMTv2 is up to date with https://aka.ms/EOMTv2-VersionsUri
VERBOSE: Starting EOMTv2.ps1 version 22.10.07.2029 on EX01-2019
VERBOSE: EOMTv2 precheck complete on EX01-2019
VERBOSE: Applying mitigation on EX01-2019
VERBOSE: Starting mitigation process on EX01-2019
VERBOSE: IIS URL Rewrite Module is already installed on EX01-2019
VERBOSE: Applying URL Rewrite configuration to EX01-2019 :: Default Web Site
VERBOSE: Mitigation complete on EX01-2019 :: Default Web Site
VERBOSE: EOMTv2.ps1 complete on EX01-2019, please review EOMTv2 logs at
C:\Users\ADMINI~1.EXO\AppData\Local\Temp\2\EOMTv2\EOMTv2.log and the summary file at C:\EOMTv2Summary.txt

This is how it looks in IIS after the EOMTv2.ps1 PowerShell script completes.

0-day vulnerability Microsoft Exchange IIS EOMTv2

Option 3: Block known attack patterns (EEMS)

For customers who have the Exchange Emergency Mitigation Service (EEMS) enabled, Microsoft released the URL Rewrite mitigation for Exchange Server 2016 and Exchange Server 2019. The mitigation will be enabled automatically.

0-day vulnerability Microsoft Exchange IIS EMS

Mitigate CVE-2022-41082

Go through the below steps to  disable remote PowerShell for non-admins/service accounts and mitigate CVE-2022-41082.

Option 1: Disable remote PowerShell for non-admins

Step 1. Run Exchange Management Shell as administrator.

Step 2. Disable Remote PowerShell for all users.

Get-User -ResultSize Unlimited -Filter 'RemotePowerShellEnabled -eq $true' | Set-User -RemotePowerShellEnabled $false

Step 3. Verify that Remote PowerShell is disabled for all users.

Get-User -ResultSize Unlimited -Filter 'RemotePowerShellEnabled -eq $true' | ft Name,UserPrincipalName

Step 4. Enable Remote PowerShell for the user(s) that needs it. This is most likely the administrator accounts and service accounts.

Set-User -Identity "userprincipalname" -RemotePowerShellEnabled $true

What if you get locked out and can’t connect with Exchange Management Shell?

Suppose you forget to enable Remote PowerShell for the admin account and Exchange Management Shell does not connect to the Exchange Server anymore, follow the below steps:

Step 1. Close Exchange Management Shell

Step 2. Run PowerShell as administrator (note that this is PowerShell and not Exchange Management Shell):

Step 3. Add the Exchange Management PowerShell Snap-In:

Add-PSSnapIn Microsoft.Exchange.Management.PowerShell.Snapin

Step 4. Enable Remote PowerShell for the admin account:

Set-User -Identity "userprincipalname" -RemotePowerShellEnabled $true

Step 5. Start Exchange Management Shell, and everything works as you expect.

Option 2: Disable remote PowerShell for non-admins (script)

This is the recommended approach because new users you create will have Remote PowerShell enabled. Running the below PowerShell script as a scheduled task every night or every couple of hours will ensure that explicitly the user accounts in the defined security group has Remote PowerShell access, and all other user accounts are disabled for Remote PowerShell.

Step 1. Start Active Directory Users and Computers.

Step 2. Create a security group with the name AllowRemotePS.

0-day vulnerability Microsoft Exchange Remote PowerShell 1

Step 3. Open the AllowRemotePS group, click on the General tab and fill in the description CVE-2022-41082.

0-day vulnerability Microsoft Exchange Remote PowerShell 2

Step 4. Click on the Members tab and add the administrators/service accounts that need remote PowerShell access. Click OK.

0-day vulnerability Microsoft Exchange Remote PowerShell 3

Step 5. Download and place DisableRemotePS.ps1 PowerShell script in C:\scripts\ folder.

Ensure the file is unblocked to prevent errors when running the script. Read more in the article Not digitally signed error when running PowerShell script.

Another option is to copy and paste the below code into Notepad. Give it the name DisableRemotePS.ps1 and place it in the C:\scripts\ folder.

# Load Exchange Management Shell PowerShell Snap-In
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

# Allow Remote PowerShell Group
$AllowRPSGroup = "AllowRemotePS"

# Get all users with enabled Remote PowerShell
$AllUsers = Get-User -ResultSize Unlimited -Filter 'RemotePowerShellEnabled -eq $true' | select SamAccountName, RemotePowerShellEnabled

# Get all users from AllowRPSGroup
$AllowUsers = Get-ADGroupMember $AllowRPSGroup -Recursive | ForEach-Object { Get-User -Identity $_.SamAccountName | select SamAccountName, RemotePowerShellEnabled }

# Enable Remote PowerShell for allowed users
foreach ($AllowUser in $AllowUsers) {
    if ($AllowUser.RemotePowerShellEnabled -eq $false) {
        Set-User $AllowUser.SamAccountName -RemotePowerShellEnabled $true
    }
}

# Disable Remote PowerShell for all users
foreach ($User in $AllUsers) {
    if ($AllowUsers.SamAccountName -notcontains $User.SamAccountName) {
        Set-User $User.SamAccountName -RemotePowerShellEnabled $false
    }
}

Step 6. Run Exchange Management Shell as administrator and run the script.

C:\scripts\DisableRemotePS.ps1

Step 7. Verify that Remote PowerShell is enabled for the AllowRemotePS security group users.

Get-User -ResultSize Unlimited -Filter 'RemotePowerShellEnabled -eq $true' | ft Name,UserPrincipalName

Step 8. Create a scheduled task so the script will run every night or every couple of hours.

Note: You should keep this script running as a scheduled task in the future because this makes the attack surfer smaller.

Verify mitigation

It’s always good to verify that you applied the mitigation successfully.

Open a web browser and insert the adjusted autodiscover URL.

https://mail.domain.com/Autodiscover/autodiscover.json@PowerShell

This is how it looks before the mitigation (which is BAD):

0-day vulnerability Microsoft Exchange bad

This is how it looks after mitigation (which is GOOD):

0-day vulnerability Microsoft Exchange good

Verify with PowerShell and run the below command:

Invoke-WebRequest https://mail.domain.com/Autodiscover/autodiscover.json@PowerShell

It should reply with The underlying connection was closed: An unexpected error occurred on a receive.

Invoke-WebRequest : The underlying connection was closed: An unexpected error occurred on a receive.
At line:1 char:1
+ Invoke-WebRequest https://mail.domain.com/Autodiscover/autodiscover.js ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

Detection

To help organizations check if their Exchange Servers have been exploited by this bug yet, GTSC released guidelines and a tool to scan IIS log files.

Method 1: Use PowerShell command:

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

In our example, the IIS logs are in the path C:\inetpub\logs\LogFiles\ and the PowerShell command will look like this:

Get-ChildItem -Recurse -Path "C:\inetpub\logs\LogFiles\" -Filter "*.log" | Select-String -Pattern 'powershell.*autodiscover\.json.*\@.*200'

Method 2: Use the tool developed by GTSC.

Based on the exploit signature, GTSC developed a tool to automate the task rather than search with a much shorter time needed than using Powershell.

0-day vulnerability Microsoft Exchange tool

Conclusion

Mitigate the Exchange Servers NOW. You must apply both mitigations, blocking known attack patterns (CVE-2022-41040) and disabling remote PowerShell for non-admins (CVE-2022-41082).

CVE-2022-41040: Only keep one mitigation rule active in IIS, and don’t use multiple rules. After that, verify that the mitigation is successfully applied. As last, detect if your Exchange Servers are exploited.

CVE-2022-41082: Disable remote PowerShell for all users first. After that, enable remote PowerShell for the administrators/service accounts that need it.

Wait for Microsoft to release a patch (they are working on it).

Suppose you have all the mailboxes in Microsoft 365/Office 365, then you should change the  autodiscover URL to Exchange Online. After that, remove the Exchange Server firewall ports, so the Exchange Server is not published to the internet.

Further information

Latest updates

Update 1: Nothing yet from Microsoft. I will keep the article up to date with the latest changes.

Update 2: Microsoft is investigating two reported zero-day vulnerabilities affecting Microsoft Exchange Server 2013, 2016, and 2019. Microsoft has confirmed that the URL Rewrite instructions and blocking the ports used for Remote PowerShell (shown in this article) successfully break current attack chains.

Update 3: Updated the IIS mitigation steps with an easier walk-through.

Update 4: Microsoft is working on a fix/patch.

Update 5: Added information that you need to install the IIS URL rewrite module (this should be installed if you have an up-to-date Exchange Server 2016/2019). But, if you have Exchange Server 2013, you need to install it if it’s not yet available on the system before you can apply the mitigation.

Update 6: Added a walk-through about how to block PowerShell Remoting on the Exchange Server.

Update 7: Use “Regular Expressions” instead of “Wildcards” when creating the rule in IIS.

Update 8: Changed the request blocking rule (how to block) from Send an HTTP 403 (Forbidden) Response to Abort Request.

Update 9: Adjusted manual mitigation to apply on Default Web Site instead of Default Web Site/Autodiscover directory only, automated mitigation with official Microsoft script, and added EEMS mitigation.

Update 10: The URL pattern to detect/prevent the Exchange 0-day provided by MSRC (Microsoft Security Response Center) and GTSC Team can easily be bypassed.

GTSC team provided an update on 03-10-2022: After receiving information from Jang (@testanull), we noticed that the regex used in the Rewrite Rule could be bypassed. The GTSC team updated the new regex in the rule.

Updated the article to the below updated pattern:

.*autodiscover\.json.*Powershell.*

Note: Microsoft didn’t yet update their script with the new pattern. So you have to add it manually (see article) for now. I will update the post once Microsoft adjusts its script as they are working on it.

Update 11: Microsoft updated the EEMS rule, which is automatically applied. The EOMTv2 script has been updated to include the URL Rewrite improvement. Ensure that you have version 22.10.03.1829 or later.

Update 12: While the first URL pattern to detect/prevent the Exchange 0-day was bypassed and fixed, there is now a second one.

Updated the article to the below updated condition input to successfully mitigate the bypass:

{UrlDecode:{REQUEST_URI}}

Update 13: The GTSC team has confirmed that the latest mitigation can be bypassed and said that they updated the value in the condition input field from {REQUEST_URI} to {UrlDecode:{REQUEST_URI}}.

Update 14: Removed the Block PowerShell remoting section from the article. If you did add an inbound rule in the firewall to block ports HTTP: 5985 and HTTPS: 5986, you should remove it as they don’t have anything to do with it.

Update 15: Added a section about how to disable remote PowerShell for non-admins. Perform these steps to mitigate CVE-2022-41082.

Update 16: Microsoft updated the EEMS rule, which is automatically applied. The EOMTv2 script has been updated to include the condition input field improvement. Ensure that you have version 22.10.05.2304 or later.

Update 17: Working on a PS script to make it easier to mitigate CVE-2022-41082.

Update 18: Added a step-by-step instruction on enabling Remote PowerShell for the admin account if you mistakenly disabled it and can’t connect with Exchange Management Shell to Exchange Server.

Update 19: DisableRemotePS.ps1 PowerShell script for CVE-2022-41082 added, including steps. This is the recommended method.

Update 20: Microsoft improved the URL rewrite rules on October 7, 2022.

Updated the article to the below updated pattern:

(?=.*autodiscover)(?=.*powershell)

The EEMS service is receiving new rule automatically. EOMTv2 script has been updated (script auto-updates on Internet connected machines and the updated version is 22.10.07.2029).

Leave a Reply