Entran al back-office con usuario y contraseña: activa el 2FA

En julio de 2025 Gustavo avisó en mayúsculas: era la tercera vez en pocas semanas que entraban en el back-office de clientes con un usuario y una contraseña válidos. Habían instalado módulos maliciosos e incluso activado una forma de pago con la que hicieron una venta fraudulenta. Nada sofisticado: una contraseña robada y ningún segundo factor.

Lo que se vio en esas semanas

• Una pasarela de pago falsa activada desde el back-office. El dueño tuvo que denunciar ante la unidad de delitos informáticos de la Guardia Civil y preparar un informe para demostrar que no hubo robo de datos sino un acceso no autorizado. Y, si el banco no lo devolvía, reembolsar al cliente.
• Un empleado administrador creado directamente en la base de datos, con un id llamativo (9527), y accesos al back-office desde IP extranjeras que los registros confirmaban.
• Otro antiguo cliente al que entraron con un usuario administrador e intentaron instalar módulos raros.
• Un compañero al que entraron en la tienda de un cliente con su propio usuario. Según su análisis de los logs, cambiaron la contraseña de su empleado con una inyección SQL a través del buscador de la tienda, en una 8.1.4, conociendo ya su correo. Tenían hasta un bot de Telegram que les avisaba de cada acceso conseguido.

En agosto Rekire lo confirmó desde su lado: estaban viendo muchos ataques a versiones obsoletas, sobre todo inyecciones SQL para crear usuarios superadministradores.

Qué hacer

1. Doble factor para todos los empleados

Es lo que más corta este tipo de ataque: aunque tengan la contraseña, sin el código no entran. Gustavo desarrolló un módulo de 2FA para empleados que admite un código genérico mientras cada empleado configura su aplicación. Tres días después de avisar a 160 clientes por correo, además de por WhatsApp, le habían preguntado ocho, y de los avisos por WhatsApp solo dos le pidieron instalarlo. Su consejo para quien diga que es «molesto»: que firme que ha rechazado la medida.

Un detalle para quien desarrolle algo así, que salió en el grupo: los secretos TOTP no deberían guardarse en texto plano. Un compañero propuso cifrarlos con la librería de cifrado que ya trae PrestaShop (Defuse) y una clave derivada de la clave de cookies de la tienda, que entonces no se puede cambiar sin perder los secretos.

2. Actualizar

Las inyecciones SQL que crean administradores entran por versiones y módulos sin actualizar. Si la tienda está en una versión sin parches, actualizarla es parte de la seguridad, no un capricho.

3. Revisar empleados y accesos

• En Parámetros avanzados → Equipo, repasa la lista de empleados: cualquiera que no conozcas, fuera. Pero no te fíes solo del listado: el administrador con id 9527 no aparecía en él, y Gustavo lo encontró por los accesos. Revisa también la tabla employee de la base de datos.
• En Parámetros avanzados → Registros, filtra las conexiones al back-office y busca IP que no reconozcas. En 1.7 y 8 cada entrada deja una línea «Back office connection from» con la IP.
• Usa para el superadministrador un correo que no sea público ni el de la web.

4. Que la tienda te avise

En el caso del compañero, lo que hizo saltar la alarma fue ver «cosas raras» en un módulo. Mejor no depender de eso: pon un aviso automático cuando se instala un módulo, se crea un empleado o cambia un método de pago.

5. Si sospechas que conocen la URL del back-office

Cambia el nombre de la carpeta de administración y las contraseñas de todos los empleados.

Si tu tienda está en una versión antigua, en Rekire hacemos la actualización dentro del bono de 50 horas.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación