THOR Collective Dispatch

THOR Collective Dispatch

Share this post

THOR Collective Dispatch
THOR Collective Dispatch
The Power of the Trio - Part 2
Copy link
Facebook
Email
Notes
More
User's avatar
Discover more from THOR Collective Dispatch
A hub for threat hunters (thrunters) and security professionals. Explore cutting-edge ideas, practical frameworks, and community-driven insights in cybersecurity. Powered by collaboration, innovation, and a relentless pursuit of a safer digital world.
Over 1,000 subscribers
Already have an account? Sign in

The Power of the Trio - Part 2

Practical Implementation of the LAYER approach

Cyb's avatar
Cyb
Apr 11, 2025
7

Share this post

THOR Collective Dispatch
THOR Collective Dispatch
The Power of the Trio - Part 2
Copy link
Facebook
Email
Notes
More
1
Share

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.

THOR Collective Dispatch is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

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:

  1. File creation events for any driver (.sys) file, along with driver load events, and statistically correlating them to your environment

  2. Successful installation of kernel drivers, where and how they are installed/loaded

  3. Monitoring the registry for new drivers and where

  4. Monitoring for Process Terminated events per host to observe clusters (several processes terminated in our EDR, sensor list)

  5. Monitoring for WEF filter events per host (monitor for our EDR, sensor list)

  6. Check for manipulations to the RunAsPPL registry key

  7. Hunting for a set of IO controls

  8. 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:

  1. Analysis, Precision, and pattern recognition: This approach encourages detailed discussions of specific implementations and helps us identify common patterns across different implementations.

  2. 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.

  3. 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?

THOR Collective Dispatch is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Trey Richardson's avatar
Jon P's avatar
A O's avatar
Creations by Lacy G's avatar
Jamie Williams's avatar
7 Likes∙
1 Restack
7

Share this post

THOR Collective Dispatch
THOR Collective Dispatch
The Power of the Trio - Part 2
Copy link
Facebook
Email
Notes
More
1
Share
A guest post by
Cyb
Cyb3rhawk leads threat hunting team. Interested in DE&TH, threat intel and DFIR. Always striving to make the daily grind of SOC analysts a breeze. Always eager to learn from others and lookout for new ways to streamline what I learn
Subscribe to Cyb

Discussion about this post

User's avatar
Measuring the Hunt When You Find “Nothing”
Because sometimes success looks like silence.
Apr 22 • 
Lauren Proehl
23

Share this post

THOR Collective Dispatch
THOR Collective Dispatch
Measuring the Hunt When You Find “Nothing”
Copy link
Facebook
Email
Notes
More
Because Logs Don’t Hunt Themselves - A Deep Dive into tstats
SPL Dispatch #1 - 04/08/2025
Apr 8 • 
Sydney Marrone
17

Share this post

THOR Collective Dispatch
THOR Collective Dispatch
Because Logs Don’t Hunt Themselves - A Deep Dive into tstats
Copy link
Facebook
Email
Notes
More
1
Introducing HEARTH: A Community-Driven Threat Hunting Repository
Threat hunting is an art and a science.
Mar 13 • 
Sydney Marrone
, 
Lauren Proehl
, and 
John Grageda
15

Share this post

THOR Collective Dispatch
THOR Collective Dispatch
Introducing HEARTH: A Community-Driven Threat Hunting Repository
Copy link
Facebook
Email
Notes
More

Ready for more?

© 2025 THOR Collective
Privacy ∙ Terms ∙ Collection notice
Start writingGet the app
Substack is the home for great culture

Share

Copy link
Facebook
Email
Notes
More

Create your profile

User's avatar

Only paid subscribers can comment on this post

Already a paid subscriber? Sign in

Check your email

For your security, we need to re-authenticate you.

Click the link we sent to , or click here to sign in.