How to Set Up Dark Web Monitoring: 13 Steps, 90 Min [2026]

Have I Been Pwned now tracks 1,038 breaches and roughly 17.8 billion pwned accounts, and the site added two new incidents in the week before this article was written: a 17.8 million-record LimeLeads leak on September 22, 2026, and a 4.7 million-record Chess.com breach dated August 2026. Most people find out their credentials are circulating on breach forums or Telegram channels only after something goes wrong, a locked account, a fraudulent charge, a login alert from a country they’ve never visited. By then the password has usually been resold, tested against a dozen other services, and dropped into an infostealer log that nobody at the company is watching.

Dark web monitoring closes that gap. Done right, it is not a subscription you buy and forget, it is a small pipeline: a data source that knows about breaches, a script that checks your identifiers against it on a schedule, and an alert path that reaches a human before an attacker gets a head start. This tutorial builds that pipeline from scratch using the Have I Been Pwned (HIBP) API, a scheduled job, Slack or email alerts, and a lightweight SQLite dashboard, then layers in manual OSINT techniques for teams that need to go further. By the end you’ll have a working project you can run today, plus the troubleshooting steps for when the API, Tor, or your automation inevitably misbehaves.

What Dark Web Monitoring Actually Means in 2026

The phrase “dark web monitoring” gets used loosely enough that it’s worth separating the marketing from the mechanics before you set anything up. There are really three distinct data sources involved, and confusing them is the single most common reason teams end up with a monitoring setup that misses the threats that actually hit them.

The first is breach databases like Have I Been Pwned, which aggregate credential dumps that have already surfaced publicly or been shared among researchers. These are not live dark web crawlers, they’re indexed collections of past incidents, updated as new leaks are verified and ingested. The second is infostealer log markets, where malware families like Vidar, Lumma, and RedLine harvest saved browser passwords, session cookies, and autofill data from infected machines, then bundle it for sale on Telegram channels and dark web marketplaces. This is a meaningfully different threat than an old database breach because the credentials are current and often still valid. The third is live dark web crawling, actual indexing of onion-service forums and marketplaces, which is what commercial platforms like Flare and Recorded Future Illuminate charge four and five figures a month to do at scale.

For most individuals and small teams, a combination of the first two data sources, checked automatically and alerted on quickly, covers the majority of real exposure. Full onion-network crawling matters more for enterprises defending brand impersonation, executive targeting, or supply-chain leaks, and this tutorial covers both the do-it-yourself path and where the commercial tier actually earns its price tag.

Why This Matters More Right Now

The breach landscape driving this tutorial isn’t theoretical. In the past few months alone, CenterPoint Energy disclosed a breach affecting 7.49 million records, image-hosting service Gyazo confirmed exposure of 23.6 million users and 490 million image identifiers, and fintech customers of Revolut dealt with two separate incidents, one tied to a fake government email and a smaller hacker claim involving 680 customers. None of those companies advertised the leaks themselves, most people learned their data was exposed from a breach-notification email, a password manager alert, or a news story, often weeks after the fact. A monitoring pipeline like the one in this tutorial exists specifically to close that lag.

The gaming and entertainment side of this problem gets less attention but is just as common. Credential-stealing malware bundled inside cracked game installers, cheat tools, and fake mod downloads routinely harvests saved logins for Steam, Discord, Roblox, and Xbox accounts alongside whatever banking or email sessions happen to be open on the same machine. If you’ve ever had to work through account recovery after a hijacked gaming account, the root cause was frequently an infostealer infection rather than a guessed password, which is exactly the kind of exposure that a credential-monitoring habit catches before it turns into a locked-out account and a support ticket.

Who Actually Needs This Setup

Not every reader needs the full pipeline described below, so it’s worth being honest about where the effort-to-benefit ratio changes.

Individuals get most of the value from Steps 2 and 3 alone: a free manual check on haveibeenpwned.com plus enabling breach alerts inside whatever password manager they already use. The scripting and automation in this tutorial is optional polish for a personal setup, not a requirement.

Small teams and solo founders benefit most from Steps 1 through 6, the full automated pipeline checking a short list of high-value addresses daily, with alerts landing in Slack. This is the sweet spot for the DIY approach, since a paid commercial platform is usually overkill at this scale and the API costs stay under $10 a month.

Growing companies with a real employee directory should add domain-wide monitoring from Step 4, plus the infostealer log coverage from Step 8, since credential exposure at this scale is less about any one person’s habits and more a statistical certainty across dozens or hundreds of accounts.

Enterprises and security teams with a dedicated budget should treat this tutorial’s pipeline as the baseline layer and add a commercial platform like Flare or Recorded Future on top for continuous crawling, brand impersonation detection, and executive protection, which a DIY script realistically cannot replicate at scale.

Prerequisites: Accounts, Tools, and Versions You Need

Before starting, gather the following. Version numbers matter here because breach-monitoring tooling changes fast, and running an outdated Tor Browser build in particular is a real security risk, not a cosmetic one.

• Python 3.11 or newer, with the requests and python-dotenv packages available via pip
• A Have I Been Pwned account and an API key (Pwned 1 tier starts at $4.50/month or $45/year for 10 requests per minute, per HIBP’s current subscription page)
• A domain you control, if you want domain-wide monitoring instead of single-address checks (requires separate domain verification and a higher-tier subscription depending on breached address count)
• Tor Browser 15.0.23 or newer (released September 15, 2026) if you plan to do any manual onion-site research
• A Slack workspace with permission to create an incoming webhook, or an SMTP account for email alerts
• SQLite 3 (bundled with Python’s standard library, no separate install needed)
• A GitHub account if you want to run the automation as a scheduled Action instead of a local cron job
• About 90 minutes for the initial build, plus ongoing time for daily alert triage

You do not need a paid commercial dark web monitoring tool to follow this tutorial. The entire pipeline below runs on the free tier of HIBP for single-address lookups, though domain-wide and stealer-log searches require a paid subscription once you exceed HIBP’s small free allowance.

Step 1: Map What You’re Actually Protecting

Skip this step and you’ll build a monitoring system that watches the wrong things. Write down every email address, domain, and username that matters: personal accounts, work accounts, service accounts used by automation, and any brand domains or subdomains your company owns. If you’re doing this for an organization, include executive personal emails too, since attackers frequently target those separately from corporate addresses because personal accounts tend to have weaker security.

Rank the list by blast radius. A shared admin email that touches your cloud infrastructure, DNS registrar, and payment processor deserves tighter monitoring than a marketing inbox. This ranking determines your alert thresholds later, not everything needs a 2 a.m. page.

Step 2: Create a Have I Been Pwned Account and API Key

Head to haveibeenpwned.com and check a couple of addresses manually first, this is free and doesn’t require an account, and it gives you a feel for what a breach record actually looks like before you start automating. For programmatic checks, you need an API key, which HIBP sells on tiered request-per-minute plans.

Plan	Requests/Minute	Monthly Price	Annual Price
Pwned 1	10	$4.50	$45
Pwned 2	50	$22	$220
Pwned 3	100	$37.50	$375
Pwned 4	500	$163	$1,630
Pwned 5	1,000	$326	$3,260
Ultra 4000	4,000	$1,304	$13,040

For an individual or small team checking a handful of addresses on a daily cron job, the Pwned 1 tier is more than enough headroom. Once you generate a key, treat it like any other API credential: never commit it to a git repository, and store it in an environment variable or secrets manager instead.

Step 3: Build a Python Script to Query the HIBP API

This script checks a single email address against the breached-account endpoint and returns a list of breaches, if any. HIBP requires a User-Agent header and your API key in an hibp-api-key header, requests missing either will fail.

import os
import requests
from dotenv import load_dotenv

load_dotenv()
API_KEY = os.environ["HIBP_API_KEY"]
HEADERS = {
    "hibp-api-key": API_KEY,
    "User-Agent": "personal-darkweb-monitor/1.0",
}

def check_account(email: str) -> list:
    url = f"https://haveibeenpwned.com/api/v3/breachedaccount/{email}"
    params = {"truncateResponse": "false"}
    resp = requests.get(url, headers=HEADERS, params=params, timeout=15)

    if resp.status_code == 200:
        return resp.json()
    elif resp.status_code == 404:
        return []  # no breaches found, this is the good outcome
    elif resp.status_code == 429:
        raise RuntimeError("Rate limited, back off and retry later")
    else:
        resp.raise_for_status()

if __name__ == "__main__":
    breaches = check_account("security-team@example.com")
    for b in breaches:
        print(f"{b['Name']} — breach date {b['BreachDate']}, {b['PwnCount']} accounts")

A clean run against an address with no history returns an empty list and a 404 status, which is the outcome you want. A hit looks like this:

[
  {
    "Name": "Chess.com (2026)",
    "Title": "Chess.com",
    "BreachDate": "2026-08-01",
    "AddedDate": "2026-09-13T00:00:00Z",
    "PwnCount": 4700000,
    "DataClasses": ["Email addresses", "Passwords", "Usernames"],
    "IsVerified": true
  }
]

DataClasses is the field to watch closely, since it tells you exactly what was exposed. A breach that leaked only email addresses is a nuisance. One that leaked passwords, security questions, or payment data changes your response entirely.

Step 4: Set Up Domain-Wide Breach Monitoring

Checking individual addresses works for personal use, but a company with dozens or hundreds of employee accounts needs domain-level search instead. HIBP’s domain search requires proving domain ownership through a DNS TXT record or an uploaded verification file, then bills based on how many breached addresses exist across that domain, with pricing that also depends on whether you want infostealer log data included.

Once verified, the domain search endpoint returns every breached address under your domain in one call instead of requiring one request per employee, which matters both for API rate limits and for cost. Run this monthly at minimum, weekly if your organization handles sensitive data or has previously been targeted.

def check_domain(domain: str) -> dict:
    url = f"https://haveibeenpwned.com/api/v3/breacheddomain/{domain}"
    resp = requests.get(url, headers=HEADERS, timeout=20)
    resp.raise_for_status()
    return resp.json()  # {"alias": ["BreachName1", "BreachName2"], ...}

Step 5: Automate Checks With Cron or GitHub Actions

A script that only runs when you remember to run it isn’t monitoring, it’s an occasional lookup. Wire it into a scheduler. On a Linux box or a small VPS, cron is the simplest option.

# Run the monitor every day at 07:00
0 7 * * * cd /opt/darkweb-monitor && /usr/bin/python3 monitor.py >> /var/log/darkweb-monitor.log 2>&1

If you’d rather not maintain a server, a GitHub Actions workflow does the same job on GitHub’s infrastructure, with your API key stored as a repository secret instead of an environment file on disk.

name: dark-web-monitor
on:
  schedule:
    - cron: "0 7 * * *"
  workflow_dispatch: {}
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install requests python-dotenv
      - run: python monitor.py
        env:
          HIBP_API_KEY: ${{ secrets.HIBP_API_KEY }}
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

The HIBP API’s lowest tier allows 10 requests per minute, which is plenty for a daily check of a small identifier list, but if you’re monitoring dozens of addresses individually rather than using domain search, add a short sleep between calls to stay under the limit.

Step 6: Wire Up Real-Time Slack and Email Alerts

A log file nobody reads is not an alert. Post new findings somewhere a human will actually see them within hours, not days. A Slack incoming webhook is the fastest way to do this.

def send_slack_alert(email: str, breach_name: str, breach_date: str, data_classes: list):
    webhook_url = os.environ["SLACK_WEBHOOK_URL"]
    message = {
        "text": (
            f":rotating_light: New breach detected for *{email}*n"
            f"• Breach: {breach_name} ({breach_date})n"
            f"• Exposed data: {', '.join(data_classes)}n"
            f"• Action: rotate this credential and check for reuse elsewhere"
        )
    }
    resp = requests.post(webhook_url, json=message, timeout=10)
    if resp.status_code != 200:
        raise RuntimeError(f"Slack webhook failed: {resp.status_code} {resp.text}")

Keep a local record of breaches you’ve already alerted on, otherwise every daily run re-announces the same old incident and your team starts ignoring the channel. The SQLite dashboard in Step 10 handles this deduplication automatically.

Step 7: Install and Harden Tor Browser for Manual OSINT

The HIBP pipeline covers known, indexed breaches, but it won’t tell you about a fresh forum post naming your company or a marketplace listing that hasn’t been aggregated yet. For that, you occasionally need to look manually, and that means Tor.

Download Tor Browser only from torproject.org, never a mirror or a third-party listing. As of this writing the current stable release is 15.0.23, published September 15, 2026, with a 15.0.22 update the week before it, which tells you how frequently this browser ships security patches, don’t run a version that’s more than a few weeks old. Before you open it, take these precautions:

• Never log into a personal or company account while routing through Tor for OSINT research
• Leave the security slider on “Safer” or “Safest” in the browser’s shield icon settings, this disables JavaScript on non-HTTPS sites and blocks several classes of exploit
• Don’t resize the browser window, the default size is part of Tor’s anti-fingerprinting design
• Use a dedicated research machine or a disposable virtual machine if you’re checking anything that could expose you to malicious downloads
• Never enter search terms into onion-site forms containing anything identifying, including test versions of your real passwords

Step 8: Search Onion Indexes Safely and Track Infostealer Logs

Ahmia is a search engine that indexes onion services, and unlike general dark web navigation, it filters out the worst content categories by policy, which makes it a reasonable starting point for legitimate research. It’s reachable both through Tor Browser directly and via a clearnet gateway at ahmia.fi for browsing without Tor, though the clearnet version won’t reach onion-only results. Search your company name, product names, and any leaked-looking usernames on a regular cadence, monthly is reasonable for most organizations, weekly if you’ve had a recent incident.

Infostealer logs deserve separate attention because they represent live, current credential theft rather than an old database dump. Malware families such as Vidar, Lumma, and RedLine infect a machine, quietly harvest every password saved in the browser along with session cookies and autofill data, then package that “log” for sale, often bundled by the thousand. A password that was never involved in any company breach can still end up for sale this way, because the exposure happened on the employee’s device, not on your servers. HIBP’s domain search can include stealer-log data as part of a higher subscription tier, and it’s worth paying for if you’re monitoring a domain of any size, since this is increasingly how credentials leak in 2026.

# Example: routing a request through the Tor SOCKS proxy for scripted onion lookups
# Requires Tor running locally (default SOCKS5 port 9050)
import requests

session = requests.Session()
session.proxies = {
    "http": "socks5h://127.0.0.1:9050",
    "https": "socks5h://127.0.0.1:9050",
}
resp = session.get("https://ahmia.fi/search/?q=example-company-name", timeout=30)
print(resp.status_code, len(resp.text))

Only script against clearnet OSINT gateways like Ahmia’s search interface, and treat scripted access to raw onion services as a manual, careful, one-off activity rather than something to automate blindly, both for safety and because most onion services actively resist automated scraping.

Step 9: Add Password Manager Breach Alerts as a Second Layer

Don’t rely on a single data source. Password managers with built-in breach monitoring add coverage that HIBP alone won’t catch, since they check the exact credentials stored in your vault rather than just the associated email address. Bitwarden’s vault includes a built-in breach report, and 1Password’s Watchtower flags reused, weak, and breached passwords directly inside the app, both of which are worth enabling if you already use one of these tools, as covered in our 1Password vs Bitwarden vs Dashlane comparison. This isn’t redundant with the HIBP pipeline, it’s a second, independent check that catches password reuse specifically, which HIBP’s breach data alone doesn’t evaluate.

Step 10: Build a Self-Hosted SQLite Monitoring Dashboard

Now tie the pieces together into the complete working project: a script that checks HIBP, stores results in a local database so it never re-alerts on the same breach twice, and posts new findings to Slack. This is the full pipeline, ready to schedule.

import sqlite3
import os
import requests
from datetime import datetime, timezone

DB_PATH = "darkweb_monitor.db"
API_KEY = os.environ["HIBP_API_KEY"]
HEADERS = {"hibp-api-key": API_KEY, "User-Agent": "darkweb-monitor/1.0"}
MONITORED_EMAILS = ["security-team@example.com", "admin@example.com"]

def init_db():
    conn = sqlite3.connect(DB_PATH)
    conn.execute("""
        CREATE TABLE IF NOT EXISTS seen_breaches (
            email TEXT, breach_name TEXT, breach_date TEXT,
            first_seen TEXT, PRIMARY KEY (email, breach_name)
        )
    """)
    conn.commit()
    return conn

def check_and_alert(conn, email):
    url = f"https://haveibeenpwned.com/api/v3/breachedaccount/{email}"
    resp = requests.get(url, headers=HEADERS, params={"truncateResponse": "false"}, timeout=15)
    if resp.status_code == 404:
        return
    resp.raise_for_status()
    for breach in resp.json():
        cur = conn.execute(
            "SELECT 1 FROM seen_breaches WHERE email=? AND breach_name=?",
            (email, breach["Name"]),
        )
        if cur.fetchone():
            continue  # already alerted, skip
        conn.execute(
            "INSERT INTO seen_breaches VALUES (?, ?, ?, ?)",
            (email, breach["Name"], breach["BreachDate"], datetime.now(timezone.utc).isoformat()),
        )
        conn.commit()
        send_slack_alert(email, breach["Name"], breach["BreachDate"], breach["DataClasses"])

if __name__ == "__main__":
    conn = init_db()
    for addr in MONITORED_EMAILS:
        check_and_alert(conn, addr)
    conn.close()

Query the database directly whenever you want a status report instead of digging through Slack history:

sqlite3 darkweb_monitor.db "SELECT email, breach_name, breach_date FROM seen_breaches ORDER BY first_seen DESC LIMIT 10;"

Step 11: Write and Test Your Breach Response Playbook

Detection without a response plan just tells you about problems faster, it doesn’t fix them. Before your first real alert fires, write down what happens next, then actually rehearse it once with a fake breach entry so the steps aren’t being improvised under pressure.

• Rotate the exposed credential immediately, and check every other service where that same password might have been reused
• Force a session logout on the affected account if the platform supports it, since a leaked session cookie can bypass a password change entirely
• Enable or verify multi-factor authentication is active, ideally a phishing-resistant method, our TOTP MFA setup guide walks through the process
• Check the exposed DataClasses field to see if security questions, payment data, or government IDs were included, since each requires a different follow-up
• If it’s a company account, determine whether breach notification law applies based on what data was exposed and which jurisdictions your users are in
• Document the incident, even a small one, since patterns across multiple small incidents often reveal a bigger problem, like a compromised employee device

If the exposure traces back to malware rather than a third-party breach, for example if the affected employee’s device shows signs of a Vidar or RedLine infection, treat it as an endpoint incident, not just a password problem, and reimage or thoroughly clean the machine before considering it resolved.

Legal and Compliance Considerations

Setting up monitoring is only half the job for a business, the other half is knowing what obligations kick in once you find something. Breach notification rules vary by jurisdiction and by what type of data was exposed, but a few patterns are consistent enough to plan around.

If your domain-wide search turns up employee credentials in a third-party breach, that generally does not trigger a notification obligation on your part, since the breach happened at the third-party service, not inside your own systems. What does trigger obligations is discovering that data your organization directly holds, customer records, health information, payment details, has itself appeared for sale. In that case, most US states require notification to affected individuals within a specific window, and sector-specific rules add further requirements, healthcare data under HIPAA and payment card data under PCI DSS both carry their own reporting timelines separate from general state breach laws.

Keep records of every monitoring check and every response action taken. If you ever need to demonstrate reasonable security practices, whether to a regulator, an insurer, or a customer, a documented monitoring history with timestamped detection and response is far more persuasive than a claim that you “take security seriously.” The SQLite database built in Step 10 doubles as this audit trail with zero extra work, since every row already carries a timestamp.

One more distinction worth internalizing: actively purchasing data from a dark web marketplace to “verify” a leak, even for defensive research, can cross into legally and ethically murky territory depending on jurisdiction and what’s being purchased. The techniques in this tutorial stick to passive observation, checking whether your identifiers appear in already-indexed breach data, and searching public onion indexes, deliberately avoiding that line.

Common Pitfalls in Dark Web Monitoring Setups

Most dark web monitoring setups fail quietly, not with an error message, but by missing the thing they were supposed to catch. These are the mistakes that show up most often.

• Treating HIBP as a live crawler. It’s a breach database, updated as incidents are verified and ingested, not a real-time dark web scanner. There is always a lag between a leak occurring and it appearing in the data.
• Hardcoding API keys directly in scripts. This is how keys end up committed to a public repository. Use environment variables or a secrets manager, and add your .env file to .gitignore before the first commit, not after.
• Ignoring rate limits until you hit a 429. The 10 requests-per-minute floor on the cheapest HIBP tier is easy to blow through if you’re looping over many addresses without a delay.
• Confusing Tor Browser privacy with operational anonymity. Logging into any personal account while browsing onion services over Tor links your research identity to your real one, defeating the purpose.
• No deduplication, causing alert fatigue. Re-announcing the same old breach every single day trains your team to ignore the channel, exactly when a genuinely new alert needs attention.
• Overlooking infostealer logs entirely. A company can have zero breach-database hits and still have active credentials for sale, because the malware harvested them straight from an employee’s browser.
• Detecting but never rotating. An alert that sits in a channel unactioned for a week provides zero protection, the whole point is closing the window between exposure and response.

Troubleshooting Dark Web Monitoring Issues

Symptom	Likely Cause	Fix
HIBP API returns 401 Unauthorized	Missing or invalid hibp-api-key header	Double-check the key was copied without whitespace and hasn’t expired on your subscription
HIBP API returns 429 Too Many Requests	Exceeded your tier’s requests-per-minute limit	Add a time.sleep() delay between calls, or upgrade to a higher tier
API request fails with no error code	Missing User-Agent header	HIBP rejects requests without a descriptive User-Agent, add one identifying your script
Domain search shows “unverified”	DNS TXT record not yet propagated or misconfigured	Recheck the exact record HIBP provided and allow up to 24 hours for DNS propagation
Tor Browser won’t connect	Network blocks Tor, or bridges are needed	Use the built-in “Connect via bridge” option and try the default obfs4 bridges
Script hangs querying onion search engines over Tor	Local Tor SOCKS proxy isn’t running or wrong port	Confirm Tor is running and listening on 127.0.0.1:9050 before your script starts
Slack webhook posts nothing, no error	Webhook URL revoked or channel archived	Regenerate the webhook in Slack’s app settings and update your environment secret
Cron job never fires	Wrong timezone assumption or crontab syntax error	Run crontab -l to confirm the entry saved, and check date against your intended schedule
SQLite “database is locked” error	Concurrent runs writing to the same file simultaneously	Ensure only one instance of the monitor script runs at a time, or add retry logic
GitHub Actions secret not picked up	Secret name mismatch between repo settings and workflow YAML	Confirm the exact secret name matches the ${{ secrets.NAME }} reference, case-sensitive

Advanced Tips for Scaling and Cutting False Positives

Once the base pipeline is running reliably, a few refinements make it far more useful for anything beyond a personal setup.

Deploy canary tokens, unique fake credentials or email addresses seeded only in one specific place, such as a single vendor contract or a single database export. If that exact token ever surfaces in a breach check or a dark web forum post, you know precisely where the leak originated, which is normally the hardest part of an investigation. This technique costs nothing and turns a vague “we might have been breached somewhere” into a specific, actionable lead.

Layer severity scoring into your alerts instead of treating every hit the same. A breach that exposed only email addresses from five years ago is informational. A breach from the last 30 days that exposed plaintext passwords and security questions is urgent. Encode this logic directly in the alert function so the Slack message itself signals how fast someone needs to react, not just that something happened.

For organizations with budget to spend, commercial platforms fill the gap this DIY pipeline doesn’t cover well: continuous crawling of active dark web forums and marketplaces rather than periodic checks against an indexed database. That’s a different and more resource-intensive job, which is why the pricing looks the way it does.

Tool	Approach	Approximate Cost	Best For
Have I Been Pwned (this tutorial)	Indexed breach database + API	$4.50–$3,260/mo by tier	Individuals, small teams, DIY pipelines
Flare	Continuous dark web and stealer-log monitoring	~$417/mo (third-party estimate)	Small-to-mid businesses wanting managed coverage
Recorded Future Illuminate	Threat intelligence platform with dark web module	~$1,000–$3,000/mo add-on; full enterprise contracts $12,000–$25,000/mo	Enterprises with dedicated threat intel teams
Bitwarden / 1Password breach reports	Vault-integrated credential and reuse checks	Included with existing subscription	Anyone already using a password manager

Note that the Flare and Recorded Future figures above are third-party pricing estimates rather than official published rate cards, since both vendors typically require a sales conversation for exact enterprise pricing. Treat them as a starting point for budgeting conversations, not a quote.

If you’re already running endpoint monitoring with a tool like osquery, correlate infostealer-related alerts with device telemetry, an employee’s HIBP hit combined with unusual process activity on their machine around the same window is a much stronger signal than either data point alone. The same logic applies to gaming and consumer platforms, where infostealer malware disguised as cracked software or cheat tools remains one of the most common credential-theft vectors, as we detailed in our breakdown of Vidar 2.0 gaming malware removal.

Frequently Asked Questions

Is dark web monitoring the same as identity theft protection?
No. Identity theft protection services usually bundle dark web monitoring alongside credit monitoring, insurance, and recovery assistance. What you’re building here is the monitoring component specifically, not the broader consumer product.

Can I monitor the dark web without using Tor at all?
Yes, for the majority of useful coverage. Breach database checks through the HIBP API require no Tor connection whatsoever, since HIBP itself operates on the regular web. Tor only becomes necessary if you want to manually browse onion-service forums directly.

How often should I run automated breach checks?
Daily is reasonable for a small list of high-value addresses. For domain-wide monitoring across a larger organization, weekly is usually sufficient given how HIBP’s data ingestion cadence works, though you can run more frequently if your subscription tier supports it.

What should I do the moment I get a breach alert?
Rotate the affected credential first, check for password reuse across other services second, and confirm multi-factor authentication is active third. Don’t wait to investigate the full scope before taking the immediate protective step of changing the password.

Is it legal to search the dark web for my own company’s data?
Passively searching indexed breach databases and using search tools like Ahmia to look for mentions of your own organization is standard security research. It becomes legally risky only if you attempt to purchase stolen data, access systems without authorization, or interact with marketplaces beyond passive observation.

Does a VPN replace the need for Tor when doing this research?
No. A VPN changes your visible IP address but does not let you reach onion services, which require Tor’s routing protocol specifically. The two tools solve different problems and are sometimes used together, though that combination has its own tradeoffs worth researching separately.

Why does my company show up in HIBP even though we’ve never been directly breached?
Employees reuse work email addresses to sign up for unrelated third-party services, gaming platforms, forums, newsletters, and when any of those services gets breached, the associated work email shows up in HIBP even though your own infrastructure was never touched.

What’s the difference between a breach and a leak from stealer logs?
A breach means an organization’s systems were compromised and its stored data extracted. A stealer log means malware on an individual’s device harvested locally saved credentials, regardless of whether any company was ever hacked. Both end up traded in similar places, but they call for different responses, a breach means rotating one credential, a stealer log infection means cleaning the whole device.

Do I need a paid HIBP subscription just to check my own personal email?
No. Checking a single email address manually on haveibeenpwned.com has always been free and doesn’t require an account or API key. You only need a paid API key once you want to automate checks programmatically or search an entire domain rather than one address at a time.

Can gaming accounts like Steam, Discord, or Roblox show up in this kind of monitoring?
Yes, and often before the player realizes anything is wrong. Gaming credentials get swept up in the same infostealer logs as banking and email passwords whenever malware infects a device, frequently through a cracked game download or a fake cheat tool. If you monitor the email address tied to those accounts, a breach alert can be your first sign that a stealer infection happened, well before you notice unauthorized purchases or a locked account.

Related Coverage

• Google Account Passkey Setup: 13 Steps, 40 Min [2026]
• Game Server Security Setup: 13 Steps, 2 CVEs Fixed [2026]
• Nessus Essentials Setup: 5 Free IPs in 12 Steps [2026]
• Cloudflare Turnstile Setup: 13 Steps, Free vs $8/Mo [2026]
• Xbox Account Hacked: 13-Step Recovery, 40 Min Fix [2026]