Dark Web Monitoring
How Plenix auto-discovers monitors from your CRM, sweeps breach data nightly, scores findings by risk, and how to triage what it turns up.
What is monitored
Your clients' domains, email addresses, and brand names are watched for appearances in breach dumps and dark-web marketplaces. Exposed accounts surface early, so you can force resets and contain the risk before it is exploited.
Monitors are mostly created for you
When a CRM company has a domain on file, Plenix creates a monitor for it automatically — you don't have to add every client by hand. Auto-discovered monitors are marked as such wherever they appear.
You can still add one yourself from Monitoring → Dark Web Monitor → Add Monitor, choosing a type:
| Type | What it matches |
|---|---|
| Domain | The domain and every subdomain of it |
| Email domain | Breaches affecting any address at that domain |
| Email address | A single address — needs an HIBP API key configured on the server; without one, per-address checks are skipped |
| Brand name | Breach names and titles containing the word |
| Keyword | A free-text match across the breach catalogue |
| IP range | Recorded for reference only — not automatically checked |
The nightly sweep
A scheduled scan runs every night and checks every active monitor against current breach data — you don't need to trigger it, and you don't need to remember to. Findings from that sweep, and from any monitor you add manually, land in the Findings tab.
Reading a finding
Each finding records what was exposed (a data-class chip — password, payment detail, physical address, and so on — colour-coded by how sensitive it is), where it appeared, and when. A numeric risk score ranks how bad it is, and each finding carries a status: Open, Acknowledge it while you investigate, mark it False positive if it doesn't hold up, or Mark resolved once you've acted on it.
Treat every open finding as live until proven otherwise.
Responding to an exposure
- Force a password reset on the affected account immediately.
- Check whether the same password is used anywhere else in that client's estate — reuse is what turns one breach into several.
- Enable multi-factor authentication on the account if it is not already on.
- Raise a ticket so the response is recorded and reportable.
- Set the finding's status to reflect where you got to — Acknowledged while working it, Resolved once handled, False positive if it turns out not to apply.
What this does not do
A finding means a credential or detail appeared in a dump — it does not mean the account has been accessed. Check sign-in logs on the affected system before telling a client they have been breached.
Tip: Report findings to clients even when the credential is stale. Demonstrating that you spotted it is a large part of what they pay for.
Where to go next
- Understand the whole module → How Device Monitoring Works
- Checking SSL Certificate Status
- How to Manage IP Addresses (IPAM)
- See where this fits in the bigger picture → How a Device Problem Becomes a Fix
Was this article helpful?