Exchange and ProxyShell: News from Microsoft and security experts

Sicherheit (Pexels, allgemeine Nutzung)[German]I have reported several times on attacks on unpatched on-premises Exchange servers using the ProxyShell method in the blog. Now Microsoft has commented on this in an article and indicates which systems are at risk. In addition, I have received further information from HurricaneLabs, which administrators should be on the lookout for with regard to an infection. Therefore, a summary of the state of affairs once again. 


Attacks via ProxyShell vulnerability

Taiwanese security researcher Orange Tsai of the DEVCORE team gave a presentation on Exchange vulnerabilities at BlackHat 2021 in early August (see my blog post Exchange vulnerabilities: Will we see Hafnium II?). In it, he showed how by combining old vulnerabilities (e.g., CVE-2021-34473, CVE-2021-34523, and CVE-2021-31207) that were closed by updates in April 2021, Microsoft Exchange servers can be attacked and taken over via exploits called ProxyLogon, ProxyOracle, and ProxyShell. .

The recommendation was to bring on-premises Exchange servers up to the latest patch level and ensure that they are not accessible via the Internet (see also Exchange Server: Update on ProxyShell vulnerabilities). Already in the blog postExchange ProxyLogon News: Patch status, new PoC and new findings (03/18/2021) I had then pointed out incipient attacks. The latest state of affairs is that before last weekend, almost 2,000 Exchange servers were successfully attacked (see Wave of attacks, almost 2,000 Exchange servers hacked via ProxyShell). Microsoft's antivirus tools can detect some malware. However, in the blog post ProxyShell, ProxyLogon and Microsoft's contradictious Exchange doc for virus scan exceptions, I had pointed out that Microsoft's recommendations exempt many Exchange folders from scanning.

Microsoft comments on ProxyShell

Microsoft has not commented on the above issue for a long time. Security researcher Kevin Beaumont has taken this up in a series of tweets.

The problem seems to be that a number of Exchange Servers are listed as vulnerable by search engines, even though they are not vulnerable via ProxyShell. Here it is good that Microsoft makes a clear statement in the Techcommunity article ProxyShell vulnerabilities and your Exchange Server.


  • Those who have the May 2021 or July 2021 security updates installed on their Exchange servers are protected from these vulnerabilities.
  • Exchange Online customers are also protected (but must ensure that all hybrid Exchange servers have been updated).

Exchange servers that meet any of the following criteria, however, are at risk and may already be infected.

  • The server is running an older, unsupported CU;
  • The server is running security updates for older, unsupported versions of Exchange released in March 2021;
  • or: the server is running an older, unsupported CU to which the March 2021 EOMT mitigations  fixes have been applied.

Microsoft states that in all of the above scenarios, one of the latest supported CUs and all applicable SUs must be installed to be protected. Any Exchange servers that do not have a supported CU and the latest available SU are vulnerable to ProxyShell and other attacks that exploit older vulnerabilities. However, anyone who finds that they need to patch now is only halfway there after the update installation – the Exchange server may long ago have a backdoor in the form of a WebShell.

I already mentioned it here on the blog – and this article brings it up again. The LockFile ransomware already targets the ProxyShell vulnerability in Microsoft Exchange servers. And the attackers are using the PetitPotam vulnerability in Windows to launch attacks. 

And I just became aware of another Exchange vulnerability via this tweet. At Pwn2Own 2021 in Vancouver, someone is reporting a new Microsoft Exchange Server remote code execution vulnerability. However, this one requires a man-in-the-middle attack to take effect. 

Finding compromised Exchange servers

There's also a security advisory from HurricaneLabs about the ProxyShell vulnerability, which came to my attention via the following tweet.  I found the article interesting because the authors specifically state what administrators can look for to detect signs of Exchange server compromise. Perhaps helpful to an administrator or two.

Detect ProxyShell infections on Exchange Servers

Florian Roth points out in this tweet that he has published new YARA rules for detecting attacks. 

Similar articles
Exchange server 0-day exploits are actively exploited
Important notes from Microsoft regarding the Exchange server security update (March 2021)
Exchange isues with ECP/OWA search after installing security update (March 2021)
Exchange Hack News – Test tools from Microsoft and others
Microsoft MSERT helps to scan Exchange Servers
Cyber attack on Exchange server of the European Banking Authority
Exchange hack: new patches and new findings
Exchange Server: Remote Code Execution Vulnerability CVE-2020-16875
Exchange hack: new victims, new patches, new attacks
Update on ProxyLogon hafnium exchange issue (March 12, 2021)
Was there a leak at Microsoft in the Exchange mass hack?
ProxyLogon hack: Administrator's Repository for affected Exchange systems
Microsoft Exchange (On-Premises) one-click Mitigation Tool (EOMT) released
Security update for Exchange Server 2013 SP1; CUs for Exchange 2019 and 2016 (03/16/2021)
Exchange ProxyLogon News: Patch status, new PoC and new findings (03/18/2021)
Exchange vulnerabilities: Will we see Hafnium II?
Exchange Server: Update on ProxyShell vulnerabilities
Attacks on Exchange Server via ProxyShell vulnerability (8/13/2021)
Exchange ProxyLogon News: Patch status, new PoC and new findings (03/18/2021)
Wave of attacks, almost 2,000 Exchange servers hacked via ProxyShell
ProxyShell, ProxyLogon and Microsoft's contradictious Exchange doc for virus scan exceptions

Cookies helps to fund this blog: Cookie settings

This entry was posted in Security and tagged , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *