The previous article detailed the findings of the Cobalt Strike remote-exec built-in command that allows executing arbitrary commands on the remote host without creating a persistent session with a Beacon.

This second part will focus on the jump command in Cobalt Strike, used to establish a connection from a compromised system to the command and control (C2) server. The command allows to remotely access and control the compromised system, and to use it as a pivot point for further attacks on the network. This article will detail lateral movements using the Cobalt Strike Beacon with the following built-in jump commands:

• jump psexec64
• jump winrm64
• jump psexec_psh

The aim here is to provide basic information on the kinds of logs and other artefacts that could be generated from Cobalt Strike on a default Windows 10 host. To get a better context and understanding, we enabled Sysmon on the victim workstation, in order to get a baseline to compare with.

The tests were done with Cobalt Strike version 4.4 with the default configuration, without any kind of customization. It is important to note that Cobalt Strike allows users to change various settings (pipe names, service name, default temporary process, etc.) to customize its footprint. Depending on the Cobalt Strike settings used by the attackers, the events generated may be slightly different and detection rules may fail.

Each command was executed twice to avoid false positives, and the investigations were conducted on one of these two executions. This short analysis can be later on used as a reference to build rules to detect Cobalt Strike movements during a forensics incident response (without Sysmon or Audit Policies).

The Lab is composed of the following elements:

• Windows 10 workstations with Sysmon installed,
• Windows Server 2016 Domain Controller.

The different steps and tools used to extract and analyze the artefacts post compromise are:

1. Run DFIR-Orc to extract artefacts on the Windows 10 machine;
2. Run log2timeline/plaso on the extracted data to build a clear timeline;
3. Analyze data using Splunk or Kibana (ELK fullstack with custom Logstash configuration).

By using DFIR-Orc and Plaso, we were able to process the most important artefacts:

• Event logs (*.evtx), including PowerShell command history;
• Prefetch files among other execution evidence;
• NTFS artefacts, such as USNjrnl and MFT;
• User and System hives (userassist, appcompatcache, etc.).

A summary of the most important findings (excluding Sysmon events) is available in the timeline below. It should be noted that these events alone do not constitute evidence of the use of a Cobalt Strike beacon, and further analysis, some of which is detailed in this article, needs to be conducted to validate or not the hypothesis of remote code execution. These timelines will be detailed and explained in the following chapters.

The Cobalt Strike jump psexec64 command allows the attacker to use the PsExec utility to execute a command or payload on a remote Windows system. When the jump psexec64 command is executed, it will use the active beacon to establish a connection to the specified Windows system, and then use the PsExec utility to run the malicious payload on the remote system. The command uses the psexec64 executable that is included in the Cobalt Strike package to run the command on x64 architectures. The Beacon type used for this test is smb.

Microsoft-Windows-Sysmon

As explained earlier, System Monitor (Sysmon) was installed on the Windows 10 workstation to have reference events on which to base our analyses. We therefore first reviewed the events recorded by Sysmon to get a baseline to compare with the extracted artefacts. The Sysmon events below have been filtered to keep the most useful ones.

Event ID 1 - Process Create

The process creation event provides extended information about a newly created process. The full command line provides context on the process execution. The ProcessGUID field is a unique value for this process across a domain to make event correlation easier.

By default, Cobalt Strike spawns a temporary process and uses rundll32.exe to inject the malicious code into it and communicate the results back to the beacon using named pipes. We can note that rundll32.exe executes without any arguments, which is very suspicious. The process chain created by the jump psexec64 command on the victim workstation is service.exe -> beacon.exe -> rundll32.exe.

Event ID 3 - Network Connection Detected

The network connection event logs TCP/UDP connections on the machine. Each connection is linked to a process through the ProcessId and ProcessGUID fields. The event also contains the source and destination host names, IP addresses, port numbers and IPv6 status.

In both of our tests, 3 connections using IPv4 are made to the victim. The first one on port 445, the second one on port 135 and the last one to a random port. Then, two IPv6 connections are recorded to port 445.

Event ID 7 - Image Loaded

The image loaded event logs when a module is loaded in a specific process. It indicates the process in which the module is loaded, hashes and signature information.

The libraries loaded by the beacon are not very fancy. This information will not be useful without Sysmon installed on the victim workstation.

Event ID 11 - File Create

File create operations are logged when a file is created or overwritten. This event is useful for monitoring autostart locations, like the Startup folder, as well as temporary and download directories, which are common places where malware is dropped during an initial infection.

A randomly named Beacon¹ was created on the file system to the C:\Windows directory by the System process. The two created Prefetch files related to rundll32.exe and the Beacon will be useful to identify Cobalt Strike execution.

Event ID 13 - Registry Value Set

Registry key and value create and delete operations map to this event type.

Cobalt Strike creates a service to run the Beacon as SYSTEM. So a registry key with a random name² is created under HKLM\\System\\CurrentControlSet\\Services\\4542843 by the Services.exe executable and the ImagePath is set to the Beacon path.

Event ID 17 - Pipe Created

Pipe creation operations map to this event type.

The communication between the Beacon and the temporary process (rundll32.exe) is done using named pipes. By default, on Cobalt Strike, the pipes created by binaries use the following format \\.\pipe\MSSE-####-server. Then, the SMB Beacon creates another pipe for the communication with the C2. The default pipe format is \\msagent_##.

Event ID 25 - Process Tampering

Since Sysmon version 13, a new type of event is recorded, called process tampering. This event is generated when a process uses hiding techniques such as hollow or herpaderp. The injection of Cobalt Strike was successfully detected by Sysmon:

Findings

Now that we have seen the events and other artefacts generated by the execution of the jump psexec64 command, let us dwell on the evidence present natively on a Windows 10 system out of the box.

Winevtx - Microsoft-Windows-Security-Auditing

Without the audit policies enabled, not many events are generated. Only two successful logons (event ID 4624) are recorded, with the logon type '3' (Network), from the compromised account "CORP\alice". If correlated, this behavior may help during the investigation to support a hypothesis. The source hostnames are not always recorded, nor is the logon process name.

The two network sessions (logon_type = 3) opened by user "CORP\alice" end a few moments later, just after the remote code execution.

Winevtx - Service Control Manager

In that particular case, since the jump psexec64 command installs a service on the targeted host, the most useful Windows record is the event ID 7045 logged by the Service Control Manager (SCM). This event indicates that a new, randomly named² (here 4542843) service has been installed on the system by user "LocalSystem". The executable used by this malicious service is a strong IOC since it will be remotely accessed using the $ADMIN share. The service terminated unexpectedly a few moments later.

Prefecth - Program execution

The Prefetch files are very useful as well because the beacon has a random name¹ and it is followed by proof of the execution of rundll32³. It is important to mention that the presence of rundll32.exe alone is not necessarily an indication of malicious activity. However, since the beacon name is randomly set by Cobalt Strike for each execution, it is difficult to define a detection rule based on the Prefetch files.

File System - MFT

The main IOC here is the beacon dropped in the $ADMIN share (C:\Windows\) and then executed by the malicious service. The binary itself has no entry in the MFT, but its Prefetch file and that of rundll32.exe are visible when the jump psexec64 command is executed.

In our case, since the system has been freshly installed, rundll32.exe has run for the first time and the birth of the Prefetch file can be observed in the MFT (here in both $FILE_NAME and $STANDARD_INFORMATION of the RUNDLL32.EXE-64292FC9.pf file), otherwise only its modification would be visible.

File System - USN journal

Just like the MFT, and as observed in the SysMon logs (event ID 11), the USN journal can also detect the malicious executable and its Prefetch file. The location of the beacon in the C:\Windows directory makes it easy to spot. The activity of the Prefetch file of rundll32.exe is also recorded. The C:\Windows\4542843.exe binary is deleted immediately after its execution.

Conclusion

The default Cobal Strike jump psexec64 command is fairly easy to detect because it creates a service with a random name² and uses the rundll32.exe³ program without any arguments to host the payload. Even if the malicious binary is deleted immediately after its execution, the location of the beacon in the C:\Windows directory makes it even easier to spot.

Detection Rule Example

The timeline is processed using plaso (https://plaso.readthedocs.io/) on data collected with DFIR-Orc (https://dfir-orc.github.io/). The available fields and their names may vary depending on how you use log2timeline and psort.

Kibana

The various KQL queries correspond to each aspect of the conclusion stated above and can of course be grouped together. The most important is the SCM record (event ID 7045). Note that all these events occur in a short period of time. The name of the beacon can be spotted with the SCM record (event ID 7045) and then used to improve the queries on the MFT and USN journal events.

parser : "winevtx" and source_name : "Service Control Manager" and eid : 7045
parser : "winevtx" and source_name : "Microsoft-Windows-Security-Auditing" and eid : (4624 or 4672 or 4634)
parser : "usnjrnl" and message : \\Windows\\*.exe
parser : ( "prefetch" or "mft" ) and message : *RUNDLL32.EXE*

Splunk

A simple query for installed services (event ID 7045) where the service path contains the ADMIN$ substring is enough:

host="*" index="*" parser=winevtx eid=7045 service_path="*ADMIN$*"
| table _time host message
| sort _time

Sigma

A Sigma rule already exists for this event (sigma/win_cobaltstrike_service_installs.yml at master · SigmaHQ/sigma).

sigma-cli >>> sigma convert -t splunk -p sysmon ../sigma/rules/windows/builtin/system/win_cobaltstrike_service_installs.yml
Parsing Sigma rules  [####################################]  100%
Provider_Name="Service Control Manager" EventID=7045 (ImagePath="*ADMIN$*" ImagePath="*.exe*" OR ImagePath="*%COMSPEC%*" ImagePath="*start*" ImagePath="*powershell*" OR ImagePath="*powershell -nop -w hidden -encodedcommand*" OR ImagePath="*SUVYIChOZXctT2JqZWN0IE5ldC5XZWJjbGllbnQpLkRvd25sb2FkU3RyaW5nKCdodHRwOi8vMTI3LjAuMC4xO*" OR ImagePath="*lFWCAoTmV3LU9iamVjdCBOZXQuV2ViY2xpZW50KS5Eb3dubG9hZFN0cmluZygnaHR0cDovLzEyNy4wLjAuMT*" OR ImagePath="*JRVggKE5ldy1PYmplY3QgTmV0LldlYmNsaWVudCkuRG93bmxvYWRTdHJpbmcoJ2h0dHA6Ly8xMjcuMC4wLjE6*")

The Cobalt Strike jump winrm64 command allows using the Windows Remote Management (WinRM) service to execute a command or payload on a remote Windows system. When the jump winrm64 command is executed, it will use the active beacon to establish a connection to the specified Windows system and then use the WinRM service to run the malicious payload on the remote system. The Beacon type used for this test is smb.

Microsoft-Windows-Sysmon

Event ID 1 - Process Create

The process creation event provides extended information about a newly created process. The full command line provides context on the process execution. The ProcessGUID field is a unique value for this process across a domain to make event correlation easier. The hash is a full hash of the file with the algorithms in the HashType field.

Over the period of time during which the jump winrm64 command is executed, one of the created processes is wsmprovhost.exe by the svchost.exe process. Indeed, since the jump winrm64 command uses the Windows Remote Management (WinRM) service, the wsmprovhost.exe process is started to handle the incoming connection and execute the command or payload.

Event ID 3 - Network Connection Detected

The network connection event logs TCP/UDP connections on the machine. Each connection is linked to a process through the ProcessId and ProcessGUID fields. The event also contains the source and destination host names, IP addresses, port numbers and IPv6 status.

Sysmon recorded 4 network connections to the victim workstation on port TCP\5985 (HTTP default WinRM port) and, since the beacon type used for this test is smb, one more to TCP port TCP\445 (SMB).

Event ID 7 - Image Loaded

The image loaded event logs when a module is loaded in a specific process. It indicates the process in which the module is loaded, hashes and signature information.

This event records the libraries loaded by a process during its execution. Without Sysmon installed on the victim workstation, it is hard to get the same information from other artefacts. However, because in that particular case the MFT artefact was able to get close information, this event is displayed here. The wsmprovhost.exe process (PID 9724) loads 88 DLL and we chose to list only two because of their records in the MFT (see below).

Event ID 11 - File Create

File create operations are logged when a file is created or overwritten. This event is useful for monitoring autostart locations, like the Startup folder, as well as temporary and download directories, which are common places where malware is dropped during an initial infection.

Our malicious wsmprovhost.exe process has the PID 9724. The Cobalt Strike Beacon runs under the context of PowerShell, this is why two PowerShell script files are generated by Microsoft to test against Applocker. If the test file executes, then it assumed that Applocker is disabled.

Event ID 17 / 18 - Pipe Created or Accessed

Pipe creation operations map to these event types when a named pipe is created (event ID 17) and when a named pipe is created or accessed (event ID 18).

The previous spotted processes with PID 4 and 9724 used several names pipes. The created pipe \\msagend_bd is made by the SMB beacon (by default) for the communication with the C2.

Findings

Now that we have seen the events and other artefacts generated by the execution of the jump winrm64 command, let us dwell on the evidence present natively on a Windows 10 system out of the box.

Winevtx - Microsoft-Windows-Security-Auditing

Like the remote-exec winrm command, 5 authentications (event ID 4624) are recorded with the logon type '3' from the compromised account CORP\alice, along with the associated privilege assignment events (event ID 4672). The source IP address and hostname are not always recorded, nor is the logon process name.

The five network sessions (logon_type = 3) opened by user "CORP\alice" end a few moments later, just after the remote code execution.

Winevtx - Microsoft-Windows-WinRM

Obviously, some good indicators to detect WinRM lateral movements are stored in the Microsoft-Windows-WinRM log file, like the event ID 91 (Creating WSMan shell on server) on the target host. This event indicates that the WinRM service has begun to listen for incoming connections on the specified ports (HTTP and HTTPS by default). On our targeted host, this event was the only record in the Microsoft-Windows-WinRM log file after the remote code execution.

Winevtx - PowerShell / Microsoft-Windows-PowerShell

While the process of creating the PowerShell beacon on the remote host is done via the Windows Remote Management (WinRM) service and not via a PowerShell session, you can detect the wsmprovhost.exe process using the PowerShell log files if PowerShell script block logging is enabled.

Unlike the remote-exec winrm command, the jump winrm64 command generates a PowerShell event ID 4104 because the block content was considered as suspicious. Script block logging events are recorded when a user starts a new session using the PowerShell remoting feature and stores blocks of code as they are executed by the PowerShell engine. This allows capturing the full PowerShell Beacon.

N.B.: Starting from PowerShell 5.0, anything that is determined as suspicious by AMSI (Antimalware Scan Interface) will automatically log a Script block/4104 event with a level of Warning⁴.

It is important to note that the event 4104 will be generated only when a user starts a new session using the PowerShell remoting feature, and not when a session is started using the jump winrm64 command in Cobalt Strike. All 29 events 4104 have been merged into a single event in the following timeline.

The recorded payload stored in the event 4104 (and split into 29 pieces of code) contains two functions, func_get_proc_address and func_get_delegate_type. These two PowerShell functions are likely used to dynamically load and execute unmanaged code in a managed environment:

• func_get_proc_address appears to use the Microsoft.Win32.UnsafeNativeMethods class to load a function pointer for a specified procedure in a specified module. This function is commonly used in interop scenarios when calling unmanaged functions from managed code.
• func_get_delegate_type appears to dynamically create a delegate type that can be used to invoke a function with a specified signature. This function may be used in scenarios where a delegate with a specific signature is required but cannot be generated at compile time.

Together, these functions could be used to dynamically load and execute unmanaged code with a specific signature in a managed environment. They will be used by the following scheme (base64-encoded payloads have been removed for more readability):

If ([IntPtr]::size -eq 8) {
    [Byte[]]$var_code = [System.Convert]::FromBase64String("... base64-encoded payload ...")

    for ($x = 0; $x -lt $var_code.Count; $x++) {
        $var_code[$x] = $var_code[$x] -bxor 35
    }

    $var_va = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer((func_get_proc_address kernel32.dll VirtualAlloc)  (func_get_delegate_type @([IntPtr]  [UInt32]  [UInt32]  [UInt32]) ([IntPtr])))
    $var_buffer = $var_va.Invoke([IntPtr]::Zero  $var_code.Length  0x3000  0x40)
    [System.Runtime.InteropServices.Marshal]::Copy($var_code  0  $var_buffer  $var_code.length)

    $var_runme = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer($var_buffer  (func_get_delegate_type @([IntPtr]) ([Void])))
    $var_runme.Invoke([IntPtr]::Zero)
}

The PowerShell script is designed to decode, inject and execute a base64-encoded shellcode in the current process using dynamic memory allocation and function pointers.

1. First, the code checks if the size of IntPtr is 8, which indicates a 64-bit operating system. If the system is running on a 64-bit architecture, the script continues to execute.
2. Next, it converts the base64-encoded payload into a byte array using the [System.Convert]::FromBase64String method and applies a bitwise XOR operation with the value 35 to each byte. This is likely used to obfuscate the payload by applying a simple obfuscation technique.
3. After that, the code retrieves the function pointer for the VirtualAlloc function in the kernel32.dll library using the func_get_proc_address function. It also uses the func_get_delegate_type function to define a delegate type with the appropriate parameters for the VirtualAlloc function. The code uses the Marshal.Copy method to copy the byte array containing the shellcode into the allocated memory.
4. Finally, the code retrieves the function pointer for the shellcode using the Marshal.GetDelegateForFunctionPointer method and creates a delegate of type Void that can invoke the shellcode. The shellcode is then executed by calling the delegate with the Invoke() method. This causes the payload to be executed in memory.

Prefecth - Program execution

Since the wsmprohost.exe process is used by the Windows Remote Management (WinRM) service to handle the incoming connection and execute the command or payload, the Prefecth artefacts can successfully detect the execution of wsmprohost.exe.

It is important to mention that the presence of wsmprovhost.exe alone is not necessarily an indication of malicious activity. The process is a legitimate component of the Windows operating system and is typically used for system management and administration tasks.

File System - MFT

As mentioned earlier in the Sysmon event ID 7, in that case the MFT can be used to get information on the images loaded by the wsmprovhost.exe process. As a matter of fact, accesses to many DLLs can be observed within the MFT.

In our case, since the Windows Remote Management (WinRM) service has run for the first time, the birth of the prefetch file can be observed in the MFT (here in both $FILE_NAME and $STANDARD_INFORMATION of the WSMPROVHOST.EXE-EF06207C.pf file), otherwise only its modification would be visible. It is possible to notice, as expected, that the execution datetime recorded in the Prefetch file occurs 10 seconds before the file itself is created on the file system.

File System - USN journal

Just like the MFT, and as observed in the SysMon logs (event ID 11), the USN journal can also detect the temporary files that are generated by the PowerShell script execution policy stored in the user's directory here: C:\Users\alice\AppData\Local\Temp\__PSScriptPolicyTest_*.

In addition, when PowerShell starts running, the C:\Users\alice\AppData\Local\Microsoft\Windows\PowerShell\ folder is created to store the ModuleAnalysisCache file, created at the same time to store cached information about modules that have been analyzed.

Finally, the USN journal also records the creation of the Prefecth file, C:\Windows\Prefetch\WSMPROVHOST.EXE-EF06207C.pf.

Conclusion

Many artefacts can lead to the conclusion that a beacon has been dropped using WinRM on the victim workstation:

• The WinRM service begins to listen for incoming connections ("Microsoft-Windows-WinRM" event ID 91);
• The PowerShell engine starts ("PowerShell" event ID 400), as well as its providers, hosted by the C:\Windows\system32\wsmprovhost.exe -Embedding application ("PowerShell" event ID 600);
• Thanks to AMSI, PowerShell scriptblock may record the Cobalt Strike Beacon ("Microsoft-Windows-PowerShell" event ID 4104);
• Regarding the file system and execution artefacts, some events could confirm the drop of the beacon, but cannot be used as proof by themselves:
• The wsmprohost.exe executable that is used by the Windows Remote Management (WinRM) service can be seen among the Prefetch files, this file being present in the MFT and in the USN journal;
• Accesses to many DLLs can be observed within the MFT, also recorded by "Sysmon" event ID 7 (Image Loaded);
• PowerShell activities also leave traces in the MFT and the USN journal in the user directory of "CORP\alice".
• Finally, once the proof of execution of the beacon has been established, the origin of the connection can sometimes be recorded by the "Security" event ID 4624 (also with event IDs 4672 and 4634).

Detection Rule Example

The timeline is processed using plaso (https://plaso.readthedocs.io/) on data collected with DFIR-Orc (https://dfir-orc.github.io/). The availablefields and their names may vary depending on how you use log2timeline and psort.

Kibana

The various KQL queries correspond to each aspect of the conclusion stated above and can of course be grouped together. Note that all these events occur in a short period of time.

parser : "winevtx" and source_name : "Microsoft-Windows-WinRM" and eid : 91
parser : "winevtx" and source_name : "PowerShell" and eid : ( 400 or 600 ) and message : *HostApplication=*wsmprovhost.exe*
parser : "winevtx" and source_name : "Microsoft-Windows-PowerShell" and eid : 4104
parser : "winevtx" and source_name : "Microsoft-Windows-Security-Auditing" and eid : (4624 or 4672 or 4634)
parser : "usnjrnl" and message : ( WSMPROVHOST.EXE* or *__PSScriptPolicyTest_* )
parser : "mft" and message : ( *WsmSvc.dll or *atl.dll or *clr.dll or *clrjit.dll or *mscoreei.dll or *mscorlib.ni.dll or *System.Core.ni.dll or *System.ni.dll or *wsmplpxy.dll )
parser : ( "prefetch" or "mft" ) and message : *WSMPROVHOST.EXE*

Splunk

This rule can be the same as the remote-exec winrm command seen in part 1, and focuses on PowerShell and WinRM events only:

host="*" index="*" parser=winevtx eid=91 OR (eid=400 AND  host_application="*wsmprovhost.exe*")
| bin span=15s _time
| eventstats distinct_count(event ID) as dis_count by _time
| where dis_count==2
| table _time eid message dis_count

Sigma

A Sigma rule already exists for this event (sigma/posh_pc_remote_powershell_session.yml at master · SigmaHQ/sigma).

sigma-cli >>> sigma convert -t splunk -p sysmon ../sigma/rules/windows/powershell/powershell_classic/posh_pc_remote_powershell_session.yml
Parsing Sigma rules  [####################################]  100%
HostName="ServerRemoteHost" HostApplication="*wsmprovhost.exe*"

The Cobalt Strike jump psexec_psh command creates a Beacon on the remote host using the psexec and PowerShell techniques. The Beacon type used for this test is smb.

Microsoft-Windows-Sysmon

Event ID 1 - Process Create

The process creation event provides extended information about a newly created process. The full command line provides context on the process execution. The ProcessGUID field is a unique value for this process across a domain to make event correlation easier. The hash is a full hash of the file with the algorithms in the HashType field.

The process chain created by the jump psexec_psh command on the victim workstation is cmd.exe -> powershell.exe. The PowerShell payload is base64 encoded several times, gzip compressed and XOR encrypted (with key "35").

Event ID 3 - Network Connection Detected

The network connection event logs TCP/UDP connections on the machine. Each connection is linked to a process through the ProcessId and ProcessGUID fields. The event also contains the source and destination host names, IP addresses, port numbers and IPv6 status.

In both of our tests, 3 connections are made. The first one on port 135, the second one to a random port and the last one to port 445.

Event ID 11 - File Created

File create operations are logged when a file is created or overwritten. This event is useful for monitoring autostart locations, like the Startup folder, as well as temporary and download directories, which are common places where malware is dropped during an initial infection.

A Prefetch file is generated for each process executed (cmd.exe and powershell.exe) and two PowerShell test scripts generated by Microsoft are created (__PSScriptPolicyTest_<random_number>.ps1):

Event ID 13 - Registry Value Set

Registry key and value create and delete operations map to this event type.

Cobalt Strike creates a service to run the PowerShell command as "SYSTEM". So a registry key with a random name is created under HKLM\\System\\CurrentControlSet\\Services\\4b3d5bc by the Services.exe process and the ImagePath registry key is set to the Beacon path.

Event ID 17 - Pipe Created

Pipe creation operations map to this event type.

The default named pipe created by the SMB Beacon for the communication is \\msagent_## and the default named pipe created for the PowerShell payload staging is \\.\pipe\status_##.

Findings

Winevtx - Microsoft-Windows-Security-Auditing

Without the audit policies enabled, not many events are generated. Only two successful logons (event ID 4624) are recorded, with the logon type '3' (Network), from the compromised account "CORP\alice". If correlated, this behavior may help during the investigation to support a hypothesis. The source hostnames are not always recorded, nor is the logon process name.

The two network sessions (logon_type = 3) opened by user "CORP\alice" end a few moments later, just after the remote code execution.

Winevtx - PowerShell

The jump psexec_pth command generates a PowerShell event ID 4104 because the block content was considered as suspicious. Script block logging events are recorded when a user starts a new session using the PowerShell remoting feature and stores blocks of code as they are executed by the PowerShell engine. This allows capturing the full PowerShell Beacon.

N.B.: Starting from PowerShell 5.0, anything that is determined as suspicious by AMSI (Antimalware Scan Interface) will automatically log a Script block/4104 event with a level of Warning⁴.

It is important to note that the event 4104 will be generated only when a user starts a new session using the PowerShell remoting feature, and not when a session is started using the jump winrm64 command in Cobalt Strike. All 29 events 4104 have been merged into a single event in the following timeline.

The last two PowerShell scriptblocks are similar to the one seen for the jump winrm64 command with the two functions, func_get_proc_address and func_get_delegate_type, which are used to dynamically load and execute unmanaged code with a specific signature in a managed environment.

The first PowerShell scriptblock decodes and decompresses a base64-encoded and gzip-compressed payload, reads the resulting data as a string, and then executes it as a PowerShell command using the IEX cmdlet. This code is the one that appears as an argument to the PowerShell command powershell -nop -w hidden -encodedcommand <base64enc_payload> (running in a hidden window with "NoProfile").

$s=New-Object IO.MemoryStream( [Convert]::FromBase64String("H4sIAAAAAAAA/61W73PaOBP+HP4KfciM7SlQEnJp6E1nym/MC4TEJKHlGEbIMjERFkiywVz7v78rG3P0mrxvZ+4yw0SWdle7zz67K4eqgqOET1SfuxQVHqmQPg/QZS533uC2Qp/QZyPnhQFRelsvZguqZmvByQy7rqBSoj9zZ0Ms8AqZ5xEWsxV3Q0bzKPnQgtQNBbXOznJnyVYYSOzRWYCVH9HZiqpn7kq4yJxU1+sGX2E/mH78WA+FoIFKv4ttqqpS0tWc+VSaFvqGnp6poIXb+ZIShf5E57Nim/E5ZgexuI7JMwRUDVx91uME6wiKzpr5yjT++MOwJoWLabG5CTGTpuHEUtFV0WXMsNB3S184itfUNPo+EVxyTxWf/KB8WXxIvB8kzvdT3w3rENlijSGOt4PUVlMd04DlELCpphgaeTTR902mU/T56M19GCh/RYt2oKjga4eKyCdUFjs4cBm9px6oGRLSFywMC5wQVIUiQJkvoBfxF2qeByFjebA7+VW7U3NAtxm4v6pkniqB1FAJK3/gxK/A0U94k5qDcH7y/oRcFvz9RDAr9z33ClVdyugCKzpTgO8JV3NnZ5NkSSEec8iln+h9QqU86oMTWHER63SOREit6V/5Sa/NNGX+TUMXmdZBJ01P6scnNHnkvjvNnVm5A3v0/mwe+sylQp+/XQ0N6vkBbcQBXvkkI7z5Ws6ox2iCRzETG4CfpnE4oG7jgI6hAZ38rNZc+eqoW0udqxLIuwSvgBLWj86kOTQNO+jTFeCXfgNNzz0oM5pJH0orzm7X35rLdYalzKNhCHVO8sihmFE3j6qB9A9H1VDxZGn85W4/ZMonWKrM3NR6BdLD1XUeQMWEBLILMIycNSU+ZhqVPOr4Lq3Fjr/IXDBexaSOGYOSA0sR5AR2NBaO0pwRbv7v/LCKDlX2as3oCqSTLtRieAE951BRCd3wgrrG/3A7q5O0KDRWGUgnTgMBHMZVHj36QkFfM/I/Ee+fufdji/nBzbqgh0SaSSFOarHS5ZJIEj1cPh2xTJATClBrCb6qYUmvr5ykjZlG+Sbc2HF/eXct2s2o1dl0miP4RfArb1rNXq97v67d90gzvB12Sl3PvrtpXIXb0A5HtVK5VQK5/abd9Ozoln+5CFdXF+7ajgawJz9sOrJhR41q53LDW9cLv3Kwk+rfzbcX87Hd+jBvt646j7Kl5Tt2VGtt6hUO6/d2VOdd0Lu5Xge1rXtFm91rOu6RbVndULzYxf95fNcMB90vJbnsQwxOZU+69UHXLqkPz+VGuzz8uo+5XNrx4LdmuI7Ji1y+xGTpxLejbgxyLy/McWo75/Lr6P3QI5Xglg+2btcut3r10o5u3f3lOhyMRw8vS8cB+WvR4rcPwUa2F1dOyMdbEsH+heO4OxcCi8bxl/IQc3dL9sl+3G/A3adngA8pb9o3HYgrqMU9sfEJYE46/bj3HA+dxKbbjJaX3gcP/C85754u1p0OqWxA/vo5qsUSXzHy4lRunxbjMamoXae2H/bIYE/Kncr7xrgyctig7V3UxnfMfXrobOd3zqDSeAz3mlEeFzAjdrrv/o7gf4EpdOQMMAVIqPffvbN07z6eTM5302zWHr8L8x1YK/+m+ZecRPiEdW8NsD4W8hkzYCMMoayFtLhoHUbJkPtawzRff/28UBFQBi8DeDtkhVdljBM9/N6YQjCK0wE5hQbzAMvy5asrCx0FYeKlMc1Dz0sGxCHCbE5mgh8/foXw8icg9miwUM95VNqVS6WS/n9VsnK/Dkudr2PzaC6vB+SJJ6c3seQm64C+CIMV/RcT8MOl/x9aDV4yY4/QJQ69jpeVMz7ncraHTvalv4cXJN2gm4R7UmGhCks+h+dm0j/Nc2whuzlG5xh9RwUIryrLl/DmFItQN1OUPqG/oS32U8Vv6J4SCk+gQpfPgaUUZqI2nRjRwrD3X1pq1riTCwAA"));IEX (New-Object IO.StreamReader(New-Object IO.Compression.GzipStream($s [IO.Compression.CompressionMode]::Decompress))).ReadToEnd();

Once decoded and decompressed, the payload gives us the PowerShell script that will be executed. The code checks if the operating system is running on a 64-bit architecture and executes a PowerShell script block using a 32-bit PowerShell process if necessary, otherwise it executes the script block in the current process. The payload stored in $DoIt is similar to the one seen for the other ones with the two functions, func_get_proc_address and func_get_delegate_type, used to dynamically load and execute unmanaged code with a specific signature in a managed environment.

Set-StrictMode -Version 2

$DoIt = @'
... PowerShell script ... 
'@

If ([IntPtr]::size -eq 8) {
    start-job { param($a) IEX $a } -RunAs32 -Argument $DoIt | wait-job | Receive-Job
}
else {
    IEX $DoIt
}

Winevtx - Service Control Manager

The beacon runs as a service, so the PowerShell activity seen above is also recorded by the Service Control Manager (SCM) with the installation of a randomly-named¹ service (event ID 7045). Although the randomness of the service name makes writing a detection rule complicated, the mentions of %COMSPEC% and powershell -nop -w hidden -encodedcommand in the program run by the service makes it easier to spot.

Prefecth - Program execution

Since both of the Command Shell and PowerShell consoles are used, two Prefetch files are generated or edited, one for the cmd.exe process and the other for the PowerShell.exe process. In some cases, other Prefetch files may be modified or created depending on the command run by the Cobalt Strike beacon, such as conhost.exe here.

It is important to mention that the presence of the cmd.exe and powershell.exe processes alone is not necessarily an indication of malicious activity.

File System - MFT

No additional information is provided by the MFT, but it confirms the use of the Command Shell and the PowerShell consoles, by modifying not only the Prefetch files, but also the executables.

File System - USN journal

The USN artefacts provide the same information as the Sysmon Event ID 11 (file created). Prefetch files for cmd.exe and powershell.exe are created and a PowerShell test script is generated.

Conclusion

The default Cobalt Strike jump command with psexec_psh is fairly easy to detect because it creates a service with a random name² with an embedded PowerShell command, so many PowerShell logs are generated to capture the full PowerShell staging payload. Unlike the jump psexec64 command, which also uses a service, the payload of the jump psexec_pth command is not dropped on the system but encoded in a PowerShell command.

Detection Rule Example

The timeline is processed using plaso (https://plaso.readthedocs.io/) on data collected with DFIR-Orc (https://dfir-orc.github.io/). The available fields and their names may vary depending on how you use log2timeline and psort.

Kibana

The various KQL queries correspond to each aspect of the conclusion stated above and can of course be grouped together. Note that all these events occur in a short period of time.

parser : "winevtx" and source_name : "Service Control Manager" and  eid : 7045 and message : *%COMSPEC%*powershell*hidden*-encodedcommand*
parser : "winevtx" and source_name : "PowerShell" and eid : ( 400 or 600 ) and message : *HostApplication=powershell*hidden*-encodedcommand*
parser : "winevtx" and source_name : "Microsoft-Windows-PowerShell" and eid : 4104
parser : "winevtx" and source_name : "Microsoft-Windows-Security-Auditing" and eid : (4624 or 4672 or 4634)
parser : "usnjrnl" and message : ( CMD.EXE* or POWERSHELL.EXE* or *__PSScriptPolicyTest_* )
parser : ( "prefetch" or "mft" ) and message : ( *CMD.EXE* or *POWERSHELL.EXE* )

Splunk

Many rules can be created to detect this command.

1. Search for the cmd.exe and powershell.exe Prefetch files;
2. Search for a logon connection followed by a service installation (like the remote-exec psexec rule created in part 1);
3. A mix of rules 1 and 2, etc.

host="*" index="*" parser=winevtx eid=7045 service_path="*%COMSPEC%*"
| table _time host message
| sort _time

Sigma

A Sigma rule already exists for this event sigma/win_cobaltstrike_service_installs.yml at master · SigmaHQ/sigma.

sigma-cli >>> sigma convert -t splunk -p sysmon ../sigma/rules/windows/builtin/system/win_cobaltstrike_service_installs.yml
Parsing Sigma rules  [####################################]  100%
Provider_Name="Service Control Manager" EventID=7045 (ImagePath="*ADMIN$*" ImagePath="*.exe*" OR ImagePath="*%COMSPEC%*" ImagePath="*start*" ImagePath="*powershell*" OR ImagePath="*powershell -nop -w hidden -encodedcommand*" OR ImagePath="*SUVYIChOZXctT2JqZWN0IE5ldC5XZWJjbGllbnQpLkRvd25sb2FkU3RyaW5nKCdodHRwOi8vMTI3LjAuMC4xO*" OR ImagePath="*lFWCAoTmV3LU9iamVjdCBOZXQuV2ViY2xpZW50KS5Eb3dubG9hZFN0cmluZygnaHR0cDovLzEyNy4wLjAuMT*" OR ImagePath="*JRVggKE5ldy1PYmplY3QgTmV0LldlYmNsaWVudCkuRG93bmxvYWRTdHJpbmcoJ2h0dHA6Ly8xMjcuMC4wLjE6*")

The three built-in jump commands tested are fairly easy to detect in a default Windows 10 workstation without any particular audit policies enabled.

The psexec64 and psexec_psh built-in commands are the easiest to detect because they are both executed as a service (with a random name²). For the psexec64 command, the ImagePath service pointed to a binary on the C:\Windows directory (previously copied), and for the psexec_psh command, it pointed to a PowerShell one-liner payload (base64-encoded and gzip-compressed).

The winrm64 built-in command is a little bit harder to detect because it does not use services, but should be fairly easy to detect because the PowerShell event ID 4104 is generated by AMSI and the full PowerShell payload is captured. In addition, a WinRM event (event id 91) is generated to warn that a connection is received.

To detect lateral movements even more efficiently, we advise installing Sysmon with a custom configuration and/or activating the relevant audit policies.

References

• Detecting CONTI Cobalt Strike Lateral Movement Techniques - Part 1 - CYB3RSN0RLAX
• Tool Analysis Result Sheet
• SigmaHQ/sigma: Generic Signature Format for SIEM Systems
• Learn Pipe Fitting for all of your Offense Projects - Cobalt Strike Research and Development
• Sysmon - Windows Sysinternals | Microsoft Docs