Por qué tu web se reinfecta: erradicar puertas traseras persistentes (BaaS)

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

La pregunta que más recibimos en incidentes recurrentes es siempre la misma: por qué mi web se reinfecta por más que la limpie. La respuesta, dura pero útil, es que no la limpiaste del todo. La reinfección casi nunca es un ataque nuevo e independiente; es el mismo compromiso que sobrevivió porque la limpieza persiguió el síntoma -el web shell visible, el spam en la home- y dejó intacta la persistencia que lo regenera. Entender esa distinción es el núcleo de nuestra investigación de referencia, Anatomía del hackeo: persistencia, backdoors y SEO-spam, y es lo que separa una desinfección real de un parche temporal.

Por qué mi web se reinfecta: síntoma frente a persistencia

Un atacante competente nunca deja una sola puerta. Cuando compromete un WordPress, planta varios mecanismos redundantes precisamente para que una limpieza apresurada no le eche. La víctima ve y elimina lo evidente -el fichero que Google marcó, el enlace de farmacia en el pie de página- pero los mecanismos de reentrada permanecen: un usuario administrador oculto, una tarea programada, una función maliciosa en la base de datos, credenciales robadas que siguen siendo válidas. Cualquiera de ellos basta para que, en horas o días, todo vuelva a estar como antes.

La reinfección, por tanto, no es mala suerte ni un segundo ataque: es la prueba de que la persistencia sigue en pie. Y localizar dónde se esconde exige revisar todas las capas del sitio, no solo los ficheros PHP que saltan a la vista.

Los escondites habituales de la persistencia

En nuestra experiencia forense, la puerta que sobrevive suele estar en uno de estos sitios:

• Usuarios administradores fantasma: cuentas con rol de administrador creadas por el atacante, a veces con nombres que imitan servicios legítimos. Mientras existan, el intruso vuelve a entrar por la puerta principal sin necesidad de web shell.
• Tareas programadas: cron jobs que reescriben el backdoor cada pocos minutos. Es la causa más frecuente de la reinfección «instantánea» y la desglosamos en Cron jobs y tareas fantasma.
• La base de datos: no solo opciones alteradas, sino triggers de MySQL que reinyectan el payload cada vez que se ejecuta una consulta rutinaria. Es una de las persistencias más difíciles de detectar porque no toca ni un solo fichero; la analizamos a fondo en Triggers de MySQL maliciosos: la puerta trasera dentro de tu base de datos.
• Web shells dispersos: no uno, sino varios, camuflados entre plugins legítimos o en uploads, para que borrar uno no elimine el acceso. La técnica está catalogada en MITRE ATT&CK como Web Shell (T1505.003).
• Credenciales comprometidas: contraseñas de FTP, del panel de hosting o claves de la base de datos que el atacante ya conoce. Si no se rotan todas, el acceso legítimo del intruso permanece aunque el código esté impecable.

Backdoor-as-a-Service: cuando el acceso a tu web es un producto

Hay un factor que explica por qué algunas webs se reinfectan una y otra vez incluso tras limpiezas cuidadosas: el acceso a tu sitio se ha convertido en mercancía. En el ecosistema del cibercrimen actual, quien vulnera una web no siempre es quien la explota. El acceso persistente se empaqueta y se revende a terceros -para enviar spam, alojar phishing, minar criptomonedas o inyectar SEO-spam- en un modelo que llamamos Backdoor-as-a-Service. Lo detallamos en Backdoor-as-a-Service: el mercado negro que revende el acceso a tu web.

La consecuencia práctica es demoledora: aunque erradiques a un operador, el acceso puede seguir en manos de otro comprador que reactiva su propia carga días después. Por eso, en estos casos, la limpieza del código es solo la mitad del trabajo; la otra mitad es cerrar y rotar por completo toda la superficie de acceso para invalidar cualquier credencial o puerta que se esté comercializando a tus espaldas.

Erradicación real: el orden importa

Romper el ciclo de reinfección exige método, no fuerza bruta. El procedimiento que aplicamos sigue siempre esta lógica:

• Primero, mapear toda la persistencia -usuarios, cron, triggers, ficheros, credenciales- antes de borrar nada, para no dejar cabos sueltos.
• Después, cerrar el acceso: rotar todas las contraseñas y claves, revocar sesiones y eliminar cuentas fantasma. Sin esto, cualquier limpieza posterior es papel mojado.
• Solo entonces, eliminar los backdoors y desactivar las tareas y triggers que los regeneran.
• Por último, cerrar la vía de entrada original -el plugin vulnerable, el core desactualizado- para que el atacante no repita el mismo camino.

Saltarse el orden es la causa número uno de que la reinfección persista: si limpias los ficheros pero no rotas las credenciales, el intruso vuelve a entrar y a plantarlo todo de nuevo. Y hay un beneficio colateral que no conviene olvidar: mientras el sitio siga sirviendo spam, Google lo penaliza, por lo que erradicar la persistencia es también recuperar la posición perdida frente a las políticas de spam de Google.

Cuándo dejar de limpiar y llamar a un forense

Si has limpiado tu web dos o más veces y vuelve a infectarse, deja de repetir el mismo procedimiento: no funciona porque no ataca la raíz. Ese patrón indica una persistencia que requiere una investigación completa del sistema de ficheros, la base de datos y los registros de acceso. En entornos exigentes -banca, comercios que procesan datos de tarjeta- una reinfección no es una molestia estética, sino una brecha activa con implicaciones de cumplimiento y de exposición de datos, y ahí la erradicación tiene que ser total y documentada. Publicaciones de referencia como el blog de Sucuri confirman que la reinfección es, casi siempre, persistencia mal erradicada, no un ataque nuevo.

Si tu web ya ha vuelto a caer después de limpiarla, es momento de mapear la persistencia completa en lugar de repetir el ciclo. Habla con nuestro equipo y planteamos una erradicación de raíz.