Within the recent weeks security professionals have been scrounging their infrastructures, and the internet, for any HAFNIUM-related indicator of compromise but this is all very retroactive work and tends to lead to more tedious efforts when you don’t have the right detection framework in place.
Let’s recap the sequence of events that occurred with HAFNIUM and then discuss how this threat could have been easily detected in any Security Operations Center — without any prior knowledge of the threat.
Initial Access & Foothold
HAFNIUM, and other threat groups, utilized newly released Microsoft Exchange vulnerabilities affecting versions 2013, 2016, and 2019, to gain initial access and establish their foothold within victim environments. Their infiltration pattern proceeded as follows:
- CVE-2021-26855 was exploited via the HAFNIUM group, amongst others, which allowed them to remotely bypass authentication into a Microsoft Exchange Server by sending arbitrary HTTP requests to gain initial access.
- Three additional CVE’s were also seen locally exploited in conjunction with CVE-2021-26855 to gain additional access to email accounts in the Microsoft Exchange environment.
3. ASP-based China Chopper web shells were then written to disk on the compromised servers and subsequently executed establishing a command-and-control channel for additional exploitation and exfiltration.
This pattern of establishing a foothold is very difficult to detect near day-0 without having any prior knowledge of the threat itself — precisely because there are several newly released vulnerabilities that were exploited. Realistically, even if your organization can develop and test PoC exploit code to develop a notable-worthy detection for these kinds of new vulnerabilities, getting it done before being compromised is unlikely, especially considering all the other priorities a Security Operations Center is faced with.
If your SOC has advanced detections in place, it is possible that an alert is created due to the web shell doing a POST to the command-and-control server.
After establishing a foothold, there were several common post-exploitation procedures that took place which are utilized by a wide variety of threat groups. These procedures, along with their respective MITRE ATT&CK mappings are as follows:
- Credential theft via LSASS process utilizing ProcDump and MiniDump Credential Access: OS Credential Dumping: LSASS Memory
- Persistence via the creation of user accounts with elevated privileges Persistence: Create Account: Local Account
- Remote execution through the use of PSExec
- Execution: Remote Services: SMB/Windows Admin Shares
- Execution: System Services: Service Execution
- Stolen data compression and staging utilizing 7-Zip Collection: Archive Collected Data: Archive via Utility
- Additional command and control channels utilizing the Nishang Framework
- Execution: Command and Scripting Interpreter: PowerShell
- Command and Control: Non-Application Layer Protocol
- Downloading additional post-exploitation tools from public repositories such as GitHub Command and Control: Ingress Tool Transfer
Detection for these kinds of events occurring within your infrastructure are straightforward and the procedures have been around for quite some time, so it is safe to say that this is fair game for the detection space. Why did most organizations miss the post-exploitation occurring after compromise?
There are a couple of issues organizations face when trying to develop and effectively respond to these kinds of common post-exploitation procedures. To begin, let’s list some of the more likely situations a SOC faces:
- All IR, no Dev: Stuck in the reactive loop of responding to incidents with minimal time or ability to research and develop threat detections.
- Detection Whaling: Trying to focus on how to create singular detections geared towards big specific threats either due to management (in)direction or analysts attempting to make the most of the little time they have towards detection development.
- Purple without Red: Although these common detections don’t necessarily need a red team or lab environment to perform red team activities due to the abundance of technical articles published on how to detect these procedures, many SOCs utilize this as a crutch to make up for their incomplete or ineffective detection capability.
- Alert-Fatigue: Yes, I said it. We all know what it is, and we are tired of hearing about it, but it remains a real issue that is affecting our SOC today. Analysts are either losing confidence and ignoring the alerts generated or are faced with a difficult decision of either disabling the detection or over-safelisting objects within their logic, both of which can lead to significant detection gaps.
- Detection Framework(less): These kinds of detections pose another issue for SOCs as they can individually become meaningless without being able to be tied together across data domains to create a single, high-efficacy alert.
But let’s assume that your SOC is not stuck in a reactive state and has developed the individual detections that are commonplace in post-exploitation activity. The issue still remains where these individual detections are unable to be tied together and will inundate an analyst with alerts to triage. For those organizations that are in this situation, my condolences for the abundance of time lost trying to find the true positive in the sea of noise — if you even knew the true positive existed in the first place — after you’ve been compromised.
Maximizing your Detections with Anvilogic
With all the detections in place, how do we properly sequence and provide constraints on top of our existing detections to allow for a higher-level detection?
By utilizing these commonplace detections as identifiers towards a bigger picture, a SOC can easily solve the remaining dilemmas to provide a single high-efficacy alert once an APT’s post-exploitation procedures begin to occur. Layer 1 Identifiers become the valuable input to more effective Layer 2 Scenario detections.
Anvilogic’s no-code Threat Scenario builder allows analysts to easily and effectively build these advanced detections looking for common post-exploitation patterns while also providing the production-ready identifiers for over 350 TTPs.
About the Author
Kevin Gonzalez is currently the Director of Security at Anvilogic where he is responsible for the threat detection lifecycle and corporate security.
Prior to Anvilogic, Kevin led cyber security operations, engineering, and architectural practices at Lennar Corporation and Cubic Corporation while consulting for several organizations to help build security analytic programs and architect security solutions.
Kevin is from Miami, Florida. He holds a master’s degree from Florida International University in Management Information Systems along with several cybersecurity certifications.
Ready to learn more about Anvilogic?
Kickstart your security operations
Anvilogic provided the necessary threat detection automation for our small SOC, adding a significant force-multiplier advantage for my team.