A leaked credentials check usually starts the same way: someone runs their work email through a free breach search engine, gets a hit, and forwards the screenshot to IT with a question mark. That single lookup is genuinely useful. What it cannot tell you is whether the password still works, whether it came from a forum dump in 2016 or an infostealer log written last Tuesday, whether the browser session cookies left with it, or whether forty other accounts on domains nobody has inventoried are sitting in the same corpus unchecked.
Treating credential exposure as an operational process rather than a one-off search is what separates a clean answer from a false sense of safety. Below is how to scope it, triage it, verify it and act on it inside 48 hours.
Free breach search tools answer narrow questions well. They can confirm that an email address appears in a named breach corpus, that a specific password appears in a corpus of previously breached passwords, and that a domain has some volume of exposure associated with it. Have I Been Pwned is the reference point most UK security teams use for the first two, and its Pwned Passwords service is a legitimate control to build into password policy.
The limits matter more than the capability. A free lookup will not tell you how recent the exposure is, because indexed corpora often carry a breach date and nothing about when the record started circulating. It will not tell you whether the password is the one the user has today. It will not tell you whether the person's device is compromised. And it will not tell you whether session tokens were harvested alongside the credential, which is the detail that decides whether a password reset actually ends the incident.
Breach corpus lookups and stealer log data are different products wearing the same label, and most teams read them as one. A hit from an old forum breach, where the password was stored hashed and has since been cracked or was never usable, usually means enforce a password change, check for reuse, close the ticket. A hit from an infostealer log means something else entirely: a real machine belonging to a real person was compromised, and the plaintext password, the autofill data, the browser history and the session cookies all left together in one archive.
Under-reacting to the second category is the single most common failure in credential response. The password change looks like remediation. The attacker is already inside the session.
Reputable password-reuse checks use k-anonymity: the client hashes the password locally, sends only the first five characters of the hash, and receives back a list of matching hash suffixes to compare offline. The full password never leaves the device. That design is sound, but the habit it teaches is not, because staff cannot distinguish a k-anonymity endpoint from a credential-harvesting clone. Enforce reuse checks inside your identity provider or password manager instead, and tell people plainly that no legitimate service asks them to type a live password into a checker.
Scope failure is the most common reason a leaked credentials check comes back clean while the organisation is exposed. Credential data is indexed by domain. If the domain is not in the query, the records are not searched, and nobody sees a gap.
Checking individual mailboxes is triage, not coverage. Domain-level search across every mail domain you own, including aliases, catch-all addresses, acquired brands, old marketing and campaign domains and regional variants, is the minimum viable scope. Acquisitions are the usual culprit: staff move to the new tenant, the legacy domain keeps receiving mail for years, and nobody adds it to the monitoring list.
Most organisations do not have a complete view of their external attack surface, and that gap propagates directly into credential monitoring. Forgotten subdomains, dev and staging environments, shadow IT SaaS sign-ups made on a corporate card, and self-service tools registered with a personal-looking work address all create accounts nobody tracked. Accurate external asset discovery that maps domains, subdomains, IP ranges and cloud services has to come before the credential search, not after it, because the discovery output is what defines the search scope.
Executive exposure rarely sits where the staff list points. Directors sign up to services with personal Gmail or Outlook accounts, reuse a password that also unlocks corporate SSO, and carry personal devices into the same browser profile as work. Classify identities as internal or external, then give the external ones their own treatment: dedicated executive profiles, per-person risk scoring, and guarded handling of findings that touch social media, travel patterns or family detail. A flat company-wide list buries the identities most useful for authorisation fraud.
Your HR list is not your identity list. Contractors, agency staff, shared service accounts and supplier logins into your systems sit outside the payroll and inside the risk. Supplier credential exposure is treated as someone else's problem right up to the moment it is used to log into your estate, which is why open source intelligence monitoring across suppliers and third parties and accreditation tracking such as current ISO 27001 status belong alongside your own credential checks.
A domain search that returns 340 exposed accounts is not a 340-item incident. Assume 300 of them trace to one recycled combolist assembled from breaches years old, and 12 are current staff whose reused passwords still work somewhere that matters. The triage question is which 12. Explaining the 340 to the board is a distraction that eats the week.
Freshness comes from the record's context, not its headline. Look at the log timestamp, the URL captured alongside the credential (a login page for your SSO portal is a very different finding from a shopping site), the software fingerprint the infostealer family leaves in the log structure, and whether the archive includes cookie and autofill files. Records that arrive with device metadata and a browser profile are almost always live-machine compromise.
Combolists get repackaged and resold constantly, and each repackaging can generate a new alert against the same underlying data. Volume inflation of this kind is why raw alert counts are a poor metric for exposure.
Alert volume, not detection, is where credential monitoring programmes die. One infected laptop can produce hundreds of individual credential records across dozens of sites, and without deduplication by identity and by source archive, plus automated resolution of records already remediated, analysts stop reading the alerts within a month. Design the queue so that one compromised device presents as one incident with an attached record set.
An intern's decade-old forum password and a finance manager's plaintext VPN credential are not the same finding. Score by the privilege attached to the identity, whether the captured URL maps to an internet-facing system you own, and whether the credential arrived in plaintext.
You can establish a lot safely. Check multi-factor authentication coverage on the affected identity, password age and last-set date, reuse against a breached-password corpus, conditional access policy applied, and the account's sign-in logs for unfamiliar IP addresses, impossible travel or successful authentications from unmanaged devices. All of that is inside your own tenant and entirely defensible.
What you should not do is test leaked credentials against third-party services your users signed up to. Credential stuffing accounts you do not own is unauthorised access under the Computer Misuse Act 1990 regardless of intent, and the fact that the account belongs to your employee does not change the ownership of the service. Authorised alternatives look like a scoped penetration test with written permission, or replaying the credential against your own systems in a controlled test.
Session cookie theft is the bypass most teams overlook. If an infostealer captured a valid session token, MFA has already been satisfied and a password reset alone leaves the attacker authenticated. Revocation of refresh tokens and active sessions is the control that closes it.
Keep an evidence trail that survives internal review: source and collection type, capture date, redacted proof, the affected identity, and the remediation actions taken with timestamps. Redact the password itself in tickets. Auditors, insurers and the ICO all want provenance, not screenshots of plaintext.
Consider the case that turns up most often. A marketing contractor's home laptop is hit by an infostealer. The log contains a plaintext password for your SSO portal, browser session cookies for the same domain, and 60 unrelated personal logins. Password reset alone leaves the stolen session valid and the malware resident.
Quarterly manual checks are close to useless for stealer log data. Logs are packaged and traded quickly, and the useful window for detection is measured in days. A check every three months mostly confirms exposure long after the value has been extracted.
Fresh credential data also circulates in closed criminal forums, marketplaces and Telegram channels before it reaches any indexed breach search engine. A free lookup can look completely clean the same week your logins are being sold, which is exactly why human research into that chatter matters: an analyst can connect a captured URL, a device fingerprint and a seller's claim in ways automated matching alone will not.
Alert design decides whether any of this gets used. Set thresholds so low-value historical records do not page anyone, maintain VIP and guarded profiles for executives and board members, and send a weekly summary of what has changed rather than a live firehose. Credential findings should then feed continuous monitoring of your external assets alongside vulnerability and DNS findings, so continuous threat exposure management treats a leaked admin password and an exposed management interface as parts of the same attack path rather than two unrelated tickets in two unrelated tools.
Right for personal checks, quick incident triage and enforcing password hygiene through reuse checks. Limited to indexed breach corpora, offer no plaintext, no deduplication, no evidence trail and no coverage of forum or Telegram activity.
Useful and partial. Microsoft Entra ID leaked credential detection and similar identity provider features catch reuse against what that vendor ingests, which is a subset. Domain search tools give you volume and a starting list, rarely the freshness signals or source context that drive triage.
Ask specific questions before signing anything: which data sources are covered beyond indexed breaches, whether plaintext passwords are available for verification, how deduplication works, what evidence each record carries, whether there is API access into your SIEM or ticketing, and how executive findings are handled. If a provider cannot answer the deduplication question clearly, expect your analysts to abandon the feed.
Small team with no dedicated security function and no regulatory pressure: free lookups plus MFA everywhere and a reuse policy aligned to NCSC password guidance, which advises against enforced periodic rotation and in favour of blocking reused and breached passwords. Mid-market with compliance obligations, Cyber Essentials certification (which currently expects multi-factor authentication on cloud services) or supplier assurance duties: domain-level monitoring with continuous coverage and a named owner for triage. MSPs and MSSPs running exposure for multiple clients: a monitored platform with multi-tenant reporting, API access and per-client scoping, which is where the DarkInvader partner programme is aimed. Anyone who will not act on the alerts: fix the process first, because buying a feed nobody reads simply documents the exposure.
Yes, for individual addresses and password reuse. Free services such as Have I Been Pwned confirm whether an address appears in an indexed breach corpus and whether a password appears in a breached-password list, using k-anonymity so the password never leaves the device. What they will not give you is recency, plaintext verification, stealer log context or coverage of the forums and Telegram channels where fresh data appears first.
Start by building an accurate domain list, including acquired brands, legacy campaign domains, regional variants and any subdomain used for authentication, then run domain-level searches against that list rather than per mailbox. Discovery has to come first, because credential data is indexed by domain and anything missing from the list is simply never searched. A free DarkInvader account is one way to see the external footprint and exposure picture before committing to a monitoring programme.
No. MFA blocks straightforward reuse of a stolen password and remains one of the highest-value controls available, which is why Cyber Essentials expects it on cloud services. It does not stop an attacker replaying a stolen session cookie, because the token already represents a completed authentication. Revoking sessions and refresh tokens is the step that closes that route.
Continuously, if stealer logs are in scope. Infostealer output moves through criminal channels in days, so a monthly or quarterly manual sweep usually detects exposure after it has been used. Continuous monitoring with weekly change reporting and immediate alerting on privileged identities is the practical target.
Establish the source type before you touch anything, because it dictates the response. An old hashed breach record means a password change and a reuse check. A stealer log means resetting every credential stored on that device, revoking active sessions and refresh tokens, reimaging the endpoint, and assessing within hours whether personal data is involved and the 72-hour ICO notification clock applies. If you want that process running continuously rather than reactively, talk to the DarkInvader team about scoping a leaked credentials check across your full external footprint.
Unlock full visibility of your external attack surface with DarkInvader’s continuous, real-time monitoring. Create your free account to discover unknown assets, detect emerging risks and stay ahead of potential threats before attackers can exploit them.
Create My Free Account
Platform 7D, New Station Street, Leeds,
LS1 4BT, United Kingdom
Mon-Fri, 9:00-17:00
Contact:
sales@darkinvader.io
+44 (0)1138805336
Last updated: 14 August 2026
©2026 DarkInvader, All Rights Reserved
