Cobalt Strike – Part Two – Kill dates
The data used for this post, and subsequent posts regarding this topic, has been graciously made available by https://hunt.io. The data used in this, and subsequent posts, spans from 2024-01-01 to 2024-05-01.
Featured image is AI generated and has provided us with ‘Coblalt Strkie’.
Introduction
This is the second post in the series, which focuses on Cobalt Strike. This second post will focus on beacons utilizing the feature called a ‘kill date’, and builds on the some of the work covered in part one.
The ‘Kill Date’
Released with Cobalt Strike version 3.4, back in July of 2016, this feature allows the operator to specify a date from which the beacon will neither execute nor wake up from its sleep anymore. By default, the beacon itself checks the kill date every time it wakes up from sleep.
This feature can be quite useful for additional coordination and can suggest a threat actor who plans a bit further than default settings. The kill date is also useful for legitimate red teams, who often run their tests and campaigns within a defined timeframe. There is no need for the beacons to work after the tests have completed.
Additionally, a threat actor might go far and wide in order to reach a specific target within a certain timeframe, but is not interested in making ‘noise’ afterwards. This is where the kill date can help as well.
The kill date allows the operator to ensure that the malware they have deployed is not running after the attack, test, or campaign, is over. This is the essence of everything above.
The data
We will be using the data provided by hunt.io, which was used in part one of this series.
The data contains a total of 2855 unique IPv4 addresses. Of these 2855 addresses, only 51 unique IPs were observed in relation to a Cobalt Strike beacon which had a kill date set.
The overview
The 51 are divided as such:
This is a complely different view than what is observed in the pie chart for the overall data in part one. Here, the US takes up the majority portion, while China, who accounted for 47% of the overall IPs observed in part one, now sits in the bottom next to countries such as Canada and Germany, at 2%.
| Country | ASN | AS Number | Count |
|---|---|---|---|
| United States | AMAZON-02 | 16509 | 32 |
| United States | MICROSOFT-CORP-MSN-AS-BLOCK | 8075 | 5 |
| United States | AMAZON-AES | 14618 | 4 |
| United States | GOOGLE-CLOUD-PLATFORM | 396982 | 2 |
| Canada | MICROSOFT-CORP-MSN-AS-BLOCK | 8075 | 1 |
| China | Hangzhou Alibaba Advertising Co.,Ltd. | 37963 | 1 |
| Germany | aurologic GmbH | 30823 | 1 |
| The Netherlands | CLOUDFLARENET | 13335 | 1 |
| The Netherlands | DIGITALOCEAN-ASN | 14061 | 1 |
| United States | Amazon Data Services Ireland Ltd | 8987 | 1 |
| United States | CLOUDFLARENET | 13335 | 1 |
| United States | 15169 | 1 |
Amazon has two of its ASN’s present in the top three. As such, we will look into the Cobalt Strike beacons with kill dates found from there to provide the biggest sample size possible.
Enriching the data
First, we want to find similarities in order to cluster events together and to identify the ones that are not part of the same campaign. As this post is about the kill date, we will start there. A few more parameters will be added to the table below, such as the country and ASN, as we already know those based on the table above.
Additionally, as the sample size is at 51 unique IPs in total, the watermark will be added as well. This is done to see if we are dealing with the same cracked versions which topped the lists in part one, before we start narrowing down the data to specific cases utilizing the kill date.
| Kill Date | Watermark | Country | ASN | AS Number | count |
|---|---|---|---|---|---|
| 20240224 | 589039153 | United States | AMAZON-02 | 16509 | 16 |
| 20240223 | 589039153 | United States | AMAZON-02 | 16509 | 12 |
| 20240615 | 1862346740 | United States | AMAZON-02 | 16509 | 3 |
| 20231217 | 1320252345 | United States | MICROSOFT-CORP-MSN-AS-BLOCK | 8075 | 1 |
| 20240124 | 876428004 | United States | MICROSOFT-CORP-MSN-AS-BLOCK | 8075 | 1 |
| 20240210 | 147270522 | United States | MICROSOFT-CORP-MSN-AS-BLOCK | 8075 | 1 |
| 20240210 | 223578096 | The Netherlands | CLOUDFLARENET | 13335 | 1 |
| 20240210 | 223578096 | United States | CLOUDFLARENET | 13335 | 1 |
| 20240210 | 223578096 | United States | GOOGLE-CLOUD-PLATFORM | 396982 | 1 |
| 20240210 | 984639906 | United States | AMAZON-AES | 14618 | 1 |
| 20240215 | 553035448 | United States | AMAZON-02 | 16509 | 1 |
| 20240223 | 589039153 | United States | AMAZON-AES | 14618 | 1 |
| 20240224 | 589039153 | United States | AMAZON-AES | 14618 | 1 |
| 20240228 | 666666666 | China | Hangzhou Alibaba Advertising Co.,Ltd. | 37963 | 1 |
| 20240304 | 1014613486 | United States | Amazon Data Services Ireland Ltd | 8987 | 1 |
| 20240315 | 1240897686 | United States | 15169 | 1 | |
| 20240410 | 1288869938 | Canada | MICROSOFT-CORP-MSN-AS-BLOCK | 8075 | 1 |
| 20240419 | 589039153 | United States | AMAZON-AES | 14618 | 1 |
| 20240601 | 1744770244 | United States | MICROSOFT-CORP-MSN-AS-BLOCK | 8075 | 1 |
| 20240601 | 1981887466 | United States | MICROSOFT-CORP-MSN-AS-BLOCK | 8075 | 1 |
| 20250920 | 987654321 | The Netherlands | DIGITALOCEAN-ASN | 14061 | 1 |
| 20251231 | 987654321 | United States | GOOGLE-CLOUD-PLATFORM | 396982 | 1 |
| 20291230 | 0 | Germany | aurologic GmbH | 30823 | 1 |
The kill date is read in yyyy-mm-dd, which puts the top result, by count, at February 24th, 20240224. Interestingly, the second result is the day prior – February 23rd, 2024. They came from the same ASN, in higher numbers than all others, and they share the same watermark.
A dive in deeper and a focus specifically on this, metrics from part one of the series will be added, such the sleep, jitter, and spawnto’s:
| Kill Date | Watermark | Country | ASN | AS Number | Sleep (ms) | Jitter (%) | Spawnto (x64) | User Agent | count |
|---|---|---|---|---|---|---|---|---|---|
| 20240224 | 589039153 | United States | AMAZON-02 | 16509 | 5000 | 44 | %windir%sysnativewermgr.exe | Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko | 16 |
| 20240223 | 589039153 | United States | AMAZON-02 | 16509 | 5000 | 0 | %windir%sysnativewermgr.exe | Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko | 12 |
| 20240223 | 589039153 | United States | AMAZON-AES | 14618 | 5000 | 0 | %windir%sysnativewermgr.exe | Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko | 1 |
| 20240224 | 589039153 | United States | AMAZON-AES | 14618 | 5000 | 44 | %windir%sysnativewermgr.exe | Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko | 1 |
| 20240419 | 589039153 | United States | AMAZON-AES | 14618 | 5000 | 0 | %windir%sysnativewermgr.exe | Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko | 1 |
A few things can be concluded from the table above:
- A custom sleep time of ‘5000’ (5 seconds) is set across the board
- Beacons with a kill date of ‘20240224’ have a custom jitter value of 44% set (2.8 to 7.2 seconds variance)
- Beacons with a kill date of ‘20240223’ use standard jitter
- Beacons use Windows Error Report Manager (wermgr.exe) as their spawnto’s
- The same user agent is used in all instances
- An outlier exists in the bottom entry, with the kill date set to ‘20240419’.
Adding it all up
More fields are added:
| Kill Date | Watermark | Country | ASN | AS Number | hostname | Domains | Submit URI | Sleep (ms) | Jitter (%) | Spawnto (x64) | User Agent | count |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 20240224 | 589039153 | United States | AMAZON-02 | 16509 | d2zp39t2eezbsc.cloudfront.net | d2zp39t2eezbsc.cloudfront.net,/s/ref=nb_sb_noss_1/167-3294888-0262949/field-keywords=books,dmobd90auod5w.cloudfront.net,/s/ref=nb_sb_noss_1/167-3294888-0262949/field-keywords=books | /N4215/adj/amzn.us.sr.aps | 5000 | 44 | %windir%sysnativewermgr.exe | Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko | 9 |
| 20240223 | 589039153 | United States | AMAZON-02 | 16509 | d1dg7ete2wkysb.cloudfront.net | d1dg7ete2wkysb.cloudfront.net,/s/ref=nb_sb_noss_1/167-3294888-0262949/field-keywords=books,dde7q711skl5j.cloudfront.net,/s/ref=nb_sb_noss_1/167-3294888-0262949/field-keywords=books | /N4215/adj/amzn.us.sr.aps | 5000 | 0 | %windir%sysnativewermgr.exe | Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko | 7 |
| 20240224 | 589039153 | United States | AMAZON-02 | 16509 | dmobd90auod5w.cloudfront.net | d2zp39t2eezbsc.cloudfront.net,/s/ref=nb_sb_noss_1/167-3294888-0262949/field-keywords=books,dmobd90auod5w.cloudfront.net,/s/ref=nb_sb_noss_1/167-3294888-0262949/field-keywords=books | /N4215/adj/amzn.us.sr.aps | 5000 | 44 | %windir%sysnativewermgr.exe | Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko | 7 |
| 20240223 | 589039153 | United States | AMAZON-02 | 16509 | dde7q711skl5j.cloudfront.net | d1dg7ete2wkysb.cloudfront.net,/s/ref=nb_sb_noss_1/167-3294888-0262949/field-keywords=books,dde7q711skl5j.cloudfront.net,/s/ref=nb_sb_noss_1/167-3294888-0262949/field-keywords=books | /N4215/adj/amzn.us.sr.aps | 5000 | 0 | %windir%sysnativewermgr.exe | Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko | 5 |
| 20240223 | 589039153 | United States | AMAZON-AES | 14618 | d1dg7ete2wkysb.cloudfront.net,/s/ref=nb_sb_noss_1/167-3294888-0262949/field-keywords=books,dde7q711skl5j.cloudfront.net,/s/ref=nb_sb_noss_1/167-3294888-0262949/field-keywords=books | /N4215/adj/amzn.us.sr.aps | 5000 | 0 | %windir%sysnativewermgr.exe | Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko | 1 | |
| 20240224 | 589039153 | United States | AMAZON-AES | 14618 | d2zp39t2eezbsc.cloudfront.net,/s/ref=nb_sb_noss_1/167-3294888-0262949/field-keywords=books,dmobd90auod5w.cloudfront.net,/s/ref=nb_sb_noss_1/167-3294888-0262949/field-keywords=books | /N4215/adj/amzn.us.sr.aps | 5000 | 44 | %windir%sysnativewermgr.exe | Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko | 1 | |
| 20240419 | 589039153 | United States | AMAZON-AES | 14618 | elouled.com | d2b1kkysr1xybx.cloudfront.net,/s/ref=nb_sb_noss_1/167-3294888-0262949/field-keywords=books,d1l8orgowmcfdk.cloudfront.net,/s/ref=nb_sb_noss_1/167-3294888-0262949/field-keywords=books | /N4215/adj/amzn.us.sr.aps | 5000 | 0 | %windir%sysnativewermgr.exe | Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko | 1 |
Pardon the formatting. I, unfortunately, stand by this.
Again, some observations:
- Beacons with a kill date of ‘20240224’ use d2zp39t2eezbsc.cloudflare[.]com and dmobd90auod5w.cloudfront[.]net to serve the beacon and for C2.
- Beacons with a kill date of ‘20240223’ use d1dg7ete2wkysb.cloudflare[.]net and dde7q711skl5j.cloudfront[.]net to serve the beacon and for C2.
- Beacon with a kill date of ‘20240419’ remains an outlier and uses a different domain to serve the beacon from than its C2 servers, which are hosted on Cloudflare domains.
- The domains use the same http-get value – ‘/s/ref=nb_sb_noss_1/167-3294888-0262949/field-keywords=books’
- The domains use the same http-post value (submit uri) – ‘/N4215/adj/amzn.us.sr.aps’
Both strings are unique enough for an online search, which finds the following C2 profile on Github
https://github.com/rsmudge/Malleable-C2-Profiles/blob/master/normal/amazon.profile
Here, we see everything we have observed so far, such as:
- The sleep value set to 5000
- The jitter value at 0
- The user agent set to ‘Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko’
- The ‘set uri’ under ‘http-get’ match the long string above
- The ‘set uri’ under ‘http-post’ match the other string above
Additionally, we can now verify some of the data we have not yet touched from our dataset against the Amazon profile. Within the parsed beacon configuration, some Base64-encoded values are present, which represent the ‘client‘ and ‘server‘ parts of the profile.
Here’s a partial overview of what the parsed config contains regarding the ‘http-post’ from the dataset:
This base64 encoded data translates to:
Properly formatted, it presents as such, which is identical to what is presented in the Amazon profile on Github:
Accept: /
Content-Type: text/xml
X-Requested-With: XMLHttpRequestHost:
d2zp39t2eezbsc.cloudfront.net
sz=160x600oe=
oe=ISO-8859-1;
sns=3717
dc_ref=http%3A%2F%2Fwww.amazon.comSumming up
We can conclude that beacons with kill dates:
- Can provide a unique starting point
- Are not common, as this is only present in 1.8% of beacon configurations parsed in this dataset
- Are mostly associated with cloud providers, such as Microsoft, Google, and Amazon
- Are mostly observed on US infrastructure
By now we know the following about the actor:
- The actor is using kill dates in February 2024 is using a default Amazon profile grabbed off Github.
- The actor uses the watermark ‘589039153’.
- The actor uses AWS (Cloudfront) infrastructure both for serving the beacon as well as C2
- The actor has an outlier that does not use an AWS Cloudfront domain.
- The actor uses a more uncommon spawnto process in ‘wermgr.exe’. In the whole dataset, this actor accounts 31 out of the 32 instances of ‘wermgr.exe’ use.