Public Elasticsearch Instances Expose 43M+ Records Including Credentials, Credit Cards, and Customer Data

SOCRadar’s AI-powered Sensitive Data Exposure Monitoring service has identified three publicly accessible and misconfigured Elasticsearch instances leaking highly sensitive data, including infostealer logs, credit card information, and millions of personal identity records.

The exposed databases contained more than 43 million records, including over 5 million valid credentials, thousands of credit cards, and large-scale PII and commercial transaction data. All three cases demonstrate how misconfigured Elasticsearch services continue to create immediate and exploitation-ready risks for organizations and individuals.

Our security team analyzed the exposed instances, notified relevant parties, and assessed the potential impact. Below, we outline the findings and associated risks.

Public Elasticsearch Exposure Landscape

Before diving into the incidents, it is important to understand the broader exposure surface.

As seen in the Shodan query results, thousands of Elasticsearch services remain publicly exposed over port 9200. These instances are often indexed by search engines and continuously scanned by threat actors.

When authentication controls are misconfigured or disabled, Elasticsearch can expose raw data directly through its API, including full datasets without any exploitation required.

Incident 1: 7.2 Million Infostealer Logs and 24,000 Credit Cards Exposed

Our monitoring identified a publicly exposed Elasticsearch database containing large-scale infostealer log data. The instance was accessible without authentication and contained actively exploitable compromise data.

Data Scope:

• 7,275,513 infostealer logs
• 5,011,917 valid credentials
• 24,910 credit cards
• Approximately 6,000 valid credit cards

Data Types Exposed:

• Browser cookies
• Stored credentials
• Machine fingerprints
• Credit card data
• System information
• Session artifacts

Severity: Critical – Active exploitation-ready compromise data

What Was Inside the Database?

The database included indexed logs typically generated by malware families that harvest credentials from infected endpoints. These logs often contain:

• Auto-saved browser passwords
• Session cookies (still valid in some cases)
• Payment card data
• Device identifiers

In some entries, we observed structured fields containing card number fragments, expiry dates, CVV codes, and card type indicators.

Credential pairs were stored in plain text, making them immediately usable for automated credential-stuffing attacks.

Risks and Threat Actor Usage

This dataset represents ready-to-use attack material. Threat actors could leverage it for:

• Immediate account takeover
• Financial fraud
• Session hijacking
• Large-scale credential abuse campaigns
• Identity pivoting into corporate networks

From a threat intelligence perspective, datasets of this nature significantly enhance account takeover detection capabilities, enable continuous credential exposure monitoring, and enrich Dark Web intelligence analysis. They also support advanced session hijacking risk assessments by correlating compromised cookies, credentials, and device fingerprints.

Because these logs originate directly from infected machines, attackers may even bypass Multi-Factor Authentication (MFA) in cases where valid session cookies remain active, making the exposed data immediately operational for exploitation.

Incident 2: 35 Million Italian PII Records Publicly Accessible

The second Elasticsearch instance contained Italy-related personal identity and contact enrichment data. The dataset was removed after detection, but at the time of discovery, it was fully accessible.

Data Scope:

• 35,677,324 records
• 4.21 GB of indexed data

Data Types Exposed:

• Full names
• Phone numbers
• Personal email addresses
• Facebook user IDs
• Location information

Severity: Critical – Plain-text, highly actionable PII

Database Structure and Content

The exposed indices included structured identity fields suitable for data enrichment and profiling.

The indexed data appeared to be aggregated from multiple sources, enabling correlation between email addresses, phone numbers, and geographic locations.

Risks Associated with Large-Scale PII Exposure

Unlike credential leaks, PII datasets enable long-term abuse.

Potential risks include:

• Executive targeting and impersonation
• Spear-phishing and whaling attacks
• SIM-swap preparation
• Account takeover pre-positioning
• Identity correlation across services
• Persistent fraud campaigns

This type of data significantly increases Executive Protection risk, especially when attackers pivot from personal identity information to corporate affiliations.

Threat actors frequently combine such datasets with breached credential databases to build high-confidence phishing and Business Email Compromise (BEC) campaigns.

Incident 3: 1.5 Million Customer Records and Commercial Data Exposed

This Elasticsearch instance exposed Germany-related customer, address, and order data, including transactional and billing metadata.

Notably, although Shodan removed the listing, the server remained accessible at the time of our investigation.

Data Scope:

• 1,507,246 unique email addresses
• 23.65 GB of data

Data Types Exposed:

• Customer names
• Emails and phone numbers
• Billing and shipping addresses
• Order IDs
• Invoice metadata and PDFs
• Payment provider and transaction IDs
• Product and pricing information

Severity: Critical – Large-scale, highly sensitive PII and commercial data exposure

What the Dataset Contained

The database included detailed customer profiles, complete address records, and order-related identifiers. The presence of transaction IDs and invoice references suggests possible financial processing links.

Business and Regulatory Risks

Exposure of structured commercial data creates both cyber and compliance risks:

• Mass phishing campaigns targeting customers
• Account takeover attempts
• Payment fraud and refund abuse
• Identity theft
• GDPR-related regulatory exposure
• Reputational damage

Such datasets allow attackers to conduct highly convincing fraud campaigns using real order numbers and transaction details.

Why Misconfigured Elasticsearch Instances Are So Dangerous

Elasticsearch is designed for fast indexing and retrieval. When deployed without proper access controls, it effectively becomes a public data repository.

Common misconfiguration causes include:

1. Exposing port 9200 directly to the internet
2. Disabling authentication
3. Weak firewall rules
4. Lack of network segmentation
5. Mismanaged cloud security groups

Threat actors continuously scan for open Elasticsearch instances. Once identified, data extraction requires minimal technical effort.

How Organizations Can Prevent Elasticsearch Data Exposure

To reduce exposure risks, organizations should implement the following controls:

• Restrict Elasticsearch access to internal networks
• Enable authentication and role-based access control
• Deploy firewall rules and IP allowlisting
• Enforce TLS encryption
• Regularly audit exposed services
• Apply cloud security posture management
• Monitor for unintended public exposure

External attack surface visibility is critical. Organizations often overlook shadow IT deployments or test environments that become publicly reachable.

How SOCRadar Helps Detect and Mitigate Exposure

When sensitive data leaks through misconfigured services, internal security tools often miss it. Public Elasticsearch instances, shadow IT assets, and third-party environments sit outside the traditional perimeter.

SOCRadar closes that visibility gap.

By combining External Attack Surface Management, Digital Risk Protection, and Cyber Threat Intelligence, we continuously monitor the internet-facing surface for exposed services and sensitive data. When we detect publicly accessible credentials, PII, or commercial records, we analyze the risk, alert affected parties, and enrich the findings with threat intelligence context.

This approach enables organizations to detect exposure early, monitor credential abuse risks, strengthen executive protection, and reduce fraud and phishing impact. Instead of reacting after attackers exploit the data, organizations can identify and mitigate exposure before it turns into an incident.

Conclusion

The difference between a misconfiguration and a breach often comes down to how quickly it is detected.

Three publicly exposed Elasticsearch instances, more than 43 million records, and millions of valid credentials and highly sensitive customer data – all accessible without authentication.

These findings are not edge cases; they reflect a recurring operational weakness: improperly secured data stores exposed directly to the internet. In each case, the data was structured, searchable, and immediately usable for fraud, account takeover, phishing, and identity abuse.

Elasticsearch is not inherently insecure. Misconfiguration is.

Organizations must assume that exposed services will eventually be discovered by search engines, security researchers, or threat actors. Restricting access and enforcing proper authentication are baseline requirements. But visibility must extend beyond internal controls.