Threat Hunting C2 over HTTPS Connections Using the TLS Certificate

Introduction

As we’ve explored in numerous articles and Malware of the Day posts, there is no shortage of communication protocols threat actors can utilize for C2 communication. And while there is a whole smorgasbord of interesting and unusual protocols like IRC, FTP, ICMP, NTP etc. to choose from, these protocols are mostly confined to specific tasks and functions.

Thus despite the proliferation of new Open-Source projects using unusual protocols, or leveraging application APIs, the vast majority of C2 communication still relies on “the Big Three”: HTTP, HTTPS, and DNS.

Why these three? Well, a good C2 protocol needs two key things: it has to blend in with the traffic on the target network, and it has to be a plausible carrier of data. So choosing to merge in with the deluge of HTTP, HTTPS, or DNS packets is always a safe choice from the attacker’s POV.

And of these three, HTTPS takes the crown. The moment an attacker wraps their C2 communication in HTTPS, everything above the basic network layer (Layer 4) gets encrypted. Just like that, a whole slew of traditional network detection methods that peek into packet content are neutralized.

But, HTTPS has a whole host of other benefits for the discerning attacker. Aside from being one of the busiest, noisiest protocols, most networks see HTTPS traffic going to new and varied IP addresses and domains all day long, so a C2 server doesn’t immediately stick out when it suddenly appears on a network for the first time. And, of course, sending data back and forth is what HTTPS does, so large packets, high data volumes, or fluctuating packet sizes are all part of its normal behavior.

So from an attacker’s POV, HTTPS sounds like the perfect C2 channel, right? And given that a huge chunk of C2 traffic does use HTTPS, it’s clearly a top choice in most environments today. But, from an attacker’s perspective, there’s one major headache that comes with HTTPS, one big hurdle they need to clear to stay hidden: the TLS certificate, also known as the X.509 Certificate.

 

What in the World is an X.509 Certificate?

At its heart, an X.509 certificate is a standardized digital document. Its main job is to tie an identity – like a person, a server, a company, or even a device – to a public key. You can think of it as a digital passport – it’s something you can show online to prove to someone else that you are who you claim to be.

But how can we trust this digital ID? Just like your real-world passport is trusted because it’s issued by a recognized authority (like your country’s government), an X.509 certificate needs to be issued by a trusted third party known as a Certificate Authority (CA) to carry any real weight. CAs are essentially a select group of companies that have built up enough reputation that we implicitly trust them to vouch for the identity information contained in a certificate.

It’s also worth knowing that every certificate is unique and, importantly, they’re all publicly logged. This happens through something called Certificate Transparency (CT) logs. Sites like crt.sh provide an easy way for anyone to search through these logs and see what certificates have been issued.

 

Who Needs to Show Their ID?

Now, just to be clear, in most of our daily online wanderings, it’s not like everyone is constantly demanding to see everyone else’s digital ID. When you type youtube.com into your browser and hit enter, the authentication is typically one-way. The server hosting youtube.com shows its X.509 certificate to your browser.

Your browser then acts like your own personal security officer, checking the certificate to make sure the server is genuinely youtube.com and not some imposter trying to trick you. This is generally called server authentication or, more broadly, TLS authentication, as it’s a fundamental part of the Transport Layer Security (TLS) protocol that HTTPS is built on. The responsibility is on the server to prove its identity to you, the client. You, as the client, usually don’t have to prove anything back.

Though we won’t get into it here, it is worth mentioning that there is another model where both the server and the client present X.509 certificates to each other and validate each other’s identities. This is known as mutual TLS (mTLS), mutual authentication, or two-way TLS.

 

What Else Does This Digital Passport Do?

Unlike your physical passport, an X.509 certificate isn’t just about proving identity. It also serves a critical functional purpose. It securely hands over the public key of the certificate holder. This public key is one half of a cryptographic pair (the other half being the private key, which is kept secret by the certificate holder).

This public key can then be used in a couple of important ways:

1. To encrypt data that’s only meant for the certificate holder. Since only the holder has the corresponding private key, only they can decrypt it.
2. To verify digital signatures created by the certificate holder. If someone signs a piece of data with their private key, anyone with their public key (from the certificate) can verify that the signature is authentic and the data hasn’t been tampered with.

 

The Attacker’s Certificate Conundrum: Where to Get One?

Okay, so we know what an X.509 certificate is, what it does, and that it’s a requirement for HTTPS. If an attacker wants to use HTTPS for their C2 channel, they’re going to need one. So let’s look at the main ways an attacker might try to get their hands on a certificate, and the pros and cons of each from their perspective.

 

Option 1: The DIY Route – Self-Signed Certificates

How It Works:

Imagine an attacker just decides to make their own passport. That’s essentially a self-signed certificate. They generate the certificate themselves without bothering any external, trusted CA. The “Issuer” field in the certificate basically points back to the certificate itself or some made-up entity.

The Upside (for the Attacker):

There are some pretty obvious benefits here. It’s free, it’s instant, and they can crank them out endlessly on demand. Perhaps the biggest perk is that it completely sidesteps any scrutiny from actual CAs, and there’s no paper trail leading back to a legitimate certificate provider.

If It’s So Easy, Why Bother With Using a CA?

Normally, for a public website, using a self-signed certificate is a non-starter. If you tried to visit a website that presented a self-signed cert, your browser would throw up a massive warning page. You can usually click through these warnings (after assuring your browser you know what you’re doing and are prepared for the consequences), but it’s a lot of friction. The average person would bail immediately.

But here’s the C2 twist: the typical browser-server relationship involves two different parties (you and YouTube, for instance). In a C2 scenario, the “client” is the C2 agent (the malware on the compromised machine), and the “server” is the attacker’s C2 server. Both components are part of the same malicious framework, effectively controlled by the attacker. There’s an implicit trust there, or rather, the attacker can program that trust.

So, if an attacker generates a self-signed certificate for their C2 server, they can simply code the C2 agent to specifically accept that particular self-signed certificate, ignoring the fact that no recognized CA vouches for it. The big hurdle most websites face – that most clients won’t connect if the cert isn’t from a trusted CA – just isn’t an issue for the C2 agent itself.

The Downside: The Environment is Watching

This might make it seem like self-signed certs are the perfect solution for C2. Problem solved, right? Nope. Even if the C2 agent application doesn’t care about the dodgy certificate, the environment it’s running in – the target host and network – almost certainly will.

Because even though the actual HTTPS communication is encrypted, the certificates themselves are exchanged before that encryption kicks in. They’re a foundational part of establishing trust and setting up that encrypted channel in the first place. This means that the X.509 certificates of all the external entities that applications on a host connect to are visible and can be scrutinized.

And because legitimate public-facing websites and mainstream software very rarely use self-signed certificates for external communication, their appearance is a glaring anomaly. Intrusion Detection/Prevention Systems (IDS/IPS) and Security Information and Event Management (SIEM) systems can all be set up to flag or outright block TLS handshakes that involve certificates not signed by a recognized CA. The simple absence of a valid CA in the certificate chain is a huge red flag.

It’s for this very reason that most C2 frameworks, if they can help it, try to avoid relying solely on self-signed certificates, at least for C2 servers that need to look somewhat legitimate to network defenses.

So what other options are there?

 

Option 2: The “Freebie” Route – Certificates from Let’s Encrypt, ZeroSSL, etc.

How It Works:

A much more common, and slightly less suspicious-looking, certificate can be obtained from automated CAs like Let’s Encrypt or ZeroSSL. The main hurdle here isn’t getting the certificate itself, but rather proving ownership of a domain name. Once an attacker has control of a domain, they can usually get a Domain Validated (DV) certificate for it automatically, without any human or organizational vetting.

It’s important to note that DV certificates offer the lowest level of validation. They just confirm that the requester controls the domain. They don’t verify the organization behind the domain, unlike Organization Validated (OV) or Extended Validated (EV) certificates. Still, for most everyday HTTPS connections, DV certificates are accepted by browsers and aren’t inherently a red flag.

The Problem Shifts: Getting the Domain

As mentioned, the attacker’s main challenge now becomes acquiring a domain name. This isn’t frictionless. Plus, using a brand-new domain, often called a Newly Registered Domain (NRD), can itself be a security red flag. Attackers have a few tricks up their sleeves here:

• Typo-Squatting: They might register domains that are slight misspellings of legitimate ones, like micr0soft.com instead of microsoft.com. However, really obvious typo-squats (like my example) are increasingly flagged by domain registrars, so attackers need to be more subtle or use less scrupulous registrars.
• Buying Expired Domains: Sometimes, legitimate businesses go bust, and their assets, including domain names, get auctioned off. An attacker could snap up an expired domain, say bobs-vintage-ceiling-fans.com, that has some history and sounds innocuous. This can give their C2 domain a veneer of maturity and legitimacy. The challenge here for attackers is finding suitable expired domains that aren’t already flagged or associated with past malicious activity, and the cost can vary.
• Dynamic DNS (DDNS): DDNS services (like No-IP or DynDNS) let users map a hostname (e.g., myevilc2.ddns.net) to a dynamic IP address that might change frequently. Attackers use this to make their C2 infrastructure more resilient to takedowns based on IP address. They can often get DV certificates for these DDNS hostnames. The downside for them is that many DDNS providers are closely monitored, and connections to DDNS domains are often viewed with higher suspicion by security tools. The rapid IP changes can also be an indicator.

 

The DV Certificate: Just One Piece of the Puzzle

Even with a “valid” DV certificate, attackers aren’t home free. A DV cert isn’t a red flag on its own, but in security, we often look at a constellation of factors. If a connection using a DV certificate also shows other weird behavior (like beaconing, unusual data transfer volumes), or if the WHOIS data for the domain shows suspicious registration patterns or sketchy registrars, it can all add up to a detection.

The Ephemeral Nature of Free DV Certs

Another headache for attackers using free DV certs, especially those from Let’s Encrypt, is their short lifespan – typically 90 days. This means they have to renew them frequently, which increases their operational workload and creates repeated opportunities for defenders to spot them if they’re monitoring CT logs or domain registration patterns.

Popularity Contest

Despite these hurdles, free DV certificates are incredibly common in the C2 world. The ease of automation, zero cost, and the initial appearance of legitimacy make them a go-to for many attackers, from amateurs to more organized groups. The sheer volume of certificates issued by providers like Let’s Encrypt means malicious ones can initially hide in plain sight.

But for more sophisticated attackers, or those with deeper pockets, there’s another, more potent option.

 

Option 3: The “Heist” Route – Stolen or Compromised Certificates

How It Works:

In this scenario, attackers manage to steal the private key and its corresponding legitimate X.509 certificate from a compromised organization. In extremely rare and sophisticated cases, they might even compromise a CA or one of its intermediaries. If an attacker pulls this off, they have a certificate that is genuinely legitimate, trusted, and belongs to an established entity. This makes spotting the malicious traffic based purely on certificate attributes incredibly difficult.

The attackers can operate with much less fear that their certificate will give them away, at least until the compromise is discovered and the certificate is revoked, or it naturally expires.

Hard to Detect, But Not Impossible (For Some)

There isn’t a lot to say about detecting these from the certificate alone, because the certificate is legitimate. Questioning its validity means scrutinizing all certificates, which isn’t usually a practical defense strategy for most. However, organizations with advanced capabilities could look for contextual clues.

For example, if traffic using a legitimate certificate for “BigCorp Inc.” suddenly starts going to an IP address in a country BigCorp has no business with, or if internal systems unexpectedly start communicating with an unusual external service using that cert, it could be an indicator.

The Barrier to Entry: Actually Stealing One

While hard to detect, the good news is that this is also pretty difficult for attackers to achieve consistently. Opportunistic moments might arise, but it’s not a readily available option for most. This means (hopefully!) it’s not something most organizations have to deal with on a regular basis.

Finally, it’s worth a quick trip down memory lane to talk about a technique that, for a while, seemed like the ultimate certificate solution for attackers.

 

Option 4: The “Free Lunch” (Now Mostly Over) – Domain Fronting

How It Worked:

For a few glorious years (for attackers, anyway), attackers had the certificate problem licked using a technique called Domain Fronting. They would use major Content Delivery Networks (CDNs) – think Akamai, Cloudflare, AWS CloudFront, Azure CDN – as redirectors for their C2 traffic. The beauty of this was that their traffic appeared to be going to the highly reputable CDN, and they could leverage the CDN’s own high-reputation certificate for the initial TLS handshake.

The actual C2 destination was hidden inside an HTTP header (like the Host header) that was only read after the TLS connection was established and decrypted at the CDN’s edge. The CDN would then dutifully forward the traffic to the attacker’s real server. So, not only did they hide their server’s true identity behind layers of encryption and redirection, but they also got to present a super-trustworthy certificate from a major CDN during the initial connection.

Why It’s Mostly a Historical Footnote Now:

That free lunch, however, eventually ended. The major cloud providers and CDNs caught on and implemented a simple but devastatingly effective countermeasure: they started enforcing that the “inner” request (the HTTP Host header) matched the “outer” request (the domain indicated in the TLS Server Name Indication – SNI). This, along with other measures to clamp down on free-tier abuse, means that in 2025, Domain Fronting is more of an interesting case study in attacker innovation than a reliable, go-to technique.

 

The Certificate Conundrum: A Goldmine for Defenders

Hopefully, walking through these different ways attackers try to get certificates has highlighted the challenges they face. Each option comes with its own set of trade-offs and, crucially for us as defenders, distinct detection opportunities.

We’ve only scratched the surface so far. Now, I want to really zero in on specific techniques we can use to sniff out suspicious HTTPS connections by looking directly at the X.509 certificate itself. It’s important to note that I’m not going to dive deep into secondary or tangentially related analyses here – things like beaconing analysis, connection fingerprinting, or IP/domain reputation checks. Those are all vital parts of a threat hunter’s toolkit, and it’s implied that any good investigation builds a case by layering multiple pieces of evidence.

To keep this article focused, we’re going to concentrate on what the certificate itself can tell us. What clues can we find embedded within that digital document that might scream “danger!” or at least whisper “hey, look a little closer at this one”?

 

Look at the Certificate Itself: The Obvious First Steps

When you get your hands on a suspicious certificate (or its details from logs), the first thing is to just look at its contents. Many security tools and platforms can parse these for you.

• Is it Self-Signed? This is often the easiest thing to spot. In a self-signed certificate, the Issuer field (who signed it) will be exactly the same as the Subject field (who it’s for). If Issuer: CN=TotallyLegitServerTrustMeBro and Subject: CN=TotallyLegitServerTrustMeBro, you’re likely looking at a self-signed cert. Another clue can be the Authority Key Identifier (AKI) and Subject Key Identifier (SKI) extensions. If the AKI’s keyIdentifier matches the certificate’s own SKI, it’s signing itself.
• If Not Self-Signed, Who Did Sign It? Look at the Issuer field. Is it “Let’s Encrypt”? Is it a major commercial CA like DigiCert or Sectigo? Or is it something you’ve never heard of?

 

These basic initial checks can help to immediately get some sense of the certificate’s legitimacy.

 

Decoding Certificate Fields: Self-Signed vs. Free DV vs. Other CA-Issued

Let’s get a bit more granular with the table below. By examining specific fields, we can find strong clues to differentiate the 3 main categories:

 

Hunting with Certificate Repositories and Timelines

The fact that certificates are publicly logged is a massive boon for us as defenders. Services like Censys, crt.sh, CIRCL, PassiveTotal, and scans.io (which hosts SonarLabs data) trawl these logs and make them searchable.

Imagine you find a suspicious connection. You can take details from the certificate (like the domain name, parts of the subject or issuer, or the certificate’s hash – more on that later) and query these repositories. This is sometimes referred to as “SSL Pivoting,” a concept notably discussed by Mark Parsons (see this excellent talk to learn more). The idea is to use one piece of certificate information to find related infrastructure or activity.

Another useful tactic is looking at the “first seen” and “last seen” data for a certificate or the domains associated with it. If you see a certificate that was only active for a single week but was used by, say, 47 different IP addresses during that time, that’s highly suspicious! Legitimate services don’t usually behave that way. This could indicate an attacker rapidly cycling through infrastructure.

All to say – once you’ve identified a suspicious HTTPS connection and found its certificate, you can consult any of the repositories above to learn much more about its historical use. How long has it been used for? When was it used for the first time? By how many IPs or domains? Who do these IPs/domains belong to? SSL Pivoting can potentially give us an additional layer of intelligence beyond just the details in the certificate itself, which can be very useful to build our case as threat hunters.

 

Spotting “Lean” or Default Certificates

Attackers, especially when using automated tools or if they’re in a hurry, often don’t bother filling in all the optional fields when generating a certificate. They’ll provide the bare minimum required to make the certificate technically valid.

So, a good hunting technique is to look for certificates in your network traffic that are unusually “lean.” For example, search for outbound connections to hosts whose certificates only have the required fields populated, and little else.

You don’t necessarily need a fancy SIEM for this. Tools like Zeek are fantastic for this kind of analysis. Zeek logs incredibly detailed information about TLS handshakes, including all the X.509 certificate fields, into its x509.log file. You can then use command-line tools (like awk, grep, sort) or GUI-based log analysis tools like Zui to wrangle this data. Try for example sorting certificates by the total length of their certificates – the short ones might warrant a closer look.

 

Default Configurations in C2 Frameworks: A Gift to Defenders

Many open-source C2 frameworks come with built-in options to generate certificates, often self-signed ones, typically using something like OpenSSL under the hood or, increasingly, native cryptographic libraries within the C2 framework itself. If attackers use these default generation options without customizing them, the resulting certificates can have very predictable, fingerprintable characteristics.

Let’s look at a couple of examples I found looking at the source code of Sliver and Merlin.

 

Sliver C2 Example:

Sliver, written in Go, uses Go’s crypto/x509 library to generate certificates. If an attacker uses Sliver’s default settings for a self-signed certificate the following fields can all be leveraged for potential detections:

• Subject Information: The CommonName (CN) will be whatever the attacker specifies (e.g., their C2 domain). However, other subject fields like Organization (O), OrganizationalUnit (OU), Locality (L), StateOrProvinceName (ST), and Country (C) are likely to be empty in the default generation process. This is a strong signal.
• Validity Period: The “NotBefore” date (start of validity) is randomized to be within the last year of generation. The certificate will then be valid for either 2 years (730 days) or 3 years (1095 days) from that randomized start date.
• Key Usage/Extended Key Usage (for its self-signed CA certs): Specific combinations like KeyUsageCertSign, KeyUsageKeyEncipherment, KeyUsageDigitalSignature, and EKU ServerAuth, ClientAuth will be present.
• SANs: The CN value will likely be mirrored in the DNSNames or IPAddresses Subject Alternative Name fields.

 

After finding this info in the Sliver source code we can then pivot to Zeek’s x509.log and look for certs where subject.organization, subject.organizational_unit, etc., are NULL/empty, the validity duration is 730 or 1095 days, basic_constraints.ca is true, and the subject.cn is in the SANs.

 

Merlin C2 Example:

Merlin also uses Go’s crypto libraries for certificate generation, and gives us a SOLID detection vector on a silver platter. Merlin’s code includes a function (CheckInsecureFingerprint) that checks against a hardcoded SHA256 hash of a publicly distributed test key pair:

4af9224c77821bc8a46503cfc2764b94b1fc8aa2521afc627e835f0b3c449f50

If an attacker lazily uses this default test certificate, its hash is a dead giveaway since we can simply consult the Zeek x590.log and look for its presence.

 

JA4X: The Certificate’s Unique Fingerprint

JA4X is a component of the JA4+ suite of network fingerprinting standards, specifically designed to fingerprint X.509 TLS certificates. Unlike traditional certificate hashes (like SHA-256) that change if a certificate is reissued even with the same parameters, JA4X focuses on how a certificate is constructed. This makes it more resilient for tracking and identifying related certificates, even if their specific values differ slightly or they are re-issued.

The core idea behind JA4X is to create a fingerprint based on the structural characteristics and patterns within the X.509 certificate. While the exact, detailed algorithm for every component of the JA4+ suite (including JA4X) is proprietary to FoxIO, the general approach involves analyzing various fields and extensions within the certificate and how they are populated or ordered.

 

Conclusion: The Never-Ending Game of Hide and Seek

The shift towards HTTPS for C2 communications has definitely made life harder for us defenders. It cloaks malicious traffic in the guise of legitimate, encrypted web activity. But, as we’ve seen, the TLS certificate – that essential component for setting up this encrypted channel in a way that tries to mimic legitimacy – remains a critical point of friction for attackers, and thus a valuable source of clues for us.

Attackers have come up with various ways to get these certificates, from quick-and-dirty self-signed ones to free DV certs on carefully chosen domains. Each method has its pros and cons for them, but more importantly, each leaves behind a trail of potential evidence. While attackers can program their C2 agents to blindly trust any certificate they throw at them, the characteristics of these certificates, the infrastructure they’re tied to, and the way they’re generated can all be leveraged for threat hunting.

But, as we’ve now gotten used to, attackers will keep refining their tactics for acquiring certificates and deploying their C2 infrastructure – maybe using more sophisticated domain generation, rotating certs more often, or finding new ways to abuse legitimate services.

Thus, it’s up to us as defenders to continue to develop more advanced analytics, share threat intelligence more effectively, and gain deeper visibility into network and endpoint activity. To paraphrase Bob Marley: You can fool some defenders some time, but you can’t fool all the defenders all the time.