Threat Hunting in action
After the incident description below, 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 as centralized 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 that misleads the user into granting permissions to execute 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 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.
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.
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.
( (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).
(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 customize their favourite tools or even not use them altogether.
The TTPs-based approach detects tactics, techniques and procedures used by the attacker, in other words, their bahavioral patterns. Therefore, the use of this approach makes it most difficult for an intruder to remain undetected.
Let us take a look at the incident scheme again and generate several hypotheses that might help detect the incident at different stages.
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).
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.
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).
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 was 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.
This hypothesis is based on the popular "parent process—childprocess" anomaly detection technique. This technique requires a deep understanding of the target operating system and which "parent process—childprocess" 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).
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.
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 defenses such as application whitelisting.
It is difficult to apply any preventive 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).
proc_file_path:"\\rundll32.exe" AND cmdline.keyword:/.*\#[0-9]+/
Fig. 10. rundll32.exe calls
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).
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 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.