Una campaña sostenida y dirigida a tiendas online ha infectado 953 comercios electrónicos, sobre todo plataformas Magento, al insertar un pequeño fragmento de código en los bloques CMS de las tiendas que carga a su vez un script malicioso sólo visible para usuarios reales, indicó la firma neerlandesa de seguridad e‑commerce Sansec.
Qué hace el código y cómo evita la detección
El código añadido en los bloques CMS de Magento solicita desde el navegador del visitante instrucciones a un servidor controlado por el atacante. Antes de enviar un payload, el servidor comprueba si la petición procede de un comprador real o de un escáner de seguridad; si detecta un escáner, no entrega nada. Esta técnica evita la mayoría de detecciones automatizadas y análisis pasivos.
Sansec ha identificado al menos cinco dominios usados por el grupo a lo largo del tiempo. Uno de los dominios observados recientemente es deepveindrilling[.]com, hallado en 83 tiendas desde que fue registrado el 6 de octubre de 2026. El cargador JavaScript actual responde a peticiones de script únicamente cuando la petición se origina en visitantes reales de sitios comprometidos y se ejecuta desde bloques almacenados en la tabla cms_block de Magento, que se usa para renderizar contenido estático en las páginas de la tienda.
Variantes del loader y persistencia local
Se han visto al menos dos versiones del cargador JavaScript. En una, el script externo guarda la carga útil en el localStorage del navegador, de modo que el código almacenado se vuelve a ejecutar en visitas posteriores aunque el dominio atacante deje de estar disponible. La segunda versión añade comprobaciones de fingerprinting del navegador para filtrar bots y escáneres y asegurar que sólo compradores reales reciben el payload. Sansec no ha determinado aún la naturaleza exacta del payload final.
Vectores de acceso y elementos observados
Sobre el vector inicial de acceso, Sansec estima que 471 tiendas Magento fueron inyectadas mediante la vulnerabilidad conocida como PolyShell (apodada también CVE‑2026‑48356 en el informe). Otras 102 tiendas permitieron la subida de archivos a través de PolyShell o de SessionReaper (CVE‑2025‑54236). En un caso concreto se encontraron webshells disfrazados de imágenes PNG en pub/media/custom_options/quote/, junto con el loader en un bloque CMS; ese bloque cambió posteriormente para apuntar a deepveindrilling[.]com.
También se documentó un compromiso distinto en una tienda Magento 2.4.7‑p10 que, aunque sin parches de núcleo pendientes, sufrió la creación de una cuenta administrativa fraudulenta que se empleó para inyectar el código.
Recomendaciones prácticas para administradores
- Auditar la base de datos: revisar las tablas cms_block y cms_page en busca de bloques inesperados o con código sospechoso.
- Comprobar cuentas administrativas: buscar usuarios no autorizados y activar la autenticación robusta para administradores.
- Aplicar parches y actualizaciones: mantener Magento y sus extensiones al día y desplegar las correcciones oficiales relacionadas con PolyShell y SessionReaper cuando correspondan.
- Revisar archivos subidos: detectar ficheros con extensiones sospechosas o contenidos encubiertos (por ejemplo, webshells renombrados).
- Fortalecer contraseñas y políticas de acceso: habilitar MFA en paneles de administración y limitar accesos al backend.
Sansec también observó que versiones tempranas de la campaña usaron Keitaro como sistema de distribución de tráfico (TDS) para decidir, según las características del visitante, si devolver un payload, redirigir o no responder. En iteraciones posteriores, el bot‑filtrado se integró directamente en el loader y se prescindió de Keitaro.
Contexto y alertas relacionadas
La divulgación de esta campaña coincide con la reciente atención sobre vulnerabilidades críticas en PHP y su explotación en entornos reales; sin embargo, Sansec no asocia directamente esos fallos con la carga final observada en estas infecciones. El hallazgo subraya la importancia de auditar de forma regular tiendas en línea —especialmente las que usan CMS con bloques editables— y de aplicar controles que detecten código dinámico inyectado en contenidos estáticos.
Para administradores y propietarios de tiendas, la prioridad inmediata es auditar los bloques CMS y las cuentas administrativas, aplicar parches y revisar el uso de localStorage y dominios remotos en las páginas públicas.
Lee también:
- Wordfence crea un equipo de respuesta para reportar amenazas activas en el ecosistema WordPress
- Buscar por nameserver revela dominios de phishing que escapan a la búsqueda por nombre
Fuente: The Hacker News
