The Password You Lost Somewhere Else Is How They Get In

Most intrusions we investigate begin with a working password, not an exploit. Where those passwords come from, why your own security had nothing to do with it, and the three controls that break the chain.

The Password You Lost Somewhere Else Is How They Get In

The intrusions that cause the most damage rarely look like intrusions at the moment they happen. There is no malware, no exploit, no alert. Someone logs in, at a plausible hour, with a real username and a real password belonging to a real employee. Every system involved behaves exactly as designed, because from the system's point of view nothing unusual has occurred.

The password was correct. It just was not being typed by the person it belonged to.

Where the password came from

Almost never from you. This is the part that organisations find hardest to accept, and it is the reason the problem is so persistent.

An employee signs up to something unrelated to work — a shopping site, a forum, a fitness app, a conference registration, a recruitment portal. They use their work email address, because it is the address they type without thinking. They choose a password. Some months or years later that unrelated service is breached, as thousands are every year, and its user database is taken.

That database is then traded, aggregated with dozens of others, and indexed into collections that anyone motivated can query. Your employee's work email address now sits in a searchable corpus next to a password they chose.

If that password was unique to the breached service, the exposure is contained and largely academic. If it was reused — or reused with a predictable variation, which counts as reused — then it is a working key to something of yours. And it is reused far more often than any policy would suggest, because people have somewhere between eighty and two hundred accounts and finite memory.

Nothing in this sequence involves a failure of your security. Your firewall was fine. Your endpoint protection was fine. The credential leaked from an organisation you have no relationship with, through no action of yours, and the first indication you will get is someone using it.

Why attackers prefer this route

Because it is cheaper and quieter than the alternatives, and it scales.

Developing or buying an exploit for an internet-facing system is expensive, perishable, and noisy — it leaves artefacts, it may fail, and it can crash the thing being exploited. Phishing a specific individual takes preparation and may be reported. Testing a large list of leaked credentials against a login page requires almost no skill, costs nearly nothing, and can be automated entirely.

More importantly, it produces no signal that ordinary defences are built to catch. There is no malicious file for an endpoint agent to quarantine. There is no exploit pattern for an intrusion detection system to match. There is a successful authentication, which is the single most common event in any environment. Unless something is specifically watching for the geography, the timing, the device, or the sheer number of failures preceding the success, the event is indistinguishable from a Tuesday.

This is also why the dwell time is so long. Attackers using valid credentials frequently sit inside environments for weeks, reading email, mapping the finance approval chain, learning who authorises payments and how they phrase their requests, before doing anything that could be noticed.

What it turns into locally

In the Kenyan incidents we are called into, a stolen credential typically becomes one of three things.

Business email compromise is the most common and the most lucrative. Access to a finance or director mailbox is used not to send anything immediately, but to watch. The attacker learns the supplier relationships, the invoice formats, the language people use with each other, the moments when payment instructions are plausible. Then a single message goes out — a change of bank details on a real, expected invoice — and it is entirely convincing, because it arrives in the correct thread, from the correct person, with the correct phrasing.

Mobile-money-themed fraud follows, exploiting the trust patterns everyone here has built around payment notifications. A message that mimics a legitimate transaction confirmation, sent from a genuine internal address, converts at rates that generic phishing from an external domain does not come close to.

Lateral movement is the third. Corporate credentials are tried against everything else the organisation runs — the VPN, the ERP, the cloud console, the payroll system — because password reuse inside an organisation is at least as common as outside it.

The three controls that break the chain

The chain has three links, and each can be cut. None of these are expensive.

Multi-factor authentication is the single most effective control against this specific attack, and the one most often deployed partially and therefore ineffectively. A stolen password stops being a working key the moment a second factor is required. The failure mode we see repeatedly is coverage: MFA is enabled on email but not the VPN, or on the VPN but not the cloud admin console, or on everyone except the three executives who found it inconvenient — who are, of course, the accounts worth stealing. Coverage is what matters, and coverage means everything, including the people who asked to be exempted.

A password manager solves reuse properly, where policy does not. Complexity rules and forced rotation produce predictable variations of one password, which defeats the purpose entirely. Giving people a manager removes the need to remember anything, at which point unique passwords per service become the path of least resistance rather than an act of discipline. It is a small licence cost against the most reliable entry route in the market.

Knowing when a credential has leaked closes the loop. The first two controls are preventative; this one is detective, and it is the only one that tells you which accounts to act on rather than asking you to act on all of them. Breach exposure monitoring watches known breach corpora for your domains and tells you which of your people appear, in which breach, and whether passwords were among the data. That converts an unknown into a specific list of resets. Have I Been Pwned offers free domain-wide search to verified domain owners and is a legitimate place to start; continuous monitoring across a wider set of sources is what platforms like NeuroThreat are for.

Do the free check first

Before anyone commissions anything, do the free version this week. Verify your domain with Have I Been Pwned and look at what comes back.

If nothing does, your urgency is genuinely lower than this article implies, and you can proceed to MFA coverage at a normal pace.

If a page of results comes back — which is the usual outcome for any organisation of size that has existed for a few years — then you are not reading a hypothetical. You are reading a description of credentials that already exist, already work in some cases, and are already searchable by people who are looking. The only variable remaining is whether you reset them before or after someone tries them.