The Power of the Trio - Part 2
Practical Implementation of the LAYER approach
In the previous blog, we have introduced the LAYER approach to address a common limitation/gap in threat hunting between high-level abstract/broad categories/concepts (MITRE Tactics and Techniques) and catch-all procedures.
This blog will walk through the practical implementation of the LAYER approach, focusing on EDR bypass conversations in the BlackBasta leaks.
First, let’s find out if any reports associated with “EDR bypass” implementations are available on BlackBasta. We might not get lucky all the time, but in this case, we found a report on Aukill that abuses a signed driver (PROCEXP.SYS), a “Bring Your Own Vulnerable Driver” (BYOVD) type of implementation.
Signed Driver Abuse - Aukill
Pyramid of Pain (PoP)
The idea of PoP is “the relationship between types of indicators you might use to detect an adversary's activities and how much pain it will cause them when you can deny those indicators to them.” AuKill's use of signed drivers seems easier to detect due to using specific versions of Process Explorer to disable EDR. So, one might argue that detecting that version or just looking for the presence of a process hacker would fall under the lower-level indicators on the pyramid, such as host or network artifacts, or hash values.
However, we might want to reconsider this when we are hunting for an implementation of the “Signed Driver” technique to achieve the “Impair Defense” Tactic. The same technique can be implemented using multiple vulnerable drivers (hello, loldrivers), and we only know about one such implementation.
MITRE Summiting the Pyramid
This framework emphasizes behavioral detection via Behavioral Analytics using knowledge from Contextual Analysis to uncover Complex Patterns.
It maps and enhances the Pyramid of Pain by mapping core IOCs into multiple categories and then adding available data sources to hunt these IOCs (I’m using IOC as a compound object as opposed to ephemeral values). The idea is that we need to create a vertically high detection on the pyramid, horizontally more to the right, or both.
Looking at the analysis from Aukill’s blog, we can glean some information like:
Driver loading shows specific sequence patterns: file creation, service registration, and driver loading
EDR bypass doesn't exist in isolation - we can see this from Blackbasta chats that they typically perform it at specific points in the attack, have to gain administrator/tusterinstaller level privileges, install as a service, drop the driver and finally disable every single service/thread related to EDR using multiple functions like TerminateViaProcexp, TerminateProcess, SERVICE_DISABLED, and NtUnloadDriver:
When observed together, the above sequence provides a high-confidence hunt regardless of which legitimate driver they use. So, we improved our hunt vertically and understood the context around the implementation of Aukill. For the hunt to shift right, we need to understand the exact implementations, have contextual knowledge on the environment we are operating in, data available to us, and more importantly, HOW and WHERE this implementation is performed in the MITRE ATT&CK or Kill chain or unified kill chain, depending on your usage.
At this stage, do we have a successful EDR hunt? Yes and no, well, partially. As one might notice, the functions used via Aukill are, in turn, IOCTL commands that perform the task via APIs/functions.
The core principle of On-detection is understanding what APIs are used in the entire implementation, what operations are performed using these APIs, and constructing a Functional call graph to identify compound functions. Mapping them to operations and then to the tool that is used.
Aukill Tool's API-Procedure mapping
If we look closer into the APIs utilized in Aukill and similar tools, we can see the following APIs to perform their “operation”
API Functions:
FindFirstFileA, GetFullPathNameA, loadDriver, CreateFile, CreateToolhelp32Snapshot, Process32First, ZwTerminateProcess, ZwSuspendProcess
Instead of just seeing them as individual API calls, we can map them to their functional patterns of what they do
Implementation Pattern:
Operational Pattern
Procedural Pattern
The above operation can, in turn, form a procedure to understand the implementation of Aukill. The adversary playbook is to discover security tools, gain necessary privileges, and terminate each identified security process.
PROCEDURE EDR_Process_Termination:
1. PERFORM Process_Discovery TARGETING "EDR processes in a specified list"
2. PERFORM Transition_to_Kernel_Mode
3. FOR EACH discovered_EDR_processes:
4. PERFORM Process_Termination TARGETING discovered_security_process
END FOR
END PROCEDURE
Technique
The entire procedure above can be classified into broader technique categories:
Tactical
We then understand the adversary is performing this technique to perform a specific tactic of creating blind spots by disabling/terminating EDR telemetry:
Defense Evasion (MITRE TA0005) - Specifically T1562.001 (Impair Defenses: Disable or Modify Tools)
Strategic
This will help us understand “HOW” and “WHERE” this technique supports the overall adversary's campaign. In our case, it is to perform adversarial actions in the environment without being detected and to maintain long-term persistence in the environment to achieve their objectives, like data exfiltration or ransomware deployment.
That was a lot. Let’s pause and unpack where each falls under multiple layers in our LAYER approach.
The Pyramid of Pain provides a strategic framework for prioritizing detection efforts based on the difficulty of evasion for attackers, focusing our attention on high-impact indicators. Looking at the Aukill implementation, the driver it uses, the hash of it, and the version number of the driver are easily changed. The API Functions like specific API calls, memory addresses, syscall numbers etc and Implementation & Operational Pattern which includes specific code patterns, memory scanning implementations, and sequences of operations to achieve an specifc operation require an adversary to re-tool and then the the fundamental behaviour (Tactic, Technique) like security tool termination will require adversary to change their approach. Overall, this will help hunters understand what constitutes a TTP and which specific component we should hunt to “impose cost” on the adversary’s actions. This also helps us generate the hunt pipeline.
MITRE Summiting the Pyramid emphasizes behavioral detection and contextual analysis, allowing us to move beyond selecting indicators to identify complex attack patterns. The LAYER approach will help us uncover new data sources (log-telemetry and others) we can use in our hunt by mapping them to different layers to help us move horizontally. API Functions and implementation will help us uncover these data sources related to Kernel Mode. Operational Pattern and Procedural layers uncover User Mode, and finally, Technique and Tactical uncover Application Mode.
Atkinson's On Detection: Tactical to Functional AKA Operation Focus offers a functional approach to understanding adversary actions, breaking them down into base functions and operational combinations. This will help us understand the nature of the technique to see what functions they must achieve to achieve their objectives, and combine multiple implementations to recognize patterns. We can understand the system interactions such as memory reads, process enumeration, or driver loading at the API Functions, the "Compound Functions" and operational combinations will help map to the Implementation and Operational Pattern, and this will help us reveal the essential apraoch an adersary takes to implement a specific objective at Procedural and Technique.
By applying this approach, we not only gain insight into what to hunt (Pyramid of Pain) but also where to look for the data for a specific hunt (MITRE Summiting) by uncovering the fundamental nature of the adversary’s behavior (Atkinson's approach).
We can apply Atkinson’s method discussed in their on-detection blog post to other open-source tools like EDRsilencer and PLKiller.exe. We do the same: we gather all APIs used in these tools, correlate them to functions, and then to operations. However, we will not go through the whole process.
EDR Neutralizing Tool Category
You might be wondering why we are doing all this. As you might know, several ransomware groups use various “tools” to neutralize EDR tools, and each tool has its way of doing it. We may not get most banks for our buck to try to “HUNT” for them all, but rather, we should have a deeper understanding of these “tools” and see what “commonalities” exist, or can we bucket them into their groups. At least from this, I can group all EDR tools as
BYOVD
PPL modification
“Disrupting” Telemetry
Unhooking and Patching
In/Direct Syscall
And by using this process, we may uncover new hunts to perform and associated data sources:
File creation events for any driver (.sys) file, along with driver load events, and statistically correlating them to your environment
Successful installation of kernel drivers, where and how they are installed/loaded
Monitoring the registry for new drivers and where
Monitoring for Process Terminated events per host to observe clusters (several processes terminated in our EDR, sensor list)
Monitoring for WEF filter events per host (monitor for our EDR, sensor list)
Check for manipulations to the RunAsPPL registry key
Hunting for a set of IO controls
Gather which data sources we have based on the https://github.com/jdu2600/API-To-ETW project to improve our data source reliability.
Conclusion
We often think hunting is about finding the “new badness” in the environment, and frequently hear it is about “finding the needle in the haystack”. But it is more about understanding the nature of the needle, the composition of the haystack, and predicting where the next needle might fall.
Ultimately, this will help us in:
Analysis, Precision, and pattern recognition: This approach encourages detailed discussions of specific implementations and helps us identify common patterns across different implementations.
Detection Engineering: This approach will help us focus on the procedural level, help us create hunts at each level, and show us avenues for new methods or variations of existing ones. We can also map these MITRE ATT&CK to the procedure level rather than saying we achieve 100% of MITRE TTPs.
Knowledge Transfer: It will encourage us to have high-level discussions in the hunt’s planning phase and shape our research questions at a more complex technical level. This will also help us document procedures associated with an implementation and our strategies for achieving “Summiting the Pyramid.”
Can we follow the same procedure for the in/Direct syscall and unhooking/patching techniques mentioned in the chat leaks?
 | A guest post by
|
