Exchange Servers Getting Hit through ProxyShell Vulnerabilities
About the ProxyShell Vulnerability
ProxyShell is a massive new exploit campaign that is targeting vulnerable Microsoft Exchange servers. The servers are publicly available and the campaign is directly responsible for a number of breaches and subsequent ransomware attacks.
There have been thousands of compromised Exchange servers to date. Ransomware is simply the byproduct of unauthorized access and privilege escalation and typically has to start with something like ProxyShell providing an attacker remote access.
In this case, major vulnerabilities are exploited in a series, to drop a web-shell that provides remote access to the affected Exchange server. Given that many organizations are forced to implement their Exchange architecture without a true DMZ separation, the successful exploit of these vulnerabilities allows an attacker to have a direct and admin-level jumping point into the rest of the network to perform actions as they see fit. This may include establishing perpetual access via many methods, stealing data, or most commonly – starting a ransomware deployment exercise.
The vulnerabilities and subsequent patches have been out for several months now and must all be exploited in series, but are all relatively easy to perform. Proxyshell itself has fully usable and publicly available versions, hosted in several repositories out on the Internet. This is making it very easy for any attacker to leverage this entire process. All of these are covered in Exchange roll-up patches at this point.
How You Can Stay Vigilant
Monitoring for this activity can be done with various different tools. The simplest form that Sedara has seen in practice and tested is the usage of behavior-based endpoint tools, such as Carbon Black. Sedara has used this method to correctly identify the web-shell activity and block it from all angles.
This doesn’t prevent an attacker from attempting the exploits again, with different parameters, but if you are monitoring your EDR tools in real-time and performing true incident response on alarms of this nature, you should be able to identify and catch this activity rather quickly.
Log Analysis
Arguably just as important, there are a number of behaviors that can be identified by a SIEM or log analysis that may have been an indication of this activity. Exchange IIS Logs will contain references to Autodiscover.json and “Powershell,” which is not common to see at all and is easily watched and alerted on if you are collecting these logs.
Exchange Web Services Logs
Additionally, watching Exchange Web Services logs shows a number of areas that could have indicated an issue. The ‘New-MailboxManagementRoleAssignment’ Powershell cmdlet is not commonly used on a regular basis and was shown giving permissions to mailboxes, in order to carry out one of the exploits and drop an email in a user’s draft folder. Watching for uncommon commands such as this one is a great way to identify behavioral anomalies in any environment or application with a SIEM.
File Integrity Monitoring
File Integrity Monitoring on Exchange servers is another way to easily catch this activity, post exploit. Once the exploit is successful, it drops a web shell with a .aspx file extension in the wwwroot\aspnet_client folder by the SYSTEM user. Adding any new executables or files to these directories is fairly uncommon and not a bad thing to look for on ANY production server. Many EDR tools can help with this process as well, without adding a dedicated FIM product.
Advanced Monitoring
Advanced monitoring with MDR services or any/all of the above tools is a great way to identify and respond to behavioral breaches, but there are always so many unknown additional variables that could lead to an attack being successful or not. In any case, if you aren’t immediately able to apply these patches to your on-prem Exchange, then immediately blocking all port 80 and 443 traffic to your system is the ONLY way to prevent this attack from happening from outside your environment.
Keep in mind, if an attacker has already entered your network from another angle, this attack is still completely plausible from inside the perimeter and is a very easy way for someone to perform privilege escalation. Without any monitoring or remediation tools or processes in place, this type of attack could go completely unnoticed until it is too late.
How Sedara Can Help
Sedara has worked on a number of these incidents in practice and are still seeing unpatched Exchange servers getting hit with this attack. Ransomware is a very common outcome of this attack, but not necessarily the only path an attacker may take once they are able to get inside.
To learn how you can stay protected, contact us today.
Subscribe to Sedara Declassified to get timely updates on new and evolving threats–and what to do about them–just like our clients do.