Resumen
Una bolsa de criptomonedas identificada como NCX supuestamente dejó una instancia interna de MongoDB expuesta en la Internet pública sin autenticación. La base de datos fue accesible durante meses, contenía ~1 GB de datos y más de 5 millones de registros, e incluía nombres, correos electrónicos, fechas de nacimiento, enlaces a documentos KYC, contraseñas con hash, semillas/URL 2FA, claves API internas, historial de IP, direcciones de monederos de cuentas y registros de transacciones.(Análisis diario de seguridad) No se trata sólo de una "fuga de PII". Se trata de una superficie de compromiso completa: robo de identidad, fraude KYC, toma de posesión de la cuenta, en la cadena de orientación, la exposición reglamentaria, y las obligaciones de respuesta a incidentes en virtud de los regímenes de protección de datos modernos que requieren la divulgación dentro de las 72 horas.(GDPR)

Este artículo aborda la violación del estilo NCX desde dos ángulos:

1. Pruebas ofensivas / realidad del equipo rojo: cómo esta configuración errónea se convierte en explotación activa.
2. Cumplimiento y respuesta: qué debe hacer una vez que sabe que ha perdido el control de los datos de identidad de los clientes y los secretos multifactor.

También explicaremos cómo una plataforma de pruebas ofensivas continuas como Penligent puede sacar a la luz y simular estos modos de fallo exactos antes de que lo haga un regulador, un atacante o un periodista.

Resumen del incidente: Qué se filtró y por qué es importante

El problema reportado es simple en su formulación y brutal en sus consecuencias: una instancia de MongoDB conectada a Internet sin autenticación. Cualquiera que conociera (o pudiera adivinar/escanear) la IP y el puerto podía navegar por las colecciones en texto plano.(Análisis diario de seguridad)

Tipos de datos expuestos

Según la divulgación, el conjunto de datos NCX contenía (por registro, más de millones de filas):

• Nombre completo / correo electrónico / fecha de nacimiento
• Imagen KYC o enlaces a documentos (pasaporte, DNI)
• Valores de semilla 2FA y URL de inscripción
• Contraseñas cifradas
• Historial de direcciones IP y metadatos de inicio de sesión
• Claves API internas / tokens de servicio
• Direcciones de monedero, historial de depósitos/retiradas, actividad en cadena
• Indicadores de estado de la cuenta (prohibición / congelación / riesgo)
• Registros de tickets de soporte

Esto es inusualmente malo por tres razones:

1. Adquisición de identidad a escala
   Si un atacante tiene su nombre legal + DoB + imagen de pasaporte, puede abrir cuentas en otros lugares, "recuperar cuentas" mediante ingeniería social o pasar el KYC en lugares más débiles. Esto es un apalancamiento de robo de identidad de libro de texto.(Análisis diario de seguridad)
2. Evasión de MFA a través de la exposición de semillas 2FA
   Si se almacenan y filtran semillas de contraseñas de un solo uso basadas en el tiempo (TOTP), un atacante puede generar códigos 2FA válidos bajo demanda e iniciar sesión como usted, aunque nunca haya compartido su contraseña. Las semillas 2FA comprometidas son esencialmente "tokens de sesión precocinados"(Análisis diario de seguridad)
3. Custodia + selección en cadena
   Las direcciones de los monederos y los historiales de transacciones permiten a un adversario determinar qué usuarios mueven realmente el dinero. Esos objetivos de alto valor pueden ser objeto de phishing ("Su retirada está bloqueada, por favor firme aquí") o SIM-swapped. Hemos visto plataformas de criptomonedas que advierten a los usuarios afectados de que esperen un phishing personalizado utilizando exactamente este método.Análisis diario de seguridad)

Problema de falta de respuesta

Al parecer, los investigadores que encontraron la base de datos MongoDB abierta intentaron la divulgación responsable en múltiples ocasiones y no recibieron una respuesta oportuna.(Análisis diario de seguridad)
Desde un punto de vista normativo, esto es catastrófico: Los regímenes de clase GDPR y muchas autoridades nacionales de protección de datos esperan una rápida contención, preservación de pruebas, notificación de la violación a los reguladores dentro de las 72 horas y, en muchos casos, notificación al usuario si el riesgo para los usuarios es alto.(GDPR)

Cadena de ataques: cómo un equipo rojo convierte "Open MongoDB" en un compromiso total de la cuenta

Esta sección está escrita como la narración de una prueba de penetración, porque así es como la recorrería un atacante (o un probador responsable).

Paso 1: Enumeración de MongoDB expuestos

• Escanea amplias franjas del espacio de direcciones de la nube en busca de los puertos clásicos de MongoDB (27017/27018).
• Agarrar banner / estado del servidor para confirmar el acceso no autenticado.
• Lista de bases de datos y colecciones (db.getNombresDeColección() etc.).
• Deshacerse de colecciones de gran valor: usuarios, auth, kyc, cartera, transacciones, apiKeys, entradas.

En otras palabras, esto no es "0-day". Es un error de configuración de los años 90: base de datos en Internet, sin autenticación, sin cortafuegos. El CISA y el NIST advierten repetidamente de que los almacenes de datos expuestos a Internet sin autenticación siguen siendo uno de los puntos de entrada más comunes de las brechas.(Comisión Europea)

A continuación se muestra una pseudo-sesión simplificada que un atacante podría ejecutar desde una caja de pruebas (no ejecutes esto contra sistemas que no poseas o tengas permiso para evaluar; realizar accesos no autorizados es ilegal):

# Descubrir hosts MongoDB abiertos (sólo lógica de ejemplo)
nmap -p 27017 --open  -oG mongo_hosts.txt

# Conectarse a un host descubierto sin credenciales
mongosh --host :27017 --eval "db.adminCommand('listDatabases')"

# Enumerar colecciones en una BD de destino
mongosh --host :27017 --eval "use ncx_users; db.getCollectionNames()"

# Volcar los documentos relacionados con los usuarios
mongosh --host :27017 --eval "use ncx_users; db.users.find().limit(5).pretty()"

Para un verdadero equipo rojo, esto es lo que está en juego. Para un regulador o el abogado de un demandante, es una prueba irrefutable de que el sistema no tenía "controles de seguridad razonables".

Paso 2: Recoger secretos y material de autenticación

Una vez dentro, un atacante tira:

• password_hash o equivalente
• totp_seed / 2fa_secreto
• clave_api / api_secret
• URL de archivos KYC

Este es el premio gordo. Los hashes de contraseñas pueden descifrarse sin conexión; las semillas TOTP permiten acuñar códigos MFA válidos; las claves API pueden comunicarse con backends internos de administración o comercio.

Los investigadores de seguridad y los equipos DFIR han señalado en repetidas ocasiones que las semillas 2FA filtradas y las credenciales API "reutilizables" son un botín de gran valor porque se convierten en una toma de control directa de la cuenta y en un movimiento lateral.(Análisis diario de seguridad)

Paso 3: Adquisición simulada de la cuenta

Con un nombre de usuario/email + contraseña (o hash crackeado offline) + semilla TOTP robada, un atacante puede generar códigos válidos de 6 dígitos localmente. Esto significa un inicio de sesión completo sin siquiera tocar el teléfono de la víctima.

Si el intercambio admite el restablecimiento de contraseña por correo electrónico y 2FA, y ambos están comprometidos, el atacante puede bloquear al usuario por completo. Este escenario (eludir la MFA utilizando datos TOTP o de factor de restablecimiento robados) es exactamente la razón por la que las guías de respuesta a las brechas de criptografía indican a los usuarios afectados que deben rotar inmediatamente las credenciales, volver a inscribir la MFA y supervisar las retiradas de fondos.(CCN.com)

Paso 4: CSC y usurpación de identidad

Dado que los enlaces a las imágenes de KYC y los escaneos de ID estaban al parecer ocultos (o detrás de URL adivinables / de larga duración), los atacantes pueden utilizarlos:

• para abrir nuevas cuentas de cambio en otro lugar como otra persona;
• para hacer ingeniería social de la atención al cliente en otros servicios ("Ahora le envío mi pasaporte, por favor, desbloquee");
• para suplantar a usuarios de alto valor con detalles muy personales ("Hola, por AML congelamos su retiro...").

Ya estamos viendo cómo las plataformas de criptomonedas advierten públicamente de que los artefactos KYC filtrados se convierten en combustible para el phishing y el fraude a medida.(Análisis diario de seguridad)

Paso 5: Selección en cadena

Las direcciones de las carteras y los registros de transacciones te dicen quién mueve realmente un volumen serio. Esa lista es oro para:

• spear-phishing (estafas de "verificación de seguridad"),
• amenazas de extorsión,
• ataques de polvo y estafas de secuestro de aprobación (firme esto, pierda fondos).

Los atacantes han pasado del "robo de contraseñas de intercambio" al "uso de metadatos financieros filtrados", porque se adapta mejor a las circunstancias y a la ingeniería social.Análisis diario de seguridad)

Lista de comprobación defensiva y correctiva (técnica)

Esto es lo que NCX (o cualquier criptointercambio, monedero fintech o plataforma de KYC-heavy) debería hacer inmediatamente después de descubrir una filtración abierta de MongoDB.

Base de seguridad de la base de datos

• Acabar con la exposición pública ahoraEliminar la instancia del enrutamiento público o bloquearla tras reglas de cortafuegos / acceso exclusivo a la VPC.
• Requerir autenticación: habilite la autenticación de MongoDB y el acceso basado en roles; nunca permita lecturas anónimas desde Internet.
• TLS en todas partes: fuerzan el transporte encriptado, no en texto plano.
• Principio del menor privilegio: los microservicios orientados al usuario sólo deben ver las colecciones que necesitan absolutamente.
• Registro y alertaRegistros de auditoría: conecte registros de auditoría continuos sobre intentos de acceso y consultas anómalas. El NIST y los reguladores de la UE esperan registros que muestren quién ha accedido a qué, cuándo, durante y después de una violación.(Comisión Europea)

Secreto y gobernanza de claves

• Rotación de claves API encontrados en el vertedero, asume que están comprometidos.
• Invalidar las "URL privadas" de larga duración a imágenes KYC; mueva esos activos detrás de URL firmadas de corta duración con ACL estricta (por ejemplo, URL S3 prefirmadas con caducidad a escala de minutos, límites de IP y auditoría).
• Refuerce las API administrativas internas que las claves filtradas podrían golpear: por ejemplo, requerir TLS mutuo, listas de IP permitidas, postura del dispositivo.

Restablecimiento de 2FA / MFA a escala

• Tratar todas las semillas TOTP expuestas como quemadas. Forzar la reinscripción de las cuentas afectadas.
• Requiere una nueva configuración 2FA con nuevas semillas que nunca se almacenan en texto plano.
• Para las cuentas de alto riesgo (por ejemplo, saldos elevados), añada temporalmente una verificación escalonada para las retiradas y los cambios de contraseña. Los equipos de seguridad e incluso los reguladores fomentan la "fricción adaptativa" posterior a la violación en operaciones de alto valor.(CCN.com)

Tratamiento de datos KYC

• Trasladar los documentos KYC a un almacenamiento cifrado con un estricto control de acceso y tokens de recuperación de corta duración, no enlaces públicos permanentes.
• Añadir el registro de acceso en la capa de objetos (quién vio el pasaporte X en el momento Y).
• Minimice la retención: el GDPR exige la minimización de los datos y la limitación de su finalidad. Si no necesita escanear su pasaporte para siempre, no lo conserve para siempre.GDPR)

Disciplina forense + respuesta a incidentes

• Toma una instantánea de la BD expuesta como prueba.
• Capture los registros de acceso antes y después del desmantelamiento para reconstruir la cronología.
• Inicie el flujo de trabajo de notificación de infracciones:
  • notifíquelo a la autoridad de protección de datos en un plazo de 72 horas desde que tenga conocimiento de ello, a menos que pueda demostrar que el riesgo es bajo;
  • notificar a los usuarios afectados "sin demora indebida" si existe un riesgo elevado para ellos (robo de identidad, apropiación de cuenta, etc.).GDPR)
• Documente toda la cadena de custodia. Tanto el GDPR como la mayoría de las ciberseguradoras esperan que conserves las pruebas y los pasos de reparación.(Perkins Coie)

A continuación se muestra un cronograma simplificado de reparación que se ejecutaría en las primeras 48 horas tras el descubrimiento:

Reguladores como la DPA de la UE y la ICO del Reino Unido señalan explícitamente que, por lo general, la notificación de infracciones a las autoridades debe realizarse en un plazo de 72 horas desde que se tiene conocimiento de ellas, y que también hay que estar preparado para notificar a las personas afectadas si existe un "alto riesgo" para ellas(GDPR)

Mapeo de cumplimiento: GDPR, SOC 2 / SOC 3 y expectativas específicas de criptografía

GDPR / Protección de datos al estilo de la UE

En virtud de los artículos 33 y 34 del GDPR, si sufre una violación de datos personales que ponga en riesgo los derechos y libertades de las personas, debe:

1. notificarlo a la autoridad de control en un plazo de 72 horas a partir del momento en que tenga conocimiento de ello, y
2. informar a los usuarios afectados "sin demora indebida", describiendo lo que ha quedado al descubierto y lo que se está haciendo al respecto.(GDPR)

Para las criptomonedas, la filtración de documentos KYC + de identidad + metadatos de inicio de sesión + semillas 2FA es absolutamente de "alto riesgo" para las personas. Permite el fraude de identidad, la pérdida financiera y la ingeniería social; los reguladores no aceptarán el silencio.

Controles de estilo SOC 2 / SOC 3

En el lenguaje SOC 2 / SOC 3 (seguridad, disponibilidad, confidencialidad), una base de datos de producción abierta y sin autenticar es una violación directa del control de acceso, la seguridad de la red y las expectativas de gestión de cambios. No se puede pasar una auditoría SOC madura si "los datos personales y secretos de clientes críticos están en una IP pública sin autenticar".

Notificación de violaciones y confianza en las criptomonedas

Las bolsas de criptomonedas se encuentran en una zona extraña: algunas no son bancos con licencia completa, pero siguen manejando dinero de clientes, pasaportes y datos AML/KYC. Es decir:

• Se le juzga como a un depositario de tecnología financiera (proteger los saldos de los clientes, prevenir el fraude) y como a un responsable del tratamiento de datos (proteger los datos personales, notificar las violaciones)".Análisis diario de seguridad)
• Si no notifica, no sólo se arriesga a multas. Te arriesgas a un daño permanente de la marca dentro de las comunidades de criptomonedas, que ya están paranoicas después de años de hackeos de intercambios y tirones de alfombras.(CCN.com)

Cómo detectar fallos "NCX-Class" antes de que lo haga Internet (Penligent View)

Seamos francos: "MongoDB público sin autenticación que expone más de 5 millones de registros" es el tipo de cosa que un bucle de pruebas ofensivo decente debería detectar mucho antes que los periodistas(Análisis diario de seguridad)

Penligent (https://penligent.ai/) lo enfoca como una prueba de adversarios continua y automatizada, básicamente un equipo rojo siempre activo. Así es como funciona:

Cartografía de activos y control de la exposición

Los agentes de Penligent mapean continuamente la superficie de ataque externa (rangos de IP en la nube, subdominios, servicios filtrados) y marcan los almacenes de datos orientados a Internet como MongoDB no autenticado, Redis, Elasticsearch, cubos de almacenamiento de objetos, etc. Esta es exactamente la clase de error de configuración que llevó a la exposición de NCX.(Análisis diario de seguridad)

Simulación de descubrimiento de datos sensibles / claves

Dentro del ámbito autorizado, Penligent intenta identificar "joyas de la corona" de alto valor en servicios expuestos:

• Semillas 2FA/TOTP
• Claves API y tokens de servicio
• Enlaces o buckets de documentos KYC
• Cartera / metadatos de retirada

A continuación, la plataforma construye una ruta de explotación ("con esta semilla podemos generar códigos MFA", "con esta clave podemos acceder a la API de administración interna"), que es lo que harían los atacantes reales, pero lo hace en un entorno controlado en lugar de secuestrar realmente las cuentas. Esto crea una narrativa de riesgo respaldada por pruebas que los equipos de seguridad pueden llevar a la dirección.

Pruebas de AMF y vías de retirada

Penligent puede simular la toma de control condicional de una cuenta: "Si un atacante robara esta semilla, ¿podría iniciar sesión? ¿Podrían retirarse sin revisión manual? ¿Podrían restablecer el correo electrónico? Así se obtiene una lista ordenada de soluciones en lugar de una espiral de pánico.

Informes de conformidad

Por último, Penligent relaciona los hallazgos con las obligaciones de infracción de 72 horas del GDPR, los fallos de control SOC 2 / SOC 3 y el riesgo de custodia de criptomonedas. Esto es importante porque no basta con solucionar el fallo, sino que hay que demostrar que se disponía de un proceso, que se tomaron medidas y que se puede informar a los reguladores.(GDPR)

En la práctica, esa es la diferencia entre "no teníamos ni idea de que nuestra base de datos era pública durante meses" y "tenemos un descubrimiento continuo, lo detectamos, lo contuvimos, aquí está el registro".

Preguntas frecuentes (para seguridad, GRC e ingeniería)

Q1. ¿Cuál es la configuración errónea más común de MongoDB que conduce a infracciones como NCX?

MongoDB públicamente enrutable sin autenticación y sin ACL de red. A menudo las instancias dev/test son promovidas a "prod temporal" y nunca son bloqueadas. CISA/NIST han advertido durante años que las bases de datos expuestas sin autenticación son una causa recurrente de fugas a gran escala.(Comisión Europea)

Q2. Si se filtra una semilla 2FA/TOTP, ¿puede un atacante iniciar sesión como yo?

Sí, si el atacante también tiene tu nombre de usuario/email y tu contraseña o un hash crackeado. Con la semilla, pueden generar códigos válidos de 6 dígitos sin fin. Es por eso que la orientación posterior a la brecha siempre dice: restablecer MFA, no sólo la contraseña.(Análisis diario de seguridad)

Q3. ¿Cómo deben almacenarse las imágenes de CSC y los documentos de identidad escaneados?

Deben estar encriptados, ser de acceso controlado y recuperables sólo a través de URL firmadas de corta duración vinculadas a una sesión autenticada, no enlaces estáticos que vivan para siempre. Cada acceso debe quedar registrado. El GDPR también espera una "minimización de datos": no acumule más datos personales de los que necesita.(GDPR)

Q4. ¿Con qué rapidez tenemos que notificarlo legalmente a los reguladores y a los usuarios?

Con arreglo a los regímenes similares al RGPD, por lo general debe notificar a la autoridad pertinente en un plazo de 72 horas a partir del momento en que tenga conocimiento de una infracción que ponga en peligro a las personas, y debe informar a los usuarios afectados "sin demora indebida" si el riesgo para ellos es elevado.(GDPR)

Conclusión

"MongoDB mal configurado" suena a error de novato. En criptografía, es existencial.
Cuando se filtran más de 5 millones de registros de usuarios con identificadores KYC, contraseñas con hash, registros IP, monederos e incluso semillas TOTP, no sólo se filtran correos electrónicos, sino identidad, liquidez y confianza".Análisis diario de seguridad)

Desde el punto de vista del equipo rojo, este es un camino de toma de poder casi automático.
Desde el punto de vista del cumplimiento, es un reloj reglamentario que no se puede parar".GDPR)

Esta es la razón por la que las pruebas ofensivas continuas, automatizadas y basadas en pruebas (descubrimiento de activos → simulación de exploits → mapeo de cumplimiento) se están convirtiendo rápidamente en obligatorias para cualquier plataforma de criptomonedas que almacene KYC y mantenga fondos de usuarios. Y si eres un usuario en un intercambio que tuvo una brecha como esta? Cambie las contraseñas, rote 2FA, asuma que el phishing dirigido está llegando y considere seriamente irse.(CCN.com)