Saltar al contenido
Blindea.
Ayuda urgente

Conocimiento del sector

Los 6 patrones de infección que encontramos en tiendas online

Mi tienda redirige a spam. El malware vuelve después de limpiar. El hosting me ha suspendido la cuenta. Detrás de casi todas esas frases hay uno de estos seis patrones. No son casos de clientes: son las tipologías reales que se repiten en tiendas WooCommerce y PrestaShop, con dónde se esconde cada una y por qué los escáneres no las encuentran.

01 El más común · SEO spam

Redirección condicional a spam

Síntoma

Tú abres tu tienda y está perfecta. Pero tus clientes te dicen que al entrar desde Google acaban en una página de pastillas, casinos o réplicas. O lo ves solo desde el móvil. O no ves nada raro y simplemente las ventas han caído en picado sin explicación.

Qué está pasando de verdad

El código malicioso no redirige a todo el mundo: comprueba de dónde vienes. Si llegas escribiendo la URL o estás logueado como administrador, te sirve la web normal. Si vienes de una búsqueda de Google o desde un móvil, te manda al spam. Está diseñado exactamente para que el dueño no lo vea.

Por eso casi siempre se descubre tarde: por un aviso de Search Console, por un cliente que se queja, o por la caída de tráfico. Mientras tanto Google ya ha empezado a indexar las páginas de spam bajo tu dominio.

Dónde se esconde

  • Inyección en la base de datos, no en los archivos: en WooCommerce, registros de wp_options con nombres inocuos y JavaScript ofuscado en wp_posts.
  • Inyección en la base de datos, no en los archivos: en PrestaShop, valores modificados en ps_configuration y en el contenido de las páginas CMS.
  • Reglas de reescritura en .htaccess, a veces al final del archivo tras cientos de líneas en blanco para que no se vean al abrirlo.
  • Código inyectado en el header.php o el footer.php del tema.
  • Código inyectado en las plantillas del tema o en un módulo aparentemente legítimo.
  • Carga remota desde un dominio que imita a un CDN o a un servicio de analítica.

Por qué el plugin no lo encuentra

Un escáner que se ejecuta desde dentro de tu web se identifica como visitante directo, así que el malware se comporta bien delante de él. Y si la inyección está en la base de datos y no en un archivo, la mayoría de escáneres de integridad de ficheros ni la miran.

Qué hacemos

Reproducimos el comportamiento del atacante: peticiones simulando referrer de Google y user-agent móvil, desde fuera del servidor. Ahí aparece la redirección. Luego rastreamos la cadena hasta el origen —base de datos, .htaccess o tema— y limpiamos los tres frentes, porque casi nunca es solo uno.

Guía: mi tienda redirige a spam
02 La razón nº1 de reinfección

Backdoor persistente en carpetas de subidas

Síntoma

Ya limpiaste la tienda —tú, tu desarrollador o un plugin— y a los pocos días volvió exactamente lo mismo. Esa es la señal: no quedó un archivo suelto, quedó la puerta.

Qué está pasando de verdad

Un atacante que entra deja siempre una forma de volver. No le sirve el acceso que usó la primera vez, porque ese lo vas a parchear. Deja un archivo PHP pequeño en un sitio donde nadie mira, capaz de ejecutar comandos o subir más archivos. Con eso reinyecta todo cada vez que lo limpias.

El 49 % de las webs comprometidas tenía al menos un backdoor. Es el patrón más importante de esta lista. Fuente: Sucuri, Hacked Website Report 2023

Dónde se esconde

  • Dentro de wp-content/uploads/, en carpetas por año y mes donde nadie entra a mirar y donde muchos servidores permiten ejecutar PHP porque nadie lo ha bloqueado. Nombres camuflados que imitan al núcleo o empiezan por punto.
  • wp-content/mu-plugins/ — los «must-use plugins» se cargan siempre y no aparecen en la lista de plugins del panel. Si no sabes que esa carpeta existe, no la vas a revisar. Es uno de los escondites favoritos.
  • override/ — los overrides son un vector clásico en PrestaShop: se cargan en lugar de la clase original y no hay un archivo del núcleo con el que compararlos.
  • Módulos falsos con nombre creíble dentro de modules/, y archivos PHP colados en img/ o en la caché de Smarty.
  • Persistencia por tareas programadas: un evento en el cron del CMS o en el crontab del sistema que vuelve a escribir el malware cada X horas. Esto es lo que hace que la infección «vuelva sola».
  • Usuario administrador oculto: una cuenta con permisos totales en wp_users, escondida de la lista de usuarios mediante un filtro cargado desde un mu-plugin.
  • Empleado añadido en ps_employee con perfil de SuperAdmin, que pasa desapercibido entre las cuentas legítimas del back office.

Por qué el plugin no lo encuentra

Un escáner compara tus archivos con los originales del núcleo y busca firmas conocidas. Un backdoor de veinte líneas escrito a medida no tiene firma que coincidir, y en las carpetas de subidas o de módulos añadidos no hay original con el que comparar. Y ningún plugin revisa el crontab del sistema, porque vive fuera de la web.

Qué hacemos

Barrido de todos los directorios escribibles buscando PHP donde no debería haberlo, revisión de los cargadores que no salen en el panel, del cron del CMS y del crontab del sistema, y auditoría de usuarios y permisos contra la base de datos en crudo, no contra lo que muestra el panel. Y después bloqueamos la ejecución de PHP en las carpetas de subidas, que es lo que evita que se repita.

Guía: qué es un backdoor y por qué tu plugin no lo detecta
03 El más grave · Brecha de datos

Robo de tarjetas en el checkout (Magecart)

Síntoma

Normalmente ninguno. Este es el patrón que se descubre por un aviso de fuera: el banco o la pasarela detecta un pico de fraude con tarjetas usadas en tu tienda, o un cliente denuncia un cargo. La tienda funciona perfectamente y los escáneres no dicen nada.

Qué está pasando de verdad

Hay JavaScript inyectado en tu página de pago que escucha lo que el cliente teclea —número de tarjeta, caducidad, CVV— y lo envía a un servidor externo antes de que el formulario llegue a la pasarela. Tu pasarela de pago no se ha vulnerado: el robo ocurre en tu web, antes de llegar a ella.

Se activa solo en la URL del checkout. Un escáner que analiza tu portada no lo ve nunca.

Dónde se esconde

  • Un script cargado desde un dominio que parece legítimo: nombres que imitan a Google Analytics, a un CDN conocido o a una librería de pago habitual.
  • Código inyectado en el JavaScript del tema, cargado solo en la plantilla del checkout.
  • Un plugin o módulo legítimo modificado: el archivo tiene el nombre correcto y funciona bien, con unas líneas añadidas.
  • En PrestaShop, un override del controlador de pago, o un módulo de pago con el código alterado.
  • En WooCommerce, hooks enganchados al proceso de checkout, o un mu-plugin que inyecta el script solo en esa página.

Por qué el plugin no lo encuentra

Porque no mira ahí. Casi todos los escáneres analizan el HTML de la portada y comparan archivos del núcleo. Este código está condicionado a una URL concreta, cargado desde fuera, y con frecuencia ni toca un archivo del núcleo.

Qué hacemos

Analizamos la página de checkout renderizada como lo haría un cliente real, inventariamos todos los scripts que se cargan y de dónde vienen, y buscamos exfiltración a dominios externos. Al localizarlo, cortamos la fuga primero y luego rastreamos la vía de entrada.

Aquí no basta con limpiar

Si ha habido captura de datos de tarjeta o datos personales, es una brecha de seguridad con obligaciones legales: notificación a la AEPD en 72 horas y probablemente aviso a tu entidad adquirente. Documentamos el alcance y las fechas para que puedas cumplir con eso. Es un trabajo distinto al de una limpieza y por eso tiene su propia tarifa.

Guía: Magecart, robo de tarjetas en el checkout
04 Daño colateral duradero

Spam saliente y hosting suspendido

Síntoma

Tu hosting te suspende la cuenta por envío de spam o consumo anormal. O, más sutil: tus clientes dejan de recibir los correos de confirmación de pedido y crees que es un problema del plugin de emails.

Qué está pasando de verdad

Hay un script en tu servidor enviando correo masivo, normalmente abusando de la misma librería de envío que usa tu tienda para los emails legítimos. Tu servidor se convierte en un nodo de spam a tu costa.

El daño no acaba al limpiar: la IP del servidor y tu dominio han entrado en listas negras de correo. Aunque elimines el script hoy, tus emails transaccionales seguirán sin llegar. Esa parte es la que casi nadie te resuelve, y es la que te hace perder pedidos en silencio semanas después.

Dónde se esconde

  • Script de envío en un directorio escribible, a menudo acompañado de un archivo de texto con la lista de destinatarios.
  • Cola de correo del servidor con miles de mensajes pendientes que no salieron de tu tienda.
  • Un formulario de contacto o de suscripción sin protección usado como relay.
  • Y casi siempre, un backdoor del patrón 2: es por donde subieron el script.

Por qué el plugin no lo encuentra

Porque el problema está en el servidor, no en la web: la cola de correo, los logs de envío y la reputación de la IP viven fuera del alcance de cualquier plugin de WordPress o módulo de PrestaShop.

Qué hacemos

Localizamos y eliminamos el emisor, purgamos la cola de correo, cerramos el relay, y gestionamos la reactivación con tu hosting aportándoles el informe de lo que se hizo —que es lo que suelen pedir para levantar la suspensión—. Y solicitamos la retirada de las listas negras de correo y la recuperación de reputación de la IP y el dominio, que es el paso que casi nadie da.

Guía: el hosting ha suspendido tu cuenta por malware
05 La vía de entrada más frecuente

Entrada por componente desactualizado

Síntoma

Ninguno, hasta que aparece cualquiera de los patrones anteriores. Este no es un síntoma: es la puerta por la que entraron.

Qué está pasando de verdad

El núcleo del gestor no suele ser el problema: lo son los plugins, módulos y temas.

Cuando se publica una vulnerabilidad en un plugin popular, empieza el escaneo automático masivo. No te eligen a ti: barren internet buscando la versión vulnerable. Entre que se publica el parche y tú lo aplicas hay una ventana, y es en esa ventana donde ocurre casi todo.

En una tienda esto pesa más que en un blog: más plugins instalados, más módulos de pago y envío, plantillas modificadas que no se pueden actualizar sin romper el escaparate, y desarrollos a medida que se quedaron sin mantenimiento cuando acabó el proyecto.

Casi 4 de cada 10 webs comprometidas (39,1 %) tenían el gestor de contenidos desactualizado en el momento de la infección. Fuente: Sucuri, Hacked Website Report 2023

Dónde se esconde

  • Plugins y módulos abandonados por su autor: nunca van a recibir el parche.
  • Plugins desactivados pero todavía presentes en el servidor: el código sigue siendo accesible y explotable. Desactivar no es desinstalar.
  • Temas comerciales con librerías antiguas empaquetadas dentro.
  • En WooCommerce, temas hijo y plugins a medida que tocan el checkout y nadie se atreve a actualizar por si dejan de cobrar.
  • En PrestaShop, overrides y módulos a medida heredados de una migración de versión mayor, que bloquean la actualización del núcleo.
  • Y el clásico: la tienda se actualizó una vez, se rompió algo, y desde entonces nadie ha vuelto a tocar nada por miedo.

Por qué el plugin no lo encuentra

Un escáner sí te avisa de que hay actualizaciones pendientes. El problema no es detectarlo, es que nadie lo aplica: actualizar una tienda en producción da miedo con razón, porque un módulo de pago que falle cuesta ventas. Así que la notificación se ignora mes tras mes. Y hay una parte que ni siquiera llega a avisar: el aviso del panel solo cubre lo que viene del canal oficial. Un componente retirado del repositorio oficial deja de compararse con nada y desaparece del contador, aunque siga instalado y activo; lo comprado en marketplaces de terceros no notifica nunca. Como el componente sigue funcionando con normalidad, nadie lo retira: solo deja de recibir parches, y nada indica que haya que actuar.

Qué hacemos

Identificamos la vía de entrada real revisando los logs de acceso, para saber qué se explotó y cuándo. Sin eso no se puede cerrar, y limpiar sin cerrar la puerta es garantizar la reinfección. Después actualizamos con copia previa y verificación de que la tienda sigue vendiendo: catálogo, carrito y pasarela probados. Y te decimos qué componentes deberías retirar porque ya no los mantiene nadie.

Checklist para proteger tu tienda
06 La reinfección que vuelve

La limpieza superficial que vuelve

Síntoma

Pagaste una limpieza. Te dijeron que estaba resuelto. A los tres días, a la semana o al mes, volvió lo mismo.

Qué está pasando de verdad

Se limpió lo visible y quedó el mecanismo. Es la consecuencia directa del patrón 2: mientras siga en pie el backdoor, la tarea programada o el usuario oculto, la infección se restaura sola. El escáner vuelve a decir «limpio» porque los archivos que conoce están correctos.

Suele pasar cuando la limpieza consistió en pasar un plugin de seguridad y borrar lo que marcó, o en restaurar una copia de seguridad que ya estaba infectada —porque el compromiso empezó antes de lo que se cree, y la copia «buena» traía el backdoor dentro—.

Dónde se esconde

  • En los mismos sitios del patrón 2: carpetas de subidas, cargadores que no salen en el panel, tareas programadas y cuentas de administrador ocultas.
  • Y uno específico de este patrón: dentro de la propia copia de seguridad que se usó para restaurar.

Por qué el plugin no lo encuentra

Porque hizo su trabajo: limpiar lo que sabe reconocer. Lo que no puede hacer es preguntarse cómo volvió a entrar. Eso requiere leer logs, comparar fechas de modificación y entender la cadena completa desde la vía de entrada hasta la persistencia. Es trabajo de análisis, no de escaneo.

Qué hacemos

Empezamos por el final: en lugar de buscar malware, buscamos el mecanismo de retorno. Correlacionamos fechas de modificación de archivos con los logs de acceso para reconstruir la secuencia: por dónde entraron, qué dejaron, qué lo dispara. Solo cuando eso está claro tiene sentido limpiar, porque entonces se puede cerrar. Y por eso podemos ofrecer garantía de 30 días: si el mecanismo de retorno sigue vivo, la limpieza no vale nada, y lo sabemos antes de darla por cerrada.

Guía: por qué vuelve la infección en WooCommerce

¿Reconoces alguno?

Si has identificado tu situación en alguno de estos patrones, ya tenemos por dónde empezar a mirar. Y si no encaja en ninguno, el diagnóstico es gratis igualmente: lo miramos y te decimos qué hay.

Pedir diagnóstico gratis

Según tu tienda

WooCommerce hackeado

Rutas, tablas y escondites propios de WordPress y WooCommerce.

PrestaShop hackeado

Overrides, módulos, tablas y caché de plantillas de PrestaShop.

Que no vuelva a pasar

Guardia gestionada: el mantenimiento que evita estos patrones.

¿Mantienes tiendas de clientes? Tenemos un canal para agencias: escalas el incidente y tu cliente sigue siendo tuyo.

Canal para agencias