Refer independent researcher Srikanth’s original resources here: [ Blogpost | PDF report | GitHub Repository ] 

“No security researcher reviewed this system before it went live. No independent auditor tested it. The RBI circular made adoption mandatory—but made security optional,” wrote Srikanth L, who runs Cashless Consumer, a consumer collective focused on digital payments, in his blogpost on how the RBI’s registry of ‘.bank.in’ domains was compromising sensitive data. Read his full report here.

What Happened? In February 2025, the Reserve Bank of India (RBI) created the ‘.bank.in’ domain suffix to be a digital mark of trust, a way for citizens to instantly verify that a website truly belongs to the official bank. Read RBI’s notices here: [ Feb 2025 |  April 2025 ] 

The security of this IDRBT Domain Registration Portal (registrar.idrbt.ac.in) was compromised and could have been exploited by a competent hacker had it not been fixed. However, it was fixed. Here is what happened briefly:

  • The entity responsible for ‘.bank.in’ domains was compromised atleast for 13 months: Srikanth’s investigation reveals that the Hyderabad-based Institute for Development and Research in Banking Technology (IDRBT) exposed its backend system via 33+ unauthenticated endpoints on its ‘.bank.in’ the domain registration portal (registrar.idrbt.ac.in), leaking the sensitive data of thousands of bank employees for at least 13 months.
  • Password hashes, mobile numbers, and emails of over 5,000 bank employees were at risk: In simple terms, anyone with some technical tools (like the command-line tool curl) could query the system without needing a password. They could freely download the encrypted (bcrypt) password hashes, mobile numbers, email addresses, login IPs, and device fingerprints of all 5,576 bank employees tasked with managing India’s banking domains.
  • Banks’ admin access at the private control: Hyderabad-based private vendor, IKCON Technologies, held 22 employee accounts on the portal, three of which had global “Super Admin” access. The investigation also uncovered 1,072 “orphan” Super Admin accounts, accounts with the highest level of access that appeared to have no active or officially traceable owners.
  • CERT-In fixed this in about 17 days: He had reported this vulnerability to India’s cybersecurity agency and got it fixed. Unlike the recent CBSE fiasco, CERT-in responded after 17 days of Srikanth flagging the cybersecurity issue, with CERT-in saying that it fixed the issue. 

The story in numbers: A numbered summary of the breach’s scale and the administrative failures:

  • 5,576: Bank employee credentials exposed (including hashes, mobile numbers, and IPs). Srikanth didn’t publicly publish this because of its sensitive information. 
  • 1,072: Orphan Super Admin accounts found on the system. He didn’t disclose this either because of sensitive information. 
  • 33+: Unauthenticated API endpoints accessible to the public.
  • 0: Public tenders and consultations for the ‘.bank.in’ portal’s creation.
  • 13+ months: The duration when the portal was leaking data—if there were a capable person to access their systems. 
  • 17 days: Time taken by CERT-in to respond to vulnerabilities flagged by Srikanth.

Source code and scripts used for this project are publicly available on GitHub. Access it here. 

A few more points he highlighted in the report are 

  • Zero Public Consultation: Unlike the global ‘.bank’ domain (developed over years with multi-stakeholder input), the RBI-mandated ‘.bank.in‘ domain in February 2025 with no consultation papers, impact assessments, or stakeholder engagement.
  • No Public Tender: The portal was built by IKCON Technologies without any public tender, RFP, or vendor evaluation. The report states that this is a violation of IDRBT’s own 2015 IT procurement handbook. 
  • Violated IDRBT’s public and open tender policy: The report noted that two months before the breach was discovered, IDRBT issued a limited (non-open) tender for Vulnerability Assessment and Penetration Testing (VAPT) of its IT infrastructure, contradicting its own mandate for open tenders on security-critical work.
  • False claims of security: IDRBT’s security privacy policy falsely claimed it was secured by firewalls and “audited for known application-level vulnerabilities before launch.”
  • Data Residency Violations: The report noted that multiple cooperative banks are hosting their ‘.bank.in’ websites on foreign servers (including the US, Lithuania, and Singapore), violating RBI data localisation rules and exposing customers to foreign jurisdiction risks.
  • Mixing of testing and production-ready domains: Test domains (e.g., testtest23.bank.in, ikcontest-aug12.bank.in) and gibberish email registrations were mixed with real banks in the production database. Several of these phantom domains even received active SSL certificates, proving they passed through the full validation pipeline. Notably, rbi.bank.in was registered but doesn’t point to the RBI’s actual website.

Why this should matter: While the leaked passwords were hashed (meaning they were scrambled and not in plain text), attackers can often crack bcrypt hashes given enough time and computing power.

So, if a malicious actor had accessed this data during the 13 months it was exposed, they could have potentially hijacked the accounts of bank employees who manage domain registrations. With that access, an attacker could spoof legitimate banking websites, redirect traffic, or issue fraudulent ‘.bank.in’ domains. Therefore, turning the RBI’s intended trust factor itself into a weapon for phishing and fraud through possible social engineering or otherwise. 

P.S. Thanks to Srikanth for pointing this issue out to us. As always, feel free to send us anonymous tips.

Also Read: