Listen to this Post
Introduction:
In the cat-and-mouse game of cybersecurity, the simplest oversight often proves to be an adversary’s undoing. A fundamental tenet of operational security (OPSEC) is that any unique or default identifier—be it a port, a user-agent, or a TLS certificate—is a beacon for defenders. For red teams and malicious actors alike, failing to modify the default X.509 certificates used by command-and-control (C2) frameworks like Cobalt Strike is not just a rookie mistake; it’s a massive gift to threat hunters, instantly exposing their infrastructure to automated detection and manual hunts.
Learning Objectives:
- Understand how default TLS certificates act as high-confidence atomic indicators for identifying Cobalt Strike C2 infrastructure.
- Master the use of network telemetry and certificate hashes to hunt for adversary infrastructure using tools like Elastic, Censys, and Zeek.
- Learn to remediate these OPSEC failures by modifying default certificates and ports to evade detection.
You Should Know:
- The Anatomy of a Default Cobalt Strike Certificate
Cobalt Strike, a commercial penetration testing tool, uses a Java Keystore (JKS) to manage its TLS certificates for team server communications. By default, the team server generates a self-signed certificate with easily recognizable attributes that act as a fingerprint. The certificate’s distinguished name (DN) often contains hardcoded values that are a dead giveaway. For example, the default certificate typically has a subject with attributes such as CN=Major Cobalt Strike, OU=AdvancedPenTesting, and O=cobaltstrike. Furthermore, the hashes of this default certificate are fixed, providing defenders with a robust, static indicator of compromise (IOC). The SHA-256 hash for the default Cobalt Strike team server certificate is 87F2085C32B6A2CC709B365F55873E207A9CAA10BFFECF2FD16D3CF9D94D390C.
This default configuration extends to the network layer. The team server typically listens on TCP port 50050, a port so strongly associated with Cobalt Strike that its very presence on a host is often sufficient to trigger an alert. The combination of a specific port and a default certificate hash creates a powerful, high-confidence signature for threat hunters.
2. Hunting with CenQL and Certificate Hashes
The ability to pivot from a known malicious host to an entire adversary infrastructure is a critical skill. Using certificate hashes is one of the most effective ways to do this. As Chad Saliby’s post demonstrates, a well-crafted CenQL (Censys Query Language) query can pinpoint hosts using default Cobalt Strike certificates.
A direct query for the default certificate’s SHA-256 hash can be structured as follows:
host.services.cert.parsed.fingerprint_sha256="87f2085c32b6a2cc709b365f55873e207a9caa10bffecf2fd16d3cf9d94d390c"
You can also search for the default certificate’s human-readable attributes. For instance, the query in the original post highlights how to look for a specific, albeit fictional, certificate subject:
host.services.cert.parsed.subject.province="Cyberspace" and host.services.cert.parsed.subject.country="Earth" and host.services.port="50050"
In the real world, a more practical query might be:
host.services.cert.parsed.subject.organization="cobaltstrike" and host.services.port="50050"
This type of querying is not limited to Censys. In an Elastic Stack environment, you can hunt for this default certificate using the following KQL (Kibana Query Language) rule, which detects the certificate’s SHA-256 hash in network traffic:
event.category:(network or network_traffic) and tls.server.hash.sha256:87F2085C32B6A2CC709B365F55873E207A9CAA10BFFECF2FD16D3CF9D94D390C
For defenders using Zeek (formerly Bro), a similar signature can be implemented to alert on this certificate hash, providing a network-level detection capability.
3. The Operational Security (OPSEC) Failure
The core issue highlighted by these hunting techniques is a fundamental OPSEC failure. When adversaries—or even less meticulous red teams—deploy Cobalt Strike with its default settings, they are broadcasting their presence to the entire internet. This is often the result of a “cognitive error” where the operator focuses on the complexity of the attack while neglecting the basic “hygiene” of their infrastructure.
As one analysis points out, many operators will modify the team server certificate but fail to change the HTTPS beacon certificate, leaving a critical detection vector open. Others might change the port but leave the certificate untouched, or vice versa. This piecemeal approach to OPSEC is ineffective; a single overlooked default setting can lead to the discovery of the entire C2 infrastructure. By failing to change these defaults, attackers essentially give threat hunters a “massive gift,” making their job of identifying and blocking malicious activity significantly easier.
4. Step-by-Step Guide to Remediation: Hardening Your C2
To avoid this low-hanging fruit detection, it is imperative to modify the default configurations. Here is a step-by-step guide to hardening a Cobalt Strike team server.
Step 1: Modify the Team Server Certificate
The default self-signed certificate for the team server (port 50050) must be replaced. This is done using the Java `keytool` utility.
- Generate a new keystore: Replace `newpass` with a strong password and provide new distinguished name information when prompted.
keytool -keystore new.store -storepass newpass -keypass newpass -genkey -keyalg RSA -alias new_alias
-
Replace the default keystore: Overwrite the default `cobaltstrike.store` file with your newly created `new.store` in the Cobalt Strike directory.
Step 2: Change the Default Team Server Port
The default port, 50050, is a major IOC. This can be modified by editing the `teamserver` script.
- Locate the line in the `teamserver` file that specifies the port, often near the end of the file.
- Change the port number from `50050` to a less common, high-1umbered port (e.g.,
58422).Original line in teamserver java -XX:ParallelGCThreads=4 -Dcobaltstrike.server_port=50050 ... Modified line java -XX:ParallelGCThreads=4 -Dcobaltstrike.server_port=58422 ...
Step 3: Modify the HTTPS Beacon Certificate
The certificate used for HTTPS beacon communication is distinct from the team server certificate. This is controlled by the Malleable C2 profile. The `https-certificate` block within the profile must be configured to use a legitimate or a properly self-signed certificate.
https-certificate {
set C "US";
set CN ".cloudfront.net";
set O "Amazon";
set OU "AWS";
}
For a more robust solution, use a valid SSL certificate from a trusted Certificate Authority (CA) to make the traffic appear fully legitimate.
- Expanding the Hunt: Pivoting from Known to Unknown
The most powerful hunting strategies don’t just look for known IOCs; they pivot from them to uncover hidden infrastructure. As noted by Censys, if you find one suspicious host, you can look at the other services it exposes or other certificates it has used historically.
For example, a threat actor might forge a certificate to impersonate `gmail.com` to make their traffic seem legitimate. While the certificate itself is fake, its presence on a host that also runs a Cobalt Strike beacon is a highly suspicious combination. A pivot query like the one below can uncover these links:
host.services.cert.parsed.issuer_dn="C=US, ST=CA, L=Mountain View, O=Google GMail, OU=Google Mail, CN=gmail.com"
This technique turns a few known data points into a much larger view of an adversary’s entire infrastructure.
What Undercode Say:
- Hunt with Hashes, Not Just Names: Relying on human-readable certificate fields is useful, but hunting with cryptographic hashes (SHA-1, SHA-256) provides a more reliable and high-confidence indicator that is less prone to false positives.
- OPSEC is a System, Not a Checklist: Modifying one default setting while leaving another untouched is a critical failure. True OPSEC requires a holistic review of all components, including ports, certificates, JARM fingerprints, and HTTP headers, to ensure a consistent and evasive profile.
Analysis: The persistence of default Cobalt Strike certificates in the wild underscores a recurring theme in cybersecurity: the human element remains the weakest link. Despite the availability of extensive documentation on how to modify these settings, the convenience of using default configurations often outweighs the perceived risk, leading to operational failures. For defenders, this presents a golden opportunity. By integrating simple, high-fidelity rules based on these default certificates into their SIEM or network monitoring tools, they can achieve a significant return on investment in their threat hunting capabilities. The shift from hunting for “evil” to hunting for “default” is a pragmatic and highly effective strategy that forces adversaries to invest more time and resources into their infrastructure setup, increasing their operational cost and likelihood of making a mistake.
Prediction:
- -1: As automated threat intelligence sharing and AI-driven hunting become more pervasive, the window of opportunity for using default or easily fingerprintable C2 infrastructure will shrink to near zero, forcing a significant evolution in adversary tradecraft.
- +1: This increased pressure will drive innovation in defensive technologies, leading to more sophisticated, automated deception and detection systems that can adapt to new, unknown threats, ultimately strengthening the overall security posture of organizations.
▶️ Related Video (74% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Chadsaliby Over – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
