{"id":31975,"date":"2026-04-07T08:00:18","date_gmt":"2026-04-07T06:00:18","guid":{"rendered":"https:\/\/www.kaspersky.es\/blog\/?p=31975"},"modified":"2026-04-07T11:56:28","modified_gmt":"2026-04-07T09:56:28","slug":"supply-chain-attacks-in-2025","status":"publish","type":"post","link":"https:\/\/www.kaspersky.es\/blog\/supply-chain-attacks-in-2025\/31975\/","title":{"rendered":"Los ataques a la cadena de suministro m\u00e1s notables de 2025"},"content":{"rendered":"<p>Los ataques a la cadena de suministro han sido una de las categor\u00edas m\u00e1s peligrosas de incidentes de ciberseguridad <a href=\"https:\/\/www.kaspersky.com\/blog\/supply-chain-attacks-in-2024\/52965\/\" target=\"_blank\" rel=\"noopener nofollow\">durante a\u00f1os<\/a>. Y si el 2025 nos ha ense\u00f1ado algo, es que los ciberdelincuentes los est\u00e1n llevando al siguiente nivel. En este an\u00e1lisis en profundidad, examinamos los ataques a la cadena de suministro ocurridos en 2025 que, aunque no siempre fueron los m\u00e1s costosos, sin duda fueron los m\u00e1s inusuales y llamaron la atenci\u00f3n del sector.<\/p>\n<h2>Enero de 2025: se encuentra un RAT en el repositorio de GitHub de DogWifTools<\/h2>\n<p>Como \u201cprecalentamiento\u201d despu\u00e9s de las fiestas, los ciberdelincuentes colocaron sistem\u00e1ticamente varias versiones de DogWifTools en <a href=\"https:\/\/www.bleepingcomputer.com\/news\/security\/solana-pumpfun-tool-dogwiftool-compromised-to-drain-wallets\/\" target=\"_blank\" rel=\"noopener nofollow\">puertas traseras<\/a>. Esta es una utilidad dise\u00f1ada para lanzar y promover <a href=\"https:\/\/es.wikipedia.org\/wiki\/Moneda_meme\" target=\"_blank\" rel=\"noopener nofollow\">monedas meme<\/a> basadas en Solana en Pump.fun. Despu\u00e9s de vulnerar el repositorio privado de GitHub para DogWifTools, los atacantes esperaron a que los desarrolladores cargaran una compilaci\u00f3n nueva, le inyectaron un RAT y luego cambiaron el programa leg\u00edtimo por su versi\u00f3n maliciosa solo unas horas m\u00e1s tarde. Seg\u00fan los desarrolladores, los actores de la amenaza lograron insertar troyanos en las versiones\u00a01.6.3 a 1.6.6 de DogWifTools para Windows.<\/p>\n<p>La fase culminante se desencaden\u00f3 a finales de enero. Despu\u00e9s de usar el RAT para recolectar una cantidad masiva de datos de dispositivos infectados, los atacantes vaciaron las carteras de criptomonedas de sus v\u00edctimas. Si bien las v\u00edctimas estiman que el bot\u00edn total super\u00f3 los 10 millones de d\u00f3lares en criptomonedas, los propios atacantes <a href=\"https:\/\/x.com\/JizzyGroup\/status\/1884395542072959208\" target=\"_blank\" rel=\"noopener nofollow\">han rebatido<\/a>\u00a0esa cifra, aunque no llegaron a revelar exactamente cu\u00e1nto se hab\u00edan llevado en realidad.<\/p>\n<h2>Febrero de 2025: el atraco de Bybit por 1500\u00a0millones de d\u00f3lares<\/h2>\n<p>Si enero fue un precalentamiento, febrero fue un colapso total. El <a href=\"https:\/\/www.kaspersky.es\/blog\/bybit-hack-lessons-how-to-do-self-custody-properly\/30815\/\" target=\"_blank\" rel=\"noopener\">hackeo del cambio de criptomonedas de Bybit<\/a> eclips\u00f3 por completo los incidentes anteriores, convirti\u00e9ndose en el atraco de criptomonedas m\u00e1s grande de la historia. Los atacantes lograron vulnerar el software Safe{Wallet}, la soluci\u00f3n de almacenamiento en fr\u00edo de m\u00faltiples firmas en la que se basaba el cambio para administrar sus activos.<\/p>\n<p>Los empleados de Bybit pensaron que estaban firmando una transacci\u00f3n rutinaria; en realidad, estaban autorizando un contrato inteligente malicioso. Una vez ejecutado, vaci\u00f3 una cartera fr\u00eda principal y dispers\u00f3 los fondos entre varios cientos de direcciones controladas por el atacante. El bot\u00edn final super\u00f3 los 400 000 ETH\/stETH, con un asombroso valor total de aproximadamente\u2026 \u00a11500 millones de d\u00f3lares!<\/p>\n<h2>Marzo de 2025: Coinbase fue el objetivo de una vulneraci\u00f3n en cascada de GitHub\u00a0Actions<\/h2>\n<p>La primavera de 2025 comenz\u00f3 con un ataque sofisticado en el cual se <a href=\"https:\/\/www.kaspersky.com\/blog\/malicious-github-action-changed-files\/53179\/\" target=\"_blank\" rel=\"noopener nofollow\">vulneraron m\u00faltiples GitHub\u00a0Actions<\/a> (los patrones de flujo de trabajo utilizados para automatizar las tareas est\u00e1ndar de DevOps) como su mecanismo de entrega principal. Todo comenz\u00f3 con el atraco de un token de acceso personal que pertenec\u00eda a un encargado del mantenimiento de la herramienta de an\u00e1lisis de SpotBugs. Mediante este punto de apoyo, los atacantes publicaron un proceso malicioso y lograron secuestrar un token de un encargado del mantenimiento del flujo de trabajo de reviewdog\/action-setup, que tambi\u00e9n estuvo involucrado en el proyecto.<\/p>\n<p>A partir de ah\u00ed, vulneraron una dependencia, el flujo de trabajo tj-actions\/changed-files, y lo modificaron para ejecutar un script de Python malicioso. Este script se dise\u00f1\u00f3 para buscar secretos de alto valor, como claves de AWS, Azure y Google\u00a0Cloud, tokens de GitHub y NPM, credenciales de base de datos y claves privadas RSA. Curiosamente, el script redact\u00f3 todo lo que encontr\u00f3 directo en registros de compilaci\u00f3n de acceso p\u00fablico. Esto signific\u00f3 que los datos filtrados no solo estaban disponibles para los atacantes, sino para cualquier persona lo suficientemente inteligente como para mirar.<\/p>\n<p>El objetivo original de esta operaci\u00f3n era un repositorio perteneciente al cambio de criptomonedas de Coinbase. Afortunadamente, los desarrolladores detectaron la amenaza a tiempo y evitaron la vulneraci\u00f3n. Despu\u00e9s de darse cuenta de que estaban a punto de perder el control de los flujos de procesos tj-actions\/changed-files, los atacantes tomaron un enfoque de ataque indiscriminado. Esto puso a 23 000 repositorios en riesgo de filtraci\u00f3n de secretos. Al final, se expusieron las credenciales confidenciales de <a href=\"https:\/\/thehackernews.com\/2025\/03\/github-supply-chain-breach-coinbase.html\" target=\"_blank\" rel=\"noopener nofollow\">varios cientos<\/a> de esos repositorios al p\u00fablico.<\/p>\n<h2>Abril de 2025: una puerta trasera en 21\u00a0extensiones de Magento<\/h2>\n<p>En abril, se <a href=\"https:\/\/www.bleepingcomputer.com\/news\/security\/magento-supply-chain-attack-compromises-hundreds-of-e-stores\/\" target=\"_blank\" rel=\"noopener nofollow\">descubri\u00f3<\/a> una infecci\u00f3n en toda una variedad de extensiones para Magento, una de las plataformas m\u00e1s populares para crear tiendas en l\u00ednea. La puerta trasera se integr\u00f3 en 21\u00a0m\u00f3dulos desarrollados por tres proveedores: Tigren, Meetanshi y MGS. Estas extensiones formaban parte de la infraestructura de varios cientos de empresas de comercio electr\u00f3nico, incluida al menos una corporaci\u00f3n multinacional.<\/p>\n<p>Seg\u00fan los investigadores que lo descubrieron, la puerta trasera en realidad se plant\u00f3 en 2019. En abril de 2025, los atacantes finalmente la activaron para vulnerar sitios web y cargar shells web. Esto se logr\u00f3 a trav\u00e9s de una funci\u00f3n incrustada en las extensiones que ejecutaba c\u00f3digo arbitrario extra\u00eddo de un archivo de licencia.<\/p>\n<p>Ir\u00f3nicamente, los m\u00f3dulos infectados inclu\u00edan MGS GDPR y Meetanshi CookieNotice. Como sugieren los nombres, estas extensiones fueron dise\u00f1adas para ayudar a los sitios a cumplir con las regulaciones de privacidad del usuario y procesamiento de datos. Al final, en lugar de garantizar la privacidad, lo m\u00e1s probable es que su uso haya dado lugar al robo de datos de los usuarios y activos financieros a trav\u00e9s del <a href=\"https:\/\/www.kaspersky.es\/blog\/illicit-code-on-legitimate-sites\/28976\/\" target=\"_blank\" rel=\"noopener\">web skimming<\/a>.<\/p>\n<h2>Mayo de 2025: ransomware distribuido a trav\u00e9s de un proveedor de servicios gestionados vulnerado<\/h2>\n<p>En mayo, los actores de ransomware de la banda DragonForce <a href=\"https:\/\/www.theregister.com\/2025\/05\/28\/dragonforce_ransomware_gang_sets_fire\/\" target=\"_blank\" rel=\"noopener nofollow\">obtuvieron acceso<\/a> a la infraestructura de un proveedor de servicios gestionados (MSP) no identificado y lo usaron para distribuir su ransomware y robar datos de las organizaciones cliente del MSP.<\/p>\n<p>Al parecer, los atacantes aprovecharon varias vulnerabilidades (incluida un fallo cr\u00edtico) en SimpleHelp, la herramienta de supervisi\u00f3n y gesti\u00f3n remota utilizada por el MSP. Estas vulnerabilidades se descubrieron en 2024 y se dieron a conocer p\u00fablicamente y se parchearon <a href=\"https:\/\/thehackernews.com\/2025\/01\/critical-simplehelp-flaws-allow-file.html\" target=\"_blank\" rel=\"noopener nofollow\">en enero de 2025<\/a>. Por desgracia, parece que el MSP decidi\u00f3 no acelerar el proceso de actualizaci\u00f3n, un retraso que la banda de ransomware no dud\u00f3 en aprovechar.<\/p>\n<h2>Junio de 2025: una puerta trasera en m\u00e1s de una docena de paquetes de npm populares<\/h2>\n<p>A principios del verano, los atacantes hackearon la cuenta de uno de los encargados del mantenimiento de la biblioteca de Gluestack y usaron un token de acceso robado para <a href=\"https:\/\/www.bleepingcomputer.com\/news\/security\/supply-chain-attack-hits-gluestack-npm-packages-with-960k-weekly-downloads\/\" target=\"_blank\" rel=\"noopener nofollow\">inyectar puertas traseras en 17\u00a0paquetes de npm<\/a>. El m\u00e1s popular de estos paquetes, @react-native-aria\/interactions, tuvo 125 000 descargas semanales, mientras que todos los paquetes vulnerados combinados sumaron m\u00e1s de un mill\u00f3n.<\/p>\n<p>Lo que es particularmente interesante en este caso son los pasos que <a href=\"https:\/\/github.com\/gluestack\/gluestack-ui\/issues\/2894#issuecomment-2955003750\" target=\"_blank\" rel=\"noopener nofollow\">tomaron los desarrolladores de Gluestack despu\u00e9s del incidente<\/a>: primero, restringieron el acceso al repositorio de GitHub para los colaboradores secundarios; en segundo lugar, activaron la autenticaci\u00f3n de dos factores (2FA) para publicar nuevas versiones; y en tercer lugar, prometieron implementar pr\u00e1cticas de desarrollo seguras como el flujo de trabajo basado en solicitudes de extracci\u00f3n, revisiones sistem\u00e1ticas de c\u00f3digo, registros de auditor\u00eda, etc. En otras palabras, antes del incidente, un proyecto con cientos de miles de descargas semanales no contaba con dichas medidas.<\/p>\n<h2>Julio de 2025: paquetes de npm populares infectados a trav\u00e9s de un ataque de phishing<\/h2>\n<p>En julio, <a href=\"https:\/\/www.theregister.com\/2025\/07\/24\/not_pretty_not_windowsonly_npm\/\" target=\"_blank\" rel=\"noopener nofollow\">los paquetes de npm volvieron a ser<\/a> las estrellas del espect\u00e1culo, incluido el paquete \u201cis\u201d, de nombre corto pero ampliamente utilizado, que cuenta con 2,7\u00a0millones de descargas semanales. Esta biblioteca de utilidades de JavaScript proporciona una amplia gama de funciones de verificaci\u00f3n de tipo y validaci\u00f3n de valores. Para llevar a cabo un ataque de phishing contra uno de los propietarios del proyecto, los atacantes utilizaron con \u00e9xito el truco m\u00e1s antiguo del libro: <a href=\"https:\/\/encyclopedia.kaspersky.com\/glossary\/typosquatting\/\" target=\"_blank\" rel=\"noopener\">typosquatting<\/a> (usaron el dominio npnjs.com en lugar de npmjs.com) y un clon del sitio web oficial de npm.<\/p>\n<p>Luego usaron la cuenta vulnerada para publicar varias de sus propias versiones del paquete con una puerta trasera integrada. La infecci\u00f3n pas\u00f3 desapercibida durante seis horas: tiempo de sobra para que una gran cantidad de desarrolladores descargaran los paquetes de npm maliciosos.<\/p>\n<p>La misma t\u00e1ctica de phishing tambi\u00e9n se implement\u00f3 contra otros desarrolladores. Los atacantes aprovecharon varias cuentas de desarrollador vulneradas para distribuir <a href=\"https:\/\/www.bleepingcomputer.com\/news\/security\/popular-npm-linter-packages-hijacked-via-phishing-to-drop-malware\/\" target=\"_blank\" rel=\"noopener nofollow\">diferentes variantes de su carga maliciosa<\/a>. Tambi\u00e9n existe una firme sospecha de que pueden haber guardado parte de su bot\u00edn para futuros ataques.<\/p>\n<h2>Agosto de 2025: el ataque de s1ngularity y una filtraci\u00f3n de cientos de secretos de desarrolladores<\/h2>\n<p>A finales de agosto, <a href=\"https:\/\/www.kaspersky.com\/blog\/nx-build-s1ngularity-supply-chain-attack\/54223\/\" target=\"_blank\" rel=\"noopener nofollow\">un incidente denominado \u201cs1ngularity\u201d<\/a> continu\u00f3 la tendencia de apuntar a los desarrolladores de JavaScript. Los atacantes vulneraron Nx, un sistema de compilaci\u00f3n popular y una herramienta de optimizaci\u00f3n de procesos de CI\/CD. El c\u00f3digo malicioso inyectado en los paquetes busc\u00f3 en sistemas de desarrolladores infectados una amplia gama de datos confidenciales, como claves de carteras de criptomonedas, tokens de npm y GitHub, claves SSH, claves de API y m\u00e1s.<\/p>\n<p>Curiosamente, los atacantes utilizaron herramientas de inteligencia artificial instaladas localmente, como Claude\u00a0Code, Gemini\u00a0CLI y Amazon\u00a0Q, para detectar secretos en las m\u00e1quinas de las v\u00edctimas. Todo lo que encontraron se public\u00f3 en los repositorios p\u00fablicos de GitHub creados con los nombres de las v\u00edctimas, usando los t\u00edtulos \u201cs1ngularity-repository\u201d, \u201cs1ngularity-repository-0\u201d y \u201cs1ngularity-repository-1\u201d. Como habr\u00e1s adivinado, de ah\u00ed viene el nombre del ataque.<\/p>\n<p>En consecuencia, los datos privados de cientos de desarrolladores terminaron a la vista, al alcance no solo de los atacantes, sino de cualquier persona con conexi\u00f3n a Internet.<\/p>\n<h2>Septiembre de 2025: un ladr\u00f3n de criptomonedas vulnera paquetes de npm que tienen 2600\u00a0millones de descargas semanales<\/h2>\n<p>La tendencia de vulneraciones de paquetes de npm lleg\u00f3 hasta septiembre. Despu\u00e9s de una nueva campa\u00f1a de phishing dirigida a los desarrolladores de JavaScript, los atacantes lograron inyectar c\u00f3digo malicioso en unas pocas docenas de proyectos de alto perfil. Algunos de estos, espec\u00edficamente \u201cchalk\u201d y \u201cdebug\u201d, cuentan con <em>cientos de millones<\/em> de descargas semanales. En conjunto, los paquetes infectados acumulaban <a href=\"https:\/\/www.kaspersky.com\/blog\/npm-packages-trojanized\/54280\/\" target=\"_blank\" rel=\"noopener nofollow\">m\u00e1s de 2600\u00a0millones de descargas por semana<\/a> en el momento de la filtraci\u00f3n, y solo se han vuelto m\u00e1s populares desde entonces.<\/p>\n<p>La carga era un ladr\u00f3n de criptomonedas: malware dise\u00f1ado para interceptar transacciones de criptomonedas y redirigirlas a las carteras de los atacantes. Afortunadamente, a pesar de haber infectado con \u00e9xito algunos de los proyectos m\u00e1s populares del mundo, los atacantes de alguna manera lograron arruinar la etapa final de su operaci\u00f3n. Al final, se fueron con <a href=\"https:\/\/www.theregister.com\/2025\/09\/09\/npm_supply_chain_attack\/\" target=\"_blank\" rel=\"noopener nofollow\">unos miserables 925\u00a0d\u00f3lares<\/a>.<\/p>\n<p>Solo una semana despu\u00e9s, ocurri\u00f3 otro incidente importante: <a href=\"https:\/\/www.kaspersky.com\/blog\/tinycolor-shai-hulud-supply-chain-attack\/54315\/\" target=\"_blank\" rel=\"noopener nofollow\">la primera ola del malware Shai-Hulud de autopropagaci\u00f3n<\/a>, que infect\u00f3 alrededor de 150\u00a0paquetes de npm, incluidos proyectos de CrowdStrike. Sin embargo, la segunda ola, que golpe\u00f3 varios meses despu\u00e9s, result\u00f3 ser mucho m\u00e1s destructiva. Analizaremos Great Worm en mayor profundidad un poco m\u00e1s adelante.<\/p>\n<h2>Octubre de 2025: GlassWorm infecta el ecosistema de Visual Studio Code<\/h2>\n<p>Aproximadamente un mes despu\u00e9s del ataque de Shai-Hulud, <a href=\"https:\/\/thehackernews.com\/2025\/10\/self-spreading-glassworm-infects-vs.html\" target=\"_blank\" rel=\"noopener nofollow\">un malware de autopropagaci\u00f3n similar denominado GlassWorm<\/a> comenz\u00f3 a infectar las extensiones de Visual Studio Code tanto en el Registro Open VSX como en el Marketplace de extensiones de Microsoft. Los atacantes buscaban cuentas de GitHub, Git, npm y Open\u00a0VSX, as\u00ed como claves de carteras de criptomonedas.<\/p>\n<p>Los creadores de GlassWorm adoptaron un enfoque muy creativo para su infraestructura de comando y control: usaron una cartera de criptomonedas en la cadena de bloques (blockchain) de Solana como su C2 principal, con Google\u00a0Calendar como canal de comunicaci\u00f3n de respaldo.<\/p>\n<p>M\u00e1s all\u00e1 de simplemente vaciar las carteras de criptomonedas de las v\u00edctimas y secuestrar sus cuentas para propagar a\u00fan m\u00e1s el gusano, los atacantes tambi\u00e9n colocaron un RAT llamado Zombi en los dispositivos infectados, lo que les otorg\u00f3 un control total sobre los sistemas vulnerados.<\/p>\n<h2>Noviembre de 2025: la campa\u00f1a IndonesianFoods y 150\u00a0000\u00a0paquetes de spam en npm<\/h2>\n<p>En noviembre, <a href=\"https:\/\/www.kaspersky.com\/blog\/indonesianfoods-npm-spam-campaign\/55453\/\" target=\"_blank\" rel=\"noopener nofollow\">surgi\u00f3<\/a> una nueva molestia dentro del registro de npm. Los atacantes usaron una campa\u00f1a maliciosa coordinada denominada IndonesianFoods para inundar el registro con decenas de miles de paquetes in\u00fatiles.<\/p>\n<p>El objetivo principal aqu\u00ed era jugar con el sistema para inflar las m\u00e9tricas y los farm tokens en tea.xyz, una plataforma de cadena de bloques (blockchain) dise\u00f1ada para recompensar a los desarrolladores de c\u00f3digo abierto. Para lograrlo, los atacantes construyeron una red masiva de proyectos interdependientes con nombres que hacen referencia a la cocina indonesia, como zul-<a href=\"https:\/\/es.wikipedia.org\/wiki\/Tapai\" target=\"_blank\" rel=\"noopener nofollow\">tapai<\/a>9-kyuki o andi-<a href=\"https:\/\/es.wikipedia.org\/wiki\/Rendang\" target=\"_blank\" rel=\"noopener nofollow\">rendang<\/a>23-breki.<\/p>\n<p>Los creadores de esta campa\u00f1a no se molestaron en robar cuentas. Estrictamente hablando, los paquetes de spam ni siquiera conten\u00edan una carga maliciosa, a menos que cuentes un script dise\u00f1ado para generar de forma autom\u00e1tica nuevos paquetes cada siete segundos. Sin embargo, el incidente funcion\u00f3 como un claro recordatorio de lo vulnerable que es la infraestructura de npm a las campa\u00f1as de spam a gran escala.<\/p>\n<h2>Diciembre de 2025: Shai-Hulud\u00a02.0 y la filtraci\u00f3n de 400\u00a0000\u00a0secretos de desarrolladores<\/h2>\n<p>El principal protagonista del a\u00f1o, no solo para los ataques a la cadena de suministro, sino probablemente para todo el campo de la ciberseguridad, fue el malware autopropagado <a href=\"https:\/\/securelist.com\/shai-hulud-worm-infects-500-npm-packages-in-a-supply-chain-attack\/117547\/\" target=\"_blank\" rel=\"noopener\">Shai-Hulud<\/a> (tambi\u00e9n conocido como Sha1-Hulud) dirigido a desarrolladores.<\/p>\n<p>Este malware fue la evoluci\u00f3n l\u00f3gica del ataque de s1ngularity que mencionamos anteriormente: tambi\u00e9n rastrea los sistemas en busca de todo tipo de secretos y los publica en repositorios abiertos de GitHub. Sin embargo, Shai-Hulud a\u00f1adi\u00f3 un mecanismo de autopropagaci\u00f3n a esta l\u00ednea de base: el gusano infecta los proyectos controlados por desarrolladores ya vulnerados mediante el uso de sus credenciales robadas.<\/p>\n<p>La primera ola de Shai-Hulud ocurri\u00f3 en septiembre e infect\u00f3 varios cientos de paquetes de npm. Pero, hacia finales de a\u00f1o lleg\u00f3 una segunda ola, denominada <a href=\"https:\/\/securelist.com\/shai-hulud-2-0\/118214\/\" target=\"_blank\" rel=\"noopener\">Shai-Hulud\u00a02.0<\/a>.<\/p>\n<p>Esta vez, el gusano se actualiz\u00f3 con funcionalidad de wiper. Si el malware no encontraba tokens de npm o GitHub v\u00e1lidos en un sistema infectado, desencadenaba una carga destructiva que borraba los archivos del usuario.<\/p>\n<p><a href=\"https:\/\/www.bleepingcomputer.com\/news\/security\/shai-hulud-20-npm-malware-attack-exposed-up-to-400-000-dev-secrets\/\" target=\"_blank\" rel=\"noopener nofollow\">Aproximadamente 400\u00a0000\u00a0secretos<\/a> se filtraron en total como resultado del ataque. Vale la pena se\u00f1alar que, al igual que con s1ngularity, todos estos datos confidenciales terminaron en repositorios p\u00fablicos donde podr\u00edan ser descargados no solo por los atacantes sino por cualquier otra persona. Y es muy probable que las secuelas de este ataque se sientan durante mucho tiempo.<\/p>\n<p>Uno de los primeros casos confirmados de un exploit que utiliza secretos filtrados por Shai-Hulud fue un robo de criptomonedas dirigido a varios miles de usuarios de Trust\u00a0Wallet. Los atacantes utilizaron estos secretos en la v\u00edspera de Navidad para cargar una versi\u00f3n maliciosa de la extensi\u00f3n Trust\u00a0Wallet, completa con un <a href=\"https:\/\/www.kaspersky.es\/blog\/what-is-a-crypto-wallet-drainer\/29613\/\" target=\"_blank\" rel=\"noopener\">drenador de criptomonedas<\/a> integrado, a Chrome Web Store. Al final, lograron huir con 8,5\u00a0millones de d\u00f3lares en criptomonedas.<\/p>\n<h2>C\u00f3mo protegerse contra ataques a la cadena de suministro<\/h2>\n<p>Cuando preparamos <a href=\"https:\/\/www.kaspersky.com\/blog\/supply-chain-attacks-in-2024\/52965\/\" target=\"_blank\" rel=\"noopener nofollow\">una retrospectiva similar para 2024<\/a>, descubrimos que era bastante f\u00e1cil ce\u00f1irse a una estructura de una amenaza por mes. Para 2025, sin embargo, fue mucho pedir. El a\u00f1o pasado se produjeron tantos ataques masivos a la cadena de suministro que simplemente no pudimos incluirlos todos en esta descripci\u00f3n general.<\/p>\n<p>El a\u00f1o 2026 se prev\u00e9 igual de intenso, por lo que te recomendamos que leas nuestra publicaci\u00f3n espec\u00edfica sobre <a href=\"https:\/\/www.kaspersky.com\/blog\/supply-chain-attacks-what-are-they-and-how-to-manage-the-risk\/52852\/\" target=\"_blank\" rel=\"noopener nofollow\">c\u00f3mo prevenir los ataques a la cadena de suministro<\/a>. Mientras tanto, aqu\u00ed tienes los puntos clave:<\/p>\n<ul>\n<li>Eval\u00faa a fondo a los proveedores y audita cuidadosamente el c\u00f3digo que integras en tus propios proyectos.<\/li>\n<li>Implementa requisitos de seguridad estrictos directamente en tus contratos de servicio.<\/li>\n<li>Desarrolla un plan integral de respuesta a incidentes.<\/li>\n<li>Supervisa tu infraestructura corporativa para detectar actividad sospechosa mediante una soluci\u00f3n de <a href=\"https:\/\/www.kaspersky.es\/next?icid=es_kdailyplacehold_acq_ona_smm__onl_b2b_kdaily_prodmen_sm-team___knext___\" target=\"_blank\" rel=\"noopener\">XDR<\/a>.<\/li>\n<li>Si tu equipo de seguridad interno est\u00e1 limitado, utiliza un servicio externo <a href=\"https:\/\/www.kaspersky.es\/enterprise-security\/managed-detection-and-response?icid=es_kdailyplacehold_acq_ona_smm__onl_b2b_kasperskydaily_wpplaceholder_______\" target=\"_blank\" rel=\"noopener\">para la b\u00fasqueda de amenazas proactiva y la respuesta oportuna<\/a>.<\/li>\n<\/ul>\n<p>Si deseas obtener m\u00e1s informaci\u00f3n sobre los ataques a la cadena de suministro, lee nuestro informe <a href=\"https:\/\/kas.pr\/k8rs\" target=\"_blank\" rel=\"noopener\">\u201cReacci\u00f3n en cadena: c\u00f3mo proteger el ecosistema digital global en una era de interdependencia<\/a>\u201c. Se basa en los conocimientos de expertos t\u00e9cnicos y revela con qu\u00e9 frecuencia las organizaciones se enfrentan a riesgos de la cadena de suministro y de las relaciones de confianza, d\u00f3nde persisten las brechas de protecci\u00f3n y qu\u00e9 estrategias emplear para mejorar la resiliencia frente a este tipo de amenazas.<\/p>\n<input type=\"hidden\" class=\"category_for_banner\" value=\"kaspersky-next\">\n","protected":false},"excerpt":{"rendered":"<p>En 2025, los ataques a la cadena de suministro se mantuvieron como una de las amenazas m\u00e1s graves a las que se enfrentaron las organizaciones. Desglosamos los incidentes m\u00e1s notables del a\u00f1o.<\/p>\n","protected":false},"author":2726,"featured_media":31976,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2202,2754,2755],"tags":[378,3553,551,2621,2798,1474,3177,3684,3702,1633,1312,784],"class_list":{"0":"post-31975","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-amenazas","11":"tag-ataque-a-la-cadena-de-suministro","12":"tag-ataques","13":"tag-cadena-de-suministro","14":"tag-codigo-abierto","15":"tag-desarrollo","16":"tag-devops","17":"tag-ladrones","18":"tag-negocio","19":"tag-puertas-traseras","20":"tag-riesgos","21":"tag-vulnerabilidades"},"hreflang":[{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/supply-chain-attacks-in-2025\/31975\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/supply-chain-attacks-in-2025\/41594\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/supply-chain-attacks-in-2025\/55522\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/supply-chain-attacks-in-2025\/30458\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.es\/blog\/tag\/ataque-a-la-cadena-de-suministro\/","name":"ataque a la cadena de suministro"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/31975","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/users\/2726"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/comments?post=31975"}],"version-history":[{"count":3,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/31975\/revisions"}],"predecessor-version":[{"id":31979,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/31975\/revisions\/31979"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/media\/31976"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/media?parent=31975"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/categories?post=31975"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/tags?post=31975"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}