The default: 63 6f 62 61 6c 74 strike
A brief story regarding cobalt team server operators being lazy AF!
TLDR; Current assessment (using cb_looper) testing cobalt strike C2 beacons have stock standard configurations with minor to no variation in complexity and are easily detected by leveraging the below process flow.
I wanted to see how many cobalt team servers are running out in the wild and analyse said servers for defensive purposes. So I did a quick check with Shodan and identified 6200 endpoints running on approx. 500ish hosts.
ssl.jarm:A07d14d16d21d21d07c42d41d00041d24a458a375eef0c576d23a7bab9a9fb1
For context surrounding how I use cobalt beacons; you can leverage cb_looper within a docker image and automate the extraction of IOC’s into your SIEM or SOAR, enabling you to have defensive actions related to cobalt strike IOC’s. The image below explains the high-level process flow.
I have also stored the latest scan and Shodan extract within my GitLab repository. Link to the repository here. This will enable you to understand this post in greater detail and dashboard/analyse it yourself.
So the first thing we do is run cb_looper against the Shodan export to collect all the major and minor cobalt strike configs exported into a Splunk index for later parsing and analysis.
The below image is the cb_looper log file, and as we can see, we have started to collect major and minor configurations, plus some IP’s do not have enumerable beacon configs.
After looper has finished, we can check to ensure the configurations were extracted and have the correct information we need, as displayed below.
Lets check the Splunk!
As we can see, all the configurations are indexed within Splunk correctly. There are approx. 40 or so fields that contain the data we need (Image was snipped for visibility)
If you are doing this yourself and using Splunk's data models I suggest you rename the fields with spaces and join certain fields like C2, user agent etc.
|rename "x64.config.C2 Server" as x64c2
|rename "x86.config.C2 Server" as x86c2
|rename "x86.config.User Agent" as x86ua
|rename "x64.config.User Agent" as x64ua
|rename "x64.config.Spawn To x86" as x64spwnx86
|rename "x64.config.Spawn To x64" as x64spwnx64
So after I configured all the correct data models, I started analysing the data for this subset of C2 beacons and identified that port:443 was the most popular and port:8443 was the least. It’s also interesting to note that not one of these beacons uses any custom ports.
After that, I wanted to see the main injection processes, as seen below in the code snippet and image.
"%windir%\syswow64\WUAUCLT.exe"
"%windir%\syswow64\WerFault.exe"
"%windir%\syswow64\dllhost.exe"
"%windir%\syswow64\eventvwr.exe"
"%windir%\syswow64\msdt.exe"
"%windir%\syswow64\mstsc.exe"
"%windir%\syswow64\rundll32.exe"
"%windir%\syswow64\spoolsv.exe"
"%windir%\syswow64\svchost.exe -k netsvcs"Then I checked the C2 URLs for both X86 and X64 beacons.
[SNIP]
"121[.]4[.]213[.]91,/push"
"129[.]28[.]201[.]96,/geo/collect/v1"
"164[.]138[.]25[.]191,/resolve/alter/"
"46[.]19[.]37[.]133,/resolve/alter/"
"clubuz[.]com,/us/ky/louisville/312-s-fourth-st[.]html"
[SNIP]User agents used for X64 beacons.
[SNIP]
"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; InfoPath.2; InfoPath.3)"
"Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; BOIE8;ENUS)"
"Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.2)"
"Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko)"
"Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0;) like Gecko"
"Windows-Update-Agent/10.0.10011.16384 Client-Protocol/1.40"
[SNIP]
Finally, I wanted to see if I could create detection methods based on time-based analysis, and I realised most of the beacons use zero jitters, and none of the beacons uses any custom jitter, which is a bit sad :(.
Thanks for reading, and if you have any questions or “positive feedback”, feel free to reach out, and as always…..
