Respuesta ante una brecha de datos: qué hacer si hackean tu tienda

El peor momento para improvisar tu plan de respuesta ante incidentes es a las 2 de la madrugada, mirando un correo de un cliente que dice: "vuestro proceso de pago me ha cobrado dos veces la tarjeta y ahora estoy recibiendo mensajes de phishing". Si gestionas una tienda PrestaShop durante el tiempo suficiente, existe una posibilidad real de que sufras una intrusión: las tiendas pequeñas y medianas reciben ataques constantemente, no porque alguien las haya elegido una por una, sino porque los escáneres automatizados lanzan exploits conocidos de PrestaShop y de módulos por toda la web y prueban cualquier puerta que esté sin cerrar. Esta guía es el procedimiento para después de que salte la alarma: una secuencia tranquila y ordenada de qué revisar, qué conservar y qué zonas específicas de PrestaShop casi con toda seguridad habrá tocado el atacante. No pretende ser una guía de prevención; si has llegado aquí antes de que ocurra nada, empieza mejor por la lista de endurecimiento de seguridad para PrestaShop.

Léela una vez ahora, mientras no hay ningún incendio. El factor que más predice una recuperación limpia es conocer el orden de actuación antes de necesitarlo.

Revisado en junio de 2026 frente a las estructuras actuales de archivos y base de datos de PrestaShop 1.6, 1.7, 8 y 9, y la regla del RGPD de notificación de brechas en 72 horas vigente en el momento de escribir este artículo.

Antes de tocar nada: conserva las pruebas

Una lupa pasa sobre una cuadrícula de iconos brillantes de archivos y carpetas, algunos resaltados en naranja.

Si tienes acceso por shell, copia los archivos, la base de datos y los registros antes de borrar nada. Ajusta el nombre de la base de datos y las rutas a tu alojamiento.

#!/usr/bin/env bash
set -euo pipefail

stamp=$(date +%F-%H%M%S)
case_dir="/root/prestashop-incident-$stamp"
mkdir -p "$case_dir"

tar --xattrs --acls -czf "$case_dir/files.tgz" /var/www/html
mysqldump --single-transaction --routines --triggers prestashop > "$case_dir/database.sql"
cp -a /var/log/nginx /var/log/apache2 /var/log/php* "$case_dir/" 2>/dev/null || true

sha256sum "$case_dir"/* > "$case_dir/SHA256SUMS"
chmod -R go-rwx ";$case_dir

El primer impulso suele ser entrar en el panel de administración y empezar a borrar archivos sospechosos. Resístelo. En cuanto empiezas a cambiar cosas, destruyes el rastro que te dice cómo entraron; y si no encuentras el punto de entrada, volverán a comprometer la tienda en cuestión de días. Tu primera acción debe ser copiar, no limpiar.

Haz una instantánea completa antes de cualquier remediación:

• Toda la raíz web — tu directorio de PrestaShop, incluidos los archivos ocultos (.htaccess, .user.ini). A los atacantes les encantan porque poca gente los audita.
• Un volcado de la base de datos — ejecuta mysqldump de la base de datos completa. La inyección a menudo vive en la base de datos, no solo en el disco (lo verás más abajo).
• Los registros — registros de acceso/error del servidor web (/var/log/nginx/ o /var/log/apache2/), registros de PHP-FPM y los propios registros de PrestaShop en var/logs/ (PS 1.7+) o log/ (PS 1.6). Los registros rotan y desaparecen; recógelos primero.

Guarda esa instantánea en un lugar al que el atacante no pueda acceder: tu portátil o un contenedor de almacenamiento nuevo, no una segunda carpeta en el mismo servidor comprometido. Esa instantánea es lo que te pedirá el equipo de abuso de tu proveedor de alojamiento, un profesional forense o una reclamación al ciberseguro, y es la única forma de reconstruir una línea de tiempo más adelante.

Contén la hemorragia sin destruir la escena

La contención y el análisis forense tiran en direcciones opuestas: quieres detener el daño, pero desconectar todo puede borrar pruebas volátiles (sesiones activas, procesos del atacante). El equilibrio para una tienda típica es este: deja la tienda fuera de línea para los clientes, pero mantén el servidor en marcha para poder investigar.

PrestaShop trae integrado el modo mantenimiento. En el panel de administración ve a Parámetros de la tienda → General → Mantenimiento (PS 1.7/8/9) y desactiva la tienda; después añade tu propia IP al campo IP de mantenimiento para poder seguir trabajando mientras los clientes ven una página de espera. Las banderas subyacentes son PS_SHOP_ENABLE y PS_MAINTENANCE_IP en la tabla ps_configuration: útil si el propio panel de administración está bloqueado o alterado y necesitas cambiarlo directamente en la base de datos.

Si los datos de pago pueden estar implicados, el modo mantenimiento no basta; y no empieces buscando en archivos. Dos llamadas tienen prioridad sobre cualquier tarea técnica:

• Tu proveedor de pagos. Stripe, PayPal, Mollie, Adyen, tu banco adquirente: quien liquide tu dinero. Tienen equipos antifraude que pueden vigilar patrones de prueba de tarjetas y marcar tarjetas afectadas. Si se inyectó un skimmer de tarjetas en tu proceso de pago, así se monitorizan las tarjetas expuestas antes de que se usen fraudulentamente.
• Tu proveedor de alojamiento. Muchas intrusiones empiezan en la cuenta de alojamiento, no en la instalación de PrestaShop, y tu proveedor puede ver cosas que tú no puedes ver (otros sitios en la misma cuenta, spam saliente, el cron que está minando criptomonedas).

Dónde se esconden realmente los atacantes en PrestaShop

Esta es la parte que se saltan los artículos genéricos de "te han hackeado", y es la clave de todo. Conocer los lugares concretos donde viven las infecciones de PrestaShop convierte un "escanea todo" desesperado en una búsqueda dirigida. En orden aproximado de frecuencia con que lo vemos:

Un primer barrido práctico en el servidor: lista todos los archivos PHP modificados en los últimos 30 días y revisa cada uno que no reconozcas. Desde la raíz web, find . -name "*.php" -mtime -30 -ls muestra archivos tocados recientemente; compáralos con una copia limpia de la misma versión de PrestaShop (descarga la versión exacta desde el sitio oficial) para distinguir archivos del núcleo de archivos manipulados. Presta especial atención a cualquier PHP que viva dentro de img/ o upload/: esos directorios nunca deberían contener PHP ejecutable, y una sola línea en tu .htaccess que deniegue la ejecución de PHP allí es una de las mejoras de endurecimiento más baratas una vez que estés limpio.

Coloca un pequeño .htaccess en cada directorio de subidas (img/, upload/, download/) para que, aunque vuelva a caer allí una shell, el servidor se niegue a ejecutarla. En Apache 2.4:

# img/.htaccess (and upload/, download/) — refuse to execute PHP
<FilesMatch "\.(php|php\d|phtml|phar)$">
    Require all denied
</FilesMatch>
php_flag engine off

Esto es contención, no una solución: impide que se ejecute una web shell plantada, pero no resuelve cómo se escribió el archivo en primer lugar. Para eso sirve la búsqueda del punto de entrada más abajo.

Por el lado de la base de datos, vuelca la tabla y compara tu lista de ps_employee con las personas que realmente trabajan contigo, y busca en el contenido CMS/configuración <script, base64_decode, eval( y dominios externos que no reconozcas. Si la brecha resulta ser específicamente un skimmer en el proceso de pago, merece la pena entender en detalle cómo entró y cómo extrae tarjetas: diseccionamos uno real en la anatomía de un ataque estilo Magecart contra una tienda PrestaShop.

Cierra las puertas: rota todas las credenciales que pueda tener el atacante

Da por hecho que el atacante tiene una copia de todo lo que pudo leer, y rótalo todo. En PrestaShop, "todo" es más largo de lo que la gente espera, y saltarse un elemento significa que entrarán de nuevo sin esfuerzo:

• Todas las contraseñas de empleados del panel de administración — y elimina cualquier cuenta que no puedas justificar. Fuerza un restablecimiento para todo el equipo, no solo para ti.
• Las credenciales de la base de datos en config/settings.inc.php (PS 1.6) o app/config/parameters.php (PS 1.7+). Cambia la contraseña del usuario MySQL y actualiza el archivo en el mismo movimiento.
• Las claves de cookies — las constantes _COOKIE_KEY_/_COOKIE_IV_ en settings.inc.php en PS 1.6, o los valores cookie_key/cookie_iv (y new_cookie_key cuando exista en PS 8/9) en parameters.php en PS 1.7+. Si se filtraron, las cookies antiguas de sesión de administrador aún podrían ser válidas. Rotar solo las claves no basta: después de rotarlas, borra las sesiones activas del lado del servidor y la caché, y luego obliga a todos los empleados a cerrar sesión y restablecer su contraseña. Eso es lo que realmente mata la sesión del atacante.
• Accesos FTP/SFTP, SSH y al panel de hosting — una contraseña FTP robada es la forma más común de que un sitio "limpio" vuelva a infectarse en cuestión de horas.
• Cualquier clave API / secreto de webhook de integraciones de pago y envío almacenado en la configuración de módulos.

Una vez rotadas las credenciales, este es el momento de cerrar la puerta de forma definitiva con autenticación de dos factores en el panel de administración, para que una contraseña filtrada por sí sola ya no sea suficiente. El paso a paso está en autenticación de dos factores, políticas de contraseñas y seguridad de administración para PrestaShop. Si tu investigación mostró que el ataque entró a base de golpear el inicio de sesión o mediante IP abusivas, añadir capas como bloqueos de IP y reCAPTCHA en el formulario de inicio de sesión mitiga los intentos automatizados de acceso. No lo trates como una solución completa: reCAPTCHA puede saltarse y no hace nada contra los ataques de relleno de credenciales con una contraseña robada válida, así que combínalo con 2FA, limitación de tasa y estrangulamiento por IP, contraseñas de empleados fuertes y únicas, y monitorización de registros.

El reloj de 72 horas: tus obligaciones bajo el RGPD

Si tu tienda tiene clientes europeos — y si envías a la UE o usas un procesador de pagos europeo, los tiene — el RGPD convierte un incidente técnico en un asunto legal con un plazo estricto. La regla que suele pillar a la gente por sorpresa: tienes 72 horas desde que tienes conocimiento de la brecha para notificarlo a tu autoridad de control (la autoridad de protección de datos de tu país), salvo que sea improbable que la brecha suponga un riesgo para los derechos de las personas. Una brecha que implique contraseñas, direcciones o datos de pago de clientes supera ese umbral con facilidad, así que planifica la notificación.

Si es probable que la brecha suponga un alto riesgo para las personas — de nuevo, los datos de pago y las contraseñas califican — también debes notificar directamente a los clientes afectados, en lenguaje claro, explicando qué ocurrió, qué datos estuvieron implicados, qué estás haciendo y qué deberían hacer ellos (cambiar su contraseña, vigilar sus extractos, esperar phishing que haga referencia a la brecha). Precisamente por eso importa la instantánea de pruebas del primer paso: no puedes escribir una notificación honesta si destruiste los datos que te dicen a qué se accedió realmente. El reloj de 72 horas empieza cuando tienes conocimiento, no cuando terminas de investigar; por eso la notificación suele salir mientras la remediación sigue en curso, con un seguimiento cuando sepas más. Eso está permitido y es lo esperable.

Una nota práctica que es fácil pasar por alto: este reloj corre en paralelo con todo lo demás de esta guía. La contención, el análisis forense y la notificación legal ocurren al mismo tiempo, que es la razón principal para mantener un registro continuo, con marca de tiempo, de cada acción que realizas desde la primera hora. Ese registro es tanto tu línea de tiempo forense como tu prueba de diligencia si un regulador la solicita.

Informar a los clientes sin empeorar las cosas

Los clientes perdonan a la tienda que se lo comunicó primero y desprecian a la que les hizo enterarse por su banco o por las noticias. La función de la notificación es ser honesta y útil, no minimizar. Explica lo ocurrido en términos humanos, exactamente cuáles de sus datos estuvieron implicados y las acciones concretas que deberían tomar; y dirige las respuestas a un canal que no ahogue tu soporte normal. Una dirección dedicada a la respuesta ante la brecha mantiene los correos nerviosos de "¿me ha afectado?" fuera de la cola de preguntas sobre pedidos.

Prepárate también para los oportunistas: las notificaciones de brechas son un imán para los phishers que se harán pasar por ti para "ayudar a los clientes a restablecer su contraseña". Indica a los clientes en la notificación exactamente qué canal usarás y que nunca les pedirás su contraseña. Cuesta una frase y evita una segunda oleada de víctimas.

No restaures la infección: reconstruir desde un estado limpio

El error de recuperación más común es restaurar la copia de seguridad de anoche. Si el atacante llevaba dos semanas dentro, la copia de anoche también contiene la puerta trasera; restaurarás el compromiso y volverás a descubrirlo el mes que viene. Trabaja hacia atrás desde tu instantánea de pruebas para identificar cuándo apareció el primer archivo malicioso o la primera fila de empleado, y luego restaura desde una copia anterior a ese momento o, de forma más fiable, reconstruye en limpio:

• Reinstala el núcleo de PrestaShop desde una descarga nueva de tu versión exacta: reemplaza los archivos del núcleo en bloque en lugar de intentar limpiarlos quirúrgicamente.
• Reinstala cada módulo desde su fuente original (el desarrollador, no tu copia posiblemente manipulada). Todo lo que no puedas obtener limpiamente, descártalo.
• Vuelve a aplicar solo los archivos de override/ y los cambios del tema que puedas justificar con seguridad.
• Migra los datos (pedidos, clientes, productos) desde la base de datos, pero solo después de limpiarla buscando cargas útiles inyectadas.

Este es también el momento de arreglar tu estrategia de copias de seguridad para que una reconstrucción limpia sea posible la próxima vez: copias automáticas diarias, almacenadas fuera del servidor de producción, con retención suficiente (piensa en más de 30 días) para poder retroceder más allá de una intrusión lenta. Una copia de seguridad que solo llega tres días atrás no sirve contra un atacante que permaneció silencioso dos semanas.

Cuando pase la tormenta: cierra el vector para siempre

Has encontrado el punto de entrada durante el análisis forense; ahora ciérralo de forma permanente, porque la reinfección por el mismo agujero es el seguimiento más común de una brecha. La solución depende de lo que haya descubierto la investigación:

• ¿PrestaShop obsoleto o un módulo vulnerable? Actualiza. Si de verdad aún no puedes actualizar el núcleo (una realidad común en tiendas 1.6/1.7 muy personalizadas), el parcheo virtual te permite bloquear el exploit conocido en la capa de petición sin tocar código; lo cubrimos en endurecimiento avanzado para tiendas que aún no puedes actualizar.
• ¿Contraseña de administrador débil o reutilizada? Política de contraseñas más 2FA, según la guía de seguridad de administración.
• ¿Falta de seguridad en el transporte o un .htaccess con fugas? Configura bien HTTPS (configuración SSL/HTTPS) y bloquea las reglas del servidor (reglas de seguridad .htaccess), incluida la denegación de ejecución de PHP en directorios de subida.
• ¿No sabes ni por dónde empezar a endurecer la tienda? La explicación en lenguaje claro para no desarrolladores es cómo proteger tu tienda PrestaShop, y la versión exhaustiva es la lista de endurecimiento de seguridad.

Preguntas frecuentes

¿Cómo sé si mi tienda PrestaShop ha sido realmente hackeada o si solo es spam?

Busca cosas que un spammer no puede fingir: una fila en ps_employee que no creaste, archivos PHP modificados en los últimos días que tú no tocaste (find . -name "*.php" -mtime -7), PHP ejecutable dentro de img/ o upload/, <script o base64_decode inesperados en tus páginas CMS o configuración, o tu tienda redirigiendo a los visitantes a otro sitio pero no a ti. Los carritos basura y el spam de formularios hacen ruido, pero son inofensivos; cuentas nuevas de administrador, scripts inyectados y archivos del núcleo manipulados son una intrusión.

¿Debo dejar mi tienda fuera de línea inmediatamente?

Deja el escaparate fuera de línea para los clientes con el modo mantenimiento, pero mantén el servidor en marcha para poder investigar. Apagar toda la máquina borra pruebas volátiles (sesiones activas, procesos del atacante) antes de que hayas averiguado cómo entraron; y sin el punto de entrada, volverás a infectarte en cuestión de días. La única excepción es un skimmer de tarjetas activo en el proceso de pago: ahí, detener la exposición de los clientes va primero, y llamas a tu proveedor de pagos en paralelo.

¿No puedo simplemente restaurar la copia de seguridad de anoche y seguir adelante?

Normalmente, no. Si el atacante llevaba dos semanas dentro, la copia de anoche también contiene la puerta trasera, así que restaurarías el compromiso y volverías a descubrirlo el mes que viene. Trabaja hacia atrás desde tu instantánea de pruebas para encontrar cuándo apareció el primer archivo malicioso o la primera fila de empleado, y luego restaura desde una copia anterior a ese momento; o, de forma más fiable, reconstruye en limpio desde una descarga nueva del núcleo y fuentes originales de módulos, migrando solo datos que hayas limpiado con búsquedas.

¿Tengo que informar de la brecha a alguien?

Si tu tienda tiene clientes de la UE y la brecha afectó a datos personales (contraseñas, direcciones, datos de pago), el RGPD te da 72 horas desde que tienes conocimiento para notificar a tu autoridad de control, y debes notificar directamente a los clientes afectados si el riesgo para ellos es alto. El reloj empieza cuando tienes conocimiento, no cuando terminas de investigar, así que la primera notificación suele enviarse mientras la remediación sigue en marcha, con un seguimiento posterior. Eso es lo esperado.

¿Cómo evito que vuelva a ocurrir?

Cierra el vector exacto que encontró tu análisis forense: parchea el núcleo o el módulo obsoleto, elimina la contraseña débil de administrador, arregla el directorio de subidas con fugas, porque la reinfección por el mismo agujero es el seguimiento más común de una brecha. Después añade las capas que hacen más difícil el siguiente intento: 2FA en el panel de administración, copias de seguridad fuera del servidor con más de 30 días de retención, y la lista de endurecimiento completa.

La parte realmente difícil de recuperarse tras una brecha no es la limpieza: es saber en qué momento has cerrado de verdad todas las puertas, porque una puerta trasera olvidada significa repetir todo esto. Si prefieres no cargar solo con esa incertidumbre, nuestro equipo construye y audita tiendas PrestaShop a diario y trabaja directamente con propietarios de tiendas en incidentes exactamente como este: sin intermediarios, sin capa de revendedores. ¿Qué obtienes con eso? Un segundo par de ojos que sabe dónde se esconden las infecciones de PrestaShop, para que puedas reabrir el escaparate con la confianza de que está realmente limpio, no solo con la esperanza de que lo esté.

Una última cosa, y es la más importante: anota lo que hiciste, en orden, con marcas de tiempo, en cuanto pase la urgencia inmediata. Ese registro es tu prueba para el RGPD, tu reclamación al seguro y, cuando lo releas con calma la semana que viene, la auditoría de seguridad más honesta que tendrás de tu propia tienda. La mayoría de las brechas se remontan a una actualización pospuesta o a una contraseña que todos compartían. Eso no es mala suerte; es la lista de tareas que ahora ya no tienes excusa para ignorar.