Introduction

In the first publication from the series of articles, we have explored the Threat Hunting approach, its difference from the classical approach to cybersecurity incident monitoring and the essential components for integrating this method. In the second publication, we delved deeper and demonstrated Threat Hunting in action with an example of a potential incident and tested several hypotheses to detect various techniques used by attacker in this incident. The incident we looked at was quite simple and could have been detected by standard audit capabilities of the Windows operating system. However, the techniques applied in this incident are common in the criminal community and are used in all kinds of attacks, including targeted.

In this article, we will increase the complexity of the incident demonstrated last time. Let us assume that the attacker is well aware of the standard audit capabilities of the Windows OS and free solutions such as Sysmon from the Sysinternals suite. We will replace all the attack techniques of our incident with more advanced ones, which lead to the same result, but allow the attacker to bypass the detection rules developed and demonstrated in the previous article. These new techniques also significantly decrease detection probability where only standard audit capabilities of the Windows OS are applied.

Flashback to the previous incident

First, let us recall the incident demonstrated in the previous article. We won’t describe every stage to avoid repetition. We will simply limit ourselves to the diagram below (Fig. 1):

Fig. 1. Diagram of the initial incident

This incident can be divided into 4 stages:

1. 1. Initial access and malicious code delivery to the compromised host: steps 1-3.
2. 2. Execution of the delivered malicious code: step 4.
3. 3. Maintaining persistence in the system to retain access even after the reboot of the compromised host: step 5.
4. 4. Finally, post-exploitation, which includes the connection to the compromised host (6), dump of credentials from the SAM database (7) and of LSASS process memory (8) using the Mimikatz utility.

Now, let’s take each of these stages separately and replace the used attack techniques with more complex ones in terms of their detection.

Then we will analyse which type of telemetry we need to detect the advanced techniques and, in an analogy with the previous article, give examples of hypotheses that can be used by threat hunters in detecting similar incidents.

Initial access

Modified incident stage

In the previous incident, a phishing email served as a primary vector of compromise. It contained a Microsoft Excel attachment with a malicious macro. The user opened the document and allowed the macro, which downloaded a payload file (Reverse Shell DLL library) from a command centre controlled by the attacker and saved the file in the temporary files directory as sysprov32.dll. At the moment of the incident, the command centre was known to the cybersecurity community and listed in a variety of Threat Intelligence sources as malicious.

To detect the incident at this stage, we applied the behavioural patterns used in the following rules:

• A Microsoft Office application process establishes connection with an address, which is tagged as malware in the Threat Intelligence sources.
• A Microsoft Office application process interacts with external addresses.
• A Microsoft Office application process creates a file with an executable extension.

Let us modify this stage of the incident by making it impossible to use the above detection patterns. The channel which was used to deliver the malicious document remains the same — email. However, we will use a Microsoft document instead of Excel (although this does not make a big difference), which also contains a malicious macro, but with a modified code.

Let us change stage 3 — downloading of an executable file from a resource, which is marked as malware in the Threat Intelligence sources. Instead of a dedicated server controlled by the attacker, whose address can be easily and quickly blacklisted, the attacker could use a widely known internet service such as Twitter, Gmail, Github, Dropbox, etc. as a command centre. In the MITRE ATT&CK matrix, this technique’s ID is T1102 and it is called ’Web Service’. Its use enables the attacker to hide their network communications and avoid detection based on blacklists of malicious addresses, as the addresses of widely known services do not get blacklisted (except solutions that allow to use whole URL or masks in blacklists, rather then only IPv4, IPv6 or FQDN).

Of course, the attacker runs the risk of being detected by service owners during the periodic scanning of all uploaded content for malware or such content being deleted if it is flagged by users. However, this does not happen instantaneously and, therefore, the attacker will probably have enough time to achieve their goals, while the public service owners are trying to spot the malicious content.

In the current example, the executable file will be downloaded from the pastebin.com service, but not from a server controlled by the attacker, which is included in multiple Threat Intelligence sources. As this service is meant to publish text data, the dll library with Reverse Shell must be converted to a text representation, and the base64 encoding algorithm serves this purpose perfectly. In the figure below, you can see an example of an executable file uploaded to Pastebin and encoded with the help of base64 (Fig. 2):

Fig. 2. An executable file uploaded to Pastebin, encoded using the Base64 algorithm

Pastebin allows to receive the downloaded data via a generated direct link. Thus, the attacker can use this link to download a base64 line, decode it and save the output executable file on the drive for further execution. This can be carried out directly from the macro, however, the interaction of the Miscrsoft Office application with the pastebin.com servers may raise alarm with an experienced analyst as an extremely atypical activity for this type of application.

And we are moving towards the second pattern which was used to detect the previous incident — interaction of a Microsoft Office application process with external addresses. In order to avoid detection, the attacker needs to somehow hide the network interaction of the Microsoft Office application with the Pastebin service, or interact on behalf of another process, for which this activity is normal and is unlikely to raise the hunter’s suspicion. And in this case the Windows operating system gives a remarkable opportunity to the attacker as an Internet Explorer COM object. This COM object is implemented as a dll library C:\Windows\System32\ieproxy.dll. When loaded to the address space of the client process, this library enables interaction with the internet resources, including the downloading of files on behalf of the Internet Explorer browser. In other words, endpoint monitoring tools will see the network activity initiated by the client application (e.g. from a Microsoft Office document macro) as that initiated by Internet Explorer (C:\Program Files (x86)\Internet Explorer\iexplore.exe) process, rather than a client application using a COM object. Thus, in the modified incident, the attacker uses a COM object to download the base64 encoded payload file.

The base64 data downloaded from Pastebin must be decoded, hence, a special function is added to the macro. The result returned by this function — a byte array of an executable PE file — must be saved on the drive for further use. Let us see how to do this undetected. Keep in mind that the standard audit capabilities of Windows, Sysmon and many commercial EDR solutions do not contain information about the file type in their file creation/change events, which leaves the file extension as the only indicator of executability. Knowing this, the threat actor can save the downloaded executable file without an executable extension (in our case — without .dll) under the name and in a directory typical of the respective application (e.g. a file with a dotm extension in the template directory C:\Users\user_name\AppData\Roaming\Microsoft\Templates). This way, the attacker will bypass the detection rule, which reveals the creation of a file with an executable extension by a Microsoft Office application.

Given the described modifications, the initial access stage will look as follows (Fig. 3):

Fig. 3. Modification of the Initial Access stage

Detection at the modified stage

Now let us see how initial access and malicious code delivery techniques can be detected at the modified stage. To do this, we will built several hypotheses and try to test them using Sysmon events and an EDR Solution (BI.ZONE SENSORS).

Hypothesis 1. The attacker may use an Internet Explorer COM object in scripts or macros to interact with the internet resources

An Internet Explorer COM object represents a dll library located at C:\Windows\System32\ieproxy.dll. For the client application to use this COM object (for example, from a macro), the ieproxy.dll library must be loaded by the application process. The loading of this library by an unusual application (such as Microsoft Office or script interpreters) can be indicative of the attacker’s attempt to employ the respective technique. Thus, the said pattern can be used to test our first hypothesis, but for this we will need DLL loading events. Unfortunately, the standard audit capabilities of the Windows OS are helpless here. The required events can only be obtained from Sysmon or an EDR agent.

Let us make the following request to test our first hypothesis (Fig. 4):

event_type:ImageLoad AND file_path:"*\\ieproxy.dll" AND proc_file_path:("\\cscript.exe" OR "\\wscript.exe" OR "\\powershell.exe" OR "\\winword.exe" OR "\\excel.exe" "\\powerpnt.exe" OR "\\mspub.exe" OR "\\visio.exe" OR "\\msaccess.exe" OR "\\regsvr32.exe")

Fig. 4. Detection (using EDR/Sysmon events) of loading the Internet Explorer COM object’s DLL by unusual process

The result of the request shows that a Microsoft process has loaded a dll library ieproxy.dll on the host odered.shockwave.local. This may be indicative of the use of an Internet Explorer COM object from the macro.

Hypothesis 2. The attacker may use paste services (pastebin.com, gist.github.com, etc.) as the command centre

In the modified incident, we have replaced the command centre, which was previously used by the attacker and marked in the Threat Intelligence sources as malware, with a legitimate web service pastebin.com. On this service, the attacker can roll out certain commands and even entire executable files as text snippets. In order to detect the malware that uses paste services as a command centre in the infrastructure, hunters could analyse the entire outbound traffic of the corporate network, directed to these services. However, large infrastructures may have too much such traffic.

In order to reduce the scope of analysed events, they should be filtered. For instance, to filter events involving DNS queries from processes, we can select all attempts to resolve domain names of the known paste services by non-browser processes. However in this case we will filter out the interaction with these services initiated using an Internet Explorer COM object, since such requests will be initiated from an Internet Explorer process. To avoid this, we need to adjust the current search pattern as follows: attempts to resolve domain names of the known paste services by non-browser processes and browsers’ COM objects. In other words, we need to select all DNS queries for resolving names of respective services, which are NOT triggered by user actions.

The attentive reader may ask how DNS queries initiated by an external application using the browser’s COM object to interact with the Internet can be distinguished from DNS queries triggered by the user surfing the Internet on the same browser? In both cases the request is initiated by a browser process. They can be distinguished by enriching the DNS request event with information about the parent process, namely — a command line of the parent process. Thus, when an Internet Explorer COM object is used, the parent of the Internet Explorer process (iexplore.exe) will be a process with a similar executable file, but containing an ’-Embedding’ argument in the command line. This is an indicator of the use of a COM object, which also applies to many other Microsoft applications.

Below we give an example of an EDR event caused by a DNS query initiated as a result of interaction with the internet resources using an Internet Explorer COM object (Fig. 5):

Fig. 5. Example of an event on a DNS query initiated as a result of interaction with internet resources using the Internet Explorer browser COM object

Now we have all necessary information to generate a search request to test our hypothesis (Fig. 6):

event_type:DNSReq AND
dns_rname:("pastebin.com" OR "gist.githubusercontent.com" OR "raw.githubusercontent.com") AND
(
(-proc_file_path:("\\firefox.exe" OR "\\iexplore.exe" OR "\\application\\browser.exe" OR "\\chrome.exe" OR "\\amigo.exe" OR "\\opera.exe" OR "\\microsoftedgecp.exe" OR "\\microsoftedge.exe" OR  "\\vivaldi.exe" OR "\\safari.exe" OR "\\ieuser.exe" OR "\\qqbrowser.exe" OR "\\spartan.exe" OR "\\spartan_edge.exe" OR "\\spartan_legacy.exe" OR "\\ucbrowser.exe" OR "\\qqbrowser.exe" OR "\\sogouexplorer.exe" OR "\\icedragon.exe" OR "\\maxthon.exe" OR "\\waterfox.exe")) OR
(proc_file_path:"\\iexplore.exe" AND proc_p_file_path:"\\iexplore.exe" AND proc_p_cmdline:*Embedding*)
)

Fig. 6. Access to Paste services (pastebin, etc.) not from browsers, but also from browser COM objects.

As results from the request, the codered.shockwave.local host has interacted with the pastebin.com service via an Internet Explorer COM object. Given the result of testing the previous hypothesis, we may conclude that the interaction with the pastebin.com service has been initiated by a Microsoft Word application process.

Hypothesis 3: The attacker may download an executable file to the system and save it without an executable extension

In the modified incident, data downloaded by a Microsoft Office process from pastebin.com represents a base64 encoded PE file. Having decoded this data, a Microsoft Word process saves the output PE file on the drive without an executable extension. This enables the attacker to evade the previous detection rule, which reveals the creation of files with executable or script extensions by Microsoft Office application processes. Without such an extension, the only way to understand whether the saved file is executable, is to analyse the first few bytes at the beginning of the file.

All PE files start with the so-called MZ header, which represents an MZ ASCII string (4D5A in HEX representation). This header can be used to detect any created executable files even if they do not have an executable extension. Unfortunately, neither the standard audit capabilities of Windows, nor Sysmon can carry out such checks of file operations, which does not allow their use in testing this hypothesis. At the same time, certain commercial EDR solutions are capable of doing this. Thus, below you can see a request for our EDR solution (BI.ZONE SENSORS), that selects events involving the creation of executable files by Microsoft Office applications, including those without executable extensions (by the file_magic field containing several bytes that the file begins with) (Fig. 7):

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 OR *.scr) OR file_magic:4D5A*)

Fig. 7. Detection (using EDR events) of executable files creation without executable extensions

The request has returned one event, which indicates that a file has been created on the codered.shockwave.local host as a Microsoft Word template, which in reality is an executable PE file according to the content of the file_magic field — the file starts with an MZ header (4D5A).

There is another way to search for this type of event — creation of a file that starts with an MZ header, but having no executable extension:

event_type:FileCreate AND file_magic:4D5A* AND -file_path.keyword:(*.msi OR *.ocx OR *.cpl OR *.ax OR *.sys OR *.scr OR *.com OR *.vxd OR *.dll OR *drv OR *.exe OR *.pif)

The presence of the so-called Magic in file creation/change events (the first few bytes starting the file) significantly expands the applicability of these events and allows to find interesting file operations not only based on file names and extensions, but on known signatures of various types of files.

Hypothesis 4: The attacker may use documents with macros for initial access

In our previous hypothesis we assumed that the activity had been initiated by a macro. Let us try to prove it. Every time the user allows macros in the opened Microsoft Office document, the respective Microsofit Office application process loads the dll library VBE7.DLL. This behavioural pattern is a fairly reliable indicator that the document contains a macro, which execution has been allowed by the user. Let us generate a search request based on this indicator to check our hypothesis (Fig. 8):

event_type:ImageLoad AND proc_file_path:("\\excel.exe" OR "\\winword.exe" OR "\\powerpnt.exe" OR "\\msaccess.exe" OR "\\mspub.exe" OR "\\outlook.exe") AND file_path:"\\VBE7.DLL"

Fig. 8. The event indicating that the user has allowed the launch of the macro in the Microsoft Word document

Our hypothesis has proved positive. The entire detected activity has been initiated by a malicious macro.

We are now done with the initial access and malware code delivery and now let us move on to code execution.

Execution

Modified incident stage

The attacker needs to somehow execute in the system the code downloaded from Pastebin, decoded and saved without an executable extension as a Microsoft Office template. Previously, we used a standard rundll32 utility for this purpose. As command line parameters, the utility received a path to the downloaded library and an ordinal number of the function for calling from the library. The latter was used to detect the corresponding stage, since the rundll32 utility is rarely used in such contexts for legitimate purposes. Besides, the utility was executed from the cmd console directly from the macro, which we also used as a detection pattern — execution of a CMD interpreter by a Microsoft Office application.

Now let us try to bypass the previously developed detection rules. We will start with the rundll32 utility, which will be used again in the modified incident for code execution from the downloaded dll library. However, we will apply a different technique — COM Hijacking (T1122). A new COM object is registered in the system directly from the macro using the reg.exe utility and the Registry key/hive restore function (you will find more information about Registry Restore in the next section). The file, that was created in system as the result of decoding the data downloaded from pastebin.com, is specified as a DLL library of registered COM object (Fig. 9):

Fig. 9. Registering a COM object with CLSID {018D5C66-4533-4307-9B53-224DE2ED1FE7}.

After the COM object is registered, the code from the respective library can be executed with the help of the little known ’-sta’ parameter of the rundll32.exe utility command line. The COM object’s GUID must be indicated together with this parameter. Once this is done, rundll32.exe will load COM object DLL library to the memory and pass on control to the entry point DLL_PROCESS_ATTACH. An example of such rundll32.exe command line — “rundll32 -sta {018D5C66-4533-4307-9B53-224DE2ED1FE7}”.

However, if rundll32 is executed directly by a Microsoft Office application process, it will be very suspicious and may draw attention of a scrupulous hunter. Let us break the parent — child relationship using the technique Parent PID Spoofing (T1502). The CreateProcess functions in Windows Vista and above allows to pass the handle of the process, which will serve as a parent to the executed child process. So, in this case the process that has called CreateProcess won’t serve as a parent of the created process. Instead, the process, whose handle was passed with arguments of the CreateProcess function, will be the parent of the created process. This technique enables the evasion of detection rules based on parent-child anomalies, since the standard audit capabilities of Windows, Sysmon and some of EDR solutions do not allow to identify the real CreateProcess caller. In our incident, we use this technique to hide the real initiator of rundll32 execution — a Microsoft Word process.

We will go a little further and try to execute rundll32 in a most plausible way so that it goes unnoticed by a most scrupulous hunter. To this effect, we will not only spoof a parent process, but a command line as well using the technique Command Line Spoofing, which can help hide the real command line used to create the process. Thus, by combining Parent Process Spoofing and Command Line Spoofing in our modified incident, we will execute the rundll32 utility from the macro, which will result in malicious code execution. Monitoring tools will recognise this execution as a true process. Below we illustrate standard Windows audit (left) and Sysmon (right) events, generated as a result of combining spoofing techniques (Fig. 10):

Fig.10. Example of Windows and Sysmon events in case of process start with spoofing the command line and the parent process

Even the most experienced hunter would hardly spot anything suspicious in these events. It all looks like a legitimate execution of the screensaver configuration interface, but in reality a Microsoft Office process has executed malware code by command rundll32 -sta {018D5C66-4533-4307-9B53-224DE2ED1FE7}.

As a result of application of these techniques, the execution of malicious code stage will look as follows (Fig. 11):

Fig. 11. Modification of the malicious code execution stage

Detection at the modified stage

Despite the seemingly difficult detection of the applied bypassing techniques, they can nonetheless be spotted. The operating system provides an opportunity of getting information about the real CreateProcess initiator and if the endpoint monitoring tool can extract this information, then it can supply this information in process creation events. When it comes to command line spoofing, it is much more complicated, however this technique can still be detected. To do this, EDR should track the PEB (Process Environment Block) modification of the processes executed in a suspended state.

Hypothesis 5. The attacker may use Parent PID Spoofing to evade detection based on parent — child anomalies

The EDR solution used in our example can receive information about the real initiator of process creation. Usually, the initiator of process creation and its parent are the same. Therefore, to save resources, the attributes of the initiator process (CreatorProcess) are only filled in the process start event if the process creation initiator (CreatorProcess) differs from the Parent Process. Below is an example of such event (Fig. 12):

Figure 12. Example EDR event for process creation with command line and parent process spoofing

Now that we understand the features of the process creation event of our EDR solution, let us try to make a search request to test our hypothesis. We need to select process creation events with filled CreatorProcess attributes (starting with CreatorProcess prefix, which in our data model are indexed into fields starting with proc_c...) excluding the processes for which this is normal (process start with elevation via UAC, execution on behalf of another user, WerFault process activity, etc.) (Fig. 13):

event_type:ProcessCreate AND proc_c_file_path:* AND proc_p_file_path:* AND -proc_file_path:"\\WerFault.exe" AND -(proc_c_file_path:"\\system32\\svchost.exe" AND proc_c_cmdline:(*seclogo* *appinfo* * netsvcs*))

Fig. 13. Parent PID spoofing detection using EDR events

Our request has returned one event that relates to the execution of the standard rundll32 utility with a parent process Explorer.exe. However, it was actually initiated by a Microsoft Word application process used to open a malicious document received from the threat actor.

Persistence

Modified incident stage

In the original incident, the attacker created a new value in the registry Run key in order to maintain persistence in the system. The value was modified directly from the malicious macro, which we used for detection — it is extremely suspicious when a Microsoft Office application process changes the registry Run key value.

Let us modify this stage to avoid detection by applying the mentioned pattern. For this, we need to either modify the registry on behalf of the application, for which registry modification is a normal process, or use non-standard functions to change the registry Run key record.

Let us apply both methods simultaneously. Instead of modifying the registry directly from the macro, we will use the reg.exe utility, for which registry modification is a standard function. However, this can be extremely suspicious where a Microsoft Office application process is a parent process of reg.exe. To break this parent — child relationship, we will use another technique — process execution from a macro through the WMI mechanism. As the result of execution via WMI, the reg.exe tool processes will have a system process wmiprvse.exe as their parent, rather than a Microsoft application process, which actually breaks the parent — child relationship. Below we provide examples of the corresponding process creation events from the Security (left) and Sysmon (right) logs (Fig. 14):

Figure 14. Example of Windows and Sysmon events in case of process execution via WMI

These events correspond to the execution of the reg.exe utility through the WMI mechanism initiated from the macro in the Miscrosoft Office document. As seen from the events, they do not contain any information indicative of a Microsoft Word process, which means that the parent — child relationship is broken.

Now let us see how we can write a new autorun value to the Run key which will go unnoticed by the monitoring tools. Instead of changing the registry key value using the functions RegSetValueA/RegSetValueW/RegSetValueExA/RegSetValueExW, which are controlled by the operating system audit, Sysmon and practically all existing EDR solutions, we can use functions less typical of this operation: RegRestoreKeyA/RegRestoreKeyW/RegReplaceKeyA/RegReplaceKeyW/RegLoadKeyA/RegLoadKeyW, which also allow to change the registry key value.

As you might have noticed from the above events, in our case we will modify the registry using RegRestoreKey, which allows us to restore an entire key or even a registry hive with all values from the file. For the sake of time, we will use the reg.exe utility, rather than develop own code for this operation.

An experienced reader could have noticed that executing through WMI the reg.exe utility, which contains in its command line the registry key *\Windows\CurrentVersion\Run is generally very suspicious and can be detected by native process creation events of the operating system. Yes, that’s true. However, let us highlight again that the reg.exe utility has been used solely to save time. In a real-life incident the registry key value could have been restored from the macro without calling additional utilities, and this wouldn’t have left in the standard Windows and Sysmon logs any indicators such as reg.exe process creation events and Run key modification — these tools do not allow to track the use of functions RegRestoreKeyA/RegRestoreKeyW

Thus, the modified stage of maintaining persistence in the system will be as follows: using an Internet Explorer COM object, a registry key dump file is downloaded to the compromised host and saved as NormalMail.dotm in the Microsoft Office template directory. The file contains pre-installed values to be written to the Run key. It is also used to write a COM object to the registry, which is required to execute the malicious code. Registry key values from this file are restored with the help of the reg.exe utility, executed by the macro via WMI.

As a result of the mentioned modifications, the persistence stage diagram will look as follows (Fig. 15):

Fig. 15. Modification of the attacker’s Persistence stage in a compromised system.

Detection at the modified stage

Let us see what hypotheses can help a hunter to detect the incident at the modified persistence stage.

Hypothesis 6: The attacker may use non-standard functions RegRestoreKeyA / RegRestoreKeyW / RegReplaceKeyA / RegReplaceKeyW / RegLoadKeyA / RegLoadKeyW / RegRenameKey to modify registry keys

To test this hypothesis, we will need events supplied by the EDR solution, which allow to control the use of the mentioned functions. Below we present an example of such event (Fig. 16):

Fig. 16. An example of EDR event in case of Registry key restore using the RegRestoreKey API

Now let us generate a request to our Threat Hunting platform, which will help to prove our hypothesis correct or false (Fig. 17):

event_type:(RegistryRestore OR RegistryLoad OR RegistryReplace OR RegistryRename) AND reg_key_path:("\\Microsoft\\Windows\\CurrentVersion\\Run" OR "\\Microsoft\\Windows\\CurrentVersion\\RunOnce" OR "\\InprocServer32" OR "\\Windows NT\\CurrentVersion\\Windows" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\" OR "\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\GPExtensions\\" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Notify\\" OR "\\Microsoft\\Windows NT\\CurrentVersion\\WOW\\Boot\\" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\Run" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\Load" OR "\\CurrentControlSet\\services\\" OR "\\ControlSet001\\services\\" OR "\\ControlSet002\\services\\" OR "\\ControlSet003\\services\\" OR "\\Control\\Lsa" OR "\\Control\\SecurityProviders" OR "\\Control\\Print\\Monitors\\" OR "\\Control\\Session Manager" OR "\\Microsoft\\NetSh" OR "\\Scripts\\Logon\\" OR "\\Scripts\\Logoff\\" OR "\\Scripts\\Startup\\" OR "\\Scripts\\Shutdown\\")

Fig. 17. Detection (using EDR events) of autoruns’s Registry keys modification using non-standard functions (RegRestoreKey/RegReplaceKey/RegLoadKey/RegRenameKey)

As you can see, the request has helped us to detect the modification of the Run key and registration of a COM object using RegRestoreKey. Our hypothesis was correct.

Hypothesis 7. To break the parent — child relationship, a malicious macro from the Microsoft Office document may create processes using the WMI mechanism

This hypothesis suggests the use of a technique which is becoming popular among attackers, for instance, in evading the detection rules based on parent — child anomalies. In our example, we have used WMI to launch the reg.exe utility from the macro. Now let us see how this activity can be detected. For this, we need a source supplying events in response to WMI commands executed by processes. This can be both EDR and standard Windows audit in form of Microsoft-Windows-WMI-Activity/Debug log, which must be allowed in advance.

Below you can see an example and results of a request for checking our hypothesis on the Threat Hunting platform (Fig. 18):

event_type:WMICommand AND wmi_command:"*Win32_Process::Create*" AND proc_file_path:("\\excel.exe" OR "\\winword.exe" OR "\\powerpnt.exe" OR "\\mspub.exe" OR "\\visio.exe" OR "\\msaccess.exe")

Fig. 18. Detection (using EDR events) of attempts to spawn process by MS Office applications through WMI

Post-exploitation

Modified incident stage

We have finally come to the post-exploitation stage. In the previous incident, the attacker used the Mimikatz utility for this stage, both as an execuatable and as a PowerShell sctipt (Invoke-Mimikatz) to dump user credentials from the SAM database and LSASS process memory. These utilities are well-known and can be detected by most antivirus solutions. Using these utilities without any modification is not the best idea for an attacker who wants to conceal their presence in a compromised system.

Last time, we detected the use of Mimikatz by specific command lines and names of PowerShell functions/scriplets. This time, let us not use any additional utilities to dump the credentials, especially such conspicuous ones as non-customised versions of the Mimikatz utility.

We will modify this stage of the incident by replacing the dump of credentials from the LSASS memory and SAM database with a dump of the SAM database itself and LSASS process memory, from which the attacker can extract the required data on his side. To create the mentioned dumps, we will limit ourselves to the use of standard capabilities of the operating system without any other tools that could increase detection probability.

To dump the SAM database, we will use the standard reg.exe utility, which in addition to restoring keys and registry hives from the file (which we used to write to the autorun unnoticed) also allows to export keys/registry hives to the file, using the API function RegSaveKey. The SAM database itself is a Windows Registry hive (HKLM\SAM), and, therefore, can be exported with the help of RegSaveKey. The respective commands are presented in the example below (alongside with the SAM hive dump, the attacker needs to dump the SYSTEM hive, which contains the key used by the system to encrypt the SAM content):

Fig. 19. Using the reg.exe utility to dump registry hives with account authentication data

To dump the LSASS process memory, we will use the MiniDump function from the dll library C:\Windows\System32\comsvcs.dll. It will be executed with the help of the rundll32.exe utility. This technique has been discovered just recently. It allows to dump any process memory from the console without using any extra tools. Below you can see an example of its usage:

Fig. 20. Creating a LSASS process memory dump with the help of the rundll32.exe utility and comsvcs.dll library

Thus, the post-exploitation stage has been modified as follows (Fig. 21):

Fig. 21: Modification of the post-exploitation stage

Now let us see how the mentioned techniques can be detected.

Detection at the modified stage

Hypothesis 8. The attacker may dump the SAM database by exporting the respective registry hive

Such export is not exclusive to the utility reg.exe, so we will not attempt to detect this technique by a specific command line of this utility. Instead, we will focus on the lower level — the employed API functions. The registry hive can be exported with the help of the functions RegSaveKeyA/RegSaveKeyW/RegSaveKeyExA/RegSaveKeyExW.

So, if we have an event source at our disposal, which allows us to control the calls of the above functions, we will be able to detect this technique regardless of the applied tool. A number of EDR solutions have this capability.

The example below (Fig. 22) shows a search request and results returned by our Threat Hunting platform:

event_type:RegistrySave AND reg_key_path.keyword:(*\\SAM OR *\\SYSTEM OR *\\SECURITY)

Fig. 22. Detection (using EDR events) of attempts to dump Registry hives with account authentication data

Our hypothesis has proved right. The attacker has dumped three sensitive registry hives on the host codered.shockwave.local. As a result, they can gain access to the local account hashes, service account passwords and cashed credentials of domain users, which allow these users to access the system even if domain controllers are not available.

Hypothesis 9. The attacker may dump the LSASS process memory to extract user credentials

As in the foregoing hypothesis, we won’t focus on detection of the specific command line (in our case — rundll32 utility), but rather will try to generate a universal request that allows to detect attempts to dump the LSASS process memory irrespective of the applied tools.

To create a memory dump of the process it is necessary to request a handle for this process, for which purpose most tools use the API function OpenProcess. Thus, having the event source, which allows to track requests for handles of another processes, it is possible to detect the given technique regardless of the tool. This can be done with the help of Sysmon, the majority of EDR solutions and even standard audit capabilities of the Windows OS.

However, as practice shows, a lot of processes access the LSASS process memory in the course of legitimate operation of the Windows OS. Therefore, this cannot serve a definite indicator of attempts to dump LSASS process memory or read the credentials directly from the memory, without its dumping.

We need to know the exact pattern to narrow our search. For this purpose, hunters should know that most memory dump utilities, including standard Windows tools, use the MiniDumpWriteDump functions from the library C:\Windows\System32\dbgcore.dll (in some Windows versions — C:\Windows\System32\dbghelp.dll). Respectively, access to the memory of the target process (whose memory dump is created) in case MiniDumpWriteDump is used, will be provided from the dbgcore.dll/dbghelp.dll library.

Now that we know how most of the process memory dump utilities work, let us put forward the requirements for the events necessary to detect their behaviour.

The event of accessing someone else’s process memory must contain information about the thread from which this access is performed. This information must include the thread’s start address and an indication that it belongs to a specific module on the drive.

With an event that meets these requirements, a threat hunter can develop a search query to find LSASS memory accesses initiated from the C:\Windows\System32\dbgcore.dll and C:\Windows\System32\dbghelp.dll libraries. The events selected by such a query will almost certainly indicate attempts to create an LSASS memory dump.

Such information is contained in the respective Sysmon events and the events of number of EDR solutions. Examples of such events (Sysmon — below, BI.ZONE sensors — above) are presented below (Fig. 23):

Figure 23: Example of Sysmon and EDR events in case of LSASS process memory access

You can identify the OpenProcess source by the thread stack trace. In this stack trace you can see that, at first, the rundll32 process called the MiniDumpW function from the comsvcs.dll library (it was this function that we specified in the rundll32 command line parameters), and from there the MiniDumpWriteDump function was called directly from dbgcore.dll, which eventually led to the access of LSASS process memory (note the top frame in the stack trace, corresponding to the call of NtOpenProcess API function from ntdll.dll).

Now that we understand how the stack trace is generated, let us develop a request to check the hypothesis on LSASS process memory dump (Fig. 24):

event_type:ProcessAccess AND proc_tgt_file_path:"\\system32\\lsass.exe" AND proc_calltrace:(*dbghelp* OR *dbgcore* OR *MiniDumpWriteDump*)

Fig. 24: Detection (using EDR/Sysmon events) of attempts to create LSASS process memory dumps

The request has returned Sysmon and EDR events which are indicative of access gained to the lsass.exe process memory by the rundll32.exe process to create a dump.

Finally, let us consider one more pattern, which can be used to test hypotheses on any registry hive and LSASS process memory dumps created by the attacker — detecting the creation of files on the drive which are by their structure actually the mentioned dumps. These files do not have well-known specific extensions, which means that they cannot be identified by their extension. However, by analogy with the above mentioned PE files they have well-known headers that can be used to identify them: “regf” (72 65 67 66) — registry dumps, "MDMP"§ (4D 44 4D 50 93 A7) — memory dumps. Thus, with an EDR solution capable of determining the type of files to be created or supplying the first few bytes from the beginning of the file (file magic) in the file creation events, we can detect the creation of files, which structure is the same as memory dump or registry dump. Such detection would be a very good addition to the ones listed above. The corresponding request to the Threat Hunting platform may look like this (Fig. 25):

event_type:FileCreate AND file_magic:(4D444D5093A7* OR 72656766*)

Fig. 25: Example of EDR events in case of registry and memory dump files creation on the drive

The request has returned events involving creation of registry hive and LSASS process memory dump files as the result of the reg.exe and rundll32.exe utilities usage to create such dumps.

Summary

So, it’s time to sum up. We took the incident from our last article where we demonstrated the Threat Hunting approach to identify its various stages, and step by step made it more complex, gradually applying more and more sophisticated techniques, bypassing the detection rules we have developed.

The resulting modified incident is no longer that simple. Detecting it would require more than just an operating system audit policy configuration. It now requires the use of additional tools that collect extended telemetry from the endpoints (like Sysmon or commercial EDR solutions).

Let us see what we have got as a result (Fig. 26):

Fig. 26. Diagram of a modified incident

The attacker, who is aware of operating system auditing capabilities and the approaches used by analysts to identify threats, will apply sophisticated techniques to counter this and remain undetected.

However, with the right tools and skilled analysts, even these types of incidents can be detected, which is exactly what we have tried to demonstrate in this article.

Let’s take a look at the summary table with rules developed based on our hypotheses, the telemetry required for them, and their mapping to the corresponded MITRE ATT&CK techniques:

Rule	MITRE ATT&CK technique	Text of request	Required telemetry
Macro executed in a Microsoft Office document	T1204: User Execution T1064: Scripting	event_type:ImageLoad AND proc_file_path:("\\excel.exe" OR "\\winword.exe" OR "\\powerpnt.exe" OR "\\msaccess.exe" OR "\\mspub.exe" OR "\\outlook.exe") AND file_path:"\\VBE7.DLL"	Sysmon Event ID 7 EDR Library Load event
Internet Explorer COM library loading by unusual process	T1071: Standard Application Layer Protocol	event_type:ImageLoad AND file_path:"*\\ieproxy.dll" AND proc_file_path:("\\cscript.exe" OR "\\wscript.exe" OR "\\powershell.exe" OR "\\winword.exe" OR "\\excel.exe" "\\powerpnt.exe" OR "\\mspub.exe" OR "\\visio.exe" OR "\\msaccess.exe" OR "\\regsvr32.exe")	Sysmon Event ID 7 EDR Library Load event
Non-browser access to Paste services (pastebin, etc.), as well as from the browser’s COM objects	T1102: Web Service	event_type:DNSReq AND dns_rname:("pastebin.com" OR "gist.githubusercontent.com" OR "raw.githubusercontent.com") AND ( (-proc_file_path:("\\firefox.exe" OR "\\iexplore.exe" OR "\\application\\browser.exe" OR "\\chrome.exe" OR "\\amigo.exe" OR "\\opera.exe" OR "\\microsoftedgecp.exe" OR "\\microsoftedge.exe" OR "\\vivaldi.exe" OR "\\safari.exe" OR "\\ieuser.exe" OR "\\qqbrowser.exe" OR "\\spartan.exe" OR "\\spartan_edge.exe" OR "\\spartan_legacy.exe" OR "\\ucbrowser.exe" OR "\\qqbrowser.exe" OR "\\sogouexplorer.exe" OR "\\icedragon.exe" OR "\\maxthon.exe" OR "\\waterfox.exe")) OR (proc_file_path:"\\iexplore.exe" AND proc_p_file_path:"\\iexplore.exe" AND proc_p_cmdline:*Embedding*) )	Sysmon Event ID 22 EDR DNS Query event
Creation of an executable file by a Microsoft Office application	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 OR *.scr) OR file_magic:4D5A*)	Sysmon Event ID 11 EDR File Create event
Creation of an executable file without an executable extension	T1036: Masquerading	event_type:FileCreate AND file_magic:4D5A* AND -file_path.keyword:(*.msi OR *.ocx OR *.cpl OR *.ax OR *.sys OR *.scr OR *.com OR *.vxd OR *.dll OR *drv OR *.exe OR *.pif)	EDR File Create event
Parent process spoofing	T1502: Parent PID Spoofing	event_type:ProcessCreate AND proc_c_file_path:* AND proc_p_file_path:* AND -proc_file_path:"\\WerFault.exe" AND -(proc_c_file_path:"\\system32\\svchost.exe" AND proc_c_cmdline:(*seclogo* *appinfo* * netsvcs*))	EDR Process Create event
Modification of registry autorun keys using non-standard functions	T1060: Registry Run Keys / Startup Folder	event_type:(RegistryRestore OR RegistryLoad OR RegistryReplace OR RegistryRename) AND reg_key_path:("\\Microsoft\\Windows\\CurrentVersion\\Run" OR "\\Microsoft\\Windows\\CurrentVersion\\RunOnce" OR "\\InprocServer32" OR "\\Windows NT\\CurrentVersion\\Windows" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Image File Execution Options\\" OR "\\Microsoft\\Windows NT\\CurrentVersion\\SilentProcessExit\\" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\GPExtensions\\" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\\Notify\\" OR "\\Microsoft\\Windows NT\\CurrentVersion\\WOW\\Boot\\" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\Run" OR "\\Microsoft\\Windows NT\\CurrentVersion\\Windows\\Load" OR "\\CurrentControlSet\\services\\" OR "\\ControlSet001\\services\\" OR "\\ControlSet002\\services\\" OR "\\ControlSet003\\services\\" OR "\\Control\\Lsa" OR "\\Control\\SecurityProviders" OR "\\Control\\Print\\Monitors\\" OR "\\Control\\Session Manager" OR "\\Microsoft\\NetSh" OR "\\Scripts\\Logon\\" OR "\\Scripts\\Logoff\\" OR "\\Scripts\\Startup\\" OR "\\Scripts\\Shutdown\\")	EDR Registry Restore Key event EDR Registry Load Key event EDR Registry Rename Key event EDR Registry Replace Key event
Creation of a child process via WMI by a Microsoft Office application	T1204: User Execution T1047: Windows Management Instrumentation	event_type:WMICommand AND wmi_command:"*Win32_Process::Create*" AND proc_file_path:("\\excel.exe" OR "\\winword.exe" OR "\\powerpnt.exe" OR "\\mspub.exe" OR "\\visio.exe" OR "\\msaccess.exe")	EDR WMI Command event
Dump of registry hives with user credentials	T1003: Credential Dumping	event_type:RegistrySave AND reg_key_path.keyword:(*\\SAM OR *\\SYSTEM OR *\\SECURITY)	EDR Registry Save Key event
Creation of a LSASS process memory dump	T1003: Credential Dumping	event_type:ProcessAccess AND proc_tgt_file_path:"\\system32\\lsass.exe" AND proc_calltrace:(*dbghelp* OR *dbgcore* OR *MiniDumpWriteDump*)	Sysmon Event ID 10 EDR Process Access event
Creation of registry hive or memory dump files	T1003: Credential Dumping	event_type:FileCreate AND file_magic:(4D444D5093A7* OR 72656766*)	EDR File Create event

Conclusion

This was the final article in this Threat Hunting series. We started with theoretical fundamentals and description of essential components for applying Threat Hunting. Then we transitioned to its practical application and demonstrated how Threat Hunting can be applied in detecting both simple and advanced techniques used by attackers, drawing on the example of potential incidents. Despite these incidents being purely ’synthetic’, the techniques described in the examples are commonly used by threat actors in real-life.

As attackers are becoming more qualified and sophisticated, security specialists are forced to change their habits. If sitting around waiting for the security solutions to trigger an alert was enough in the past, then today this approach may lead to months or even years of unnoticed attackers in the infrastructure. This is why Threat Hunting as a proactive approach to threat detection is becoming increasingly popular.

We hope that our publications have given you some insights into this approach and wish you happy hunting!