Investigate Exchange Server Logs to Detect the HAFNIUM Exploit

4 March 2021 by Liisa Tallinn and Raido Karro

On 2 March 2021, Microsoft detected multiple 0-day exploits (CVE) attacks on on-prem Exchange Servers. Microsoft attributes the campaign with high confidence to HAFNIUM, a group assessed to be state-sponsored and operating out of China. Reportedly, the attackers operate primarily for the purpose of stealing data from US-based infectious disease researchers, law firms, higher-education institutions, defense contractors, policy think tanks, and nongovernmental organizations. The CVEs referencing this incident are the following:

  •  CVE-2021-26855, a server-side request forgery (SSRF) vulnerability that allowed the attackers to send arbitrary HTTP requests and authenticate as the Exchange server.
  •  CVE-2021-26857, an insecure deserialization vulnerability in the Unified Messaging service. Insecure deserialization is when untrusted user-controllable data is deserialized by a program. Exploiting this vulnerability gave Hafnium the ability to run code as SYSTEM on the Exchange server. This requires administrator permission or another vulnerability to exploit.
  •  CVE-2021-26858, a post-authentication arbitrary file write vulnerability. If Hafnium could authenticate with the Exchange server, then it could use this vulnerability to write a file to any path on the server. The group could authenticate by exploiting the CVE-2021-26855 SSRF vulnerability or by compromising a legitimate admin’s credentials.
  • CVE-2021-27065 is a post-authentication arbitrary file write vulnerability in Exchange. If HAFNIUM could authenticate with the Exchange server then they could use this vulnerability to write a file to any path on the server. They could authenticate by exploiting the CVE-2021-26855 SSRF vulnerability or by compromising a legitimate admin’s credentials.

Task One - Patch the Server

If you suspect your organization might be vulnerable to this exploit as you're running an on-prem Exchange server (2010, 2013, 2016, 2019), the first thing to do is patch the server. If unsure about your patch status, run this Nmap script by Kevin Beaumont to check for the CVEs using Outlook Web App path data

Task Two - Check the Logs

To analyze the impact of the incident, run a quick analysis of suspicious activities on your IIS Exchange server logs. A blog post by Volexity and Reddit thread by Huntress are both great sources for indicators of compromise based on what they see happening in their customers' domain. In case you haven’t ingested the logs into a SIEM and need to work directly with the files for a quick post-mortem, we’ve prepared a few analysis scripts for this specific Exchange vulnerability. The queries are based on the publicly shared indicators to help you detect if, how, and when your Exchange server was hit. 

Accessing IIS Exchange Server Logs

  1.  If you’re not running SpectX in the same machine where you’ve stored the IIS logs, create a new datastore to connect SpectX to your IIS logs.
  2.  Download the SpectX query pack from Github, (Code > download zip) and upload it to SpectX (full instructions
  3.  In SpectX resource tree on the left, open the base_query.sx file in the query pack > microsoft_iis > exchange_vuln_march_2021 folder 
  4. In the base_query.sx file, replace URI on line 2 with the one pointing to your log files.  The fastest way to figure out the URI syntax pointing to your logs is to open the Input Data browser in SpectX, navigate to one of your log files and copy the URI from the data browser. 
  5. Save the query with the new URI and click 'Run'. That's it. You can now open and run other queries from the exchange_vuln pack to get some answers.

Queries to Find Indications of Compromise

These are the three basic queries to see if and how you've been affected by the exploit.  The full query pack for this vulnerability is available on Github

1. Any suspicious IPs seen in the logs? 
Check if you have requests from suspicious IPs as reported by Volexity and Huntress.
@[./base_query.sx]
| filter(c_ip IN (103.77.192.219,
        104.140.114.110,
        104.250.191.110,
        108.61.246.56,
        149.28.14.163,
        157.230.221.198,
        167.99.168.251,
        185.250.151.72,
        192.81.208.169,
        203.160.69.66,
        211.56.98.146,
        5.254.43.18,
        80.92.205.81,
        165.232.154.116
        )
)

2. When were unique .aspx files seen first?
This query will list unique .aspx files according to their first-seen date. This will give you a view of the most recent web shells. 
@[./base_query.sx]
| filter(uri_stem LIKE '%.aspx')
| select(first_seen:min(timestamp), uri_stem)
| group(uri_stem)
| sort(first_seen desc)
| select(first_seen_ago:duration(now()-first_seen), *)
Follow up with running the base query again,  adding a filter with the IP from that newly created web shell record. This will allow investigating all activity originating from this IP.
@[./base_query.sx]
| filter(c_ip = 1.2.3.4)
| sort(timestamp desc)

3. As Volexity has observed the attackers using Tor, check if and how your server has been accessed from the TOR network. 
$torPattern = "
('ExitNode ' LD:tor_id EOL
'Published ' TIMESTAMP('yyyy-MM-dd HH:mm:ss'):tor_published EOL
'LastStatus ' TIMESTAMP('yyyy-MM-dd HH:mm:ss'):tor_last_status EOL
)?
'ExitAddress ' IPV4:tor_ip ' ' TIMESTAMP('yyyy-MM-dd HH:mm:ss'):tor_time EOL
";
@tor= PARSE(src:'https://check.torproject.org/exit-addresses', pattern:$torPattern)
| select(tor_ip, tor_time, tor_id);

@[./base_query.sx]
| leftjoin(@tor ON left.c_ip = right.tor_ip)
| filter(tor_ip is not null)
| select(tor_ip, tor_time, tor_id, *)

About SpectX

SpectX is a log analyzer that runs queries directly on log files, no need to move or ingest them anywhere for analysis. Point the queries to your IIS Exchange server and go. 

Last but not Least

For a generic analysis on Exchange user activity, check out our blog post from 2020 on Analyzing IIS logs: Microsoft Exchange, OWA, and ActiveSync Activities

Back to articles