Washington Police Department Pwn3d by Ransomware Group Babuk
So it’s all over the news outlets, a police department (Washington DC PD) has been hit by a ransomware syndicate, Babuk. So firstly, let’s be realistic everyone can get pwn3d and at this time our thoughts go out to those affected and to the teams working the response. Being hit by ransomware is NOT fun and not something we would wish upon anyone. That being said this isn’t an ambulance chase, what I want to do hear is look at the TTPs from Babuk in a bit more detail so hopefully we can help inform and educate people so they can strengthen their security postures.
Imagine being able to read emails from any mailbox from a corporation! But everyone uses office 365… don’t they? Well ok even if that was the case (It’s not) then the RCE would come into play. An RCE into system level access to Exchange which is so heavily tied to active directory they are almost joined at the hip) is a killer foothold. However, you pain the scenarios they aren’t good!
All knowing and all powerful
Imagine if you could read everyone’s email! What could you do with this?
- Steal IP
- Steal data
- Steal credentials
- Extort, blackmail and bribe
The SSRF vulnerability enabling a threat actor to gain unauthenticated read access to mailboxes would be a killer tool for both nation state spies and criminals alike. Read more “ProxyLogon – A god mode backdoor even when used with READ only”
This isn’t a rant, far from it but I’ve been working on this for over a week now and some major questions are sprining to mind with regard to how the IOCs and detection details released may have hindered response efforts. These vulnerabilities were known about since at least December 2020, there were months to get detection intel and scripts/tools ready for people (that’s if you don’t question why did it take so long). So I’ve put some of my thoughts down here on some of the challenges with the IoCs initially released and the detection tools etc. I’ll probably update this later but wanted to publish it before it becomes virtual dust! Read more “Thoughts on IOCs for Exchange Hafnium/ProxyLogon”
Ok so John and I have been working on this for a while. We have been working with both customers and industry profesionals and there’s a common theme. Understranding the events from this incident are quite challenging because:
- We don’t have sample log output for known bad traffic
- The vulns can be used for data theft and/or backdoors (and further actions on target)
Getting guidance out so far on this has been challenging becuase:
- There is not a public full kill chain POC to do comaprisons to (i’m ok with that)
- We don’t have a pw3d server that has all the indicators from all the routes on
So to try and help people we have made a diagram which we will update as we go.
Essentially you need to perform a weighted analysis to understand if:
- You had recon only
- You had some SSRF
- YOu had SSRF that led to data theft
- You had a webshell planted
With the Hafnium “incidents” and Exchange vulnerabilities I wanted to help people with ruling in or out compromise of their Exchange 2010 environments. At the time of writing, I don’t believe that Hafnium affected Exchange 2010 via the reported kill chain, I believe that BEC would be required but this is a theory, my general view is Exchange 2010 might be ‘safe’ from this kill chain. This is due to the initial stage leveraging CVE-2021-26855 which is an SSRF vulnerability which only affectes the new architecture (2013+). However, this is an unsupported platform so I wanted to help with some baselines and talk about how I would approach ruling compromise in or out (at least with regards to these vulnerabilities). The key impact area is a web shell. I’ve made some baselines to help people look for abnormalities.
This document was made with limited time and without full Whitebox access to source code and engineering expertise. The areas we are checking for IOCs appear to make logical sense, but the OS and APP (Exchange 2010) are unsupported, and we are not the vendor. So, I am afraid your hunting responsibility is on you, this is just my opinions and thoughts from a very fast analysis. Use at your own risk. Read more “Exchange 2010 Rapid Analysis for IOCs”
For vendor guidance please see:
CVE Refs: CVE-2021-21972, CVE-2021-21973, CVE-2021-21974
There’s a new unauthenticated remove code execution (RCE) in vSphere 6.5, 6.7 and 7.0 which has just dropped. There’s a vendor patch and currently there is no known public exploit however the hunt will now be on and I can imagine that it’s hours and days until this is in the wild rather than weeks or months.Read more “vSphere Unauthenticated Remote Code Execution Vulnerability – VMSA-2021-0002”