Existe una categoría de brecha que no produce alertas, no activa ninguna regla de detección y no deja rastro de intrusión, porque no hay intrusión. Alguien le hace a una interfaz pública una pregunta que nunca debió responder, y la interfaz responde, con toda cortesía, varios millones de veces.
Qué pasó
El 14 de septiembre de 2026, CenterPoint Energy presentó un Formulario 8-K ante la SEC informando que tenía conocimiento de una publicación en línea en la que un tercero decía tener un conjunto de datos con información de clientes. CenterPoint es una empresa de servicios públicos con sede en Houston que atiende a unos siete millones de clientes en Indiana, Minnesota, Ohio y Texas.
La vía fue un sistema expuesto a internet. Según el propio relato del atacante, la interfaz carecía de tokens de autenticación, límites de tasa, verificación de certificados y firewall de aplicaciones web. Afirma haber extraído 7.49 millones de registros de clientes en formato JSONL —nombres, teléfonos, direcciones, números de cuenta, montos de facturación, los últimos dígitos del número de seguridad social y números de licencia de conducir— y señala que un CAPTCHA fue el único obstáculo que le impidió alcanzar los 17.44 millones de registros disponibles.
Dos cosas merecen énfasis, y apuntan en direcciones opuestas.
El formulario es evidencia sólida. Un 8-K es una declaración regulada, con consecuencias legales si es inexacta. No es un boletín de prensa de un proveedor ni una fanfarronada de foro: la empresa reconoció el hecho de manera formal.
Las cifras no lo son. CenterPoint se abstuvo expresamente de confirmar el número de registros y afirmó que sigue trabajando con especialistas externos para determinar el alcance, y que notificará a clientes y reguladores según lo exija la ley. La cifra de 7.49 millones y las categorías de datos vienen del atacante. No las repetiríamos como hechos establecidos, y nadie debería hacerlo: es justamente el error que el sector cometió varias veces este año.
La compañía indicó que su operación no se vio interrumpida. Los sistemas que controlan el suministro de electricidad y gas no estuvieron involucrados.
Por qué este tipo de brecha es tan difícil de notar
Una intrusión convencional deja evidencia: un inicio de sesión desde un lugar extraño, una elevación de privilegios, un proceso que no debería estar corriendo, una conexión saliente a un host desconocido. La ingeniería de detección se construye sobre el supuesto de que algo anormal ocurre.
Una API demasiado permisiva no produce nada de eso. Cada solicitud está bien formada. Cada respuesta es un 200. El tráfico va a un servicio que debe ser alcanzable, desde clientes que parecen clientes. La única señal es el volumen, y el volumen solo sirve si alguien definió por adelantado qué es normal y fijó un umbral.
Por eso estos casos suelen salir a la luz no por el monitoreo sino por la publicidad del propio atacante. La organización se entera cuando aparece en un foro.
Las preguntas que esto debería provocar
Casi cualquier organización puede enumerar sus aplicaciones web. Muchas menos pueden enumerar los endpoints de API que hay detrás, y menos todavía pueden decir qué devuelve cada uno ante una solicitud sin autenticar. La brecha se abre en lugares predecibles:
- Un endpoint hecho para una aplicación móvil, que se asume privado porque la app es el único cliente previsto.
- Una consulta usada por una sola página interna, que nunca se pensó para ser invocada directamente.
- Un endpoint de integración para un socio, autenticado con una llave compartida que nunca se rotó ni se acotó.
- Algo que un proveedor levantó durante un proyecto y quedó vivo después de terminarlo.
Nada de esto es exótico. Es el residuo normal de construir software a lo largo del tiempo.
Qué hacer en concreto
Inventaría lo expuesto a internet, incluyendo lo que no construiste. No solo sitios: endpoints. Escanea tu propia huella externa como lo haría un atacante, e incluye subdominios, entornos de pruebas y cualquier cosa que un proveedor haya desplegado por ti.
Prueba qué entrega cada endpoint sin credenciales. Quita el token, envía la solicitud, lee la respuesta. Hazlo desde fuera de tu red. Este único ejercicio encuentra más que el alcance de muchas pruebas de intrusión, y cuesta una tarde.
Limita la tasa por defecto, no por excepción. Una interfaz que devuelve un registro de cliente por solicitud es una consulta. La misma interfaz respondiendo doscientas mil veces es una exportación masiva. La diferencia es un umbral que alguien tiene que fijar.
No uses un CAPTCHA como control de acceso. Según el propio atacante, lo demoró; no le impidió llevarse 7.49 millones de registros. El CAPTCHA es fricción, no autorización.
Alerta por volumen de respuestas por cliente. Si registras el tráfico de API y nadie lo lee, tienes la evidencia de la brecha y ninguno de los beneficios. Las anomalías de volumen por identidad son una de las pocas detecciones que funcionan para este tipo de problema.
Diseña la respuesta para devolver menos. Un endpoint que contesta "¿esta cuenta existe?" no necesita devolver el número de licencia de conducir del titular. Devolver de más es la causa raíz más común aquí, y la más fácil de corregir en una revisión de código.
Una nota sobre infraestructura crítica
La cobertura ha sido clara en que el suministro de gas y electricidad no se vio afectado, y esa distinción importa. La tecnología operativa que mueve una red eléctrica es un entorno distinto de los sistemas de facturación que guardan datos personales, y confundirlos produce alarmismo que no ayuda a nadie.
Pero el lado comercial de una empresa de servicios públicos guarda exactamente el material que hace funcionar el fraude de identidad: nombre, dirección, número de cuenta, parte del número de seguridad social, licencia de conducir. Para los siete millones de personas del otro lado, "las luces siguieron encendidas" es cierto y no especialmente reconfortante.
El resumen
Nada fue hackeado, en el sentido en que suele usarse la palabra. Un sistema que debía ser alcanzable lo era, y respondió con más generosidad y más veces de lo que nadie se había puesto a verificar. Eso es un problema de diseño y de inventario, no de defensa, y por eso rara vez lo atrapan los controles en los que más se invierte.
La solución no tiene glamour y es barata frente a la exposición: saber qué expones, probar qué devuelve sin credenciales y ponerle un límite a cuántas veces va a responder.
Fuentes
- CenterPoint Energy confirms data breach following claims on hacking forum — Help Net Security
- CenterPoint Energy customers' personal information breached in data incident — ABC13 Houston
- CenterPoint Energy data breach — hackers stole customers' personal data — Cybersecurity News
