Threat intel

CenterPoint Energy, the Houston electric and natural gas utility with about 7 million metered customers in Texas, Indiana, Minnesota and Ohio, has reported to the Texas Attorney General that 1,062,060 Texas residents were affected by a data breach. The listing, posted on October 13, gives the exposed data as names, addresses, Social Security number information and driver's license numbers. Customers in the other three states may be affected too; CenterPoint has not published a total.

The company first disclosed the breach in a Form 8-K filed with the Securities and Exchange Commission (SEC) on September 14, saying an unauthorized third party obtained customer personal information "through one of the Company's external facing systems". It learned of the theft from a hacker's forum post. That hacker claims 7.49 million records, pulled through a customer-facing API (application programming interface) that had no authentication token, no rate limiting and no web application firewall (WAF) in front of it. CenterPoint has confirmed neither the method nor the count. Anyone running a customer portal or mobile app backed by an API should test for the alleged weaknesses now.

Confirmed facts and claims

CenterPoint's 8-K, filed under Item 8.01 (other events) rather than Item 1.05 (material cybersecurity incidents), says electric and gas delivery was not affected, that the scope is still being determined, and that the company does not expect a material impact on its finances. It brought in outside incident responders, reported the breach to law enforcement and notified some regulators. It did not name the system, the attacker or the data fields.

The rest comes from the attacker, who posts as "4d722e4d656f77". On September 12 they offered a 2.5 GB archive on a cybercrime forum. BleepingComputer, Security Affairs and Help Net Security report the claimed fields as names, phone numbers, service and billing addresses, account numbers, billing amounts and partial Social Security numbers; Help Net Security and CyberInsider say the partial numbers are the last four digits. The attacker also says a CAPTCHA (a challenge that blocks automated clients) stopped the download partway, and that about 17.44 million records were otherwise within reach.

The gap between 7.49 million records and 1,062,060 Texans has several possible explanations. A record may be an account or a service address rather than a person, so one customer can appear several times; the Texas figure excludes the other three states; and forum sellers often inflate their numbers. None of these has been confirmed. Proposed class actions filed in federal court allege the theft ran from August 17 to September 1.

How a customer API leaks a whole customer base

A typical portal call looks like GET /api/accounts/{accountId}/billing. Two checks should happen on every request. Authentication proves who the caller is, usually with a session token or a JSON Web Token (JWT), a signed token in the Authorization header. Object-level authorization then confirms that this caller owns accountId. OWASP lists the failure of the second check as API1:2023, Broken Object Level Authorization, the top API risk.

If an endpoint skips both checks, and account IDs are numeric or follow a predictable format, a script can request every ID in turn. That is enumeration. Rate limiting (OWASP API4:2023, Unrestricted Resource Consumption) caps how many requests one client may make per minute, and a WAF or bot management rule can flag a single source sending thousands of uniform requests. The attacker claims all four controls were absent, and BleepingComputer reports they said they walked through millions of IDs.

The exposed fields matter as much as the access check. Customer APIs often return the whole database row, last four of the Social Security number and driver's license number included, while the screen shows only a name and a balance. OWASP calls this API3:2023, Broken Object Property Level Authorization. Guest flows such as paying a bill or checking an outage with an account number but no login are the usual place to find endpoints shaped like this. We have no confirmation that CenterPoint used one.

What to test in your own APIs

Start from traffic, not documentation. Export the routes seen in your API gateway or load balancer logs for the last 30 days and compare them with your OpenAPI specs; old mobile app versions and guest flows tend to show up only in the logs.

For authorization, create two test customers, A and B. Request B's account, bill and profile with A's token, with no Authorization header, and with an expired token. Each should return 401 or 403, and the response body should not differ in a way that confirms B exists. Do this on every route that takes an ID, including the parameters in POST bodies.

For rate limits, send 300 requests in one minute from a single client to a lookup endpoint and confirm you get HTTP 429 (too many requests) well before the end. Limit per token, per source IP and per looked-up account, because an attacker spreading requests across many IP addresses beats a per-IP limit alone. Compare the JSON returned with what the page renders and strip anything the page does not use.

Checking whether it already happened

The useful signal is one client touching many different objects. In Splunk, against gateway or proxy logs with a uri_path field:

index=web uri_path="/api/accounts/*" status=200 | rex field=uri_path "/api/accounts/(?<acct>[^/]+)" | stats dc(acct) AS accounts sum(bytes) AS bytes BY src_ip | where accounts > 50 | sort - accounts

Set the threshold to a real customer's behaviour; a household rarely has more than a few accounts. Look also for successful 200 responses with no Authorization header, user agents such as python-requests, curl or Go-http-client, and IDs requested in numeric order. If your logs keep only seven days, an exfiltration lasting two weeks, as the CenterPoint lawsuits allege, is already partly gone, so check retention on the gateway, WAF and CDN before you need it.

Notification clocks if it happens to you

For US public companies, the SEC requires an Item 1.05 8-K within four business days of deciding an incident is material. SEC staff guidance from May 2024 says incidents judged not material, or not yet assessed, can be disclosed voluntarily under Item 8.01, which is what CenterPoint did. A later materiality decision starts the four-day clock for an Item 1.05 filing.

Texas law (Business and Commerce Code section 521.053) requires notice to affected people within 60 days of determining a breach occurred. A breach of 250 or more Texans must also be reported to the Attorney General, through its online form, within 30 days, including the number of residents affected and notified so far. The CenterPoint listing appeared about a month after the 8-K. Indiana, Minnesota and Ohio each have their own notice laws, so a multi-state customer base means several clocks running at once. Keep a per-state count of affected people from the first day of the investigation; every regulator form asks for it.

CenterPoint customers should expect phishing that quotes a real account number, address and bill amount, and should check any payment request against the amount shown when they log in to the portal directly.

Our web application penetration tests run the cross-account, enumeration and rate-limit checks above against your own APIs, and our attack surface management work finds the forgotten endpoints and app backends that never reached the spec. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: SecurityWeek, Security Magazine, Security Affairs, CenterPoint Energy Form 8-K, BleepingComputer, Help Net Security, CyberInsider, AllAboutLawyer, OWASP API Security Top 10 2023, Texas Business and Commerce Code 521.053, Bryan Cave Leighton Paisner on Item 1.05 and 8.01.