CenterPoint Energy Data Breach: API Exposure and Enterprise Incident Response Lessons

CenterPoint Energy has confirmed that attackers stole customer personal information in a cyberattack, after a threat actor claimed online to have obtained millions of records from the Houston-based utility.

The incident is a reminder that a breach doesn’t require endpoint malware or a phishing email to succeed; sometimes an exposed external-facing system and a handful of missing API controls are all it takes.

For IT, security, and identity teams, the CenterPoint Energy breach is a case study in why public API security and external attack surface monitoring deserve the same attention as endpoints and identity providers.

Inside the CenterPoint Energy breach

Here’s how the incident surfaced and what CenterPoint Energy has confirmed so far.

• The claim: A threat actor posted online claiming to have stolen 7.49 million customer records, prompting CenterPoint’s investigation.
• The alleged data: Names, phone numbers, service and billing addresses, account numbers, billing amounts, and partial Social Security numbers, later partially leaked after the actor said the company ignored them.
• The confirmation: CenterPoint’s SEC filing confirms an unauthorized third party accessed customer personal information via an external-facing system.
• The unknowns: The filing doesn’t name the attacker, the number of customers affected, or the exact data types confirmed stolen.
• The impact: The incident did not disrupt electric and gas delivery services.
• The response: CenterPoint activated incident-response procedures, hired third-party experts, strengthened protections, and notified law enforcement and regulators. Law firms have since filed class-action lawsuits.

How the attack reportedly worked

The reported attack path is a useful illustration of how a public API without adequate controls becomes a direct customer data breach vector.

• ID enumeration: The threat actor claimed to have exfiltrated records by iterating through millions of sequential or predictable customer IDs on a public-facing API.
• Missing rate limiting: Without per-account or per-IP request throttling, an API has no built-in brake on high-volume, automated querying.
• No WAF protection: A web application firewall typically catches abnormal request patterns, scraping behavior, and known attack signatures before they reach the backend application.
• Lack of anomaly detection: Large-scale, sequential data pulls tend to look nothing like normal customer traffic, but only if something is actively watching for that pattern.

None of this required malware, credential theft, or a foothold on an endpoint. If the claims hold up, the entire event could have played out as a script quietly working through an ID range on a system its owners never built to notice.

The attack path, step by step

Closing the gap: Where Hexnode fits

While Hexnode doesn’t sit in front of a company’s public APIs, the broader lesson of this incident — that under-monitored external systems and automated abuse can move data before anyone notices — connects directly to endpoint-side visibility and containment.

Detection and containment (XDR):

• Hexnode XDR’s Investigate tab lets analysts run intuitive queries across roughly seven days of historical endpoint and process event data. The platform maps this data to the MITRE ATT&CK framework. This helps trace whether a script, browser session, or command-line tool on a managed endpoint accessed or staged sensitive data.
• If admins identify a compromised or misused endpoint during an incident like this, they have several response options. They can isolate the device from the network, retaining only the console connection for forensics. They can also kill the offending process or quarantine a suspicious file directly from the console.

Reducing exposure at the endpoint (UEM):

• Hexnode UEM lets admins push custom scripts (PowerShell, Bash, Python) to managed Windows, macOS, and Linux devices to block unauthorized tooling that attackers could use to interact with exposed systems from a managed device.
• Hexnode UEM feeds device compliance status into Microsoft Entra ID for Conditional Access on Android, iOS, and macOS 11+ devices. For Okta environments, Hexnode pairs with Okta Device Trust to enforce context-aware access policies.

What Hexnode doesn’t cover:

Hexnode doesn’t sit in front of a company’s public-facing APIs. It doesn’t provide rate limiting, WAF rules, or abuse detection for them. That layer of defense belongs to API gateways, WAF vendors, and application security tooling, not endpoint management or XDR.

Featured resource

Introduction to Hexnode XDR

Hexnode XDR unifies endpoint visibility, threat detection, and UEM integration for proactive enterprise-wide security remediation.

DOWNLOAD

Conclusion

The CenterPoint Energy breach didn’t need a phishing email or malware to unfold; it needed an exposed API and a few missing controls. That’s an increasingly common pattern, one enterprises can’t outsource entirely to their identity or endpoint stack.

Public APIs, customer portals, and other external-facing systems need dedicated hardening. That means rate limiting, WAF rules, and anomaly detection tuned to bulk-access patterns. Teams should also review what they expose to the internet. Pairing that with endpoint visibility, XDR-driven investigation, and device-aware access completes the picture. Together, these treat API and endpoint security as one problem, not two.