Limpiar una tienda PrestaShop hackeada: eliminar malware y hardening posterior

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

Cuando una tienda PrestaShop empieza a redirigir pedidos, inyecta scripts en el checkout o Google la marca como «engañosa», no basta con borrar dos ficheros y respirar aliviado. Limpiar PrestaShop hackeado y eliminar malware es un proceso ordenado: primero contener, luego identificar el vector, después erradicar todo el implante y solo al final volver a producción con un hardening que impida la reinfección. Este artículo forma parte de nuestra guía de respuesta a incidentes (DFIR): web hackeada, qué hacer, donde encajan la contención, el análisis forense y el retorno al servicio.

Conviene decirlo desde el principio: una tienda PrestaShop maneja datos de pago. En PathSentinel tratamos también entornos exigentes —banca y comercios con datos de tarjeta— y ese contexto cambia las prioridades: aquí no solo se recupera una web, se protege información que puede acabar en un skimmer.

Antes de limpiar PrestaShop hackeado: aislar y preservar evidencia

El primer impulso —borrar y reinstalar— destruye las pruebas que necesitas para saber por dónde entraron. Aísla la tienda del tráfico (página de mantenimiento o cortando en el WAF/proxy, no apagando el servidor) y haz una copia forense del sistema de ficheros y una exportación de la base de datos antes de tocar nada. Trabajar sobre una imagen preserva marcas de tiempo, logs y el propio implante para el análisis. El marco de referencia es el NIST SP 800-61 para el ciclo del incidente y el NIST SP 800-86 para la adquisición correcta de evidencia.

Registra la hora de detección, los síntomas (redirecciones, spam SEO, cargos fraudulentos reportados por clientes) y quién tuvo acceso. Ese cuaderno de bitácora será oro si el incidente escala a notificación por brecha de datos.

Encontrar el implante: dónde se esconde el malware en PrestaShop

PrestaShop tiene rincones muy concretos que los atacantes reutilizan una y otra vez. Revisa con método:

• Módulos maliciosos o troyanizados en /modules/: módulos que nunca instalaste, o legítimos con ficheros PHP añadidos. Un clásico es el módulo «de pago» falso que captura el número de tarjeta.
• La carpeta /override/: sobrescrituras de controladores del front que inyectan JavaScript en la página de confirmación de pedido (skimmer tipo Magecart).
• Caché de Smarty en /var/cache/: plantillas compiladas con código PHP inyectado, herencia de la conocida cadena de 2022 que encadenaba una inyección SQL con ejecución vía la caché de Smarty. No borres esa caché sin antes revisarla: es evidencia.
• Webshells disfrazados en /admin*/, /img/ o el tema activo: ficheros con nombres plausibles (logo.php, index_old.php) que ejecutan eval, base64_decode o assert sobre datos de la petición.
• La base de datos: registros inyectados en ps_configuration, pestañas fantasma en ps_tab, y sobre todo empleados no autorizados en ps_employee o claves de la webservice que no reconoces.

La caza de indicadores no se hace solo con antivirus: combina búsquedas de patrones sospechosos con la comparación contra una instalación limpia de tu misma versión de PrestaShop y de cada módulo. Lo que sobra, sobra.

Erradicar sin dejar puertas traseras

Erradicar significa retirar todo el implante, no el más visible. Un skimmer suele venir acompañado de una o varias puertas traseras para volver a entrar cuando «limpies». Por eso:

• Restaura el core de PrestaShop y los módulos legítimos desde fuentes oficiales, no desde la copia comprometida.
• Revisa manualmente config/settings.inc.php (o app/config/parameters.php en 1.7) y las tareas cron por si dejaron un ejecutor persistente.
• Rota todo: contraseñas de empleados, cookie keys, claves de la webservice, credenciales de base de datos, accesos FTP/SSH y tokens de pasarelas de pago.

Si dudas de si conviene limpiar en producción o partir de una base sana, lee cómo restaurar desde copia de seguridad sin reinfectarte: el backup rara vez basta por sí solo, porque muchos respaldos ya contienen la puerta trasera.

Hardening posterior: que no vuelva a pasar

La limpieza sin hardening es una tregua, no una solución. Una vez la tienda está sana:

• Actualiza PrestaShop y cada módulo a la última versión con parches de seguridad; retira los módulos que no uses.
• Renombra la carpeta de administración y activa 2FA para todos los empleados.
• Ajusta permisos de ficheros (nada de 777), impide la ejecución de PHP en /img/, /upload/ y /download/, y desactiva la evaluación de plantillas en producción.
• Coloca un WAF por delante y monitoriza la integridad de ficheros para detectar cualquier reescritura del checkout.

Para orquestar todo el retorno al servicio con orden —del corte inicial al 100% operativo— tienes el plan de recuperación tras un hackeo. Y si la tienda procesa tarjetas, valora notificar según tus obligaciones y apóyate en recursos como CISA para el endurecimiento continuo.