Incidentes y vulnerabilidades
Capital One, Equifax, Log4Shell, Heartbleed, XZ: brechas y vulnerabilidades públicas desglosadas en causa, impacto, primera respuesta y prevención, por las lecciones que siguen vigentes.
Fraude de 7pay (2019) — Cómo se secuestró una app de pago sin 2FA
Los secuestros de cuentas empezaron el día siguiente al lanzamiento; ~808 usuarios perdieron ~¥38,6 millones. El fallo de fondo fue el diseño de autenticación: (1) no había autenticación de dos factores, así que el inicio de sesión solo pedía ID + contraseña, y (2) un restablecimiento de contraseña que podía enviar la nueva a un correo distinto del registrado — de modo que fragmentos de datos personales bastaban para secuestrar una cuenta. Defiéndete exigiendo 2FA en acciones sensibles, restringiendo el restablecimiento a los canales registrados, detectando y bloqueando el relleno de credenciales, y haciendo que un segundo par de ojos revise los flujos de autenticación antes del lanzamiento.
Fuga de datos de Benesse (2014) — por qué no se pudo detener a un interno y la defensa del privilegio mínimo
Un ingeniero de sistemas externo en una empresa del grupo subcontratada usó un acceso a la base de datos concedido legítimamente para copiar datos de clientes en masa, transferirlos a un teléfono personal y venderlos a corredores de datos. El software de monitorización bloqueaba la escritura a almacenamiento USB, pero no la transferencia a un teléfono (MTP). Se filtraron hasta ~35 millones de registros. Defiéndete minimizando el privilegio (privilegio mínimo / need-to-know), cerrando cada vía de exfiltración con DLP, detectando el acceso masivo y extendiendo la supervisión hasta contratistas y subcontratistas.
Ransomware de Capcom (2020) — por qué un viejo dispositivo VPN fue la vía de entrada, y la defensa ante la doble extorsión
La vía de entrada fue un viejo dispositivo VPN de respaldo que se había dejado en marcha en una filial norteamericana después de que unidades más nuevas lo reemplazaran. Desde ahí se vulneró la red, se robaron datos y luego el ransomware cifró los sistemas (doble extorsión). Los datos personales de hasta ~390.000 personas quedaron potencialmente expuestos (sin datos de tarjetas de pago). Capcom se negó a pagar, restauró desde copia de seguridad y lo divulgó con transparencia. Defiéndete retirando el equipo sin uso, parcheando los dispositivos de borde y cubriendo tanto el robo como el cifrado (segmentación, detección, copias de seguridad).
El robo de NEM a Coincheck (2018) — Cómo se robaron unos 530 millones de dólares y la defensa de la gestión de claves
El punto de entrada, según se informó, fue phishing dirigido / malware contra empleados, que robó la clave privada de un monedero caliente conectado a Internet; después se movieron unos 523 millones de XEM (unos 530 millones de dólares de la época) en una sola operación. El fallo de fondo fue mantener un saldo enorme e instantáneamente gastable 'en caliente' y sin multifirma: una sola clave robada movió casi todo. Defiéndete manteniendo las claves importantes en frío / en una bóveda dedicada, minimizando el saldo caliente, eliminando los puntos únicos de fallo (aprobación múltiple) y detectando y deteniendo las operaciones masivas anómalas.
Ransomware de KADOKAWA / Niconico (2024) — por qué se propagó a toda la empresa, y la segmentación de red y el BCP
La vía de entrada se describió como phishing que robó las credenciales de un empleado; desde ahí se vulneró la red interna y se ejecutó el ransomware, tumbando durante meses muchos servicios del grupo (incluido Niconico) y filtrando datos de ~250.000 personas. Según reportes y análisis, la propagación a toda la empresa se atribuye a que sistemas de muy distinta criticidad compartían la misma red — al parecer sin segmentación suficiente. Defiéndete segmentando la red por criticidad, usando autenticación resistente al phishing, y preparando la continuidad del negocio (BCP) y la recuperación.
Filtración de datos de Takufile-bin (2019) — por qué guardar contraseñas en texto plano es fatal, y la defensa del hashing
Se explotó una vulnerabilidad del servidor para lograr acceso no autorizado y se filtraron ~4,8 millones de registros — nombres, correos, contraseñas de acceso, fechas de nacimiento, incluidos clientes dados de baja. El fallo decisivo fue que las contraseñas de acceso se guardaban sin cifrar, en texto plano: al filtrarse, eran usables de inmediato y alimentaron el robo de cuentas en otros sitios por reutilización de contraseñas. Defiéndete guardando las contraseñas como un hash de un solo sentido con sal, sin conservar datos que no necesitas, parcheando vulnerabilidades y preparándote para la reutilización (2FA).
Filtración masiva de MOVEit (2023) — cómo un zero-day de inyección SQL alcanzó a más de 2.700 organizaciones, y cómo defenderse
La entrada fue un zero-day de inyección SQL (CVE-2023-34362) en MOVEit Transfer, expuesto a internet. Se plantó un web shell (LEMURLOOT) y se robaron datos en masa de la base de datos de respaldo, golpeando a más de 2.700 organizaciones y ~93,3M de personas. La mayoría de las víctimas fueron arrastradas indirectamente porque un proveedor usaba MOVEit. En tu entorno: parcheo rápido de KEV, minimizar la exposición, mínimo privilegio y segmentación web↔BD, inventario de proveedores y minimización de datos.
Filtración de Capital One (2019) — cómo un SSRF expuso más de 100M de registros, y cómo defenderse
Un solo SSRF alcanzó el endpoint de metadatos → credenciales IAM temporales con privilegios excesivos → copia masiva de S3, filtrando ~106M de registros. Cada salto pudo haberlo detenido. En tu entorno: IMDSv2, IAM de mínimo privilegio y una lista de permitidos para las peticiones salientes.
Filtración de Codecov (2021) — cuando una «herramienta de confianza» del CI fue secuestrada y se filtraron secretos
Una herramienta de confianza del CI (el Bash Uploader curl|bash) fue alterada en origen. Como tu propio código quedó intacto, pasó ~2 meses inadvertida mientras se filtraban secretos del CI; una verificación de checksum lo detectó. En tu CI: verifica los artefactos descargados, secretos de mínimo privilegio, rotación, monitorización de salida.
Filtración de Equifax (2017) — cómo un fallo de Apache Struts sin parchear expuso a 147M de personas
La causa fue un CVE conocido y ya parcheado (CVSS 10.0) dejado sin aplicar en un sistema público. Un certificado de monitorización caducado ocultó la exfiltración durante 76 días. En tu entorno: inventario de activos, un SLA de parcheo, monitorización automática y detección saludable.
Heartbleed (CVE-2014-0160) — cuando se filtró memoria desde los cimientos del tráfico cifrado
La sobrelectura de memoria de OpenSSL podía filtrar claves privadas y sesiones. La causa: el servidor confiaba en una longitud declarada y leía memoria adyacente. La lección: actúa como si todo se hubiera filtrado —reemite certificados, rota todos los secretos— más el peso del software fundacional y la seguridad de memoria.
Log4Shell (CVE-2021-44228) — la noche en que el mundo temió un fallo que ni siquiera podía confirmar tener
El fallo de CVSS 10.0 de Log4j. El verdadero miedo era la dependencia transitiva: estar afectado a través de una librería que no sabías que usabas. Un camino pasivo de registro de logs se convirtió en vector de ataque. SBOM, monitorización automática, parcheo rápido y seguir los CVE de seguimiento son las lecciones.
La puerta trasera de XZ Utils (CVE-2024-3094) — cuando la confianza misma era el objetivo
Un mantenedor de confianza plantó una puerta trasera en xz: un ataque a la cadena de suministro. El «esto va lento» de un ingeniero lo detectó justo antes de la estable. El objetivo no era el código, sino las personas y la confianza. Minimiza dependencias, fija versiones, compila de forma reproducible, persigue anomalías y apoya a los mantenedores.