953 tiendas Magento cargaron un loader que se esconde de los escáneres

A las 21:54 UTC del 7 de octubre de 2026, el escáner eComscan de Sansec encontró en la tabla cms_block de una tienda Magento dos etiquetas script que llamaban a deepveindrilling.com, un dominio registrado el día anterior. Es la quinta dirección de una campaña que ha inyectado su loader en 953 tiendas online desde julio de 2025, casi todas Magento, y que desde el 23 de octubre solo entrega su carga a quien el servidor considera un comprador real.

La firma neerlandesa de seguridad para comercio electrónico publicó el análisis el 24 de octubre en su informe sobre deepveindrilling.com. Encontró el nuevo dominio en los bloques CMS de 83 tiendas. Sesenta de ellas ya habían cargado antes alguno de los loaders del mismo operador, y 34 lo hacían desde octubre de 2025. Es decir, la mayoría de las víctimas de octubre llevaban meses comprometidas sin saberlo.

Dos scripts en cms_block y una clave fpCode que no se borra

Los bloques CMS son los fragmentos de contenido estático que Magento pinta en las páginas de la tienda, y viven en la base de datos. Sansec detectó el código malicioso en la tabla cms_block de 148 instalaciones a lo largo de la campaña y nunca en core_config_data ni en los ficheros del tema. Quien revise solo el código de la tienda en disco no lo va a ver.

La primera versión de octubre usaba dos scripts. El primero lee del localStorage del navegador una entrada llamada fpCode y, si existe, mete su contenido en el atributo onclick de un div invisible y lo pulsa por código. El navegador ejecuta así lo almacenado como manejador de eventos, sin pasar por eval(). Nada en el bloque escribe fpCode, de modo que tiene que hacerlo el segundo script, que carga https://deepveindrilling.com/?s=d35c5031.

El cambio respecto a la oleada de marzo está en la persistencia. Entonces, el loader borraba la carga guardada después de ejecutarla una vez. Ahora la conserva, de modo que un visitante que la recibió una vez la vuelve a ejecutar en cada página que visita, aunque el dominio esté caído o bloqueado en la red de la tienda. Limpiar el bloque CMS detiene nuevas infecciones, pero el navegador del cliente sigue guardando la carga.

El código que Sansec reprodujo en su aviso de PolyShell muestra la segunda mitad del loader de marzo. Crea un script cuya dirección va en base64 y le añade el referrer, el título y los parámetros de la URL de la página que visita el cliente. En marzo la carga se guardaba bajo la entrada 136c1e07507f4a97 de localStorage, y Sansec incluye también 136c1e07507f4a98 entre los indicadores.

El 23 de octubre el operador reescribió los bloques otra vez y el loader apareció en 9 tiendas más. Las 71 tiendas que Sansec volvió a rastrear hasta el 24 de octubre ejecutan ya la nueva versión, que sustituye la etiqueta script por un loader en línea que envía una huella del navegador a https://deepveindrilling.com/?s=49b7ca5f&fp=. Esa huella detecta navegadores automatizados por navigator.webdriver, por las variables globales de Selenium y por las propiedades cdc_ de ChromeDriver, y añade el nombre de la GPU obtenido de WebGL, núcleos de CPU, memoria, tamaño de pantalla, zona horaria, idiomas y client hints. Es la misma lógica de filtrar a quién se infecta que hemos visto en campañas de espionaje, aplicada aquí a tiendas online.

El filtro funciona. Cuando urlscan.io abrió una tienda infectada con un Chrome automatizado, recibió un HTTP 200 y Sansec no encontró ningún contenido añadido en la página. Por eso la firma reconoce que todavía no ha capturado la carga final.

Cinco dominios en quince meses, de manulfie.click a deepveindrilling.com

El operador cambia de dirección cada pocos meses y deja atrás los dominios viejos incrustados en las tiendas que no se limpian. El gráfico de Sansec muestra cada dominio como barra mientras fue el activo y como línea fina mientras siguió presente en tiendas comprometidas.

La línea temporal recoge 863 tiendas para manulfie.click desde el 9 de julio de 2025, 494 para neswnsssn.click desde el 12 de diciembre, 355 para lanhd6549tdhse.top desde el 30 de marzo de 2026, 246 para additionalver.com desde el 8 de junio y 83 para deepveindrilling.com desde el 7 de octubre. Las cifras se solapan porque una misma tienda pasa de un dominio al siguiente. Hubo otros dos en pocas tiendas, hdfdsi84j3h.top, registrado tres minutos después de lanhd6549tdhse.top, y c85grt98sd.com.

Hasta octubre, el segundo script era la integración Script (async) de Keitaro, un rastreador publicitario comercial que también funciona como sistema de distribución de tráfico (TDS). El TDS recibe el referrer, el título de la página y la cadena de consulta, y decide para cada visitante si devuelve una carga, una redirección o nada. Cuando Sansec pidió el script de additionalver.com el 24 de octubre como si fuera un equipo Windows de escritorio, obtuvo QWE=123, una sentencia que no hace nada, y una cookie que marca al visitante durante 24 horas. Con deepveindrilling.com el operador prescinde de Keitaro y lleva el filtrado de bots al propio loader.

Lo que vieron los compradores reales se conoce por los registros antiguos. El 12 de diciembre de 2025, un cliente con sesión iniciada en una tienda infectada recibió de manulfie.click un script que cargó https://crypto-insider.top/ssl/ y, cinco minutos después, https://leqdger.click/ssl/. Ese último dominio imita la marca de carteras de criptomonedas Ledger, se registró el 12 de septiembre de 2025 y ya ha caducado. Sansec Watch, el servicio de la firma que recoge los informes de la política de seguridad de contenidos (CSP) de las tiendas, registró unas 52.000 cargas de additionalver.com desde navegadores de visitantes.

Hay un detalle que afecta a tiendas que dan la campaña por cerrada. neswnsssn.click y manulfie.click caducaron y alguien volvió a registrarlos en mayo de 2026, ahora con los servidores de nombres de un servicio de aparcamiento de dominios. Entre agosto y octubre, Sansec aún encontró el loader de manulfie.click en 9 tiendas y el de neswnsssn.click en 6. Sus visitantes envían el referrer y el título de la página al nuevo dueño del dominio, y su navegador ejecuta cualquier script que este devuelva.

PolyShell y SessionReaper, las dos puertas que Sansec encontró abiertas

Las reescrituras de octubre no necesitaron ninguna vulnerabilidad nueva, porque 60 de las 83 tiendas ya estaban infectadas. Las oleadas anteriores sí apuntan a fallos de subida de ficheros de Magento. El 30 de marzo de 2026, el operador colocó el loader de lanhd6549tdhse.top en 471 tiendas en una hora después de subir webshells mediante PolyShell, el fallo de subida de ficheros que Sansec había descubierto y bautizado el 17 de marzo.

El registro que Sansec publicó aquel día recoge una tienda nueva cada pocos segundos entre las 12:52 y las 13:10 UTC, todas con la misma llamada atob() que decodifica la URL del loader. Entre los dominios anonimizados aparecen terminaciones .es, .fr, .it, .pt, .pl e .ie, junto a muchos .com. Sansec no ha publicado un reparto por países de las 953 tiendas, así que a 27 de octubre no hay un recuento de víctimas en España.

Dentro de la campaña, eComscan encontró el loader en 169 instalaciones de Magento 2 a las que les faltaba al menos un parche del núcleo. En 102 de ellas (60 %) había además ficheros subidos mediante PolyShell o SessionReaper. En 3.024 instalaciones comparables con otro skimmer, el porcentaje es del 32 %.

PolyShell es CVE-2026-48356, una subida sin restricciones de ficheros de tipo peligroso (CWE-434) en la API REST, con CVSS 3.1 de 9,3 y vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N tanto para Adobe como para NVD. La ficha de CVE-2026-48356 remite al boletín APSB26-73 del 14 de julio de 2026, casi cuatro meses después de los primeros ataques. Según Sansec, Adobe ya había incluido la corrección en Magento 2.4.9 el 12 de mayo, sin llevarla entonces a las ramas anteriores. CISA no la había incluido en KEV en la versión del catálogo del 26 de octubre. Una tienda en Magento 2.4.7-p1 tenía webshells de PolyShell disfrazadas de imágenes PNG en pub/media/custom_options/quote/, junto al loader en un bloque CMS, y seguía sin el boletín APSB26-73.

SessionReaper es CVE-2025-54236, un fallo de validación de entrada (CWE-20) con CVSS 3.1 de 9,1 que permite secuestrar sesiones sin interacción del usuario. Adobe lo corrigió el 9 de septiembre de 2025 en el boletín APSB25-88. Sansec había adelantado la llegada del parche un día antes en Bluesky.

Sansec BV@sans.ec

Adobe will release fix for the critical SessionReaper attack tomorrow Sept 9th. All Magento and Adobe Commerce versions are vulnerable. Sansec Shield users are already protected, all others should standby and implement patch once it is published (likely 14h UTC). sansec.io/research/ses...

sansec.io

SessionReaper, a critical bug in Magento & Adobe Commerce (CVE-2025-54236)

Adobe breaks their regular patch schedule and will release an emergency fix for CVE-2025-54236 within the next 24 hours. Automated abuse is expected and merc...

September 8, 2025 at 1:26 PM UTC

En ese post de Sansec del 8 de septiembre de 2025, la firma avisaba de que «All Magento and Adobe Commerce versions are vulnerable» (todas las versiones de Magento y Adobe Commerce son vulnerables). CISA añadió CVE-2025-54236 a su catálogo KEV el 24 de octubre de 2025, con fecha límite el 14 de noviembre para las agencias federales de EE. UU.

Estar al día tampoco protege a quien ya fue comprometido. Una tienda en Magento 2.4.7-p10, sin ningún parche del núcleo pendiente, recibió deepveindrilling.com a las 16:46 UTC del 23 de octubre, una hora después de un escaneo limpio. eComscan había encontrado en ella una cuenta de administrador no autorizada el 16 de septiembre y un backdoor GSocket el 24 de septiembre. «Patched stores get the loader too» (las tiendas parcheadas también reciben el loader), resume Sansec. En su análisis de SessionReaper, la firma explica por qué: si la clave de cifrado de Magento se filtra, el atacante puede modificar los bloques CMS de forma indefinida, y los tokens de las integraciones de API sobreviven a la rotación de esa clave.

Cómo buscar el loader en cms_block y cms_page

Sansec advierte que los dominios suelen ir en base64, así que conviene buscar los patrones del código y no los nombres. Esta es la consulta que propone para la tabla de bloques, que hay que repetir sobre cms_page y adaptar si la tienda usa prefijo de tablas.

SELECT block_id, identifier, update_time FROM cms_block
WHERE content LIKE '%fpCode%' OR content LIKE '%se_referrer%'
   OR content LIKE '%localStorage.getItem%';

La columna update_time indica la última escritura del atacante, un dato útil para acotar la ventana del incidente. Para localizar la vía de entrada, Sansec sugiere listar lo que haya en los directorios de subida que usan PolyShell y SessionReaper y buscar el backdoor accesson.php, que en marzo apareció replicado en carpetas assets/images/ de casi todos los directorios del proyecto.

find pub/media/custom_options/ pub/media/customer_address/ -type f ! -name '.htaccess'
find . -name 'accesson.php' -type f

Con eso, el orden de trabajo para una tienda Magento queda así.

1. Ejecuta la consulta sobre cms_block y cms_page y guarda el contenido y el update_time de cada bloque sospechoso antes de borrarlo.
2. Revisa los ficheros de pub/media/custom_options/ y pub/media/customer_address/, busca accesson.php en todo el árbol y comprueba si hay procesos desconocidos, como un cliente GSocket.
3. Revisa la tabla admin_user y elimina las cuentas que no reconozcas, y borra las integraciones de API que nadie haya dado de alta.
4. Rota la clave de cifrado de Magento siguiendo la guía de Sansec y cambia las contraseñas de la base de datos, de los administradores y de las integraciones.
5. Aplica APSB26-73 para PolyShell y APSB25-88 para SessionReaper, y revisa los boletines posteriores de Adobe para tu rama.
6. Bloquea en el servidor web el acceso a pub/media/custom_options/ y, si usas CSP en modo informe, busca en los informes los dominios de la tabla de abajo.
7. Si la tienda procesa pagos o datos de clientes en España, valora con tu delegado de protección de datos la notificación a la AEPD y comunica el incidente a INCIBE-CERT.

Quien gestione varias tiendas tiene en este caso un ejemplo claro de por qué la búsqueda de indicadores de compromiso no sustituye a la investigación de la intrusión. «Deleting the script does not remove that access» (borrar el script no elimina ese acceso), insiste Sansec.

Indicadores de la campaña según Sansec

Sansec publica la lista al final de su informe. Los valores van tal cual los publica la firma. Las claves de localStorage citadas arriba completan la lista.

Lo que falta por saber de deepveindrilling.com

La pieza que falta es la carga final. Sansec no la ha capturado porque el servidor la niega a cualquier navegador que parezca automatizado, y los únicos rastros de lo que recibían los compradores son de diciembre de 2025, con un dominio que imitaba a Ledger. Leemos el cambio de octubre como una apuesta por durar más en cada tienda. Casi todo el crecimiento sale de víctimas antiguas, y la carga queda guardada en el navegador del cliente.

La cronología encaja con algo que ya vimos con PHP2Shell y con las webshells de Nextcloud. El parche se aplica y el acceso obtenido antes sigue ahí. En Magento el problema se agrava porque el código malicioso vive en la base de datos y se ejecuta en el navegador del cliente, lejos de los EDR del servidor y de los escáneres automatizados que el loader ya sabe esquivar. Quien quiera repasar cómo se analiza un JavaScript ofuscado en el navegador tiene en el loader de marzo un buen caso de prueba.

Si tu tienda cargó alguno de estos dominios en los últimos quince meses, trátala como comprometida hasta que encuentres la vía de entrada, aunque hoy tenga todos los parches y el bloque CMS esté limpio.