Inside an Indian Data Brokerage Running on Unauthorized KYC Access

Key Findings

The catalog spanned identity, financial, employment, telecom, and vehicle records. A single vehicle registration number, priced at INR 5 or roughly USD 0.06, returned the owner's full name, father's name, present and permanent addresses, pincode, and mobile number. Across the whole catalog, sold through both a public Telegram bot and a business API platform at prices from INR 5 to INR 700, roughly USD 0.06 to USD 8.00, a buyer could obtain:

• Identity: full name, father's name, gender, age range, PAN card details, and Aadhaar validity with the last four digits and whether a mobile number was linked
• Location and contact: present address, permanent address, pincode, mobile number, and email address
• Financial: full CIBIL credit score and report, full Experian credit report as a PDF, financier, insurance company, policy number and cover validity, FASTag balance and linked bank, and LPG subsidy linkage
• Employment: UAN, and complete employment history including employer names and dates of exit
• Corporate: GST registration details and company directorships by DIN
• Telecom: subscriber name, address, operator, connection type and circle, plus the phone number behind a Telegram username
• Vehicle and behavioral: registration, engine and chassis numbers, make, model and variant, fuel type and manufacturing date, OEM service and accident repair history with workshop and cost detail, and paid and pending traffic violations with locations
• Official documents: the Registration Certificate and the driving license, as downloadable PDFs

No consent from the person whose data was sold. No check on who was asking or why.

• No government database was breached, and credentials tied to three licensed organizations were in use on the platform. The operator held credentials belonging to Invincible Ocean, SurePass[.]io, and TruthScreen[.]com (AuthBridge), and ran ordinary queries through ordinary channels. From upstream, the traffic was indistinguishable from a paying customer in good standing. The SurePass bearer token was issued in February 2024 and carries an expiry claim reading February 2044, and it was verifying real Aadhaar numbers against India's national identity database for more than seven months. Nothing in the chain re-checked who was holding it. Read the note below on what that does and does not mean.
• A Mahindra production cloud key was exposed and live. A private key linked to a Mahindra India production Google Cloud environment was embedded in a public Cloudflare Worker. It minted working access tokens for anyone who called the URL, with no password and no login, for more than seven months.
• One access path remained open at the time of publication. Following our disclosure the Invincible Ocean credentials were revoked, the SurePass token stopped authenticating, and the Mahindra worker stopped minting tokens. The Suzuki worker referenced in the platform's own configuration never responded to testing, so we cannot confirm a working credential existed there at all. One of the two TruthScreen proxy workers was still returning full VAHAN records, including owner contact numbers. AuthBridge did not respond to our disclosure, and we re-reported the continuing exposure to CERT-In ahead of publication.
• The vehicle pipeline was addressable against the entire national fleet. A registration number is public by design, so any vehicle a buyer could see could be converted into a name, home address, and mobile number for INR 5. That places more than 350 million registered vehicles inside theoretical reach, including those belonging to government, judicial, military, and press figures. The observed logged volume was 1,793 queries, and we found no evidence of systematic exploitation at scale.
• This model leaves nothing to investigate. The major identity data breaches on record became public because an intruder broke in and left forensic evidence, or because an authorized user's queries carried their name in an audit log. A six-cent API call through a Telegram bot produces no intrusion, no anomaly in the provider's logs, and no accountable buyer. The absence of a detectable event is a property of the business model rather than an accident of this case.
• Cyderes research and disclosure drove the takedown. Howler Cell identified the operation, traced it back to the licensed providers supplying it, and reported the findings to CERT-In and each affected organization on 1 June 2026. Attribution to the handle MRXISBACK is assessed with moderate confidence, and the activity may involve more than one person. The original channel and most of its bots went offline in the weeks that followed. The pre-disclosure backup channel held 21,329 subscribers. The channel rebuilt in July 2026 holds roughly 2,230, close to a 90 percent loss of audience. One bot survived as an anchor while everything else was re-registered, making this a partial rebuild rather than a clean restart.

What We Did and Did Not Find

We did not confirm that Invincible Ocean, SurePass[.]io, TruthScreen[.]com (AuthBridge), or Mahindra India were compromised. That is not what this report claims.

We found that credentials and keys tied to these organizations were exposed and in active use on external systems, with no indication those systems were authorized to hold them. How the credentials left their owners' control is a separate question this investigation could not answer. That distinction matters. An exposed credential is a serious problem on its own, and it is a different problem from a confirmed breach of the company that issued it.

One of the exposures described here was still open when this was published. Where that is the case, we withhold the identifying details of the endpoint. We describe only what it returns, and we report the continuing exposure to CERT-In rather than leaving it unattended. Every worker URL, project identifier, and service account in this report is redacted for that reason.

Summary

For less than a cup of roadside chai, anyone could buy a stranger's complete identity profile. The seller ran a Telegram bot with a tidy menu, tiered pricing, and a payment link that behaved like any other consumer app.

The access behind it was genuine. A licensed Indian identity-verification provider had issued an API token in February 2024 and set it to expire in 2044. Two years into that twenty-year window, it was verifying strangers' Aadhaar numbers at six cents a query. To our knowledge, no one at the top of the chain knew, and no one in the middle appears to have checked.

"Aadhaar" and the "RC Book"

Two terms in this report are specific to India, and the first one carries most of the weight.

Aadhaar is India's national identity system and the single most important credential a citizen holds. Enrollment captures name, date of birth, gender, and address, together with biometrics: ten fingerprints, two iris scans, and a facial photograph. More than a billion people are enrolled, making it the largest biometric identity database in the world.

The number matters because everything else attaches to it. Opening a bank account, registering a SIM card, filing taxes, claiming a subsidy or a pension, and completing most KYC checks in India all run through Aadhaar. Confirming that a given Aadhaar number belongs to a given person is therefore a strong identity confirmation, which is why the Aadhaar Act restricts who may collect and store it, and why the number is normally displayed masked to its last four digits.

The endpoint on sale here did not return biometrics. It confirmed that an Aadhaar number was valid and returned the demographic attributes UIDAI holds against it, including age range, state, gender, and whether a mobile number was linked. That is enough to establish that a person is who a buyer believes them to be, which is the function banks and lenders pay for.

The second term is narrower.  When someone buys a vehicle in India, the government issues a Registration Certificate, commonly called the RC book, which records the owner and their personal details. Like Aadhaar, it is meant to be private.

Why This Is Not Another Breach-Dump Story

India has seen a run of reporting on Telegram bots selling citizen data, and this operation belongs to a different category. Those bots resold breach dumps. Their records came from leaked databases, were often years stale, and degraded as they aged. This operation queried live systems of record in real time, through licensed intermediaries, using credentials issued to legitimate companies. The records it sold were current because they came from the authoritative source at the moment of the query.

The operation sits in India, and the data it sold is Indian. The architecture is not specific to India. It runs on the stack any legitimate software business uses. Regulated identity providers at the top, resold API access in the middle, a self-serve portal with an analytics dashboard at the bottom, and a mainstream payment processor collecting the money.

That points to a structural weakness in how identity-verification-as-a-service is commonly designed. Trust attaches to the API key rather than to the person holding it, and nobody downstream checks whether the person being looked up agreed to any of it.

The cost to run a single lookup was tiny, and the price charged was tiny too, just a few rupees. The platform's own records logged 1,793 API calls, backed by an internal ledger of 694 credit movements. What made it work was the price point rather than the volume. Identity and vehicle records sold for as little as INR 5, roughly USD 0.06, cheap enough to make a lookup an impulse purchase and low enough that almost anyone could afford to pull a stranger's details.

The operator sold the same data through two channels at once. Telegram served individual buyers who wanted a single lookup. authsure[.]in served companies that wanted to plug the data into their own products. Same data behind both, two kinds of customers.

Along the way we found something unrelated. A live production cloud key for Mahindra India, sitting in a public Cloudflare Worker, minting valid access tokens on demand for more than seven months.

The economics are what make this dangerous. Enumerating every registered vehicle in India would cost around USD 20 million, and nobody attempted it. Identifying every vehicle in a single car park costs about USD 11. This is precision surveillance priced as an impulse purchase. Unlike the large identity breaches on record, it leaves nothing behind for anyone to investigate.

Responsible Disclosure

Howler Cell Threat Research Team reported these findings to each affected organization and to CERT-In, India's national cybersecurity authority, on 1 June, 2026. The reports went out ahead of any public release, in line with our responsible disclosure policy, which provides a 60-day window before publication. That window has elapsed. 

Our disclosure covered authsure[.]in, the Telegram service, and the organizations whose credentials were found in use on that infrastructure. We did not notify Hyundai, Spinny, Cars24, or the telecom operators whose records appeared in the catalog, because the logs are the only evidence available and they do not establish that any of those entities were breached.

On re-checking credential liveness in early August 2026, one exposure was found still open. The Suzuki worker was also re-checked and remains unresponsive, consistent with our original testing. Until that exposure is closed, vehicle owners should treat any unsolicited contact that cites their RC details as a possible signal of this leak, and registration authorities and identity providers should assume RC records tied to these tokens may already be circulating. We are naming this exposure to get it fixed.

How We Validated the Findings

Following careful verification of the activity, Cyderes Howler Cell obtained access to the authsure[.]in infrastructure. The method is withheld for now to safeguard the already exposed data.

We introduced no third-party personal data at any point. No external Aadhaar number and no external vehicle number were supplied. The values used to confirm that endpoints were live were already present in the operator's own API configurations and backend logs, alongside the analyst's own vehicle and personal records. The only identity data involved was data the operator had already stored or data belonging to the analyst running the test. Personal data encountered in stored configurations was observed only to the extent necessary to confirm misuse, and was neither retrieved nor retained beyond that point.

Validation was performed as follows.

• Mahindra. The worker exposed an endpoint that any caller could use to mint a fresh Google access token, with no password and no login. Calling it returned live access tokens, which confirmed the embedded service account was real and functioning. One token was then passed to Google's public OAuth2 token introspection endpoint, which reported the token as genuine, returned its granted storage scope, and carried the service account email. The project ID inside that email is how the key was identified as belonging to Mahindra Digital Platform's production environment.
• SurePass. The Aadhaar validation endpoint was called using an Aadhaar number already present in the operator's own APIs table configuration. The endpoint returned HTTP 200 with a live UIDAI response confirming age range, state, gender, and mobile linkage.
• TruthScreen. The RC lookup worker was called using a vehicle registration number already embedded in the worker by the operator. The endpoint returned HTTP 200 with a live VAHAN record. The result was cross-checked against our own data.

Current Status

Three dates anchor this report, and each measures something different. Upstream credentials were validated through late April 2026. The Telegram bots were last confirmed live in May 2026. Credential liveness was re-checked on 4 August 2026.

Following the Howler Cell report to CERT-In, the original Telegram channel and most of its bots went offline. The operator did not stop. Aware of the exposure, they re-registered a new channel, a new lookup bot, and a new operator handle, and the service is running again.

The rebuild was partial. One bot, @rtovehicledetailsssbot, stayed running through the takedown and served as the anchor while everything around it was replaced. The replacement infrastructure operates through that bot together with @rtovehicleinfooobot, administered under the handle @MRXISBACKK.

The takedown did measurable damage. The original backup channel held 21,329 subscribers when we captured it before disclosure. The replacement channel, created around 10 July 2026, holds roughly 2,230. The operation lost close to 90 percent of its audience and is rebuilding from near zero.

Upstream, most of the supply chain is closed. As of 4 August 2026, the entire Invincible Ocean endpoint surface returns HTTP 501 and is no longer usable, and the SurePass token returns HTTP 401 on both Aadhaar and PAN, consistent with a revoked account. The Mahindra worker shell still responds on its health path, but the token generation endpoint returns HTTP 500 and no longer mints tokens. The suzuki-history worker referenced in the platform's configuration remains deployed but did not respond to testing at any point, and we were unable to confirm it ever held a working credential.

One path is still open. Of the two TruthScreen proxy workers, the first remains deployed with its data path failing. The second is still live and still returning full VAHAN records, including the owner's contact number. AuthBridge did not respond to our disclosure on 1 June 2026, and the exposure has now run for more than two months past notification. We have re-reported it to CERT-In, who responded to the original disclosure and contacted the relevant entities.

The pattern is worth stating plainly. Infrastructure can be taken down, and taking it down cost this operator most of their customer base. The tooling, the supplier knowledge, and the playbook survived, and rebuilding those took weeks rather than months.

Scope and Precedent

The platform's own logs record 1,793 queries. That is the observed floor, and it describes what was run rather than what was reachable. Reachable scope is a different question and it is the one that determines how seriously this should be taken. What follows assesses addressable population. We found no evidence that any of it was systematically exploited, and nothing here should be read as a count of victims.

Scope in this operation is governed by a single variable: whether the input a buyer needs is publicly observable.

The vehicle pipeline is the outlier and the only part that scales. A registration number is public by design, painted on the vehicle and legible to anyone standing near it. Every other endpoint requires the buyer to already hold a private identifier, which makes those queries useful for confirming an identity rather than discovering one. The vehicle endpoints do something different. They convert a public observation into a private dossier, at INR 5 per conversion, on any vehicle in the country.

The Economics

Two numbers bound the problem. Enumerating the national fleet at INR 5 a query would cost roughly USD 20 million, which is impractical, and nothing in the request logs suggests anyone attempted it. Enumerating every vehicle in a single facility car park, call it two hundred vehicles, costs about USD 11.

Mass surveillance is priced out. Surveillance of one building, one street, or one compound is priced at lunch money. Population figures therefore understate this rather than inflating it, because an attacker does not need 350 million records. They need the plate they photographed, or the two hundred plates in the car park that interests them.

High-Value Individuals

India holds the world's third-largest concentration of billionaires, behind the United States and China, with 308 on the Hurun Global Rich List 2026 and 229 on the Forbes 2026 list. Add the senior civil service, the judiciary, serving military and police officers, and the press corps. Prices varied by the type of record requested and never by whose record it was. A cabinet secretary's registration details cost the same INR 5 as anyone else's, with no watchlist, no exclusions, and no additional check where the subject was sensitive.

Vehicles belonging to heavily protected individuals are frequently registered to companies or trusts rather than to a person, so a lookup may return a corporate entity instead of a home address. That limits what a query against a principal yields directly, and a corporate registration still confirms an affiliation.

The exposure does not sit with the principal. The vehicles around a protected person are usually registered to people with no protection at all: staff, drivers, family members, and other residents at an address. A perimeter is easier to map than a principal, and it resolves to the same location.

Precedent

The harms this architecture enables are not hypothetical. Three documented cases outside India show the same failure modes reaching the same kinds of people. None of them involved a commercial broker, and all three are laid alongside this operation below.

Two details from those cases are worth keeping in view. An Associated Press investigation covering all fifty US states and three dozen of the largest cities found officers routinely running driver and vehicle records on people they had personal interest in, including one who looked up home addresses of women he found attractive. In April 2026, the Institute for Justice documented at least 18 US officers caught using a commercial license-plate reader network to track a romantic interest, one of them running close to 180 queries against a partner and the partner's ex over two months. Singapore, for its part, characterized the SingHealth intrusion as deliberate, targeted and well-planned, and explicitly not the work of casual hackers or criminal gangs.

Credit files deserve one further note. They identify financial distress, which is among the most useful selectors available for recruitment targeting, and this platform sold full credit reports on named individuals for INR 500.

Why These Are the Cases We Know About

Every case above became public because an intruder broke in and left evidence, or because an authorized user's queries carried their name in an audit log. Read the last column downward, and the pattern is plain. Attribution shortens as the method gets cheaper, and at six cents a query it reaches zero. We know what we know about identity data misuse because it was expensive enough to leave something behind.

Affected Organizations

The investigation identified four organizations whose credentials or keys were found in use on external systems they did not appear to authorize. This is not a claim that any of them were breached.

• • Invincible Ocean. A licensed Indian KYC and data intelligence aggregator with upstream access to CIBIL, Experian, and telecom KYC. Three separate credential sets tied to this provider were found in unauthorized use on authsure[.]in, together covering thirteen API endpoints across financial, employment, and identity data categories.
  • SurePass[.]io. A licensed Aadhaar e-KYC provider with direct integration to UIDAI. A bearer token issued by SurePass under the identity dev.sevenunique[@]surepass[.]io, belonging to SevenUnique Technologies, was found in unauthorized use against Aadhaar verification endpoints. The token was issued in February 2024 and its expiry claim reads February 2044.
  • AuthBridge (TruthScreen platform). An Indian data enrichment provider with licensed access to the VAHAN national vehicle registry. TruthScreen authentication tokens were found embedded inside two attacker-controlled Cloudflare Workers acting as a credential-holding proxy layer.
  • Mahindra India. A production Google Cloud Platform service account private key from project mdp-ad-gld-dta-prd-[REDACTED], the Gold-layer data environment in Mahindra Digital Platform's Medallion architecture, was found embedded in attacker-controlled infrastructure. The worker minted live OAuth tokens on demand for more than seven months. This is a separate enterprise finding from the KYC credential chain, surfaced during the investigation.

The Operator

All observed components are attributed to the handle MRXISBACK with moderate confidence. The basis is the consistent use of the MRX naming convention across worker URLs and its recurrence throughout the associated Telegram assets, together with the operator's own public announcement linking the two sales channels.

We stop short of asserting a single individual. A Telegram account can be operated by several people, and other identities appear in the platform backend, including the names attached to the payment accounts and a further handle recorded as Ansh. Multiple operators or collaborators remain a live possibility.

The earliest traceable footprint is a Telegram channel named Vehicle OSINT Sport Team (t[.]me/Vehicle_OSINT), created in December 2024. Payments were collected by UPI QR code through a dedicated handler bot, with one payment address registered under the business name Last Shop and processed through Razorpay and Yes Bank.

The original channel and bot later went dormant. Rather than discontinuing the operation, the operator migrated to new handles and carried the existing subscriber base across each transition. Access to the bot requires a channel subscription, which expands the audience and retains users on the network when bot handles change.

Handle rotation follows a deliberate pattern of single-character re-registration. The lookup bot moved from @rtovehicleinfoobot to @rtovehicleinfooobot, the operator handle from @MRXISBACK to @MRXISBACKK, and the backup channel from vehiclebackup2 to vehiclebackupp. Each pair differs by one character. These are distinct assets rather than transcription errors, and they are flagged as such in the appendix.

Over the documented lifetime the operator cycled through four payment processors and three registered UPI identities. Each rotation makes financial tracing harder.

The Supply Chain

The architecture runs five tiers deep. Government and bureau systems of record sit at the top. Licensed aggregators holding legitimate access sit below them. The operator occupies the third tier, querying those aggregators with credentials it did not own and routing requests through Cloudflare Workers to obscure their origin. Business customers buy programmatic access at the fourth tier through a clean API. Retail buyers reach the same data at the fifth tier through the Telegram bots.

The operator held no authorization to access UIDAI, VAHAN, CIBIL, or Experian.

Figure 1: authsure[.]in supply chain, from authoritative source to retail buyer, with defensive break points

The Telegram Operation

A routine investigation into Telegram bots offering vehicle lookup services surfaced a larger enterprise. The activity is a structured data brokerage run across two sales channels.

Figure 2: Telegram search for "vehicle info" surfaces the active bots and backup channel

At the time of investigation, the service ran through two bots supported by a backup channel at t[.]me/vehiclebackup2, which held 21,329 subscribers. These bots were last confirmed live in May 2026 and were actively marketed to new users at that point. The channel and bots shown in Figures 3 through 6 are the pre-disclosure infrastructure. The current replacement handles are listed under Current Status above and in the appendix. 

Figure 3: The companion channel t[.]me/vehiclebackup2

Figure 4: @mrxisback, operator profile

Figure 5: @rtovehicledetailsssbot, Bot 1

Figure 6: @rtovehicleinfoobot, Bot 2

Bot and Channel Inventory

The full inventory of eight bot handles, three channels, and two operator handles appears in the appendix.

The Payment Trail 

Table 3: Payment Trail

What the Bot Sells

The bot offers a tiered catalog priced per query. Conversions below use a rate of approximately INR 87.6 to the US dollar as of August 2026.

Table 4: Bot services catalog with pricing

The operator advertised premium services within the channel, including vehicle records sourced from Spinny and Cars24. These two were sold only through Telegram and never appeared on the B2B platform. How the operator obtained Spinny and Cars24 records is not established by the available evidence.

Figure 7: Advertisement for Spinny and Cars24 data services

Figure 8: Bot welcome menu

The bot accepts a vehicle registration number and returns an owner profile for as little as INR 5 per query, including name, address, contact number, and insurance status. Users load a prepaid balance and pay per lookup.

Figure 9: Bot response format for a vehicle RC query

authsure[.]in: The B2B Platform

In September 2025, the operator used the backup channel to introduce authsure[.]in, a B2B API marketplace running on the same data pipeline as the Telegram bot service. The announcement establishes the link between the two.

Figure 10: The operator's announcement of authsure[.]in

How It Works

authsure[.]in is a professionally presented API marketplace built on a React front end, a Supabase back end, and a Cloudflare Worker proxy layer. It offers businesses an integration point for Indian KYC and identity data lookups. The homepage markets the service as a Secure API Platform. The admin dashboard provides tabs for client management, pricing tiers, API key issuance, and usage analytics. In presentation and behavior the platform matches a legitimate SaaS product.

The provenance of the data is what separates it from a licensed aggregator. Every record derives from credentials the platform was not authorized to hold. The customer-facing experience resembles a standard commercial API. The supply chain supporting it does not.

The Platform Interface

The front end presents as a credible enterprise SaaS product, advertising four feature pillars: Secure Authentication, API Key Management, Analytics and Monitoring, and Client Management.

Figure 11: The authsure[.]in homepage

Dashboard access is restricted, and no self-registration flow exists. The login page states that accounts can be created only by the platform administrator, which indicates the operator provisioned every customer account manually. Prospective clients were directed to a request form capturing name, company, contact number, and intended API use case. 

Figure 12: The login page

Figure 13: The access request form

API Services

The services catalog was publicly accessible without login at authsure[.]in/services and listed eleven entries grouped by data category, of which ten were live products and one was a test entry. Each carried a description and a stated business use case, presented in a format matching a legitimate KYC marketplace.

Figure 14: The API Services page

Table 5: API services overview

None of these services are licensed to authsure[.]in. Every data source listed is reached using credentials obtained without authorization. The public catalog functions as a commercial facade built on credential misuse.

Hyundai Service History is worth a note. It was advertised as item 2 in the public catalog, but in the platform's own APIs table it existed only among the unpublished development-stage configurations. The operator marketed a product that was never fully wired up.

The Exposed Backend

What the Database Contained

The platform's backend storage held twelve tables mapping the full operational footprint of authsure[.]in.

Table 6. Exposed database summary

The apis table proved the most operationally significant. It held all three Invincible Ocean credential sets and the SurePass token in plaintext, together with the Cloudflare Worker URLs that carried TruthScreen authentication.

The request_logs table contained 1,793 records spanning September 2025 to April 2026, a log of every API call the platform processed in that window. Each call represents a query against an individual's records. The Telegram side of the operation kept no comparable log we could recover, so the true number of lookups performed across both channels is higher than 1,793 and cannot be bounded from the available evidence.

Two financial tables are easily conflated and serve different purposes. payment_transactions records eleven external Razorpay gateway events, the actual INR payments clients made to buy credits. credits_transactions is the internal billing ledger and the primary financial record, holding 694 rows that capture every API query that consumed credits, every administrative top-up, and every credit conversion following a Razorpay payment. Most account funding happened through manual administrative top-ups or off-platform UPI transfers, so total revenue cannot be reconstructed.

The Customer Registry

The profiles table held twelve accounts: the operator's administrative account, a test account, and ten paying clients. The operator account, sahiba[@]authsure[.]in, is confirmed administrative by a role-resolution function returning admin for its UUID. The test account was created four days after the administrative account and was used to embed live PAN and phone numbers as test parameters within API configurations.

Table 7. Customer registry

One account carries a recorded balance that the payment ledger does not support. Only a small administrative top-up is logged against it, and no corresponding gateway payment exists. We treat that balance as unreliable rather than as evidence of a large purchase, and we note that the possibility of third-party modification to this database cannot be excluded. Figures drawn from the backend elsewhere in this report are consistent across multiple tables, and we have no indication of tampering beyond this single field.

Who the Clients Were

The ten paying accounts above read as vehicle-information resellers and small commercial operators. That is the documented customer base.

The product mix points at a wider market. The two most expensive items on the menu were used-car platform records at INR 700 and INR 500, which indicates the vehicle trade was the paying segment. Insurance and loan lead generation fit the mobile-to-vehicle and policy-expiry products. Recovery agents, matrimonial investigators, and low-cost pre-employment screening fit the address, phone, and employment-history products. Fraud fits several. The Aadhaar endpoint lets a buyer confirm that stolen KYC data is still valid before using it, which is why an endpoint returning so little is worth paying for.

The API Configurations

The APIs table contained 27 entries in two categories. Eleven services were published, of which ten were live products. The remaining sixteen were development-stage configurations never made available.

The published services expose the full proxy chain behind each live offering.

• • RC lookups route through two dedicated TruthScreen Cloudflare Workers.
  • Aadhaar verification routes through the SurePass bearer token directly to UIDAI.
  • CIBIL Score queries draw on Invincible Ocean credential set 1.
  • Suzuki service history routes through a worker we could not validate; see the note under The Data Sourcing Chain.
  • Mahindra service history routes through the GCP service account worker, the same worker that mints live OAuth tokens against Mahindra's production Gold-layer environment.

Figure 15: Published APIs as recorded in the authsure[.]in APIs table

The sixteen unpublished entries cover additional Invincible Ocean endpoints: PAN to UAN mapping, UAN employment history, mobile to PAN, mobile to UAN, LPG subsidy details, PAN to GST, company director search by DIN, Experian credit PDF, chassis to vehicle, CIBIL Score V3, Hyundai service history, and Mobile Identity 2.0. Four further entries indicate the operator experimented with alternate mobile identity routing.

Several unpublished configurations contained genuine personal data belonging to unidentified individuals, embedded directly as test API parameters during setup, with names, phone numbers, and PAN numbers stored in plaintext.

Figure 16: Unpublished API configurations as recorded in the APIs table

Taken together, the 27 entries map the operator's upstream access at the time of investigation: three Invincible Ocean accounts, one SurePass token with a 2044 expiry claim, two TruthScreen Cloudflare Workers, and the Mahindra GCP token generator. One further entry, the suzuki-history worker, could not be validated and is treated separately. Every credential held in the database was stored in plaintext.

The Data Sourcing Chain

Establishing where the data originates means tracing three upstream pipelines, each supplying a different category of Indian personal data. What the operator built works as a credential aggregation layer. It is a proxy business earning a margin on the gap between the cost of obtaining API access it did not own, and the price customers pay for a clean integration point.

Provider 1: Invincible Ocean

api.invincibleocean[.]com. Credentials revoked and accounts disabled following disclosure.

Invincible Ocean is a licensed Indian KYC and data intelligence API aggregator whose access spans telecom subscriber records, EPFO employment databases, GSTN, MCA company records, the credit bureaus CIBIL and Experian, and the VAHAN vehicle registry. The operator held three separate Invincible Ocean credential sets in plaintext within the APIs table, which indicates multiple accounts were obtained or that credentials were rotated as they expired.

Figure 17: Invincible Ocean credential sets found on the platform

Figure 18: Live CIBIL API query

Figure 19: Live Experian PDF API query

Together, these credential sets covered thirteen API endpoints, giving the operator broad reach across the personal and financial data of Indian citizens. The endpoints ranged from PAN tax records and employment histories to full Experian credit reports in PDF form.

Table 8: Invincible Ocean endpoint inventory

From January 2026 onwards the Invincible Ocean credentials began returning 401 errors, reporting invalid credentials and a disabled account, which indicates the accounts were flagged or revoked. By March 2026, most endpoints were returning 500 errors instead. We read the 500s as ambiguous, a sign of endpoint instability rather than proof of revocation, because in our validation logic a 500 meant authentication passed and the endpoint was still live. The revocation inference rests on the 401s. Either way, the credentials stopped working, which explains the sharp drop in the platform's API call volume through early 2026. We disclosed the exposure to Invincible Ocean, who acted quickly and revoked the affected credentials. As of 4 August 2026, the entire endpoint surface returns HTTP 501.

Provider 2: SurePass[.]io to UIDAI

kyc-api.surepass[.]io. Token observed revoked, HTTP 401 as of 4 August 2026.

SurePass[.]io is a licensed Aadhaar e-KYC API provider integrated directly with UIDAI, India's Unique Identification Authority. The operator held a SurePass bearer token in the platform backend, registered to the identity dev.sevenunique[@]surepass[.]io, an account belonging to SevenUnique Technologies. The token was issued on 24 February 2024. Its expiry is not inferred: the decoded JWT payload carries an exp claim resolving to February 2044, a twenty-year validity window.

The token was confirmed live in late April 2026 and had been in active use since September 2025. Real Aadhaar numbers were therefore verified against India's national identity database using credentials the operator did not own, for more than seven months.

Figure 20: Live Aadhaar query returning PII

Figure 21: The SurePass token as stored on the platform

Provider 3: AuthBridge TruthScreen to VAHAN

TruthScreen platform. One worker failing, one still live and serving records as of early August 2026.

AuthBridge's TruthScreen platform is an Indian data enrichment provider holding licensed access to the VAHAN national vehicle registry. The operator routed vehicle lookup requests through two Cloudflare Workers acting as a credential-holding proxy layer. Because the TruthScreen authentication tokens sit inside the workers rather than in the Supabase database, the arrangement adds a layer of abstraction between the platform and the upstream provider.

Both workers were confirmed live in late April 2026, and multiple TruthScreen transaction IDs appear in the platform's request logs. As of the early August 2026 re-check the first worker remains deployed with its data path returning HTTP 500. The second is still live and still returning HTTP 200 with full VAHAN records, including the owner contact number. This is the one exposure in this report that remained open at publication, and it has been re-reported to CERT-In.

The credentials themselves were not directly observable, since the tokens sit inside the worker rather than in the database. Attribution rests on the string truthscreen in the worker URL together with the TruthScreen transaction IDs recorded in the request logs.

Table 9: TruthScreen worker endpoints

Figure 22: Live vehicle number query returning data

A Fourth Worker We Could Not Confirm

The APIs table also referenced a worker named suzuki-history, tied to the platform's INR 50 Suzuki service history product. Unlike the Invincible Ocean, SurePass, and TruthScreen credentials, we found no evidence this worker ever returned data. It did not respond during testing, and we could not confirm that a working credential was ever held there. We are not counting it as a fourth affected organization or a confirmed access path. It is documented here, and the worker URL is retained in the appendix, because it appeared in the operator's own configuration and a reader working from that table should not conclude independently that it was validated when it was not.

The Mahindra India Trace

The Mahindra finding was not the original focus of the investigation. It surfaced in the APIs table alongside the other worker configurations, as a Cloudflare Worker URL named mahindra-history-[REDACTED].workers[.]dev, set up to serve vehicle service history lookups for the platform's INR 70 Mahindra service.

What set it apart from the other workers was the endpoint path, /token/generate. Instead of proxying a lookup, this endpoint mints Google OAuth tokens. It required no password and no login, so anyone who knew the URL could call it and get a fresh token on demand.

A Mahindra India production GCP service account private key had been embedded inside the public worker. The worker signs JWTs with that private key and exchanges them at Google's OAuth endpoint for short-lived tokens, regenerating them on each call. Passing one of those tokens to Google's public token introspection endpoint confirmed it was genuine and returned the service account email. That project ID is how we identified the key as belonging to Mahindra Digital Platform's production environment.

Table 10: Mahindra GCP worker attributes

The project ID decomposes into recognizable Mahindra naming conventions, where mdp denotes Mahindra Digital Platform, ad denotes Advanced Data, gld the Gold layer of a Medallion architecture, dta data, and prd production. This is a production environment rather than a development or test instance.

Figure 23: Live Mahindra vehicle service history query

The devstorage.read_only scope permits the holder to list and download every Google Cloud Storage bucket in the project. The datastore scope, as Google defines it, grants full read and write access to Cloud Firestore and Cloud Datastore. Within the authsure[.]in context, the operator appeared to use the token only to query Mahindra vehicle service history records. The token was capable of considerably more.

We attempted to reach Mahindra India directly on two occasions. Both emails bounced, and we received no acknowledgement through any other channel. We relied on CERT-In to route the disclosure.

What Should Defenders Do

Nothing in this operation looks like an attack from the upstream side. Every query was authenticated, well-formed, and delivered through a documented API by a customer whose credentials checked out. No malware, no intrusion, no anomalous protocol behavior. Signature-based controls and platform telemetry have nothing to fire on. This is the category of risk that surfaces through hunting rather than alerting, and it applies three different ways depending on where an organization sits in the chain.

If You Buy Identity Data

Most banks, insurers, lenders, gig platforms, and marketplaces consume third-party identity verification APIs. Fourth-party risk in identity data is the exposure this case demonstrates, and it goes largely unmanaged.

• • Inventory every identity, KYC, and enrichment API your products call. For each one, name the entity that holds the upstream license, not the entity that sends the invoice. Those are different questions.
  • Ask each vendor to produce the license and the sublicensing right. Resellers frequently hold neither.
  • Treat price as a signal. A per-lookup rate well below the licensed rate means someone in the chain is not paying for access.
  • Treat provisioning behavior as a signal. No self-registration, manual account creation by an administrator, and a contact form in place of a signup flow describe a gray-market supplier.
  • Consuming unlawfully obtained personal data in good faith still leaves you holding unlawfully obtained personal data. That is a DPDP Act and GDPR-like exposure independent of intent, and it is the business consequence that follows from a vendor inventory gap.

If You Sell Identity Data

Providers in this case did not distinguish the operator from a legitimate customer, because they were not looking at the right signals. Every detection below runs on telemetry they already had.

• • Baseline category breadth per API key. A key issued to a lending platform for onboarding that begins querying vehicle registrations, employment history, and LPG subsidy records is not doing onboarding. This is the highest-fidelity signal in the case.
  • Pin expected customer egress. The operator proxied everything through Cloudflare Workers. Alerting on authentication from serverless edge ASNs would have surfaced this early.
  • Detect repeat subjects across unrelated customers. The same PAN or vehicle number queried by several downstream accounts is a reseller fingerprint.
  • Watch velocity and daily shape. Retail resale traffic follows consumer hours and arrives in bursts. Enterprise onboarding traffic is smoother and follows business hours.
  • Cap token lifetimes and force refresh. A bearer token issued in February 2024 and valid until 2044 is an unmanaged credential.
  • Require a consent reference on every query and reject queries without one. This single control breaks the business model described in this report.

If You Run Production Cloud Workloads

The Mahindra finding is the most broadly applicable part of this investigation.

• • Long-lived JSON service account keys are the root cause. If they exist in your environment, you have this exposure. Workload identity federation removes the class of problem, and constraints/iam.disableServiceAccountKeyCreation enforces it at the organization level.
  • Enumerate every service account key, age it, and revoke anything without a named owner or older than your rotation policy.
  • Extend secret scanning to edge compute. Coverage usually reaches repositories and CI pipelines and stops there. Cloudflare Workers and equivalent edge functions are a real blind spot.
  • Detect use as well as exposure. Cloud audit logs showing a production service account authenticating from unexpected ASNs is a hunt rather than an alert, and a Gold-layer production identity authenticating from edge infrastructure is anomalous at the log layer.
  • Read the scopes. devstorage.read_only lists and downloads every bucket in the project. datastore grants read and write on Firestore. Write access to a production Gold-layer store is a data integrity problem alongside a confidentiality one.

Break Points Across the Chain

Table 11: Defensive break points by chain step

Cyderes threat hunting runs the query-pattern and egress analyses described above against client telemetry, and the vendor inventory work sits with exposure management. Neither depends on a signature.

Conclusion

This is a business, and its inventory is people who were never told they were part of it.

Indian identity infrastructure is designed to be queried by licensed intermediaries acting on a citizen's behalf. Consent authorizing a lookup is granted once, at the top of the chain, to an aggregator holding a license. Below that point nothing re-verifies who is asking or why. A bearer token therefore inherits the full authority of the license it was issued under, which is how a token issued to a legitimate company in February 2024 was still verifying real Aadhaar numbers against UIDAI in April 2026 on behalf of a Telegram bot.

For an ordinary citizen the consequence is that their life can be reassembled from the outside, one paid query at a time. National identity through Aadhaar. Tax identity through PAN. Credit history through CIBIL and Experian. Vehicle ownership through VAHAN. Mobile subscriber identity through telecom KYC. Employment history through EPFO. Company directorships through MCA. Data drawn from a dozen separate government and bureau systems was reachable through a single platform, priced by the query, leaving no trace on the citizen's side.

The same capability aimed at the right person becomes a national security concern. Everything sold here is targeting data. A vehicle number seen outside a military base, a ministry car park, or a police station resolves to a name, a home address, and a mobile number. A mobile number resolves to a subscriber identity and, through the Telegram lookup, to an online persona. Assembled across a few lookups costing a few rupees each, that is a pattern-of-life profile on a soldier, a judge, a journalist, a bureaucrat, or a witness, built without a single covert operation and without the target knowing they were queried. The scope section above sets out why the vehicle pipeline is the part that reaches everyone, and why the people hardest to query directly are still reachable through the vehicles parked around them. We found no evidence that this capability was used for targeting, and the point stands on what the platform made possible rather than on what it was used for. Hostile intelligence services, organized crime, and terrorist planners all need the same thing before they act, which is a verified fix on who a person is and where they can be found. A commercial lookup service that answers that question for anyone with a UPI account removes the hardest part of the job. It also scales, and the resulting queries look identical to routine commercial KYC traffic in the provider's logs.

The Mahindra finding shows the same failure inside an enterprise. A production Gold-layer environment had a service exposed for seven months behind a worker anyone could call. What the operator did with that token is documented here. Whether anyone else reached it during those seven months is not something the available evidence can establish either way, and it is the kind of question a post-incident review is best placed to close out.

Disclosure worked better here than the usual telling of these stories allows, and it did not work completely. Howler Cell found this operation, traced it to the licensed providers feeding it, and reported it. That report closed the Invincible Ocean and SurePass pipelines, killed the Mahindra token generator, and cost the retail operation close to 90 percent of its subscribers. The operator came back within weeks under new handles, anchored on the one bot that survived, and is rebuilding an audience from roughly 2,230 people instead of 21,329. One VAHAN path is still open, because the provider holding it never answered. The only exposure still open sits with the one provider that never acknowledged the disclosure at all.

What remains is the number this report is named after. Somewhere along this chain a verified Indian identity was priced at roughly six cents a lookup, and it cleared at that price for months. The architecture around the seller made it that cheap to buy, and the person being sold remains the only party to the transaction who never knew it took place.

Appendix

Telegram Infrastructure

Three assets were re-registered with single-character variations on their predecessors. These are distinct handles rather than transcription errors.

UPI Payment Identifiers

Platform and Infrastructure