Detecting Cobalt Strike: Penetration TestersEven if penetration testers are granted access that circumvents endpoint detections, countermeasures can detect their Cobalt Strike activity in the environment. By: Counter Threat Unit Research Team
The Cobalt Strike threat emulation framework lets legitimate penetration testers emulate threat actors. However, the methods used to access the environment often differ. Threat actors typically use malware to gain initial access to the network and subsequently deploy Cobalt Strike. Penetration testers are often granted access to internal networks and systems so they can test the security and response of the enterprise. As a result, the penetration testers can bypass endpoint countermeasures and security controls that typically detect phishing or malware activity that threat actors use for initial access. Legitimate testing typically assumes that the organization has already been breached.
In one engagement, Secureworks® Counter Threat Unit™ (CTU) researchers observed penetration testers leveraging local administrator access and the Microsoft Build Engine process to compile and execute a Cobalt Strike Beacon payload directly on the host. This process runs every time a user logs onto the system, injecting the Cobalt Strike Beacon payload into the userinit.exe user initialization process. The penetration testers then used Cobalt Strike Beacon to execute the PowerSploit exploitation scripting tool's "Install-ServiceBinary" function to obtain SYSTEM-level privileges. The observed PowerShell commands used the "-nop -exec bypass -EncodedCommand" parameters followed by a Base64-encoded command, which revealed that they were launched from Cobalt Strike Beacon.
The penetration testers deployed Cobalt Strike Beacon to other hosts in the environment. They then used the Rundll32 execution utility to inject shellcode into the svchost.exe service host process on those systems. This technique enabled them to perform remote code execution on the systems via the Windows Management Instrumentation (WMI) service. They used WMI to create persistence via a Microsoft Build Engine service that compiles and executes Cobalt Strike Beacon on these hosts. This action immediately provided the penetration testers with widespread access to the network.
These techniques are not common in enterprise environments. For example, it is not typical developer behavior to compile binaries as a service that are executed every time a user logs in. Nor is it common for developers to compile and execute binaries over the network using WMI. These anomalous behaviors enable CTU™ researchers to develop countermeasures that can reliably detect the abuse of legitimate Windows utilities for nefarious purposes.
Table 1 maps the observed penetration testing techniques to the MITRE ATT&CK® framework.
|Observed activity||MITRE ATT&CK mapping|
Trusted Developer Utilities Proxy Execution: MSBuild
Process Injection: Proc Memory Native API
|Remote code execution||
Command and Scripting Interpreter: PowerShell
Signed Binary Proxy Execution: Rundll32
Windows Management Instrumentation
|Establish persistence||Create or Modify System Process: Windows Service|
|Lateral movement||Remote Services: SMB/Windows Admin Shares|
Table 1. MITRE ATT&CK techniques used by penetration testers.
This engagement illustrates how Cobalt Strike can be deployed without dropper malware and reveals that insecure development practices could add to an attack surface. It is possible to detect deployment attempts regardless of a threat actor's level of access. Accounting for every possible scenario of Cobalt Strike deployment enables network defenders to respond to these incidents. Secureworks Taegis™ XDR countermeasures incorporate this type of intelligence, allowing organizations to rapidly detect and contain intrusions before threat actors can achieve their goals. Preview Taegis XDR to learn more about the tool.
Other posts in this series: