Summary
General
On September 29, Microsoft Security Threat Intelligence reported two significant zero-day vulnerabilities being exploited in the wild. The two vulnerabilities, named “ProxyNotShell”, affect Microsoft Exchange Server 2013, Exchange Server 2016, and Exchange Server 2019. The vulnerabilities are denoted as:
- CVE-2022-41040, Server-Side Request Forgery (SSRF), CVSS score of 8.8.
- CVE-2022-41082, Remote Code Execution (RCE), CVSS score of 6.3.
According to Microsoft, the SSRF vulnerability can be exploited by authenticated users, successful exploitation will allow the attacker to trigger the RCE vulnerability when Exchange PowerShell is accessible to the attacker, furthermore, according to Microsoft, there are limited targeted attacks that utilize both vulnerabilities to access users’ systems.
In the Wild Exploitation and Current Attribution
Cyberint Research Team detected over a dozen unique IPs which actively scan the web for the ProxyNotShell. In addition, a PoC for the SSRF and RCE vulnerabilities was publicly available on GitHub and as of now is unavailable. However, Nmap scanners that contain SSRF-like requests to test if a server is vulnerable are developed by blue teams and are still publicly available, threat actors might use those for detection and exploitation purposes.
Researchers observed that attackers dropped web shells into the Exchange servers and presumably being maintained by the Antsword management tool which is freely available on GitHub.
Current attribution is aimed at Chinese APTs for the following reasons:
- The detected web shells contain a codepage parameter of 936, which stands for Microsoft Chinese encoding.
- Various Chinese APTs were detected previously for deploying web shells on Exchange servers to gain a hold on the victims’ server alongside using Chinese-related management tools, which strengthens the connection to the threat actors’ origin.
Recommendations
While no patches are available yet, Microsoft announced that Exchange Online customers don’t need to take any action as Microsoft is detecting and mitigating the current threat.
For on-premises/hybrid Exchange users, current public best-practice mitigations and rule writings instructions are the following:
- Within IIS for the Frontend Autodiscover site, select an option to add a request blocking rule.
- Ensure that the rule will block access based on “URL Path”.
- Add the string “.*autodiscover.json.*@.*Powershell.*” (without quotes).
- Ensure that the rule uses regular expressions.
- For the condition input, select {REQUEST_URI}.
Further elaboration and updates can be found in Microsoft’s blog.
IOCs
Webshells (SHA256)
c838e77afe750d713e67ffeb4ec1b82ee9066cbe21f11181fd34429f70831ec1
65a002fe655dc1751add167cf00adf284c080ab2e97cd386881518d3a31d27f5
b5038f1912e7253c7747d2f0fa5310ee8319288f818392298fd92009926268ca
c838e77afe750d713e67ffeb4ec1b82ee9066cbe21f11181fd34429f70831ec1
be07bd9310d7a487ca2f49bcdaafb9513c0c8f99921fdf79a05eaba25b52d257
DLLs (SHA256)
074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82
45c8233236a69a081ee390d4faa253177180b2bd45d8ed08369e07429ffbe0a9
9ceca98c2b24ee30d64184d9d2470f6f2509ed914dafb87604123057a14c57c0
29b75f0db3006440651c6342dc3c0672210cfb339141c75e12f6c84d990931c3
C8c907a67955bcdf07dd11d35f2a23498fb5ffe5c6b5d7f36870cf07da47bff2
76a2f2644cb372f540e179ca2baa110b71de3370bb560aca65dcddbd7da3701e
IPs:
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
URLs:
hxxp://206[.]188[.]196[.]77:8080/themes.aspx
C2:
137[.]184[.]67[.]33
