MeduzaLocker's "Licindia" Data Leak: Inside a Structured, Multi-Directory Exposure Claim

CyberMon identified a data-leak-site (DLS) listing operated under the MeduzaLocker name that contains a victim entry labelled "Licindia," associates it with the domain licindia.com, and exposes a categorized file repository spanning Financial, HR, Legal, Marketing, Reports, Clients, and Unsorted data. The data is listed for sale at $50,000. The domain and naming pattern are consistent with the Life Insurance Corporation of India (LIC), the country's dominant state-owned life insurer, though the DLS listing itself does not independently prove that the underlying data originated from LIC's infrastructure.

The strongest technical characteristic of the listing is its organization. Rather than a single archive or a flat credential dump, the repository is divided by business function. This matters because a cross-functional dataset can carry more intelligence value than isolated files: financial records can potentially be correlated with client, procurement, HR, tax, and operational data.

The evidence does not show where these files were originally stored. Nothing in the DLS post establishes whether the source was a workstation, shared drive, file server, accounting application, cloud repository, backup system, Nextcloud deployment, third-party environment, or another data source.

The five explicitly quantified categories account for 3,652 listed items before Clients and HR are considered.

The Financial directory is the largest explicitly quantified section. Visible spreadsheet filenames combine organization or trading names with structured identifier strings, including examples associated with AQUA ROYAL, AQUA TRENDS, ARUNA AGENCY, and ASN HYDRO.

Without opening and validating the underlying spreadsheets, CyberMon cannot determine which fields they contain or whether every identifier is genuine. If authentic, however, combinations of business names, registration-style identifiers, and reconciliation records could increase the credibility of vendor impersonation, payment-redirection, or targeted social-engineering attempts.

The Clients directory contains multiple CSV files beginning with "FBP Purchase Order," carrying sequential identifiers and date/time components in their filenames. The interface exposes both Open and Download actions for these files, and a separate OUTPUT.xls is also listed.

Purchase-order context can be operationally sensitive because it may reveal supplier relationships, transaction workflows, or document patterns. The captures do not prove that such information has been used in fraud; they only show the listed filenames and file-access routes.

The Legal directory contains filenames referencing GST and GSTR1, including multiple PDFs with structured identifiers and accounting periods such as 032023, 122022, 082022, 112022, 012023, and 062022.

The filenames support describing these as GST/GSTR1-labeled documents. They do not establish which taxpayer fields, personal data, or financial values are present inside the documents.

The HR directory includes a PDF named "ESI 51001438980000999C11.pdf," with Open and Download actions exposed by the interface.

The Reports directory includes multiple Microsoft Access database files: converted.mdb (38.8 MB), main1819.mdb (9.4 MB), main1920.mdb (10.7 MB), main2021.mdb (11.9 MB), main2122.mdb (14.6 MB), and main2223.mdb (15.1 MB).

The year-like naming pattern suggests a historical sequence, but the captures contain no database schemas, table names, or row counts. A single database can contain multiple related tables, so record counts cannot be inferred from file size alone.

The Marketing directory reports 415 items and contains numerous spreadsheets. Visible names include "01.MONTHILY GST RECONILATION APRIL 22 ONWARDS.xlsx," "stock.xlsx," and "Sundry Creditor.xlsx." Another page lists "Welcome to Nextcloud Hub.docx" and "winGlobal Sign.cer." This mix suggests that the actor's directory labels may not precisely reflect business ownership or data sensitivity.

The Unsorted directory reports 324 items and includes legacy .XLS files such as 01SLXL.XLS, 01SR1.XLS, and 01SR2.XLS. Legacy spreadsheet and Access formats can contain substantial structured data even when their filenames are generic.

The captured HTML reveals a browsable disclosure application rather than a static victim notice. Individual file entries expose routes following patterns such as /preview/sorted/<category>/<filename> and /download/sorted/<category>/<filename>. CSV and some supported files additionally expose /view/ actions. The platform implements pagination, with Marketing spread across five pages and Financial across 29 pages.

The DLS also repeatedly displays demo-access language indicating that only a subset of files is initially visible and that fuller access would be available after publication. This means the DLS post is best treated as evidence of a staged data-disclosure mechanism rather than a complete copy of the underlying dataset.

Many displayed file "Modified" timestamps cluster around 17-18 August 2026, while root directory timestamps in one capture show 19 August 2026. The DLS post appeared on 2 September 2026. These dates establish what the interface displayed at capture time.

They do not establish the breach date, initial compromise date, exfiltration time, ransomware execution time, or when the organization first became aware of the incident. The displayed timestamps could represent source-file metadata, ingestion timing, repository processing, or another internal workflow of the disclosure platform.

• A Tor interface branded MeduzaLocker FILESTATION.
• A victim entry named "Licindia."
• The actor page associates the entry with licindia.com and states nine emails were extracted.
• A multi-directory repository organized by business-function categories.
• Platform-reported counts for Financial, Marketing, Unsorted, Legal, and Reports.
• Visible Preview / View / Download routes and demo-access restrictions.

• The initial-access vector or exploited vulnerability.
• Whether ransomware encryption occurred inside the organization.
• The exact exfiltration volume or number of affected people.
• Whether every listed file originated directly from LIC infrastructure.
• Ransom amount, negotiations, or payment status.
• Independent confirmation by the affected organization.
• Any secondary fraud or weaponization of the exposed data.

• Business email compromise and invoice fraud: Purchase orders, creditor records, and financial context could potentially improve the realism of supplier-impersonation or payment-redirection attempts.
• Third-party exposure: Files named after external entities may indicate supplier, customer, or partner data that could require separate impact analysis.
• Identity and social engineering: HR, tax, and regulatory records may contain attributes useful for highly targeted social engineering.
• Historical structured-data exposure: The sequence of .mdb files could represent multi-year datasets. If validated, historical retention would materially affect incident scope.
• Credential and secret review: The listing of email addresses, a certificate file, and infrastructure-adjacent artifacts warrants investigation for passwords, tokens, private keys, browser stores, configuration secrets, or archived credentials.

• Validate authenticity: Compare sample filenames, hashes where available, document naming conventions, and internal file inventories against authoritative systems.
• Establish provenance: Identify the servers, shares, applications, endpoints, or repositories that originally hosted the relevant Financial, Legal, Marketing, Reports, HR, and Client material.
• Hunt for exfiltration: Review endpoint, identity, proxy, firewall, cloud, and storage telemetry for bulk reads, archive creation, staging, compression, and unusual outbound transfers.
• Scope identities and third parties: Determine whether the affected corpus contains employee, customer, vendor, partner, or other third-party information.
• Review secrets and authentication artifacts: Search the implicated repositories for credentials, tokens, browser data, private keys, certificate material, connection strings, and configuration files.
• Monitor for secondary abuse: Track phishing, impersonation, supplier fraud, leaked credentials, and other activity that may reuse genuine business context from the exposed files.

At the same time, the captures do not independently prove a compromise of LIC infrastructure, identify the attack vector, establish ransomware execution, quantify the actual exfiltrated dataset, or determine the number of affected individuals. Until those elements are independently validated, the most accurate characterization is a substantial MeduzaLocker data-exposure claim supported by a browsable file listing, with the underlying intrusion and complete dataset still requiring confirmation.