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
The next step is to gather as much information as possible about the tools needed to re-create the attack scenario. You can use OSINT to collect as much information as possible. Even if there is only high-level information available, every little hint helps. For instance, you may only find mentions of the attack in a threat intelligence report along with the outcome or the end goal after its use. Knowing the outcome can be helpful during the data analysis step later on.
If you feel stuck, you can reach out to others within the information security community. You will be surprised how many people are willing to assist. Be patient when you reach out to others; they don’t work around your schedule.
Some general questions to consider are:
A. What are the prerequisites for the attack?
Specific app/OS version
A certain misconfiguration needs to be present.
Privileges needed.
B. What is the end goal of the attack?
C. What data sources do I need to have to capture the activity?
Network logs
Process execution logs
Authentication logs
A combination of all the above?!
D. How do I launch the attack?
Use-case example:
The red teaming experiments blog has a nice post going through the attack.
Prerequisites:
Download mimikatz from gentilkiwi’s official Github page
3. Execute the attack
Once you have the necessary information and tools, it is time to execute the threat emulation. Making a note of the attack’s execution time and hostname will come in handy during the analysis phase.
It is important to note that if you require external tools to carry out the attack, you should validate the credibility and authenticity of the tools you intend to use. There have been numerous occasions where people publish backdoored tools and scripts.
Use-case example:
Step 1: Enable the Wdigest protocol and Log-off and Log back on
Step 2: Execute mimikatz with the appropriate command-line arguments
4. Analyze the collected data and create your TH queries
Having enriched logs forwarded to a centralized location where they can be parsed and be ready to review can save a lot of time during this phase. Knowing the execution time, you can jump-start the investigation and start looking into data without worrying about running additional tools.
If this is out of reach for whatever reason, you can still use some tools to collect the information from the hosts involved during the emulation. Some of these tools are Velociraptor and Kape. One should be familiar with more than one method of solving the same problem.
When capturing and analyzing network traffic, tools like the Security Onion, Arkime, or good ‘ol Wireshark make great candidates for the job.
After running the attack, you can check the security solutions you have installed (if any). Do you see any network or endpoint-based detections? If so, you can get more information about the type of detection triggered. Regardless of whether detection was triggered, if you use an EDR solution, you can query the generated telemetry surrounding the execution time.
Assuming that you found some interesting and unique indicators of attack, next step is to craft the initial queries based on the language supported by your SIEM or other solutions you use.
Knowing about some indicators that may appear in your dataset can help you identify unique patterns associated with the execution of the attack. The list below is not exhaustive, but it does include some of my favorite things to check out first:
A. Process Tree analysis
Parent-child process relationships
B. Command Line
Execution Paths
Arguments used
etc.
C. Files
Dropped files
Directory creation
D. Service/scheduled task creation/modification
E. Registry key creation/modification
Sysmon logs can include even more, detailed endpoint information that can be useful for creating the initial threat-hunting queries. Some of my favorite Sysmon Event IDs for enhanced visibility are:
Event ID 7: Image loaded
Event ID 8: CreateRemoteThread
Event ID 9: RawAccessRead
Event ID 10: ProcessAccess
A complete list of the Sysmon events and a further explanation of the above EIDs can be found here: https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon#events.
You might want to look into the Sigma project when creating your queries.
“Sigma is a generic and open signature format that allows you to describe relevant log events in a straightforward manner.”
Many security researchers contribute their detection rules in the Sigma format. You can take some of the rules and translate them into your SIEM/EDR-specific language. Once familiar with writing sigma rules, these rules can be contributed to the community and the project.
Example Sigma rule:
There are many free resources to start learning about Sigma. @nas_bench has put together some of the best ones here: https://github.com/nasbench/SIGMA-Resources.
Use-case example:
Detection Lab includes a Splunk instance to which the data are being forwarded. I use Sysmon logs to inspect the data and create the queries in this example.
A sigma rule for the above query would look like the below:
You can test and translate your sigma rules online using https://uncoder.io/ courtesy of SOC Prime.
5. Eliminate false positives
Unfortunately, it’s not all roses when you are threat hunting. It is common to have false positives after receiving the results of your initial broad searches. Filtering out benign activity is one way of improving your queries. False positives require some time to verify. At times, I spend multiple hours analyzing data and trying to make sense of the noise (false positives). Ultimately, the goal is to reduce the noise without compromising the quality of the query.
Use-case example:
The above query could be refined even more to avoid any false positives. This is an example of that:
source=”WinEventLog:Sysmon” (EventCode=13 OR EventCode=1) (Image=”*\\reg.exe” CommandLine=”* add *” TargetObject=*wdigest*) OR ((ParentImage=”*\\cmd.exe” OR ParentImage=”*\\powershell.exe”) CommandLine=”*wdigest*”) | sort +_time | table EventCode Image CommandLine TargetObject TaskCategory | sort +_time
6. Make the threat hunt repeatable
Now that you have created and refined your queries, all that’s left is to document your research and share it with the appropriate teams and the community if you choose to do so. The goal here would be to create a detection to eliminate a repeat of the same threat hunt in the future.
If the results are too noisy and are not a good candidate for a new detection, there is another way to make the threat hunt repeatable. The refined queries can be automated with the help of an Application Programming Interface (API). Most free and paid SIEM/EDR solutions have an API, which provides a way to query the data programmatically. Scripts can then be used to automatically run the queries and complete a big portion of the analysis.
Conclusion
By understanding how attackers operate, you can better design your security solutions and hunt for threats in your network. I hope this post has helped you apply threat emulation to fill in any knowledge gaps, experiment, and test your queries for more effective threat hunting.
About the Author: Kostas is a security researcher with many years of experience in the field. Coming from a technical background in incident response, he specializes in intrusion analysis and threat hunting.
Kostas devotes most of his spare time to supporting the information security community by producing free threat intelligence reports as part of the DFIRReport effort, of which he is a member. You may reach out to him with questions on Twitter @Kostastsale