Considering that the server’s code is written in Java and isn’t very large, it wasn’t too hard to find bugs there.įor example, in the Screenshot and Keylogger task replies, there’s an interesting behavior when reading the reply’s data: public void process_beacon_callback_decrypted(final String beaconID, final byte responseBytes) print('nnFound beacon reply:n', t.decode(req.body, req.headers, params)) We’re not interested in remote code execution vulnerability here as it would be overkill for our purposes. In practice, that vulnerability allowed for remote code execution on the server. A great write-up written by nccgroup is worth reading for a more in-depth understanding of Beacon’s communication internals. The entire process described above is wrapped in the chosen Malleable profile’s transformation steps, which are also embedded in the stager itself.īelow is an example of a popular Malleable C2 profile that masquerades traffic as a normal request for the jquery code ( source): An example of a popular Malleable C2 profile Vulnerabilitiesįirst, it should be noted that there was already one known vulnerability in Cobalt Strike that was previously reported. In short, this feature lets the attacker encode (“transform” in Cobalt’s language) all the beacon’s HTTP communications. One of the most famous features of Cobalt Strike is its Malleable C2. The entire communication flow is explained in the official documentation, but the outline above should suffice for what follows.
#COBALT STRIKE BEACON WHAT IS IT REGISTRATION#
Tasks are encrypted using an AES key sent by the Beacon in the registration request. Receiving tasks generally happens over HTTP GET requests and the Beacon replies with the task data over HTTP POST requests. Tasks can, for example, be used to get a process list, run a command, conduct lateral movement, and many other things of interest to the attacker. From this point, the Beacon works by receiving and replying to “tasks”. We will refer to that part as “Beacon registration”.Īfter the Beacon has registered with the server, the attacker can interact with the Beacon. When a Beacon stager runs, it gathers information about the computer it is running on (CPU architecture, keyboard layout, internal IP, etc.), encrypts that info using the public key, and sends it to the server in an HTTP GET request. We can get the Beacon’s public RSA key by parsing its configuration Every Beacon stager has the public key embedded in it. The first time the Cobalt Strike server runs, it creates randomly generated RSA keys, private and public, stored in a file named “.Cobalt Strike.beacon_keys”.
To understand the vulnerabilities we found, we will briefly cover how Cobalt Strike Beacon communication works. This led us to discover the vulnerabilities reported in CVE-2021-36798 and which we describe below. Given its rampant adoption by red teams and attackers alike, we wanted to better understand the operational security of Cobalt Strike. SentinelOne detects Cobalt Strike Beacon and we are constantly rolling out new ways to detect modifications or novel ways to load Beacon in memory. SentinelOne has seen numerous attacks involving Cobalt Strike Beacons across our customer base. At the same time, many APTs and malicious actors also use it. We have released a new Python library to help generically parse Beacon communication in order to help the research security community.Ĭobalt Strike is one of the most popular attack frameworks designed for Red Team operations.The vulnerabilities can render existing Beacons unable to communicate with their C2 server, prevent new beacons from being installed, and have the potential to interfere with ongoing operations.Versions 4.2 and 4.3 of Cobalt Strike’s server contain multiple Denial of Service vulnerabilities (CVE-2021-36798).
0 kommentar(er)
