Hunting Rituals #5:
Why hypothesis-based threat hunting is essential in cybersecurity

Proactive threat hunting is essential if you want to counter sophisticated threats that evade conventional security tools. Many advanced attackers use techniques that blend into normal network activity, avoiding detection and bypassing automated alerts.

This blog post showcases a real-life example of how hypothesis-based threat hunting can uncover hidden threats.

NOTE: The purpose of this blog post is not to share threat intelligence but to emphasize the importance of either having an in-house threat hunting team or using threat hunting services.

Introduction

In a typical one-time threat hunting engagement, experts will use a hypothesis-based approach to develop and test hunting strategies within the client’s environment and uncover potential threats. Such hypotheses are derived from years of experience in dealing with cybercriminals and an in-depth understanding of how threat actors operate.

In this blog post, we focus on Tactics, Techniques and Procedures (TTPs) that adversaries often use to maintain persistence in a compromised environment: creating or modifying registry run keys. Run keys in the Windows Registry are designed to allow programs to execute automatically during system startup. Threat actors often abuse this legitimate functionality to ensure that their malware executes every time the system boots, even after reboots or user logouts.

The methodology involves identifying suspicious processes that create or modify Run keys, or suspicious Run keys being created or modified. By analyzing telemetry data and logs, we uncovered a stealthy malware sample that had embedded itself in the system and was operating without triggering EDR alerts. Our case study emphasizes the importance of proactive hunting to detect threats that are designed to bypass reactive security controls. The techniques and tools used to uncover this evasive malware demonstrate that hunting based on TTPs can be a game-changer for modern cybersecurity defenses.

Key takeaways

• Why threat hunting within the organization is essential
• Why a hypothesis-based approach in threat hunting is highly effective
• How to conduct a hunt, from baselining to  threat identification

Who may find this post interesting:

• Cybersecurity teams
• Heads of SOCs
• Information security team leads

Step 1: Testing the hypothesis

Before beginning a hunt, experts must develop an initial hunting hypothesis. In this case, our hunting hypothesis was:

The objective is to either prove or disprove the hunting hypothesis i.e., was there really a malicious Run key created or modified? If yes, a threat does indeed exist.

Before testing the hypothesis, we must identify the relevant log sources. In our case, the client had onboarded Group-IB Managed XDR, which has an event type that makes it possible to see processes modifying the registry. We will therefore test the hypothesis using Group-IB Managed XDR.

The hunting hypothesis is then transformed into a query supported by the EDR syntax:

Fig. 1. Events returned pre-filtering

The query uses wildcards to encompass all Windows Run keys:

• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce

The query in question generated 29,084 events, including a significant amount of noise, which will need to be baselined in the next step.

Step 2: Baselining

Before proceeding with threat identification using the constructed query, we must identify normal activities related to the hunting hypothesis to create an exclusion clause for the query. Techniques like aggregating events and stack counting (i.e., counting distinct events for a set of fields like process command line) are used in this step. This step is known as baselining, where experience and knowledge of attackers’ TTPs are leveraged to differentiate between benign and malicious activities.

The objective of this step is to apply filters (e.g., excluding software used in normal business operation) to narrow down the number of events to analyze, which makes the threat identification process more efficient.

Fig. 2. Events returned post-filtering

The fine-tuned query has reduced the number of generated events to approximately 4,500. Although the numbers are substantial, we concluded that the baseline is adequate to move on to the next step.

Step 3: Threat identification

Once the initial filtering (baselining) has been completed, we conducted the following actions:

1. Identification of suspicious processes writing to the registry Run key.
2. Identification of suspicious values written to the registry Run key.

We observed a suspicious entry where a process (E:\System\Autodrive.exe) wrote an executable (located in the user’s Temporary folder) under the sub-key “Internet Security.” This behavior is highly suspicious because it suggests an attempt to disguise the sub-key as part of a legitimate product’s routine execution.

Fig. 3. Suspicious Run key written

Step 4: Deep-dive analysis

During this stage, a few investigative questions must be answered before proving or disproving the initial hypothesis:

1. What is E:\System\AutoDrive.exe? Does it exhibit unusual behavior?
2. What is “~temp~48407iG.exe” in the user’s temporary folder? Does it exhibit unusual behavior?

The deep-dive analysis will begin by examining item 1, filtering for process creation events related to the process “AutoDrive.exe.”

Understanding the process context of Autodrive.exe

Fig. 4. Process context of “AutoDrive.exe

The process creation event tells us a few things:

1. It is spawned by the process E:\Passwords.exe.
2. The process AutoDrive.exe appears to be masquerading itself as a Microsoft binary, which is evident from the metadata (e.g., having OriginalFileName of “IEXPLORE.EXE”).

As the hashes were not present in the threat intelligence database, we collected and analyzed the specimens “AutoDrive.exe” and “Passwords.exe”. The specimens turned out to be malicious and capable of spreading via USB. They are also capable of writing to the Run registry key.

At this stage, we can conclude that a USB-based threat exists within the organization. However, to assess its impact fully, further analysis must be conducted.

Investigating other events linked to AutoDrive.exe

When we examined file creation events performed by “AutoDrive.exe”, we observed that the process was responsible for creating the file “~temp~48407iG.exe”. The hash of “~temp~48407iG.exe” was found to be the same as “AutoDrive.exe”, which means that it had created a copy of itself under a randomly generated name in the user’s temporary folder.

Fig. 5. File created by “Autodrive.exe”

Investigating other events linked to ~temp~48407iG.exe

Fig. 6. Unsigned “iexplore.exe” created by “~temp~48407iG.exe”

The executable “~temp~48407iG.exe” copied itself to the folder “C:\Program Files\Internet Explorer”, effectively overwriting the original iexplore.exe and subsequently spawning it as a process.

Overview of the infection chain

With the broader view of the entire activity chain of “Autodrive.exe,” the hunting hypothesis was validated as a true positive — malware was indeed responsible for creating a registry Run key.

Other interesting findings

Fig. 7. Legitimate “iexplore.exe” showing a valid digital signature

With reference to Figure 6, the file “iexplore.exe” created by ~temp~48407iG.exe is unsigned. However, the legitimate “iexplore.exe” is actually signed. This provides a hunting opportunity for this specific threat with the following hunting query in Group-IB Managed XDR:

Conclusions

Despite the presence of multi-layered security features such as an antivirus program, no alerts were generated for this event. This means that certain threats can evade signature-based detection and remain dormant within the environment. Identifying such threats is challenging as they often rely on specific techniques (e.g., writing to the Run key), which can appear as legitimate actions performed by trusted applications. However, by adopting a proactive approach and focusing on detecting threats through tactics, techniques, and procedures (TTPs), we were able to intercept the threat before it progressed to the ‘Impact’ stage of the attack chain.

Let’s be clear: Threat hunting is not optional.

Group-IB is a leading cybersecurity provider with decades of experience in fighting cybercrime. Our expertise means that we can distinguish between benign and malicious activities by performing threat hunting using your EDR solution. You may also opt to deploy Group-IB Managed XDR for the purpose of threat hunting, complex defense, and identifying attacks across multiple vectors.