India's Banking Domain Registry Leaked Credentials for Over 5,500 Bank Employees

The Irony of a Security Mandate

When the Reserve Bank of India introduced the .bank.in subdomain in 2025, the intent was straightforward: create a trusted namespace that would make it harder for criminals to impersonate financial institutions online. Every bank operating in India, numbering in the thousands, was required to register and migrate to the new domain structure. The policy aimed to establish a clear signal to customers that they were interacting with legitimate banking sites, not phishing traps.

Instead, the initiative itself became a security liability. The Institute for Development and Research in Banking Technology (IDRBT), appointed as the exclusive registrar for the namespace, operated a domain registration portal that exposed sensitive information on more than 5,500 bank employees for over a year. The breach underscores a pattern we've observed across Asia: ambitious digital mandates often outpace the security infrastructure needed to support them.

What Was Exposed

Security researcher Srikanth L documented the flaw in a detailed technical report published in late June. The registration portal operated by IDRBT exposed 33 unauthenticated REST API endpoints, accessible to anyone with basic command-line tools. No authentication was required. No rate limiting was in place. The data available through these endpoints included bcrypt password hashes, mobile phone numbers, email addresses, login IP addresses, and device fingerprints for every authorized user managing .bank.in domains.

These users are not ordinary bank customers. They are the technical staff and domain administrators entrusted with maintaining the online presence of India's banking institutions. Access to their credentials and contact information opens multiple attack vectors: credential stuffing, social engineering, targeted spear-phishing, and even direct account takeover if the bcrypt hashes prove weak or if passwords have been reused across services.

Srikanth L disclosed the vulnerability to IDRBT in early June. The institute has since closed the open endpoints, but the portal operated in this state for approximately 13 months, from its launch until the fix was applied. During that window, any attacker with knowledge of the endpoints could have harvested the same data.

Infrastructure Weaknesses Beyond the Leak

The researcher's investigation revealed problems that extend beyond the API exposure. By querying the accessible data, Srikanth L mapped the broader security posture of India's banking domain infrastructure and found significant gaps.

Around 80 percent of registered .bank.in domains do not implement DNSSEC, the DNS security extension that helps prevent cache poisoning and spoofing attacks. Without DNSSEC, an attacker who compromises DNS records can redirect users to fraudulent sites, the exact threat the .bank.in namespace was designed to mitigate.

Roughly 40 percent of domains lack DMARC, the email authentication protocol that verifies sender identity and helps block spoofed messages. In an environment where phishing remains the dominant threat to retail banking customers, the absence of DMARC is a glaring oversight.

The researcher also identified banks hosting their .bank.in sites on shared servers located in the United States, Singapore, and Lithuania. While offshore hosting is not inherently insecure, it complicates jurisdiction, incident response, and regulatory oversight, especially when the policy goal was to create a trusted, domestically controlled namespace.

Many domains are secured with free Let's Encrypt certificates. These certificates are cryptographically sound, but their automated issuance and short validity periods can create operational risk if renewal processes are not properly monitored. For institutions handling sensitive financial transactions, certificate management is not a trivial concern.

The Regulatory Vacuum

At DailyTechWire, we've tracked the rollout of domain security initiatives across several Asian markets, including South Korea's financial certificate mandates and Singapore's push for centralized digital identity. What distinguishes the Indian case is the regulatory silence following disclosure.

Neither the Reserve Bank of India nor IDRBT has issued a public statement on the breach. India's Computer Emergency Response Team (CERT-In), the national cybersecurity coordination body, has not published an advisory. The absence of official comment leaves banks, their customers, and the broader financial sector without guidance on whether credentials were accessed, what mitigation steps are being taken, or how oversight of the registry will be strengthened.

This silence is particularly troubling given the scope of the exposure. If attackers did access the data during the 13-month window, they now possess a roadmap to India's banking infrastructure, including the identities and contact details of the individuals responsible for domain security at each institution. That information can enable highly targeted attacks, including business email compromise and credential harvesting campaigns that would be difficult to distinguish from legitimate administrative communications.

A Mandate Without Enforcement

The .bank.in policy was implemented through regulatory directive, not through competitive procurement or phased rollout. IDRBT, a research institute under the Reserve Bank of India, was designated as the sole registrar. This centralization was intended to ensure consistency and control, but it also created a single point of failure.

The researcher's findings suggest the portal was deployed without a comprehensive security audit. The presence of 33 open API endpoints, many returning sensitive user data without authentication, points to a lack of secure development practices and pre-launch penetration testing. For a system designed to anchor trust in India's banking ecosystem, the oversight is striking.

Srikanth L has published some of the accessed data in a public GitHub repository, framing the release as a resource for security researchers to understand the scale and architecture of India's banking domain infrastructure. While transparency can aid defense, the publication also means that information previously available only to those who knew to look for the open API is now indexed and searchable, potentially lowering the barrier for opportunistic attackers.

What This Means for Regional Banking Security

India's banking sector has been a leader in digital payments innovation, from the Unified Payments Interface (UPI) to the rollout of biometric authentication through Aadhaar. But infrastructure security has not always kept pace with adoption. The .bank.in incident illustrates the risk of mandating new systems without ensuring the operational security of the entities tasked with managing them.

For regional observers, the case raises questions about how domain security initiatives should be governed. Centralized registries offer control and consistency, but they also concentrate risk. Distributed models, where multiple accredited registrars compete, can introduce redundancy and market discipline, but they complicate oversight and standardization.

The lack of DNSSEC and DMARC adoption among registered banks suggests that compliance with the .bank.in mandate was treated as a checkbox exercise, not as an opportunity to harden security posture. This pattern is not unique to India. Across Southeast and South Asia, we've observed regulatory mandates that are implemented in name but not in depth, often because penalties for non-compliance are weak or enforcement is inconsistent.

Looking Forward

The IDRBT has closed the vulnerable endpoints, but the broader questions remain unresolved. Were the exposed credentials accessed by malicious actors during the 13-month exposure window? What steps are being taken to rotate compromised credentials and notify affected banks? Will the Reserve Bank of India conduct an independent audit of the registry's security practices and publish the findings?

Until those questions are answered, the .bank.in namespace remains a trust anchor with a documented history of insecurity. For a policy designed to protect customers from phishing and fraud, that is an uncomfortable legacy. The incident serves as a reminder that security mandates are only as strong as the systems built to enforce them, and that transparency, both in design and in response to failure, is essential to maintaining trust in digital infrastructure.