How Stolen Employee Credentials Can Lead to Banking Data Breaches in India

Security spending in banking follows the value of the asset. The core platform gets the budget, the audits, and the hardening, because that is where the money and the data sit. The logic is sound right up to the point where an attacker declines to attack the asset at all and reaches it through a person who already has access. That path has become the cheapest one available, and the controls most banks trust were built for a different route.

What follows is not a pitch for abandoning the controls you have. It is a walk through exactly where each of them stops, why the stopping point is structural rather than a coverage gap you can close with more of the same, and what a complete posture actually requires once you accept that some credentials will leak no matter what you do. It sits alongside the wider argument that consent and prevention controls alone are not DPDP compliance.

Most banks can tell you what they have spent hardening the core banking platform. Very few can tell you the price of the credential that lets an attacker skip it entirely. In 2025, that price averaged around ten dollars: the going rate for a single infostealer log on a dark web market, one infected machine's worth of saved passwords, session tokens, and the exact addresses where each of them works.

That is the uncomfortable arithmetic behind almost every recent people-vector breach in banking. The attacker did not defeat the core platform. They did not need to. They logged in as someone who could already reach the data, using a credential that was on sale before anyone inside the bank knew it had leaked. The vault held. The attacker simply walked in through an employee who had the keys, and the keys had been copied weeks earlier from a laptop the bank did not control.

This is worth stating plainly because most credential defence is built to answer a different, older question. The instinct is to make the login harder to break: longer passwords, forced rotation, multi-factor authentication, endpoint agents on every corporate machine. All of it is sensible, and none of it is sufficient, because the credential that breaches you next was not broken at your login. It was captured somewhere else and is now in inventory in a market.

Credential security is not a login problem. It is a circulation problem, and every control that lives at the login inherits the same blind spot: it can defend the door, but not a key that has already been copied and put up for sale.

To see why, it helps to walk through the three defences banks lean on, in order of increasing sophistication, and understand exactly where each one stops.

Password Policy: Hardening a Secret the Attacker Already Has

The oldest defence is to make the password itself strong. Complexity rules, minimum lengths, mandatory rotation, a blocklist of the obvious choices. The premise is that the threat is a password someone can guess or crack, so a password that resists guessing and cracking is a safe one.

Password policy has one virtue. It closes the door on brute force and on the worst human habits. It also has one fatal limitation against the modern threat. It hardens a secret that the attacker is no longer trying to guess.

An infostealer does not guess. It reads. Once the malware is running on a device, it opens the browser's saved-password store and exfiltrates the plaintext the user actually typed, in full, however long and however random it was. A forty-character string generated by a password manager and a reused "Bank@123" are worth the same to a stealer log, because both arrive in the log as cleartext, already resolved, already mapped to the site they unlock. Password strength answers a question: can this be guessed? The infostealer never has to ask. For the vector that now dominates, policy hardens the one part of the problem the attacker has already routed around.

MFA Everywhere: Protecting the Login the Attacker Bypasses

The correct response to leaked passwords is multi-factor authentication, and this is not a strawman: MFA is the single highest-value credential control a bank can deploy, and it genuinely neutralises the replayed password. Steal the password, try to log in, and the second factor stops you cold. Against a static credential, MFA works as designed.

But MFA protects a specific moment, the login, and the credential economy has moved past that moment. Infostealers do not only take passwords. They take the authenticated session: the cookie the browser holds after a successful login, the token that says this session already passed every check. A live session cookie is not a key to the door. It is proof that someone already opened the door and is still inside. Replay it, and you inherit the open session without ever reaching the login, so the second factor is never asked for, because from the system's point of view the authentication already happened. This is precisely why fresh stealer logs, under forty-eight hours old, sell for a premium on the same markets: the session tokens inside them have not yet expired, and a valid session is worth more than a password MFA can stop.

MFA drives the value of a stolen password toward zero and does nothing to a stolen session. A bank that has enforced MFA everywhere has done something essential and has not touched the fastest-growing half of the problem.

Endpoint Security: Watching the Devices You Manage

The most sophisticated layer stops trusting the credential and watches the machine. Endpoint detection on corporate laptops, device management that flags the malware, the security stack that catches an infostealer the moment it executes. Where it is deployed, this is real protection, and it is the layer most likely actually to stop a stealer infection before the log is built.

It shares the same ceiling as the others, hidden under better coverage. Endpoint security only exists on the endpoints you administer, and the infection that produces the log is overwhelmingly on a device you do not. It is the employee's personal laptop, where they checked corporate webmail once and let the browser save the password. It is the home desktop the family shares, running a cracked application with a stealer bundled inside. It is the contractor's own machine, outside your fleet, outside your policy, outside your EDR entirely. One infected personal device produces a structured log containing every password that device's browser had saved, and if one of those was a corporate login, the credential is now compromised from a machine your endpoint stack was never on. The credential is corporate. The device is not. And the two facts together are invisible to every endpoint control you own, because the control was never installed where the theft happened.

The coverage is better than a password rule and better than a login check. The place the theft actually occurs is still outside it.

The Common Failure: They All Defend the Login. The Credential Leaks Somewhere Else.

Step back, and the three defences stop looking like three different solutions. Password policy hardens the secret. MFA guards the moment it is used. Endpoint security watches the machines you run. They are three points on one line, each a more sophisticated version of the same underlying assumption: that the fight happens at your authentication boundary, on infrastructure you control.

The credential economy is built to win before that boundary. By the time a corporate login sits in a stealer log, it was captured on a device outside your fleet, before it ever reached your login, and it is now packaged for sale. Every login-centric control is defending a door that the key was copied nowhere near. This is not a gap at the edges of these tools. It is structural, and the scale of it is not theoretical. Infostealers contributed to the theft of roughly 1.8 billion credentials in 2025, from around 5.8 million infected devices, and the industry data that should stop every security leader is this: Verizon's 2025 Data Breach Investigations Report found that a majority of ransomware victims had corporate domain credentials sitting in stealer log markets before the attack that hit them. The exposure was not undetectable. It was undetected. The breach was the consequence of no one looking at the market where the credential was already for sale.

What the Credential Economy Actually Looks Like

There is a different place to look, and it exists because a leaked credential is not a secret an attacker hoards. It is a product, and a product has to be listed to be sold. The infostealer economy runs like any other supply chain. Malware, most of it rented as a subscription for a few hundred dollars a month, harvests logs from infected devices at scale. The logs are aggregated and sold in bulk on Telegram channels and dark web shops, single logs going for as little as five dollars and rarely more than fifty. Initial access brokers buy in volume and comb the logs for the valuable material, the corporate logins, the VPN and cloud credentials, and resell that access at a steep markup. Live session cookies are traded to whoever wants an already-authenticated seat. The whole cycle, from infection to a log packaged and weaponised, routinely completes within forty-eight hours.

The consequence that matters is not the sophistication. It is the visibility. A credential broker cannot sell an inventory nobody can see; a marketplace listing is, by design, a public artefact. For the credential vector that now opens most corporate intrusions, the moment of monetisation and the moment of exposure are the same moment. The attacker's business model does the one thing your login controls cannot: it forces your leaked credential into the open, where it can be found by anyone who is looking. The question is whether anyone on your side is.

Why External Credential Monitoring Is the Right Approach

You cannot prevent every leak. The personal device, the reused password, the human who clicks, the third party's laptop, all of them sit outside your controls by definition, and the numbers make clear that prevention alone is losing ground against a market this large and this cheap. So the only complete posture assumes that credentials will leak and watches the market where leaked credentials surface, continuously, so that the interval between "your credential is for sale" and "you know it is for sale" shrinks toward zero. This is the same shift that moves a bank from reacting to a breach to running a defined detect, contain, and report lifecycle for a personal data breach.

This does not replace MFA or endpoint security. Those still raise the cost of the leaks you can prevent, and they should stay exactly where they are. External monitoring is the layer that catches the leaks you cannot prevent, at the one point where the attacker's own economics force the evidence into daylight. Prevention hardens the door. Monitoring watches the market that is openly selling copies of your key. A bank that does the first and not the second has built a strong door and left the key trade unwatched, which is the trade that Verizon's own data says precedes most of these breaches.

How Privy Is Built for This

Privy monitors the credential economy against your identity surface continuously, and it does so for two populations that most tools treat separately: your own employees' corporate logins, and your processors' employees, because a vendor employee's leaked credential frequently carries access straight into your environment. Crucially, Privy does not hand you a raw feed of dark web noise. Every signal runs through attribution, mitigation context, and obligation before it becomes a finding, so what reaches you is scoped rather than screaming. Walk through the failure cases that defeat the login-centric stack, and the difference shows in each one.

The strong password in a stealer log: your policy certified it, and it is compromised anyway, because policy never governed the device it was stolen from. Privy surfaces the listing, attributes the credential to a corporate identity, and flags it as an exposure your internal controls had no way to see.

The live session cookie: MFA is enforced across the estate and, for this finding, irrelevant, because the cookie is proof that authentication already succeeded. Privy distinguishes a leaked password, which enforced MFA still contains, from a leaked session, which it does not, and rates the two differently. One headline, two severities, so the finding that actually bypasses your strongest control is not buried under the one your control already handles.

The personal-device infection: no agent, no internal telemetry, no signal anywhere inside your perimeter, because the theft happened on a machine you never administered. The only place this exposure becomes visible is the market, and the market is exactly where Privy is watching.

The processor employee's credential that opens your door: a vendor login carrying VPN, SFTP, or API access into your systems, sitting in a stealer log, is not a reputational note about a supplier. It is a live path into you, the kind of exposure a mature third-party risk management programme is meant to catch, and Privy triages it as one: rotate and revoke first, investigate second, rather than filing it as a third-party footnote. It is also why vendor contracts are the biggest blind spot in most programmes: the access is real long before the paperwork acknowledges it. And because each finding arrives already interpreted, with whose credential, whether MFA contains it, what it can reach, and what obligation it triggers all attached, your team spends its time responding rather than parsing.

One honest boundary worth stating plainly: external monitoring sees the credentials that reach the criminal market, which is the overwhelming majority of the modern credential vector but not all of it. A password phished and used within hours by an actor who never lists it for sale will not appear in any feed, and monitoring sees the leaked output of an infection, not the infection itself, which is why endpoint prevention stays essential. Timing is imperfect too: the date a credential appears in a feed is the date the market saw it, not the date it was stolen, and some logs surface late. Monitoring narrows the gap between compromise and knowledge. It does not close it, which is precisely why the prevention controls remain in place. They reduce the leaks. Monitoring is how you learn, without waiting for an attacker to demonstrate it, that a leak got through anyway.

Closing: The Right Question for Security Leaders

After a breach headline, the instinct is to audit the door. Are our passwords strong enough, is MFA enforced everywhere, is endpoint detection deployed on every machine? These are reasonable questions, and a bank should be able to answer all three with a confident yes. But notice what every one of them assumes: that the credential that breaches you is one you can still protect. The credential that breaches you next has already been copied, from a device you do not manage, and is already listed for sale, and not one of those three questions will surface it. When one does surface, what privacy incident management actually involves decides how fast you can act on it.

So ask the question that actually maps to how these breaches happen. When one of your employees' credentials, or one of your processors' employees' credentials, is sitting for sale in a stealer log, what tells you? If the honest answer is "the attacker, by using it," then you are scheduled to find out at the single worst moment there is, after the login has already succeeded.

The hard lesson of every recent people-vector breach is not that the attacker was brilliant. It is that the attacker was cheap. They did not need a zero-day or a genius. They needed a valid credential, and the market had one for about ten dollars. You cannot stop every credential from leaking. You can refuse to be the last to know that one did.

If you want to see what your own identity surface looks like from the market's side, the credentials of your employees and your processors' employees that may already be listed, reach out at shivani@idfy.com or book a demo. We'll show you where the trade is happening before an attacker does.

FAQ's

1. What is an infostealer log? 

It is the structured output of infostealer malware running on an infected device: the saved passwords, session tokens, and the addresses of the sites each one unlocks, packaged for sale on dark web markets. A single log represents one infected machine's worth of credentials.

2. Why doesn't a strong password protect against this?

 Because an infostealer reads the password rather than guessing it. It pulls the plaintext straight from the browser's saved-password store, so a forty-character random string and a weak reused password arrive in the log the same way, already resolved and mapped to the site they unlock.

3. If we have MFA everywhere, are we covered? 

MFA neutralises a replayed password, but infostealers also take the authenticated session cookie, which is proof the login already succeeded. Replaying a live session cookie inherits an open session without ever reaching the login, so the second factor is never requested.

4. Doesn't endpoint security stop the theft? 

Only on the devices you administer. The infection that produces the log is usually on a personal laptop, a shared home desktop, or a contractor's own machine, outside your fleet and your EDR. The credential is corporate; the device is not.

5. What is external credential monitoring?

 It is continuous watching of the markets where leaked credentials surface, so the gap between "your credential is for sale" and "you know it is for sale" shrinks toward zero. It catches the leaks prevention controls cannot, at the point the attacker's own economics force the evidence into the open.

6. Does monitoring replace MFA and endpoint security?

 No. Prevention controls still reduce the leaks you can stop and should stay in place. Monitoring is the layer that catches the leaks you cannot prevent. The two work together.

7. Why do processor employees' credentials matter? 

A vendor employee's leaked login often carries VPN, SFTP, or API access straight into your environment. In that case, it is not a note about a supplier's hygiene; it is a live path into your systems, and it needs to be triaged as one.

8. What are the limits of external monitoring? 

It sees credentials that reach the criminal market, which is most of the modern vector but not all of it. A password phished and used within hours, never listed for sale, will not appear in a feed. Feed timing also reflects when the market saw a credential, not when it was stolen. Monitoring narrows the gap between compromise and knowledge; it does not close it.