BLOG ◆ DEC 01, 2025

Using Cobalt Strike to Find (More) Cobalt Strike

Cobalt Strike, Research, Threat Intelligence

Introduction

In this post, we go into some techniques for using known Cobalt Strike services and the certificates that live on them to find other suspected Cobalt Strike servers. By using a handful of confirmed C2 hosts as a base and looking laterally at every other TLS certificate and service they expose, you can turn a few known data points into a much larger view of the infrastructure behind them.

We begin with the obvious examples: public Malleable C2 profiles that ship with prebuilt HTTPS certificate setups (Gmail, jQuery, Bing, and others) and how their distinguished names appear in internet-wide scan data. From there, we focus on a quirk in how Cobalt Strike generates self-signed certificates, how you can develop small tools to hunt down these quirks, and then talk about a few Cobalt Strike servers running trusted (non-self-signed) certs.

Throughout this post, we will use a mix of Censys Search, the Censys API command-line interface, a bit of Python, and JSON JQ to sort through and extract specific information from host data; however, we will attempt to offer UI-only alternatives where possible.

Pivoting from Known to Unknown Infra

When you are sifting through large volumes of scan data to surface something new, the trick is not to start from scratch. The internet is too large for that approach to be effective. The most reliable method is to anchor your search to something you already know is suspicious, such as a confirmed C2 host, a strange certificate, or an odd protocol banner, and then look at adjacent pieces of data. What else runs on that host? What other services share its certificate history? Which neighbors sit in the same ASN or the same /24?

Pivoting from the known to the unknown is a simple yet effective way to uncover emerging threats. Real infrastructure leaves a trail, and if you follow that trail, it often leads to things the operators did not intend to expose.

For example, we found an odd certificate on a server that also hosted a Cobalt Strike beacon configuration on a different port.

Here, we’re looking at an untrusted TLS certificate purporting to belong to gmail.com, with both the subject_dn and issuer_dn fields set to:

C=US, ST=CA, L=Mountain View, O=Google GMail, OU=Google Mail, CN=gmail.com

This is obviously a forged Gmail certificate. Fake certificates aren’t inherently interesting on their own; anyone with OpenSSL can mint whatever “Google” certificate they want. The important part is that the broader internet doesn’t trust it. In this case, nothing about the certificate itself would be enough to identify threat activity.

But what is interesting is where that certificate appears.

A Censys search for that exact issuer_dn and subject_dn today returns 4 hosts presenting this certificate, as shown in the screenshot below. Note that one of those hosts is running a Cobalt Strike C2 endpoint.

Each of these hosts presents its own version of the certificate, meaning each one has a unique SHA-256 fingerprint, and there are four independently generated fake Gmail certificates deployed across four separate hosts, all of which are running a Cobalt Strike service on a different port.

What matters here is that, with a bit of investigation, you can tie these certificates back to a Malleable C2 profile; specifically, one configured to make Beacon traffic mimic legitimate Gmail web activity.

When you inspect the configuration in the GitHub repository above, every field aligns perfectly with what we see in the found certificates: the Common Name (CN), the Organization (O), and even the validity window. The relevant section of the profile looks like this:

https-certificate {
	set CN       "gmail.com";
	set O        "Google GMail";
	set C        "US";
	set L        "Mountain View";
	set OU       "Google Mail";
	set ST       "CA";
	set validity "365";
}

Another good example of correlating subjects and issuer DNs to a particular known profile is:

C=US, ST=, L=, O=jQuery, OU=Certificate Authority, CN=jquery.com

This same DN appears on 68 distinct hosts in Censys (plus one variant with “C=AU”), and every single one of those hosts is already flagged as running Cobalt Strike. That’s not a coincidence. This fake “jquery[.]com” certificate comes from a publicly available repository that includes a widely used jQuery-themed Malleable C2 profile:

https-certificate {
    set C   "US";
    set CN  "jquery.com";
    set O   "jQuery";
    set OU  "Certificate Authority";
    set validity "365";
}

If we look closely, we can see what’s missing from the above configuration: the ST (State) and L (Location) fields. When those fields are omitted, Cobalt Strike generates a DN with empty values with the keys intact, producing the exact pattern we see in the wild. Every time a server using this profile starts, it generates a new self-signed certificate using these fields.

The intent behind the profile is straightforward: make beacon traffic appear like ordinary browser fetches for a common JS dependency, so the C2 traffic blends into the noise of normal web browsing. But from an internet-scanning perspective, the resulting certificate pattern is pretty distinct.

Turning Malleable C2 Profiles Into Censys Searches

We can even convert other known Malleable C2 profiles into Censys search queries. For example, consider this profile that is designed to make beacons look like Bing search traffic. By pulling the https-certificate stanza from the configuration, we can derive the exact DN it would generate:

https-certificate {
    set CN       "www.bing.com";
    set O        "Microsoft Corporation";
    set C        "US";
    set L        "Redmond";
    set OU       "Microsoft IT";
    set ST       "WA";
    set validity "365";
}

Results in:

C=US, ST=WA, L=Redmond, O=Microsoft Corporation, OU=Microsoft IT, CN=www.bing.com

And that DN can be converted into this Censys search query:

host.services: (
	cert.parsed.issuer_dn = "C=US, ST=WA, L=Redmond, O=Microsoft Corporation, OU=Microsoft IT, CN=www.bing.com" 
	and cert.parsed.subject_dn = "C=US, ST=WA, L=Redmond, O=Microsoft Corporation, OU=Microsoft IT, CN=www.bing.com")

This query returns four hosts on the internet. And just as with the jQuery example, Censys has already identified the services as Cobalt Strike because this certificate pattern is well-known and coupled with public CS configurations.

Hunting for Custom and Modified Cobalt Strike Profiles

So, we know there are at least four hosts using that unmodified publicly available C2 profile—but what if we want to go a step further and proactively identify other potential Cobalt Strike servers? Specifically, ones using modified, or custom Malleable C2 profiles, so maybe we can preemptively block their C2 traffic before it ever reaches an endpoint?

One approach is to start with known Cobalt Strike hosts and examine every certificate they serve. A simple heuristic is to look for certificates where the subject_dn equals the issuer_dn (a good indicator that the certificate was generated by a Malleable profile). Using the Censys CLI and a bit of JQ, we can do the following:

 % cencli search -p -1 '$KNOWN_COBALT_STRIKE_FINGERPRINT' 
  | jq '
      .[] 
      | .host.services[] 
      | select(.cert?.parsed?) 
      | select((.cert.parsed.issuer_dn // "") == (.cert.parsed.subject_dn // "")) 
      | .cert.parsed.issuer_dn
    ' -cr 
  | sort 
  | uniq

This query finds hosts that match a known Cobalt Strike fingerprint, iterates over all TLS-enabled services, and prints the DN of any certificate whose subject and issuer match. Running this with a broad fingerprint, such as ‘host.services.threats.name=”Cobalt Strike”‘ quickly surfaces several suspicious certificates, including:

... snip snip ...
C=AU, ST=, L=, O=jQuery, OU=Certificate Authority, CN=jquery.com
C=china, ST=anhui, L=baidu, O=baidu, OU=development, CN=antladdie.asia
C=CH, ST=Not, L=Yes, O=Cool, OU=DOG, CN=Word
C=CN, L=HangZhou, O=Alibaba (China) Technology Co., Ltd., CN=*.aliyun.com
C=CN, ST=Beijing, L=Beijing, O=Chaitin Co., Ltd., OU=Chaitin
C=CN, ST=Beijing, L=Beijing, O=China Construction Bank, OU=ccb cloud, CN=yun.ccb.com
C=CN, ST=Beijing, L=Beijing, O=Sofaware, OU=360.cn, CN=360
C=CN, ST=Beijing, L=Beijing, O=THU, OU=Tsinghua University, CN=Su San
C=CN, ST=, L=, O=Tencent, OU=Certificate Authority, CN=tencent.com.cn
C=(CN), ST=(SHANGHAI), L=(DONGCHENG), O=(SHANGHAI), OU=(SHANGHAI), CN=(CN)
C=CN, ST=Shanghai, L=Shanghai, O=Example Inc., OU=Web Security, CN=127.0.0.1
C=CN, ST=Shanghai, L=Shanghai, O=Hode Technology (Shanghai) Limited, OU=IT, CN=HD Tech Inc Global CA
C=CN, ST=Shenzhen, L=Guangdong Province, O=Tencent, OU=Tencent Technology (Shenzhen) Company Limited, CN=CN
C=CN, ST=Sichuan, L=Chengdu, O=HEYLINUX, OU=IT, CN=SRE
C=CN, ST=WA, L=Beijing, O=Hao123, OU=Hao123, CN=www.hao123.com
.... snip snip ...

If you don’t want to use the CLI, you can generate an aggregate report from the Censys Platform UI based on a known Cobalt Strike fingerprint and manually review the certificate patterns. Some of the issuer DNs stand out immediately. However, there’s an even more reliable way to hunt for these Cobalt Strike-generated certificates.

The Default Cobalt Strike RDN Fingerprint

One of the best examples that shows how Cobalt Strike generates a self-signed certificate is the certificate that ships with Cobalt Strike itself, it has a SHA-256 fingerprint of:

87f2085c32b6a2cc709b365f55873e207a9caa10bffecf2fd16d3cf9d94d390c

This certificate appears on more than 100 hosts in Censys. Its subject and issuer DN fields look like this:

C=, ST=, L=, O=, OU=, CN=

All of the fields are completely empty; however, it is perfectly valid from an X.509 perspective.

And if we look more closely at the certificates known to be produced by Cobalt Strike, a very clear pattern emerges. The Distinguished Name (DN) always consists of the standard Relative Distinguished Name (RDN) attributes. The values can be arbitrary, but the structure must still conform to the X.509 DN format. Subject and issuer fields can appear in any order and contain any content, as long as they use valid RDN types such as C, ST, L, O, OU, and CN.

However, Cobalt Strike’s certificate generation itself has a tell: it always emits these fields in a fixed order: C → ST → L → O → OU → CN

Even if some values are left blank in the Beacon configuration, the keys still appear (with empty values), resulting in DNs like the one shown above with an empty certificate. This ordering behavior is consistent across different known profiles.

Note: this specific structure and ordering apply only to the self-signed certificates generated by Cobalt Strike itself; an administrator can still generate differently formatted certificates using a third-party tool or by obtaining a valid certificate from a trusted CA. A good example of this is this certificate for fuiedth[.]top, which was found running on a Cobalt Strike service but was, at one point, a legitimate and trusted cert.

Automating the Hunt With the Censys CLI

Knowing that the ordering of the RDN types is consistent with Cobalt Strike, and that CS will generate certificates with matching issuer and subject_dn’s, we can automate a search for other potential suspected certificates using a Python wrapper around the Censys CLI tool to automatically pull out certificates that match Cobalt Strike ordering, and then recursively search those matches for even more certificates from all services that are already associated with Cobalt Strike. The full example script can be found here.

Using the script above, if we run it like this (as a Censys Threat Hunting user):

% python3 findcerts.py --query 'host.services.threats.name = "Cobalt Strike"' --depth 3

The script, with these arguments, identifies 92 distinct certificates whose structure and RDN ordering match the pattern generated by Cobalt Strike’s certificate engine. The following is a small sample of the certificates we found; the full list of DNs is available at this GitHub Gist link.

C=US, ST=California, L=Sacramento, O=Alphabet Inc, OU=Google.com, CN=Google Spider
C=(), ST=(), L=(), O=(Shenzheng Tencent Computer), OU=(未包含在证书中), CN=(www.qqt.com)
C=, ST=, L=, O=, OU=, CN=
C=, ST=, L=, O=, OU=, CN=localhost
C=AS, ST=, L=, O=graphics, OU=body sales, CN=v2.25.org
C=AU, ST=, L=, O=jQuery, OU=Certificate Authority, CN=jquery.com
C=BR, ST=DF, L=Brasília, O=Instituto Nacional do Seguro Social, OU=Tecnologia da Informação, CN=meu.inss.gov.br
C=Bing, ST=Bing, L=Bing, O=Bing, OU=Bing, CN=WWW.Bing.COM
C=CH, ST=Not, L=Yes, O=Cool, OU=DOG, CN=Word
C=CN, ST=, L=, O=Tencent, OU=Certificate Authority, CN=tencent.com.cn
C=CN, ST=BJ, L=BJ, O=BAIDU, OU=BAIDU, CN=www.baidu.com
C=CN, ST=Beijing, L=Beijing, O=China Construction Bank, OU=ccb cloud, CN=yun.ccb.com
C=CN, ST=Beijing, L=Beijing, O=Sofaware, OU=360.cn, CN=360
C=CN, ST=Beijing, L=Beijing, O=THU, OU=Tsinghua University, CN=Su San
C=US, ST=, L=, O=visualstudio, OU=Certificate Authority, CN=login.visualstudio.com
C=US, ST=WA, L=Redmond, O=Microsoft Corporation, OU=Microsoft IT, CN=www.bing.com

Validating Suspected Cobalt Strike Services

So just to recap a little here: we’ve pivoted from known Cobalt Strike services to identifying additional certificates on those same hosts that have suspicious-looking subject_dn and issuer_dn values, all of which follow the same very specific RDN ordering. However, none of these certificates are automatically proof of Cobalt Strike. At this stage, they are simply suspects; certificates with characteristics consistent with Cobalt Strike, but not yet confirmed.

A brief note on how Censys validates suspected Cobalt Strike services: when the scanner believes a service may be Cobalt Strike, it attempts to fetch both the (default) 32-bit and 64-bit Beacon configurations. If retrieval is successful, the scanner parses the configuration and exposes the parsed fields directly in the host details. But this process is not guaranteed to succeed. Configurations may have been relocated, HTTP paths may have been customized, the host may be offline, or the service may simply refuse the request. In practice, the scanner’s outcome typically falls into one of three states:

protocol: HTTP, endpoint_type: COBALT_STRIKE — The scanner successfully retrieved and parsed a Beacon configuration.
protocol: HTTP (no parsed config), label: COBALT_STRIKE — Retrieval was attempted but failed. The host may still be tagged based on other signals, such as known certificate fingerprints or behavioral indicators. (for example, a known certificate fingerprint).
protocol: UNKNOWN (tagged as COBALT_STRIKE) — The scanner could not complete an HTTP handshake. Any Cobalt Strike label was applied indirectly (e.g., fingerprint-based detection) rather than from a successful config fetch.

Note: In most cases, when a service is tagged as Cobalt Strike, but the protocol is UNKNOWN, it is a password-protected Cobalt Strike Team Server.

Case Study: the “Google Spider” Certificate

So, knowing this, let’s look at one of the datapoints from our recursive search above: the hosts that serve the “CN=Google Spider” certificate, which at the time of writing matches 13 hosts. First, we check whether any of the services involved have been successfully scanned as COBALT_STRIKE by generating an aggregation report, setting our “breakdown” field to host.services.protocol, and checking the “Filter results to only records that match my query” option so that we can see what protocols were found on the specific port where this certificate was found.

Here, we see that for the majority of hosts with this certificate, we were unable to determine the underlying protocol, meaning we have no hard evidence that these are Cobalt Strike servers. But there may be evidence in the history of these certificates that may give us some insight. So first, we collect all of the SHA-256 hashes of the currently available certificates by generating an aggregation report on the fingerprints and find that each instance of this issuer_dn has its own unique version:

 0ea352518df75fac18159aa18628d0b66f2be3cddac36365b7947e2bf383f9d6
 31926ef1389e8a982d6f457d890e5d86f63d85c403b42e4f3e0391ad764c0340
 3b0bae2f1a697cbecb2d7524c07940e2ed673f84e84e7be705e03f01f7c44cb4
 3bc7ffb79ff5eda68da6f235ce7242ab98faeac97836f736862089e640151811
 3e7a7ad164363d774cf21662e4abd22319ade83654f6d4bb4d60a3d20dee24c0
 48be78ef234dd25064b640ace4592c7be6854d87d3925e11b18d2b9fcf014f8e
 58e1a450c882b0d4e1520b4bc9ea94bf4e26927d358b91b3c02b5ae4f27217f0
 597ca154190e525ef749047f07eef5201f3a0e2e6140cb30c405d38a4b85ee7e
 9094b82ced1fd5e09d1bce5439aa21b732fdea4831d742bca70c0c7b41d0b201
 9372728b6d3e779b5f99a37c76c40a9bdb6648afbcc7453bfbb24d55abf08468
 999ddda538f930e4b33856f1a1fc8519f9d8272bcffc854d145c252bf8532f53
 a7a2cbeef2f5de6c7e0036645d4af4891dac33f94725a6765fd284ed099b4669
 b9d5067fb8d80d777631871f00c115007c34726ab1b6dd8eff5856a6218b4f9e
 c7cbd6c722dc347274a9db72b67b1ad876e23c8ed869519c4a16be01ad5734d7
 e81db75534212189fba81568fe82497bcf93c4ff7bcee974e8cb55ddc1c7968d

Optionally, if we wanted to collect information on all certificates with this “Google Spider” subject and issuer through all time, not just seen on hosts currently, we can use the Censys CLI and JQ search through the certificate database and gather just the fingerprints:

% censcli search 'cert.parsed.subject_dn="C=US, ST=California, L=Sacramento, O=Alphabet Inc, OU=Google.com, CN=Google Spider" and cert.parsed.issuer_dn="C=US, ST=California, L=Sacramento, O=Alphabet Inc, OU=Google.com, CN=Google Spider"' | 
  jq '.[].certificate.fingerprint_sha256' -cr

We can then iterate over each certificate fingerprint and generate a timeline report to see which hosts, ports, and service types were found running it. The majority of these hosts show up as “unknown” because if you go look at the services in question, you will see the following banner:

Since this is a response from a TLS service (meaning the TLS handshake has already been completed), the “15 03 03 02 02 0A” set of bytes is actually a TLS-layer alert for “Unexpected Message”. This usually means the service is speaking a custom application-layer protocol on top of TLS, which is why the scanner can’t classify it.

And while most of these fingerprints for this “Google Spider” certificate turned up nothing interesting, we found a single service on a single host that was up between 2025-09-04 and 2025-09-22, and during that time, our scanner successfully pulled down and parsed a legitimate Cobalt Strike beacon configuration. Here is a screenshot of that fingerprint’s certificate history:

While the service was short-lived, we now know that this “Google Spider” certificate with the fingerprint “e81db75534212189fba81568fe82497bcf93c4ff7bcee974e8cb55ddc1c7968d” was found running on the host 43[.]156[.]59[.]110:28443 back in September of 2025 (screenshot below):

Seeing this information, we can be pretty sure that this certificate, with this specific structure and matching issuer and subject, relates to Cobalt Strike infrastructure. All it takes is for a threat actor to make one mistake to make this correlation. We can then take this search query for this certificate, feed it through the Censys CLI to generate a list of hosts using JQ:

% cencli search '
  host.services: (
    cert.parsed.subject_dn = "C=US, ST=California, L=Sacramento, O=Alphabet Inc, OU=Google.com, CN=Google Spider"
    and cert.parsed.issuer_dn  = "C=US, ST=California, L=Sacramento, O=Alphabet Inc, OU=Google.com, CN=Google Spider")'-p -1 | jq '.[].host.ip'

140[.]143[.]131[.]180
129[.]226[.]210[.]240
47[.]245[.]53[.]237
154[.]12[.]86[.]154
124[.]221[.]255[.]78
47[.]104[.]159[.]246
120[.]26[.]208[.]69
38[.]190[.]227[.]110
107[.]174[.]67[.]215
106[.]53[.]202[.]250
185[.]243[.]41[.]252
8[.]134[.]166[.]14
47[.]121[.]31[.]109

Matching Suspicious Certs Back to Public C2 Profiles

Not all of the searches for these matching subjects/issuers (historical or otherwise) are this fruitful, as in, there is no history of Censys being able to 100% validate that the certificates in question are Cobalt Strike, but we can do some educated guesses based on the certificate values and match those up with known public Cobalt Strike C2 profiles. Some good examples of this are the two certificates that our script found that include the string “EdgeProxyBAYJune” in the Organizational Unit field:

These two certificates (with over 15 hosts at the time of writing) seem to be modified versions of this OneDrive C2 profile. So we cannot validate via fetching the beacon configuration, but we can validate via prior knowledge.

https-certificate {
    set CN       "mail.live.com"; #Common Name
    set O        "Microsoft Corporation"; #Organization Name
    set C        "US"; #Country
    set L        "Redmond"; #Locality
    set OU       "Outlook EdgeProxyBAYJune2015"; #Organizational Unit Name
    set ST       "Washington"; #State or Province
    set validity "365"; #Number of days the cert is valid for
}

When Hunting Finds Issues in Your Scanner (And How That’s a Win!)

Some of the certificates we discovered with this script looked so suspicious that, after some scrutiny, we actually uncovered a small bug in our Cobalt Strike scanner, which meant our probes were not reaching the next stage to attempt the beacon download. For example, this certificate was found on a single host, but the scanner did not recognize the service running on it as Cobalt Strike; instead, the service entry appeared as a normal HTTP(s) server.

C=TW, ST=, L=, O=CYBERDOCS31, OU=privs IT, CN=v7.04.org

This definitely fits the format and structure, but we were unsure whether it was a true CS server. But after a little debugging, we found the root cause and made a minor update to the scanner, the result of which is a verified Cobalt Strike beacon fetch:

A Small Field Guide to Cobalt Strike Themed Certificates

A non-trivial subset of the certificates we found using this method are essentially cosplay: self-signed certificates claiming to be companies like Microsoft, Google, or other large web properties, but living on random VPS/Cloud ranges and high ports. But some of them are not just vanity; they map directly back to a public Malleable C2 profile. The following is a subset of the discovered certificates broken down by organization/category, along with any links to known public C2 profiles:

Putting It All Together

As a final step, we can automate the whole thing. The Python script above (`findcerts.py`) walks our starting set of verified Cobalt Strike hosts, recursively pulls out every certificate that matches CS’s RDN structure, and prints out each unique subject_dn/issuer_dn pair as a Censys search query. Once we have that list, we can feed every discovered DN back into the Censys CLI to identify all hosts that present those certificates anywhere on the internet (whether or not they have been verified as Cobalt Strike).

Here is that exact pipeline:

% python3 findcerts.py 
  --query 'host.services.threats.name = "Cobalt Strike"' 
  --depth 3 
| grep 'host.services' 
| while read -r line; do
      cencli search -p -1 -f host.ip "$line" 
      | jq -cr '.[].host.ip'
  done 
| sort -u

You can run it on demand or drop it into a cronjob to produce a rolling feed of suspected C2 infrastructure. The output will look something like this (already defanged) here:

101[.]126[.]85[.]120
101[.]132[.]173[.]62
101[.]132[.]71[.]240
101[.]133[.]160[.]80
101[.]200[.]193[.]211
101[.]200[.]198[.]154
101[.]200[.]54[.]84
101[.]200[.]73[.]39
101[.]230[.]104[.]198
101[.]32[.]109[.]112
101[.]32[.]114[.]211
101[.]34[.]205[.]214
101[.]34[.]216[.]106
... snip snip...

This gives you a continually expanding set of IPs tied together not by payloads or network behavior, but by the operators’ own certificate choices. This can be an effective way to surface new Cobalt Strike servers long before their beacon configurations are even retrieved.

Cobalt Strike With Legitimate Certificates.

So far, we’ve talked quite a bit about looking at Cobalt Strike servers with specifically structured untrusted self-signed certificates, but there are instances where Cobalt Strike services live on the internet with completely legitimate, trusted certificates, though these are fairly rare. This rarity may be in part because, if you are going above and beyond with your infrastructure (purchasing certificates), you would presumably spend a good deal of time covering your tracks and hiding the services from the public eye a little better, and as such, these specific categories of Cobalt Strike servers are particularly interesting.

At the time of writing, there are only five hosts on the internet serving up a Cobalt Strike beacon configuration while also serving on a port with a legitimate certificate:

77[.]83.207.217 (eonlinesuccess[.]com)

To start, we can look at 77[.]83.207.217 and see that the certificate is for eonlinesuccess[.]com and was first seen in Google’s Certificate Transparency (CT) logs on 2025-10-03 18:22:16 UTC via the Let’s Encrypt CA, with a validity period of 89 days. The first time that Censys ever observed this certificate being used on an actual Cobalt Strike host was on 2025-11-10T08:16:09Z

The configuration uses several domain names for compromised hosts to beacon out to:

labs[.]eonlinesuccess[.]com
courses[.]eonlinesuccess[.]com
edu[.]eonlinesuccess[.]com

All of which will use the following HTTP GET or POST request along with these specific headers:

GET /assets/677.client.web.22b3dfc0258033253a2b.js
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 Edg/134.0.3124.85
Accept: */*
Accept-Language: en-US,en;q=0.7
Accept-Encoding: gzip, deflate, br, zstd
Connection: keep-alive
Referer: https://www.theguardian.com/
Sec-Fetch-Dest: script
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: cross-site
Cookie: Tbwid="iwfZEczPAowlXG1IHQgl4w"; bwid_withoutSameSiteForIncompatibleClients="idFromPV_gl4w"; GU_geo_country="US"

POST /v2.0/batch/event
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.36 Edg/134.0.3124.85
Accept: */*
Accept-Language: en-US,en;q=0.7
Accept-Encoding: gzip, deflate, br, zstd
content-type: text/plain
Origin: https://www.theguardian.com
Connection: keep-alive
Referer: https://www.theguardian.com/

[{"name":"Pageview","properties":"-","cohorts":["bhig-aw","bhjm-aw","bhmr-aw"]}]

However, this exact certificate was also found running on 45[.]159.79.134 more than a month earlier (2025-10-03) and is still running today. But, the service on that host looks to be completely legitimate, simply returning a 301 redirect back to itself:

This is yet another host we can preemptively block, as it appears to be directly related to the Cobalt Strike server on 77[.]83.207.217, even though it looks legitimate.

The next two Cobalt Strike hosts with legitimate certificates are 88[.]214.50.137 and 88[.]214.50.149; we are grouping these two together because they both sit in the same /24 subnet in Moscow, Russia, in AS216341. In other words, these hosts are most likely related to each other due to their close proximity.

88[.]214.50.137 (softwarecommerce[.]net)

88[.]214.50.137’s beacon attempts to use one of three domain names:

api[.]softwarecommerce[.]net
back[.]softwarecommerce[.]net
backoffice[.]softwarecommerce[.]net

All of which will use the following HTTP GET or POST request, along with these specific headers and payloads:

GET /cdn-cgi/trace
Accept: */*
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.7
Referer: https://www.perplexity.ai/
#Traceparent: 54-414bf88daa606f2c-31
Tracestate: dd=s:1;o:rum
X-Datadog-Origin: rum
X-Datadog-Sampling-Priority: 1
X-Datadog-Trace-Id: b28ced24c4899c2447d

The POST is a little bit more interesting, as it seems to be attempting to mimic a request to “perplexity[.]ai” with an empty query:

POST /rest/autosuggest	
Accept: */*
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.7
Content-Type: application/json
Origin: https://www.perplexity.ai
Referer: https://www.perplexity.ai/

{"query":"","search_mode":"","source_tab_url":""}

88[.]214.50.149 (datasystemconsulting[.]com)

88[.]214.50.149 is a similar Cobalt Strike beacon, even down to the specific technology it tries to mimic: it pretends to be an AI API, this time masquerading as “elevenlabs[.]io” using the domain name “datasystemconsulting[.]com”, again with a legitimate and trusted certificate.

While both of these Cobalt Strike hosts are pretty straightforward in their maliciousness and seem related in more than one way, the gap in the IPs piqued our interest, as we wanted to know whether there was anything suspicious or malicious between or near those two hosts.

For example, if we look at 88[.]214.50.136 today, there is only an SSH service running, but if we look at the historical context, we see that between the dates of 2025-11-09 and 2025-11-17, Censys observed yet another Cobalt Strike server with a valid and trusted certificate for “netsolutionpoint[.]com”. And like the last two hosts, it was again masquerading as an API client for an AI service, this time for “claude[.]ai”:

And if we look at the timeline for this specific certificate (netsolutionpoint[.]com), we can see that it was, and still is running on the host 185[.]219.7.201

The 185[.]219.7.201 host becomes more interesting once you look at its historical service data. Between 2025-08-24 and 2025-09-14, it exposed an RDP service on port 3389 using a certificate with the subject and issuer CN=DESKTOP-NQNIABF. That same RDP certificate metadata appears on 53 other hosts, with 40 of them concentrated in the same autonomous system as 185[.]219.7.201: AS400992, which is registered to an ISP calling itself ZhouyiSat Communications (“hxxps://zhouyitelecom[.]org”). Seeing identical RDP certificates across many hosts usually indicates automated deployment from a shared base image, where each instance inherits the same default hostname, which is reflected directly in the certificate’s Common Name.

AS400992 (ZhouyiSat)

At first glance, the website for ZhouyiSat looks to be pretty legitimate and seems to be an ISP for residential users, where you can even check if they provide services in your area:

But the more you scroll, the less legitimate the website becomes. Their product descriptions are Lorem Ipsum placeholders, and the “About Us” section is blatant filler text:

And just for the memes, their “TV & Streaming” services they provide are quite out of the ordinary:

In other words, the entirety of AS400992 is a fake company posing as a residential internet provider in London, England. In reality, it was established in 2024 and is most likely a front for a Russian bulletproof hosting company. In fact, AS400992 is in Spamhaus’s ASN DROP list due to (allegedly) being owned and operated by known criminals.

So, to recap: we began with two Moscow-based Cobalt Strike servers (88[.]214.50.137 / 88[.]214.50.149), checked the historical context of nearby hosts, and found a third beacon at 88[.]214.50.136 on 2025-11-09. That host reused a certificate pointing us to 185[.]219.7.201, where historical data exposed an RDP certificate shared across dozens of machines—most of them inside AS400992, a so-called “London ISP” that’s actually a criminal-run bulletproof hosting provider.

77[.]83.207.218 (setupcloudos[.]com)

The host 77[.]83.207.218 is currently serving a Cobalt Strike beacon on port 4433, using a valid Let’s Encrypt certificate for setupcloudos[.]com. The beacon configuration rotates between two hostnames: app[.]setupcloudos[.]com and prod[.]setupcloudos[.]com, and attempts to blend in by mimicking traffic to asicminervalue[.]com:

Here are some examples of the beacon traffic it would generate:

GET /_next/static/chunks/4467-ad945db2b9ed2efb.js
Accept: */*
Accept-Language: en-US,en;q=0.6
Accept-Encoding: gzip, deflate, br, zstd
Connection: keep-alive
Referer: https://www.asicminervalue.com/

POST /api/v3/send-form
Accept: */*
Accept-Language: en-US,en;q=0.6
(Accept-Encoding: gzip, deflate, br, zstd
(Referer: https://www.asicminervalue.com/
Content-Type: application/json
Connection: keep-alive

({"ds":{"origins":true,"fmps":58,"asol":""}]}

However, these domain names currently resolve to the IP address 46[.]202.92.109, a host that doesn’t appear to have any malicious history other than having once run the hosting control server “Easypanel” back in August. But if we fast forward a few months in time, we can see that in October of 2025, this same “setupcloudos[.]com” certificate was running on port 443:

This host, like the others we’ve examined, where the beacon configurations pointed to entirely different machines, is a strong hint that things are not as innocent as they seem. Even though these VPS instances look ordinary today and don’t currently expose anything obviously malicious, the fact that active beacon configurations reference their domain names is hard to ignore.

47[.]100.183.39 (fastapi[.]services)

Up until 2025-11-18, this host was running a Cobalt Strike server on port 443 using the default, untrusted CS certificate. But on 2025-11-19, the operator behind the system swapped it out for a fully legitimate certificate for the domain fastapi[.]services:

In the associated beacon configuration, the operator defined four outbound hosts for the Beacon to call home to, all using the same “/jquery-3.3.1.min.js” URI:

163[.]181.77.216
155[.]102.181.184
155[.]102.175.138
163[.]181.228.146

Individually, these systems don’t look malicious at all, but taken in aggregate, they reveal something sort of interesting: all four sit on AS24429, a large Taobao-owned network used as a shared content proxy layer within Alibaba’s wider infrastructure. In other words, these aren’t C2 servers at all; they’re generic front-end proxy servers.

In the Beacon configuration itself, there’s a HostHeader field instructing all outbound requests to present:

Host: www.fastapi.services

The www[.]fastapi[.]services hostname resolves to a CNAME that points to www[.]fastapi[.]services[.]queniuaa[.]com, and the queniuaa.com domain sits inside Alibaba’s CDN infrastructure. In practice, this means the Beacon never talks directly to the real C2 server. Instead, it connects to whichever Taobao/Alibaba edge node is geographically closest, sends its jQuery-themed GET or POST request, and lets the CDN forward that traffic back to the actual Cobalt Strike team server behind fastapi[.]services.

The effect is that the operator uses a real CDN as a redirector mesh. The raw IPs in the C2 list are just entrypoints the CDN happens to route through, not actual command servers. The actual C2 is hidden behind fastapi[.]services and accessed only when the CDN sees the correct Host header.

If we run a search using the Censys certificate database, which also includes data from Certificate Transparency (CT) logs, we’ll see that there was a precertificate issued by GoDaddy on October 18th, 2025, that includes the alt name of “www[.]fastapi[.]services”:

Observing a prescert basically means that the CA logged its “intent” to issue a certificate, but for whatever reason, a deployable certificate was never created or put into use. Precerts always appear in CT logs, even if the issuance process fails or is abandoned. In other words, someone attempted to obtain a legitimate GoDaddy certificate for “www[.]fastapi[.]services”, but for whatever reason, the final certificate never materialized on any host we can observe today. That doesn’t mean one won’t surface later, so it’s worth keeping an eye on this domain for new certificate activity.

Conclusions

None of this is magic. We started with a handful of confirmed Cobalt Strike servers and, by following their certificates, history, and neighbors, ended up with a lot more information about related infrastructure. The primary lesson here is that certificates, CT logs, and scan data are not just metadata; they are connective tissue. If you treat the data as a graph instead of a single field on a host result, you can turn one beacon into a bunch of leads.

At Censys, we regularly run hunts like this to surface, verify, and tag emerging C2 infrastructure so it can be detected, monitored, and accounted for before operators use it in real-world campaigns. A lot of this research can be done with a standard Censys account, but you will miss out on the host tags and parsed C2 configurations without a Threat Hunting upgrade. Learn more about the Censys Threat Hunting Module.

AUTHOR

Mark Ellzey

Senior Security Researcher

Mark Ellzey is a Senior Security Researcher at Censys. Before his current role, Mark has worked as both a network security engineer and software developer for several internet service providers and financial institutions for over 22 years.