Threat Hunting Series: Using Threat Emulation for Threat Hunting
Originally published on October 10, 2022 on Medium.
Author Kostas
This post will demonstrate how threat emulation can be used for threat hunting. I often use threat emulation to understand the evidence an attack leaves behind upon execution.
While there are many use cases for threat emulation, this post will focus on emulating attackers’ techniques to help with threat hunting. Threat emulation is a powerful tool that can be used for threat hunting. Security teams can generate the necessary telemetry and test security solutions by emulating attackers' techniques in a lab environment. This process can help you understand an attacker’s mindset and approach, allowing you to hunt for threats more effectively.
As a threat hunter, finding available resources to hunt for an adversarial technique can be difficult at times. Some of the resources could be attack-related information (think threat intelligence/incident response reports) and telemetry (logs). In such cases, you must conduct your own research and employ threat emulation to help generate the necessary data.
IMPORTANT
Before you start emulating the attack and digging through logs, it would be best to establish what you are looking for and the purpose of your research.
It is necessary to have a lab environment to assist with recreating the attack scenarios and collect the generated telemetry. You can then analyze the results and hunt for the unique Indicators of Attack (IoAs) in production environment(s).
Steps to a successful emulation
There are numerous factors to consider before emulating an attack. I have separated the phases of emulation below:
Create a lab environment.
Gather information about the attack
Execute the attack
Analyze the collected data and create your TH queries
Eliminate false positives
Make the threat hunt repeatable
This section will go over these key steps and provide a high-level explanation for each. I will also include an example to solidify the concept. The example use case will enable the Wdigest protocol to extract clear-text credentials.
Here is a mind map of the below process:
1. Create a test environment
IMPORTANT
Just to clarify here, this will not be a malware lab. Although it is still recommended that the lab environment is isolated from any other hosts outside the lab, this will be a testing environment for re-creating attacks.
Consider using policies matching your organization’s environment when building the test environment. For instance, requesting the golden image from the IT department to have installed on one of the hosts in the lab. Additionally, in the case of a windows AD environment, you could use the same Group policies, for instance:
Disabling LDAP signing
Disabling SMB signing
Disabling NLA
etc.
Mirroring your test environment is not essential; however, it can make the results of the threat emulation more relevant to the network you will be hunting later on.
Another important aspect is the logging capabilities of the host machines. To get the most out of the emulation, hosts should record all activities, and enabling enhanced logging will help with that. A good way of enhancing logging capabilities is by using Sysmon. Sysmon can provide extensive details in addition to the default Windows event logs. Furthermore, all logs should be forwarded to a centralized location to facilitate analysis. You might use the ELK stack or any other solution you can get your hands on.
What logs should you collect?
While endpoint telemetry is arguably the most relevant data source in most scenarios, network data is also useful when developing detections for malicious communication patterns. An Intrusion Detection System (IDS) like Suricata could help create network detections, while solutions such as Zeek can provide detailed network visibility. Capturing web traffic may therefore be beneficial.
You can capture web traffic on individual endpoints with open-source software such as Wireshark or T-Shark. There are more efficient methods of capturing network traffic, but this method should be enough to get things started.
Finally, if you want to evaluate the security solutions that your organization is using, it is best to include them in your lab setup. Make sure to create detect-only policies in cases where the default prevention policy blocks tools during the emulation.
By incorporating all the above configurations, you can recreate attacks and observe their potential impact on your organization’s production environment. At the same time, the generated telemetry will help you research various attacks and attack paths. Below, I include some resources for setting up a lab environment:
Pre-made lab environments:
Detection Lab: https://detectionlab.network/
Splunk Attack Range v2.0: https://www.splunk.com/en_us/blog/security/introducing-splunk-attack-range-v2-0.html
Step-by-step guide:
Use-case example:
Setting up and using Detection-Lab
2. Gather information about the attack