MOVEit, 3CX y la Era del Supply Chain (2023)
2023 consolidó los ataques de cadena de suministro como el vector dominante. El compromiso de 3CX por Lazarus Group fue el primer ataque de doble supply chain documentado, y la explotación masiva de MOVEit Transfer por Cl0p afectó a más de 2.700 organizaciones y 90 millones de personas sin necesidad de desplegar ransomware.
2023: el año en que la cadena de suministro se convirtió en campo de batalla
Si SolarWinds en 2020 fue la demostración de concepto, 2023 fue la confirmación de que los ataques de cadena de suministro de software se habían convertido en el vector preferido para operaciones de alto impacto. En un período de tres meses, dos ataques de supply chain sacudieron la industria: el compromiso de 3CX por Lazarus Group (marzo) y la explotación masiva de MOVEit Transfer por Cl0p (mayo-junio).
Cada uno representaba un modelo diferente de amenaza. El ataque a 3CX fue una operación de espionaje de estado-nación con un nivel de sofisticación sin precedentes: un doble ataque de supply chain donde la cadena de suministro de un proveedor fue comprometida a través de la cadena de suministro de otro. El ataque a MOVEit fue una operación criminal masiva que demostró que el ransomware ya ni siquiera necesitaba cifrar datos para ser lucrativo.
Y en el fondo, una tendencia emergente en los ecosistemas de paquetes de software (npm, PyPI, RubyGems) mostraba que el supply chain no era solo un problema de grandes proveedores: cualquier dependencia de código abierto podía ser un vector de ataque.
3CX: el primer ataque de doble supply chain
3CX Desktop App y su ecosistema
3CX es una empresa de comunicaciones que desarrolla un sistema de telefonía VoIP (Voice over IP) utilizado por más de 600.000 organizaciones y 12 millones de usuarios diarios en todo el mundo. Su producto principal, 3CX Desktop App, se instala en los ordenadores de los empleados para gestionar llamadas, videoconferencias y mensajería.
La cadena de compromiso
Lo que hizo único al ataque de 3CX fue su naturaleza de cascada: un supply chain attack dentro de otro supply chain attack.
Paso 1: Compromiso de Trading Technologies (2021). Lazarus Group comprometió X_Trader, una aplicación de trading financiero desarrollada por Trading Technologies. A pesar de que X_Trader había sido descontinuada en 2020, la aplicación seguía disponible para descarga y algunos usuarios la mantenían instalada. Los atacantes troyanizaron el instalador oficial.
Paso 2: Infección del empleado de 3CX. Un empleado de 3CX instaló la versión comprometida de X_Trader en su ordenador personal. El malware inyectado (VEILEDSIGNAL) proporcionó a Lazarus acceso al ordenador del empleado y, a través de las credenciales almacenadas, acceso a la red corporativa de 3CX.
Paso 3: Compromiso del build pipeline de 3CX. Una vez dentro de la red de 3CX, los atacantes accedieron al sistema de compilación del software y modificaron el proceso de build para inyectar código malicioso en el instalador oficial de 3CX Desktop App.
Paso 4: Distribución masiva (marzo 2023). Las versiones troyanizadas de 3CX Desktop App (para Windows y macOS) fueron distribuidas a clientes a través del mecanismo oficial de actualización, firmadas con el certificado digital legítimo de 3CX.
Trading Technologies (X_Trader)
↓ compromiso del instalador
Empleado de 3CX instala X_Trader troyanizado
↓ credenciales comprometidas
Lazarus accede a la red de 3CX
↓ compromiso del build pipeline
3CX Desktop App troyanizada
↓ actualización oficial firmada
600.000+ organizaciones clientes de 3CX
Detección y análisis técnico
El ataque fue detectado a finales de marzo de 2023 cuando múltiples herramientas de seguridad comenzaron a alertar sobre comportamiento sospechoso de 3CXDesktopApp.exe.
Vector técnico en Windows: La aplicación troyanizada cargaba una DLL maliciosa (ffmpeg.dll) mediante la técnica de DLL Sideloading. La DLL descargaba iconos cifrados alojados en un repositorio de GitHub. Al descifrar los iconos, se revelaban las direcciones de servidores C2. El malware contactaba esos servidores para descargar un tercer componente: un infostealer llamado ICONICSTEALER que recopilaba datos del navegador.
Segunda fase selectiva: Para objetivos de alto valor, Lazarus desplegaba un backdoor adicional llamado Gopuram, que proporcionaba acceso completo al sistema comprometido.
| Atributo | Detalle |
|---|---|
| Fecha de detección | 29 de marzo de 2023 |
| Actor | Lazarus Group (G0032, DPRK) |
| Tipo | Doble supply chain attack |
| Primer eslabón | Trading Technologies / X_Trader |
| Segundo eslabón | 3CX Desktop App |
| Técnica de inyección | DLL Sideloading (ffmpeg.dll) |
| Payload fase 1 | ICONICSTEALER (infostealer) |
| Payload fase 2 | Gopuram (backdoor completo) |
| Usuarios potencialmente afectados | 12 millones diarios |
| MITRE | T1195.002, T1574.002, T1059 |
La atribución a Lazarus
Múltiples investigadores (Mandiant, Kaspersky, ESET, Symantec) atribuyeron el ataque a Lazarus Group basándose en:
- Similitudes de código entre el malware desplegado y herramientas previamente atribuidas a Lazarus
- Infraestructura C2 compartida con campañas anteriores de Lazarus
- La motivación financiera (Lazarus genera fondos para el programa nuclear y de misiles de Corea del Norte)
- Técnicas operacionales consistentes con el modus operandi de Lazarus
MOVEit Transfer: explotación masiva sin ransomware
MOVEit Transfer y su papel en las empresas
MOVEit Transfer, desarrollado por Progress Software, es un software de transferencia segura de ficheros (Managed File Transfer, MFT) utilizado por organizaciones para mover datos sensibles entre sistemas, socios comerciales y clientes. Por su función, los servidores MOVEit contenían exactamente el tipo de datos que los atacantes querían: información personal, registros financieros, datos médicos y documentos corporativos confidenciales.
CVE-2023-34362: SQL Injection en MOVEit
El 31 de mayo de 2023, Progress Software publicó un aviso de seguridad sobre una vulnerabilidad crítica de SQL injection en MOVEit Transfer (CVE-2023-34362, CVSS 9.8). Pero para entonces, Cl0p ya llevaba días explotándola.
| Atributo | Detalle |
|---|---|
| CVE | CVE-2023-34362 |
| CVSS | 9.8 (Crítica) |
| Tipo | SQL Injection (SQLi to RCE) |
| Componente afectado | Interfaz web de MOVEit Transfer |
| Autenticación requerida | Ninguna |
| Impacto | Acceso completo al servidor y datos almacenados |
| Explotación en el wild | Desde al menos 27 de mayo de 2023 |
La vulnerabilidad permitía a un atacante no autenticado inyectar código SQL malicioso en la interfaz web de MOVEit Transfer, obteniendo acceso a la base de datos subyacente y, a través de ella, ejecución de código remoto en el servidor.
La campaña de Cl0p: exfiltración sin cifrado
Cl0p (también conocido como TA505, MITRE ID G0092) no era un recién llegado. El grupo había perfeccionado su técnica de explotar vulnerabilidades zero-day en software de transferencia de ficheros con ataques previos contra Accellion FTA (2020) y GoAnywhere MFT (enero 2023). MOVEit fue la tercera iteración de esta estrategia, y la más devastadora.
Lo que diferenciaba la campaña MOVEit de las operaciones tradicionales de ransomware era su modelo operativo:
- Explotación automatizada: Cl0p escaneó Internet en busca de servidores MOVEit expuestos y explotó CVE-2023-34362 de forma automatizada
- Web shell persistente: Desplegaron un web shell personalizado llamado LEMURLOOT (fichero human2.aspx, imitando el componente legítimo human.aspx de MOVEit)
- Exfiltración masiva: Descargaron los datos almacenados en cada servidor comprometido
- Sin cifrado: No desplegaron ransomware. No cifraron ningún sistema.
- Extorsión pura: Publicaron en su sitio de filtraciones los nombres de las víctimas y amenazaron con publicar los datos si no se pagaba
Esta estrategia era más eficiente que el ransomware tradicional por varias razones:
- Menor riesgo de detección (no hay proceso de cifrado que active alertas)
- Menor complejidad operativa (no necesitan mantener infraestructura de descifrado)
- El software de transferencia de ficheros contiene datos valiosos por diseño
- La amenaza de publicación es suficiente para presionar a las víctimas
Escala del impacto
Las cifras finales del ataque a MOVEit fueron extraordinarias:
| Métrica | Cifra |
|---|---|
| Organizaciones comprometidas | Más de 2.700 |
| Individuos afectados (datos expuestos) | Más de 90 millones |
| Países afectados | ~30 |
| Sector más impactado | Educación, sanidad, gobierno, finanzas |
Entre las víctimas más notables:
| Víctima | Sector | Datos comprometidos |
|---|---|---|
| Departamento de Energía (EE.UU.) | Gobierno | Datos de empleados |
| Shell | Energía | Datos de empleados |
| British Airways | Aviación | Datos de empleados (vía Zellis) |
| BBC | Medios | Datos de empleados (vía Zellis) |
| Ernst & Young | Consultoría | Datos de clientes |
| Gobierno de Nueva Escocia | Gobierno | Datos de ciudadanos |
| BORN Ontario | Sanidad | 3,4 millones de registros de nacimiento |
| Maximus | Gobierno/IT | 11 millones de registros |
| Múltiples universidades | Educación | Datos de estudiantes y personal |
Impacto económico
Se estima que Cl0p obtuvo entre 75 y 100 millones de dólares en pagos de rescate por la campaña MOVEit, según análisis de Coveware. Muchas víctimas, particularmente en el sector público y educativo, se negaron a pagar, pero los datos exfiltrados fueron publicados igualmente.
El caso Okta: el proveedor de identidad como supply chain
En octubre de 2023, Okta (proveedor líder de gestión de identidades y acceso) sufrió una brecha que expuso datos de todos sus clientes de soporte. Los atacantes accedieron al sistema de soporte de Okta utilizando credenciales robadas y descargaron ficheros HAR (HTTP Archive) que contenían tokens de sesión activos de clientes, incluyendo empresas como BeyondTrust, Cloudflare y 1Password.
Aunque técnicamente no era un supply chain attack clásico, el compromiso de un proveedor de identidades tiene el mismo efecto multiplicador: una brecha en Okta potencialmente compromete a todos sus clientes. BeyondTrust detectó un intento de acceso no autorizado utilizando un token de sesión robado de Okta y alertó a la compañía semanas antes de que Okta confirmase la brecha públicamente, lo que generó críticas sobre la velocidad de respuesta y transparencia del proveedor.
El incidente reforzó una lección dolorosa: la centralización de la identidad digital en un solo proveedor crea un punto de fallo catastrófico. Si el proveedor de identidad cae, todo lo que depende de él queda expuesto.
Tendencia emergente: paquetes maliciosos en ecosistemas open source
npm, PyPI y el supply chain del desarrollador
Mientras 3CX y MOVEit acaparaban titulares, una tendencia menos visible pero igualmente preocupante se consolidaba en 2023: la publicación de paquetes maliciosos en los repositorios de software open source.
Los ecosistemas de paquetes (npm para JavaScript, PyPI para Python, RubyGems para Ruby, crates.io para Rust) permiten a cualquier persona publicar paquetes que millones de desarrolladores pueden instalar con un solo comando. Esta apertura, fundamental para la innovación, también creaba un vector de supply chain que los atacantes explotaban de formas cada vez más creativas:
Typosquatting: Publicar paquetes con nombres casi idénticos a paquetes populares (por ejemplo, requet en lugar de request, crypt0 en lugar de crypto). El desarrollador que comete un error tipográfico al instalar descarga código malicioso en lugar del paquete legítimo.
Dependency confusion: Publicar paquetes públicos con el mismo nombre que paquetes internos privados de empresas, aprovechando que muchos gestores de paquetes priorizan el repositorio público sobre el privado. Alex Birsan demostró la viabilidad de esta técnica en 2021 comprometiendo entornos de Apple, Microsoft y PayPal.
Account takeover: Comprometer cuentas de mantenedores de paquetes populares para inyectar código malicioso en actualizaciones legítimas. El caso de ua-parser-js (octubre 2021, 8 millones de descargas semanales) fue un precedente que se repitió con frecuencia creciente.
En 2023, se documentaron más de 245.000 paquetes maliciosos solo en npm y PyPI. Aunque la mayoría eran cryptominers y stealers de bajo impacto, la escala del fenómeno indicaba que el supply chain del desarrollador se había convertido en un campo de batalla permanente.
El patrón emergente: supply chain como vector dominante
Evolución del supply chain attack (2017, 2023)
| Año | Ataque | Actor | Mecanismo | Escala |
|---|---|---|---|---|
| 2017 | NotPetya (vía M.E.Doc) | Sandworm | Actualización troyanizada | ~49.000 orgs |
| 2017 | CCleaner | APT41 | Build pipeline | ~2,3 millones |
| 2020 | SolarWinds | APT29 | Build pipeline + firma | ~18.000 orgs |
| 2021 | Kaseya (REvil) | REvil | Zero-day en software MSP | ~1.500 orgs |
| 2023 | 3CX | Lazarus | Doble supply chain | ~600.000 orgs |
| 2023 | MOVEit | Cl0p | Zero-day en MFT | ~2.700 orgs |
| 2024 | XZ Utils | Desconocido | Social engineering de mantenedor | Potencialmente ilimitada |
Por qué el supply chain es irresistible
Los ataques de cadena de suministro ofrecen una relación esfuerzo/impacto que ningún otro vector puede igualar:
- Escala: Un solo compromiso proporciona acceso a miles o millones de víctimas
- Confianza: El software llega por canales legítimos, firmado digitalmente
- Evasión: El código malicioso se ejecuta dentro de software autorizado
- Persistencia: Las actualizaciones maliciosas se instalan automáticamente
- Dificultad de detección: El comportamiento malicioso se mezcla con el comportamiento legítimo del software comprometido
MITRE ATT&CK: técnicas principales
| Técnica | ID | Descripción en el contexto de 2023 |
|---|---|---|
| Supply Chain Compromise: Software Supply Chain | T1195.002 | 3CX (doble), MOVEit (zero-day en software de transferencia) |
| Exploit Public-Facing Application | T1190 | CVE-2023-34362 en MOVEit Transfer |
| Command and Scripting Interpreter | T1059 | Web shells, LEMURLOOT en MOVEit |
| DLL Side-Loading | T1574.002 | ffmpeg.dll malicioso en 3CX |
Impacto regulatorio: SBOM, gestión de riesgos de terceros y Secure by Design
La aceleración del SBOM
Los ataques de 2023 aceleraron una transformación regulatoria que SolarWinds había iniciado en 2021. La Orden Ejecutiva 14028 de Biden ya exigía que los proveedores de software del gobierno federal proporcionasen un SBOM (Software Bill of Materials) para cada producto. Pero la adopción era lenta y la implementación desigual.
3CX y MOVEit cambiaron el cálculo. Si una organización no sabe qué componentes de software utiliza, no puede evaluar si alguno de ellos ha sido comprometido. El SBOM dejó de ser una exigencia burocrática para convertirse en una necesidad operativa urgente. En 2023, el NIST publicó guías actualizadas para la generación y el consumo de SBOMs, y empresas como Microsoft, Google y Siemens empezaron a exigir SBOMs a sus proveedores como requisito contractual.
Gestión de riesgos de terceros (TPRM)
Los ataques de 2023 expusieron la debilidad sistémica de la gestión de riesgos de terceros. Muchas de las víctimas de MOVEit no utilizaban el software directamente: sus datos fueron comprometidos porque un proveedor de servicios (como Zellis, la empresa de nóminas de British Airways y la BBC) utilizaba MOVEit para procesar su información.
Esta cadena de dependencias, donde el riesgo se transmite a través de múltiples capas de proveedores, obligó a las organizaciones a replantear su enfoque de TPRM. Ya no bastaba con evaluar la seguridad del proveedor directo: había que evaluar la seguridad de los proveedores del proveedor.
La iniciativa Secure by Design (CISA)
En abril de 2023, la CISA (Cybersecurity and Infrastructure Security Agency) publicó su iniciativa "Secure by Design", un conjunto de principios que pedían a los fabricantes de software asumir la responsabilidad de la seguridad de sus productos antes de la entrega al cliente, no después. Los principios incluían:
- Seguridad por defecto: Los productos deben ser seguros sin necesidad de configuración adicional por parte del cliente
- Eliminación de vulnerabilidades por clases enteras: En lugar de parchear vulnerabilidades individuales, eliminar las clases de vulnerabilidad (como SQL injection) mediante diseño seguro del código
- Transparencia radical: Los fabricantes deben publicar información sobre vulnerabilidades, sus prácticas de desarrollo y la composición de su software (SBOM)
La iniciativa fue una respuesta directa a la realidad de 2023: CVE-2023-34362 era una SQL injection, una clase de vulnerabilidad conocida desde hace más de dos décadas. Que un software de transferencia de ficheros empresariales tuviera una SQL injection no autenticada en 2023 era un fallo de diseño, no de operaciones.
Lecciones de 2023
Para organizaciones
- Verificar la cadena de suministro es insuficiente si la cadena de suministro de tu proveedor también está comprometida. El caso 3CX demostró que la integridad de un proveedor depende de la integridad de todos sus propios proveedores
- El software de transferencia de ficheros (MFT) es un objetivo de alto valor. Cualquier software que almacena o transmite datos sensibles necesita aislamiento de red y monitorización intensiva
- La extorsión sin cifrado es el nuevo modelo. Las organizaciones necesitan asumir que la exfiltración de datos es un escenario tan probable como el cifrado
- SBOM no es suficiente sin monitorización continua. Saber qué componentes tiene tu software es el primer paso, pero necesitas alertas cuando esos componentes son vulnerables
- Centralizar la identidad en un solo proveedor crea un punto de fallo catastrófico. El incidente de Okta demostró que la cadena de suministro no es solo software: incluye servicios de identidad, procesadores de nóminas y cualquier proveedor con acceso a datos
Para la industria
2023 confirmó que el supply chain de software era el nuevo perímetro de seguridad. No bastaba con proteger los propios sistemas si el software de confianza que se instalaba en ellos estaba comprometido. El concepto de "confianza cero" debía extenderse no solo a los usuarios y dispositivos sino al propio software, incluyendo las actualizaciones firmadas de proveedores reputados.
La industria de la ciberseguridad se enfrentaba a un problema fundamental: las defensas tradicionales estaban diseñadas para detectar software malicioso, no software legítimo que contenía código malicioso. Resolver esa brecha requería un cambio de paradigma que apenas comenzaba a gestarse, impulsado por iniciativas como Secure by Design de CISA y la adopción progresiva de SBOMs como estándar de la industria.
Preguntas frecuentes
Artículos relacionados
Este contenido tiene fines exclusivamente educativos y de investigación en ciberseguridad defensiva. No se proporcionan binarios maliciosos ni payloads ejecutables. El uso indebido de esta información es responsabilidad exclusiva del usuario. Leer disclaimer completo.