Breach and brand monitoring: the attack paths that never touch your network

DedSec Security Research

Most security spend defends the path that runs through your infrastructure. An attacker finds a service, exploits it, moves laterally, takes data. Every control in a standard stack sits somewhere on that line.

There is a second path that does not touch your infrastructure at all. Someone signs in with a password that leaked from an unrelated breach, or your customer types their credentials into a domain that looks like yours, or they install an app that carries your logo and was published by someone else. Nothing on that path generates a firewall event, an EDR alert or a scanner finding, because nothing on that path is yours.

Maphra treats this as its own pillar for that reason: breach and brand monitoring covers credential exposure in breach corpora, dark and deep web mentions, look-alike domains and impersonating applications. What follows is what makes each of those useful rather than decorative.

Credential exposure

The mechanism is dull and extremely effective. A staff member reuses a password on an unrelated service. That service is breached. The credential appears in a corpus. Nobody at your organisation is involved in any part of this until the login succeeds.

Monitoring for it means tracking your domains across breach corpora and surfacing the accounts that need a reset, with alerting when new exposure appears. The operational questions that decide whether it works:

• Freshness. A corpus is only as good as the feeds behind it. If a source stops returning data — a key expires, a quota is exhausted, a provider changes its terms — a naive integration reads the empty response as "no exposure found" and your dashboard turns reassuringly green at exactly the moment it stops working. Ask any vendor, including us, how their monitoring distinguishes "nothing found" from "source unavailable".
• Identity resolution. Exposure is reported against email addresses. Your response happens against accounts. A leaked address that belongs to a former employee, an alias, a shared mailbox or a personal account used for a work service each need a different action, and only you can supply that mapping.
• What you do with it. Detection without a reset workflow is a newsletter. The value is in the loop: exposure appears, the affected account is identified, the credential is rotated, and MFA coverage on that account is checked while somebody is already looking.

Dark and deep web mentions sit alongside this. They are less structured and more variable in quality, and they are best read as a lead to investigate rather than a finding to action directly.

Look-alike domains

A look-alike domain is infrastructure an attacker builds to be mistaken for yours. The registration is the earliest signal you will ever get, usually days or weeks before anything is hosted on it.

The detection problem is that "similar to your brand" is a fuzzy predicate, and fuzzy predicates generate noise. The variants that matter in practice:

• Character substitution and homoglyphs, including internationalised names that render as your brand but encode as something else entirely. A monitoring system that compares the encoded form and a human who reads the rendered form are looking at two different strings, and the gap between them is the whole attack.
• Top-level domain swaps, where the second-level label is exactly yours.
• Prefix and suffix constructions — a hyphenated word bolted onto your name.
• Legitimate similarity: your regional entities, your partners, and unrelated organisations that happen to share a word with you.

That last category is why a raw list of similar registrations is close to useless. What makes a look-alike actionable is corroboration: is it resolving, is there content, does the content copy yours, is there a certificate, is there a mail record configured on it. A registered-but-parked domain is worth watching. A resolving domain serving a copy of your login page is worth acting on this afternoon, and the difference should be visible without opening each one by hand.

Impersonating applications

The app variant of the same idea. Someone publishes an application using your name, logo or brand, either to harvest credentials or to trade on your reputation. Your customers experience it as your product, which means you own the consequences whether or not you own the code.

Two things decide whether this detection is signal or noise. The first is what counts as a match — a brand string appearing in an application title matches an enormous number of legitimate listings, including your own, your resellers' and integrations built on your API. The second is evidence capture. Impersonating listings are removed, renamed and republished constantly, so a detection that records only "we saw a listing" and not what the listing contained is worthless by the time anyone reviews it. Capture the publisher, the identifiers, the description and the assets at detection time, because the live listing will not be there when you need to justify a takedown.

Why this cannot live with the rest of your tooling

An internal scanner cannot see any of it. There is no asset to scan. The domain belongs to somebody else, the app is on somebody else's platform, and the credential leaked from somebody else's database.

It nevertheless belongs in the same place as the rest of your external exposure, because that is where the response gets decided. In Maphra this sits beside asset discovery, exposure analysis and vulnerability management, so a look-alike domain that resolves to infrastructure adjacent to yours, or a leaked credential for an account that administers a discovered asset, is visible in the same view as the asset itself. Attack paths do not respect the boundary between "our stuff" and "impersonation of our stuff", and neither should the surface you monitor.

A reasonable starting posture

If you are standing this up from nothing, the sequence that gets value earliest:

1. Get your domains under breach monitoring and run one clean-up pass on everything already exposed. This is almost always the largest immediately-actionable set.
2. Turn on alerting for new exposure, and check the alerting works by looking for a source that has gone quiet.
3. Add look-alike domain monitoring, and spend the first fortnight tuning what you consider corroborated rather than trying to action everything.
4. Add application monitoring last, with evidence capture switched on from the first run.

None of this is exotic. It is simply the half of the attack surface that most programmes never look at, because no scanner they own can point at it.

More about Maphra · All posts