Four Grooming Signals Worth Alerting On: What Three Months of Underground Monitoring Actually Found

1. The dark-web monitoring market sells volume

Walk into any annual cybersecurity vendor expo and count the booths advertising dark-web monitoring. Almost every one of them sells the same product: a crawler that visits a curated list of forums and marketplaces, extracts mentions of the customer's domain, and surfaces those mentions in a dashboard. The dashboard reports volume: number of mentions per week, sentiment analysis, "exposure score" derived from the volume. The pitch is that visibility into the underground gives the security team a head start on the attacker.

The pitch is almost entirely wrong. Volume metrics from underground forums correlate poorly with actual exploitation risk. Most mentions of a customer's domain on a major forum are unactionable: they are stale credentials from a 2019 breach, they are typo-squatting research, they are someone asking whether they should phish a specific company. The number of mentions per week is not a signal. It is a measurement of the noise floor.

We built our own collection three quarters ago. The collection is intentionally narrow, four primary forums plus a handful of Telegram channels, and the post-collection analysis is intentionally aggressive about deduplication and noise rejection. Over three months of disciplined operation, the collection produced approximately 4,300 mentions of our active customer base. Four of those mentions produced findings that customers acted on. The signal-to-noise ratio is roughly 0.1 percent. The four signals that survived are the ones described below.

2. Signal 1, Proof-of-life screenshots

The strongest signal in our collection is the proof-of-life screenshot. An attacker preparing to sell access to a target frequently posts a screenshot demonstrating that access: a logged-in admin panel, a directory listing of an internal share, a database query result showing recent records. The screenshot is the bait that converts a forum thread into a buyer; without it, the seller has no proof.

Our detector for this class looks for image attachments adjacent to mentions of customer hostnames, customer-specific UI elements (logos, branded headers), or customer-specific data shapes (employee ID formats, internal ticket numbers, specific date ranges that suggest recent capture). When the detector fires, the result is reviewed by a human within two hours. The review establishes whether the screenshot is a fabrication (compositing of public material), a stale capture from a years-old breach (matched against known-breach corpora), or a fresh capture.

A fresh capture is a Sev-1 ticket. The customer's IR team is contacted directly, with the screenshot, the forum URL, and the seller's pseudonym. The detection-to-notification interval has averaged forty-seven minutes across the events that have triggered the alert.

The most operationally relevant fact about this signal is that it has fired five times in the last quarter. Five. Across our entire active customer base, over three months. The volume is small because the signal is real, most forum chatter is not this, and we deliberately suppress everything that is not.

3. Signal 2, CVE-plus-customer-vertical pairing

The second signal looks for an emerging exploit chatter pattern around a CVE paired with the customer's industry vertical. The chatter shape we look for is "anyone testing this on [vertical]?", a question that signals an attacker is moving from generic exploitation to targeted exploitation of a specific industry.

The detection logic joins three streams: the CVE mention stream from forum monitoring, the active CVE catalogue from our nightly research chain, and the industry-vertical metadata from each customer's engagement profile. A fire requires (a) a CVE mention in a monitored channel, (b) the CVE projecting against any customer's stack via the Version Vulnerability Projector, and (c) industry-specific framing in the post text.

When the detector fires, the affected customers receive a brief stating "the [CVE] you may be exposed to is being actively researched against your industry on [forum]; we recommend escalating its remediation priority". The brief includes the detection trace and a link to the active Proof Capsule for the CVE.

This signal fired eleven times in the last quarter. Three of those fires preceded broader public exploitation by two-to-four days, providing the affected customers with an early-warning window that did translate into faster patching.

4. Signal 3, Credential-stuffing list with timestamp drift

The third signal is more technical. The general dark-web monitoring market routinely surfaces credential lists containing customer email addresses; these are mostly stale, derived from years-old breaches of unrelated services. The signal worth alerting on is the credential list whose composition suggests fresh compromise, specifically, a list with a recent timestamp distribution and password complexity profile inconsistent with stale-breach reuse.

Our analysis applies three filters. First, the list must contain at least N credentials matching the customer's domain (N varies by customer size; for a 10k-employee customer, N is around 50). Second, the password distribution in the list must show recency markers, passwords that match the customer's current complexity policy (which often shifted in the last 18 months), passwords that include calendar tokens from the current or previous quarter, passwords that include the customer's current branding (suggesting users set them on the current site). Third, the credential timestamps (where the list includes them) must skew recent.

A list passing all three filters is treated as evidence of a fresh credential-phishing or session-stealer campaign targeting the customer. The notification is delivered to the customer's identity team with the list (delivered through a secure channel, never the dashboard), the analysis trace, and a recommended response: force-rotate passwords for the affected accounts, trigger MFA re-enrolment, and review session-token issuance logs for the affected user set.

This signal fired six times in the last quarter. All six tied to confirmed info-stealer malware campaigns whose proceeds were being aggregated and sold; the timing of our alert preceded the customer's first internal indicator by an average of nineteen days.

5. Signal 4, Initial-access broker listing with customer-specific properties

The fourth signal is the most consequential and the rarest. Initial-access brokers, IABs, sell prepackaged access to compromised networks. The listings carry a standard format: industry, revenue band, employee count, country, access type (VPN, RDP, Citrix, web shell, Active Directory account), and price.

Our detector pairs new IAB listings against our customer roster and looks for specific-enough matches that the listing plausibly describes a specific customer. The matching uses three properties: industry plus revenue band plus country narrows the candidate set; access type pairs against the customer's known infrastructure (a Citrix listing matches the customer who runs Citrix); listing-included details (region of operation, recent acquisition history, named subsidiary if mentioned) tighten further.

When a listing matches a single customer with high confidence, the notification is treated as a critical-severity finding. The customer's IR lead is contacted within thirty minutes. The brief includes the listing URL, the broker's pseudonym, the asking price, and the access type. The customer's response typically begins with a credential-rotation sweep, VPN session enumeration, and an emergency review of recent privileged-account activity.

This signal fired three times in the last quarter. Two of the three matched accurately enough that the customer's investigation found corroborating evidence (anomalous VPN logins, unauthorised AD object changes). The third resolved as a misattribution, the listing matched the customer's industry-and-size profile but the access turned out to be from a different organisation in the same vertical. We log the false positives explicitly so the customer can audit our detection accuracy.

6. The signals we deliberately do not alert on

Our customers ask us frequently why we do not alert on the broader categories the market sells. The answer is consistent: those categories have signal-to-noise ratios below what an SOC can act on. Specifically:

The defining choice in dark-web monitoring is what not to alert on. The market's bias is towards over-alerting because the dashboard has to look full. Our bias is towards under-alerting because a security operations lead's most valuable resource is their attention. The four signals above are what survived the cull.

7. What we publish to every customer

The four detection patterns above are the active set. The detection logic is documented in our customer-portal trust centre and is auditable per-engagement. Customers can request the per-fire evidence for any alert their organisation received, including the original forum URL, the detection trace, and the analyst's decision rationale. We treat the underground monitoring outputs with the same evidence discipline we apply to Test Capsules: signed, persistent, queryable.

Most dark-web monitoring promises early warning and delivers volume metrics. We promise four signals and deliver four signals. The customer's SOC stops drowning. The actual emergencies make it to the top of the queue.

Verifiable security.