Summary
Our labs team’s ability to recreate a reliable end-to-end exploit underscores the severity of the ProxyLogon vulnerability. Compounding the criticality of this vulnerability, we’ve been able to use the ProxyLogon vulnerability in conjunction with a common Active Directory misconfiguration to achieve organization-wide compromise. The Active Directory and Exchange permission path issue up until now has been largely ignored by companies because the attack chain depended on a vulnerable Exchange server. The new Exchange vulnerability removes that dependency and an attacker can daisy chain these two issues to expand the compromise from a company’s email to the company itself.
While the discussions around attribution and intent are intriguing, the current focus of defensive security professionals should be:
- What is the actual exploit chain?
- How do we prevent the exploit?
- How to detect if we have been compromised?
- What can we do to remediate?
The technical deep dive in how the exploit chain was discovered and how it works can be found in our previous article. The focus here is going to be focused around “What is Next?”.
Exploit Chain
[image id=”2747″ filter=”false”]
The exploit chain for this activity can be remotely executed with no user intervention or prior knowledge of the environment. Once the chain has been completed the attacker will have access to arguably one of the most important assets in the environment and with a clear path to the Domain Controller (DC) and Domain Administrator (DA).
Gather Information
The start of this attack requires the gathering of 3 specific bits of information. The attacker will need the domain, hostname, and administrators SID (Security Identifier) to be used later on in the chain. The domain and hostname are leaked through Remote Procedure Calls (RPCs) that are thoroughly detailed via Microsoft’s open specification initiative. We have not yet publicly disclosed how an attacker can obtain the Administrator SID, but suffice to say the SID is discoverable, we have successfully obtained it via a crafted request to a service behind the SSRF, and we have a fully functioning exploit. Once the attacker has the Administrator SID they can move on to the authentication bypass portion of the attack.
Authenticate Bypass
Once the attacker has a solid lay of the land; the next goal is to execute their code as an administrator. All of the remote code execution vulnerabilities require an authentication bypass, which is accessible via Server-Side Request Forgery (SSRF). This will let them call vulnerable APIs with administrator permissions.
Drop Payload into the OAB Directory
Once an attacker can call vulnerable Exchange APIs, they attempt to establish a foothold and ensure they can come back if needed to or even persist through a reboot. This can be accomplished through an Arbitrary File write vulnerability (CVE-2021-27065) The OAB (Offline Address Book) has virtual directories that act as a housing for the attacker to drop their files. Once the files are up on the exchange server, the attacker can reset the OAB Virtual Directory which will write the newly added files to disk.
Prevention
It has been reported that over 30,000 organizations have been compromised by this vulnerability. The clearest path to prevention of this exploit is to apply the March 2021 Exchange Security Updates. With the exploit actively being used by threat actors in the wild, it is almost impossible to overstate the criticality for applying this patch. That said, there is a mitigation that can break the chain above to buy your organization time to do any necessary testing around the patch before it gets deployed. A deep dive of the mitigation can be found in the article “Microsoft Exchange Server Vulnerabilities Mitigations – updated March 9, 2021” For the exploit chain above the specific migration in question is “The Backend cookie Mitigation”. The script filters out malformed and malicious cookies and prevents the SSRF vulnerability from being taken advantage of.
Detection
There are a metric ton of IoCs out there published by most Security Vendors. The most comprehensive solution is to leverage the “Test-ProxyLogon” script found on Microsoft’s Github page. They are actively updating it, and from our testing, it would detect evidence of all of the ProxyLogon activity we have seen.
[image id=”2746″ filter=”false”]
In our testing the script has been relatively low impact to the server and should not affect the operation capacity of the server. In our testing the Test-Proxy Logong Script found the majority of the ways we executed the exploit chain, and while it is not fool proof it is still one of the better mechanisms to detect any evidence of proxylogon activity.
Remediation
If you have been compromised, please reach out to your security team as they should have the greatest fidelity of your environment and will know best how to move forward with blocking the threat actor and kicking them out of the environment. If there is no security team available our remediation recommendations are as follows:
- Run the Test-ProxyLogon script mentioned above, to start generating a more complete understanding of the scope of the compromise. Make sure to check every exchange server in your environment (internal/external). Check them all.
- Perform Log analysis of the compromised Exchange servers, at this point, it would also be beneficial to audit the Kerberos ticket logs. The goal is to understand what has happened on the exchange server, if there has been any lateral movement, and what the persistence (if any) there is.
- Clean up – There are a few paths that can be taken here. The decision of how to execute a clean-up is not necessarily a straight line and is more of a matrix. There will be comments from a Level of Effort and Confidence of a clean state perspective. At the end of the day doing something is:
- Restoring from a known good backup. You should test the back up and make sure that it is not compromised BEFORE replacing your current server. This would give you a medium level of confidence and be a medium level of effort.
- Cleaning up the server in line. This is the fastest to execute but the mode of least confidence, as this is a fresh attack and more details will always be forthcoming, there does exist the chance that you will miss some accesses the threat actor has dropped.
- Rebuild the exchange server – Depending on your data retention requirements, and how your data stores are set up. This could be relatively easy or impossible to do, over all it would be a high level of effort. However, once accomplished you can be confident that the server is in a good state and has not been compromised.
- Patch and Apply preventative measures, after the clean-up. It is imperative that you prevent the attacker from coming back. Patching should be a #1 priority and an integral part of the cleanup process.
Acknowledgements
Special thanks to the Praetorian Labs team and their amazing write up on the vulnerability. The entire security community as a whole has come together to share information and work to keep defenders ahead of the attackers. This work would not be possible without the whole community.
References
- Reproducing the Microsoft Exchange Proxylogon Exploit Chain: https://www.praetorian.com/blog/reproducing-proxylogon-exploit/
- Multiple Security Updates Released for Exchange Server – updated March 8, 2021: https://msrc-blog.microsoft.com/2021/03/02/multiple-security-updates-released-for-exchange-server/
- Microsoft Exchange Server Vulnerabilities Mitigations – updated March 9, 2021: https://msrc-blog.microsoft.com/2021/03/02/multiple-security-updates-released-for-exchange-server/
