Full Report
It happened at a major US telco in the early 2000s
Analysis Summary
# Incident Report: Massive Storage of Plaintext Customer PII/PCI at Major US Telco
## Executive Summary
A newly hired Database Administrator (DBA) discovered that a major US cellular carrier was storing millions of customer records, including Social Security Numbers and full credit card details with CVVs, in unencrypted plaintext. The vulnerability was compounded by "day-one" sudo-level access granted to new staff without vetting or least-privilege controls. The issue was remediated by purging the local data and requiring the system to query the secure upstream billing provider as intended.
## Incident Details
- **Discovery Date:** Early 2000s (Exact date unspecified)
- **Incident Date:** Ongoing until discovery in the early 2000s
- **Affected Organization:** Major National US Cellular Carrier (Name withheld)
- **Sector:** Telecommunications
- **Geography:** United States
## Timeline of Events
### Initial Access
- **Date/Time:** New Hire's First Day
- **Vector:** Over-provisioned Internal Employee Credentials
- **Details:** A new DBA ("Joker") was granted immediate `sudo`-level access to production database servers during her initial onboarding.
### Lateral Movement
- **Details:** No movement was necessary; the initial credentials provided immediate, unrestricted access to the main production server housing mobile data service records.
### Data Exfiltration/Impact
- **Details:** While no malicious exfiltration was reported, the potential scope included the entire master customer table. Data included names, addresses, SSNs, and 16-digit credit card numbers (some with CVV) for the carrier’s entire national subscriber base.
### Detection & Response
- **How it was discovered:** Internal audit by a new employee ("Joker") during a "get to know the system" task.
- **Response actions taken:** Management was notified; the plaintext billing data was deleted from the local database; developers were forced to re-integrate with the secure upstream Amdocs billing server for all transactions.
## Attack Methodology
- **Initial Access:** Valid internal administrator credentials granted on day one.
- **Persistence:** Standard administrative account persistence.
- **Privilege Escalation:** Not required; user was granted `sudo` immediately.
- **Defense Evasion:** None; the data was stored openly in the clear.
- **Credential Access:** Access to the database provided direct access to customer financial credentials.
- **Discovery:** Manual database querying and table inspection.
- **Collection:** Access to the master customer table.
- **Exfiltration:** Potential for bulk export (though not executed by the whistleblower).
- **Impact:** Massive exposure of PII and PCI data.
## Impact Assessment
- **Financial:** Potential for catastrophic fines and fraud losses had the data been breached by a malicious actor.
- **Data Breach:** Exposure of millions of records (SSNs, CC numbers, CVVs).
- **Operational:** Required immediate architectural changes to the mobile web billing workflow.
- **Reputational:** Massive potential for brand damage in the early days of mobile commerce.
## Indicators of Compromise
- **Network indicators:** N/A (Internal misconfiguration)
- **File indicators:** Cleartext storage of CSV/SQL tables containing "CC_Num" or "SSN" strings.
- **Behavioral indicators:** Immediate use of root/sudo privileges by unvetted new hires.
## Response Actions
- **Containment:** Access to the production database was reviewed.
- **Eradication:** Deletion of stored credit card and PII data from the local production server.
- **Recovery:** Restoration of proper API/upstream calls to the secure Amdocs billing system.
## Lessons Learned
- **Architecture Flaw:** Locally "caching" sensitive billing data to avoid upstream latency creates a massive security liability.
- **Onboarding Risk:** Giving full production `sudo` access to new hires before background checks or departmental vetting is completed is a critical failure.
- **Compliance:** Failure to adhere to basic cryptographic standards (even in the early 2000s) suggests a lack of internal audit controls.
## Recommendations
- **Least Privilege:** Implement Role-Based Access Control (RBAC). Employees should only have access to the data required for their specific role.
- **Zero Trust:** Move toward a zero-trust model where internal access is not implicitly trusted.
- **Tokenization:** Use tokenization for sensitive data so that customer names and financial details are never stored in the same cleartext table.
- **Encryption at Rest:** Ensure all PII and PCI data is encrypted using industry-standard algorithms (AES-256).
- **Data Minimization:** Never store CVV data, and only store the minimum amount of PII necessary for business operations.