SBI dark-web exposure raises questions over loan systems and third-party security

Experts tell CRN India that loan-sourcing platforms, CRM applications and connected environments warrant scrutiny as SBI investigates the authenticity, source and extent of the suspected data exposure.

The suspected exposure of customer information linked to State Bank of India (SBI) has raised questions about whether the data originated in loan-sourcing or lead-management systems, and whether connected applications and third-party environments could have played a role.

Speaking to CRN India, Govind Rammurthy, CEO and managing director of eScan, said, “The fields reportedly found in the exposed data appear more consistent with loan-sourcing and lead-management workflows than with systems used to manage banking accounts and transactions.”

Eventus Security co-founder and CTO, Manish Chasta, said investigators must also examine how customer information moves between banking systems, integrated applications and external environments.

The comments follow SBI’s disclosure to stock exchanges on October 21 that its preliminary examination identified 3,897 customer records containing personally identifiable information (PII) among approximately 375,000 records found on the dark web.

The bank said it received alerts from a threat intelligence service provider, the Defence Cyber Agency and the Indian Computer Emergency Response Team (CERT-In). It has activated its cyber incident response and containment protocols and engaged an independent CERT-In-empanelled cybersecurity agency.

SBI is investigating the authenticity and completeness of the records, their potential source and the associated risks. Its preliminary findings do not establish that all 375,000 records belong to SBI customers. The bank has not confirmed which systems were involved or how the information may have been exposed.

Loan-sourcing platforms warrant scrutiny

Rammurthy said the reported presence of lead IDs, loan application metadata and customer information points towards a loan-sourcing or lead-management system rather than the core banking environment.

“Core banking is organised around account numbers, balances and transactions,” he said. By contrast, lead IDs and loan application metadata are more commonly associated with CRM and lead-management platforms used to source and track loan enquiries and applications.

The structure of the dataset may offer further clues.

Rammurthy said, “The presence of personal details in only a relatively small portion of the reported 375,000 records could be consistent with an enquiry or partially completed application pipeline rather than a clean customer master database. However, this pattern alone cannot establish the source of the data or the number of affected customers.”

Investigators should also examine the spread of branches and products represented in the records, the presence of KYC images and application forms, and timestamps that could reveal when the information was collected or moved between systems.

Rammurthy said a “CRM or lead-management platform”, potentially operated by or with a third party, is one possible source. He cautions that only SBI’s forensic investigation can validate that assessment.

Chasta said the presence of customer information alongside CIF numbers and lead IDs raises questions about whether the exposure occurred within a banking system or while data moved between applications.

“These identifiers alone cannot establish the source,” he said, adding that CRM platforms, integrated applications and third-party environments should form part of the investigation.

The distinction matters for banks and their technology partners, because customer information can move through several systems and organisations. A security review limited to core banking infrastructure may not account for every application or external environment that handles the data.

Chasta said “investigators should examine API logs, database access histories, export records and vendor permissions” to reconstruct the data trail.

Banks should also map sensitive identifiers across systems and flag unusual bulk exports or access from unfamiliar accounts.

He describes the risk as “identity fragmentation”, where information that appears relatively harmless in isolation becomes more useful when combined with other datasets. Attackers could use the resulting details to build convincing phishing messages or impersonate bank representatives.

The information reportedly includes names, registered mobile numbers, dates of birth, gender, email addresses, residential addresses, branch identifiers, CIF identifiers, lead IDs and loan or lead metadata.

There is no confirmed evidence in the information disclosed so far that the records have been used to commit fraud or that customers have suffered losses.

First 72 hours focus on containment and customer risk

The experts say the initial response should prioritise validating the alert, containing any continuing exposure, preserving evidence and assessing potential customer harm. These activities should proceed in parallel rather than wait for the full forensic investigation to conclude.

Chasta said investigators should “validate samples of the records and correlate external threat intelligence” with API logs, database activity and identity events. This can help establish whether the data reflects a historical exposure or an ongoing compromise.

Automated monitoring can help flag bulk exports, unusual access patterns and potentially compromised credentials. Organisations should also restrict service accounts to the datasets and functions required for their work, while reviewing access permissions across connected applications and vendors.

Rammurthy said, “The first day should include identifying the systems and data involved and closing any exposed route, whether it relates to compromised credentials, an exposed API or a third-party system.”

Investigators must preserve logs and other evidence to establish how the information became accessible.

Reporting obligations are another consideration. CERT-In’s 2022 directions require specified cyber incidents to be reported within six hours of being noticed or brought to an organisation’s notice.

Banks must assess the applicable reporting requirements and meet the prescribed timelines rather than wait for the full scope of an incident to be established. They must also consider relevant Reserve Bank of India requirements.

Customer notification remains a key consideration

The potential misuse of exposed personal information also makes customer communication part of the response.

Chasta said banks should consider enhanced transaction monitoring and risk-based customer advisories where the data could support targeted phishing or impersonation.

Rammurthy said potentially affected customers should be warned about impersonation calls and reminded never to share one-time passwords (OTPs). Preparing customer communication should happen alongside the technical investigation, rather than only after every forensic question has been resolved.

The Internet Freedom Foundation has separately called for direct notification to affected customers, disclosure of the categories of information involved and a helpline.

It has also raised questions about the possible involvement of KYC documents, vendors and direct selling agents. These remain questions for investigation, not established findings about the source of the suspected exposure.

SBI said there is no material impact on its core business operations, financial performance or continuity, and that its operations remain normal.

The bank has not confirmed whether the data originated from core banking, a loan-sourcing platform or a third-party environment. It has also not disclosed the entry point or method through which the information may have been exposed.