Full Report
In 2019, the now-defunct B2B marketing leads database service LimeLeads suffered a data breach due to an exposed, unsecured Elasticsearch server. The incident exposed tens of millions of records of largely corporate contact data containing 17.8M unique email addresses, along with phone numbers, employers, job titles and geographic locations including state, city and postcode.
Analysis Summary
# Incident Report: LimeLeads Exposed Elasticsearch Server Breach
## Executive Summary
In August 2019, the B2B marketing firm LimeLeads suffered a significant data exposure due to an unsecured Elasticsearch server left accessible to the public internet. The incident resulted in the compromise of 49 million records, including 17.8 million unique email addresses and sensitive corporate contact information, which were subsequently offered for sale on underground forums. The breach eventually contributed to the organization becoming defunct.
## Incident Details
- **Discovery Date:** September 2019 (Public reporting/HIBP indexing)
- **Incident Date:** August 2019
- **Affected Organization:** LimeLeads (Now defunct)
- **Sector:** B2B Marketing / Data Broker
- **Geography:** United States
## Timeline of Events
### Initial Access
- **Date/Time:** August 2019
- **Vector:** Misconfigured Cloud Database
- **Details:** An Elasticsearch server was left exposed to the internet without password protection or firewall restrictions, allowing anyone with the IP address to query the data.
### Lateral Movement
- **Details:** Not applicable. The data was stored in an exposed, flat-file structure within the unsecured database, requiring no lateral movement to access the primary data store.
### Data Exfiltration/Impact
- **Details:** Threat actors discovered the exposed instance and scraped approximately 49 million records. This data was later put up for sale on dark web marketplaces and hacking forums.
### Detection & Response
- **How it was discovered:** Security researchers and journalists (ZDNet) identified the exposed server and the subsequent sale of the data online.
- **Response actions taken:** The server was eventually secured/taken offline, though the company has since ceased operations.
## Attack Methodology
- **Initial Access:** Publicly accessible Elasticsearch instance (No authentication required).
- **Persistence:** Not required; data was permanently available until the server was secured.
- **Privilege Escalation:** None; the exposed service provided administrative-level access to data by default.
- **Defense Evasion:** None; the server was completely open.
- **Credential Access:** Not required.
- **Discovery:** Internet-wide scanning for open ports (specifically port 9200).
- **Lateral Movement:** N/A.
- **Collection:** Automated scraping of the Elasticsearch indices.
- **Exfiltration:** Direct download of database records via the exposed API.
- **Impact:** Massive data leak leading to corporate dissolution.
## Impact Assessment
- **Financial:** Significant loss of business value, legal liabilities, and eventual closure of the company.
- **Data Breach:** 49 million total records; 17.8 million unique emails. Includes names, employers, job titles, phone numbers, and granular geographic data.
- **Operational:** The service is now defunct.
- **Reputational:** Complete loss of trust in the marketplace as a data broker.
## Indicators of Compromise
- **Network indicators:** Public access to port 9200/tcp on LimeLeads infrastructure.
- **File indicators:** Database dumps appearing on hacking forums (e.g., "limeleads_49M_records.sql").
- **Behavioral indicators:** High-volume egress traffic from the database server to unrecognized external IP addresses.
## Response Actions
- **Containment:** The exposed Elasticsearch server was eventually secured or decommissioned.
- **Eradication:** Removal of public-facing access points.
- **Recovery:** Not applicable; the company did not survive the fallout of the incident.
## Lessons Learned
- **Key takeaways:** Misconfigured cloud assets remain one of the most common and damaging vectors for data breaches.
- **What could have been done better:** Implementation of a basic "Secure by Design" philosophy, ensuring that no database is reachable via the public internet without encrypted authentication and IP whitelisting.
## Recommendations
- **Access Control:** Implement strict Identity and Access Management (IAM) policies and ensure databases are placed within private subnets/VPCs.
- **Continuous Monitoring:** Utilize automated tools (e.g., Shodan alerts or cloud security posture management - CSPM) to scan for accidentally exposed ports.
- **Encryption:** Ensure data at rest is encrypted, though this does not replace the need for proper authentication.
- **Audit:** Conduct regular third-party security audits of cloud infrastructure.