The 31-Month Warning
In July 2026 a data-extortion group listed Bank of Baroda and offered roughly a terabyte of customer data as a free download. Working corporate credentials for the bank had been circulating in criminal marketplaces since October 2023. This is what was visible, and when.
Executive Summary
On 24 July 2026, the Triple X data-extortion group listed Bank of Baroda on its leak site, claiming approximately 1 TB of customer data including account-opening forms and photographs of customers holding identity documents. The listing states an attack date of 12 May 2026. No ransom was demanded the data was offered free. The incident was reported by Indian national press; the bank had issued no public statement at the time of writing.
TechOwl analysed the bank's externally observable credential exposure using commercially available infostealer and combolist data. We found no zero-day and no novel tradecraft. We found 239 working corporate credentials already publicly purchasable on the day of the claimed attack and three unmissable escalation signals in the eight months before it.
The warning was neither subtle nor hidden. It simply appeared somewhere nobody was looking: criminal marketplaces, employees' personal laptops, and public DNS records — rather than inside the bank's own systems.
By the Numbers
What Happened
| Attribute | Value |
|---|---|
| Threat actor | Triple X — data-extortion group, emerged May 2026 |
| Attack date (per actor) | 12 May 2026 |
| Publicly listed | 24 July 2026 — 73 days later |
| Claimed volume | ~1 TB (unverified) |
| Ransom | None ; offered as a free download |
| Claimed contents | Account-opening forms; photographs of customers holding national identity cards; retail and corporate net-banking, loan and NRI records |
Three details make this case unusual and instructive for every bank.
The data was free. No ransom means no negotiation window and no leverage. By the time a victim learns of a free release, the data is already public and redistributed. Containment is never an available option , only damage limitation and customer protection.
Ten weeks elapsed between attack and listing. Any incident scoping that begins at the listing date misses the entire intrusion. Log-retention windows are usually the binding constraint, and they are set years before the day you need them.
The claimed data class was identity documents, not a database extract. That points at a document store rather than a core banking system and a photograph of a customer holding their ID card defeats precisely the control that artefact exists to provide.
Attack & Exposure Timeline
We deduplicated 3,692 raw records from commercial infostealer and combolist sources down to 2,741 unique credential events across 967 corporate accounts and 142 infected machines, then asked one question: on the day of the attack, what was already public?
| Measure | Identity provider | Whole corporate estate |
|---|---|---|
| Unique accounts exposed | 505 | 967 |
| Already circulating on the attack date | 239 · 47% | 631 · 65% |
| Oldest credential still in circulation | October 2023 | December 2020 |
| Warning window | 31 months | 65 months |
Harvesting against the bank's identity provider was not a steady trickle. It changed regime three times, and each change was large enough to be unmissable in a monitoring feed.
Credential records captured per month; identity provider
Red bars mark the claimed attack month (May 2026) and the post-attack peak (June 2026). The three labelled increases are the escalation signals described below.
View as table
| Month | Records | New accounts | Cumulative |
|---|---|---|---|
| Jun 2025 | 1 | 1 | 8 |
| Jul 2025 | 1 | 1 | 9 |
| Aug 2025 | 1 | 1 | 10 |
| Sep 2025 | 22 | 9 | 19 |
| Oct 2025 | 55 | 10 | 29 |
| Nov 2025 | 41 | 8 | 37 |
| Dec 2025 | 120 | 21 | 58 |
| Jan 2026 | 63 | 18 | 76 |
| Feb 2026 | 51 | 37 | 113 |
| Mar 2026 | 159 | 64 | 177 |
| Apr 2026 | 117 | 50 | 227 |
| May 2026 — attack | 170 | 90 | 317 |
| Jun 2026 — peak | 292 | 138 | 455 |
| Jul 2026 — partial | 126 | 50 | 505 |
The highest month on record is June 2026 after the attack. Harvesting did not slow following the incident; the rate more than doubled, from 4.97 records per day before to 11.03 after. There is no containment inflection at either the attack date or the listing date. Whatever remediation occurred did not reach the infected endpoints.
Plotting the same data cumulatively makes the point that monthly counts obscure: exposure did not appear suddenly. It accrued for two and a half years, and the curve was already steepening months before anyone acted on it.
Cumulative identity-provider accounts exposed
Each step is an account appearing publicly for the first time. By the claimed attack date, 239 of the eventual 505 were already in circulation — the oldest for 31 months.
Compromised Device Analysis
We sampled 38 of the infected machines in depth, retrieving their full credential sets rather than only the bank-related entries. The result was consistent and unambiguous.
| Signal | Result |
|---|---|
| Machines carrying personal webmail accounts | 38 / 38 |
| Machines with consumer gaming or entertainment logins | 36 / 38 |
| Machines matching the bank's corporate naming convention | 1 / 142 |
| Machines with no antivirus product recorded | ~2 in 3 |
| Source addresses on consumer ISPs | All of them |
These were not corporate endpoints. Windows profile names were manufacturer defaults LENOVO, HP, acer. One machine carried 214 personal Gmail
accounts alongside a cracked game launcher. Another sat next to a school domain, streaming
services and personal banking at a different bank.
The geography told the real story. Exposure spread across provincial cities Vadodara, Kanpur, Nagpur, Prayagraj, Jabalpur, Moradabad, Amritsar, Guntur rather than clustering around corporate offices. This is not a work-from-home programme. This is branch and field staff signing in to corporate systems from personal, family-shared computers on home broadband and mobile data.
Infections arrived through pirated software, keygens and licence loaders — and in nine cases through children's game installers.
Two-thirds of infected machines had no antivirus at all. Every machine that did report a product was running it at the moment credentials were successfully stolen. More importantly: these machines were never in the corporate estate. No amount of patching or EDR rollout on managed devices touches a laptop the bank does not own.
Attribution Analysis
Consistent with: commodity infostealer → credential resale → hands-on intrusion
The credentials were captured at the moment of sign-in, as users typed them. They are not hashes to crack or guesses to validate they are known-good working credentials. One record in our dataset carried a Telegram resale channel watermark, confirming commercial circulation.
Roughly 26% of the corpus was duplicate republication across sources, which is itself evidence of wide resale rather than a single closely-held collection.
Credential Hygiene — The Multiplier
Reducing every observed password to its character shape reveals a population that is not random. The most common shapes are a capitalised word followed by a symbol and a short number. Over half of all accounts shared a password with at least one other account.
- One password was shared by 129 accounts. A single guess would authenticate as roughly a quarter of the exposed population.
- Another had been in circulation for 64 months — over five years — spanning unrelated third-party platforms. That makes it an administratively issued convention rather than individual user error.
- 81% of usernames followed
firstname.lastname, making the namespace predictable without any reconnaissance.
Combine a predictable username scheme with a templated password convention and the arithmetic becomes uncomfortable: an attacker does not strictly need stolen credentials at all. The stolen credentials merely prove the pattern holds.
How Little the Takeover Required
Four things had to be true for a stolen password to become a permanently owned corporate account. All four were true. None of them required skill.
No address, no path, and no protocol detail appears in either capture or anywhere in this article. Both were single page loads with no credentials submitted. They are included so that defenders recognise the same two pages in their own estate because this configuration is common, not because it is unique to one bank. Every organisation running legacy federation should check for both.
The Rewind — Same Attack, With Monitoring
Run the same timeline against an organisation with continuous credential monitoring and three independent opportunities appear. Any one of them breaks the chain.
| When | Signal | Available response |
|---|---|---|
| Sep 2025 8 months before |
Collection jumps from 1 record/month to 22 | Investigate the regime change; reset affected accounts while they number in single figures |
| Dec 2025 5 months before |
120 records in one month; 21 accounts newly exposed | Exposure is no longer dismissible as background noise; escalate to conditional access |
| Mar 2026 2 months before |
New accounts nearly double while total records triple | Treat as active targeting; force estate-wide reset and device-compliance enforcement |
None of these signals required privileged access, an incident, or a tip-off. All three were observable in commercially available data, for a subscription cost trivial next to the cost of the outcome.
MITRE ATT&CK Mapping
Observed and assessed techniques across the exposure chain:
T1204.002 and T1555.003 are directly evidenced in observed malware paths. T1078 and T1110.003 are assessed as consistent with the actor's stated method — not confirmed.
Mitigation Guidance
Identity & Endpoint Hardening
- Require a compliant, managed device for corporate sign-in. This single control closes the entire class of exposure described above. Patching and EDR on the managed estate do not because the affected machines were never in it.
- Verify multi-factor authentication is enforced on every authentication path, not only the one your team tested in a browser. Legacy federation platforms commonly publish more than one way in.
- Deploy a banned-password list seeded with your own brand words and the shapes actually in use. A reset without this simply regenerates the same convention.
- Audit for shared passwords across accounts. If one password authenticates 129 people, your blast radius is the password not the account count.
Continuous Monitoring
- Monitor infostealer and combolist feeds for your corporate domains continuously. Point-in-time assessments miss regime changes, and regime change is the signal.
- Alert on rate of change, not absolute volume. Twenty-two records is a small number and easy to dismiss but it was a 2,100% increase, and the single most actionable signal in the entire dataset.
- Track first-seen dates per account. Cumulative exposure curves reveal targeting that raw counts hide.
- Extend monitoring to subsidiaries, joint ventures and merged-entity domains. Exposure does not respect org charts.
This Was Visible Before It Happened
Every organisation we assess believes it would have caught this. Most would not have and the reason is structural rather than technical. The warning signs did not appear inside the bank's own systems. They appeared in criminal marketplaces, on employees' personal laptops, and in public DNS records: three places almost nobody monitors, and none of which raise a SIEM alert.
The bank had a security operations centre. It had a web application firewall that demonstrably worked. Its newest infrastructure was among the best-defended we assessed. None of that mattered, because the credentials were stolen from devices the bank did not own and replayed as authentication events indistinguishable from the real employee.
Don't wait for the leak-site listing
TechOwl SHIELD monitors credential exposure, attack surface and brand abuse continuously for banks and financial institutions. If you would like to know what is currently purchasable about your organisation, we can tell you this week.
