<p> </p>
<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="attack-scenarios-what-if-a-bad-actor-had-found-this-first">Attack
Scenarios: What If a Bad Actor Had Found This First?</h1>
<p>The vulnerability documented in this report was discovered and
responsibly disclosed within 25 minutes. But the portal had been live
for over 13 months. Below are realistic attack chains a malicious actor
could have executed — each one using only the data already accessible
through the unauthenticated endpoints.</p>
<h2 id="scenario-1-phishing-at-scale">Scenario 1: Phishing at Scale</h2>
<p> Under an hour.</p>
<p>An attacker downloads the full user database (5,461 records)
containing names, email addresses, mobile numbers, and organization
names. Each record identifies exactly which bank employee manages which
bank’s domain registration. The attacker crafts personalised
spear-phishing emails:</p>

<p>These emails would appear legitimate because they contain correct
internal details only the real IDRBT portal should know. A single
compromised credential would give the attacker authenticated access to
the portal.</p>
<h2 id="scenario-2-domain-hijacking-via-credential-theft">Scenario 2:
Domain Hijacking via Credential Theft</h2>
<p> A few days to weeks, depending on password strength.</p>
<p>The exposed bcrypt hashes include those of 1,072 orphan Super Admin
accounts — accounts with no organisation association, meaning they can
access any bank’s domain settings. Even bcrypt can be cracked for weak
passwords. A bank employee whose password is something like or would
have their hash cracked in hours.</p>
<p>With Super Admin access, an attacker can:</p>

<h2 id="scenario-3-the-invisible-redirect">Scenario 3: The Invisible
Redirect</h2>
<p> Minutes with portal access.</p>
<p>An attacker with portal credentials changes the A record for (a real
cooperative bank) from the legitimate server IP to a phishing site
hosted on a cheap overseas server. The SSL certificate on the phishing
site is obtained via Let’s Encrypt — free, automated, and requiring no
identity verification. Since does not mandate EV/OV certificates or
Certificate Authority Authorization, the browser shows a green padlock
next to the fake site.</p>
<p>A customer checking their balance sees a page that looks identical to
their bank’s website. They enter their username, password, and OTP. The
attacker now has everything needed to drain their account. The customer
has no way to know — every visible signal (the domain, the padlock icon,
the familiar layout) tells them this is legitimate.</p>
<h2 id="scenario-4-insider-threat-amplification">Scenario 4: Insider
Threat Amplification</h2>
<p> Instant.</p>
<p>The exposed data includes device fingerprints and login IP addresses
of every registered user. An attacker can map which employees have Super
Admin access versus regular user access, which organisations have the
weakest security postures (cooperative banks with minimal IT staff), and
which employees have not logged in recently (orphaned or stale accounts
ripe for takeover).</p>
<p>This intelligence would allow a nation-state actor or organised
cybercrime group to target the weakest link in the trust chain with
surgical precision.</p>
<h2 id="key-takeaway">Key Takeaway</h2>
<p>None of these scenarios required exploiting a zero-day, bypassing a
firewall, or writing a single line of exploit code. The attacker only
needed . The data was already public. The only reason these scenarios
did not materialise is that CashlessConsumer found the vulnerability
first and reported it responsibly — before any malicious actor did.</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>This gap becomes even more striking given that a separate Limited
Request for Proposal for VAPT (Vulnerability Assessment and Penetration
Testing) of IDRBT’s IT infrastructure was published on April 8, 2026 at
— a limited, non-open tender just two months before the portal
vulnerabilities were discovered. The VAPT RFP itself was a limited
tender, contradicting IDRBT’s own procurement norms that mandate open
tenders for security-critical work.</p>
<p>The portal footer states ``Developed \&amp; Maintained by IDRBT’’ but
technical evidence shows development by \textbf{IKCON Technologies}
(Hyderabad), with 22 employee accounts in the system including 3 with
global Super Admin access. IKCON’s own public website lists the
registrar as a marquee client engagement and claims to have advised over
380 cooperative banks on domain migration , while its core offerings
(Unified Meeting Suite, ResolveGen ticketing system) are unrelated to
banking domain security.</p>
<p>The IDRBT Domain Registration Portal’s Privacy Policy and Terms of
Use, published on the same registrar portal, make explicit security
representations that are directly contradicted by this investigation’s
findings:</p>

<p>These documents remain live on the portal at the time of this
report’s publication .</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: \emph{"If the buyer knows neither his/her
requirements nor about vendors’ capabilities or products, then the IT
project is certain to fail."}</p>
<h3 id="academic-security-research-published-but-ignored">Academic
Security Research — Published but Ignored</h3>
<h3 id="unnecessary-exposure-of-internal-infrastructure">Unnecessary
Exposure of Internal Infrastructure</h3>
<p>The exttt{.bank.in} migration mandate itself created a structural
security problem. Banks were required to migrate all their
internet-facing services to exttt{.bank.in} domains — including internal
systems that should never have been publicly exposed. HRMS portals,
employee self-service platforms, UAT and staging environments, and test
instances of banking applications all received exttt{.bank.in} domains
alongside the main customer-facing banking portal.</p>
<p>This decision multiplies the attack surface. Before the mandate, an
attacker would need to discover a bank’s internal systems through DNS
brute-forcing, CT log analysis, or other enumeration techniques. After
the mandate, the IDRBT portal provides a definitive directory of every
service a bank considers internet-facing — including systems that should
have remained internal. The investigation found domains like
exttt{ikcontest-aug12.bank.in}, exttt{datatest98.bank.in}, and
exttt{testtest23.bank.in} — clearly test or staging systems — alongside
live banking domains. Several of these phantom test domains have active
SSL certificates in public CT logs, confirming they went through the
full domain validation pipeline.</p>
<p>A proper security review before launching the exttt{.bank.in}
namespace would have identified this risk and established policies such
as: prohibiting non-production domains, requiring DMARC and DNSSEC
enforcement as a condition of registration, mandating EV/OV certificates
so domain ownership is verified against legal entity records, and
restricting allowed services types to customer-facing banking interfaces
only. None of these were considered. The global exttt{.bank} TLD, by
contrast, requires all of these as a condition of registry
membership.</p>

<p>No equivalent risk assessment appears to have been conducted for the
exttt{.bank.in} mandate. A simple review before go-live could have
flagged these as avoidable exposures.</p>
<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>



<ul>
<li>IDRBT, , Tender No. IDRBT/SYS/ES/10/2025-2026, April 8, 2026. A
limited (non-open) tender issued just two months before the
vulnerability was discovered. The VAPT did not detect the
unauthenticated API exposure. ()</li>
<li>IDRBT, (undated, portal launched May 2025). The governing terms for
domain registration. ()</li>
<li>IDRBT, (domain registration portal). Contains security
representations including “protected zones with firewalls and IPS”,
“audited for known application-level vulnerabilities before launch”, and
“all known vulnerability was addressed.” Our investigation contradicts
these claims. ()</li>
<li>IDRBT, (August 12, 2025). Online training for bank officers on using
the registration portal.</li>
<li>IDRBT, — Registrant Registration Flow, Registration Terms, and
governing policies.</li>
<li>IKCON Technologies, — Banking Support service line. IKCON claims
“380+ banks migrated” with the portal as a marquee project. ()</li>
<li>Times of India, , December 19, 2025. Reports 889 domains registered
by 747 unique banks. ()</li>
<li>EasyDMARC, . Demonstrates the global standard’s enforcement approach
vs India’s voluntary model. ()</li>
<li>fTLD Registry Services, . Detailed security baseline requirements
for the global TLD. ()</li>
<li>Hacker News, , February 2025. News coverage at launch. ()</li>
</ul>
<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>
