Traditional web security scanning checks what an attacker can find by probing your server: missing headers, exposed directories, SQL injection vectors, TLS configuration. This is necessary but incomplete. It tells you nothing about what an attacker already has - credentials stolen months ago by infostealer malware, sitting in a database on a criminal forum, waiting to be used.

Shieldome includes dark web monitoring as part of every full scan. Here is what it checks and what to do when something is found.

Two threat intelligence sources

Infostealer databases (HudsonRock Cavalier)

Infostealer malware (Redline, Raccoon, Vidar, and dozens of variants) infects user and employee devices - often via phishing links, malicious browser extensions, or cracked software downloads. Once installed, the malware silently exfiltrates everything stored in the browser: saved passwords, cookies, autofill data, and session tokens. This data is then sold in bulk on Telegram channels and criminal marketplaces.

HudsonRock Cavalier aggregates this data and exposes a lookup API: given a domain, it returns the number of employee and user records linked to that domain that appear in infostealer databases.

What makes infostealer data particularly dangerous:

Public breach databases (Have I Been Pwned)

HIBP aggregates data from publicly disclosed data breaches - database dumps that have been leaked, published, or sold and eventually became publicly available. The domain search identifies whether email addresses under your domain appeared in any known breach.

HIBP data is older and less immediately actionable than infostealer data, but it covers a broader historical range and is useful for identifying accounts that were compromised in past incidents and may not have had passwords reset.

Severity levels and what they mean

CRITICAL: compromised employee records (infostealer)

If Shieldome returns CRITICAL for an infostealer finding, it means employees at your organization have active credential records in the HudsonRock database. This is not a theoretical risk - it means stolen credentials exist and are potentially in active use by threat actors.

Immediate actions:

  1. Force a password reset for all employees, not just those confirmed in the database (you only know the domain, not which individuals)
  2. Invalidate all active sessions immediately - revoke session tokens server-side
  3. Enforce MFA across all systems if you have not already - stolen passwords are useless against TOTP or hardware keys
  4. Run an endpoint detection scan on employee devices to identify and remove active malware
  5. Check recent login logs for unusual IPs, times, or geolocations

HIGH: user records or HIBP breach

More than 100 compromised user records or a confirmed HIBP breach indicates significant exposure of customer credentials. Actions:

  1. Notify affected users and prompt password resets - many jurisdictions require breach notification
  2. Invalidate sessions for affected accounts
  3. Review whether the breach data includes any payment or PII information that triggers regulatory obligations
  4. Enforce MFA for high-value accounts

What this check cannot tell you

Dark web monitoring tells you that credentials exist - not whether they have been used. It also cannot identify which specific individuals are affected (only the domain). Think of it as a smoke detector: it tells you something is wrong and you need to investigate, not exactly where the fire is.

For a full picture, dark web monitoring should be combined with:

How Shieldome checks your domain

When you scan https://staging.example.com, Shieldome extracts example.com as the root domain and queries both intelligence sources against that domain. No credentials are submitted; no data from your systems is sent. The queries are read-only lookups against threat intelligence databases.

Results appear as findings in the 🌑 darkweb scanner section of your scan report, alongside your standard OWASP findings. They are included in PDF exports and can trigger webhook notifications through your configured integrations.

See the dark web monitoring documentation for configuration details and API key setup.