Top News Exchange Hack: New Microsoft Exchange zero-days are actively exploited for attacks
by Tina Siering
Warning of two new critical IT security vulnerabilities
Attention: on September 29, 2022, GTSC published a blog article about security vulnerabilities with a high risk! It reports a new attack opportunity that exploits two not yet disclosed vulnerabilities (0-Day). In doing so, attackers can perform remote code execution (RCE) on affected Microsoft on-premise Exchange servers.
Our security analysts have also verified anomalies in connection with the new zero-day vulnerabilities during active analysis as part of our managed services. Among other things, the vulnerability occurs in Outlook Web Access (OWA) or in a related component and has not yet been fixed by Microsoft.
Particularly critical:
According to the current knowledge of our analysts, the vulnerabilities turn out to be so critical that they allow the attacker to perform remote code execution (RCE) on the compromised system. There are currently no CVE numbers for these vulnerabilities. However, Advisories with a CVSS of 8.8 and 6.3 have been submitted to the Zero Day Initiative.
Requests used in this exploit chain are similar to those used in attacks targeting the ProxyShell vulnerabilities, however.
Microsoft has not yet released any information about the two vulnerabilities! The exploit works in two phases:
- Requests with a similar format as the ProxyShell vulnerability: autodiscover/autodiscover.json?@evil.com/<Exchange-backend-endpoint>&Email=autodiscover/autodiscover.json%3f@evil.com
- Using the above link to access a component in the backend where the RCE could be implemented.
Until Microsoft releases appropriate security updates to address the two zero-days, GTSC shared a temporary workaround:
In Autodiscover at FrontEnd, select the URL Rewrite tab and then Request Blocking.
- Add the string ".*autodiscover\.json.*\@.*Powershell.*" to the URL path.
- Condition entry: Select {REQUEST_URI}
Our security analysts have reviewed the recommendation of the workaround and come to the conclusion that it is better to restrict the access from external completely to avoid potential serious damage in the current (unresolved situation)!
If your Exchange is not on-premise or the OWA has not been made externally accessible, you are affected by this vulnerability, but there is no risk of compromise.
Our Allgeier secion customers with an active managed service contract for ACD are of course informed about malicious communication on their systems, currently we are actively checking for IoCs.
Recommended action:
- Disconnect affected systems from the Internet
- Deactivate firewall rules
- In the case of virtual machines, a snapshot with working memory should also be created - preferably before disconnecting the network connection. This could be helpful in a later forensic investigation.
- Temporarily disconnect the affected system from the network
- Disconnect virtual network card or physical network cable
- Check affected systems offline for known Indicator of Compromise (IoC).
The safest way is to completely disconnect the system from Internet access (incoming and outgoing) and temporarily disconnect the system from the network in general. While the system is disconnected from the network, the logs of the IIS belonging to the Exchange should be checked for malicious connections. Additionally, the files listed in the known IoCs should be checked.
To help organizations and enterprises check whether Exchange servers have already been exploited, GTSC has published a policy and tool for scanning IIS log files (stored by default in the %SystemDrive%\inetpub\logs\LogFiles folder).
Method 1: Use powershell command:
Get-ChildItem -Recurse -Path <Path_IIS_Logs> -Filter "*.log" | Select-String -Pattern 'powershell.*autodiscover\.json.*\@.*200
Further information: https://gteltsc.vn/blog/warning-new-attack-campaign-utilized-a-new-0day-rce-vulnerability-on-microsoft-exchange-server-12715.html
On this important topic, register today for the "Microsoft Exchange 0-Day" webinar we will be hosting on 10/4/2022 from 2pm to 3pm.
Registration link: https://register.gotowebinar.com/register/7786495483422818576
We'll be posting more updates and information here throughout the day!
Update 30.09.2022 11:51 MESC
Microsoft has confirmed the two vulnerabilities (CVE-2022-41040, CVE-2022-41082).
Microsoft Customer Guidance-Link: https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/
The first vulnerability (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.
Update 01.10.2022 12:30 MESC
Microsoft has provided the mitigation tool "EOMTv2" to fix the current vulnerability CVE-2022-41040.
You can find more information on the following page of the manufacturer:
Update 04.10.2022 15:00 MESC
The recommendation issued by Microsoft to disable PowerShell remote access for users without administrator rights, via
Method 1:
Use powershell command:
Get ChildItem Recurse Path < Path_IIS_Logs > Filter "*.log" | Select String Pattern
powershell autodiscover json .*.*\@.*200
has proven to be inefficient and can be bypassed with little effort. Specifically, the "@" character in Microsoft's URL block appears to be unnecessarily precise and therefore insufficient.
Security researchers at GTSC confirm that (instead of Microsoft's proposed URL block) a less specific alternative is available that should cover a wider range of attacks: .*autodiscover\.json.*Powershell.*
We recommend that you check your settings to this effect and adjust them if necessary.
Source: https://www.bleepingcomputer.com/news/security/microsoft-exchange-server-zero-day-mitigation-can-be-bypassed/
Update 05.10.2022 09:24 MESC
Microsoft has since adjusted the recommended actions and corrected the rule to the proposed version:
.*autodiscover\.json.*Powershell.
In addition, Microsoft's developers have equipped the offered EOMTv2 script for automated rollout of the rewrite rule with the improved rule.
-------------------------------------------------------------------------------------------------------------
The MVSP vulnerability scanner used by Allgeier secion has been detecting and reporting the Exchange exploits since 04.10.2022!
Update 06.10.2022 10:11
Microsoft has again submitted an updated rule. Administrators are advised to remove the previously created rule and insert a new one:
=> String .*autodiscover\.json.*Powershell.* must be recreated for Request-Block rule for Autodiscover.
Updated customer guidance from Microsoft on recommended countermeasures: Select "Regular Expression" option under "Using" and select "Abort Request" for "How to block". Select the newly created rule and click on "Edit" under "Conditions". In the "Condition Input" field, change the string {URL} to {UrlDecode:{REQUEST_URI}}.
Administrators who have activated the Exchange Emergency Mitigation Service (EEMS) have already received the re-updated rule from Microsoft and nothing needs to be done. Without EEMS: Admins can use the adapted EOMTv2 script Vs. 22.10.05.2304 for automated entry or create the rule manually.
In addition, remote PowerShell access should be disabled for non-administrators.
Update 07.10.2022 09:20
Recommendation to check for Proxynotshell
Proxynotshell check via nmap: https://github.com/CronUp/Vulnerabilidades/blob/main/proxynotshell_checker.nse
Update 10.10.2022 09:00 MESC
There are further adjustments from Microsoft to mitigate the vulnerability, the details are in the following article:
Update 09.11.2022 10:27 MESC
As part of November 2022 Patch Tuesday, Microsoft fixed the ProxyNotShell vulnerabilities in security update KB5019758 for Microsoft Exchange Server 2019, 2016 and 2013:
https://support.microsoft.com/en-us/topic/description-of-the-security-update-for-microsoft-exchange-server-2019-2016-and-2013-november-8-2022-kb5019758-2b3b039b-68b9-4f35-9064-6b286f495b1d
Update 21.12.2022 15:00 MESC
Attention: As of 20 December 2022, new evidence exists that it is possible for attackers to bypass Microsoft's published mitigation measures and install malware on target systems.
Ransomware-enabled attackers are using a new exploit chain containing one of the ProxyNotShell vulnerabilities (CVE-2022-41082) to achieve remote code execution on Microsoft Exchange servers. Instead of CVE-2022-41040, an SSRF vulnerability in the Microsoft Exchange Autodiscover endpoint, a new vulnerability CVE-2022-41080 is used to achieve privilege escalation via Outlook Web Access (OWA).
Based on the new reports, it must be assumed that the mitigation measures proposed by Microsoft do not provide sufficient protection. IT security managers should therefore check the installation of the patches published on 8 November 2022 (KB5019758) as soon as possible.
Appendix
Identified Indicators of Compromise (IOCs)
Indicators of Compromise (IoC) are characteristics and data that indicate that a computer system or network has been compromised. These are, for example, unusual network activities, special files, entries in log files or started processes.
The following indicators of compromise are currently known, or have been uncovered by our SOC team as part of their analysis:
IoC list Exchange 0day:
Files:
pxh4HG1v.ashx:
- SHA-256 c838e77afe750d713e67ffeb4ec1b82ee9066cbe21f11181fd34429f70831ec1
RedirSuiteServiceProxy.aspx:
- SHA-256 65a002fe655dc1751add167cf00adf284c080ab2e97cd386881518d3a31d27f5
- SHA-256 b5038f1912e7253c7747d2f0fa5310ee8319288f818392298fd92009926268ca
Xml.ashx:
- SHA-256 c838e77afe750d713e67ffeb4ec1b82ee9066cbe21f11181fd34429f70831ec1
errorEE.aspx:
- SHA-256 be07bd9310d7a487ca2f49bcdaafb9513c0c8f99921fdf79a05eaba25b52d257
Dll.dll:
- SHA-256 074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82
- SHA-256 45c8233236a69a081ee390d4faa253177180b2bd45d8ed08369e07429ffbe0a9
- SHA-256 9ceca98c2b24ee30d64184d9d2470f6f2509ed914dafb87604123057a14c57c0
- SHA-256 29b75f0db3006440651c6342dc3c0672210cfb339141c75e12f6c84d990931c3
- SHA-256 c8c907a67955bcdf07dd11d35f2a23498fb5ffe5c6b5d7f36870cf07da47bff2
180000000.dll:
- SHA-256 76a2f2644cb372f540e179ca2baa110b71de3370bb560aca65dcddbd7da3701e
IPs:
- 137[.]184[.]67[.]33
- 125[.]212[.]220[.]48
- 5[.]180[.]61[.]17
- 47[.]242[.]39[.]92
- 61[.]244[.]94[.]85
- 86[.]48[.]6[.]69
- 86[.]48[.]12[.]64
- 94[.]140[.]8[.]48
- 94[.]140[.]8[.]113
- 103[.]9[.]76[.]208
- 103[.]9[.]76[.]211
- 104[.]244[.]79[.]6
- 112[.]118[.]48[.]186
- 122[.]155[.]174[.]188
- 125[.]212[.]241[.]134
- 185[.]220[.]101[.]182
- 194[.]150[.]167[.]88
- 212[.]119[.]34[.]11
- 13[.]77[.]160[.]181
- 109[.]167[.]197[.]53
- 3[.]238[.]137[.]11
- 3[.]238[.]137[.]12
- 37[.]120[.]153[.]229
- 185[.]65[.]134[.]252
- 49[.]34[.]171[.]65
- 143[.]110[.]251[.]168
- 172[.]104[.]218[.]130
- 213[.]226[.]123[.]154
- 146[.]0[.]75[.]2
- 206[.]188[.]196[.]77
Need help upgrading your IT security for 2022? Contact us!
Related articles
For several days now, there has been a strong accumulation of successful compromises by the "QakBot" malware (also known as "QBot" and "QuackBot") worldwide. We have also already identified successful attacks as part of our ACD monitoring. After infection, criminals can gain access to online banking accounts, leak user data, and reload further malware. As one measure to mitigate the risk, we urgently recommend adjustments to the Group Policy Objects (GPO).
Cybercriminals are true masters at constantly adapting their attack mechanisms to effective IT security measures. New tools and iterative changes to existing malware are used to mercilessly exploit security vulnerabilities. Among the numerous threats, ransomware stands out as one of the biggest. More and more companies have to face extortion Trojans. A completely new threat called LockFile now relies on intermittent encryption. LockFile not only encrypts much faster than previous ransomware, but also bypasses security solutions that work reliably. This article shows why criminals are increasingly relying on intermittent encryption and how companies should react to the new threat.
Read more … New ransomware trend: Why criminals increasingly rely on intermittent encryption
Due to the war in Ukraine, secion provides an assessment of the threat situation for companies and examines the question of whether increased Russian attacks on companies in Germany, Austria and Switzerland can be identified. There is currently no evidence of an acute increase in the threat posed by Russian state actors in Western Europe, but there is increased public awareness of these cyberattacks. In addition, "third-party actors" are creating a new dynamic.