SBI Data Exposure Investigation: Analysing the Siriusim Claim, 3,897 PII Records, and the Unknown Attack Path

Executive Summary

State Bank of India(SBI) disclosed an incident involving the loss of certain data after customer-related records appeared on the dark web on 21st October 2026.According to SBI's reported stock-exchange disclosure, an initial review of approximately 375,000 records available online identified 3,897 customer records containing personally identifiable information (PII).

The incident followed alerts reportedly received by SBI on 16 October 2026 from its threat-intelligence provider, the Defence Cyber Agency and the Indian Computer Emergency Response Team (CERT-In). SBI stated that it had activated its incident-response procedures and engaged an independent CERT-In-empanelled cybersecurity agency to investigate the authenticity, completeness, source and extent of the exposed information.

The incident attracted further attention following a claim attributed to a threat actor using the name Siriusim. According to public reporting, the actor allegedly claimed to have released approximately 375,000 rows of data in CSV format and 2,722 PDF documents associated with SBI. Reported document categories included loan applications, customer onboarding information and account-opening material. These quantities and descriptions originate from the reported threat-actor claim and should not be treated as independently verified measurements of a confirmed breach.

The reported exposure raises several security concerns. Names, dates of birth, telephone numbers, email addresses, residential addresses, branch identifiers, Customer Information File (CIF) identifiers and loan-related metadata can provide attackers with information that makes targeted phishing, impersonation and financial social engineering more convincing.

However, the public evidence available at the time of writing does not establish the original access method, the system from which the information originated, whether an external service provider was involved, or whether the person claiming to publish the data originally obtained it through an intrusion.

This report separates confirmed public disclosures from third-party allegations and analytical hypotheses. It examines possible data-origin scenarios, the evidence required for technical attribution, relevant MITRE ATT&CK techniques for investigation, and defensive measures that banks and affected customers can consider.

Central assessment: SBI has disclosed a data-loss incident and identified customer records containing PII in an online dataset. The incident's underlying technical cause and the identity of the party responsible for the original exposure remain undetermined in the public evidence reviewed.

1. Incident Overview

1.1 What happened?

The incident became publicly visible through reports of customer-related information being advertised on a cybercrime forum. A threat-monitoring account reportedly publicised the Siriusim claim on 16 October 2026.

SBI subsequently disclosed that it had received alerts concerning the suspected exposure and had begun investigating. Its preliminary review identified 3,897 customer records containing PII within a much larger collection of approximately 375,000 records.

SBI's disclosure is important because it establishes that the bank investigated an actual data-loss concern rather than the story being solely an unsubstantiated social-media allegation. Nevertheless, the disclosure does not establish that every item in the advertised collection is genuine, that all items originated from SBI, or that a particular technical vulnerability was exploited.

1.2 Incident timeline

DateReported eventIntelligence significance16 October 2026SBI reportedly received alerts from its threat-intelligence provider, the Defence Cyber Agency and CERT-In.Earliest publicly reported notification date; not necessarily the date of initial compromise.16 October 2026A threat-monitoring account reportedly publicised a claim attributed to Siriusim.Establishes an early public reporting point for the alleged dataset.17 October 2026Media reporting examined a small number of alleged sample records.Provides limited evidence for assessing whether some samples may be genuine.19 October 2026Further coverage discussed the allegation before SBI's public disclosure.Demonstrates that the claim received attention before the bank's filing.21 October 2026SBI publicly disclosed a data-loss incident and preliminary findings.Establishes the bank's reported response and initial record count.21–23 October 2026Further media and civil-society coverage examined the incident and customer-notification questions.Identifies outstanding transparency, privacy and incident-response questions.

Timeline limitation: These dates describe alerts, public claims, reporting and disclosure. They do not reconstruct the time of initial access, data collection, exfiltration or publication. Those events may have occurred on different dates.

1.3 What did SBI report?

The reported disclosure stated that:

The final point concerns operational and business impact. It should not be interpreted as proof that all customer information was safe, that no customer could suffer fraud, or that the investigation had ruled out further exposure.

2. Understanding the Dataset Claims

2.1 The 375,000-record figure

The figure of approximately 375,000 rows originates from the reported threat-actor claim and is also referenced in coverage of the incident. It should be distinguished from the 3,897 records SBI identified as containing PII in its preliminary review.

These are not interchangeable quantities.

A row in a CSV file does not necessarily represent one unique person. A dataset may contain duplicate records, historical entries, records from different sources, non-customer records, incomplete entries or records that cannot be attributed to the organisation in question.

To determine the number of affected people, investigators would need to establish record authenticity, identify duplicates, correlate records to legitimate systems and determine which entries actually relate to identifiable individuals.

2.2 What does the 3,897 figure mean?

SBI's reported preliminary finding was that 3,897 customer records containing PII were identified among the larger set of records examined.

This does not necessarily mean that:

The correct interpretation is that 3,897 PII-containing customer records were identified during the preliminary analysis reported by SBI. The final scope remains subject to the investigation.

2.3 The 2,722 PDF documents

The alleged threat-actor listing reportedly included 2,722 PDF documents in addition to the CSV records.

The number and description of these documents have not been independently established in the public evidence reviewed. SBI's reported preliminary disclosure does not fully describe the contents of this alleged PDF collection.

Potential document categories mentioned in reporting include loan applications, supporting documents and account-opening forms. If authentic, these could contain more detailed personal information than a basic contact record. However, the exact document contents must not be assumed without verification.

Investigators would need to determine:

These questions can be investigated using lawfully obtained, redacted samples and authorised reference data. Downloading or circulating suspected stolen customer documents is not necessary to establish a defensible public assessment.

3. Threat Actor Assessment: Siriusim

3.1 What is known?

Public reporting attributed the online dataset claim to a threat actor using the name Siriusim.

That establishes a reported association between the name and the publication claim. It does not independently establish the identity of the operator, the operator's location, the techniques used to obtain the records or whether the operator was responsible for the original compromise.

The name should therefore be treated as an alleged threat-actor identity rather than a fully attributed adversary.

3.2 Why a leak claim is not proof of the original intrusion

Cybercrime ecosystems contain several distinct roles:

One person or group may perform several of these roles, but that cannot be assumed.

A threat actor can publish data obtained by another actor, acquire information through an intermediary, combine data from previous incidents or make an exaggerated claim to attract attention.

Consequently, identifying the account that published a dataset is not the same as identifying the party that first accessed the source system.

3.3 Intelligence confidence

AssessmentConfidenceA claim attributed to Siriusim was publicly reported.High confidence that the claim was reported.The entire advertised dataset is authentic.Undetermined.Siriusim originally compromised SBI infrastructure.Not established.Siriusim obtained the data from a third party.Not established.Siriusim's real-world identity is known.Not established.

These confidence labels apply to the evidence reviewed, not to the actor's actual capabilities.

3.4 What would support attribution?

A credible attribution would require multiple independent lines of evidence, such as:

A forum username, a threat actor's statement or a screenshot alone is insufficient to establish responsibility for the original breach.

4. Data Classification and Potential Exposure

The types of information described in public reporting have different security implications.

Data typeMeaningPotential risk if exposedFull nameIdentifies an individual.Targeted impersonation and identity correlation.Date of birthPersonal identifying attribute.Social engineering and identity-profile enrichment.Registered mobile numberTelephone number associated with a customer.Targeted calls, SMS phishing and account-recovery attacks.Email addressDigital contact identifier.Phishing, credential attacks and impersonation.Residential addressPhysical location information.Privacy risks and more convincing targeted fraud.GenderPersonal attribute.Profile enrichment and targeted social engineering.Branch identifierIdentifies an associated bank branch.More credible-looking branch-specific impersonation.Customer Information File (CIF) identifierInternal identifier associated with a customer's banking relationship.Potentially useful for customer profiling and fraudulent enquiries if combined with other weaknesses.Lead IDIdentifier associated with a customer lead or application workflow.May reveal relationships between records or application processes.Loan-related metadataInformation associated with a lending or lead record.Targeted loan scams and impersonation of loan officers.KYC or application documentsDocuments used for identity verification or onboarding, if present.Potential identity theft and more extensive exposure of personal information.

The table distinguishes reported data categories from the unverified contents of the alleged PDF collection.

4.1 Does the exposure prove that bank accounts were compromised?

No such conclusion can be drawn from the reported PII fields alone.

The public reporting reviewed does not establish that account passwords, PINs, OTPs, transaction authorisation credentials or core banking access were compromised.

However, personal information can still be security-sensitive. An attacker may use exposed details to construct credible communications, impersonate bank personnel or persuade a customer to disclose additional information.

The distinction is between exposure of customer information and compromise of the systems or credentials used to authorise financial transactions. The former does not automatically prove the latter.

5. Source Attribution: Where Could the Data Have Originated?

The most important unresolved technical question is the original source of the records.

The presence of customer identifiers and loan-related metadata makes several workflows relevant to the investigation. It does not prove that any specific system or organisation was compromised.

Hypothesis A: SBI's own application or customer-management systems

SBI systems that process customer onboarding, loan applications or customer records are one possible source.

Why investigate it?

The reported field categories could be associated with customer-management and lending workflows.

Evidence required:

Assessment: Plausible investigative hypothesis; not confirmed.

Hypothesis B: An SBI subsidiary or associated entity

The records could potentially originate from a separate business unit or associated entity that processes customer applications or financial products.

Why investigate it?

Financial institutions may operate multiple systems and business lines, each with its own customer identifiers and data-processing workflows.

Evidence required:

Assessment: Plausible investigative hypothesis; no specific entity has been established as the source.

Hypothesis C: A third-party service provider or lending partner

A provider involved in application processing, document handling, customer acquisition or related services could be a potential source.

Why investigate it?

Customer information may be shared with external processors as part of legitimate business operations. A security failure in a connected environment can expose data even if the primary banking platform remains operational.

Evidence required:

Assessment: Worth investigating, but no vendor breach has been publicly established.

Hypothesis D: Misconfigured database, API or document repository

An improperly configured repository or application access-control mechanism could expose information to unauthorised parties.

Technical concepts to investigate:

Evidence required:

Historical configuration, access logs, permission records and evidence of unauthorised retrieval.

Assessment: A general data-exposure scenario, not a finding about SBI's systems.

Hypothesis E: Compromised employee or service account

An attacker could potentially use legitimate credentials to access data without exploiting a software vulnerability.

Evidence required:

Assessment: Possible, but no public evidence reviewed establishes compromised credentials.

Hypothesis F: Insider activity or previously exposed data

The collection might include data exported by an authorised user, records acquired in an earlier incident, or material aggregated from several sources.

Evidence required:

Assessment: Cannot be ruled in or out using the current public evidence.

Source-attribution conclusion

The public evidence does not currently support selecting one of these hypotheses as the confirmed root cause. The appropriate next step is to identify the originating data system and correlate it with access and export evidence.

6. Attack-Path Reconstruction

A defensible attack-path reconstruction separates the stages of a possible intrusion from the events that have actually been observed.

The following sequence is a conceptual investigation model, not a claim that these steps occurred in the SBI incident.

Stage 1: Initial access

Possible routes to investigate include compromised credentials, exploitation of a public-facing application, unauthorised access through a third-party connection or insider activity.

Evidence required: Authentication logs, vulnerability records, endpoint telemetry, application logs and vendor access records.

Stage 2: Access to relevant records

An intruder would need access to the systems or files containing the target information, unless the data had already been obtained elsewhere.

Evidence required: Database audit trails, application access logs, file-access records and permission history.

Stage 3: Collection

The actor may have collected records through queries, exports, downloads, document retrieval or another process.

Evidence required: Unusual query volumes, export-job activity, file-access events and evidence of unexpected bulk retrieval.

Stage 4: Exfiltration

Exfiltration means the unauthorised transfer of data out of the environment where it was stored or processed.

Evidence required: Network telemetry, proxy logs, firewall records, cloud audit events, endpoint evidence and any available transfer records.

Stage 5: Publication or sale

The acquired data may subsequently be advertised, sold, shared or published.

Evidence required: Original public-post evidence, reliable timestamps, archived copies where lawfully available and verified links between the posted records and the originating source.

Stage 6: Secondary exploitation

If genuine personal information is available to criminals, it may be used for targeted scams, identity fraud or further attempts to obtain credentials.

Evidence required: Fraud reports, customer complaints, relevant threat intelligence and evidence linking subsequent activity to the exposed information.

Current limitation: Public reporting establishes an alleged publication and SBI's reported investigation, but does not establish the preceding technical stages. The original intrusion path remains unknown.

7. MITRE ATT&CK Mapping

MITRE ATT&CK is a knowledge base describing adversary tactics and techniques. It can help investigators organise hypotheses and map observed behaviour to established terminology.

The techniques below are candidates for investigation only. They must not be presented as confirmed techniques used against SBI without supporting evidence.

ATT&CK techniqueIDWhy it may be relevant to an investigationCurrent statusValid AccountsT1078An attacker could abuse legitimate credentials to access data.Unconfirmed hypothesisExploit Public-Facing ApplicationT1190An exposed application could be an initial-access route.Unconfirmed hypothesisData from Information RepositoriesT1213Relevant if an actor collected information from a repository.Unconfirmed hypothesisExfiltration Over Web ServiceT1567Relevant if evidence shows data was transferred through an external web service.Unconfirmed hypothesisExfiltration Over Web Service: Exfiltration to Cloud StorageT1567.002Relevant if evidence establishes exfiltration to a cloud-storage service.Unconfirmed hypothesis

The mapping should be refined when evidence becomes available. If investigators establish that data was published by a third party without any new intrusion, the attack-path analysis would need to reflect that distinction.

Reference: MITRE ATT&CK — https://attack.mitre.org/

8. Detection and Threat-Hunting Recommendations

The following recommendations are intended for authorised defenders investigating a possible exposure of customer information. They are not claims that the relevant telemetry has been collected or that the proposed events occurred at SBI.

8.1 Identity and authentication monitoring

Investigate:

Correlate events with the user's normal access patterns and approved administrative activity to reduce false positives.

8.2 Database monitoring

Investigate:

A high-volume query is not automatically malicious. Investigators should consider the account, query purpose, timing, approved jobs and surrounding events.

8.3 Application and API monitoring

Review:

The objective is to determine whether the application enforced authorisation at the appropriate level and whether access patterns were consistent with legitimate use.

8.4 File and cloud-storage monitoring

Review:

Where cloud services are involved, correlate object-access logs with identity events, API activity and network telemetry.

8.5 Exfiltration monitoring

Review outbound network, proxy, endpoint and cloud logs for suspicious transfer patterns. Investigators should correlate volume, destination, timing, process identity and user activity rather than relying on a single indicator.

Encrypted traffic or traffic to a common cloud provider is not, by itself, proof of exfiltration.

###

9. Customer Impact and Threat Scenarios

9.1 Targeted phishing

An attacker with a customer's name, phone number and banking context could create a message that appears more credible than a generic phishing attempt.

For example, a fraudulent message might refer to a genuine branch or a previously submitted loan application.

The risk arises because personal context can make a fraudulent communication appear legitimate. This does not mean that a specific phishing campaign has been attributed to the SBI incident.

9.2 Vishing and impersonation

Vishing is voice-based phishing in which a caller attempts to persuade a victim to disclose information, authorise an action or transfer funds.

Exposed customer details could allow an attacker to impersonate a bank representative more convincingly. Customers may assume that someone who knows their name, branch or loan-related information must be legitimate.

9.3 Identity profiling

Information from different sources can be combined to build a more detailed profile of a person. This is sometimes described as data enrichment.

Even if an exposed dataset contains no passwords, combining contact information, identifiers and application details could increase the usefulness of the data to a fraudster.

9.4 Loan-related social engineering

If loan-related information is authentic, it could potentially support fraudulent communications about application status, verification requirements, fees or document submission.

The specific contents of the alleged PDF files have not been fully established, so claims about particular identity documents should remain conditional.

9.5 Account takeover

Account takeover means gaining unauthorised control of a person's account.

The reported PII exposure does not establish that SBI account credentials or transaction authorisation mechanisms were compromised. Nevertheless, exposed personal details could be used as supporting information in social-engineering or account-recovery attempts.

Risk conclusion: The principal demonstrated concern is exposure of personal information. Targeted fraud is a credible potential consequence, but actual downstream fraud attributable to this incident has not been established in the public evidence reviewed.

10. Customer Protection Recommendations

Customers should treat unexpected communications that refer to personal or loan-related details with caution.

Recommended precautions include:

Customers should not assume that every communication containing accurate personal information is legitimate.

11. Disclosure, Governance and Regulatory Questions

The incident also raises questions about how affected customers are informed and how organisations communicate the impact of a data exposure.

The Internet Freedom Foundation (IFF) published an analysis on 21 October 2026 and said it had written to SBI, copying the Reserve Bank of India (RBI) and CERT-In. Among other requests, IFF asked SBI to clarify what the larger dataset and alleged PDF collection contain, whether affected customers had been notified, and how the data left the relevant environment once the investigation is complete.

These are requests for clarification by a civil-society organisation, not findings that SBI violated a specific legal obligation.

At the time of IFF's publication, it said it had not found a public customer notification. The absence of a public notice does not prove that no affected customer was contacted privately. The status should be rechecked before publication.

Relevant legal and regulatory considerations include:

Legal obligations must be assessed against the provisions actually in force on the relevant date. The fact that a law has been enacted does not necessarily mean that every provision has already commenced. This report does not make a legal finding about SBI's compliance.

12. Evidence Ledger: Facts, Claims and Unknowns

An evidence ledger helps prevent an investigation from turning assumptions into conclusions.

StatementEvidence categoryAssessmentSBI disclosed a data-loss incident.Public disclosure reported by multiple outlets.Established as a reported disclosure.SBI's preliminary analysis identified 3,897 PII-containing customer records.SBI's reported disclosure.Established as the preliminary finding.Approximately 375,000 records were advertised or found online.Threat-actor claim and media reporting.Reported; complete authenticity and composition remain unresolved.Siriusim was associated with the publication claim.Public reporting of the alleged claim.Attribution of the claim is reported; original intrusion attribution is unproven.The alleged collection included 2,722 PDFs.Threat-actor claim reported by media.Not independently validated in full.Some sample records may correspond to real individuals.Limited media-reported sample checks.Supports the possibility that some samples are genuine; does not validate the full dataset.SBI's core operations were not materially affected.SBI's reported statement.Established as the bank's stated assessment of operational impact.A specific vendor was breached.No verified public evidence identified.Unknown.A specific vulnerability was exploited.No verified public evidence identified.Unknown.A particular employee or threat actor caused the original exposure.No verified public evidence identified.Unknown.The total number of unique affected individuals is known.No complete public reconciliation identified.Unknown.All affected customers were or were not notified.Public reporting raised the question; no complete verified answer identified.Requires updated confirmation.

13. What Evidence Would Resolve the Root Cause?

A conclusive technical investigation should establish the following.

13.1 Data provenance

Investigators should determine which legitimate system or organisation originally held the exposed records. Schema comparisons, document metadata and internal identifiers can help narrow the source, but require corroboration.

13.2 Initial access

Authentication records, vulnerability evidence, endpoint telemetry and relevant third-party logs should establish how unauthorised access first occurred, if an intrusion was involved.

13.3 Collection and exfiltration

Database audit records, file-access logs, export histories and network telemetry should establish whether data was collected and transferred without authorisation.

13.4 Scope

The final scope assessment should identify the affected data categories, the number of unique individuals, the period involved and whether the same source exposed additional records.

13.5 Attribution

Attribution should distinguish the person or organisation that first obtained the information from anyone who later possessed, sold or published it. The conclusion should be based on multiple corroborating lines of evidence.

13.6 Independent validation

A public summary of the independent investigation, where available, would allow researchers to distinguish confirmed technical findings from hypotheses and unsupported claims.

14. Intelligence Gaps and Confidence Assessment

High confidence

Moderate confidence

These assessments are limited to the reported evidence and should be updated if better primary evidence becomes available.

Low or undetermined confidence

The absence of public evidence is not proof that a particular event did not occur. It means the event cannot currently be established from the sources reviewed.

Research note: This is an open-source intelligence assessment, not an official forensic report. Claims, figures, legal requirements and incident status should be rechecked against original documents and any new official disclosures before publication. No conclusion in this report should be interpreted as a definitive attribution of the incident to a named individual, company or vulnerability.