Microsoft has confirmed that two recently reported zero-day vulnerabilities in Microsoft Exchange Server 2013, 2016, and 2019 are being exploited in the wild.
"The first vulnerability, identified as CVE-2022-41040, is a Server-Side Request Forgery (SSRF) vulnerability, while the second, identified as CVE-2022-41082, allows remote code execution (RCE) when PowerShell is accessible to the attacker," Microsoft said.
"At this time, Microsoft is aware of limited targeted attacks using the two vulnerabilities to get into users' systems."
The company added that the CVE-2022-41040 flaw can only be exploited by authenticated attackers. Successful exploitation then allows them to trigger the CVE-2022-41082 RCE vulnerability.
Microsoft says Exchange Online customers don't need to take any action at the moment because the company has detections and mitigation in place to protect customers.
"Microsoft is also monitoring these already deployed detections for malicious activity and will take necessary response actions to protect customers. [..] We are working on an accelerated timeline to release a fix," Microsoft added.
According to Vietnamese cybersecurity outfit GTSC, who first reported the ongoing attacks, the zero-days are chained to deploy China Chopper web shells for persistence and data theft and to move laterally through the victims' networks.
GTSC also suspects that a Chinese threat group might be responsible for the ongoing attacks based on the web shells' code page, a Microsoft character encoding for simplified Chinese.
The threat group also manages the web shells with the Antsword Chinese open-source website admin tool, as revealed by the user agent used to install them on compromised servers.
Mitigation available
Redmond has also confirmed mitigation measures shared yesterday by GTSC, whose security researchers also reported the two flaws to Microsoft privately through the Zero Day Initiative three weeks ago.
"On premises Microsoft Exchange customers should review and apply the following URL Rewrite Instructions and block exposed Remote PowerShell ports," Microsoft added.
"The current mitigation is to add a blocking rule in "IIS Manager -> Default Web Site -> Autodiscover -> URL Rewrite -> Actions" to block the known attack patterns."
To apply the mitigation to vulnerable servers, you will need to go through the following steps:
- Open the IIS Manager.
- Expand the Default Web Site.
- Select Autodiscover.
- In the Feature View, click URL Rewrite.
- In the Actions pane on the right-hand side, click Add Rules.
- Select Request Blocking and click OK.
- Add String “.*autodiscover\.json.*\@.*Powershell.*” (excluding quotes) and click OK.
- Expand the rule and select the rule with the Pattern ".*autodiscover\.json.*\@.*Powershell.*" and click Edit under Conditions.
- Change the condition input from {URL} to {REQUEST_URI}
Since the threat actors can also gain access to PowerShell Remoting on exposed and vulnerable Exchange servers for remote code execution via CVE-2022-41082 exploitation, Microsoft also advises admins to block the following Remote PowerShell ports to hinder the attacks:
- HTTP: 5985
- HTTPS: 5986
GTSC said yesterday that admins who want to check if their Exchange servers have already been compromised could run the following PowerShell command to scan IIS log files for indicators of compromise:
Get-ChildItem -Recurse -Path <Path_IIS_Logs> -Filter "*.log" | Select-String -Pattern 'powershell.*autodiscover\.json.*\@.*200'
Comments
howartp - 1 year ago
Could someone add the default/likely paths for <Path_IIS_Logs> mentioned in the powershell test?
serghei - 1 year ago
From GTSC's report: %SystemDrive%\inetpub\logs\LogFiles folder
FiRem00 - 1 year ago
This will locate your own exact log path for the Default Web Site:
Import-Module -Name WebAdministration
(Get-ItemProperty -Path 'IIS:\Sites\Default Web Site' -Name logfile).directory
Guenter_Born - 1 year ago
Microsoft has now published the above mentioned Techcommunity post with a few hints and mitigations - but there are questions open about the steps and RegEx patterns to mitigate.
https://borncity.com/win/2022/09/30/microsofts-empfehlungen-fr-die-exchange-server-0-day-schwachstelle-zdi-can-18333/
MakoM - 1 year ago
Please, on the picture of rewrite rule is PATTERN only * , but when you follow instruction and use PATTERN .*autodiscover\.json.*\@.*Powershell.* it wil create .*
Which one is good setting? Thnks
Sennva - 1 year ago
Don't forget to change the "Using" option from wildcard to Regular Expression in mitigation step 7.
Per Microsoft's mitigation screenshot here: https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/
glenndm - 1 year ago
@MakoM
The 5th screenshot in the link Sennva posted shows .* as Pattern - so I think that's the correct setting
If this matches, then the secondary pattern .*autodiscover..... is tested.
edit:
on careful comparison, my rule shows Input as "URL path after '/Autodiscover/'" whereas the screenshot show "URL path after '/'" ?
both patterns fired on an extract from the IISlog (see below), so I guess it works either way?
edit2: there is a subtle difference between the mitigation described here and in the link (sennva)
here : the rewrite rule is placed at the default web site autodiscover level
the link places the rewrite rule at the root level
which explain my first edit
I'm not totally sure which is the correct one (I suspect the link from sennva), but I'll leave them both for now.
@Sennva:
Thanks for the using option, I totally missed that one
I recently underwent an attack, now resolved.
The compromise check returned positive hits dated back to november last year, so it's possible this method is older than zero-day.
Last edit for today: this seems similar
https://cyware.com/news/tortilla-gang-abusing-proxyshell-vulnerabilities-to-spread-babuk-87cb0b18/
djust270 - 1 year ago
Here I show how to apply the mitigations with PowerShell https://github.com/djust270/Exchange_Exploit_Resources/blob/main/CVE-2022-41040_CVE-2022-41082_Mitigations.ps1