TLS/SSL Hunting Without Decryption

Somewhere north of 90% of enterprise traffic runs over TLS now, and that’s exactly why “just inspect the payload” stopped being a viable hunting strategy years ago. Decrypting everything at scale is expensive, legally complicated in a lot of jurisdictions, and increasingly defeated by certificate pinning anyway. The good news, and it’s genuinely good news, is that TLS leaks a surprising amount of metadata before encryption even kicks in and attackers, even the ones using TLS deliberately to blend in, mostly aren’t thinking about what that metadata gives away.

The handshake itself, the certificate exchange, even the timing of the connection none of that requires breaking encryption to analyze, and all of it carries genuine hunting value.

JA3 and JA3S fingerprinting still earns its keep

JA3 fingerprints the TLS client hello the specific combination of TLS version, cipher suites, extensions, and elliptic curves a client offers, hashed into a single string. Legitimate applications tend to have consistent, recognizable JA3 hashes because they’re using standard libraries in predictable ways. Malware, particularly anything built on frameworks like Cobalt Strike or custom C2 tooling, often has a distinctive JA3 hash because it’s using a specific TLS library configuration that doesn’t match common browsers or standard system tools.

The practical hunt: maintain a watchlist of known-malicious JA3 hashes from threat intel sources, sure, but the higher-value approach is baselining what JA3 hashes are normal in your environment and flagging anything new or rare. A host suddenly generating traffic with a JA3 hash that’s never appeared anywhere else in your environment, especially from a process that should be using a standard browser stack, is worth a look regardless of whether that specific hash is on anyone’s public blocklist yet. JA3S, the server-side equivalent, works the same way for characterizing C2 infrastructure on the response side.

Certificate analysis catches more than people expect

Self-signed certificates, certificates with suspiciously short validity periods, or certificates issued by free CAs used in combination with a domain registered days earlier these patterns show up constantly in malicious infrastructure and rarely in legitimate enterprise traffic, at least not in that specific combination. A certificate valid for exactly 90 days issued through a free automated CA isn’t inherently suspicious on its own plenty of legitimate small services use exactly that setup. What matters is the combination: new cert, new domain, unusual JA3, all converging on one connection.

Certificate subject and issuer field mismatches are worth specific attention too. A certificate claiming to be issued for a well-known brand’s domain but signed by a CA that brand has never used, or a certificate where the subject alternative names list includes a mix of legitimate-looking and clearly algorithmically generated domains, is a strong signal of either a misconfigured legitimate service or, more interestingly, shared C2 infrastructure serving multiple campaigns off the same certificate.

SNI field mismatches expose domain fronting and more

The Server Name Indication field in a TLS handshake tells the server which hostname the client is trying to reach, and it travels in plaintext even in an otherwise fully encrypted session one of the few places TLS still leaks something directly readable. Comparing the SNI value against what DNS resolution actually returned for that connection, and against what the certificate’s subject field claims, surfaces inconsistencies that are hard for an attacker to fully hide.

Domain fronting where the SNI field shows one domain (often a legitimate, trusted one like a major CDN) while the actual HTTP Host header inside the encrypted session requests something else entirely has gotten harder for attackers to pull off as major cloud providers have restricted it, but variants still show up. Any mismatch between SNI and the IP’s typical reverse DNS, or SNI values that don’t match any domain your DNS logs show being resolved by that host, deserves a closer look. It’s one of the more reliable “something’s being obscured here” signals available without decryption.

Timing and volume patterns compound everything above

Everything covered in beaconing analysis applies directly here too TLS sessions with suspiciously regular intervals, consistent byte counts, or connection durations that cluster tightly are worth correlating against the certificate and JA3 findings rather than treated as separate investigations. A connection with an unrecognized JA3 hash, a certificate issued four days ago, and a five-minute beaconing interval isn’t three weak signals. Stacked together, that’s close to a confirmed finding, and building your detection logic to score these signals cumulatively rather than requiring any single one to hit a high-confidence threshold on its own produces a much more usable alert queue.

Getting the tooling in place before you need it

None of this works without the right visibility deployed ahead of time JA3 extraction in particular needs to happen at the point of capture, whether that’s a network sensor like Zeek (which extracts JA3/JA3S natively) or an equivalent capability in your existing network monitoring stack. If you’re not already logging TLS handshake metadata separately from full payload capture, that’s the gap to close first, because retrofitting this analysis onto historical traffic you didn’t capture properly just isn’t possible.