Ataques a la cadena de suministro: 9 ejemplos y defensa

Title etiqueta: Ejemplos de Ataques a la Cadena de Suministro: La Guía Completa (2013–2024) Meta descripción: Descubre qué son los ataques a la cadena de suministro y explora 9 ejemplos importantes de SolarWinds a XZ Utils, con mecanismos de ataque, datos de impacto financiero y estrategias de defensa.

¿Qué es un shock de oferta y qué significa para la ciberseguridad?

El ciberataque más costoso de la historia registrada no comenzó con un hacker irrumpiendo en una red gubernamental. Comenzó con una actualización de software. Un programa de contabilidad utilizado por miles de empresas en Ucrania entregó sigilosamente código malicioso que se propagó por redes corporativas globales en cuestión de horas, causando finalmente daños estimados en 10.000 millones de dólares. Ese ataque, NotPetya, es uno de los nueve principales supply chain attack examples que esta guía cubre en detalle, con el actor, el mecanismo y el impacto financiero documentado para cada uno.

Comprender estos incidentes comienza con un concepto de la economía: la onda de choque de la oferta. Una onda de choque de la oferta es una interrupción súbita e inesperada en el suministro de un producto o servicio que se propaga a todos los que dependen de él. Los ejemplos clásicos son los embargos de petróleo y los desastres naturales. Estos eventos se originan en un único punto de una red de suministro, pero causan daños en cascada a miles de consumidores aguas abajo que no tuvieron ningún papel en la interrupción original.

Los ciberataques a la cadena de suministro operan como una forma de shock de oferta digital. Un atacante compromete a un proveedor de software o componente de hardware de confianza en una etapa previa, y el daño se propaga automáticamente a cada organización que instala dicho software, confía en dicho proveedor o depende de dicho componente. La víctima no hizo nada malo. Sus propias defensas fueron eludidas por completo. El ataque explotó la cadena de suministro, no al objetivo. Al igual que un embargo petrolero puede paralizar industrias que nunca tocaron una refinería, una actualización de software comprometida puede devastar a organizaciones que nunca interactuaron con el atacante.

Esta guía ofrece una visión completa: qué son los ataques a la cadena de suministro, cómo funcionan técnicamente, todos los incidentes importantes con nombre propio desde 2013 hasta 2024 con datos de impacto cuantificados, quiénes los llevan a cabo y por qué, y qué pueden hacer las organizaciones y los desarrolladores para reducir su exposición.

¿Qué es un ataque a la cadena de suministro?

Un ataque a la cadena de suministro es un ciberataque que compromete a una organización de forma indirecta al dirigirse a un proveedor tercero de confianza, un componente de software o un elemento de hardware en la cadena de suministro de dicha organización. Los atacantes insertan código malicioso o puertas traseras en software o hardware legítimo en las fases iniciales, de modo que las víctimas introducen la amenaza ellas mismas sin saberlo a través de procesos rutinarios de actualización o adquisición. Los propios controles de seguridad de la víctima se eluden porque el ataque proviene de una fuente de confianza.

Una cadena de suministro de software abarca todos los componentes, bibliotecas y procesos involucrados en la creación y entrega de un producto de software. Esto incluye dependencias de código de un Tercero, bibliotecas de código abierto, infraestructura de compilación, servidores de actualización y firmware de hardware. Cualquiera de estos elementos puede servir como punto de entrada.

La diferencia clave entre un ataque a la cadena de suministro y un ciberataque directo radica en dónde ataca el atacante. En un ataque directo, el atacante se dirige a los propios sistemas, aplicaciones o usuarios de la víctima y debe superar los controles de seguridad de esa organización. En un ataque a la cadena de suministro, el atacante se dirige a un proveedor en el que la víctima ya confía, eludiendo completamente esos controles. Un solo proveedor comprometido puede exponer miles de organizaciones posteriores simultáneamente.

Una brecha de seguridad de datos es un resultado, no un método de ataque. Los ataques a la cadena de suministro pueden causar brechas de seguridad de datos, pero no todas las brechas de seguridad de datos implican compromisos en la cadena de suministro. Tampoco todos los ataques a la cadena de suministro resultan en el robo de datos: NotPetya causó destrucción en lugar de filtración de datos.

Cómo funcionan los ataques a la cadena de suministro

Los ataques a la cadena de suministro siguen un patrón consistente: los atacantes comprometen a un proveedor de confianza en lugar de dirigirse directamente a la organización víctima. El ataque se propaga a través de los canales habituales de distribución de software, actualizaciones o adquisición de hardware.

El ciclo de vida del ataque: Paso a paso

1. El atacante identifica a un proveedor de confianza o un componente de software utilizado por el objetivo
2. El atacante obtiene acceso al sistema de compilación, al repositorio de código o al servidor de actualizaciones del proveedor
3. Se inserta código malicioso en el software o hardware legítimo antes de su distribución
4. El proveedor distribuye el producto comprometido a través de sus canales habituales y de confianza
5. La organización objetivo instala la actualización o despliega el componente, introduciendo la amenaza
6. El atacante utiliza el punto de apoyo establecido para realizar movimientos laterales, espionaje o desplegar cargas útiles destructivas

Taxonomía de vectores de ataque

Actualizaciones de software troyanizadas

Una actualización troyanizada es particularmente peligrosa porque elude casi todos los controles de seguridad estándar. La actualización llega de un proveedor en el que la organización ya confía, posee un certificado digital legítimo de firma de código, supera los análisis antivirus y de seguridad de punto final, y el usuario la instala voluntariamente como parte del mantenimiento rutinario. Nadie en la organización objetivo hizo nada malo.

Un compromiso del sistema de compilación tiene como objetivo el proceso de compilación automatizado que convierte el código fuente en software ejecutable. Un atacante obtiene acceso al entorno de compilación de un proveedor e inserta código malicioso durante la compilación. El paquete de software resultante parece idéntico a la versión legítima. Un flujo de trabajo (pipeline) de CI/CD (integración continua/despliegue continuo) comprometido en esta etapa propagará código malicioso a cada lanzamiento de software posterior, incluso si el código fuente original permanece limpio. Por este motivo, incluso una auditoría de código exhaustiva del repositorio de origen no detectaría el ataque.

Piénsalo de esta manera: imagina que un proveedor farmacéutico reemplaza sigilosamente un medicamento legítimo por una versión contaminada antes del envío. El hospital que lo recibe y lo administra no ha hecho nada malo. El ataque se aprovechó de la cadena de suministro, no del hospital.

SolarWinds, CCleaner y ASUS ShadowHammer siguieron este patrón. En cada caso, los atacantes comprometieron la infraestructura de compilación del proveedor en lugar de las organizaciones objetivo directamente.

Ataques a Registros de Paquetes de Código Abierto

Los registros de paquetes públicos se encuentran entre las superficies de ataque más activas en la cadena de suministro de software. Esto incluye npm para JavaScript, PyPI para Python, RubyGems para Ruby, NuGet para .NET y Maven para Java. Solo el registro npm alberga más de dos millones de paquetes. Un solo paquete Popular comprometido puede propagar código malicioso a millones de aplicaciones.

Tres patrones de ataque distintos atacan este ecosistema. En typosquatting, un atacante registra un paquete con un nombre casi idéntico a un paquete legítimo popular (por ejemplo, lodahs en lugar de lodash) esperando captar a desarrolladores distraídos. En confusión de dependencias, el atacante utiliza el mismo nombre que un paquete interno privado de una organización objetivo en un registro público. Los sistemas de compilación que comprueban los registros públicos antes que los privados descargarán automáticamente la versión maliciosa. En inyección de paquetes maliciosos, un paquete legítimo se ve comprometido después de su publicación, ya sea robando las credenciales del mantenedor o mediante ingeniería social del proyecto.

La confusión de dependencias se demostró públicamente a gran escala por primera vez en 2021 por el investigador de seguridad Alex Birsan, quien logró la ejecución de código dentro de los procesos de compilación de Apple, Microsoft, PayPal y otras 35 empresas importantes utilizando esta técnica. El ataque funcionó no por un error, sino por cómo los gestores de paquetes resuelven los conflictos de nombres entre registros públicos y privados.

Sobre Log4Shell: Log4Shell (CVE-2021-44228), la vulnerabilidad crítica descubierta en diciembre de 2021 en la biblioteca de registro de Java Apache Log4j, se describe con frecuencia como un ataque a la cadena de suministro. No fue así. Log4Shell fue una vulnerabilidad de software involuntaria. Ningún atacante la insertó en la base de código de Log4j. La confusión surge porque la presencia de Log4j como dependencia en miles de productos de software hizo que la identificación de todos los sistemas afectados se asemejara a un problema de auditoría de la cadena de suministro. El modelo de amenazas es diferente: los ataques a la cadena de suministro implican código malicioso insertado intencionadamente por un atacante, mientras que Log4Shell fue un fallo accidental que los atacantes explotaron posteriormente.

Compromiso de MSP y movimiento lateral

Un Proveedor de Servicios Gestionados (MSP) es una empresa que gestiona de forma remota la infraestructura, seguridad y sistemas de TI de una organización cliente. Los MSP son utilizados comúnmente por empresas pequeñas y medianas que carecen de equipos de TI internos. Comprometer a un MSP otorga a los atacantes acceso administrativo simultáneo a todos los clientes de ese MSP, convirtiendo a los MSP en vectores de ataque multiplicadores de fuerza con un alcance descendente desproporcionado. Asesoramiento de la CISA AA22-131A) advierte específicamente a los MSP que son objetivos de alta prioridad.

Una vez dentro de cualquier red a través de una actualización troyanizada o una dependencia comprometida, los atacantes suelen utilizar técnicas de movimiento lateral. Estas técnicas explotan credenciales legítimas y rutas de acceso a la red para pivotar desde el sistema inicialmente comprometido hacia objetivos más sensibles. En el ataque a SolarWinds, APT29 utilizó la puerta trasera SUNBURST como primer punto de entrada y luego se movió lateralmente hacia sistemas de correo electrónico y almacenes de datos sensibles en varias agencias gubernamentales.

Ejemplos de Principales Ataques a la Cadena de Suministro

La siguiente tabla resume los ejemplos más significativos de ataques a la cadena de suministro desde 2013 hasta 2024, organizados por actor, vector e impacto documentado.

Filtración de datos de Target (2013)

Target (2013) — un grupo de delincuentes obtuvo acceso a la red de puntos de venta de Target tras comprometer primero a Fazio Mechanical Services, un contratista tercero de climatización y refrigeración que poseía credenciales de red para el acceso remoto a los sistemas de Target.

La brecha de Target es el primer ejemplo ampliamente estudiado del patrón de ataque a la cadena de suministro. Los atacantes no penetraron directamente las defensas perimetrales de Target. Obtuvieron credenciales de un pequeño proveedor de HVAC, usaron esas credenciales para acceder a la red de Target a través de una vía de acceso legítima y, a continuación, se movieron lateralmente hacia los sistemas de punto de venta que procesaban los datos de las tarjetas de pago.

El resultado fue el robo de datos de tarjetas de pago de aproximadamente 40 millones de clientes y de datos personales de aproximadamente 110 millones. Los costes totales de Target derivados de la brecha superaron una cifra estimada de 200 millones de dólares en acuerdos, honorarios legales y remediación. El ataque estableció el modelo que ataques posteriores perfeccionaron: comprometer a un proveedor de confianza con acceso al objetivo real para, a continuación, utilizar ese acceso como punto de entrada. Las investigaciones del Servicio Secreto de los EE. UU. y del Departamento de Justicia confirmaron la vía del proveedor tercero como el vector de entrada.

Ataque a la cadena de suministro de SolarWinds (2020)

SolarWinds (2020): el grupo APT29 (Cozy Bear), atribuido al Servicio de Inteligencia Exterior (SVR) de Rusia, comprometió el proceso de compilación de la plataforma de monitorización de TI Orion, insertando la puerta trasera SUNBURST en una actualización de software rutinaria descargada por aproximadamente 18.000 clientes de SolarWinds.

SolarWinds es ampliamente considerado el ciberataque de cadena de suministro más importante en la historia registrada. Orion era una plataforma de monitorización de TI ampliamente desplegada utilizada por agencias gubernamentales de EE. UU. y grandes corporaciones. Los atacantes insertaron la puerta trasera SUNBURST en el pipeline de compilación del software, lo que significa que el código malicioso se compiló directamente en el paquete de actualización legítimo de Orion, firmado con certificados válidos de SolarWinds y distribuido a través de canales de actualización oficiales.

Entre las aproximadamente 18.000 organizaciones que descargaron la actualización troyanizada, los atacantes seleccionaron objetivos de alto valor para una explotación secundaria. Estos incluían los Departamentos del Tesoro, Comercio, Seguridad Nacional y Estado de los Estados Unidos, así como Microsoft, FireEye y otras importantes empresas tecnológicas. La intrusión pasó desapercibida durante aproximadamente nueve meses antes de que FireEye la descubriera mientras investigaba una anomalía en sus propios sistemas.

APT29 utilizó el punto de apoyo de SUNBURST como un punto de acceso inicial, luego se movió lateralmente a través de redes comprometidas para acceder a sistemas de correo electrónico y comunicaciones sensibles. La operación fue evaluada como una campaña de espionaje en lugar de un ataque destructivo. La respuesta del gobierno de EE. UU., coordinada a través del Asesoramiento CISA AA20-352A,), incluyó directivas de emergencia que afectaron a todas las agencias federales civiles.

NotPetya (2017)

NotPetya (2017) — Sandworm, atribuido a la inteligencia militar rusa GRU (Unidad 74455), inyectó código malicioso en una actualización de software de M.E.Doc, una aplicación de contabilidad ucraniana utilizada por una gran parte de las empresas que operan en Ucrania.

NotPetya no era ransomware. Mostraba una nota de rescate, pero era una tapadera. El código sobrescribió el Master Boot Record (MBR) de los sistemas infectados y los dejó permanentemente irrecuperables. Era un wiper destructivo diseñado para causar el máximo daño, sin un mecanismo de pago real. La apariencia similar a un rescate fue diseñada para dificultar la atribución durante la respuesta inicial.

El vector de infección inicial fue la actualización de M.E.Doc, pero NotPetya se propagó rápidamente más allá de Ucrania a través de la vulnerabilidad EternalBlue y la propagación en red, convirtiéndose en una catástrofe mundial en cuestión de horas. Los daños totales se han estimado en aproximadamente 10.000 millones de dólares en todo el mundo, lo que lo convierte en el ciberataque más destructivo de la historia por impacto financiero. Entre las víctimas nombradas se encuentran el gigante naviero Maersk (aproximadamente 300 millones de dólares en daños; la empresa tuvo que reinstalar 45.000 PC y 4.000 servidores desde cero), el fabricante farmacéutico Merck, FedEx/TNT Express, y Mondelez International. Muchas de estas organizaciones no tenían conexión directa con Ucrania y fueron víctimas colaterales alcanzadas a través de la conectividad global de la red.

El ataque está documentado detalladamente en la investigación retrospectiva de Wired y se atribuye a Sandworm por parte de Estados Unidos, Reino Unido y Australia. Sandworm es distinto de APT29/Cozy Bear: operan bajo diferentes agencias de inteligencia rusas (GRU frente a SVR) con mandatos operativos distintos.

Ataque a Kaseya VSA (2021)

Kaseya VSA (2021) — REvil, un grupo ciberdelincuente de ransomware como servicio (RaaS) sin afiliación estatal, explotó una vulnerabilidad de día cero en Kaseya VSA para distribuir actualizaciones maliciosas a clientes de MSP simultáneamente.

Kaseya VSA es una plataforma de monitorización y gestión remota ampliamente utilizada por Proveedores de Servicios Gestionados (PSM). REvil, un grupo criminal con motivación financiera, identificó la superficie de ataque de los PSM y la explotó a gran escala. Al comprometer la plataforma VSA, REvil podía distribuir actualizaciones maliciosas que parecían originarse en el PSM de confianza a todas las organizaciones cliente aguas abajo a la vez.

El resultado: aproximadamente 60 MSP fueron comprometidos y, a través de ellos, aproximadamente 1.500 empresas dependientes sufrieron ataques de ransomware (malware que cifra los datos de una víctima y exige un pago por la clave de descifrado). REvil exigió 70 millones de dólares en Bitcoin por un descifrador universal. El ataque ilustró con particular claridad la lógica de multiplicador de fuerza de la selección de MSP: una Plataforma comprometida alcanzó a cientos de organizaciones en una sola operación. Asesoramiento de CISA AA21-200B) proporciona el análisis técnico completo.

Ataque a la cadena de suministro de Codecov (2021)

Codecov (2021) — un atacante no atribuido manipuló el script Bash Uploader de Codecov, una herramienta de informes de cobertura de código integrada en las canalizaciones de CI/CD de miles de organizaciones, y la utilizó para exfiltrar variables de entorno, incluyendo credenciales y tokens de API.

Codecov es un servicio de análisis de cobertura de código utilizado por equipos de desarrollo de software para realizar el seguimiento de la cobertura de las pruebas. El atacante modificó el script Bash Uploader que las organizaciones descargan y ejecutan como parte de sus procesos de compilación automatizados. Debido a que el script se ejecutaba dentro del entorno CI/CD, tenía acceso directo a variables de entorno que contenían credenciales, tokens y claves de acceso al repositorio.

El compromiso pasó desapercibido durante aproximadamente dos meses antes de que Codecov lo descubriera en abril de 2021. Entre las organizaciones afectadas se encontraban Twilio, HashiCorp y Confluent, quienes revelaron que se habían expuesto credenciales. El ataque demostró un vector de cadena de suministro específico de CI/CD: en lugar de comprometer el producto de software final, los atacantes se dirigieron a las herramientas que las organizaciones utilizan para crear y probar software. Este ataque se sitúa en la intersección entre el compromiso de la canalización de compilación (build pipeline) y el robo de credenciales, representando un patrón distinto de los vectores de distribución de actualizaciones utilizados en SolarWinds y CCleaner.

Ataque a la cadena de suministro de CCleaner (2017)

CCleaner (2017) — el grupo AXIOM, atribuido a ataques informáticos respaldados por el Estado chino, comprometió el entorno de compilación de Piriform (el desarrollador de CCleaner) e insertó el malware Floxif en el instalador legítimo de CCleaner distribuido a través de canales oficiales.

CCleaner es una popular utilidad de optimización de PC con millones de usuarios particulares y empresariales. El ataque demostró que los compromisos en la cadena de suministro no se limitan al software empresarial. Aproximadamente 2,27 millones de usuarios descargaron la versión troyanizada antes de que se detectara el compromiso.

El ataque tuvo una segunda fase: se preconfiguró una carga útil dirigida para activarse únicamente en sistemas pertenecientes a aproximadamente 40 empresas de alta tecnología, entre ellas Cisco, Intel, Samsung y Sony. Para la gran mayoría de los usuarios afectados, el malware recopiló datos de forma pasiva. Para las empresas tecnológicas que eran el objetivo, representó una grave intrusión en redes sensibles. El análisis de Cisco Talos de la infraestructura de mando y control de CCleaner proporcionó el primer desglose técnico completo del ataque.

ASUS ShadowHammer (2019)

El grupo BARIUM, atribuido a ciberataques patrocinados por el estado chino, comprometió la utilidad Live Update de ASUS y distribuyó una versión con puerta trasera, firmada con certificados digitales legítimos de ASUS, a través de servidores de actualización oficiales de ASUS.

Este ataque demostró una implicación significativa para la confianza digital: los certificados legítimos de firma de código no pueden ser fiables como prueba de integridad del software si la propia infraestructura de firma ha sido comprometida. La actualización troyanizada de ASUS llevaba certificados válidos de ASUS y se distribuyó a través del mecanismo de actualización oficial de ASUS, pasando cada verificación estándar. Aproximadamente 500.000 usuarios de ASUS recibieron la actualización con puerta trasera.

Los atacantes no estaban interesados en los 500.000 usuarios. La carga útil maliciosa estaba preconfigurada para activarse únicamente en sistemas con aproximadamente 600 direcciones MAC específicas, lo que indica inteligencia previa sobre los objetivos concretos. La campaña fue descubierta y documentada por el equipo de investigación de Kaspersky (Securelist) en 2019.

Los ataques a la cadena de suministro de hardware y firmware plantean una preocupación particular: las modificaciones realizadas a nivel de firmware persisten tras reinstalaciones del sistema operativo y permanecen invisibles para las herramientas de seguridad basadas en software.

Ataque a la cadena de suministro de 3CX (2023)

3CX (2023) — El Grupo Lazarus, atribuido a la Oficina General de Reconocimiento (RGB) de Corea del Norte, ejecutó el primer ataque de cadena de suministro sobre cadena de suministro confirmado públicamente, alcanzando el entorno de compilación de 3CX a través de un compromiso previo en la cadena de suministro del software de Trading Technologies.

El ordenador personal de un empleado de 3CX se vio comprometido a través de un instalador troyanizado para Trading Technologies X_TRADER, una plataforma de trading financiero. Ese instalador de Trading Technologies ya había sido comprometido en su cadena de suministro por Lazarus Group en una operación anterior. El equipo comprometido del empleado dio a los atacantes acceso al entorno de compilación de 3CX, que utilizaron para insertar malware en la 3CX Desktop App, una plataforma de comunicaciones VoIP utilizada por más de 600.000 empresas y 12 millones de usuarios diarios en todo el mundo.

El ataque se dirigió de forma desproporcionada a empresas del sector financiero. Dado que el compromiso de 3CX fue en sí mismo la consecuencia posterior de un ataque previo a la cadena de suministro, este es el primer caso confirmado de un ataque a la cadena de suministro que desencadena un segundo ataque a la cadena de suministro. La implicación práctica: las organizaciones ahora deben considerar no solo si sus proveedores directos son seguros, sino también si los proveedores de sus proveedores han sido comprometidos. El desglose técnico completo está documentado en análisis del incidente de Mandiant.)

Puerta trasera de XZ Utils (2024)

XZ Utils (2024) — operando bajo la identidad fabricada «Jia Tan», en lo que los investigadores de seguridad evalúan como una operación de un estado nación basada en indicadores de comportamiento, y sin atribución pública definitiva confirmada, un actor desconocido pasó aproximadamente dos años infiltrándose en el proyecto de código abierto XZ Utils antes de insertar una puerta trasera (backdoor) dirigida a la autenticación SSH en sistemas Linux.

XZ Utils es una biblioteca de compresión de datos que funciona como infraestructura invisible en millones de servidores Linux. No es una aplicación orientada al usuario, sino el tipo de software fundamental del que otros programas dependen silenciosamente. Un atacante que operaba como «Jia Tan» comenzó a contribuir código legítimo y de alta calidad al proyecto XZ Utils en 2022, ganando credibilidad y obteniendo finalmente privilegios de commit mediante una participación sostenida con el mantenedor del proyecto.

A principios de 2024, «Jia Tan» introdujo una puerta trasera en las versiones 5.6.0 y 5.6.1 de XZ Utils. La puerta trasera fue diseñada para comprometer la autenticación SSH en las distribuciones de Linux afectadas, lo que podría haber permitido al atacante acceso remoto a cualquier servidor que ejecutase la versión afectada de la biblioteca. El SSH es el principal protocolo de administración remota para servidores Linux en todo el mundo, por lo que el alcance potencial del impacto era considerable.

La puerta trasera fue detectada antes de su despliegue masivo por Andres Freund, un ingeniero de Microsoft que notó un consumo inusual de la CPU y una degradación del rendimiento de SSH durante su trabajo rutinario y rastreó el origen. Su descubrimiento, publicado en marzo de 2024, evitó un compromiso de la cadena de suministro que podría haber afectado a millones de servidores. El aviso de la OpenSSF (CVE-2024-3094) proporciona el informe técnico completo.

Por qué los ataques a la cadena de suministro son tan peligrosos

Los ataques a la cadena de suministro son difíciles de detectar y detener porque aprovechan la confianza que las organizaciones depositan en sus proveedores de software, en lugar de vulnerabilidades en los propios sistemas de las organizaciones. Cuatro factores agravan el desafío de la detección.

El software malicioso llega de una fuente de confianza: un proveedor cuyos certificados, dominios e infraestructura de actualización la organización objetivo ya ha autorizado. Las actualizaciones troyanizadas a menudo llevan certificados de firma de código digital válidos emitidos al proveedor legítimo, por lo que la verificación del certificado se realiza correctamente. Las herramientas antivirus y de detección de puntos finales pueden no marcar el software firmado por un proveedor de confianza y entregado a través de canales oficiales. Los atacantes sofisticados también retrasan deliberadamente las operaciones activas después del acceso inicial para evitar activar la detección de anomalías. APT29 operó dentro de las redes comprometidas por SolarWinds durante aproximadamente nueve meses antes de su detección, un tiempo de permanencia que ilustra cuánto tiempo puede prolongarse la brecha entre el compromiso y el descubrimiento.

Los ataques a la cadena de suministro han aumentado en frecuencia y sofisticación a lo largo de la última década. Los informes sobre el panorama de amenazas de ENISA documentan una tendencia ascendente sostenida, identificando los ataques a la cadena de suministro como una categoría de amenaza de primer nivel para los sectores de infraestructuras críticas. Esta escalada es visible en el registro histórico: el compromiso de CCleaner de 2017 afectó a 2,27 millones de usuarios particulares; la operación SolarWinds de 2020 comprometió a más de 100 agencias gubernamentales de EE. UU.; el incidente evitado de XZ Utils de 2024 tuvo como objetivo la infraestructura central de Linux utilizada por millones de servidores a nivel mundial. La ambición de los ataques ha crecido sustancialmente con cada ciclo.

Las consecuencias financieras se corresponden con esa escala. NotPetya causó daños globales estimados en 10.000 millones de dólares, y Maersk por sí sola informó de aproximadamente 300 millones de dólares. El ataque de Kaseya generó una demanda de rescate de 70 millones de dólares entre 1.500 empresas afectadas. La respuesta del gobierno de EE. UU. al caso SolarWinds costó cientos de millones en remediación e inversión en seguridad mejorada. Organizaciones gubernamentales y del sector público (SolarWinds), empresas de servicios financieros (3CX), empresas tecnológicas (objetivos de segunda fase de CCleaner) y operadores de infraestructuras críticas en los sectores prioritarios designados por CISA han sido objeto de ataques. Ninguna industria que dependa de software o servicios de gestión de terceros ha quedado fuera del alcance.

--- ## Quiénes Realizan Ataques a la Cadena de Suministro

Los ataques a la cadena de suministro son llevados a cabo por dos categorías distintas de actores de amenazas: grupos de amenazas persistentes avanzadas (APT) de estados-nación y organizaciones criminales con motivaciones financieras.

Una Amenaza Persistente Avanzada (APT) se refiere a un actor de amenazas sofisticado y con amplios recursos, generalmente una agencia de inteligencia estatal o una unidad cibernética militar, que lleva a cabo campañas de intrusión dirigidas a Largo plazo con objetivos estratégicos específicos. Las APT prefieren los ataques a la cadena de suministro porque un único compromiso ascendente proporciona acceso simultáneo a cientos o miles de objetivos de alto valor, maximizando el rendimiento de inteligencia de una sola operación y minimizando el riesgo de detección. La atribución de la actividad de las APT es probabilística y se basa en indicadores forenses que incluyen coincidencias de código, patrones de infraestructura y tiempos operativos, en lugar de pruebas directas.

Los grupos de estados-nación atribuidos a ataques documentados a la cadena de suministro incluyen: APT29 (Cozy Bear), atribuido al Servicio de Inteligencia Exterior de Rusia (SVR), que llevó a cabo la operación SolarWinds; Sandworm, atribuido a la inteligencia militar de Rusia (GRU), que llevó a cabo NotPetya a través de M.E.Doc; Grupo Lazarus, atribuido a la Oficina General de Reconocimiento de Corea del Norte, que llevó a cabo el ataque a 3CX; el grupo BARIUM, atribuido a operaciones patrocinadas por el estado chino, que llevó a cabo ASUS ShadowHammer; y el grupo AXIOM, también atribuido a operaciones patrocinadas por el estado chino, que llevó a cabo el ataque a CCleaner. BARIUM y AXIOM son grupos distintos a pesar de tener ambos atribución china.

No todos los ataques a la cadena de suministro son operaciones de estados-nación. El ataque a Kaseya VSA fue llevado a cabo por REvil, una organización de cibercrimen de habla rusa que opera bajo un modelo de ransomware como servicio, sin afiliación a ningún estado-nación. Los grupos criminales con motivaciones financieras han adoptado técnicas de cadena de suministro porque comprometer a un único MSP permite distribuir ransomware a cientos de organizaciones cliente en una sola operación, aumentando drásticamente el retorno en comparación con el ataque a víctimas individuales.

Cómo defenderse de los ataques a la cadena de suministro

La defensa contra los ataques a la cadena de suministro requiere ampliar su programa de seguridad más allá de sus propios sistemas para cubrir a los proveedores, los componentes de software y la infraestructura de los que depende su organización. El objetivo no es construir un perímetro perfecto, sino reducir el radio de impacto cuando un proveedor de confianza se ve comprometido.

Lista de comprobación de defensa empresarial y organizativa

• Implemente una política de Lista de materiales de software (SBOM) para todo el software que su organización adquiera o desarrolle, de modo que pueda identificar los componentes afectados cuando se divulgue un compromiso en la cadena de suministro
• Audite las prácticas de seguridad de los proveedores Tercero antes de la adquisición y de forma anual, utilizando cuestionarios estandarizados alineados con la norma NIST SP 800-161r1
• Exija a los proveedores que proporcionen SBOM actualizados para todos los productos de software que entren en su entorno, como parte de su proceso de adquisición y contratación
• Aplique los principios de la arquitectura Zero Trust: imponga el acceso con privilegios mínimos para todo el software y los servicios, implemente la microsegmentación de red para contener el movimiento lateral y realice verificaciones continuas en lugar de confiar en la ubicación de la red
• Supervise comportamientos anómalos en el software de proveedores de confianza, ya que las desviaciones de comportamiento con respecto a las líneas de base conocidas pueden indicar una actualización comprometida incluso cuando las firmas sean válidas
• Revise las certificaciones de seguridad de los proveedores (SOC 2 Tipo II, ISO 27001) e incluya requisitos de seguridad explícitos y obligaciones de notificación de brechas en los contratos con los proveedores
• Siga la guía de seguridad de la cadena de suministro de la CISA) e implemente el marco NIST SP 800-161r1 (C-SCRM) para extender su gestión de riesgos a los proveedores Tercero
• Mantenga un plan de respuesta a incidentes que cubra explícitamente los compromisos de software de Tercero, incluidos los procedimientos para el aislamiento de emergencia del software afectado en todo su entorno

¿Qué es una Lista de materiales de software (SBOM)?

Una Lista de Materiales de Software (SBOM, por sus siglas en inglés) es un inventario legible por máquina de todos los componentes, bibliotecas y dependencias incluidos en un producto de software. La analogía funcional es la de una etiqueta nutricional para el software: mientras que una etiqueta nutricional enumera los ingredientes y sus cantidades, una SBOM detalla cada biblioteca de código abierto, componente de un Tercero y dependencia directa que formó parte de la creación de una aplicación, junto con los números de versión y la información de las licencias.

Un SBOM es importante para la seguridad de la cadena de suministro porque responde a la pregunta que a las organizaciones les cuesta responder durante un incidente: "¿Estamos afectados?" Cuando se reveló el incidente de SolarWinds, las organizaciones sin un inventario de software tuvieron que auditar manualmente cada sistema para determinar si ejecutaban Orion. Las organizaciones con SBOMs actuales pudieron consultar su inventario directamente. La misma lógica se aplicó durante el casi incidente de XZ Utils: saber qué servidores ejecutaban qué versión de la biblioteca marcó la diferencia entre horas de tiempo de respuesta y semanas de incertidumbre.

Orden Ejecutiva 14028 sobre la Mejora de la Ciberseguridad Nacional (firmada en mayo de 2021, como respuesta directa al ataque de SolarWinds) exigió que los proveedores de software que venden al gobierno federal de EE. UU. proporcionaran SBOM. La CISA ha publicado una guía de implementación de SBOM tanto para productores como para consumidores. Herramientas como SPDX, CycloneDX y Syft pueden generar SBOMs automáticamente a partir de la mayoría de las bases de código e imágenes de contenedores.

Arquitectura de Confianza Cero y Defensa de la Cadena de Suministro

La arquitectura de confianza cero reduce el daño que puede causar un ataque a la cadena de suministro al aplicar el principio de "nunca confíes, verifica siempre" a cada solicitud de acceso, incluidas las solicitudes de software que parezca provenir de proveedores de confianza. Los ataques a la cadena de suministro tienen éxito específicamente al explotar la confianza implícita. La confianza cero elimina esa confianza implícita de la ecuación.

Los tres controles más directamente relevantes para la defensa de la cadena de suministro son: el acceso con privilegios mínimos (que limita lo que cualquier software comprometido puede alcanzar dentro de su red, de modo que una actualización con puerta trasera no pueda acceder a sistemas fuera de su ámbito legítimo); la microsegmentación de red (que contiene el movimiento lateral para que un atacante que obtenga un punto de apoyo inicial no pueda propagarse libremente); y la monitorización continua del comportamiento (que detecta actividad anómala de software de confianza incluso cuando la entrada inicial eludió la detección basada en firmas).

Zero trust es una filosofía de seguridad y un modelo de arquitectura, no un producto de software para comprar. Las principales referencias autoritativas son el Modelo de madurez de confianza cero de la CISA y NIST SP 800-207.

Lista de comprobación de defensa para desarrolladores y DevOps

Los desarrolladores e ingenieros de DevOps tienen control directo sobre las superficies de ataque que son el objetivo más común en los ataques a la cadena de suministro de código abierto. Estas acciones reducen la exposición de tu pipeline:

• Fijar y bloquear las versiones de las dependencias en todos los manifiestos de paquetes (package-lock.json, requirements.txt, Gemfile.lock) para que una versión maliciosa recién publicada no pueda ser extraída automáticamente en la próxima compilación
• Configurar su sistema de compilación para que prefiera los registros privados sobre los públicos y reservar todos los espacios de nombres de paquetes internos en los registros públicos para prevenir ataques de confusión de dependencias
• Ejecutar escaneo automatizado de dependencias en cada compilación usando herramientas como Dependabot, OWASP Dependency-Check o Snyk para marcar paquetes conocidos como vulnerables o sospechosos antes de que lleguen a producción
• Generar un SBOM para cada lanzamiento usando CycloneDX o Syft, y almacenarlo junto con sus artefactos de compilación para tener un inventario auditable de componentes para cada versión desplegada
• Requerir commits firmados y aplicar reglas de protección de ramas en su canal principal de compilación para prevenir que código no autorizado ingrese al proceso de compilación
• Auditar los paquetes de terceros antes de añadirlos: comprobar el historial de publicaciones del mantenedor, el número de descargas, la actividad del repositorio y si el paquete ha sido transferido recientemente a un nuevo propietario

Seguridad de la cadena de suministro: requisitos normativos y de cumplimiento

Varios marcos regulatorios importantes exigen ahora explícitamente que las organizaciones aborden los riesgos de seguridad de la cadena de suministro como parte de sus obligaciones de ciberseguridad. Estos requisitos pasaron de ser una recomendación a una obligación en gran medida como resultado del ataque a SolarWinds.

Marco Regulatorio de EE. UU.

En Estados Unidos, el principal desencadenante normativo fue la Orden Ejecutiva 14028 sobre la Mejora de la Ciberseguridad Nacional, firmada por el presidente Biden el 12 de mayo de 2021, como respuesta directa al ataque de SolarWinds y al incidente de Kaseya VSA. La EO 14028 ordenó que los proveedores de software que venden al gobierno federal de EE. UU. deben proporcionar una Lista de Materiales de Software (SBOM) para sus productos. Encomendó al NIST el desarrollo de directrices sobre la seguridad de la cadena de suministro y al CISA la implementación de los estándares SBOM. Este mandato se aplica a los proveedores que abastecen al gobierno federal. No exige directamente las SBOM a todas las organizaciones del sector privado, aunque los estándares que generó se han adoptado ampliamente como requisitos de adquisición en contextos empresariales.

La referencia principal de estándares técnicos es NIST SP 800-161r1 ("Prácticas de Gestión de Riesgos de la Cadena de Suministro de Ciberseguridad para Sistemas y Organizaciones"), que extiende los marcos estándar de gestión de riesgos de ciberseguridad para cubrir explícitamente a proveedores terceros, vendedores y componentes de software. La C-SCRM (Gestión de Riesgos de la Cadena de Suministro de Ciberseguridad) según NIST SP 800-161r1 exige a las organizaciones realizar evaluaciones de riesgo de proveedores, verificar la procedencia del software, exigir SBOMs en la adquisición y mantener planes de respuesta a incidentes que tengan en cuenta los compromisos de terceros. La publicación de CISA "Defending Against Software Supply Chain Attacks" proporciona orientación práctica para la implementación alineada con los requisitos de la EO 14028.

Marco Regulatorio de la UE

Las organizaciones europeas se enfrentan a requisitos paralelos en el marco de dos directivas. La Directiva NIS2 (Directiva sobre seguridad de redes y sistemas de información 2) exige a las organizaciones de sectores críticos, como la energía, el transporte, la sanidad y la infraestructura digital, que aborden los riesgos de seguridad en la cadena de suministro como parte de sus obligaciones obligatorias de gestión de riesgos de ciberseguridad. La DORA (Reglamento sobre resiliencia operativa digital) se aplica a las entidades del sector financiero en la UE e incluye requisitos detallados para la gestión del riesgo de los proveedores de servicios TIC de Terceros, abordando directamente los vectores de ataque de la cadena de suministro. La ENISA (Agencia de la Unión Europea para la Ciberseguridad) sirve como la principal fuente autorizada para las organizaciones de la UE, desempeñando el papel equivalente al de la CISA en Estados Unidos.

Resumen de Referencia Regulatoria

Preguntas Frecuentes Sobre Ataques a la Cadena de Suministro

¿Qué es un ataque a la cadena de suministro?

Un ataque a la cadena de suministro ataca a una organización indirectamente al comprometer a un proveedor de tercero de confianza, un componente de software o un elemento de hardware. Los atacantes insertan código malicioso en etapas anteriores para que las víctimas introduzcan la amenaza sin saberlo a través de actualizaciones de software rutinarias o la adquisición de hardware. No se requiere ninguna vulnerabilidad en los propios sistemas de la víctima. El ataque tiene éxito porque llega a través de un canal que la víctima ya ha autorizado.

¿Cuáles son ejemplos de ataques a la cadena de suministro?

Los ejemplos más significativos de ataques a la cadena de suministro de 2013 a 2024:

• SolarWinds (2020): se insertó la puerta trasera SUNBURST en las actualizaciones de la Plataforma Orion; afectó a aproximadamente 18.000 clientes, incluyendo más de 100 agencias gubernamentales de EE. UU.
• NotPetya (2017): malware de tipo wiper destructivo distribuido a través de las actualizaciones del software de contabilidad M.E.Doc; causó unos daños globales estimados en 10.000 millones de dólares
• Kaseya VSA (2021): REvil utilizó un día cero de VSA para distribuir ransomware a más de 1.500 empresas a través de MSP comprometidos
• XZ Utils (2024): una campaña de ingeniería social de dos años de duración estuvo a punto de insertar una puerta trasera SSH en la infraestructura de Linux a nivel mundial
• CCleaner (2017): el malware Floxif llegó a 2,27 millones de usuarios; la segunda fase se dirigió a 40 importantes empresas tecnológicas
• ASUS ShadowHammer (2019): una actualización de firmware con una puerta trasera firmada con certificados válidos de ASUS llegó a 500.000 usuarios
• 3CX (2023): primer ataque confirmado de cadena de suministro sobre cadena de suministro; llegó a más de 600.000 empresas a través de Lazarus Group

¿Cómo funciona un ataque a la cadena de suministro?

Los ataques a la cadena de suministro siguen una secuencia repetible:

1. El atacante selecciona un proveedor o dependencia de software de confianza del que depende el objetivo
2. El atacante obtiene acceso al entorno de compilación, repositorio de código o infraestructura de actualización de dicho proveedor
3. Se inserta código malicioso en software legítimo antes de que se distribuya
4. El proveedor envía el producto comprometido a través de sus canales normales y de confianza
5. El objetivo instala la actualización, introduciendo la amenaza en su propio perímetro
6. El atacante activa el punto de apoyo para el espionaje, el robo de datos o cargas útiles destructivas

¿Cuál es el ataque a la cadena de suministro más famoso?

El ataque a SolarWinds (2020) es ampliamente considerado el ciberataque de cadena de suministro más importante de la historia. APT29, atribuido al servicio de inteligencia SVR de Rusia, insertó la puerta trasera (backdoor) SUNBURST en las actualizaciones de SolarWinds Orion, afectando a aproximadamente 18.000 clientes, entre ellos más de 100 agencias gubernamentales de EE. UU. La brecha pasó desapercibida durante aproximadamente nueve meses y desencadenó directamente la Orden Ejecutiva 14028 para Mejorar la Ciberseguridad de la Nación.

¿Por qué son tan peligrosos los ataques de cadena de suministro?

Los ataques a la cadena de suministro conllevan un riesgo compuesto por cuatro motivos. El software malicioso proviene de un proveedor en el que la organización ya confía, eludiendo las defensas perimetrales sin explotar ningún fallo en los sistemas propios del objetivo. Las actualizaciones troyanizadas llevan firmas digitales válidas, superando las comprobaciones de certificados. Es posible que las herramientas antivirus no marquen el software firmado y entregado por el proveedor. Los atacantes sofisticados permanecen inactivos tras el acceso inicial para evitar activar la detección de anomalías de comportamiento. La operación SolarWinds persistió sin ser detectada durante nueve meses. Un solo proveedor comprometido puede llegar a miles de organizaciones situadas más abajo en la cadena, escalando el impacto de una única intrusión mucho más allá de lo que suelen lograr los ataques directos.

¿Están aumentando los ataques a la cadena de suministro?

Los ataques a la cadena de suministro han aumentado en frecuencia y sofisticación a lo largo de la última década. Los informes anuales de ENISA sobre el panorama de amenazas documentan los ataques a la cadena de suministro como una categoría de amenaza sostenida y creciente, con un volumen de ataques que aumenta año tras año. La trayectoria es visible en los propios incidentes: desde la brecha de Target de 2013, posibilitada por un pequeño contratista de climatización (HVAC), hasta la campaña de espionaje de SolarWinds de 2020 que afectó al gobierno de EE. UU., hasta el casi incidente de XZ Utils de 2024, dirigido a la infraestructura central de Linux. Los grupos criminales con motivaciones financieras también han adoptado métodos de cadena de suministro, como demostró el ataque a Kaseya: una única plataforma de MSP comprometida llegó a cientos de organizaciones cliente en cuestión de horas.

¿Cómo pueden defenderse las organizaciones contra los ataques a la cadena de suministro?

Las organizaciones pueden reducir su exposición a los ataques a la cadena de suministro mediante estas acciones:

• Implementar una política de Lista de Materiales de Software (SBOM) para mantener un inventario completo de los componentes de software e identificar los sistemas afectados cuando se divulgue una vulnerabilidad
• Exigir a los proveedores que proporcionen SBOM y demuestren certificaciones de seguridad vigentes (SOC 2, ISO 27001) como condiciones de adquisición
• Aplicar los principios de la arquitectura Zero Trust: acceso de mínimo privilegio, microsegmentación de red y supervisión continua del comportamiento
• Supervisar el software de proveedores de confianza para detectar anomalías de comportamiento, no solo indicadores basados en firmas
• Seguir la guía de seguridad de la cadena de suministro de la CISA y alinear los procesos de evaluación de riesgos de proveedores con la norma NIST SP 800-161r1 (C-SCRM)
• Mantener un plan de respuesta a incidentes que cubra explícitamente los compromisos de software de un Tercero

Notas de publicación: (1) Implementar el esquema de datos estructurados FAQPage en la sección de Preguntas Frecuentes y el esquema Article en la página completa, para maximizar la elegibilidad para las funcionalidades 'People Also Ask' y los resultados enriquecidos. (2) Las citas externas en este artículo enlazan a CISA, NIST, Mandiant, Kaspersky/Securelist, Wired, OpenSSF y Cisco Talos como fuentes autorizadas. (3) Los enlaces internos a contenido relacionado sobre ciberseguridad en este sitio (guías de ataques de ransomware, explicaciones de arquitectura de confianza cero, recursos de implementación de SBOM, guías de gestión de riesgos de proveedores, resúmenes de actores de amenazas APT) deben ser añadidos por el equipo de publicación antes del despliegue.