Threat Clusters
Phishing kits are rarely used once. The same kit — the same page structure, the same fake login form — is redeployed across dozens of throwaway domains, often faster than any blocklist can keep up. Threat Clusters turns that reuse against the attacker: Surface Security groups structurally similar phishing pages into named threat families using fuzzy hashing, so the second, third, and hundredth deployment of a kit is recognized instantly, no matter what domain it appears on.
The Threat Clusters page (/dashboard/threat-clusters) is where you see the threat families detected in your environment, control whether clustering runs at all, and decide whether to participate in the shared intelligence pool.
[SCREENSHOT PLACEHOLDER: The Threat Clusters page showing the three summary cards (Active Clusters, Total Samples, Shared Pool), the Clustering Settings card with both toggles, and the cluster table with several rows populated]
How it works
Building clusters from your alerts
When the browser extension detects a suspicious page, it computes a one-way fuzzy hash of the page's structure. This is a fingerprint of how the page is built — not a copy of its content — and it stays stable even when an attacker swaps out domains, logos, or text.
Clusters grow from your own triage work:
- When your team resolves a phishing alert as a true positive, its structural fingerprint is fed into the clustering engine. If the fingerprint is similar enough to an existing cluster, it joins that cluster as a new sample. If it matches nothing, it seeds a brand-new cluster.
- When a new phishing detection arrives and its fingerprint matches a known cluster, the resulting alert is automatically acknowledged and escalated to Critical severity — a match against a confirmed kit family is about as high-confidence as a detection gets. High-scoring matches are also added to the cluster as new samples.
Each cluster's Confidence score rises as more samples accumulate: a cluster with one sample is a hypothesis, a cluster with fifty samples is an established kit family.
Protection in the browser
Clustering is not just reporting. The browser extension periodically syncs the active cluster fingerprints (roughly every six hours) and scores the pages your users visit against them. When a page's structure matches a cluster at or above the similarity threshold and the user's policy mode is Warn or Block, the extension shows the warning or block page immediately and raises an alert — even if the domain has never been seen before.
Several guardrails prevent false positives on legitimate sites:
- Learning mode never warns or blocks; matching is skipped entirely.
- Domains on your phishing whitelist are skipped.
- Your designated protected domains are skipped — they are admin-verified as the real thing.
- Well-known identity provider sign-in pages are skipped, since phishing kits imitate them so closely that the genuine page would otherwise score high against its own imitations.
The shared intelligence pool
Clustering works entirely within your own tenant by default. Optionally, you can opt in to the shared intelligence pool:
- You contribute: when an alert is resolved as a true positive, its anonymized cluster signature (the fuzzy structural hash, target brand names, kit family name, confidence score, and timestamps) is submitted to the pool.
- You receive: cluster fingerprints discovered by other participating organizations are synced back and appear in your cluster table with a shared source label. Your extensions match against them just like your own clusters — so a kit that hit another organization yesterday can be blocked in your environment today, on first contact.
Your organization's identity, domain names, URLs, alert details, and user data are never shared. The full list of what is and is not shared appears in the privacy disclosure shown when you enable the option.
Using the page
Summary cards
Three cards summarize the state of clustering at a glance:
| Card | Meaning |
|---|---|
| Active Clusters | Clusters currently active (matching and syncing to extensions), with the total count across all pages |
| Total Samples (this page) | Combined sample count of the clusters on the current table page |
| Shared Pool | How many visible clusters came from the shared pool, plus whether sharing is opted in ("Sharing opted in" / "Sharing disabled") |
Clustering Settings
The Clustering Settings card holds two toggles:
- Enable Threat Clustering — "Automatically cluster structurally similar phishing page hashes into threat families using ssdeep fuzzy matching. Enables kit family attribution and cross-alert correlation." This is the master switch. When it is off, no new clusters are built and extensions receive an empty cluster list (they stop matching).
- Opt In to Shared Intelligence — "Contribute anonymized cluster signatures to the shared threat intelligence pool and receive clusters discovered by other tenants." This toggle is only available while clustering is enabled.
Turning on sharing first shows the Privacy Disclosure — Shared Intelligence Pool panel, which spells out exactly what is shared (fuzzy page structure hashes, target brand names, kit family names, confidence scores, timestamps) and what is not (your organization's identity, domain names, URLs, alert details, user data). Click Enable Sharing to confirm or Cancel to back out.
[SCREENSHOT PLACEHOLDER: The Clustering Settings card with both toggles on and the Privacy Disclosure panel expanded, showing the "What is shared" and "What is NOT shared" lists with the Enable Sharing and Cancel buttons]
Two rules keep the settings consistent:
- Sharing cannot be enabled while clustering is disabled.
- Disabling clustering automatically disables sharing as well.
The cluster table
The Threat Clusters table lists every cluster visible to your tenant, 25 per page:
| Column | What it shows |
|---|---|
| Cluster | The cluster name and a truncated form of its representative structural fingerprint. Clusters built from your own alerts are auto-named with a timestamp (for example Cluster-20260315-142200); shared clusters are named after their kit family where known |
| Target Brands | The brands the kit impersonates (for example Microsoft, Okta), shown as badges |
| Kit Family | The attributed phishing kit family, or "Unknown" |
| Samples | How many confirmed page fingerprints belong to the cluster |
| Confidence | Percentage badge, color-coded: green at 75% and above, yellow from 50-74%, red below 50% |
| Last Seen | When a sample was last observed ("Today", "Yesterday", or days ago) |
| Source | auto for clusters built from your own alerts; shared_pool for clusters received from the shared intelligence pool |
Each active cluster row has a Deactivate action. Deactivating a cluster removes it from matching: it stops syncing to extensions and stops influencing new alerts. Use this if a cluster is producing matches you believe are wrong.
[SCREENSHOT PLACEHOLDER: A close-up of the cluster table showing the Cluster, Target Brands, Kit Family, Samples, Confidence, Last Seen, and Source columns, with one row's Deactivate action visible]
Worked example: a rotating kit campaign
- Monday morning, a user lands on
secure-portal-login.example-cdn.net, a Microsoft-lookalike page. The extension detects it and raises a phishing alert. Your analyst investigates and resolves it as a true positive. The page's structural fingerprint seeds a new cluster,Cluster-20260316-091504, with one sample and modest confidence. - Tuesday, the attacker rotates to three fresh domains — same kit, new hosts. Each detection's fingerprint matches the cluster. The alerts arrive already acknowledged and escalated to Critical, and the cluster grows to four samples with rising confidence.
- By Wednesday, extensions across your fleet have synced the cluster fingerprint. A user on a laptop that has never seen the campaign clicks a link to a fourth domain — and is blocked before the page can collect anything, because its structure matches the cluster.
- If you have opted in to sharing, the anonymized signature also entered the shared pool on Monday — so other participating organizations were protected before the campaign ever reached them, and you receive the same head start from their discoveries.
Threat Clusters vs. Campaign Intelligence
Surface Security has two related but distinct correlation features. If you have read about Campaign Intelligence, here is how they differ:
| Threat Clusters | Campaign Intelligence | |
|---|---|---|
| What it correlates | Page structure fingerprints (fuzzy hashes) of phishing kits | Multi-signal campaign fingerprints (structural, visual, and domain features) across organizations |
| Where it acts | Actively used for detection: extensions warn or block on cluster matches, and matching alerts are auto-escalated | Enrichment only: adds campaign context, "first seen elsewhere" timing, and organization counts to alerts your detectors already raised — never used to block |
| Works without sharing? | Yes — clustering of your own alerts is fully local; sharing only adds the cross-organization pool | No — it is entirely a cross-organization feature |
| Where you see it | This page, plus auto-escalated alerts in Alerts | The Campaigns page and campaign context on alert detail pages |
The two features share one switch: the Opt In to Shared Intelligence toggle on this page controls the same tenant-wide Threat Intelligence Sharing setting that governs Campaign Intelligence. Enabling sharing here opts you into both; disabling it turns both off.
Troubleshooting and FAQ
The table says "Enable threat clustering above to start grouping phishing kit signatures." Clustering is off. Turn on Enable Threat Clustering in the Clustering Settings card.
Clustering is on but the table is empty. Clusters are built as phishing alerts arrive and, above all, as your team resolves them as true positives. A quiet environment — or one where alerts are never triaged — produces few clusters. Resolving confirmed phishing alerts as true positives in Alerts is what seeds and grows clusters.
Why did an alert arrive already acknowledged and marked Critical? Its page fingerprint matched an active cluster. The auto-acknowledge and severity escalation are intentional: a match against a confirmed kit family needs response, not re-triage.
Can a legitimate site get blocked by a cluster match? The matching path deliberately skips your phishing whitelist, your protected domains, and well-known identity provider sign-in pages, and it only ever warns or blocks for users in Warn or Block policy mode. If a specific cluster still misbehaves, Deactivate it — matching stops on the next extension sync.
I deactivated a cluster — how fast does it take effect? Deactivation removes the cluster from the active set immediately on the server. Extensions pick up the change on their next cluster sync (they sync roughly every six hours).
Does enabling clustering send anything outside my deployment? No. Clustering alone is fully local to your tenant. Only the separate Opt In to Shared Intelligence toggle causes anonymized signatures to be exchanged, and it always shows the privacy disclosure before taking effect.