A threat actor accessed CenterPoint Energy's systems and copied 7.49 million customer records without setting off any alarms. The entry point was a public API, and it lacked proper security measures.
What Happened
In August 2024, an unauthorized party extracted customer data from CenterPoint Energy, a utility serving about 7 million customers in Indiana, Minnesota, Ohio, and Texas. The attacker used an external-facing API to collect names, phone numbers, service and billing addresses, account numbers, billing amounts, and partial Social Security numbers.
The attacker, known as "4d722e4d656f77", contacted CenterPoint Energy before leaking the data. When the company didn't respond adequately, they published the dataset and explained their method: iterating through customer IDs via a public API that lacked rate limiting, web application firewall protection, and other controls.
CenterPoint confirmed the breach in a filing with the U.S. Securities and Exchange Commission. Multiple class-action lawsuits followed, alleging the breach occurred from August 17 to September 1, 2024.
Timeline
August 17-September 1, 2024: Attacker accesses customer records through public API
Early September 2024: Attacker contacts CenterPoint Energy
September 2024: Attacker leaks dataset after claiming company ignored warnings
September 2024: CenterPoint discovers online post claiming theft of 7.49 million records
September 2024: CenterPoint files incident disclosure with SEC
September-October 2024: Multiple class-action lawsuits filed in federal courts
Which Controls Failed
This breach wasn't sophisticated. The attacker didn't exploit a zero-day vulnerability or breach perimeter defenses. They simply accessed what was available.
Rate limiting: The API accepted millions of requests without throttling. A basic rate limit would have detected the pattern quickly.
Authentication and authorization: The API either didn't require proper authentication or allowed access beyond authorization. Each request should have checked if the session had permission to view the data.
Web application firewall: No WAF was in place to detect and block automated scraping. A WAF would have flagged the request volume and pattern as suspicious.
API security monitoring: The security team lacked visibility into API request patterns. Millions of sequential queries should have triggered alerts.
Input validation: The API accepted sequential ID enumeration without checking for automated access.
Data minimization: The API returned full customer records, including partial SSNs. It should have returned only the necessary data.
What the Standards Require
NIST CSF Core Functions highlight these failures:
Identify (ID.AM): Maintain an inventory of external-facing systems and APIs. CenterPoint had the API documented, but the security team didn't understand its exposure.
Protect (PR.AC): Identity management and access control must extend to APIs. Limit access to authorized users, processes, and devices.
Protect (PR.PT): Protect communications and control networks. An internet-facing API with customer data requires protective technology.
Detect (DE.CM): Security monitoring must cover all attack surfaces, including APIs. The lack of alerting on sequential requests was a detection failure.
NIST SP 800-53 requires:
AC-3 (Access Enforcement): Enforce approved authorizations for logical access. This API didn't enforce authorization at the record level.
SI-10 (Information Input Validation): Check information inputs for validity. Sequential ID enumeration should have been blocked.
AU-6 (Audit Review, Analysis, and Reporting): Review and analyze audit records for unusual activity. API access logs weren't reviewed adequately.
Insurance Data Security Model Law requires:
Section 4(a)(1): A comprehensive written information security program based on risk assessment
Section 4(a)(2): Designation of qualified individuals to oversee the program
Section 4(a)(4): Regular testing and monitoring of security controls
While CenterPoint isn't an insurer, utilities handling customer billing data face similar regulatory expectations.
Lessons and Action Items
Inventory your external-facing APIs today. Pull your API gateway logs, DNS records, and application documentation. List every API that accepts external requests. Document what data it exposes and its authentication requirements.
Implement rate limiting on every public API. Start with conservative thresholds. Adjust based on legitimate use patterns. A billing API shouldn't accept 10,000 requests per hour from one source.
Deploy a WAF in front of customer-facing APIs. Configure it to detect patterns like sequential IDs, high request volumes, and unusual geolocations.
Build API monitoring into your SOC. Your security team should get alerts for spikes in API requests, sequential ID patterns, or multiple queries from one source. Investigate these alerts promptly.
Enforce authorization at the record level. Validate every API request: Does this session have permission to access this record? Authentication doesn't equal authorization for all records.
Minimize data exposure in API responses. Return only the fields necessary for the API's purpose. Billing APIs rarely need to return partial SSNs.
Test your APIs with an attacker's mindset. Have your red team or a third party try to enumerate records, bypass rate limits, and access unauthorized data. Do this quarterly.
Document your API security architecture. When facing legal or regulatory scrutiny, explain your controls and their rationale. "We didn't know the API was exposed" won't suffice.
CenterPoint's breach shows that utility companies must secure public APIs like tech firms. Your customers trust you with their data. That trust requires more than good intentions. It requires rate limits, authorization checks, and monitoring to catch enumeration attempts before millions of records are compromised.
