PrestaShop hackeado: detectar y eliminar un skimmer bancario

El peor hackeo es el que no rompe nada

Cuando una tienda PrestaShop hackeada se cae con un error 500, el comerciante se entera en menos de una hora. Cuando lleva un skimmer, la tienda sigue funcionando a la perfección: los pedidos entran, los clientes pagan y un script inyectado en la página de pago copia sin hacer ruido los números de tarjeta hacia un servidor ajeno.

La oleada detectada en PrestaShop a principios de 2026 responde a este patrón. El punto de entrada casi nunca es el núcleo: es un módulo de terceros sin actualizar, instalado a veces años antes y olvidado desde entonces.

Dos consecuencias inmediatas para el comerciante: la pérdida de la conformidad PCI DSS ante su proveedor de pagos y la obligación de notificar la brecha a la autoridad de protección de datos —la AEPD en España— en un plazo de 72 horas, en virtud del artículo 33 del RGPD.

Las señales que deben alertarle

Ninguna de estas señales es una prueba por sí sola, pero todas merecen una comprobación:

• varios clientes avisan de cargos fraudulentos poco después de comprarle;
• su proveedor de pagos le escribe por una tasa de fraude anormal;
• un archivo JavaScript del tema tiene una fecha de modificación reciente aunque usted no haya publicado nada;
• aparece una etiqueta <script> que apunta a un dominio desconocido en el código fuente de la página de pedido;
• Google Search Console avisa de contenido engañoso o de páginas de spam indexadas.

Los dominios de exfiltración imitan a propósito servicios legítimos: nombres que contienen cdn, analytics, jquery o tag-manager, sobre extensiones poco habituales. Un dominio que se parece a Google sin ser google.com es la señal más fiable.

El diagnóstico por SSH, en cinco comandos

Archivos modificados en los últimos siete días:

find . -type f -name "*.php" -mtime -7 -not -path "./var/cache/*"
find . -type f -name "*.js" -mtime -7 -not -path "./var/cache/*"

Código ofuscado en los temas y los módulos:

grep -rl "eval(atob\|eval(String.fromCharCode\|_0x" themes/ modules/

Puertas traseras clásicas:

grep -rl "eval(\$_POST\|assert(\$_REQUEST\|base64_decode(\$_" . --include="*.php"

En la base de datos, una inyección histórica muy documentada consiste en colar JavaScript en el nombre de la tienda, que se reimprime en todas las páginas:

SELECT name, value FROM ps_configuration WHERE value LIKE '%<script%';
SELECT id_employee, email, active FROM ps_employee;

Una cuenta de empleado que no reconoce, o un valor de configuración que contiene HTML, bastan como confirmación.

El procedimiento de limpieza

Limpiar un sitio hackeado en desorden garantiza la reinfección. El orden importa.

1. Congelar la escena. Haga una copia completa de los archivos y de la base de datos antes de tocar nada. Es su única prueba y su único modo de entender por dónde entraron.

2. Detener la hemorragia. Ponga la tienda en modo mantenimiento. Mientras la página de pago siga en línea, los números seguirán saliendo.

3. Restaurar el código desde una fuente limpia. Vuelva a descargar el núcleo de PrestaShop en la versión exacta que tiene instalada y sobrescriba los archivos, conservando img/, upload/, download/, sus módulos propios y config/settings.inc.php. Reinstale cada módulo de terceros desde su editor, nunca desde un archivo comprimido encontrado en el servidor.

4. Limpiar la base de datos. Corrija los valores alterados de ps_configuration, elimine las cuentas de empleado desconocidas e inspeccione las páginas CMS y las descripciones de producto que contengan <script>.

5. Renovarlo todo. Contraseñas de los empleados, contraseña de la base de datos, accesos FTP/SSH, claves API de los módulos de pago y las claves criptográficas de config/settings.inc.php (_COOKIE_KEY_, _RIJNDAEL_KEY_). Regenerar esas claves cierra todas las sesiones abiertas, incluida la del atacante.

6. Cerrar la puerta de entrada. Sin este paso, la reinfección llega en cuestión de días. Actualice todos los módulos, consulte los avisos de seguridad publicados por Friends-of-Presta para cada uno de ellos y aplique los parches de seguridad del núcleo.

Blindar la tienda para el futuro

• Renombrar la carpeta de administración y protegerla con una autenticación HTTP adicional.
• Impedir la ejecución de PHP en img/, upload/ y download/ desde la configuración del servidor.
• Activar la doble autenticación en todas las cuentas de empleado.
• Poner en marcha un cortafuegos de aplicaciones web y una vigilancia de la integridad de los archivos: un archivo PHP creado en modules/ debe generar una alerta.
• Hacer copias de seguridad diarias, con una retención mínima de 30 días. Una copia de 7 días no sirve de nada frente a una intrusión que se descubre tres semanas después.

Si su tienda se ha visto comprometida a través de un módulo de búsqueda por facetas sin parchear, lea también nuestro análisis de la vulnerabilidad ps_facetedsearch.

Intervención de urgencia

Un skimmer sale más caro cada día que sigue en su sitio. Auditamos, limpiamos y aseguramos la tienda, con un informe escrito del vector de entrada. Diagnóstico gratuito, respuesta en menos de 1 h — hable con nosotros.