Threat Hunting in action

Introduction

In the previous article, we explained the essence of Threat Hunting and demonstrated its capability in detecting modern cyberthreats. With small examples, we analysed various hunting approaches such as IoC-, Tool- and TTPs-based approaches and the differences between them.

In this publication, we will dive deeper to explore Threat Hunting in action, drawing on the example of a simulated incident. After giving the incident description, we will illustrate how hunters generate hypotheses and apply various approaches to detect malicious activity. When searching for indicators of this activity, we will use Windows OS audit events and the Sysmon utility from the Sysinternals Suite, while the Elastic Stack-based Threat Hunting platform will serve for the centralised storage and analysis of data.

Incident description

As a result of a phishing attack, an unsuspecting user opens the email attachment, which is a Microsoft document with an enticing name ‘Annual_Salary_Bonuses.xlsm’. The file contains a malicious macro, which misleads the user into granting a permission for execution, and performs the following sequence of actions (fig. 1):

connects to the attacker’s control server and downloads the viewpage.php file with payload — meterpreter reverse shell
renames and saves the downloaded file in the %TEMP% directory as sysprov32.dll
writes to the registry run key HKCU\Software\Microsoft\Windows\CurrentVersion\Run the userprep value with the following content: rundll32 C:\Users\vadmin\AppData\Local\Temp\sysprov32.dll,#0
executes the payload from the sysprov32.dll file, using the command rundll32 C:\Users\vadmin\AppData\Local\Temp\sysprov32.dll,#0.

After the reverse shell execution, the attacker gains remote access to the user’s computer and dumps the user’s credentials from the SAM (Security Accounts Manager) Database with the help of the Invoke-Mimikatz.ps1 PowerShell script. However, the dumping of credentials from the LSASS (Local Security Authority Server Service) process memory fails as the Invoke-Mimikatz.ps1 script contains a Mimikatz utility version, which is not working on the user’s machine. Therefore, the attacker downloads to the user’s computer the latest version of the Mimikatz utility as an executable PE-file and saves it in the directory c:\Users\vadmin\Documents\ as m.exe. After the file is executed, the attacker steals the credentials from the RAM.

Fig. 1. Stages of the attack

Hypothesising

We have understood the sequence of actions performed by the attacker. Now let us demonstrate how hunters can detect the incident using each of the three approaches that we explored in the previous article.

Usually it all starts with a clue derived from testing of the initial hypothesis. The clue enables hunters to reconstruct the whole incident step by step. Initial hypotheses can be formed by applying one of the three approaches: IoC-, Tool- or TTPs-based.

Let us take these approaches from the simplest to the most complex and start with the IoC-based approach.

IoC-based hunting

IoC-based hypotheses involve the searching for indicators of compromise in the protected infrastructure. In the case of our incident, the IP address of the attacker’s control server obtained from the Threat Intelligence base may serve as such indicator.

Let us assume that we have selected the indicator presented in fig. 2 to test our hypothesis.

Fig. 2. Selecting an indicator of compromise from the Threat Intelligence base

According to the Threat Intelligence, the IP address 31.179.135.186 is being exploited by a malware.

Now let us generate an initial hypothesis. It may sound like this: there is a compromised host or a group of hosts in our infrastructure, which have connected or are connecting to the malicious control server with the IP address 31.179.135.186.

Using the Threat Hunting platform and available telemetry, let us try to prove the hypothesis false or positive. The request example and results are presented in fig. 3.

Request text

event_type:NetworkConnection AND (net_src_ipv4:31.179.135.186 OR net_dst_ipv4:31.179.135.186)

Fig. 3. Testing an IoC-based hypothesis on the Threat Hunting platform

The results returned by the request show that the DESKTOP-HVS4327 host has been making network connections to the malicious IP address via ports 443 and 8443.

The hypothesis has been proved positive — we may conclude that the host has been compromised.

Sysmon Event ID 3 and Windows Event ID 5156 have a field with the name of the process that has established the network connection. Let us check what processes have been attempting network connections to the malicious host (fig. 4).

Fig. 4. Processes that have created network connections with the malicious IP address

The initial connection was established by the process C:\Program Files (x86)\Microsoft Office\Office16\excel.exe, which is logical as the incident started after the user had opened the malicious Microsoft Excel attachment. We can also see a number of connections made by the rundll.32.exe process. As a result of the hypothesis testing, the incident was successfully detected.

In addition to the IP address, other indicators such as sysprov32.dll and Annual_Salary_Bonuses.xlsm files or the userprep registry value can be used to detect the incident being researched. However, the attacker can easily change all of the above listed indicators and avoid detection through the IoC-based hunting.

Tool-based hunting

Now let us see how the Tool-based approach can be applied to detect the malicious activity associated with the incident. As you may remember from the previous article, this approach identifies indicators specific to the hacker’s tools, for instance, command lines, named pipes, PowerShell commandlets or network signatures.

In order to steal the users’ credentials, the attacker used the popular Mimikatz utility and its PowerShell version — Invoke-Mimikatz, which employs the reflective PE injection to load Mimikatz into the memory.

For our Tool-based hypothesis, let us assume that the Mimikatz or Invoke-Mimikatz utility could have been used in our infrastructure to dump the user credentials. We will be searching for specific command lines in the process start events (Windows Security Event ID 4688 and Sysmon Event ID 1), and for PowerShell commandlets — by Windows PowerShell log events (Event IDs 400, 800) and Microsoft-Windows-PowerShell/Operational log events (Event ID 4104). The request example for hypothesis testing on the Threat Hunting platform and its results are presented in fig. 5.

Request text

( (cmdline:(*powershell* OR *SyncAppvPublishingServer* OR *pwsh*) OR proc_file_originalfilename:"PowerShell.EXE" OR proc_file_productname:"PowerShell Core 6" OR proc_file_description:"Windows PowerShell" OR event_log_source:PowerShell AND event_id:400) AND  cmdline:("Invoke-Mimikatz" OR "Invoke-ReflectivePEInjection" OR "Invoke-ReflectiveDllInjection" OR "Write-BytesToMemory" OR "Enable-SeDebugPrivilege" OR "Create-RemoteThread") ) OR (( (event_log_source:PowerShell AND event_id:800) OR (event_log_source:"Microsoft-Windows-PowerShell" AND event_id:4104) ) AND script_text:("Invoke-Mimikatz" OR "Invoke-ReflectivePEInjection" OR "Invoke-ReflectiveDllInjection" OR "Write-BytesToMemory" OR "Enable-SeDebugPrivilege" OR "Create-RemoteThread"))

Fig. 5. Detecting commandlets specific to the Invoke-Mimikatz utility

The request enabled us to detect the execution of commandlets specific to the Invoke-Mimikatz utility. Let us make another request to check for any Mimikatz utility command lines in the process start events (fig. 6).

Request text

(cmdline:(*mimikatz* *DumpCerts* *DumpCreds* "*invoke\-mimikatz*")) OR (cmdline:(*kerberos* *sekurlsa* *logonpasswords* *lsadump* *privilege*) AND cmdline.keyword:*\:\:*)

Fig. 6. Detecting command lines specific to the Mimikatz utility

Hypotheses testing has revealed the usage of the Invoke-Mimikatz and Mimikatz utilities on the DESKTOP-HVS4327 host. As seen from the command lines, the threat actor has dumped the local users’ credentials from the SAM base, as well as the credentials from the LSASS process memory.

As you see, the Tool-based approach is quite reliable. To be able to evade such detection, the attacker will have to customise their favourite tools or even not use them altogether.

TTPs-based hunting

The TTPs-based approach detects tactics, techniques and procedures used by the attacker, in other words, their bahavioural patterns. Therefore, the use of this approach makes it most difficult for an intruder to remain undetected.

Let us take look at the incident scheme again and generate several hypotheses that can help to detect the incident at different stages.

Hypothesis 1: An office application process has connected to a malicious host

The testing of this hypothesis requires integration with the Threat Intelligence source. Events with indicators of compromise (such as file hashes, IP addresses, domain names, email addresses, etc.) can be enriched with a special tag, e.g. malware.

On our Threat Hunting platform, all events like NetworkConnection have their IP addresses enriched in the Threat Intelligence base. Thus, our hypothesis can be tested through a simple request (fig. 7).

Request text

event_type:NetworkConnection AND proc_file_path:("\\excel.exe" OR "\\winword.exe" OR "\\powerpnt.exe") AND (enrich.ti.net_dst_ipv4.categories:Malware OR enrich.ti.net_src_ipv4.categories:Malware)

Fig. 7. An office application process connecting to a malicious host

The testing of this hypothesis has detected the presence of network connections from the process C:\Program Files (x86)\Microsoft Office\Office16\excel.exe to the malicious host with the IP address 31.179.135.18.

Despite the seeming similarity with the detection by IP address described at the beginning of this article, this approach has certain advantages. First, we are not limited to a single indicator, as we can use all indicators from the Threat Intelligence base. Second, even if we did not find the attacker’s IP address in the Threat Intelligence base, we would have detected the connection between the office application and the external IP address. This fact alone deserves attention and requires thorough analysis.

Hypothesis 2: An office application has created an executable file

Attackers often use malicious macros in documents as lightweight code to deliver the main payload from the control server. In this case, an office application process may save a payload file in the file system for its further execution. If the attacker has not disguised the file extension to be less suspicious, we can use the FileCreate Sysmon event (Event ID 1) to detect such activity.

Let us make another request on the Threat Hunting platform to find out if any executable files have been created on the host by an office application process (fig. 8).

Request text

event_type:FileCreate AND proc_file_path:("\\excel.exe" OR "\\winword.exe" OR "\\powerpnt.exe") AND file_path.keyword:(*.exe OR *.dll OR *.cpl OR *.msi OR *.sys)

Fig. 8. Executable files created by the Microsoft Excel application

Our hypothesis has proved positive again. The request results show that an executable file C:\Users\vadmin\AppData\Local\Temp\sysprov32.dll has been created on the host DESKTOP-HVS4327 by the process C:\Program Files (x86)\Microsoft Office\Office16\excel.exe

However, where a payload file has a less innocuous extension, our request won’t return any results.

Hypothesis 3: An office application has executed a cmd command interpreter

This hypothesis is based on the popular ’parent process — child process’ anomaly detection technique. This technique requires a deep understanding of the target operating system and which ’parent process — child process’ pairs are considered normal in this system.

Execution of a cmd command interpreter by an office application is an anomalous event. It can be indicative of the execution of malicious code built into the document such as a macro or DDE. The results of the next request will show whether such anomalies are found in our infrastructure (fig. 9).

Request text

event_type:ProcessCreate AND proc_p_file_path:("\\excel.exe" OR "\\winword.exe" OR "\\powerpnt.exe")  AND (proc_file_path:"\\cmd.exe" OR cmdline:(cmd.exe "*cmd *"))

Fig. 9. Execution of a cmd command interpreter by the MS Excel application

It is evident from the results that the process ’C:\Program Files (x86)\Microsoft Office\Office16\excel.exe’ has executed a cmd command interpreter on the host DESKTOP-HVS4327 with a command line C:\Windows\System32\cmd.exe /c rundll32 C:\Users\vadmin\AppData\Local\Temp\sysprov32.dll,#0. Our hypothesis proved positive.

In addition to the cmd interpreter, the hypothesis can be extended to searching for the indicators of executed PowerShell interpreters and Cscript\Wscript interpreters.

Hypothesis 4: rundll32 has been used to call the dll library function using the ordinal number

In order to execute the payload from sysprov32.dll, the attacker used the rundll32 program.

Rundll32.exe is a legitimate Windows OS program, which enables code execution from a random dll library. Using rundll32, intruders can proxy the execution of malicious code to evade the defences such as application whitelisting.

It is difficult to apply any preventative measures against this technique. Likewise, it is practically impossible to prohibit rundll32 execution in the system, because it is actively used by the operating system to carry out legitimate operations. Furthermore, attempts to detect all rundll32 executions may result in a multitude of false positives.

However, there is a solution. Rundll32.exe has a specific feature that allows to call dll library functions by the ordinal number, not by the name. While such rundll32 calls are not typical of legitimate operations, they are often used by malware to bypass signature detection. With the help of the next request, we can test the hypothesis on the presence of anomalous rundll32 calls in our infrastructure, using the process start events (fig. 10).

Request text

proc_file_path:"\\rundll32.exe" AND cmdline.keyword:/.*\#[0-9]+/

Fig. 10. rundll32.exe calls

Hypothesis 5: An office application has changed the registry run key

After the user had opened the malicious document, the threat actor gained remote access to the computer. However, the access is not permanent and will be lost after system reboot.

To retain access after the reboot, attackers apply a variety of persistence techniques. An example of such technique is writing the payload to the registry run keys and code execution during the login process.

In the case of our incident, the payload was saved in the registry key HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. The writing of any values into the registry run key by office applications is an anomaly, which can be indicative of malicious code attempting to maintain persistence in the system. Let us make a request to test our hypothesis (fig. 11).

Request text

event_type:RegistryValueSetPersistence AND proc_file_path:("\\excel.exe" OR "\\winword.exe" OR "\\powerpnt.exe") AND reg_key_path:("\\Microsoft\\Windows\\CurrentVersion\\Run" OR "\\Microsoft\\Windows\\CurrentVersion\\RunOnce" OR "\\Microsoft\\Windows\\CurrentVersion\\RunServices" OR "\\Microsoft\\Windows\\CurrentVersion\\RunServicesOnce")

Fig.11. The registry run key changed by a MS Excel process

The results returned by the request show that the process C:\Program Files (x86)\Microsoft Office\Office16\excel.exe has created in the registry key HKU\S-1-5-21-3921924719-2751751025-4067464375-1003\Software\Microsoft\Windows\CurrentVersion\Run a userprep value with rundll32 C:\Users\vadmin\AppData\Local\Temp\sysprov32.dll,#0.

Please note, that a similar activity can be detected both with the help of Sysmon Event ID 13 and security audit of the Windows OS (Event ID 4657). To enable Windows event generation, you should have SACL (System Access Control List) pre-installed on the respective registry keys.

Summing up

By applying the Threat Hunting approaches we could detect malware activity at all stages of the incident. The hypotheses which used the TTPs-based approach have proved to be the most effective.

However, when applied alone, the manual approach to hypothesis testing can be irrational and time-consuming. For better Threat Hunting efficiency, each completed hypothesis testing exercise should be analysed for automation opportunities and development of detection rules. Organised this way, the process will allow to significantly decrease the dwell time and save the hunters’ time.

The table below summarises the rules, which have been developed on the basis of our hypotheses, required telemetry and their mapping on the MITRE ATT&CK tactics and techniques.

Rule name	MITRE ATT&CK technique	Request text	Required telemetry
Connection to a malicious host by an office application process	T1071 — Standard Application Layer Protocol T1043 — Commonly Used Port	event_type:NetworkConnection AND proc_file_path:("\\excel.exe" OR “\\winword.exe” OR “\\powerpnt.exe”) AND (enrich.ti.net_dst_ipv4.categories:Malware OR enrich.ti.net_src_ipv4.categories:Malware)	Windows Security Event ID 5156 Sysmon Event ID 3 Интеграция с Threat Intelligence
Creation of an executable file by an office application	T1105 — Remote File Copy T1204 — User Execution	event_type:FileCreate AND proc_file_path:("\\excel.exe" OR “\\winword.exe” OR “\\powerpnt.exe”) AND file_path.keyword:(.exe OR .dll OR .cpl OR .msi OR *.sys)	Sysmon Event ID 11
Execution of a cmd command interpreter by an office application	T1059 — Command-line interfaces T1204 — User Execution	event_type:ProcessCreate AND proc_p_file_path:("\\excel.exe" OR “\\winword.exe” OR “\\powerpnt.exe”) AND (proc_file_path:"\\cmd.exe" OR cmdline:(cmd.exe “cmd ”))	Windows Security Event ID 4688 Sysmon Event ID 1
Using rundll32 to call the dll-library function by the ordinal number	T10865 — rundll32	proc_file_path:"\\rundll32.exe" AND cmdline.keyword:/.*\#[0-9]+/	Windows Security Event ID 4688 Sysmon Event ID 1
Change of the registry run key by an office application	T1060 — Registry Run Keys / Startup Folder T1204 — User Execution	event_type:RegistryValueSet AND proc_file_path:("\\excel.exe" OR “\\winword.exe” OR “\\powerpnt.exe”) AND reg_key_path:("\\Microsoft\\Windows\\CurrentVersion\\Run" OR “\\Microsoft\\Windows\\CurrentVersion\\RunOnce” OR “\\Microsoft\\Windows\\CurrentVersion\\RunServices” OR “\\Microsoft\\Windows\\CurrentVersion\\RunServicesOnce”)	Windows Security Event ID 4657 Sysmon Event ID 13

Conclusion

This was an example of Threat Hunting in action.

It should be noted that the attacker’s techniques in our example are quite simple — they can be detected by a properly configured operating system and free tools. On the other hand, these simple techniques are often exploited in real incidents, including targeted attacks.

At the same time, the development of EDR (Endpoint Detection and Response) solutions has prompted attackers to apply more sophisticated methods to successfully evade the detection rules, which are based on standard operating system audit capabilities and free tools. Detection of these techniques require more advanced telemetry and special tools, which will be the topic of our next article.