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:
Key CVES include:
CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, and CVE-2021-27065.
What I know
- On March 2nd (Tuesday) patches for range of vulnerabilities (0-days) were released to combat active exploitation in the wild.
- Kevin B released an NSE for detection (Tuesday)
- Dan (me) wrote and published a rapid dev IOC detection script (Exchange 2016) March 3rd (Wednesday)
- I ran the script on a customer server and found “Recon Only” Activity on the 26 of February 2021 (UK Destination IP)
- March 6th – I publish baselines of Exchange 2010 to help people “rule out” activity on Exchange 2010 environments. (honestly without known good baselines that’s really quite hard to do)
- March 6th NCC/Ollie publishes file lists and hashes from the update files to help people baseline and detect anomalies
- March 4th – Exchange Team released a script for checking IOCs (2013-2019)
- March 5th CERT LV publishes web shell detection script
- March 6th Official Microsoft NSE released for network-based detection
- March 7th Microsoft release an update to their independent scan tool – https://docs.microsoft.com/en-us/windows/security/threat-protection/intelligence/safety-scanner-download
- PwnDefend Exchange HoneyPot goes online ~ 0900
- March 8th PwnDefend Community IP List released
- This has been generated from sources, MS, Volexity, real life servers, honeypots and IOCs submitted to me.
- March 8th – Microsoft releases patches for earlier CUs
- March 9th – I’ve released a rapid RCE detection script here:
- Obviously don’t just use one indicator but if RCE was used the timestamp on that object gets modified. They can clearly overwrite this was they get system access but they probably didn’t bother.
- March 16 – Microsoft Release the EOMT (Exchange On Premises Mitigation Toolkit)
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
- 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
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.
Post Recon the first activity appears to be exploitation of an SSRF
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 seems to be the usual mimikat, process dumping, lateral movement, data exfil etc.
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.)
- I think people are going to struggle with IOCs and here is why:
- 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.)
I’ve knocked up a quick RCE checker here:
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:
You can check for malware with ESET
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):
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:
Please contribute if you can!
These were hashed using the following script:
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)
Once you are stable, patched, are in a known good position here are some things to think about:
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
Ensure you have a robust and routing patch management process
Make sure your systems are backed up and that these backups are secure from ransomware or other threat actor attacks.
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.
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!