SBN

Security Advisory Regarding ProxyShell

Over the past several months, Microsoft has been having a bit of a bad run with their popular email server platform: Exchange.

Earlier this year, a nation-state group referred to as HAFNIUM was found to be exploiting Exchange servers with a set of high-impact vulnerabilities–an authentication bypass and a remote code execution (RCE). Collectively, these vulnerabilities were referred to as “ProxyLogon“. Recently, a new set of somewhat related but unique vulnerabilities have emerged, referred to as “ProxyShell”.

ProxyShell consists of three different CVEs:

  • 2021-34473 Pre-Auth remote code execution
  • 2021-34523 Post-Auth code execution using Exchange PowerShell Remoting 
  • 2021-31207 Post-Auth code execution and file write

In a nutshell, the patches to ProxyLogon earlier in 2021 were incomplete and lead to an entirely different set of vulnerabilities. One of the key indicators discovered from ProxyShell exploit attempts is web requests to the URL:

https[://]<exchange server>/autodiscover/autodiscover.json

This URL pattern is one of the key components of triggering the first stage of the three exploit chain. If readers are looking for HTTP requests to this URL, be sure that you’re looking for both GET and POST requests. Why? The NMAP NSE script that scans for this vulnerability uses GET requests to and examines the HTTP response code to determine if a target is vulnerable. If the target returns a 302 status response, it’s vulnerable. On the other hand, other proof of concept exploits all seem to use POST requests.

If readers are collecting IIS logs (usually under ms:iis:auto), my recommendation is to look for requests to the URLs:

  • /autodiscover*
  • /autodiscover/autodiscover.json*
  • *autodiscover.json*

Look for any HTTP response codes to these requests that are NOT 400-series (sc_status). Consider analysing the user-agent (cs_user_agent) that sent the request, source IP addresses (src), and/or X-Forwarded-For IP (x_forwarded_for) addresses.

As far as other post-exploitation detection is concerned, the old standby of “Do you have process creation logs?” (e.g., Group Policy Process Creation Auditing — Event ID 4688, Sysmon Event ID 1, etc.) and looking for unusual processes that have w3wp.exe as a parent process is a good place to start hunting for anomalous activity. Specifically, if w3wp.exe is a parent process for powershell.exe, cmd.exe, LOLBAS tools, or an unusually named executable that you’ve never seen before, It’s time to take a closer look. 

Host-based indicators of compromise may include:

  • Newly created files (.aspx) in any of the Microsoft Exchange installation subdirectories (e.g., *inetpub\wwwroot\*, *Program Files\Microsoft\ExchangeServer\V15\FrontEnd\HttpProxy\owa\auth\*)
  • Newly created files and folders under the ProgramData directory
  • Any recent modifications to the file *Windows\System32\inetsrv\Config\applicationHost.config (consider looking at the modification timestamps to see if the file was recently modified)

Huntress Labs has done an excellent job talking about all of the details regarding the vulnerabilities and indicators related to ProxyShell. Their write-up of the situation can be found here. Orange Tsai’s write-up of the vulnerability chain for Pwn2Own is available here.

The post Security Advisory Regarding ProxyShell appeared first on Hurricane Labs.

*** This is a Security Bloggers Network syndicated blog from Hurricane Labs authored by Tony Robinson. Read the original post at: https://hurricanelabs.com/security-advisory/security-advisory-regarding-proxyshell/?utm_source=rss&utm_medium=rss&utm_campaign=security-advisory-regarding-proxyshell