Módulos «nulled» de PrestaShop: el mercado de backdoors que infecta tu tienda

Por PathSentinel · Jesús Macías Rubiales — Investigación de seguridad web

Instalar un módulo PrestaShop nulled es un peligro con backdoor casi garantizado. «Nulled» significa una versión pirata de un módulo de pago cuya protección de licencia ha sido eliminada; el problema es que, en el proceso, casi siempre se le añade código malicioso. No es software gratis: es el vehículo de entrega de una puerta trasera que quien lo publica controla desde el primer minuto. Este artículo forma parte de nuestra guía pilar sobre seguridad de e-commerce y multi-CMS, y aquí desmontamos por qué este mercado es tan rentable para el atacante y tan caro para tu tienda.

Por qué un módulo PrestaShop nulled es un peligro con backdoor

Piensa en el modelo de negocio del que «regala» el módulo. Nadie invierte tiempo en romper una licencia y alojar la descarga por altruismo. El retorno está en el código que inyecta: un fragmento ofuscado que abre una vía de acceso remoto, se conecta a un servidor de control o se prepara para robar datos de tarjeta en el checkout. Los patrones que encontramos en estas investigaciones se repiten:

• Webshell o cargador ofuscado escondido entre el código legítimo del módulo, a menudo con nombres que imitan ficheros del núcleo.
• Ejecución remota mediante funciones como eval sobre datos recibidos por POST o cookies, que permiten al atacante ejecutar comandos a demanda.
• Skimmer de tarjetas inyectado en la plantilla de pago, que copia los datos que el cliente teclea antes de que lleguen a la pasarela.
• Creación de administradores fantasma y tareas programadas que reinstalan el backdoor aunque borres el archivo visible.

El resultado es una tienda que sigue «funcionando» mientras filtra pedidos, credenciales y, en el peor caso, tarjetas de tus clientes.

Cómo infecta y por qué reincide

La infección no termina cuando instalas el módulo; ahí empieza. El backdoor establece persistencia en varios puntos a la vez para sobrevivir a una limpieza superficial: ficheros dispersos por el árbol de directorios, entradas en la base de datos, un administrador oculto y a veces una tarea cron. Por eso muchos comerciantes «limpian» borrando el módulo y a los pocos días vuelven a estar infectados: eliminaron la parte visible pero no el mecanismo de reinstalación.

Es exactamente el mismo problema de cadena de suministro que afecta a otros CMS cuando se instalan extensiones de origen dudoso, y que analizamos de forma transversal en nuestra visión pilar. El proyecto oficial insiste en descargar solo desde fuentes de confianza; sus recomendaciones están recogidas en PrestaShop Security.

Señales de que tu tienda ya está comprometida

• Ficheros PHP recientes o modificados en carpetas de módulos y en el directorio de administración.
• Administradores que no reconoces, o empleados con permisos que nadie asignó.
• Código JavaScript desconocido cargándose en la página de pago.
• Conexiones salientes del servidor a dominios extraños, o picos de tráfico sin explicación.
• Clientes que reportan cargos fraudulentos tras comprar en tu tienda: la señal más grave de todas.

Si detectas esto último, estás ante un incidente de datos de tarjeta. Cualquier tienda que procese pagos está bajo el paraguas de PCI DSS, y una filtración conlleva obligaciones de notificación y, potencialmente, responsabilidad legal. En PathSentinel atendemos precisamente ese tipo de incidentes exigentes, incluidos entornos de banca y comercios con datos de tarjeta, además de la pyme que solo quiere volver a operar limpia.

Cómo limpiar y prevenir la reinfección

• Contén primero. Aísla la tienda o ponla en mantenimiento antes de tocar nada, y preserva evidencia (logs, copia forense) por si hay que notificar.
• Erradica la persistencia completa, no solo el módulo: ficheros dispersos, entradas en base de datos, administradores fantasma y tareas cron. Una limpieza a medias garantiza la reincidencia.
• Rota todas las credenciales del panel, base de datos, FTP y APIs de pago.
• Reinstala módulos legítimos desde el marketplace oficial o el desarrollador original. Si un módulo de pago era demasiado caro, la alternativa nunca es la versión pirata.
• Refuerza el checkout. Los mismos principios que aplicamos en WooCommerce seguro valen aquí: minimizar el manejo de datos de tarjeta y vigilar cualquier script en la página de pago.
• Cumple con tus obligaciones. Si hubo exposición de datos personales o de tarjeta, revisa las implicaciones que detallamos en fugas de datos en tu tienda.

Para entender cómo un proyecto maduro gestiona y comunica sus vulnerabilidades, el Joomla! Security Centre es una buena referencia de contraste: los avisos existen para que descargues de fuentes oficiales, no de foros de «nulled». Si sospechas que ya tienes un backdoor y no logras cortar la reinfección, escríbenos desde contacto.