Symmetric EncryptionĬobalt Strike uses AES-256 in CBC mode with HMAC-SHA-256 for task encryption. We now have enough information to generate and encrypt our own metadata. The following HTTP request capture shows a metadata blob being sent Base64 encoded in the Cookie header, which is the default setting: In this example, the metadata will be sent Base64 encoded as a Cookie named “user”. The following is from the Cobalt Strike blog example. This allows the operator to customise various properties of the traffic, such as where the metadata blob is sent (.e.g in a header, or a cookie), and how it is encoded. Metadata from the beacon is sent according to the settings in the malleable C2 profile. Beacon Communication Encryption and Metadata Encryption, Decryption and Structure However, if you are in possession of the public key (which can be retrieved via the checksum8 staging URL), then it is possible to encrypt and decrypt taskings via a fake session. In a real-world scenario it is not possible to decrypt existing Beacon communications as the keys are negotiated securely over RSA, with the beacon only having the public key. It should be noted that this is strictly only to aid in debugging whilst writing an exploit. To compile/run this code, you will need set set your classpath to the cobaltstrike.jar file (e.g. Private keys are serialized in a file named “.cobaltstrike.beacon_keys”, in the same folder as the Team Server files. This can be achieved using the following Java code, running on the Team Server. To aid in debugging you may also wish to dump the RSA private key from the Team Server. This is encrypted using the RSA public key, extracted from the stager. Whenever beacon checks in, it sends an encrypted metadata blob. Beacon Checking In – 1.2.3 – Over: Keys Keys Keys. This involves various Cobalt Strike communications and encryption internals we need to understand prior to being able to build an exploit payload. Once decoded and executed, the beacon then needs to communicate with the Team Server. The Internals of Cobalt Strike Beacon Comms This was recently published by the SentinelOne team, who released the CobaltStrikeParser tool. The XOR encoder used will not be discussed in the post as this is a feature of the licensed version of Cobalt Strike.Īfter the DLL is extracted from the stager blob, the beacon settings can be extracted, along with the public key, using a fixed XOR key of 0圆9. This was added as a feature following the official fix for the vulnerability discussed in this post.Īfter the stager shellcode is downloaded, a custom XOR encoder is used to decode the rest of the shellcode, before execution is passed to the decoded beacon DLL. Since Cobalt Strike 3.5.1, you can now also disable staging entirely using the “ host_stage = false” setting. That said, from a Red Team Operational perspective, fully staged (a.k.a Stageless) payloads are always preferred where possible.īy default, Cobalt Strike supports the Meterpreter staging protocol and exposes its stager URL via the checksum8 format. The aim here being to work around size-constrained vulnerability exploitation, for example where you only have a certain amount of space to hold your shellcode as the result of a buffer overflow or similar. Beacon Staging Primerīeacon staging is the process of downloading a beacon (DLL) shellcode blob, which will be executed via a smaller shellcode stager – typically as a result of an exploit or dropper document.
#COBALT STRIKE BEACON DLL PATCH#
A patch was promptly released in the guise of 3.5.1. The vulnerability was disclosed by the team at Cobalt Strike in 2016 as being actively exploited in September. Cobalt Strike 3.5-hf2 (further hardening).Cobalt Strike 3.5-hf1 (hot-fix addressing in-the-wild exploit chain).
![cobalt strike beacon dll cobalt strike beacon dll](https://blog.morphisec.com/hs-fs/hubfs/Blog_images/1-Q1-2019/Cobalt%20strike/CS-img11-750px.png)
In Cobalt Strike there was a vulnerability fixed that existed in a number of versions: We hope that this post will help Blue Teams with detection engineering and provide a good understanding of the encryption fundamentals that underpin Cobalt Strike.įor the Red Team, we provide an example of why it is important to harden your Command and Control infrastructure.
#COBALT STRIKE BEACON DLL CODE#
We then explore the subsequent exploitation of a vulnerability in Cobalt Strike 3.5 from 2016 to achieve remote unauthenticated code execution on the Team Server. This blog looks at some of the communication and encryption internals of Cobalt Strike between Beacons and the Team Server in the 3.5 family. This vulnerability applied to a 5 year old end of life version of CobaltStrike and is being published in the spirit of archaeological interest in the vulnerability.