Defense

Introduction

On March 2nd, 2021 at ~6pm GMT Microsoft released an out of band update to all version of exchange from 2010 through to 2019. This was in response to a range of vulnerabilities which had been abused (a 0-day) by a threat actor (coined by MS as HAFNIUM).

For more info from MS please see the following:

https://www.microsoft.com/security/blog/2021/03/02/hafnium-targeting-exchange-servers/

Key CVEs

Key CVES include:

CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065.

What I know

We are now getting reports of other threat actor groups abusing the exploits. It’s been less than week, I would envision exploits being spread criminally NOW and POCs being public within the next week (unless people hold them off) so this is not over yet.

Why this matters?

This chain of vulnerabilities can be abused to achieve remove code execton (RCE) – that’s really BAD!

High Level Kill Chain

Vulnerabilities Abused

  • CVE-2021-26855 – Remote Code Execution flaw, via untrusted connections to the Exchange server on port 443. Does not require user interaction
  • CVE-2021-26857 – Remote Code Execution flaw, via untrusted connections to the Exchange server on port 443
  • CVE-2021-26858 – Remote Code Execution flaw, via untrusted connections to the Exchange server on port 443
  • CVE-2021-27065 – Remote Code Execution flaw, via untrusted connections to the Exchange server on port 443

Recon

It looks like passive recon may have been conducted, I did see some evidence of recon which may have used the favicon hash for identification.

My hunch is recon was conducted using separate infra or passive sources e.g. Shodan, Censys etc.

Initial Access

SSRF

https://www.tenable.com/blog/cve-2021-26855-cve-2021-26857-cve-2021-26858-cve-2021-27065-four-microsoft-exchange-server-zero-day-vulnerabilities

Post Recon the first activity appears to be exploitation of an SSRF

https://www.volexity.com/blog/2021/03/02/active-exploitation-of-microsoft-exchange-zero-day-vulnerabilities/

This allows read access to mailboxes from an unauthenticated position. Please note this to my knowledge only affects Exchange 2013 upwards.

Remote Code Execution

A vulnerability in Set-OabVirtualDirectory leads to RCE. This allows an attacker to drop a shell. The shell may be a stager which when visited would then download a full shell. (there may have been memory/stack capacity limitations which force this staged webshell route)

Post Exploitation

Post exploitation seems to be the usual mimikat, process dumping, lateral movement, data exfil etc.

Context Checklist

Q: Do you use office 365?

Q: If yes, do you use hybrid mode (do you have an exchange server/s on premises still)?

R: If no, you can go back to worrying about all the other threats you face! If you are in hybrid mode or have on-premises exchange let’s look at that scenario:

Q: Do you have Exchange 2010?

R: If yes, ok so we don’t believe the kill chain being used works on Exchange 2010, we do however know this, some of the vulnerabilities do exist, there are patches available, we recommend that you mitigate the risk, patch, and then review your exchange environment to make sure that it is in a known good state (there may be other nasties you don’t know about. Once that’s done go and review why you are running an unsupported critical business application and work out how you migrate from it.

R: if no, great, you are running a version that is at least in the support bracket. Now we need to do a few things.

Exchange 2013 and Greater

This is for if you haven’t done anything in response to this yes.

  • Review if you can isolate connectivity to port 443 (and do so if it’s safe to do so – there would be an availability impact, so this is optional etc.)
  • Review patch levels
    • Ensure you are on the latest or at least supported CU version e.g., Exchange 2016 must be on CU18 or CU19
  • Deploy patches, you MUST run these with ADMIN rights from an ELEVATED process or OWA/ECP will break (I did this and manually fixed things before realising I had deployed with a medium integrity process rather than high (oops)
  • Review the server for Indicators of Compromise (IOCs) and investigate if any are found. You may need to kick off a formal incident response (and may need external support)
    • I think people are going to struggle with IOCs and here is why:
      • If you have detect a webshell your system is probably F****D, you then need to check if your whole domain is compromised. This in itself may not be easy to determine (or quick).
      • If you don’t find a webshell but you have entries in your logs with “python” user agents, that have references to “x.js” or “y.js” (or another random named .js) you may have mad data compromise.
    • I’m working with some industry people etc. to see if we can do something in this space. I don’t have a pwn3d system and do not currently have the full kill chain available so I can’t show what the IIS and Exchange (and OS etc.) logs should look like.
    • Understanding the logs is not easy (i’m struggling, I don’t live in the exchange logs. I’m hoping we can get some more guidance from Microsoft on what we should see in IIS logs, HTTP proxy logs etc.)
  • There is a new updated tool called EMOT from Microsoft. I don’t believe it removes all the analysis complexity but it will put in a URL re-rewrite rule, run the saftey scanner and remove known bad foo.

IOC Checking Scripts

I’m listing these in order that I would run these (you might wonder why mine is lower down, that’s because mine is less user friendly and requires path mods for some environments etc.)

https://github.com/microsoft/CSS-Exchange/tree/main/Security

https://github.com/cert-lv/exchange_webshell_detection

I’ve knocked up a quick RCE checker here:

https://github.com/PwnDefend/Exchange-RCE-Detect-Hafnium

if RCE is achived the OAB VirtualAddress object datechanged property should be modified which would give you an idea something has triggered that function.

Then we have my two really rapidly produced scripts:

https://github.com/mr-r3b00t/ExchangeMarch2021IOCHunt

https://github.com/PwnDefend/Exchange2010_IOC_Hunt

ESET

You can check for malware with ESET

https://docs.microsoft.com/en-us/windows/security/threat-protection/intelligence/safety-scanner-download

Hashes and Baselines

[UPDATE] – Microsoft have hashed all the exchange files and have got a repo here: https://github.com/microsoft/CSS-Exchange/tree/main/Security/Baselines

Exchange 2010 Installed Baselines (LAB single VM all roles):

https://github.com/PwnDefend/Exchange2010_hashes

I used the NIRSOFT tool for this:

Community Bad IP List

I’ve put together a community bad IP list taking IP data from CTI, IRL servers and honeypot data:

https://github.com/PwnDefend/badExchangePews

Please contribute if you can!

Exchange Updates

https://github.com/nccgroup/Cyber-Defence/tree/master/Intelligence/Exchange

These were hashed using the following script:

https://gist.github.com/olliencc/4225cedcc49db5c70b4c1c7a9be88bbb

Validation

If you need to validate the integrity of your deployment you should take a baseline view of all the files on your systems (you may just focus on the application e.g., Exchange and IIS)

Generate a list of all the files and create hashes of these. Compare the file list to the baselines and compare the hashes. Investigate anomalies (some anomalies will be normal; some may be threat actor activity)

Stabilization

Once you are stable, patched, are in a known good position here are some things to think about:

Monitoring

Make sure you have monitoring and auditing on key activity and critical areas e.g., monitor file web shell/file creations, monitor for bad activity e.g., brute force, cred stuffing etc.

Look to ensure logging includes:

  • Security Logging
  • Process Logging
  • Network Traffic Logging (e.g., host-based firewall and network-based firewalls)
  • IPS/IDS Logs

Patching

Ensure you have a robust and routing patch management process

Backup

Make sure your systems are backed up and that these backups are secure from ransomware or other threat actor attacks.

Configuration

Make sure your configuration is hardened and in alignment with good practises.

AV & EDR

It’s a good idea to check your exclusion paths, either way make sure you have the right tools in place, and make sure they are effective.

Check the Guidance from MS on exlusions but also recogise the impact of exclusions on your posture.

https://docs.microsoft.com/en-us/exchange/antispam-and-antimalware/windows-antivirus-software?view=exchserver-2019

Further reading

Operation Exchange Marauder: Active Exploitation of Multiple Zero-Day Microsoft Exchange Vulnerabilities

General Cyber Security

There are a huge range of areas to cover such as identity and access management, segmentation, data encryption, backups, patch management, vulnerability management, penetration testing etc. etc. These kinds of events show that having the right investments mean that you can identify, protect, detect, respond, and recover really effectively so even a 0-day shouldn’t ruin your month. It does however require hard work to get there, but the work pays off.

Events like this as fast paced and always evolving, I’ll keep updating content where I can. Whilst these things are horrible for organisations and people, I do love how the cyber community pulls together in these scenarios (everyone just chips in, no one cares which company name you work under we just get together to help ppl!). There are so many people working on all areas of this so thanks to everyone in the community!

Be safe, be secure and may the force be with you!

mR3b00t

Related articles

Leave a Reply

Copyright (c) Xservus Limited