TLS Hunting — JA3/JA4 Rarity, Certificate Metadata, and SNI Anomalies

Every TLS connection leaves a fingerprint in the handshake — before any data is encrypted. JA3/JA4, certificate metadata, and SNI together form the hunter’s TLS toolkit: enough to identify anomalous clients, attacker-generated certificates, and routing tricks — without decrypting a single byte.

JA3/JA4 Rarity Analysis

Building the JA3 Frequency Baseline

// 30-day JA3 frequency baseline
Zeek_ssl_CL
| where TimeGenerated > ago(30d)
| summarize 
    host_count = dcount(id_orig_h_s),
    conn_count = count(),
    sample_snis = make_set(server_name_s, 5)
  by ja3_s
| order by host_count desc
// Top 10: browser JA3s (Chrome, Firefox, Edge, Safari, curl)
// Long tail: unknown or rare clients → investigate

The top 10 JA3 values in most enterprises will be:

Chrome on Windows (various versions)
Firefox on Windows/Mac
Edge on Windows
Microsoft .NET framework (used by Windows Update, Office)
Python requests library

Any JA3 seen by only 1 host that isn’t in these expected categories is a hunt lead.

Rarity Hunt Query

// Find JA3 values unique to single hosts (rare clients)
Zeek_ssl_CL
| where TimeGenerated > ago(30d)
| summarize 
    host_count = dcount(id_orig_h_s),
    conn_count = count(),
    distinct_snis = dcount(server_name_s),
    sample_sni = take_any(server_name_s),
    sample_host = take_any(id_orig_h_s)
  by ja3_s
| where host_count == 1            // Only 1 internal host uses this TLS profile
| where conn_count > 50            // But they've used it many times (programmatic)
| where distinct_snis <= 3         // To few unique SNIs (not a browser)
| order by conn_count desc

A rare JA3 used >50 times by 1 host, connecting to ≤3 unique server names, is a high-priority beacon + TLS fingerprint combination.

Certificate Metadata Hunting

Even if a JA3 isn’t in any blocklist, a self-signed or freshly-generated certificate reveals attacker infrastructure.

// Hunt for suspicious certificate characteristics via x509.log
Zeek_x509_CL
| where TimeGenerated > ago(30d)
// Join to ssl.log to get associated connection context
| join kind=inner (
    Zeek_ssl_CL 
    | where local_orig_b == true and local_resp_b == false
  ) on $left.id_s == $right.cert_chain_fuids_s
| where 
    // Self-signed: issuer == subject
    (certificate_issuer_s == certificate_subject_s) or
    // Very short validity (auto-generated cert)
    (datetime_diff('day', certificate_not_valid_after_t, certificate_not_valid_before_t) < 30) or
    // Generic CN
    (certificate_subject_s contains "localhost" or certificate_subject_s contains "Default")
| project 
    TimeGenerated,
    id_orig_h_s,
    id_resp_h_s,
    server_name_s,
    ja3_s,
    certificate_subject_s,
    certificate_issuer_s,
    certificate_not_valid_before_t,
    certificate_not_valid_after_t

Key checks per certificate:

Check	Command	Red Flag
Cert age	`not_valid_after - not_valid_before`	< 30 days or > 10 years
Self-signed	issuer == subject	Always suspicious on port 443
SAN extension	Parse certificate extensions	No SAN = old tooling
Subject CN	certificate_subject	’localhost’, IP literal, generic
Serial number	certificate_serial	0, 1, or small integers

SNI Anomaly Hunting

Empty SNI Hunt

// Connections on port 443 with no SNI
Zeek_ssl_CL
| where TimeGenerated > ago(7d)
| where id_resp_p_i == 443
| where local_orig_b == true and local_resp_b == false
| where isempty(server_name_s)  // No SNI
| summarize 
    conn_count = count(),
    unique_dsts = dcount(id_resp_h_s)
  by id_orig_h_s
| where conn_count > 10
| order by conn_count desc

Empty SNI on port 443 with >10 connections is either: custom TLS library (C2 tool), direct-IP C2 (no domain), or misconfigured legacy application. Each deserves a process pivot.

SNI vs IP Mismatch (Domain Fronting Indicator)

// Find where SNI doesn't reverse-resolve to destination IP
// (Simplified — full domain fronting detection requires HTTP Host header comparison)
Zeek_ssl_CL
| where TimeGenerated > ago(7d)
| where local_orig_b == true and local_resp_b == false
| where isnotempty(server_name_s)
// Flag: SNI has different registrable domain than destination IP's PTR
// (Requires PTR lookup enrichment — shown conceptually)
| where sni_registered_domain != ptr_registered_domain
| where ptr_registered_domain in (known_cdn_domains)  // CDN IP + different SNI

More practically: look for ssl.log entries where server_name is an internal or allowed domain but the destination IP is external and not in that domain’s known IP range.

Worked Example

TLS hunt: identifying custom C2 via JA3 rarity + cert metadata

PEAK Hypothesis: An adversary using a custom C2 framework (not a default Cobalt Strike profile) is operating in our network. Their TLS fingerprint won’t match known signatures, but their certificate will be self-signed and recently generated. Target: unique JA3 values + self-signed certs + port 443.

Step 1 — JA3 Rarity Query:

Results: 4 JA3 values seen by exactly 1 host each, >100 connections:
  a1b2c3d4: 10.1.2.33 → 142 connections over 3 days (all to 185.220.101.9:443)
  e5f6g7h8: 10.4.1.15 → 87 connections over 2 days (all to github.com)
  i9j0k1l2: 10.2.3.44 → 210 connections over 7 days (all to office.com) ← exclude (known SaaS)
  m3n4o5p6: 10.5.1.7  → 56 connections over 1 day (all to 94.130.50.4:443)

Candidates: a1b2c3d4 (10.1.2.33) and m3n4o5p6 (10.5.1.7). Exclude e5f6… (github.com = known) and i9j0… (office.com = known).

Step 2 — Certificate Metadata:

For a1b2c3d4 (10.1.2.33 → 185.220.101.9):

subject: CN=C2Server
issuer:  CN=C2Server          ← self-signed
not_before: 2024-08-10        ← 4 days ago
not_before: 2024-09-10        ← 30-day validity
serial: 1                     ← sequential small integer
SAN: absent                   ← no SAN extension

All five cert red flags present.

For m3n4o5p6 (10.5.1.7 → 94.130.50.4):

subject: CN=94.130.50.4       ← IP address as CN (no domain)
issuer:  CN=94.130.50.4       ← self-signed
not_before: 2024-08-14        ← today
not_valid_after: 2025-08-14   ← 1-year validity (Let's Encrypt-length but self-signed)
serial: 0

Four red flags.

Step 3 — Endpoint Pivot (Sysmon Event 3):

10.1.2.33 → C2 connection process: OneDriveStandaloneUpdater.exe in C:\Users\Public\ (wrong path for a Microsoft binary).

10.5.1.7 → C2 connection process: svchost.exe (PID 8844) from C:\Windows\Temp\ (wrong path).

Both hosts running C2 tools masquerading as legitimate Windows binaries.

PEAK Act: Escalate both hosts to IR (P1 — active C2). Write Sigma rule targeting self-signed cert + single-host JA3 rarity combination.

Retrieval Practice

ssl.log shows server_name=api.microsoft.com but the destination IP 91.213.50.22 resolves to a Hetzner VPS in Germany. Microsoft's IPs are in 13.64.0.0/11 and similar ranges. What does this indicate?

Reveal answer

This is a domain fronting or misconfigured C2 indicator. The SNI claims to be api.microsoft.com — a legitimate Microsoft domain — but the actual destination IP is a Hetzner VPS (German hosting provider), which is completely unrelated to Microsoft. Legitimate connections to api.microsoft.com would resolve to Microsoft's IP ranges (AS8075). Possible explanations: (1) Domain fronting — the attacker is using api.microsoft.com as an SNI cover while the actual traffic routes to the VPS. (2) DNS poisoning/hijack — the victim's DNS was manipulated to return the VPS IP for a Microsoft domain. (3) hosts file manipulation — the attacker modified the host's DNS resolution for api.microsoft.com. Investigate: check the host's DNS configuration, compare with another host's resolution of api.microsoft.com, check the endpoint for hosts file modification (Sysmon Event file write to C:\\Windows\\System32\\drivers\\etc\\hosts).