🛡 DATA BREACHES 🛡

La filtración de TiDB expone suposiciones erróneas sobre la seguridad en la nube.

⏰22 de octubre de 2026🛡CyberObservatorio

Idioma

◢ DATA BREACHES ◣

La filtración de TiDB expone suposiciones erróneas sobre la seguridad en la nube.

⟫ 21/10/2026 ⟫ Nate Nelson

Fuente: Dark Reading

La reciente brecha de seguridad en un proveedor de bases de datos de código abierto ha sacado a la luz una grave deficiencia en la forma en que muchas empresas abordan la seguridad en la nube. Esta situación no solo afecta a la empresa implicada, sino que también pone en riesgo a una amplia gama de clientes y organizaciones que dependen de sus servicios. En un contexto donde la digitalización y la dependencia de la infraestructura en la nube se han vuelto omnipresentes, la protección de datos sensibles y la integridad de los sistemas son más cruciales que nunca.

El 19 de octubre, la empresa de software PingCAP, conocida por su programa de bases de datos SQL TiDB, reveló que había sido objeto de un ataque cibernético. Según la información en su sitio web, PingCAP proporciona servicios a importantes corporaciones estadounidenses como Atlassian, Square y Pinterest, así como a destacados actores en el ámbito de la inteligencia artificial en China, como Manus y Kimi, entre otros. La gravedad de la situación es evidente al considerar la magnitud de los clientes afectados y el potencial riesgo a la seguridad de sus datos.

Los perpetradores del ataque se identifican como "Fulcrum Security", o FulcrumSec, un grupo relativamente nuevo en el ámbito del cibercrimen que se especializa en extorsiones. Su sitio de filtración ya incluye a organizaciones de renombre como LexisNexis, Novo Nordisk y el Grupo de Aeropuertos de Manchester (MAG). Según las investigaciones preliminares, FulcrumSec logró comprometer a PingCAP, obteniendo acceso casi irrestricto a sus sistemas de gestión en la nube, finanzas, análisis y almacenamiento durante más de un mes.

Uno de los aspectos más preocupantes de esta brecha es si expuso datos sensibles de los clientes downstream. Aunque los investigadores aún están determinando el alcance del incidente, las primeras evidencias sugieren que la información almacenada por PingCAP sobre sus clientes podría haber estado en riesgo, a pesar de que las bases de datos de los clientes no fueron directamente comprometidas. Esto plantea serias cuestiones sobre la confianza que las empresas pueden tener en sus proveedores de servicios en la nube.

En una notificación de seguridad publicada 12 días después de la detección del incidente, PingCAP reconoció que los hackers tuvieron acceso a sus sistemas desde el 9 de septiembre hasta el 7 de octubre. Utilizando credenciales de cuentas de servicio robadas, los atacantes accedieron a sistemas internos de la empresa y copiaron datos y código fuente. No obstante, la investigación independiente realizada por PingCAP no encontró evidencia de que los atacantes ejecutaran comandos maliciosos o mantuvieran un acceso persistente en sus sistemas, ni que accedieran a las bases de datos de los clientes. En cambio, se determinó que los actores de amenazas accedieron a datos de facturación y otra información comercial, como términos de contrato y precios, así como datos relacionados con cuentas en la nube y el uso de productos.

Sin embargo, FulcrumSec presentó una narrativa más sombría. En un post de "nombre y vergüenza" en su sitio de filtración, afirmaron tener en su posesión todos los registros de gestión de servicios de PingCAP, sus registros financieros, archivos almacenados en Google Cloud, tickets de soporte de Jira, datos de gestión de relaciones con clientes (CRM), datos analíticos, código fuente, además de un registro de cuatro años de cada conexión que sus clientes realizaron al servicio TiDB Cloud. De forma crucial, los hackers no afirmaron haber robado bases de datos de TiDB directamente, sino que obtuvieron una gran cantidad de datos de usuario potencialmente explotables, como las mencionadas claves API y otros secretos, así como datos internos sensibles expuestos por comandos en la base de datos en la nube.

Los atacantes mencionaron a empresas específicas atrapadas en el fuego cruzado: compañías estadounidenses reconocidas como AirBnB y Booking.com, gigantes corporativos asiáticos como Baidu y Fujitsu, así como algunas de las más grandes empresas de videojuegos del mundo, incluidas Capcom, Konami y Square Enix. Asia representó la mayor parte de los afectados, con cerca de 2,000 organizaciones en Japón, China y Hong Kong, y 500 más en India.

FulcrumSec también aseguró que su acceso no autorizado se extendió por casi dos meses, no solo uno. Fue tan exhaustivo que, durante ese tiempo, lograron establecer un espejo del propio sistema de gestión de servicios de PingCAP. En lugar de tener que exfiltrar datos manualmente, su feed de replicación extraía automáticamente copias frescas de la base de datos interna de la empresa cada seis horas, durante 22 días.

Es importante tener en cuenta que las afirmaciones realizadas por actores de amenazas deben ser recibidas con cierto escepticismo. Dark Reading no ha podido confirmar de manera independiente las afirmaciones de FulcrumSec. Sin embargo, el grupo tiene un historial de fiabilidad. Por ejemplo, el verano pasado, FulcrumSec comprometió al Grupo de Aeropuertos de Manchester (MAG), alegando haber robado 86GB de datos. Sin embargo, esa cantidad resultó ser una subestimación, ya que el total real de datos robados fue de 640GB, lo que contenía mucha más información personal identificable de la que MAG había admitido.

Incluso si se ignoran por completo las afirmaciones de los hackers y se considera la evaluación más limitada de PingCAP como la verdad, el incidente sigue representando un riesgo potencialmente grave para los clientes. Los peligros más agudos residen no solo en los datos amplios de los clientes o en las claves API, sino en los datos exfiltrados menos obvios. Esto incluye tickets de Jira, historiales de SQL y lugares donde las organizaciones filtran inadvertidamente datos internos. Por ejemplo, cuando los clientes utilizan servicios de bases de datos gestionados en la nube, envían comandos a los servidores de los proveedores, lo que puede conllevar secretos corporativos o datos sensibles de diversas índoles.

Crystal Morin, estratega senior de ciberseguridad en Sysdig, explica que los proveedores no suelen tener la intención de almacenar secretos. Sin embargo, los clientes a menudo los transmiten para utilizar funciones diseñadas para mayor comodidad, y los datos pueden acumularse en lugares que pocos consideran como almacenes de credenciales. Un ejemplo de ello son los textos y errores del editor SQL de PingCAP, donde se puede acumular historial de consultas y salidas de error, lo que puede incluir cadenas de conexión utilizadas para depurar algo en el momento.

Shane Barney, director de seguridad de la información en Keeper Security, respalda el punto de vista de Morin, señalando que el incidente de PingCAP ilustra una realidad diaria en la seguridad empresarial: los atacantes no necesitan comprometer directamente la base de datos principal de un cliente si pueden obtener sistemáticamente credenciales de acceso de los proveedores. En los ecosistemas modernos de software como servicio (SaaS), los metadatos de los clientes, las claves API y los registros de consultas diagnósticas suelen filtrarse en los entornos de los proveedores a través de una telemetría operativa cotidiana. Cuando se roban credenciales de cuentas de servicio o tokens de API administrativos de un proveedor, esos datos operativos agregados se convierten en un mapa de explotación.

Ante esta situación, es fundamental que las organizaciones mantengan una buena higiene en la seguridad en la nube, como rotar las claves API orientadas a los proveedores y eliminar secretos codificados y de larga duración en los flujos de trabajo de desarrollo. También se recomienda evaluar a los proveedores de servicios gestionados exigiendo evaluaciones de riesgo de terceros continuas y certificaciones independientes, como SOC 2 Tipo II e ISO 27001.

Morin exhorta a las organizaciones a formular preguntas específicas al evaluar a los proveedores de la nube. "Los equipos deberían buscar entender qué datos proporcionados por el cliente retiene el proveedor y cuál es su política de retención. También deberían preguntar si escanean en busca de secretos al recibir datos y si eliminan lo que encuentran", sugiere. "Además, deberían entender cómo se manejan las credenciales de las cuentas de servicio, si son de corta duración, cómo están definidas, con qué frecuencia se rotan y qué detecciones se activan ante un uso anómalo de credenciales o cuentas".

Finalmente, Morin aconseja no olvidar preguntar sobre la notificación de brechas, específicamente el cronograma y los desencadenantes que la activan. En un mundo cada vez más digitalizado, donde la seguridad de la información es fundamental, estos pasos son cruciales para mitigar riesgos y proteger datos sensibles en la nube.

◢ DATA BREACHES ◣

TiDB Breach Exposes Flawed Cloud Security Assumptions

⟫ 21/10/2026 ⟫ Nate Nelson

Source: Dark Reading

A breach of an open source database provider may have inadvertently highlighted a serious gap in the way companies think about their cloud security. On Oct. 19, software maker PingCAP, which sells an SQL database program called TiDB, disclosed that it had been breached. According to PingCAP's website, it serves major American corporations like Atlassian, Square, and Pinterest, as well as major players in China's artificial intelligence (AI) space, includingManus,Kimi, and more. The perpetrator — the somewhat deceptively named "Fulcrum Security," or FulcrumSec, for short — is a relatively new extortionist group whose leak site already includes major organizations like LexisNexis, Novo Nordisk, and the Manchester Airports Group (MAG). Earlier this fall, FulcrumSec appears to have compromised PingCAP, enjoying something shy of unfettered access to all of its cloud management, financial, analytics, storage, and other systems for a month or more. The even bigger issue is whether the breach exposed downstream customers' sensitive data. Investigators are still working out the details, but early evidence suggests that customers may in fact be at some risk. Though their actual databases weren't breached, the information their vendor stored about them may have been enough to cause serious issues. Dark Reading reached out to PingCAP for comment but the company did not respond at press time. In asecurity notificationpublished 12 days after first having discovered the incident, PingCAP acknowledged that hackers had access to its systems from Sept. 9 to Oct. 7. Using stolen service account credentials, the company wrote, the unauthorized party accessed internal company systems and then copied data and source code. PingCAP's own third-party-assisted investigation found no evidence that attackers ran malicious commands or maintained persistent access in their systems, nor did they access any customers' databases. Instead, it said, the threat actors accessed customers' billing and other business data, such as contract terms and pricing, as well as various information pertaining to cloud accounts and product usage — email addresses, SQL editor text and errors, etc. They also exported a table with encrypted API keys, though investigators said the encryption protected the keys from actually being used maliciously. FulcrumSec, however, painted a bleaker picture. In a name-and-shame post to its leak site, the hackers claimed to be in possession of all of PingCAP's service management records, its financial records, its files stored within Google Cloud, Jira support tickets, customer relationship management (CRM) data, analytics data, source code, plus a four-year-long log of every connection every one of its customers ever made to the TiDB Cloud service. Crucially, the hackers did not claim to have stolen any TiDB databases straight up. Instead, they indirectly obtained a wealth of potentially exploitable user data like those aforementionedAPI keysand other secrets, and potentially sensitive internal data exposed by cloud database commands. The attackers fingered individual enterprises caught in the crossfire: brand name US companies like AirBnB and Booking.com, Asian corporate giants like Baidu and Fujitsu, and a few of the world's biggest video game companies, including Capcom, Konami, and Square Enix. Asia represented the biggest slice of the pie, with nearly 2,000 affected organizations in Japan, China, and Hong Kong, with another 500 from India. Additionally, FulcrumSec said its unauthorized access lasted for nearly two months, not just one. It was so comprehensive and unthreatened that, in the meantime, they were able to stand up a mirror of PingCAP's own service management system. Instead of having to manually exfiltrate data, their replication feed automatically pulled fresh copies of the company's internal database every six hours, for 22 days. Claims made by threat actors must always be met with a degree of skepticism, and Dark Reading did not independently confirm FulcrumSec's. Still, the group does have some record of reliability. Last summer, for example, the group breached Manchester Airports Group (MAG), claiming to have stolen 86GB of data. That data turned out to contain far more genuinepersonally identifiable information(PII) than MAG copped to, according to reporting byBleepingComputer. And whereas some hackers exaggerate their winnings, this case was something of the opposite: that initial 86GB claim in fact represented compressed data. The hackers clarified that the actual, uncompressed total stolen was actually 640GB. Even if one were to completely ignore the hackers' account, and take PingCAP's more limited assessment as the truth, it would still represent a potentially serious risk to customers. Arguably the most acute dangers — more than the broad customer data, or the API keys if they are in fact protected — lie in the less obvious exfiltrated data. This includes Jira tickets, SQL histories, and places where organizations unthinkingly leak internal data. For instance, when customers use their cloud-managed database services, they send commands to the vendors' servers, obviously. Those interactions can often carrycorporate secrets, or sensitive data of many other sorts. "Vendors don't typically set out to store secrets. However, customers often pass them over to use features built for convenience, and the data can settle in places few people think of as credential stores," Crystal Morin, senior cybersecurity strategist at Sysdig, explains. PingCAP's SQL editor text and errors as an example, she says. "That's query history and error output, which is where secrets can accumulate when someone pastes a connection string to debug something on the fly," Morin adds. In FulcrumSec's name-and-shame post, for example, it highlighted exfiltrated SQL statements that listed in full view one medical clinic's roster of patients, and another's list of medical professionals. Keeper Security chief information security officer (CISO) Shane Barney seconds Morin's point. "The PingCAP incident illustrates a daily reality in enterprise security: attackers do not need to compromise a customer's primary database directly if they can systematically harvest upstream credentials," he says. "In modernsoftware-as-a-service(SaaS) ecosystems, customer metadata, API keys and diagnostic query logs routinely seep into vendor environments through everyday operational telemetry. When service account credentials or administrative API tokens are stolen from a provider, that aggregated operational data transforms into a road map for exploitation." Barney emphasizes the importance of cloud security hygiene — such as rotating vendor-facing API keys, and eliminating hardcoded and long-lived secrets in developer workflows — and vetting one's managed service providers by demanding continuous third-party risk assessments and independent certifications and attestations such asSOC 2 Type IIand ISO 27001. Morin urges organizations to ask a few specific questions when vetting cloud providers. "Teams should seek to understand what customer-provided data the vendor retains and what its retention policy is. They should also ask whether they scan for secrets at ingest and redact what they find," she says. "Teams may also want to understand how service account credentials are handled, whether they’re short-lived, how they’re scoped, how often they rotate, and what detections fire on anomalous credential or account use." And, she says, don't forget: "Inquire about breach notification, specifically the timeline and what triggers it."

𝐗 Twitter f Facebook ☎ WhatsApp ✈ Telegram

← VOLVER A CIBERSEGURIDAD