Diferencia entre revisiones de «Filtración de Condé Nast»
(Página creada con «Categoría:Familias de malware Categoría:Ciberataques = Filtración de Condé Nast = 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. El incidente salió a la luz pública en diciembre de 2025, cuando un actor de…») |
Sin resumen de edición |
||
| (No se muestran 4 ediciones intermedias del mismo usuario) | |||
| Línea 1: | Línea 1: | ||
= 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 == | |||
= | {| class="wikitable" | ||
! 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) == | ||
= | {| 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) | |||
|} | |||
== | == 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 === | ||
= | {| 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) | |||
|} | |||
=== Línea de tiempo del incidente (UTC) === | |||
{| class="wikitable" | |||
! 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 === | ||
= | {| class="wikitable" | ||
! 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 === | ||
= | {| 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 | |||
|} | |||
=== 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 == | ||
{| 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 | |||
|} | |||
== | == Flujo de Ataque (Cyber Kill Chain) == | ||
| | {| 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 | |||
|} | |||
== | == Infraestructura Utilizada == | ||
= | {| class="wikitable" | ||
! 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 === | ||
{| 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 | |||
|} | |||
== | === Cálculo de factibilidad === | ||
{| 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 | |||
[[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:
|
| 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