NOTE: Please read the entire article, mitigation steps will not be enough to fully remediate this threat.
[Update: 10/10/2022]: Microsoft has updated mitigation guidance again. Please review the Microsoft mitigations from the link below fully (several steps have been altered) to ensure that you have applied all mitigations correctly.
[Update: 10/6/2022]: Attackers have been able to bypass the original and second set of mitigations provided by Microsoft. Microsoft has updated their guidance to reflect this as additional mitigation changes will need to be implemented. The Microsoft link at the bottom of this article reflects these new mitigation strategies, and is specifically noted in Step 10 of that article.
Additionally, it should be noted that Microsoft is recommending that remote PowerShell be disabled for Exchange servers. Based on the type of attack it is unclear at this time how remote PowerShell is being utilized in this attack chain. As a standard security measure PowerShell remoting should NEVER been enabled for externally facing servers and addresses, and should only be utilized from the internal network.
—–
To be fair, I had a hard time with a title for this post. This vulnerability hasn’t been assigned a really cool name yet, aside from Kevin Beaumont labeling it “ProxyNotShell” but that’s somewhat of a misnomer since there definitely will be a shell upon exploit.
What’s going on?
Yesterday, 9/29, a new Zero-Day was announced regarding Microsoft Exchange servers. This applies to all 2013, 2016, and 2019 Microsoft Exchange Servers, the current maximum CVSS score we’ve observed is 8.8, though that seems a bit low given the potential for damage. Two CVEs have been named in this attack: CVE-2022-41040 and CVE-2022-41082.
This discovery was made by GTSC Cyber Security and is still somewhat under investigation. Let’s at least hit the confirmed points below, and then we’ll discuss some of the fuzzier details, mitigation steps, and why those mitigation steps aren’t going to be enough.
This new vulnerability is exploited in a strikingly similar way to ProxyShell, so much so that the URI in use looks nearly identical to those utilized with ProxyShell, and the attackers appear to be using the ChinaChopper shell in these attacks as well.
An example of the URI utilized: autodiscover/autodiscover.json?@evil.com/<Exchange-backend-endpoint>&Email=autodiscover/autodiscover.json%3f@evil.com.
What can happen?
If you were involved with any ProxyShell attacks, that looks very familiar to you. As with ProxyShell this allows Remote Code Execution (RCE) and generally leads to the attackers placing a webshell (think of it as a command prompt, or PowerShell prompt that can be used remotely by an attacker) that would operate in the same user-context as Microsoft Exchange. In other words, it’s a highly privileged command/PowerShell prompt, likely operating as “System” or another high level account that Microsoft Exchange is utilizing. The possibilities once that shell is dropped are nearly limitless, but some of the scary ones:
- Administrative access to Exchange
- Potential path to Domain Administrator (or greater) level access
- Administrative access to all aspects of the Exchange Server (including mail databases, potentially cached credentials, etc.)
- High potential for lateral movement into the organization’s network
Does this require authentication?
[Update 10/6/2022]: More sources seem to be solidifying the need for authentication to exploit this vulnerability. Though this may be the case, this should not serve as an excuse to delay mitigation of this vulnerability, as any valid credential set would still allow an attacker to proceed with the attack. As noted in the section below, you would have to be 100% confident that you have no compromised user accounts and this is not the reality for many organizations.
—–
As of this writing, it is unclear as to whether this vulnerability can be exploited without having some form of authentication (a working set of user credentials). In the Microsoft article (linked below) it indicates that authentication is required, which is the likely reason for the relatively low CVSS score. Other articles mention honeypots that are being actively exploited, which leads us to believe that authentication may not be required. This type of confusion is not uncommon during the early research of a new vulnerability, but it’s best to assume that authentication is not required and perform the mitigation steps anyway. Even if authentication is required, are you 100% confident that NONE of your user (or service) accounts have been compromised?
Mitigation
Mitigation steps have been provided by Microsoft. These seem fairly straightforward and can be found in this article: https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/
As with ProxyLogon and ProxyShell, the mitigation steps will only prevent (assuming they work this time) NEW attacks. If your Exchange server has already been exploited (it very likely will be as this vulnerability becomes widely known over the next few hours/days) and a shell has been placed, these mitigation steps will not fix that issue. The attackers will still have access to your Exchange server.
What should you do next?
- Perform mitigation steps ASAP
- Assume compromise and initiate an immediate threat hunt in your Exchange environment. Utilizing the log searching methods noted in the articles linked below.
- If you are uncomfortable performing this threat hunt or feel that you need help, reach out to a trusted security partner for help.
- It can not be stressed enough, you must assume that you have likely been breached and threat hunt. Remediation steps will not stop an active attack, they will only prevent a new attack.
Sources:
BleepingComputer: https://www.bleepingcomputer.com/news/security/new-microsoft-exchange-zero-days-actively-exploited-in-attacks/
Kevin Beaumont: https://doublepulsar.com/proxynotshell-the-story-of-the-claimed-zero-day-in-microsoft-exchange-5c63d963a9e9
