The fix was developed at a running pace as Cobalt Strike is essential to Red Team operations


The team behind the Cobalt Strike penetration testing tool has responded to reports of a failed remote code execution (RCE) exploit patch with a new fix.

HelpSystems’ Cobalt Strike enables cybersecurity professionals to simulate attacks with post-exploit agents and is arguably the most popular threat emulation software of its type.

However, the source code of old versions of the licensed software is subject to leaks – the latest of which reportedly took place in 2020.

As a result, Cobalt Strike often surfaces within the arsenal of sophisticated threat actors who use the software to set up command and control (C2) beacons for illicit communication.

Failed fix

Given the importance of this tool and how red teams worldwide rely on Cobalt Strike for their research and cybersecurity audits, the details of the failed patch were kept private until a fix could be released.

On October 17, Rio Sherri, managing security consultant of IBM’s X-Force Red Adversary Simulation team, revealed in a blog post that a patch designed to resolve a known RCE vulnerability had failed.

The vulnerability, tracked as CVE-2022-39197 and issued a CVSS severity score of 6.1, is a cross-site scripting (XSS) issue that allowed remote attackers to execute code without permission on the Cobalt Strike teamserver.


YOU MAY ALSO LIKE Microsoft Office Online Server open to SSRF-to-RCE exploit

It was possible to trigger the bug by inspecting a Cobalt Strike v.4.7 payload and modifying the username field. Alternatively, an intruder could create a new, malicious payload using the extracted information.

A researcher with the pseudonym ‘Beichendream’ privately reported the original security flaw.

HelpSystems published an out-of-band patch for the RCE on September 20. The Cobalt Strike 4.7.1 release added a new property to the teamserver file, which “specifies whether XSS validation is performed on selected Beacon metadata,” according to HelpSystems.

However, after IBM researchers Sherri and Ruben Boonen examined the patch, it transpired that the 4.7.1 update was “insufficient to mitigate the impact of the vulnerability”.

If an attacker created Java Swing components, the researchers found, it was possible to circumvent the fix and create arbitrary Java objects in class paths, as Java Swing will interpret any text as HTML content as long as it begins with an HTML tag. Object tags could then load a malicious payload from the server, which a Cobalt Strike client would subsequently deploy.

Second patch

IBM X-Force notified HelpSystems of its findings privately and requested a new CVE, CVE-2022-42948. The researchers also assisted Cobalt Strike developers in creating a bulletproof patch.

The vulnerability has been resolved in Cobalt Strike v. 4.7.2 via a second out-of-band patch. HelpSystems thanked IBM, noting that the circumvention was caused by the Cobalt Strike interface being built on the Java Swing framework.

While IBM requested a new CVE, HelpSystems did not, noting that the underlying issue is in Java Swing rather than Cobalt Strike as a standalone application.

“We felt that there were parallels between this and the recent log4j vulnerability – thousands of applications that used log4j were vulnerable and yet there aren’t CVEs to cover every single vulnerable application,” commented Greg Darwin, Cobalt Strike software development manager. “It is the same case here, although I appreciate that some people may disagree.”

The Daily Swig has reached out to IBM for clarity on the focus of the new CVE assignment and we will update if and when we hear back.


DON’T MISS Apache Commons Text RCE: Resemblance to Log4Shell but exposure risk is ‘much lower’