How we measure exploitation

1. The decoys

huntback runs internet-facing decoys that answer like real products: VPN gateways, load balancers, PHP and ERP servers, and more. They replay responses captured from the real software, but nothing behind them is real and nobody uses them. So every request a decoy receives is unsolicited. It may come from a search-engine-style scanner, a researcher or an attacker; we do not call it an attack until it matches an exploit signature.

2. From a request to a CVE sighting

Each captured request is matched against network signatures: our own, and wire-level templates from the public Nuclei project. A match tags the request with a CVE. A tagged request is an attempt. Some attempts carry a full exploit payload; others are probes that only check whether a target looks vulnerable. Counts on our pages include both, and the CVE record shows the request so you can tell which.

Internal signature names that are not CVEs (for example a product-specific detection we wrote ourselves) are left out of CVE counts.

3. What "exploited in the wild" means here

We mark a CVE as exploited when at least one of these is true, and we show which:

• it is listed in the CISA Known Exploited Vulnerabilities (KEV) catalog;
• CISA's own SSVC assessment says exploitation is active, a vendor advisory (Cisco, Fortinet, Palo Alto Networks, Ivanti) says it is aware of exploitation, or Microsoft marks it "Exploited: Yes";
• our decoys captured attempts against it.

An attempt on a decoy is not a successful compromise. Decoys are not vulnerable; an attempt shows that someone is trying, which is what a defender needs to know first.

4. Lead time over CISA KEV

For every CVE we keep the earliest decoy capture and the earliest outside exploitation report, and we never move either timestamp later. When CISA adds the CVE to KEV, we compare our earlier signal with the listing.

CISA publishes the date a CVE was added, not the time. We count the listing from the start of that day (00:00 UTC), so a signal on the listing day itself is never counted as a lead, and a lead is never overstated. Each row says where our first signal came from: our own decoys, or the outside report and its source.

We can only claim a lead for exploitation we could see: a CVE needs a network signature on our decoys, or an outside report, before it can appear in that table.

We also only claim a lead for new CVEs, published at most 90 days before our first signal. CISA often adds old CVEs to KEV that attackers have used for years; seeing one of those on our decoys before the listing says when we started watching, not when exploitation started. A CVE with no known publish date is treated as old.

5. Loot

When a source attacks a decoy, huntback scans it back. If it serves an open directory, a staging panel or a payload, we download what it serves publicly, never execute it, record a SHA-256 for every file, and label it (webshell, phishing kit, exploit script, C2 configuration, miner and so on).

The public loot index shows counts, labels and file types per host. Each host's own public page (linked from the index) lists file names, with any name that could identify a victim (a domain or an email address) redacted. File contents and downloads stay inside the signed-in console.

6. What we do not claim

• That an attempt succeeded, or that a given organisation was compromised.
• That two hosts share an operator because they share a TLS fingerprint (JARM): that is a lead to check, not proof.
• That our counts measure the whole internet: they measure what reached our decoys.

7. Freshness

New CVEs, vendor advisories and CISA's exploitation flags are pulled every hour. KEV status and EPSS scores come from the daily catalog sync. The live numbers on the homepage refresh every couple of minutes.

8. Citing huntback

Please cite "Source: huntback (huntback.io)" and link the CVE page, the loot index or this page, whichever matches what you are quoting.