Reconnaissance Rules vs CVEs

Reconnaissance rules are called "Reconnaissance" or "Recon Rules" in the web interface, and "fingerprint rules" or "fingerprints" in the API. This documentation uses both terms interchangeably — they refer to the same thing.

Two Types of Tracking

The Live Exploit Tracker monitors threats at two levels:

• CVEs: Specific, named vulnerabilities (e.g., CVE-2024-25600 — a code injection flaw in Bricks Builder for WordPress).
• Reconnaissance Rules (API: fingerprint rules): Product-level probing patterns that detect reconnaissance or exploitation activity targeting a product family, regardless of which specific CVE the attacker intends to exploit.

Both share the same scoring system (CrowdSec Score, Opportunity/Targeted Score, Momentum Score), the same exploitation phases, and the same integration/blocklist capabilities. The difference is in what they track and why.

CVE Tracking

A CVE entry in the tracker focuses on a single, identified vulnerability. The detection rule is built around the specific exploit technique — the URL, the payload structure, the HTTP method — that attackers use to exploit that particular flaw.

CVE tracking is ideal when:

• You know which specific vulnerabilities affect your environment
• You want to monitor exploitation of a known flaw you haven't patched yet
• You need to assess the urgency of a specific patch

Each CVE entry includes a description, CVSS score, CWE classification, references, a CrowdSec Analysis, and a timeline of key events (CVE published, detection rule released, first exploitation observed).

Fingerprint Rule Tracking

A fingerprint rule detects product-level probing and reconnaissance activity that doesn't map to a single CVE. Instead, it catches patterns like:

• Scanning for the presence of a specific product (e.g., probing known Microsoft Exchange endpoints to determine if a server is running Exchange)
• Enumeration of product versions or configurations
• Broad reconnaissance that could precede exploitation of any of several CVEs affecting that product

Examples

Fingerprint Rule	What It Detects
Microsoft Exchange Probing	Reconnaissance targeting Exchange servers, including version detection and endpoint enumeration across Exchange Server, OWA, and EWS.
F5 Probing	Scanning activity targeting F5 BIG-IP and TMUI interfaces.
WordPress Probing	Broad WordPress discovery and enumeration activity.

Why Fingerprints Matter

Fingerprint rules fill a critical gap:

1. Early warning: Reconnaissance typically precedes exploitation. Seeing fingerprint activity targeting a product you run suggests an attacker is mapping your attack surface — even if they haven't launched an exploit yet.

2. Zero-day coverage: When a new vulnerability is disclosed for a product, attackers who were already probing that product may exploit it immediately. If you're tracking the fingerprint rule, you already have visibility into who has been scanning your infrastructure.

3. Multi-CVE protection: A single product may have dozens of CVEs. Vendor subscriptions automatically cover all CVEs and reconnaissance rules for a vendor's products. Fingerprint rules complement this by providing reconnaissance-specific visibility — detecting probing activity that precedes exploitation.

Feature Comparison

Capability	CVEs	Fingerprints
Scores (CrowdSec, Opportunity, Momentum)	✅	✅
Exploitation phases	✅	✅
IP intelligence (attacker IPs with CTI)	✅	✅
Timeline (activity over time)	✅	✅
Firewall integration subscriptions	✅	✅
CVSS score	✅	—
CWE classification	✅	—
CrowdSec Analysis narrative	✅	✅
CVE events timeline	✅	—

Using Them Together

The most comprehensive monitoring strategy combines vendor subscriptions with targeted CVE and reconnaissance rule tracking:

1. Subscribe to your vendors — this is the simplest starting point. A vendor subscription automatically covers all current and future CVEs and reconnaissance rules for that vendor's products. See Vendor Subscriptions.
2. Add individual fingerprint rules for products outside your subscribed vendors, or when you want reconnaissance-specific visibility.
3. Monitor specific CVEs for unpatched vulnerabilities to inform patching priorities and triage decisions.

For example, if you run WordPress and Microsoft infrastructure:

• Subscribe to the WordPress and Microsoft vendors to automatically cover all their CVEs and reconnaissance rules
• Add individual subscriptions for any other products you use that aren't covered by a vendor subscription (e.g., a niche plugin or appliance)
• Use the tracker's scores and phases to prioritize which patches to apply first