Hirdman: Reverse Check Interactive Demo

01 Hirdman · Leak

The compromised password was changed. Is the risk closed?

A reverse check is a search for all accounts linked to one breach, by address, login, nickname or password.

Record from a breach

Password••••••••••••

Sourcethird-party storage

Risk closed

Standard check

One password compromised → it was replaced → "risk closed"

Reverse check

One password compromised → it reveals all linked accounts → a path to the company portal

02 Links

Reverse check: from one record to its links

03 Hidden route

A route that a standard check does not show

An employee moved on from a previous job and signed up at a shop with their work email and the same password. The shop was breached: the password worked on the portal.

04 Defence

What to fix first and whom to protect

The passwords were changed and the incident was closed. But breached databases end up on forums, and new attackers run the reverse check again and come back into the company.

Accounts0new data ≈0

Stop password reuse

Changing it is not enough: use a unique password for every service. A variant of the old pattern will end up in a dictionary again.

Second factor and passkeys

Passkeys and a second factor on the portal and admin logins. A matching password will not open the login, and session theft is limited by short session lifetimes and device binding.

Close the account

The admin and test accounts, and accounts from the previous job: disable them or bring them under control before the next round.

Attribution: we link one person's accounts Smaller blast radius: the path breaks off sooner Priority: what to fix first

Text version

01. Leak

The breach contains a record with the login john.d@aceme.example and a password that the attacker now knows. The password was changed, and the incident is marked closed. But only one address was checked, and the password is known to more than the company.

02. Links

From one identifier (an address, a login or a nickname), a reverse check opens new accounts: a previous workplace, a personal mailbox, forum accounts. The nickname mutates along the same pattern: john_d, john_d87, johndoe_2025. One account yields 300 to 500 new data points. If the computer has an infostealer, sessions and site assets are taken from the account, and the reverse check reveals even more links.

The age of a password does not matter. A password a person has used for years, or a predictable variant such as "2025!", is cracked quickly by rule-based brute-force tools. We see this scenario from incident to incident.

03. Hidden route

An employee moved on from a previous job and signed up at an online shop with their work email and the same password. The shop was breached, and the password worked on the corporate portal. A standard breach check will not show this route. The same happens with vendors: an account on a service created for a company task, for example to buy cloud hosting, is linked to the company even without the company's email in the registration. The compromise happens at the vendor, not on the main domain.

04. Defence

The passwords were changed and the incident was closed. But breached databases end up on forums, and new attackers run the reverse check again and come back into the company. A company usually closes what it knows about: corporate email and known access. Personal notes that mention the company stay open, and an attacker returns through them.

A one-time code does not help if the attacker is already working with an issued session. Phishing-resistant sign-in methods (passkeys), short session lifetimes and device binding protect against this.

What to do: a unique password for every service; passkeys and a second factor on the portal and admin logins; disable or bring under control the forgotten admin and test accounts and accounts from the previous job.