<p>The IDRBT Domain Registration Portal at — the exclusive registry for
banking domains — exposed its entire REST API via 33+ unauthenticated
endpoints. For over a year, anyone on the internet could retrieve bcrypt
password hashes, mobile numbers, email addresses, login IPs, and device
fingerprints for — the people entrusted with managing India’s banking
domains. The trust anchor meant to protect citizens was itself wide
open.</p>
<p> The portal was built by IKCON Technologies without any public
tender, RFP, or competitive process — in direct violation of IDRBT’s own
published procurement handbook (2015). IKCON held 22 employee accounts,
including 3 with global Super Admin access. The namespace itself was
mandated without public consultation, impact assessment, or a published
security baseline, and IDRBT’s own academic research on domain security
was ignored in its implementation.</p>
<p> Of 1,497 registered domains, only match across RBI IFSC and DICGC
insurance records — the rest include phantom test domains, gibberish
registrations, and non-bank entities, several with live SSL
certificates. Unlike the global TLD (which mandates DNSSEC, DMARC ,
HSTS, and EV/OV certificates), enforces none of these: 80% of
cooperative banks lack DNSSEC, 40% have no DMARC, and multiple banks
host customer-facing sites on foreign servers in violation of RBI data
localization rules.</p>
<p> The vulnerability was reported to CERT-In on June 8, 2026. CERT-In
confirmed on June 25, 2026 that IDRBT has fixed the issue. This report
documents the full investigation, findings, and systemic gaps in India’s
banking domain security framework.</p>
<p></p>
<h1 id="introduction">Introduction</h1>
<h2 id="what-is">What is ?</h2>
<p>On February 7, 2025, the Reserve Bank of India announced the creation
of — a dedicated Internet domain namespace for Indian banks, managed by
the Institute for Development and Research in Banking Technology
(IDRBT). The intent was straightforward: create a ``trusted zone’’ where
citizens could verify they were visiting a legitimate bank website.</p>
<p>A domain is supposed to be the digital equivalent of a bank’s
physical branch — you see the name on the door, you know it’s real. The
RBI circular (RBI/2025-26/28, April 22, 2025) mandated that all
scheduled commercial banks, cooperative banks, and regional rural banks
migrate to domains.</p>
<h2 id="why-domain-trust-matters">Why Domain Trust Matters</h2>
<p>When a citizen types into their browser, the suffix serves as a trust
anchor. It answers one question: ``Is this website genuinely operated by
the entity it claims to be?’’</p>
<p>This trust anchor is critical because:</p>
<p>However, domain trust is only as strong as the controls at the
registry. If the registry itself has weak authentication, unpatched
vulnerabilities, and no enforcement of baseline security, the trust
anchor is compromised.</p>
<h1 id="domain-trust-global-vs-india">Domain Trust: (Global) vs
(India)</h1>
<h2 id="background">Background</h2>
<p>The global Top-Level Domain is managed by fTLD Registry Services, a
consortium founded by the American Bankers Association. It enforces the
strongest security requirements of any TLD, including mandatory DNSSEC,
DMARC , HSTS, and certificate authority authorization.</p>
<p>India’s was created as a sub-domain under the existing ccTLD (managed
by NIXI). This architectural choice gives IDRBT far less control over
security policy compared to a full TLD registry, but the security gaps
found go well beyond what is explainable by this distinction.</p>
<h2 id="side-by-side-comparison">Side-by-Side Comparison</h2>

<h2 id="what-the-comparison-reveals">What the Comparison Reveals</h2>
<p>The gap between and is not incremental — it is categorical. On every
measurable security dimension, the global standard imposes mandatory,
enforceable requirements while the Indian equivalent makes them optional
or ignores them entirely.</p>
<p>This is particularly concerning because:</p>
<h1 id="disclosure-timeline">Disclosure Timeline</h1>

<h1 id="impact-assessment">Impact Assessment</h1>
<h2 id="credential-compromise-critical">1. Credential Compromise
[CRITICAL]</h2>
<p>5,576 unique users have bcrypt password hashes exposed across
multiple unauthenticated endpoints. Weak passwords (common for
inter-bank portals) can be cracked offline. Affects employees of Indian
banks, cooperative banks, and financial institutions.</p>
<h2 id="account-takeover-risk-high">2. Account Takeover Risk [HIGH]</h2>
<p>With recovered credentials, attackers can log in to the portal and
manage domain registrations for .IN banking domains, DNS settings, and
billing. Domain hijacking could redirect banking traffic.</p>
<h2 id="phishing-at-scale-high">3. Phishing at Scale [HIGH]</h2>
<p>Exact user list, mobile numbers, email addresses, organization names,
and invoice context enable highly targeted spear-phishing against
banking staff.</p>
<h2 id="domain-hijacking-risk-high">4. Domain Hijacking Risk [HIGH]</h2>
<p>With portal access, an attacker could transfer domain registrations,
change DNS records to redirect banking traffic, or modify billing
information.</p>
<h2 id="reputational-damage-medium">5. Reputational Damage [MEDIUM]</h2>
<p>The national banking domain registrar under RBI purview leaking user
data and financial records undermines trust in India’s banking digital
infrastructure.</p>
<h2 id="systemic-weakness-medium">6. Systemic Weakness [MEDIUM]</h2>
<p>No mandatory DMARC, DNSSEC, HSTS, or CAA enforcement. The global TLD
requires all of these. India’s requires none.</p>
<h1 id="domain-triangulation">Domain Triangulation</h1>
<h2 id="methodology">Methodology</h2>
<p>IDRBT’s database of registered domains was cross-referenced against
two authoritative datasets:</p>
<h2 id="results">Results</h2>
<p> Cross-referencing these three datasets is harder than it looks.
Banks use varying legal names across registries
(e.g. <code>State Bank of India'' vs</code>SBI’’, cooperative banks with
regional names in multiple scripts), the IDRBT domain list does not
carry a canonical organisation identifier, and IFSC/DICGC records key
off different naming conventions. A domain that fails to match is not
necessarily fake or invalid — it may simply use a name the
fuzzy-matching did not catch. The figures below should therefore be read
as indicative findings rather than a precise count of illegitimate
domains.</p>
<p>The cross-reference surfaced the following categories:</p>
<h1 id="systemic-issues">Systemic Issues</h1>
<h2 id="testproduction-overlap">Test/Production Overlap</h2>
<p>Multiple test domains were found alongside real banks in the
production database:</p>
<p>These phantom domains are not just administrative noise — several
have active SSL certificates in Certificate Transparency logs,
confirming they went through the full domain validation pipeline.</p>
<h2 id="no-public-tender">No Public Tender</h2>
<p>No public tender, RFP, or contract award for the development of the
Domain Registration Portal was found across:</p>
<p>The portal footer states ``Developed &amp; Maintained by IDRBT’’ but
technical evidence shows development by (Hyderabad), with 22 employee
accounts in the system including 3 with global Super Admin access.</p>
<h2 id="data-residency-violations">Data Residency Violations</h2>
<p>Multiple cooperative banks were found hosting their websites on
foreign servers:</p>
<p>This raises serious concerns about compliance with RBI data
localization requirements and exposes cooperative bank customers to
foreign jurisdiction risks.</p>
<h2 id="procurement-governance">Procurement &amp; Governance</h2>
<p>Beyond the technical vulnerabilities, an equally troubling picture
emerges from how the registry was procured, designed, and governed.</p>
<h3 id="no-public-consultation-on-design">No Public Consultation on
Design</h3>
<p>RBI announced in its bi-monthly monetary policy statement on February
7, 2025 — not through a consultation paper, draft circular for public
comment, or any stakeholder engagement process. The formal circular
(RBI/2025-26/28, April 22, 2025) was issued with immediate effect,
giving banks barely six months to migrate. Unlike the global TLD — which
was developed over years through multi-stakeholder consultation
involving the ABA, fTLD Registry, financial institutions, and security
researchers — India’s was designed and mandated in near-total opacity.
No green paper, white paper, or impact assessment was published.</p>
<h3 id="idrbts-own-procurement-handbook-violated-for">IDRBT’s Own
Procurement Handbook — Violated for </h3>
<p>IDRBT literally wrote the book on public procurement. In 2015, it
published — a comprehensive 32-page handbook authored by Dr. G.R.
Gangadharan (Assistant Professor, IDRBT) with a foreword by
then-Director Dr. A.S. Ramasastri. It was meant to teach banks how to
procure IT properly.</p>
<p>IDRBT then violated multiple principles from its own handbook for the
portal:</p>
<p>The handbook itself warns: </p>
<h3 id="academic-security-research-published-but-ignored">Academic
Security Research — Published but Ignored</h3>
<p>IDRBT is primarily a research and training institute. Its academic
staff have published multiple papers on domain security, DNSSEC
deployment, and cybersecurity benchmarks for the banking sector. Yet
none of this research appears to have informed the implementation. The
registry mandates none of the security controls that IDRBT’s own
researchers have argued for in peer-reviewed literature — no DNSSEC
requirement, no DMARC enforcement, no EV/OV certificate mandate, no data
residency verification. Research that could have shaped a
secure-by-design registry was published, filed, and apparently ignored
by the same institution.</p>
<h3 id="what-should-have-happened">What Should Have Happened</h3>
<p>A proper process would have included:</p>
<p>None of these happened. India’s banking namespace — meant to be a
trust anchor — was built without the trust-building processes that
public infrastructure deserves.</p>
<h1 id="methodology-1">Methodology</h1>
<p>All findings in this report were obtained using only passive and
non-invasive techniques. No exploit was written, no payload was
delivered, and no authentication was bypassed through active means.</p>
<p></p>
<p>All findings can be independently verified using the following
techniques:</p>
<h3 id="unauthenticated-api-access">Unauthenticated API Access</h3>

<h3 id="phantom-domain-detection">Phantom Domain Detection</h3>

<h3 id="data-residency-check">Data Residency Check</h3>
<p> Public APIs, CT logs, DNS, client-side source code. \ No password
cracking, no stolen tokens, no injection, no brute force.</p>
<p></p>
<p>Every finding in this report can be independently reproduced by any
researcher with and . No specialized tools, authenticated access, or
exploit code is required. This is not a testament to sophisticated
research — it is evidence of how fundamentally broken the access
controls were.</p>
<h1 id="recommendations">Recommendations</h1>
<h2 id="immediate-confirmed-fixed-by-cert-in">Immediate (Confirmed Fixed
by CERT-In)</h2>

<h2 id="short-term">Short-term</h2>

<h2 id="long-term-governance">Long-term (Governance)</h2>

<h1 id="open-data">Open Data</h1>
<p>All non-sensitive datasets from this investigation are published for
independent verification and further research. No PII, bcrypt hashes, or
sensitive data is included in published datasets.</p>
<p>The domain list from this investigation feeds into the project at — a
daily automated audit of and parallel Indian financial TLDs. Every day
at 02:30 UTC, it discovers new subdomains from Certificate Transparency
logs, Wayback Machine, urlscan.io, and HackerTarget, then probes each
one for DNS resolution, HTTPS reachability, HTTP status codes, and page
titles. Results are published as CSV, JSONL, Parquet, and SQLite.</p>
<p>This data enables the broader public to build their own monitoring
tools — including uptime monitors like which tracks the live status of
Indian banking and financial domains in near real-time. Any researcher,
journalist, or concerned citizen can use the open data to independently
verify which bank websites are operational and which have security
gaps.</p>
<p>Source code and scripts for all analysis: </p>
<h1 id="conclusion">Conclusion</h1>
<p>The namespace is a well-intentioned initiative to create a trusted
zone for Indian banking. However, the investigation reveals fundamental
gaps at every level of the trust chain:</p>
<p> CERT-In confirmed the vulnerability is fixed. The exposed endpoints
are no longer accessible.</p>
<p> The fix addresses the immediate API exposure but does not address
the systemic issues documented in this report — the lack of mandatory
security baselines, the absence of public procurement, the data
residency gaps, or the phantom domain problem.</p>
<p> No exploit code or active attack paths are included. All data was
obtained from publicly accessible APIs with no authentication bypass —
no brute force, no injection, no privilege escalation was used.</p>
<p> \ \ </p>
<h1 id="responsible-disclosure">Responsible Disclosure</h1>
<p>This investigation was conducted under standard responsible
disclosure principles.</p>
<p> June 8, 2026, 05:30 UTC — filed with CERT-In () within 25 minutes of
discovery.</p>
<p> June 8, 2026, 07:30 UTC — extended findings including orphan users,
phantom domains, and DSC proxy exposure.</p>
<p> June 25, 2026 — CERT-In confirmed IDRBT has fixed the
vulnerability.</p>
<p></p>
<p>The vulnerability was present for approximately 13 months (May 2025 –
June 2026). CERT-In’s confirmation of the fix means the exposed
endpoints are no longer accessible. However, we cannot confirm how long
the exposure existed before discovery, or whether any malicious actor
accessed the data during that period.</p>
<h1 id="references">References</h1>

<h1 id="appendix-a-explain-it-like-im-five-eli5">Appendix A: Explain It
Like I’m Five (ELI5)</h1>
<p>India’s central bank (RBI) created a special internet address ending
in so that people could tell real bank websites apart from fake ones.
The idea was good: if a website ends in , you should be able to trust
it’s a genuine bank — like seeing a government stamp on a document.</p>
<p>The company in charge of handing out these special addresses (IDRBT)
built a website to manage them. But that website was left wide open.
Anyone in the world — with no password, no login, nothing — could look
up the private details of thousands of bank employees: their email
addresses, phone numbers, and scrambled versions of their passwords. For
over a year.</p>
<p>Someone left the keys to India’s banking ``trusted zone’’ under the
doormat for over a year. A researcher found it, reported it quietly, and
it’s now locked. But the house itself still needs better locks, alarm
systems, and rules about who gets to build the next one.</p>
<h1 id="appendix-b-glossary">Appendix B: Glossary</h1>
<p></p>
