Microsoft Exchange Control Panel (ECP) Vulnerability CVE-2020-0688 Exploited
March 6, 2020
On February 11, 2020, as part of Patch Tuesday, Microsoft released cumulative updates and a service pack that addressed a remote code execution vulnerability found in Microsoft Exchange 2010, 2013, 2016, and 2019. The vulnerability was discovered by an anonymous security researcher and reported to Microsoft by way of Trend Micro's Zero Day Initiative. Two weeks after the security updates were released, the Zero Day Initiative published a blog post providing more details on the vulnerability. The post made it clear that an attacker could exploit a vulnerable Exchange server if the following three criteria were met:
- The Exchange Server had not been patched since February 11, 2020.
- The Exchange Control Panel (ECP) interface was accessible to the attacker.
- The attacker has a working credential that allows them to access the Exchange Control Panel in order to collect the ViewStateKey from the authenticated session cookie as well as the __VIEWSTATEGENERATOR value from a hidden field within the page source. The credential leveraged by the attacker does not need to be highly privileged or have ECP access.
Shortly after the post was published, Volexity began seeing this vulnerability exploited in the wild by advanced persistent threat (APT) actors. Then on March 4, 2020, Rapid7 released a module that would incorporate this exploit into the Metasploit penetration testing framework.
APT Exploitation
Volexity has observed multiple APT actors exploiting or attempting to exploit on-premise Exchange servers. In some cases the attackers appear to have been waiting for an opportunity to strike with credentials that had otherwise been of no use. Many organizations employ two-factor authentication (2FA) to protect their VPN, e-mail, etc., limiting what an attacker can do with a compromised password. This vulnerability gives attackers the ability to gain access to a significant asset within an organization with a simple user credential or old service account. This issue further underscores why changing passwords periodically is a good best practice, regardless of security measures like 2FA. In recent attacks, Volexity has observed the Exchange ECP vulnerability leveraged to do the following:
- Run system commands to conduct reconnaissance
- Deploy webshell backdoor accessible via OWA
- Execute in-memory post-exploitation frameworks
Volexity has also observed multiple concerted efforts by APT groups to brute-force credentials by leveraging Exchange Web Services (EWS) in an effort to likely exploit this vulnerability. While brute-forcing credentials is a common occurrence, the frequency and intensity of attacks at certain organizations has increased dramatically following the vulnerability disclosure. Volexity believes these efforts to be sourced from known APT groups due to IP address overlap from other attacks and, in some cases, due to the targeting of credentials that would only be known from a previous breach.
Detection
If you have concerns that your Exchange server has been targeted or may be compromised, there are a handful of directories and resources on your Exchange server that can be examined. Use the details below to search for signs of suspicious or malicious activity. Note: Volexity has primarily investigated incidents involving Exchange 2013 and 2016 servers. It is possible certain log files or data may be different on Exchange 2010 or 2019.
Exchange Server Exception Log
When something goes wrong with ECP, a folder named ServerException may get created in the ECP Logging directory. The existence of this folder and files does not necessarily mean the server has been exploited. This is a normal logging directory for when something goes wrong. With that said, Volexity has looked at several Exchange servers where this folder did not exist at all, and some where there were a handful of unrelated files in the directory. Volexity has also found this folder to have several recent files on exploited Exchange servers. These log files were created when the attackers exploited the servers. In order to look for these files, check for the following directory:
\Program Files\Exchange Server\<version number>\Logging\ECP\ServerException
Inside this directory would be files with a naming schema like ECPServerException20200227-1.LOG. Once inside these files you will find an abundance of data that is logged. There are a number of things to look for that will help you figure out if this is related to this exploit. Looking for the following strings may be a good indicator:
The serialized data is invalid.
Exception has been thrown by the target of an invocation.
This log will also capture the source IP of the request, the URL, and the User-Agent. If you take the captured URL and see __VIEWSTATE= , you will want to take that base64 blob and see if you can decode it. If this log is related and malicious, there is a good chance it will decode to the commands the attacker was attempting to execute on the system.
Application Event Log
Volexity has observed exploit activity being captured by Windows Event Logging under the Application Log in the form of an error. The log can be quite detailed and useful depending on what the attacker did and how the payload was encoded. Here are some details about the type of event log you will be searching for:
Log Name: Application
Source: MSExchange Control Panel
Event ID: 4
Level: Error
If you find a relevant event ID, it should be easy to confirm if it is related to attempted exploitation. Quite a bit of data will be captured, which at the start typically includes the username of the account that triggered the exploit followed by the URL, which should look something like this:
https://<exchange URL>/ecp/default.aspx?__VIEWSTATEGENERATOR=<snip>&__VIEWSTATE= <snip>
Pay close attention to that VIEWSTATE URL. It should be an extremely long chunk of base64 text, which when decoded may show you exactly what the attacker was executing on the system.
In the earliest cases that Volexity has investigated, it can clearly be seen that attackers were using ysoserial in order to generate payloads. This is also evident when looking through these event logs.
IIS Logs
By default, Exchange servers should be logging access via a standard IIS log. The default location will be at C:\Inetpub\Logs\LogFiles\W3SVC1\. This path can be changed and more than one site may be used, which would result in additional or alternate W3SVC# directories. All access to /ecp/ should be logged in these files. Simply looking for requests going to /ecp/default.aspx should be enough to narrow down your search. However, looking at all requests with /ecp/ in the path would be advised. Further examination of these logs should show the same __VIEWSTATEGENERATOR and __VIEWSTATE parameters. As described above, the __VIEWSTATE parameter can then be further examined through base64 decoding to look for signs of exploitation. This log should also capture the source IP address and username that was leveraged in the attack.
Web Directories
An attacker can write malicious files and tools in any number of places. However, attackers often like to start with placing a webshell on Exchange servers. Any folder that is accessible over the Internet through a web browser is a potential target. Attackers will often place files or folders associated with Outlook Web Anywhere (OWA) or the default IIS web directory. A few example directory paths to check for webshells are:
\Inetpub\wwwroot\
\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth
\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\Auth
Additional Detection
In addition to the sources listed above, it is worth noting that all the commands run by the attackers after successful exploitation would be spawned under the IIS worker process w3wp.exe on the Exchange server. Monitoring for various processes such as PowerShell.exe, net.exe, net1.exe, cmd.exe, ping.exe, nslookup,exe, certutil.exe, etc., where the parent process is w3wp.exe can be an effective mechanism to detect exploitation.
Mitigation
The most obvious way to address this vulnerability is to apply the security updates made available from Microsoft on February 11, 2020. Another best practice that Volexity has long advised is to place access control list (ACL) restrictions on the ECP virtual directory in IIS and/or via any web application firewall capability. Volexity recommends that the ECP directory not be accessible to anyone that does not specifically need to access it. Ideally, this means disabling access from the Internet and even restricting which IPs within an organization can reach it. It is worth noting that 2FA may prevent the attack from being successful, as the attacker may not be able to acquire the data needed to exploit the vulnerability.
Volexity also strongly recommends that organizations continue to expire passwords and require users to update passwords periodically. Despite various guidance about passwords never needing to be changed, Volexity frequently works cases where old passwords resulted in serious data breaches. This vulnerability underscores such a case where an organization can be locked down, have properly deployed 2FA, and still have an incident due to outdated or weak password. Furthermore, Volexity recommends disabling accounts that are no longer needed or that have not logged in for extended periods of time (e.g., greater than 90 days).
Conclusion
The latest Microsoft Exchange ECP vulnerability has provided attackers with another opportunity to break into organizations where they may previously have been unsuccessful. Staying current with patches is the best defense for an organization. Fortunately, this vulnerability does require a compromised credential to exploit and, as a result, will stave off widespread automated exploitation such as those that often deploy cryptocurrency miners or ransomware. However, more motivated attackers now have a way to compromise a critical piece of the IT infrastructure if it is not updated. If you have not already, apply these security updates immediately and look for signs of compromise.
If you have concerns about a breach, or if you have questions or find something you think may warrant further investigation, reach out to Volexity to see if we can help.