Por qué tu web se vuelve a hackear: persistencia, admins ocultos y triggers

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

La pregunta «por qué mi web se vuelve a hackear» aparece siempre después de la segunda o tercera limpieza fallida: pagas a alguien, borra el malware, y en cuestión de horas o días vuelve todo. No es mala suerte ni un atacante obsesionado contigo: es persistencia mal erradicada. Este artículo forma parte de nuestra serie Anatomía del hackeo: persistencia, backdoors y SEO-spam, y aquí explicamos los mecanismos concretos que hacen que una infección resucite.

La regla de oro de la respuesta a incidentes es esta: limpiar los síntomas no elimina la infección. Si solo borras las páginas de spam o el archivo malicioso que te saltó en el antivirus, estás quitando la punta del iceberg. Debajo queda una cadena de acceso diseñada precisamente para sobrevivir a ese barrido.

Los cuatro motivos por los que mi web se vuelve a hackear

En la práctica forense, cuando investigamos por qué una web se vuelve a hackear, casi siempre encontramos una o varias de estas causas conviviendo:

• Backdoors y web shells repartidos por el sistema de archivos. Un solo script PHP ofuscado en uploads/ basta para reinstalar todo. Es la técnica Web Shell (T1505.003) de MITRE ATT&CK: acceso remoto persistente que ignora tus contraseñas.
• Administradores ocultos: usuarios con rol admin que no aparecen en el listado normal del panel porque el malware los filtra de la consulta. Cambias tu contraseña y el atacante entra con la suya.
• Triggers y tareas programadas: entradas en el cron de WordPress o en la base de datos que, cada X horas, comprueban si el payload sigue presente y lo reinyectan si falta. Limpias a mediodía, a medianoche vuelve.
• Vector de entrada abierto: el plugin vulnerable, la credencial filtrada por un infostealer o los permisos 777 que permitieron el primer acceso siguen ahí. Aunque limpies perfectamente, te vuelven a entrar por la misma puerta.

El trigger: el mecanismo que convierte una limpieza en un bucle

El componente más frustrante es el trigger. Imagina un pequeño vigilante dentro de tu web cuya única función es asegurarse de que el malware existe. Puede vivir en un mu-plugin, en una opción de la base de datos o en una función inyectada en el tema. Cuando tú borras el archivo malicioso, el trigger lo detecta en su siguiente ejecución y lo vuelve a crear desde cero, a veces con un nombre distinto para despistar.

Por eso la secuencia «borrar archivo → parece limpio → reaparece» es tan característica. No estás luchando contra un archivo, sino contra un proceso que lo regenera. Hasta que no localizas y eliminas el trigger —y el usuario oculto que lo respalda—, el bucle no se rompe.

Cómo romper el ciclo de reinfección de forma definitiva

Erradicar de verdad exige tratar la web como una escena y trabajar de forma completa, no por parches:

• Inventario total de persistencia: buscar todos los backdoors, no el primero que aparezca. Comparar el árbol de archivos con un core limpio revela los intrusos.
• Auditar usuarios directamente en la base de datos, no solo en el panel, para cazar los admins ocultos.
• Revisar cron y mu-plugins: ahí viven los triggers que reinyectan.
• Rotar TODAS las credenciales a la vez: WordPress, base de datos, FTP/SFTP, hosting y API. Si dejas una sin cambiar, el acceso sigue vivo.
• Cerrar el vector original: actualizar o retirar el plugin culpable, y verificar que la credencial filtrada ya no sirve.

Todo esto debe hacerse en una sola ventana de limpieza. Si rotas contraseñas hoy pero dejas un backdoor para mañana, el atacante simplemente vuelve a robar las nuevas. La coordinación es lo que rompe el ciclo.

Cuando la reinfección esconde una operación mayor

A veces tu web no es el objetivo, sino un nodo. La reinfección persistente es típica de campañas que explotan muchos sitios a la vez —por ejemplo para SEO spam o apuestas— y ocultan el contenido al dueño mediante engaño al rastreador. Ese engaño lo explicamos en cloaking y doble-fetch, y una de sus variantes más molestas, con miles de URLs en japonés, en el japanese keyword hack. En esos casos, el spam que reaparece viola las políticas de spam de Google y penaliza tu posicionamiento mientras el bucle siga abierto.

Si tu web ya se ha reinfectado varias veces, o si manejas datos sensibles —una tienda con pago con tarjeta o un entorno bancario—, conviene tratar el caso como respuesta a incidentes seria, no como una limpieza más. Es el tipo de escenario exigente que abordamos en PathSentinel. Para ampliar sobre firmas de estos kits, el blog de Sucuri es una referencia útil.