Cobalt Strike Full Version 46
Nichelle Gruger
Cobalt Strike is a threat emulation tool used by red teams and advanced persistent threats for gaining and maintaining a foothold on networks. This blog post will cover the detection of Cobalt Strike based off a piece of malware identified from Virus Total:
NOTE: This feature is not available in the default options file due to potential performance considerations it may have on the Decoder. This feature is experimental and may be deprecated at any time, so please use this feature with caution, and monitor the health of all components if enabling. Also, please look into the customHeader() function prior to enabling this, as that is a less intensive substitute that could fit your use cases.
The purpose for this, amongst others, is that the trial version of Cobalt Strike has a distinctive HTTP Header that we, as analysts, would like to see: -cobalt-strike-trials-evil-bit/. This HTTP header is X-Malware - and with our new option enabled, this header is easy to spot:
NOTE: While this is one use case to demonstrate the value of extracting the HTTP Headers, this metadata proves incredibly valueable across the board, as looking for uncommon headers can help lead analysts to uncover and track malicious activity. Another example where this was useful can be seen in one of the previous posts regarding POSH C2, whereby an application rule was created to look for the incorrectly supplied cachecontrol HTTP response header: -and-control-poshc2
Pivoting off this header and opening the Event Analysis view, we can see a HTTP GET request for KHSw, which was direct to IP over port 666 and had a low header count with no referrer - this should stand out as suspicious even without the initial indicator we used for analysis:
If we had decided to look for traffic using the Service Analysis key, which pulls apart the characteristics of the traffic, we would have been able to pivot of off these metadata values to whittle down our traffic to this as well:
Looking into the response for the GET request, we can see the X-Malware header we pivoted off of, and the stager being downloaded. Also, take notice of the EICAR test string in the X-Malware as well, this is indicative of a trial version of Cobalt Strike as well:
NetWitness Packets also has a parser to detect this string, and will populate the metadata, eicar test string, under the Session Analysis meta key (if the Eicar Lua parser is pushed from RSA Live) - this could be another great pivot point to detect this type of traffic:
Further looking into the Cobalt Strike traffic, we can start to uncover more details surrounding its behaviour. Upon analysis, we can see that there are multiple HTTP GET requests with no error (i.e. 200), and a content-length of zero, which stands out as suspicious behaviour - as well as this, there is a cookie that looks like a Base64 encoded string (equals at the end for padding) with no name/value pairs, cookies normally consist of name/value pairs, these two observations make the cookie anomalous:
Based off of this behaviour, we can start to think about how to build content to detect this type of behaviour. Heading back to our HTTP Lua options file on the Decoder, we can see another option named, customHeaders() - this allows us to extract the values of HTTP headers in a field of our choosing. This means we can choose to extract the cookie into a meta key named cookie, and content-length into a key named http.respsize - this allows us to map a specific HTTP header value to a key so we can create some content based off of the behaviours we previously observed:
After making the above change, we need to add the following keys to our index-concentrator-custom.xml file as well - these are set to the index level of, keys, as the values that can be returned are unbounded and we don't want to bloat the index:
And for the anomalous cookie, we can use the following logic. This will look for no name/value pairs being present and the use of equals signs at the end of the string which can indicate padding for Base64 encoded strings:
Now we can start to track the activity of Cobalt Strike easily in the Investigate view. This could also potentially alert the analyst to other infected hosts in their environment. This is why it is important to analyse the malicious traffic and create content to track:
Cobalt Strike is a very malleable tool. This means that the indicators we have used here will not detect all instances of Cobalt Strike, with that being said, this is known common Cobalt Strike behaviour. This blog post was intended to showcase how the usage of the HTTP Lua options file can be imperative in identifying anomalous traffic in your environment whilst using real-world Live malware. The extraction of the HTTP headers, whilst a trivial piece of information, can be vital in detecting advanced tools used by attackers. This coupled with the extraction of the values themselves, can help your analysts to create more advanced higher fidelity content.
All Eset employs protection-wise at VT is static signature detection for the most part. The only way to fully known if the malware is not actually detected at some stage is to run it. Also if the malware is run in a local sandbox, VM, etc.., that doesn't prove anything since malware these days increasingly deploy anti-sandbox, VM, etc. evasion tactics. That is the malware won't perform any malicious activities.
Since the issue is Cobalt Strike detection here, this article is how to mitigate those attacks: -attack-guides-msp-cobalt-strike-threat-mitigation . The point to note is cmd.exe is deployed is some form in most of these attacks.
I for one monitor all cmd.exe execution; even those I manually initiate via explorer.exe. Most important is to pay attention to cmd.exe startup from a downloaded unknown and untrusted process. Better yet, monitor any process startup running from %Temp% directory and sub-directories.
I found a Cobalt Strike sample that was uploaded to the malware sharing web site on 8/11. Verified on VT that Eset was not detecting the sample with a last analyzed time of 9 hours ago. I also noted that the sample had been previously uploaded to VT on 8/3.
The goal for any Cobalt Strike attack is the deployment of a post-exploitation payload, known as a Beacon,'' onto a compromised endpoint. While some Cobalt Strike attacks can involve executables such as DLL files or libraries being installed on a targeted endpoint, most work by injecting malicious shellcode into legitimate processes. With Cobalt Strike payloads uniquely generated for specific victims and hidden within innocent processes and applications, antivirus solutions that rely on recognizable malicious signatures cannot see or stop them.
Although Cobalt Strike is a command and control (C2) framework, which means that attacks rely on attackers establishing communication with clients installed on targeted machines, analyzing network traffic is not a reliable way of finding and stopping Cobalt Strike Beacons.
As noted, don't rely on a Cobalt Strike beacon signature for stopping future attacks using a modified version of the beacon. This also might explain why it takes so long for Eset to develop a "smart" signature for Cobalt Strike beacon.
The point to note in this instance was the beacon download code was embedded in a .vbs script run from a powershell script. Also, no one at VT detected this malware as Cobalt Strike and all the detections were for the NetSupport RAT vbs script code.
What I have observed is in many of these .exe samples the beacon code is encrypted. Decryption of this code might be occurring via named pipe convention as previously posted. In any case, Eset needs to improve is memory scanning capability in this regard.
Of note is Kaspersky appears to be the only mainstream AV to detect these Cobalt Strike beacons at first sight. What I have observed is its initial detection name is prefixed with "VHO" which is later removed from the detection at VT. I suspect this is Kaspersky's "on-the-fly" signature creation at work which @SeriousHoax commented on in other forum threads. Perhaps its time Eset colaborate with Kaspersky in regards to how its able to detect these beacons.
I have had some DNS hijack incidents of late. To verify I did not not have some malware undetected by Eset, I downloaded and ran Kaspersky's Antivirus Tool (KVRT) and ran a full system scan including all internal hard drives. The only thing KVRT detected was 18 hack tools, POC's, etc. I have accumulated over the years used for testing purposes. Obviously, none of these had been detected by Eset.
Cobalt Strike per se is not malware. It is a legit penetration test tool widely used by computer security audit concerns; an expensive one at that: -plans . The problem with it, as with other like software, is these products always seem to be acquired by hackers.
Eset will not detect hack tools per se. Only Eset can answer why but I suspect it has to do with false positive detection and Eset's aborence of such. If Cobalt Strike detection at first sight is a major concern, one would be better served using Kaspersky or a product that uses its engine which will detect hack tools.
b1e95dc632