Diferencia entre revisiones de «Filtración de Condé Nast»

De CiberWiki
VisualWikitexto
Sin resumen de edición
Sin resumen de edición
 
(No se muestran 3 ediciones intermedias del mismo usuario)
Línea 1: Línea 1:
= Filtración de Condé Nast =
= Condé Nast: Filtración y Venta de 32,8 Millones de Registros de Usuarios (2025-2026) =


La '''Filtración de Condé Nast''' es un incidente de seguridad que involucra la exposición y venta de datos personales de aproximadamente '''32,8 millones de usuarios''' de las publicaciones de Condé Nast, incluyendo '''Vogue, The New Yorker, GQ, Glamour, WIRED y Vanity Fair''', entre otras.
== Nombres Alternativos / Aliases ==


El incidente salió a la luz pública en diciembre de 2025, cuando un actor de amenazas conocido como '''"Lovely"''' filtró un subconjunto de datos correspondientes a WIRED (2,3 millones de registros). Posteriormente, en septiembre de 2026, se puso a la venta la base de datos completa (32,8 millones de registros) en un foro de ciberdelincuencia en ruso por 15.000 dólares, revelando que la filtración original era mucho más grande de lo que se creía.
* Condé Nast Data Breach (Por el impacto)
* WIRED Leak (Por la publicación inicial afectada)
* Condé Nast Database Sale (Por la venta posterior)
* Lovely Leak (Por el alias del presunto atacante)
* Condé Nast 33M Records Incident (Por el volumen de datos)


== Cronología del incidente ==
== Fecha de Detección / Actividad ==


=== Ataque y extracción de datos (Septiembre - Octubre 2025) ===
{| class="wikitable"
* Según el análisis de las fechas de creación de cuentas en la muestra, los datos fueron extraídos entre '''septiembre y finales de octubre de 2025'''.
! Fecha !! Evento
* La extracción duró varias semanas, capturando nuevas cuentas a medida que se creaban, y se detuvo en los últimos días de octubre de 2025.
|-
* Las cuentas en la muestra fueron registradas entre el '''9 de febrero de 1999''' y el '''23 de octubre de 2025''', lo que refleja la antigüedad de la base de datos de usuarios.
| Septiembre - 23 octubre 2025 || Extracción de datos (según evidencia de la muestra)
|-
| 8-9 septiembre 2025 || Último registro en el archivo de WIRED (fecha de corte)
|-
| 22 noviembre 2025 || "Lovely" contacta a DataBreaches.net haciéndose pasar por investigador
|-
| 20 diciembre 2025 || Filtración pública del subconjunto de WIRED (2.366.576 registros)
|-
| 7 septiembre 2026 || Puesta a la venta de la base de datos completa (32.815.767 registros) en foro ruso
|-
| 7 septiembre 2026 || Análisis de Ransomnews verifica autenticidad de la muestra
|-
| 7 septiembre 2026 || Artículo de Pierluigi Paganini (Security Affairs)
|-
| 7 septiembre 2026 || Artículo de Ransomnews Research Team
|-
| 7 septiembre 2026 || Artículo de BleepingComputer (referencia al informe de WIRED)
|-
| 8 septiembre 2026 || Artículo de Sergiu Gatlan (BleepingComputer) sobre F5 (contexto)
|}


=== Filtración inicial de WIRED (Diciembre 2025) ===
'''Estado''': Activo. La base de datos completa está a la venta. Condé Nast no ha confirmado públicamente la brecha.
* El '''20 de diciembre de 2025''', el actor "Lovely" publicó un dataset de '''2.366.576 registros''' de suscriptores de WIRED en foros de hacking como BreachForums y Breach Stars.
* Antes de la filtración, "Lovely" contactó a DataBreaches.net en noviembre de 2025, haciéndose pasar por un investigador llamado "Dissent Doe", afirmando haber encontrado seis vulnerabilidades en el sistema de cuentas de Condé Nast.
* Ante la falta de respuesta de Condé Nast, el actor liberó los datos de WIRED como un "regalo de Navidad" (''Christmas Lump of Coal'').
* El conjunto de datos incluía aproximadamente:
    * 2,3 millones de direcciones de correo electrónico.
    * 285.936 nombres de suscriptores.
    * 102.479 direcciones físicas.
    * 32.426 números de teléfono.
* Los registros estaban en formato JSON e incluían IDs de usuario, fechas de creación (2011-2022) y marcas de tiempo de actividad hasta el 8 de septiembre de 2025.


=== Venta de la base de datos completa (Septiembre 2026) ===
== Actor de Amenaza (Atribución) ==
* El '''7 de septiembre de 2026''', una cuenta anónima en un foro de hackers en ruso puso a la venta una base de datos con '''32.815.767 registros''' de usuarios de Condé Nast por '''15.000 dólares'''.
* El vendedor afirmaba ser el responsable de la filtración de WIRED y ofrecía una versión sin los registros de WIRED que contenía '''30.455.594 líneas'''.
* La aritmética del vendedor es verificable: 32.815.767 - 30.455.594 = 2.360.173 registros de WIRED, una cifra que coincide con el archivo filtrado de WIRED (2.366.576 registros) con una precisión del '''0,27%'''.


== Datos expuestos ==
{| class="wikitable"
! Categoría !! Descripción
|-
| '''Nombre del Actor''' || "Lovely" (presunto, según el vendedor)
|-
| '''Vínculo Gubernamental''' || No establecido
|-
| '''Tipo de Actor''' || Ciberdelincuencia / Venta de datos / Posible ransomware
|-
| '''Sofisticación''' || MEDIA-ALTA. Utilizan:
* Explotación de vulnerabilidades IDOR y broken access control
* Enumeración de IDs secuenciales para extraer datos masivamente
* Capacidad de retener datos durante meses antes de venderlos
* Uso de foros de ciberdelincuencia en ruso con depósito en garantía
|-
| '''Motivación''' || Financiera (venta de datos a compradores de phishing, fraude, etc.)
|-
| '''Objetivo''' || 32,8 millones de registros de usuarios de Condé Nast
|-
| '''Precio de venta''' || $15.000 USD (menos de $0,0005 por registro)
|}


La base de datos incluye 14 campos por registro, aunque no todos los registros contienen toda la información:
== Resumen Ejecutivo ==


| Campo | Porcentaje de registros |
En septiembre de 2026, una base de datos con '''32.815.767 registros de usuarios de Condé Nast''' fue puesta a la venta en un foro de ciberdelincuencia en ruso por '''$15.000 USD'''. El vendedor afirmaba ser el responsable de la filtración de WIRED de diciembre de 2025 (bajo el alias "Lovely") y ofrecía una versión sin los registros de WIRED que contenía 30.455.594 líneas.
|-------|------------------------|
| Dirección de correo electrónico | 100% |
| Nombre y apellido | 31,6% |
| Dirección postal | 22,3% |
| Género | 17,5% |
| Fecha de nacimiento | 12,6% |
| Número de teléfono | 2,9% |


=== Datos NO expuestos ===
Ransomnews analizó una muestra de 5.000 filas y concluyó que los datos son '''auténticos''', basándose en pruebas de coherencia interna (tasas de llenado de campos, correlación nombre-email, fechas de proveedores, coherencia geográfica).
* '''No contiene contraseñas''' ni hashes de contraseñas.
* '''No contiene nombres de usuario''' para mostrar.
* '''No contiene datos de pago''' (tarjetas de crédito, etc.).


=== Análisis de la muestra ===
=== Hechos confirmados ===


Ransomnews analizó una muestra de 5.000 filas del vendedor y concluyó que los datos son auténticos basándose en varias pruebas de coherencia interna:
{| class="wikitable"
! Hecho !! Estado
|-
| Datos de 32,8 millones de usuarios a la venta || ✅ Confirmado (análisis de muestra)
|-
| Muestra de 5.000 filas verificada como auténtica || ✅ Confirmado (Ransomnews)
|-
| Subconjunto de WIRED (2,3M registros) filtrado en diciembre 2025 || ✅ Confirmado (BleepingComputer)
|-
| Vendedor afirma ser "Lovely" || ⚠️ No verificado independientemente
|-
| Condé Nast ha confirmado la brecha || ❌ No (silencio corporativo)
|-
| Contraseñas o datos de pago expuestos || ❌ No (según el esquema de la muestra)
|-
| Sistema de cuentas de Condé Nast comprometido || ✅ Probable (según evidencia de fechas)
|}


* '''Tasas de llenado de campos''': Coinciden con los totales del vendedor con una diferencia de solo 1,2 puntos porcentuales.
=== Línea de tiempo del incidente (UTC) ===
* '''Nombres y correos electrónicos''': El 61,9% de las filas con nombre completo incluyen ese nombre o sus iniciales en la dirección de correo electrónico. Al mezclar los nombres aleatoriamente, la tasa de coincidencia cae al 0,3%.
* '''Fechas de proveedores de correo''': Ninguna de las 227 cuentas de Apple Relay, iCloud, Outlook, Me.com o Proton fue creada antes del lanzamiento de su proveedor.
* '''Geografía''': El 96,4% de los códigos postales de EE.UU. coinciden con el estado indicado, y el 93,5% con la ciudad indicada.
* '''Errores humanos''': La muestra contiene errores típicos de formularios web rellenados por personas a lo largo de décadas (ej: "Seleccione su estado" como valor literal, índices de menús desplegables, nombres en minúsculas, fechas de nacimiento el 1 de enero).


=== Distribución demográfica ===
{| class="wikitable"
* El '''77% de los registros con género declarado son femeninos''' (633 F, 186 M), lo que se ajusta a publicaciones como Vogue, Glamour y Allure, y no a WIRED.
! Fecha y hora !! Evento
* Gmail representa el 45% de las direcciones, Yahoo el 13%, Hotmail el 8%, AOL el 4%, con una larga cola de 772 dominios.
|-
| Septiembre 2025 || Comienza la extracción de datos (cuentas nuevas aparecen parcialmente)
|-
| 8-9 septiembre 2025 || Último registro en el archivo de WIRED (fecha de corte)
|-
| 23 octubre 2025 || Último registro en la muestra (fin de la extracción)
|-
| 22 noviembre 2025 || "Lovely" contacta a DataBreaches.net como "Dissent Doe"
|-
| 20 diciembre 2025 || Filtración pública del archivo de WIRED (2.366.576 registros)
|-
| 7 septiembre 2026 || Base de datos completa a la venta en foro ruso ($15.000)
|-
| 7 septiembre 2026 || Ransomnews publica análisis de verificación
|-
| 7 septiembre 2026 || Security Affairs publica artículo de Pierluigi Paganini
|}


== Vector de ataque ==
=== Declaración oficial de Condé Nast ===


Según los análisis de seguridad, el incidente se produjo por:
'''Condé Nast no ha emitido ninguna declaración pública sobre esta filtración.''' No respondió a las preguntas de SecurityWeek en diciembre de 2025. La única información pública provino de Ars Technica (propiedad de Condé Nast), que afirmó que su propio sistema independiente no se vio afectado.


=== Vulnerabilidades IDOR (Insecure Direct Object Reference) ===
== Vector de Ataque / Métodos de Distribución ==
* El sistema de cuentas de Condé Nast utilizaba '''identificadores secuenciales predecibles''' para los perfiles de usuario.
* Los atacantes podían iterar a través de estos IDs y consultar las APIs subyacentes para recuperar registros de suscriptores a gran escala.
* El backend no verificaba correctamente si el solicitante tenía autorización para acceder a cada perfil.


=== Controles de acceso rotos (Broken Access Control) ===
=== Mecanismo técnico del ataque ===
* Ciertos endpoints de gestión de cuentas carecían de suficientes salvaguardas de autenticación y autorización.
* Esto permitía a usuarios no autenticados no solo ver datos sensibles, sino también '''modificar atributos del perfil''', como direcciones de correo electrónico y contraseñas.


=== Falta de respuesta a la divulgación responsable ===
{| class="wikitable"
* El actor "Lovely" afirmó haber contactado a Condé Nast en múltiples ocasiones para reportar las vulnerabilidades, sin obtener respuesta.
! Fase !! Descripción
* Esta falta de comunicación llevó a la filtración pública como forma de presión.
|-
| 1. Reconocimiento || Identificación de endpoints de API de Condé Nast con IDs secuenciales predecibles
|-
| 2. Explotación IDOR || Iteración a través de IDs de cuenta para acceder a perfiles de otros usuarios
|-
| 3. Extracción masiva || Descarga automatizada de registros de usuarios a gran escala
|-
| 4. Almacenamiento || Retención de los datos durante meses (septiembre-octubre 2025)
|-
| 5. Filtración selectiva || Publicación de un subconjunto (WIRED) para demostrar autenticidad
|-
| 6. Venta privada || Venta de la base de datos completa en foro de ciberdelincuencia
|}


== Impacto y riesgos ==
=== Por qué fue posible ===


Aunque la base de datos no contiene contraseñas ni datos de pago, la exposición de información personal identificable (PII) plantea riesgos significativos:
{| class="wikitable"
! Factor !! Explicación
|-
| IDs secuenciales predecibles || Los identificadores de cuenta permitían enumeración masiva
|-
| Falta de autorización a nivel de objeto || El backend no verificaba si el solicitante tenía permiso para acceder a cada perfil
|-
| Controles de acceso rotos || Endpoints de gestión de cuentas sin autenticación suficiente
|-
| Falta de rate limiting || No había límites en el número de consultas a la API
|-
| Sin detección de scraping || No se identificó la extracción masiva de datos
|}


* '''Phishing dirigido''': La combinación de nombre real, dirección postal y la revista a la que está suscrito permite crear avisos de renovación, problemas de facturación u ofertas de regalo muy convincentes.
=== Lo que Condé Nast NO ha explicado ===
* '''Fraude postal''': Una quinta parte de los registros incluye dirección postal completa, lo que facilita el envío de cartas fraudulentas que parecen legítimas.
* '''Ingeniería social''': Los atacantes pueden usar los datos para manipular a las víctimas con información personalizada.
* '''Correlación con otras filtraciones''': Los datos pueden combinarse con otras brechas para obtener un perfil más completo de la víctima.
* '''Doxing y swatting''': La exposición de direcciones físicas aumenta el riesgo de acoso o ataques dirigidos.


== Respuesta de Condé Nast ==
* Cómo los atacantes obtuvieron acceso inicial al sistema de cuentas.
* Por qué las vulnerabilidades IDOR no fueron detectadas antes.
* Qué medidas específicas se han tomado para mitigar futuros incidentes.
* Si se notificó a los 30,5 millones de afectados fuera de WIRED.
* Si los atacantes contactaron a Condé Nast para exigir rescate.


* Condé Nast '''no ha confirmado públicamente la filtración''' ni ha comentado sobre la venta de la base de datos.
== Técnicas, Tácticas y Procedimientos (TTPs) - MITRE ATT&CK ==
* No respondió a las preguntas de SecurityWeek en diciembre de 2025.
* La única información pública provino de Ars Technica (propiedad de Condé Nast), que afirmó que su propio sistema independiente no se vio afectado.
* Los 2,3 millones de registros de WIRED fueron agregados a '''Have I Been Pwned''', pero los otros 30,5 millones de afectados no han recibido notificación equivalente.


== Señales de compromiso (IOCs) ==
{| class="wikitable"
! Táctica (MITRE ATT&CK) !! Técnica / Subtécnica !! Descripción / Implementación
|-
| Initial Access (TA0001) || Exploit Public-Facing Application (T1190) || Explotación de vulnerabilidades IDOR en APIs de cuentas
|-
| Initial Access (TA0001) || Valid Accounts (T1078) || Uso de cuentas existentes para acceso no autorizado
|-
| Discovery (TA0007) || Account Discovery (T1087) || Enumeración de IDs de cuenta para identificar objetivos
|-
| Collection (TA0009) || Data from Information Repositories (T1213) || Extracción de datos de usuarios desde APIs
|-
| Collection (TA0009) || Data from Local System (T1005) || Almacenamiento de datos extraídos en sistemas locales
|-
| Exfiltration (TA0010) || Exfiltration Over Web Service (T1567) || Transferencia de datos a servidores externos
|-
| Impact (TA0040) || Data Manipulation (T1565) || Potencial uso de datos para phishing y fraude
|}


| Tipo | Valor |
== Flujo de Ataque (Cyber Kill Chain) ==
|------|-------|
| **Foro** | Foro de ciberdelincuencia en ruso (nombre no especificado) |
| **Alias del vendedor** | Lovely (presunto) |
| **Precio de venta** | $15.000 USD |
| **Registros en venta** | 32.815.767 |
| **Registros sin WIRED** | 30.455.594 |
| **Registros de WIRED** | ~2.360.173 |


== Mitigaciones y recomendaciones ==
{| class="wikitable"
! Fase !! Descripción
|-
| 1. Reconocimiento || Identificación de endpoints de API de Condé Nast y estructura de IDs
|-
| 2. Armamento || Desarrollo de scripts de enumeración y extracción automatizada
|-
| 3. Entrega || Acceso a las APIs a través de peticiones HTTP directas
|-
| 4. Explotación || Iteración de IDs para recuperar registros de usuarios no autorizados
|-
| 5. Instalación || Almacenamiento de los datos extraídos en servidores controlados
|-
| 6. Comando y Control || No aplica (ataque de extracción directa, no persistente)
|-
| 7. Acción sobre Objetivos || Filtración de subconjunto WIRED (diciembre 2025); Venta de base de datos completa (septiembre 2026); Potencial uso para phishing, fraude y correlación de datos
|}


=== Para usuarios afectados ===
== Infraestructura Utilizada ==


* '''Desconfiar de correos de suscripción''': Los atacantes pueden usar los datos para enviar avisos de renovación, problemas de facturación u ofertas de regalo convincentes.
{| class="wikitable"
* '''Acceder directamente a los sitios web''': En lugar de usar enlaces de correos electrónicos, acceder directamente al sitio web de la editorial a través de una dirección conocida.
! Tipo !! Característica !! Propósito
* '''Tratar el correo físico con sospecha''': Las cartas fraudulentas que mencionan el título de una revista o una suscripción real no garantizan su autenticidad.
|-
* '''Verificar la dirección de correo''': Si la dirección expuesta se reutiliza en otros servicios, esa reutilización constituye una exposición.
| Scripts de enumeración || Automatización de peticiones HTTP || Extracción masiva de datos
* '''Usar gestores de contraseñas y MFA''': Aunque no se expusieron contraseñas, es buena práctica usar contraseñas únicas y autenticación multifactor.
|-
* '''Monitorear intentos de phishing''': Estar atento a mensajes inesperados sobre renovaciones, problemas de facturación o verificaciones de cuenta.
| Proxies / VPN || Múltiples IPs para evadir detección || Distribución de consultas
|-
| Servidores de almacenamiento || Infraestructura para retener datos || Almacenamiento de 32,8M de registros
|-
| Foro de ciberdelincuencia || Foro ruso con depósito en garantía || Venta de la base de datos
|}


=== Para organizaciones ===
== Detalle Técnico - Vulnerabilidad IDOR y Broken Access Control ==


* '''Auditar y aplicar autorización a nivel de objeto''': En todas las APIs de cuentas y perfiles para prevenir vulnerabilidades IDOR.
=== ¿Qué es IDOR? ===
* '''Implementar limitación de velocidad y throttling''': Para detectar y bloquear actividad de enumeración y scraping a gran escala.
* '''Reemplazar identificadores secuenciales''': Con IDs de objeto no adivinables para reducir la superficie de ataque.
* '''Requerir MFA''': Para inicios de sesión y acciones sensibles de cuenta (cambios de correo, restablecimientos de contraseña).
* '''Mejorar el monitoreo y logging''': Para identificar patrones de acceso anómalos en servicios de identidad.
* '''Establecer canales claros para divulgación de vulnerabilidades''': Para evitar que los investigadores recurran a la filtración pública.


== Relación con otros conceptos ==
'''IDOR (Insecure Direct Object Reference)''' es una vulnerabilidad de control de acceso que ocurre cuando una aplicación utiliza identificadores de objetos predecibles (como IDs numéricos secuenciales) para acceder a recursos, pero no verifica si el usuario tiene autorización para acceder a ellos.


* '''[[Ciberdelincuentes]]''': El actor "Lovely" es el presunto responsable de la filtración y venta.
=== Vulnerabilidad explotada ===
* '''[[Ingeniería Social]]''': Los datos expuestos facilitan ataques de phishing dirigido.
* '''[[Filtración de datos]]''': Incidente de exposición masiva de información personal.
* '''[[IDOR]]''': Vulnerabilidad de referencia directa a objetos insegura que permitió el acceso no autorizado.
* '''[[Control de acceso]]''': Fallos en los controles de acceso permitieron la extracción masiva de datos.
* '''[[GDPR]]''': La filtración podría conllevar sanciones bajo regulaciones de protección de datos.


== Véase también ==
{| class="wikitable"
! Componente !! Problema
|-
| IDs secuenciales || Los IDs de cuenta eran predecibles (1, 2, 3, ...)
|-
| Falta de autorización || El backend no verificaba si el solicitante tenía permiso
|-
| Endpoints sin autenticación || Algunos endpoints permitían acceso sin autenticación
|-
| Sin rate limiting || No había límites en el número de consultas
|-
| Sin detección de scraping || No se identificó la extracción masiva
|}


* [[Ciberdelincuentes]]
=== Cálculo de factibilidad ===
* [[Ingeniería Social]]
* [[Filtración de datos]]
* [[IDOR]]
* [[Control de acceso]]
* [[GDPR]]
* [[WIRED]]
* [[Condé Nast]]


----
{| class="wikitable"
! Parámetro !! Valor
|-
| IDs de cuenta || Secuenciales y predecibles
|-
| Velocidad de extracción || Miles de registros por hora
|-
| Tiempo para extraer 32,8M || Días o semanas (según la muestra)
|-
| Detección || Nula (no había monitoreo de scraping)
|-
| Probabilidad de éxito || ALTA (sin controles de acceso efectivos)
|}
 
=== Nota sobre el impacto ===
 
Los atacantes no necesitaban explotar vulnerabilidades complejas. La combinación de IDs secuenciales y falta de autorización a nivel de objeto permitió la extracción masiva de datos sin ser detectados durante semanas.
 
== Datos Expuestos ==
 
{| class="wikitable"
! Campo !! Porcentaje de registros
|-
| Dirección de correo electrónico || 100%
|-
| Nombre y apellido || 31,6%
|-
| Dirección postal || 22,3%
|-
| Género || 17,5%
|-
| Fecha de nacimiento || 12,6%
|-
| Número de teléfono || 2,9%
|}
 
'''Datos NO expuestos:'''
 
* No contiene contraseñas ni hashes.
* No contiene nombres de usuario para mostrar.
* No contiene datos de pago.
 
== Víctimas y Sectores Afectados ==
 
{| class="wikitable"
! Categoría !! Datos
|-
| Número de registros || 32.815.767
|-
| Número de afectados || 32,8 millones de usuarios
|-
| Publicaciones afectadas || Vogue, The New Yorker, GQ, Glamour, WIRED, Vanity Fair, Allure, Bon Appétit, y otras
|-
| Tipo de clientes || Suscriptores de revistas, usuarios registrados
|-
| Sectores potencialmente afectados || Medios de comunicación, publicación, consumo
|-
| Geografía || Global (con mayoría en EE.UU., 82% de los registros)
|-
| Subconjunto de WIRED || 2.366.576 registros (filtrados en diciembre 2025)
|-
| Registros no-WIRED || 30.455.594 (no públicos hasta septiembre 2026)
|}
 
=== Notificación a clientes ===
 
* WIRED notificó a los afectados por su filtración (2,3M) y los agregó a Have I Been Pwned.
* Los otros 30,5 millones de afectados '''no han recibido notificación''' equivalente.
* Condé Nast no ha emitido declaración pública.
 
== Impacto y Riesgo ==
 
{| class="wikitable"
! Categoría !! Nivel !! Descripción
|-
| Impacto inmediato || MEDIO-ALTO || 32,8M de registros a la venta
|-
| Riesgo de phishing || ALTO || Datos suficientes para correos dirigidos convincentes
|-
| Riesgo de fraude postal || MEDIO || 22,3% de registros con dirección postal
|-
| Impacto reputacional (Condé Nast) || ALTO || Silencio corporativo y falta de transparencia
|-
| Riesgo sistémico || MEDIO || Base de datos de usuarios de medios de comunicación
|-
| Probabilidad de reincidencia || MEDIA || Si no se corrigen las vulnerabilidades IDOR
|}
 
=== Comparativa con otros incidentes de filtración de datos ===
 
{| class="wikitable"
! Incidente !! Año !! Impacto !! Lección clave
|-
| LastPass || 2022 || Bóvedas encriptadas de 25M+ usuarios robadas || Las bóvedas offline pueden ser descifradas con el tiempo
|-
| Passwordstate || 2021 || Actualización de software comprometida (malware) || Los mecanismos de actualización son vectores críticos
|-
| Dashlane || 2026 || ~20 bóvedas robadas por fuerza bruta a 2FA || El 2FA no es invencible si no hay rate limiting
|-
| '''Condé Nast''' || '''2025-2026''' || '''32,8M de registros de usuarios a la venta''' || '''Las vulnerabilidades IDOR permiten extracción masiva sin detección'''
|}
 
=== Lecciones del incidente LastPass (2022) ===
 
El informe de TechCrunch señala que, tras la brecha de LastPass en 2022:
 
* "Los requisitos de contraseña para los primeros clientes eran mucho más débiles que el estándar posterior, lo que permitió a los hackers descifrar fácilmente las contraseñas de las bóvedas de algunos clientes mediante ataques de fuerza bruta."
* "Se han reportado varios casos de hackers que robaron grandes cantidades de criptomonedas de los clientes, probablemente utilizando claves privadas almacenadas en bóvedas de LastPass robadas."
 
'''Aplicación a Condé Nast''': Aunque no se expusieron contraseñas, la combinación de nombre, dirección postal y publicación a la que está suscrito el usuario permite ataques de phishing altamente dirigidos.
 
== Recomendaciones de Mitigación ==
 
=== Para usuarios afectados (los 32,8M) ===
 
{| class="wikitable"
! Acción !! Urgencia !! Descripción
|-
| Desconfiar de correos de suscripción || ALTA || Avisos de renovación, problemas de facturación, ofertas de regalo
|-
| Acceder directamente a los sitios web || ALTA || En lugar de usar enlaces de correos electrónicos
|-
| Tratar el correo físico con sospecha || MEDIA || Cartas fraudulentas que mencionan la revista
|-
| Verificar la dirección de correo || MEDIA || Si se reutiliza en otros servicios, esa reutilización es la exposición
|-
| Usar gestores de contraseñas y MFA || MEDIA || Aunque no se expusieron contraseñas, es buena práctica
|-
| Monitorear intentos de phishing || ALTA || Estar atento a mensajes inesperados
|}
 
=== Para organizaciones (medidas post-incidente) ===
 
{| class="wikitable"
! Medida !! Estado según Condé Nast
|-
| Auditoría de APIs para IDOR || No especificado
|-
| Implementación de autorización a nivel de objeto || No especificado
|-
| Rate limiting en APIs de cuentas || No especificado
|-
| Reemplazo de IDs secuenciales || No especificado
|-
| Monitoreo de scraping || No especificado
|-
| Notificación a afectados fuera de WIRED || Pendiente
|-
| Transparencia total || Pendiente (silencio corporativo)
|}
 
=== Para la industria de medios y publicación ===
 
* Implementar autorización a nivel de objeto en todas las APIs de cuentas.
* Reemplazar IDs secuenciales con identificadores no adivinables (UUIDs).
* Implementar rate limiting agresivo en endpoints de cuentas.
* Monitorear patrones de acceso anómalos (scraping, enumeración).
* Establecer canales claros para divulgación de vulnerabilidades.
* Notificar a los afectados de forma transparente y oportuna.
 
=== Para usuarios en general (no solo Condé Nast) ===
 
{| class="wikitable"
! Recomendación !! Por qué
|-
| Usar frases de paso largas || 20+ caracteres son más seguras que contraseñas cortas
|-
| Habilitar 2FA en todas las cuentas críticas || Email, banca, criptomonedas, gestor de contraseñas
|-
| Preferir claves de seguridad físicas || YubiKey, Google Titan, passkeys
|-
| No reutilizar contraseñas || Una brecha en un sitio no compromete otros
|-
| Monitorear brechas de datos || Usar servicios como Have I Been Pwned
|}
 
== Herramientas de Detección ==
 
=== Para Condé Nast (post-incidente) ===
 
{| class="wikitable"
! Herramienta/Técnica !! Propósito
|-
| Rate limiting || Limitar consultas a APIs por IP/cuenta
|-
| Detección de scraping || Identificar patrones de enumeración masiva
|-
| Alertas en tiempo real || Notificar a usuarios y SOC sobre actividad anómala
|-
| WAF con reglas específicas || Bloquear tráfico automatizado sospechoso
|-
| Auditoría de APIs || Revisar endpoints para IDOR y broken access control
|}
 
=== Para usuarios (autodetección) ===
 
{| class="wikitable"
! Indicador !! Qué buscar
|-
| Correos de suscripción inesperados || Avisos de renovación, facturación, regalos
|-
| Correo postal fraudulento || Cartas que mencionan la revista
|-
| Actividad de inicio de sesión inusual || Horarios o ubicaciones anormales
|-
| Intentos de phishing || Mensajes que solicitan verificación de cuenta
|}
 
=== Servicios de monitoreo recomendados ===
 
{| class="wikitable"
! Servicio !! Propósito
|-
| Have I Been Pwned (HIBP) || Verificar si el correo apareció en brechas de datos
|-
| Monitor de crédito || Detectar actividad financiera no autorizada
|-
| Alertas de inicio de sesión || Configurar en cuentas críticas (email, banca, etc.)
|}
 
== Antecedentes: Incidentes en Gestores de Contraseñas y Medios ==
 
{| class="wikitable"
! Fecha !! Empresa !! Incidente !! Impacto
|-
| 2021 || Click Studios (Passwordstate) || Actualización de software comprometida con malware || Clientes afectados tuvieron que restablecer todas sus credenciales
|-
| 2022 || LastPass || Brecha masiva: bóvedas de 25M+ usuarios robadas || Descifrado de bóvedas con contraseñas débiles; robo de criptomonedas reportado
|-
| 2026 || Dashlane || Fuerza bruta a 2FA, ~20 bóvedas robadas || Riesgo de descifrado para clientes con contraseñas maestras débiles
|-
| '''2025-2026''' || '''Condé Nast''' || '''Filtración de 32,8M de registros de usuarios''' || '''Datos a la venta por $15.000; riesgo de phishing dirigido'''
|}
 
=== Patrón común ===
 
En los cuatro casos, el eslabón débil no fue el cifrado (AES-256 es seguro), sino:
 
* Contraseñas maestras débiles (LastPass, Dashlane)
* Mecanismos de autenticación mal implementados (Dashlane: falta de rate limiting en 2FA)
* Procesos de actualización comprometidos (Passwordstate)
* '''Vulnerabilidades de control de acceso (Condé Nast: IDOR y broken access control)'''
 
== Opiniones de Expertos ==
 
*"Este incidente demuestra un fallo fundamental en la implementación de controles de acceso por parte de Condé Nast. Una vulnerabilidad IDOR debería ser detectada en cualquier auditoría de seguridad básica. El hecho de que los atacantes pudieran extraer 32,8 millones de registros sin ser detectados durante semanas indica una falta grave de monitoreo y autorización a nivel de objeto. Es como tener una biblioteca con 32 millones de libros... y permitir que cualquiera los tome prestados sin carné."* — Fernando Vargas (CiberAnalyst)
 
*"Lo más preocupante no es la filtración en sí, sino la falta de transparencia de Condé Nast. No han explicado cómo los atacantes obtuvieron acceso, qué medidas específicas tomaron después, ni si los 30,5 millones de afectados fuera de WIRED han sido notificados. Los clientes merecen respuestas claras cuando se trata de su información personal."* — Fernando Vargas
 
*"Este incidente es un recordatorio de que las vulnerabilidades de control de acceso (como IDOR) siguen siendo una de las causas más comunes de filtraciones masivas de datos. La solución es simple en teoría: implementar autorización a nivel de objeto en todas las APIs, reemplazar IDs secuenciales con UUIDs y monitorear patrones de acceso anómalos. En la práctica, muchas organizaciones siguen fallando en esto."* — Fernando Vargas
 
== Referencias y Fuentes ==
 
* Ransomnews Research Team. (2026, 7 de septiembre). Condé Nast: 32,8 millones de registros de usuarios a la venta, muestra verificada.
* Paganini, P. (2026, 7 de septiembre). Tras la filtración de WIRED, Condé Nast ofrece a la venta datos de 32,8 millones de usuarios. Security Affairs.
* BleepingComputer. (2026, 7 de septiembre). Hacker claims to leak WIRED database with 2.3 million records.
* DataBreaches.net. (2025, noviembre-diciembre). Condé Nast gets hacked, and DataBreaches gets "played".
* SecurityWeek. (2025, diciembre). Hacker claims theft of 40 million Condé Nast records after WIRED data leak.
* Ars Technica. (2025, diciembre). Condé Nast user database reportedly breached, Ars unaffected.
* Have I Been Pwned. (2026). WIRED data breach entry.
 
== Historial de Revisiones ==
 
{| class="wikitable"
! Fecha !! Versión !! Autor !! Cambios Realizados
|-
| 2026-09-10 || 1.0 || Fernando Vargas Hincapié || Creación inicial basada en el informe de Ransomnews, Security Affairs y BleepingComputer
|}
 
== Indicadores de Compromiso (IOCs) ==
 
=== Para usuarios de Condé Nast ===
 
{| class="wikitable"
! Tipo de indicador !! Qué buscar !! Acción
|-
| Correos de suscripción inesperados || Avisos de renovación, facturación, regalos || Acceder directamente al sitio web
|-
| Correo postal fraudulento || Cartas que mencionan la revista || Desconfiar y verificar
|-
| Intentos de phishing || Mensajes que solicitan verificación de cuenta || No hacer clic en enlaces
|-
| Reutilización de correo electrónico || Si el correo expuesto se usa en otros servicios || Cambiar contraseñas en otros servicios
|}
 
=== Para Condé Nast (medidas post-incidente) ===
 
{| class="wikitable"
! Indicador de detección !! Implementación recomendada
|-
| Enumeración de IDs secuenciales || Detectar patrones de acceso secuencial → bloquear
|-
| Scraping de APIs || Detectar múltiples consultas desde la misma IP → bloquear
|-
| Acceso a perfiles no autorizados || Implementar autorización a nivel de objeto
|-
| Velocidad de consultas > 100/minuto || Claramente automatizado → bloquear IP/origen
|}
 
=== Servicios de monitoreo recomendados ===
 
{| class="wikitable"
! Servicio !! Propósito
|-
| Have I Been Pwned (HIBP) || Verificar si el correo apareció en brechas de datos
|-
| Monitor de crédito || Detectar actividad financiera no autorizada
|-
| Alertas de inicio de sesión || Configurar en cuentas críticas (email, banca, etc.)
|}
 
== Preguntas sin respuesta (según informe de Ransomnews) ==
 
{| class="wikitable"
! Pregunta !! Estado
|-
| ¿Cómo obtuvieron los atacantes acceso inicial al sistema de cuentas? || No respondido
|-
| ¿Por qué las vulnerabilidades IDOR no fueron detectadas antes? || No respondido
|-
| ¿Qué medidas específicas tomó Condé Nast para mitigar futuros incidentes? || No especificado
|-
| ¿Los clientes afectados fuera de WIRED han sido notificados? || No claro
|-
| ¿Los atacantes contactaron a Condé Nast para exigir rescate? || No respondido
|-
| ¿Condé Nast sabe quién está detrás del ataque? || No respondido
|-
| ¿Se ha confirmado que el vendedor es "Lovely"? || No verificado independientemente
|}
 
== Etiquetas / Categorías ==
 
condé nast data breach wired leak 32 million records idor vulnerability broken access control lovely ransomnews security affairs bleepingcomputer phishing credential exposure 2025 2026


''Esta página forma parte de la [[:Categoría:Familias de malware]] y
[[Categoría:CAMPAÑAS|CAMPAÑAS]]
[[Categoría:CAMPAÑAS|CAMPAÑAS]]

Revisión actual - 14:36 10 sep 2026

Condé Nast: Filtración y Venta de 32,8 Millones de Registros de Usuarios (2025-2026)

Nombres Alternativos / Aliases

  • Condé Nast Data Breach (Por el impacto)
  • WIRED Leak (Por la publicación inicial afectada)
  • Condé Nast Database Sale (Por la venta posterior)
  • Lovely Leak (Por el alias del presunto atacante)
  • Condé Nast 33M Records Incident (Por el volumen de datos)

Fecha de Detección / Actividad

Fecha Evento
Septiembre - 23 octubre 2025 Extracción de datos (según evidencia de la muestra)
8-9 septiembre 2025 Último registro en el archivo de WIRED (fecha de corte)
22 noviembre 2025 "Lovely" contacta a DataBreaches.net haciéndose pasar por investigador
20 diciembre 2025 Filtración pública del subconjunto de WIRED (2.366.576 registros)
7 septiembre 2026 Puesta a la venta de la base de datos completa (32.815.767 registros) en foro ruso
7 septiembre 2026 Análisis de Ransomnews verifica autenticidad de la muestra
7 septiembre 2026 Artículo de Pierluigi Paganini (Security Affairs)
7 septiembre 2026 Artículo de Ransomnews Research Team
7 septiembre 2026 Artículo de BleepingComputer (referencia al informe de WIRED)
8 septiembre 2026 Artículo de Sergiu Gatlan (BleepingComputer) sobre F5 (contexto)

Estado: Activo. La base de datos completa está a la venta. Condé Nast no ha confirmado públicamente la brecha.

Actor de Amenaza (Atribución)

Categoría Descripción
Nombre del Actor "Lovely" (presunto, según el vendedor)
Vínculo Gubernamental No establecido
Tipo de Actor Ciberdelincuencia / Venta de datos / Posible ransomware
Sofisticación MEDIA-ALTA. Utilizan:
  • Explotación de vulnerabilidades IDOR y broken access control
  • Enumeración de IDs secuenciales para extraer datos masivamente
  • Capacidad de retener datos durante meses antes de venderlos
  • Uso de foros de ciberdelincuencia en ruso con depósito en garantía
Motivación Financiera (venta de datos a compradores de phishing, fraude, etc.)
Objetivo 32,8 millones de registros de usuarios de Condé Nast
Precio de venta $15.000 USD (menos de $0,0005 por registro)

Resumen Ejecutivo

En septiembre de 2026, una base de datos con 32.815.767 registros de usuarios de Condé Nast fue puesta a la venta en un foro de ciberdelincuencia en ruso por $15.000 USD. El vendedor afirmaba ser el responsable de la filtración de WIRED de diciembre de 2025 (bajo el alias "Lovely") y ofrecía una versión sin los registros de WIRED que contenía 30.455.594 líneas.

Ransomnews analizó una muestra de 5.000 filas y concluyó que los datos son auténticos, basándose en pruebas de coherencia interna (tasas de llenado de campos, correlación nombre-email, fechas de proveedores, coherencia geográfica).

Hechos confirmados

Hecho Estado
Datos de 32,8 millones de usuarios a la venta ✅ Confirmado (análisis de muestra)
Muestra de 5.000 filas verificada como auténtica ✅ Confirmado (Ransomnews)
Subconjunto de WIRED (2,3M registros) filtrado en diciembre 2025 ✅ Confirmado (BleepingComputer)
Vendedor afirma ser "Lovely" ⚠️ No verificado independientemente
Condé Nast ha confirmado la brecha ❌ No (silencio corporativo)
Contraseñas o datos de pago expuestos ❌ No (según el esquema de la muestra)
Sistema de cuentas de Condé Nast comprometido ✅ Probable (según evidencia de fechas)

Línea de tiempo del incidente (UTC)

Fecha y hora Evento
Septiembre 2025 Comienza la extracción de datos (cuentas nuevas aparecen parcialmente)
8-9 septiembre 2025 Último registro en el archivo de WIRED (fecha de corte)
23 octubre 2025 Último registro en la muestra (fin de la extracción)
22 noviembre 2025 "Lovely" contacta a DataBreaches.net como "Dissent Doe"
20 diciembre 2025 Filtración pública del archivo de WIRED (2.366.576 registros)
7 septiembre 2026 Base de datos completa a la venta en foro ruso ($15.000)
7 septiembre 2026 Ransomnews publica análisis de verificación
7 septiembre 2026 Security Affairs publica artículo de Pierluigi Paganini

Declaración oficial de Condé Nast

Condé Nast no ha emitido ninguna declaración pública sobre esta filtración. No respondió a las preguntas de SecurityWeek en diciembre de 2025. La única información pública provino de Ars Technica (propiedad de Condé Nast), que afirmó que su propio sistema independiente no se vio afectado.

Vector de Ataque / Métodos de Distribución

Mecanismo técnico del ataque

Fase Descripción
1. Reconocimiento Identificación de endpoints de API de Condé Nast con IDs secuenciales predecibles
2. Explotación IDOR Iteración a través de IDs de cuenta para acceder a perfiles de otros usuarios
3. Extracción masiva Descarga automatizada de registros de usuarios a gran escala
4. Almacenamiento Retención de los datos durante meses (septiembre-octubre 2025)
5. Filtración selectiva Publicación de un subconjunto (WIRED) para demostrar autenticidad
6. Venta privada Venta de la base de datos completa en foro de ciberdelincuencia

Por qué fue posible

Factor Explicación
IDs secuenciales predecibles Los identificadores de cuenta permitían enumeración masiva
Falta de autorización a nivel de objeto El backend no verificaba si el solicitante tenía permiso para acceder a cada perfil
Controles de acceso rotos Endpoints de gestión de cuentas sin autenticación suficiente
Falta de rate limiting No había límites en el número de consultas a la API
Sin detección de scraping No se identificó la extracción masiva de datos

Lo que Condé Nast NO ha explicado

  • Cómo los atacantes obtuvieron acceso inicial al sistema de cuentas.
  • Por qué las vulnerabilidades IDOR no fueron detectadas antes.
  • Qué medidas específicas se han tomado para mitigar futuros incidentes.
  • Si se notificó a los 30,5 millones de afectados fuera de WIRED.
  • Si los atacantes contactaron a Condé Nast para exigir rescate.

Técnicas, Tácticas y Procedimientos (TTPs) - MITRE ATT&CK

Táctica (MITRE ATT&CK) Técnica / Subtécnica Descripción / Implementación
Initial Access (TA0001) Exploit Public-Facing Application (T1190) Explotación de vulnerabilidades IDOR en APIs de cuentas
Initial Access (TA0001) Valid Accounts (T1078) Uso de cuentas existentes para acceso no autorizado
Discovery (TA0007) Account Discovery (T1087) Enumeración de IDs de cuenta para identificar objetivos
Collection (TA0009) Data from Information Repositories (T1213) Extracción de datos de usuarios desde APIs
Collection (TA0009) Data from Local System (T1005) Almacenamiento de datos extraídos en sistemas locales
Exfiltration (TA0010) Exfiltration Over Web Service (T1567) Transferencia de datos a servidores externos
Impact (TA0040) Data Manipulation (T1565) Potencial uso de datos para phishing y fraude

Flujo de Ataque (Cyber Kill Chain)

Fase Descripción
1. Reconocimiento Identificación de endpoints de API de Condé Nast y estructura de IDs
2. Armamento Desarrollo de scripts de enumeración y extracción automatizada
3. Entrega Acceso a las APIs a través de peticiones HTTP directas
4. Explotación Iteración de IDs para recuperar registros de usuarios no autorizados
5. Instalación Almacenamiento de los datos extraídos en servidores controlados
6. Comando y Control No aplica (ataque de extracción directa, no persistente)
7. Acción sobre Objetivos Filtración de subconjunto WIRED (diciembre 2025); Venta de base de datos completa (septiembre 2026); Potencial uso para phishing, fraude y correlación de datos

Infraestructura Utilizada

Tipo Característica Propósito
Scripts de enumeración Automatización de peticiones HTTP Extracción masiva de datos
Proxies / VPN Múltiples IPs para evadir detección Distribución de consultas
Servidores de almacenamiento Infraestructura para retener datos Almacenamiento de 32,8M de registros
Foro de ciberdelincuencia Foro ruso con depósito en garantía Venta de la base de datos

Detalle Técnico - Vulnerabilidad IDOR y Broken Access Control

¿Qué es IDOR?

IDOR (Insecure Direct Object Reference) es una vulnerabilidad de control de acceso que ocurre cuando una aplicación utiliza identificadores de objetos predecibles (como IDs numéricos secuenciales) para acceder a recursos, pero no verifica si el usuario tiene autorización para acceder a ellos.

Vulnerabilidad explotada

Componente Problema
IDs secuenciales Los IDs de cuenta eran predecibles (1, 2, 3, ...)
Falta de autorización El backend no verificaba si el solicitante tenía permiso
Endpoints sin autenticación Algunos endpoints permitían acceso sin autenticación
Sin rate limiting No había límites en el número de consultas
Sin detección de scraping No se identificó la extracción masiva

Cálculo de factibilidad

Parámetro Valor
IDs de cuenta Secuenciales y predecibles
Velocidad de extracción Miles de registros por hora
Tiempo para extraer 32,8M Días o semanas (según la muestra)
Detección Nula (no había monitoreo de scraping)
Probabilidad de éxito ALTA (sin controles de acceso efectivos)

Nota sobre el impacto

Los atacantes no necesitaban explotar vulnerabilidades complejas. La combinación de IDs secuenciales y falta de autorización a nivel de objeto permitió la extracción masiva de datos sin ser detectados durante semanas.

Datos Expuestos

Campo Porcentaje de registros
Dirección de correo electrónico 100%
Nombre y apellido 31,6%
Dirección postal 22,3%
Género 17,5%
Fecha de nacimiento 12,6%
Número de teléfono 2,9%

Datos NO expuestos:

  • No contiene contraseñas ni hashes.
  • No contiene nombres de usuario para mostrar.
  • No contiene datos de pago.

Víctimas y Sectores Afectados

Categoría Datos
Número de registros 32.815.767
Número de afectados 32,8 millones de usuarios
Publicaciones afectadas Vogue, The New Yorker, GQ, Glamour, WIRED, Vanity Fair, Allure, Bon Appétit, y otras
Tipo de clientes Suscriptores de revistas, usuarios registrados
Sectores potencialmente afectados Medios de comunicación, publicación, consumo
Geografía Global (con mayoría en EE.UU., 82% de los registros)
Subconjunto de WIRED 2.366.576 registros (filtrados en diciembre 2025)
Registros no-WIRED 30.455.594 (no públicos hasta septiembre 2026)

Notificación a clientes

  • WIRED notificó a los afectados por su filtración (2,3M) y los agregó a Have I Been Pwned.
  • Los otros 30,5 millones de afectados no han recibido notificación equivalente.
  • Condé Nast no ha emitido declaración pública.

Impacto y Riesgo

Categoría Nivel Descripción
Impacto inmediato MEDIO-ALTO 32,8M de registros a la venta
Riesgo de phishing ALTO Datos suficientes para correos dirigidos convincentes
Riesgo de fraude postal MEDIO 22,3% de registros con dirección postal
Impacto reputacional (Condé Nast) ALTO Silencio corporativo y falta de transparencia
Riesgo sistémico MEDIO Base de datos de usuarios de medios de comunicación
Probabilidad de reincidencia MEDIA Si no se corrigen las vulnerabilidades IDOR

Comparativa con otros incidentes de filtración de datos

Incidente Año Impacto Lección clave
LastPass 2022 Bóvedas encriptadas de 25M+ usuarios robadas Las bóvedas offline pueden ser descifradas con el tiempo
Passwordstate 2021 Actualización de software comprometida (malware) Los mecanismos de actualización son vectores críticos
Dashlane 2026 ~20 bóvedas robadas por fuerza bruta a 2FA El 2FA no es invencible si no hay rate limiting
Condé Nast 2025-2026 32,8M de registros de usuarios a la venta Las vulnerabilidades IDOR permiten extracción masiva sin detección

Lecciones del incidente LastPass (2022)

El informe de TechCrunch señala que, tras la brecha de LastPass en 2022:

  • "Los requisitos de contraseña para los primeros clientes eran mucho más débiles que el estándar posterior, lo que permitió a los hackers descifrar fácilmente las contraseñas de las bóvedas de algunos clientes mediante ataques de fuerza bruta."
  • "Se han reportado varios casos de hackers que robaron grandes cantidades de criptomonedas de los clientes, probablemente utilizando claves privadas almacenadas en bóvedas de LastPass robadas."

Aplicación a Condé Nast: Aunque no se expusieron contraseñas, la combinación de nombre, dirección postal y publicación a la que está suscrito el usuario permite ataques de phishing altamente dirigidos.

Recomendaciones de Mitigación

Para usuarios afectados (los 32,8M)

Acción Urgencia Descripción
Desconfiar de correos de suscripción ALTA Avisos de renovación, problemas de facturación, ofertas de regalo
Acceder directamente a los sitios web ALTA En lugar de usar enlaces de correos electrónicos
Tratar el correo físico con sospecha MEDIA Cartas fraudulentas que mencionan la revista
Verificar la dirección de correo MEDIA Si se reutiliza en otros servicios, esa reutilización es la exposición
Usar gestores de contraseñas y MFA MEDIA Aunque no se expusieron contraseñas, es buena práctica
Monitorear intentos de phishing ALTA Estar atento a mensajes inesperados

Para organizaciones (medidas post-incidente)

Medida Estado según Condé Nast
Auditoría de APIs para IDOR No especificado
Implementación de autorización a nivel de objeto No especificado
Rate limiting en APIs de cuentas No especificado
Reemplazo de IDs secuenciales No especificado
Monitoreo de scraping No especificado
Notificación a afectados fuera de WIRED Pendiente
Transparencia total Pendiente (silencio corporativo)

Para la industria de medios y publicación

  • Implementar autorización a nivel de objeto en todas las APIs de cuentas.
  • Reemplazar IDs secuenciales con identificadores no adivinables (UUIDs).
  • Implementar rate limiting agresivo en endpoints de cuentas.
  • Monitorear patrones de acceso anómalos (scraping, enumeración).
  • Establecer canales claros para divulgación de vulnerabilidades.
  • Notificar a los afectados de forma transparente y oportuna.

Para usuarios en general (no solo Condé Nast)

Recomendación Por qué
Usar frases de paso largas 20+ caracteres son más seguras que contraseñas cortas
Habilitar 2FA en todas las cuentas críticas Email, banca, criptomonedas, gestor de contraseñas
Preferir claves de seguridad físicas YubiKey, Google Titan, passkeys
No reutilizar contraseñas Una brecha en un sitio no compromete otros
Monitorear brechas de datos Usar servicios como Have I Been Pwned

Herramientas de Detección

Para Condé Nast (post-incidente)

Herramienta/Técnica Propósito
Rate limiting Limitar consultas a APIs por IP/cuenta
Detección de scraping Identificar patrones de enumeración masiva
Alertas en tiempo real Notificar a usuarios y SOC sobre actividad anómala
WAF con reglas específicas Bloquear tráfico automatizado sospechoso
Auditoría de APIs Revisar endpoints para IDOR y broken access control

Para usuarios (autodetección)

Indicador Qué buscar
Correos de suscripción inesperados Avisos de renovación, facturación, regalos
Correo postal fraudulento Cartas que mencionan la revista
Actividad de inicio de sesión inusual Horarios o ubicaciones anormales
Intentos de phishing Mensajes que solicitan verificación de cuenta

Servicios de monitoreo recomendados

Servicio Propósito
Have I Been Pwned (HIBP) Verificar si el correo apareció en brechas de datos
Monitor de crédito Detectar actividad financiera no autorizada
Alertas de inicio de sesión Configurar en cuentas críticas (email, banca, etc.)

Antecedentes: Incidentes en Gestores de Contraseñas y Medios

Fecha Empresa Incidente Impacto
2021 Click Studios (Passwordstate) Actualización de software comprometida con malware Clientes afectados tuvieron que restablecer todas sus credenciales
2022 LastPass Brecha masiva: bóvedas de 25M+ usuarios robadas Descifrado de bóvedas con contraseñas débiles; robo de criptomonedas reportado
2026 Dashlane Fuerza bruta a 2FA, ~20 bóvedas robadas Riesgo de descifrado para clientes con contraseñas maestras débiles
2025-2026 Condé Nast Filtración de 32,8M de registros de usuarios Datos a la venta por $15.000; riesgo de phishing dirigido

Patrón común

En los cuatro casos, el eslabón débil no fue el cifrado (AES-256 es seguro), sino:

  • Contraseñas maestras débiles (LastPass, Dashlane)
  • Mecanismos de autenticación mal implementados (Dashlane: falta de rate limiting en 2FA)
  • Procesos de actualización comprometidos (Passwordstate)
  • Vulnerabilidades de control de acceso (Condé Nast: IDOR y broken access control)

Opiniones de Expertos

  • "Este incidente demuestra un fallo fundamental en la implementación de controles de acceso por parte de Condé Nast. Una vulnerabilidad IDOR debería ser detectada en cualquier auditoría de seguridad básica. El hecho de que los atacantes pudieran extraer 32,8 millones de registros sin ser detectados durante semanas indica una falta grave de monitoreo y autorización a nivel de objeto. Es como tener una biblioteca con 32 millones de libros... y permitir que cualquiera los tome prestados sin carné."* — Fernando Vargas (CiberAnalyst)
  • "Lo más preocupante no es la filtración en sí, sino la falta de transparencia de Condé Nast. No han explicado cómo los atacantes obtuvieron acceso, qué medidas específicas tomaron después, ni si los 30,5 millones de afectados fuera de WIRED han sido notificados. Los clientes merecen respuestas claras cuando se trata de su información personal."* — Fernando Vargas
  • "Este incidente es un recordatorio de que las vulnerabilidades de control de acceso (como IDOR) siguen siendo una de las causas más comunes de filtraciones masivas de datos. La solución es simple en teoría: implementar autorización a nivel de objeto en todas las APIs, reemplazar IDs secuenciales con UUIDs y monitorear patrones de acceso anómalos. En la práctica, muchas organizaciones siguen fallando en esto."* — Fernando Vargas

Referencias y Fuentes

  • Ransomnews Research Team. (2026, 7 de septiembre). Condé Nast: 32,8 millones de registros de usuarios a la venta, muestra verificada.
  • Paganini, P. (2026, 7 de septiembre). Tras la filtración de WIRED, Condé Nast ofrece a la venta datos de 32,8 millones de usuarios. Security Affairs.
  • BleepingComputer. (2026, 7 de septiembre). Hacker claims to leak WIRED database with 2.3 million records.
  • DataBreaches.net. (2025, noviembre-diciembre). Condé Nast gets hacked, and DataBreaches gets "played".
  • SecurityWeek. (2025, diciembre). Hacker claims theft of 40 million Condé Nast records after WIRED data leak.
  • Ars Technica. (2025, diciembre). Condé Nast user database reportedly breached, Ars unaffected.
  • Have I Been Pwned. (2026). WIRED data breach entry.

Historial de Revisiones

Fecha Versión Autor Cambios Realizados
2026-09-10 1.0 Fernando Vargas Hincapié Creación inicial basada en el informe de Ransomnews, Security Affairs y BleepingComputer

Indicadores de Compromiso (IOCs)

Para usuarios de Condé Nast

Tipo de indicador Qué buscar Acción
Correos de suscripción inesperados Avisos de renovación, facturación, regalos Acceder directamente al sitio web
Correo postal fraudulento Cartas que mencionan la revista Desconfiar y verificar
Intentos de phishing Mensajes que solicitan verificación de cuenta No hacer clic en enlaces
Reutilización de correo electrónico Si el correo expuesto se usa en otros servicios Cambiar contraseñas en otros servicios

Para Condé Nast (medidas post-incidente)

Indicador de detección Implementación recomendada
Enumeración de IDs secuenciales Detectar patrones de acceso secuencial → bloquear
Scraping de APIs Detectar múltiples consultas desde la misma IP → bloquear
Acceso a perfiles no autorizados Implementar autorización a nivel de objeto
Velocidad de consultas > 100/minuto Claramente automatizado → bloquear IP/origen

Servicios de monitoreo recomendados

Servicio Propósito
Have I Been Pwned (HIBP) Verificar si el correo apareció en brechas de datos
Monitor de crédito Detectar actividad financiera no autorizada
Alertas de inicio de sesión Configurar en cuentas críticas (email, banca, etc.)

Preguntas sin respuesta (según informe de Ransomnews)

Pregunta Estado
¿Cómo obtuvieron los atacantes acceso inicial al sistema de cuentas? No respondido
¿Por qué las vulnerabilidades IDOR no fueron detectadas antes? No respondido
¿Qué medidas específicas tomó Condé Nast para mitigar futuros incidentes? No especificado
¿Los clientes afectados fuera de WIRED han sido notificados? No claro
¿Los atacantes contactaron a Condé Nast para exigir rescate? No respondido
¿Condé Nast sabe quién está detrás del ataque? No respondido
¿Se ha confirmado que el vendedor es "Lovely"? No verificado independientemente

Etiquetas / Categorías

condé nast data breach wired leak 32 million records idor vulnerability broken access control lovely ransomnews security affairs bleepingcomputer phishing credential exposure 2025 2026

Obtenido de «https://darfe.es/ciberwiki/index.php?title=Filtración_de_Condé_Nast&oldid=3396»