Severity modifiers
Next to every pair's numeric score, you'll see a word: Info, Low, Medium, High, or Severe. That's the severity. It tells you which pairs to look at first. This page explains what pushes severity up and what pulls it down.
Score vs severity, quick version: the score only measures behavior (“does this look like a beacon?”). The severity takes that score and adjusts it based on everything else Beacon knows about the destination (known-bad fingerprints, threat intel hits, suspicious certificates). Two pairs with the same score can land on different severities.
The two numbers, side by side
Score (0–100): how beacon-like the timing, payload, and duration patterns look. Covered in detail on Behavioral scoring.
Severity (Info → Severe): the triage priority you should treat the pair at. This is what sorts your Detections list by default. A Severe pair lands at the top even if another pair has a slightly higher raw score.
What pushes severity up
- Known-bad TLS fingerprint (JA3 or JA4). The biggest bump. If the client is using a fingerprint that matches Cobalt Strike, Sliver, Metasploit, or another cataloged hacker toolkit, the pair jumps up the severity ladder regardless of how boring the timing is. See Fingerprinting.
- Known-bad HTTP fingerprint (JA4H). Same idea, for HTTP instead of TLS.
- Self-signed or suspicious certificate. Real websites get certificates from trusted authorities. C2 servers often skip that step and make their own, especially for short-lived campaigns.
- Threat-intel hits. Multiple feeds flagging the same destination stack on top of each other. A hit on Emerging Threats plus an AbuseIPDB confidence score plus a VirusTotal cluster is much stronger than any one source alone. See Threat intel.
- Suspicious hosting. Fresh networks, bulletproof hosting providers, or networks whose ownership changed in the last 30 days. Criminals churn through infrastructure faster than legitimate businesses do.
- Missing Accept-Language on HTTP. Real browsers always include this header. A lot of malware forgets. Small bump, but it adds up with others.
What pulls severity down
- Well-known big-tech destination. Microsoft, Google, Cloudflare, Amazon, Apple. These hosts carry huge amounts of legitimate traffic. The pair still shows up in your list (Beacon doesn't hide it), but its severity is dimmed so you don't waste time.
- Clean threat intel across every feed. Not a guarantee the destination is safe, but it modestly reduces severity compared to “we couldn't check” or “feeds were flaky.”
- Recognized client with matching JA4H. The User-Agent says “Chrome 118” and the HTTP fingerprint matches Chrome 118. Consistent answers on both sides of the handshake pull severity down.
Reading the result in the panel
Open any pair and scroll to Explain why. You'll see every modifier that applied, written out in English:
+Severity: JA4 matches Cobalt Strike+Severity: 3 threat-intel feeds reported-Severity: destination is a Microsoft ASN
If you think Beacon got the severity wrong, the modifier list tells you exactly which signal to challenge.
Can I tune the weights?
Not in the current release. Severity weights are the same for every workspace. Per-workspace tuning is planned.
For now, your biggest tuning knob is Mark benign / Confirm malicious. Marking a pair benign doesn't change the severity weights, but it will suppress matching future pairs so they stop cluttering your queue.