Detecting Cobalt Strike beacons with JA3 and JARM fingerprinting

Cobalt Strike remains a common post-compromise tool in intrusion sets because it gives an operator a flexible command-and-control channel, tasking framework, and a way to blend into normal network traffic. For defenders, the challenge is not just spotting malware on an endpoint. It is identifying the beaconing pattern that sits behind the traffic, especially when the payload is short-lived, fileless, or launched through legitimate processes.

That is where TLS fingerprinting can help. JA3 and JARM are not silver bullets, but they are useful enrichment signals for network detection, threat hunting, and triage. Used well, they can help a small security team narrow a large volume of encrypted traffic down to a manageable set of suspicious connections. Used badly, they can create noisy detections that are hard to trust. The practical answer is to treat them as part of a broader detection stack, not as standalone proof of compromise.

Why Cobalt Strike beacon detection still matters

How beaconing fits into post-compromise command-and-control activity

A beacon is the regular communication pattern used by an implant to check in with its controller. In Cobalt Strike environments, that traffic often appears as periodic HTTPS requests, sometimes with jitter, retries, and domain rotation. The traffic may look ordinary at first glance because it uses TLS, common ports, and infrastructure that changes frequently. The point is not to identify a single malicious packet. It is to recognise the pattern of repeated outbound contact that does not fit the host’s normal behaviour.

For UK SMEs, this matters because the initial compromise may already have happened before the beacon is visible. A phishing attachment, stolen credentials, or a vulnerable internet-facing service can all lead to a foothold. Once the attacker is inside, the beacon becomes the operational link that enables discovery, lateral movement, and data theft. If you can detect that link early, you reduce the time available for follow-on activity. That is why network detections complement endpoint hardening and process telemetry, rather than replacing them. If you are building out that broader picture, it is worth pairing this topic with network-layer command-and-control detection and fileless malware and living-off-the-land detection.

Where JA3 and JARM add value alongside endpoint and proxy telemetry

JA3 and JARM help because they describe characteristics of TLS handshakes rather than the content of the encrypted session. That means they can still be observed even when you cannot inspect the payload. In practice, they are most useful when combined with other signals such as destination reputation, DNS patterns, process lineage, and user context. A single fingerprint hit might be benign. A fingerprint hit from a workstation that has never spoken to that service before, at an unusual time, with a suspicious parent process, is a much stronger lead.

What JA3 and JARM actually measure

JA3 as a client-side TLS fingerprint

JA3 is a hash of selected fields from the TLS ClientHello message. It captures details such as the TLS version, cipher suites, extensions, elliptic curves, and elliptic curve formats offered by the client. The result is a compact fingerprint that can be compared across sessions. The value is not that it uniquely identifies malware. The value is that many clients, including malware families and custom tooling, tend to reuse the same TLS stack or the same handshake configuration.

For defenders, JA3 is most useful when you want to group outbound connections by client behaviour. If a host suddenly starts using a JA3 value that is rare in your environment, or one associated with known malicious tooling, that is worth investigating. The limitation is that common software can share fingerprints with malicious tools, especially when both use the same underlying libraries. That is why baselining matters.

JARM as a server-side TLS fingerprint

JARM works differently. It actively probes a TLS server with a series of crafted ClientHello messages and records how the server responds. The resulting fingerprint reflects the server-side TLS implementation and configuration. This is useful for identifying infrastructure that may be hosting C2 services, because many operators reuse the same server stack, reverse proxy, or TLS termination pattern across multiple hosts.

In a Cobalt Strike context, JARM can help cluster infrastructure that looks similar even when domains change. It is especially useful when paired with passive DNS, certificate data, and hosting metadata. However, it is still only a clue. A JARM match does not prove malicious intent. It tells you that a server presents a TLS profile that resembles something you have seen before, or something that is uncommon enough to warrant attention.

How Cobalt Strike traffic tends to stand out

Common TLS characteristics seen in beacon infrastructure

Many Cobalt Strike deployments use TLS in a way that is operationally convenient rather than browser-like. That can create patterns such as unusual cipher ordering, limited extension sets, non-standard server behaviour, or a mismatch between the claimed service and the observed handshake. Some operators use default or lightly modified configurations. Others customise heavily to avoid detection. The important point is that the traffic often has a repeatable shape, and that shape can be fingerprinted.

In a mature environment, you should expect some overlap with legitimate software. Security tools, VPN clients, remote administration platforms, and application frameworks can all generate odd-looking TLS handshakes. That is why a good detection programme does not rely on a single JA3 or JARM value. It uses the fingerprint as one feature in a wider scoring model.

Why fingerprints are useful but not sufficient on their own

A useful way to think about JA3 and JARM is as enrichment rather than verdict. They can reduce search space, support clustering, and help you pivot across related events. They cannot tell you whether a connection is malicious in isolation. For example, a JA3 value may be shared by a legitimate library used in a line-of-business application. A JARM value may match a benign reverse proxy. If you alert on the fingerprint alone, you will spend time chasing false positives. If you combine it with host context and network behaviour, the signal becomes far more actionable.

Building a practical detection workflow

Collecting TLS metadata from Zeek, Suricata, proxy logs, or NDR tools

To operationalise fingerprinting, you need telemetry that exposes TLS handshake metadata. Zeek is a common choice because it can log TLS client and server details in a structured way. Suricata can also surface TLS metadata, and many proxy platforms record negotiated cipher suites, SNI, certificate details, and destination information. Some NDR platforms compute JA3 and JARM natively, which can save engineering time if you already trust the data pipeline.

For a small team, the key design question is not which tool is fashionable. It is where the data is most reliable and easiest to normalise. If you already centralise logs into a SIEM, make sure the fingerprint fields are preserved as searchable attributes. If you are using Zeek, for example, you might ingest the tls.log and conn.log streams into your analytics platform, then join them with DNS and endpoint events by time, host, and destination. If you are using proxy logs, ensure the fingerprint is tied to the original client IP and user identity where available.

Normalising fingerprints and enriching them with context

Fingerprint values are only useful if they are consistent. Normalise casing, remove empty values, and keep the raw field as well as any derived hash. Enrich each event with data that helps triage: asset criticality, user role, geolocation, domain age, certificate issuer, ASN, and whether the destination is already known in your environment. If you are mapping this into a detection engineering workflow, it helps to align the output with your existing MITRE ATT&CK coverage so you can see where the detection sits in the kill chain.

A practical enrichment pattern is to score events on three axes: rarity, risk, and corroboration. Rarity asks whether the fingerprint is unusual in your estate. Risk asks whether the destination or host is sensitive. Corroboration asks whether there are supporting indicators from endpoint, DNS, or identity telemetry. That approach is more robust than a simple allow or deny list.

Detection logic and tuning considerations

Using allowlists, baselines, and confidence scoring

Start with a baseline of normal fingerprints in your environment. Most organisations will find that a small number of JA3 values account for a large proportion of traffic, especially from browsers and managed applications. Build allowlists carefully and review them periodically. A fingerprint that is common today may not remain common after a software update, and a fingerprint that is rare may become legitimate after a new application rollout.

Confidence scoring works well here. For example, you might assign a higher score when a rare JA3 appears on a server that also has a suspicious JARM, a newly registered domain, and a workstation process that does not normally make outbound HTTPS connections. You might assign a lower score when the same JA3 appears from a managed browser on a known SaaS destination. The goal is to reduce alert fatigue while preserving high-value leads.

Reducing false positives from browsers, libraries, and security tools

False positives often come from software that shares TLS libraries or intentionally uses unusual handshakes. Browsers are a good example because they are heavily standardised but still vary by version and platform. Security tools, backup agents, and monitoring software can also generate traffic that looks odd from a pure fingerprint perspective. The answer is not to ignore these tools. It is to model them explicitly.

One useful pattern is to maintain separate baselines for user workstations, servers, and security appliances. Another is to suppress known-good fingerprints only when they appear from expected hosts, processes, and destinations. That prevents a blanket allowlist from hiding genuinely suspicious use of the same fingerprint elsewhere in the estate. If you are already tuning endpoint telemetry, the same discipline applies here as in credential theft and misuse detection: context matters more than a single indicator.

Correlating fingerprint hits with other beacon indicators

Process, domain, and network context from endpoint and DNS telemetry

When a JA3 or JARM match appears, the next step is correlation. On the endpoint side, look for the parent process, command line, user context, and any recent script activity. On the network side, check DNS query timing, domain age, certificate reuse, and whether the destination has appeared across multiple hosts. If the beacon is using a domain fronting pattern or a rotating infrastructure model, you may see repeated connections to a small set of IPs with changing hostnames, or the reverse.

DNS telemetry is especially valuable because it can show whether the host resolved the domain shortly before the connection, whether the domain is newly observed, and whether the query pattern is consistent with normal application behaviour. If the same host also shows suspicious process creation, unusual PowerShell, or a recent credential event, the confidence level rises quickly.

Mapping findings to MITRE ATT&CK techniques for triage

MITRE ATT&CK is useful here because it gives analysts a shared language for describing what the beacon may represent. Cobalt Strike beaconing often sits within command and control techniques, but the surrounding activity may also include initial access, execution, persistence, privilege escalation, or discovery. Mapping the detection to ATT&CK helps you understand whether you are seeing an isolated network event or part of a broader intrusion chain.

That mapping also helps with reporting and improvement. If you repeatedly detect suspicious TLS beacons but never see the corresponding endpoint activity, you may have a visibility gap. If you see the endpoint activity but not the network signal, your telemetry pipeline may need work. If you are building a broader detection programme, it is worth aligning this with a structured approach such as mapping detections and controls to MITRE ATT&CK.

Operational response when a match appears

Triage questions for SOC analysts and small security teams

When a fingerprint match appears, the first question is whether the event is expected. Which host generated it, which user was logged on, and what process initiated the connection? Is the destination a known service, a newly observed domain, or an IP with no obvious business purpose? Has the same fingerprint appeared elsewhere in the estate, or is this a one-off?

Next, check whether the event is isolated or part of a sequence. Did the host recently execute a script, spawn a suspicious child process, or connect to unusual DNS infrastructure? Did the user have a recent sign-in anomaly or privilege change? The aim is to decide whether you are dealing with a benign outlier, a misconfigured application, or a likely beacon that needs containment.

Containment priorities without overreacting to a single indicator

Do not jump straight to destructive action on the basis of one fingerprint alone. A measured response is usually better. If the evidence is weak, collect more telemetry and increase monitoring. If the evidence is strong, isolate the host, preserve volatile data where possible, and block the destination at the appropriate control point. If the destination is shared infrastructure, avoid broad blocking that could disrupt legitimate services.

For UK SMEs, the practical priority is to preserve evidence, reduce exposure, and keep the response proportionate. That usually means isolating the endpoint, checking for additional hosts with the same fingerprint, and reviewing recent authentication and process activity. If you have a playbook for incident handling, this is the point to use it. If not, the response should still be structured and documented so that you can learn from the event afterwards.

Implementation patterns for UK SMEs

Using Microsoft Sentinel, Sigma, or NDR platforms to operationalise detections

If you are using Microsoft Sentinel, a common pattern is to ingest Zeek, proxy, firewall, or NDR data into Log Analytics, then write KQL analytics that look for rare JA3 or JARM values, suspicious destination combinations, and repeated outbound connections over a short interval. Sigma can help you keep the detection logic portable if you want to express the rule once and adapt it across platforms. For teams with an NDR platform, it may be simpler to use the vendor’s native fingerprinting and then forward high-confidence alerts into the SIEM for correlation.

A practical detection stack might look like this: collect TLS metadata, build a baseline of common fingerprints, flag rare or newly observed values, enrich with DNS and endpoint context, and route only the higher-confidence matches to analysts. That keeps the workflow manageable for a small team. It also avoids turning every odd TLS handshake into a ticket.

Where this fits in a broader detection engineering programme

Fingerprinting works best when it sits inside a broader detection engineering programme. That means version-controlled rules, documented tuning decisions, test cases, and regular review of false positives and misses. It also means validating detections with safe simulation where possible, so you know whether your telemetry and logic behave as expected. If you are already working on detection quality, this sits naturally alongside Sigma-based SIEM detections and measuring detection quality and false positives.

Limitations, evasions, and next steps

Why attackers change infrastructure and fingerprints

Attackers adapt quickly. They can change TLS libraries, proxy through different infrastructure, rotate certificates, or deliberately mimic common client behaviour. That means a fingerprint that works well today may lose value tomorrow. Some operators also use legitimate cloud services or compromised infrastructure to make their traffic blend in. For that reason, you should expect fingerprinting to be a moving target.

The right response is not to abandon the technique. It is to keep it under review, measure how often it produces useful leads, and supplement it with other signals. If a fingerprint stops being distinctive, retire it or lower its weight. If a new pattern emerges repeatedly in confirmed incidents, promote it into your detection set.

How to combine fingerprinting with hunting and continuous improvement

Hunting is where JA3 and JARM often pay off. Search for rare fingerprints across your estate, then pivot into the hosts, users, and destinations associated with them. Look for clusters over time rather than isolated hits. Feed confirmed findings back into your baselines and alert logic. That continuous improvement loop is what turns a useful indicator into a sustainable control.

For many UK SMEs, the most realistic objective is not perfect detection. It is faster identification of suspicious outbound traffic, better prioritisation of analyst time, and more confidence that the team will notice beaconing early enough to respond. If you want help shaping that into a practical detection roadmap, a consultant can help you align telemetry, tuning, and response to the rest of your security programme.

Speak to a consultant

Frequently asked questions

Is JA3 enough to detect Cobalt Strike beacons?

No. JA3 is useful for highlighting unusual client TLS behaviour, but it is not sufficient on its own. It works best when combined with destination reputation, DNS data, endpoint process context, and other beacon indicators.

What is the difference between JA3 and JARM in practice?

JA3 fingerprints the client side of the TLS handshake, so it helps you group outbound connections by client behaviour. JARM fingerprints the server side by probing how a TLS server responds, which can help identify or cluster suspicious infrastructure.