It has been discovered by our security researcher that the Cobalt denial of services (DoS) vulnerabilities permit blocking of beacon command-and-control (C2) transmission channels and advanced setups.

Cobalt Strikes is an appropriate penetration testing tool designed to be utilized as an attack framework by red teams (groups of the security professional who act as an attacker on their own organization’s framework to found security flaws and various vulnerabilities).

However, Cobalt Strike is also utilized by threat actors (mostly seen utilized during ransomware attacks) for post-exploitation tasks after setting up so-called beacons, which give them persistent remote access to negotiated devices. Utilizing these beacons, the threat actors can later access the hijacked servers to intake information or set up second-stage malware payloads.

How it Targets on Attackers’ Framework?

SentinelLabs (the team of threat actors at SentinelOne) found the DoS vulnerabilities collectively tracked as CVE-2021-36798 and known as Hotcobalt in the updated version of Cobalt Strike’s server. As they found, one can register fake beacons with the server of a particular Cobalt Strike installation. By transferring fake tasks to the server, one can crash the server by exhausting available memory.

The crash can delivers installed beacons unable to transmit with the C2 server; block new beacons from being installed on penetrating systems, and interfere with currently red team (or malicious) operations that utilized the setup beacons.

“This allow a malicious threat actor causes memory exhaustion on the machine the Cobalt’s server (the ‘Teamserver’) runs on, which creates the server unresponsive until it is restarted,” SentinelLabs said.

“This means that live beacons cannot transmit to their C2 until the operators restart the server. Restarting however, won’t be enough to defend against this vulnerability as it is possible to frequently target the server until it is patched or the beacon’s configuration is changed.”

Since Cobalt Strike is also heavily utilized by threat actors for different vicious purposes, law enforcement and security researchers can also employ the Hotcobalt vulnerabilities to takeoff the malicious framework.

On the 20th of April, SentinelLabs has revealed the vulnerabilities to CobaltStrike’s parent company HelpSystems, who discovered them in Cobalt Strike 4.4, released earlier today. HelpSystems also suggests those who cannot immediately update to the latest Cobalt Strike version to harden their C2 infrastructure by:

• Disabling staging on versions of Cobalt Strike previously to 4.4
• Limiting access to their timeserver framework to only required sources

Disclosure Timeline:

04/20/2021 – Initial contact with HelpSystems for issue disclosure.

04/22/2021 – Issue details disclosed to HelpSystems.

04/23/2021 – HelpSystems confirmed the issue and asked for an extension until August 3rd.

04/28/2021 – SentinelOne accepted the extension.

07/18/2021 – Submitted CVE request to MITRE.

07/19/2021 – CVE-2021-36798 was assigned and reserved for the specified issue.

08/02/2021 – SentinelOne shared the publication date and post for review.

08/02/2021 – HelpSystems reviewed and confirmed the post for publication.

08/04/2021 – HelpSystems released Cobalt Strike 4.4, which contains a fix for CVE-2021-36798.

How do RCE and Source code leak?

This is not the first vulnerability to affect CobaltStrike, with HelpSystems having patched a directory traversal attack vulnerability in the team server in 2016, leading to remote code execution attacks.

In November 2020, our experts also reported that the source code for the Cobalt Strike post-exploitation toolkit had allegedly been leaked in a GitHub repository. 

As new Intel’s Vitali Kremez told our experts at the time, the leak was most likely the re-compiled source code of the 2019 Cobalt Strike 4.0 version.