El skimmer que el administrador no ve: WebRTC en el checkout

A finales de julio de 2026, Rekire estaba terminando de limpiar una tienda hackeada cuando un detalle no le cuadraba: en el checkout, al elegir pago con tarjeta, a algunos clientes les salía un formulario para escribir la tarjeta en la propia tienda. Y el módulo de pago de esa tienda siempre redirige al banco. Respuesta corta: era un skimmer preparado para que el administrador no lo viera nunca, y no estaba en los ficheros que se suelen comparar.

Cómo se escondía

• No salía con la sesión del back-office abierta. Gustavo lo sospechó enseguida: con la cookie de la sesión de administrador, el formulario no aparecía.
• No se dejaba reproducir. Rekire no consiguió verlo ni desde el móvil, ni en incógnito, ni con otros navegadores o IP. Según Gustavo, el formulario tardaba dos o tres segundos en aparecer y el script elegía a quién mostrárselo, por ejemplo según la IP del visitante.
• No estaba donde se compara. Comparando ficheros y base de datos con una copia de hacía más de cinco meses no aparecían diferencias fuera de lo normal. Lo que sí apareció: una función comentada en el custom.js del tema que mostraba y ocultaba un bloque con un identificador casi igual a uno legítimo (con una «р» cirílica), y un trozo de la caché del menú del back-office con un script que, la primera vez (lo controlaba con una marca en localStorage), redirigía al administrador a un dominio que imitaba al de Addons de PrestaShop.

Qué hacía el código, ya desofuscado

Gustavo lo desmontó entero. El cargador estaba troceado y se montaba con Function([trozos].join(""))() para no dejar cadenas reconocibles. Después:

1. Abría un canal WebRTC hacia un servidor del atacante en el puerto 443. WebRTC no va por fetch ni por XHR, así que no aparece en la pestaña de red como una petición normal ni lo ven las extensiones que vigilan el tráfico HTTP.
2. Por ese canal descargaba la segunda fase, la descomprimía y la inyectaba como un <script> copiando el nonce de un script legítimo de la página. Así se saltaba la política de seguridad de contenidos (CSP).
3. La segunda fase escuchaba los campos de número, caducidad y CVC, todos los campos de la página (nombre, correo, teléfono), lo que se pegaba desde el portapapeles y el envío del formulario. Al pulsar «Pagar» mandaba todo.
4. Además sustituía XMLHttpRequest.send, con lo que veía todo el tráfico AJAX de la página.

El formateo del número en grupos de cuatro y la barra de la fecha eran solo fachada para que el formulario pareciera de verdad. Un mes antes, otro compañero había contado en el grupo un caso parecido: un formulario de tarjeta sin ningún distintivo que se abría dentro del checkout desde el código de un módulo de pago.

Dónde buscar si sospechas algo así

• Prueba como un cliente de verdad: navegador sin sesión del back-office, sin historial, otro equipo y otra conexión. Si tu módulo redirige al banco, cualquier formulario de tarjeta dentro de la tienda es una alarma.
• No te quedes en los PHP. Revisa el custom.js y los JS del tema, los textos guardados en la base de datos (configuración de módulos, páginas CMS, bloques de HTML) y las cachés de var/cache.
• Busca identificadores raros. Un id que parece legítimo pero lleva una letra de otro alfabeto no aparece al buscar el original.
• La CSP ayuda, pero no basta si el código ya está dentro y puede leer el nonce del DOM.

Después de limpiar

Rekire encontró más de una intrusión distinta en esa tienda. Por eso otro miembro del grupo recomendaba lo que muchas veces es más barato: migrar a una instalación limpia con módulos actualizados, porque si no sabes por dónde entraron, volverán a entrar. Y en cualquier caso: cambia todas las contraseñas (back-office, hosting, FTP, base de datos), la carpeta de administración y las claves de API.

Gustavo acabó escribiendo una extensión de navegador que revisa el back-office y la tienda mientras navegas y avisa de lo que parece peligroso. Rekire busca skimmers, puertas traseras y web shells en los ficheros con su módulo de alertas de seguridad. Si necesitas que limpiemos una tienda, lo hacemos dentro de un bono de horas.

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