Cómo encontrar una puerta trasera en tu web (y por qué se reinfecta)

Si has limpiado tu web y a los dos días vuelve a estar infectada, no es que la limpieza fallara: es que quedó una puerta trasera. Es un trozo de código que el atacante deja escondido para poder volver a entrar cuando quiera, aunque cambies las contraseñas y actualices todo. Mientras esa puerta siga ahí, limpiar es como achicar agua sin tapar la vía. En esta guía tienes dónde se esconden, cómo reconocerlas sin ser programador y cómo comprobar que no queda ninguna.

Aviso realista desde el principio: encontrar puertas traseras es de lo más difícil de una limpieza. Algunas son evidentes; otras están partidas en varios trozos o escondidas dentro de un archivo legítimo, y ahí ya hace falta ojo entrenado. Vamos a por las que sí puedes cazar tú, y al final te digo cuándo conviene parar y pedir ayuda.

Por qué una web recién limpiada se reinfecta enseguida

El orden de los ataques suele ser este: entran, dejan una o varias puertas traseras primero, y después montan el spam, las redirecciones o lo que vayan a monetizar. Cuando tú ves el problema y limpias, borras lo visible (el spam) pero no lo que dejaron escondido para volver. A las pocas horas, o en un par de días, un proceso automático usa esa puerta y lo reconstruye todo.

Por eso una reinfección rápida no significa que hayas limpiado mal el spam: significa que la puerta sigue abierta. Y por eso restaurar una copia de seguridad muchas veces no arregla nada: si la copia es posterior a la intrusión, la puerta trasera viene incluida en la copia.

Los escondites habituales: uploads, mu-plugins y temas inactivos

Las puertas traseras se meten donde menos miras y donde no deberían existir archivos ejecutables. Los sitios clásicos en un WordPress:

• /wp-content/uploads/: esta carpeta es para imágenes y PDF. Si encuentras ahí un archivo .php, es sospechoso por definición: no hay ninguna razón legítima para que un PHP viva entre las fotos.
• /wp-content/mu-plugins/: los must-use plugins se cargan solos, sin aparecer en la lista normal de plugins del panel. Es un escondite perfecto porque desde el administrador ni los ves. Muchas webs no usan esta carpeta; si la tuya la tiene y no la creaste tú, revísala entera.
• Temas y plugins inactivos: un tema que no usas sigue teniendo sus archivos en el servidor. El atacante mete la puerta ahí porque sabe que nadie mira un tema desactivado. Lo mismo con plugins desactivados pero no borrados.
• El propio wp-config.php y los index.php: a veces añaden unas líneas al principio o al final de un archivo legítimo, para que no salte a la vista.

Y hay un escondite que no es un archivo: la propia base de datos. Algunas puertas traseras se guardan como una opción de WordPress (en la tabla wp_options) o dentro del contenido de un widget o de una entrada, y desde ahí se ejecutan. Estas son de las más difíciles de encontrar a mano, porque no aparecen ordenando archivos por fecha; hay que mirar dentro de la base de datos, y por eso mucha limpieza que solo toca ficheros las deja pasar.

Buscar por fecha de modificación y por patrones de código

Tu mejor herramienta gratis es la fecha de modificación. Entra por FTP o por el administrador de archivos del hosting y ordena los archivos por fecha, de más nuevo a más antiguo. Si sabes aproximadamente cuándo empezó el problema, todo lo modificado en esa ventana que tú no tocaste es candidato a revisar. Un archivo del núcleo de WordPress con fecha de la semana pasada, cuando tú no actualizaste nada, no debería tener esa fecha.

Después, busca por patrones. Si tu hosting te deja usar SSH, comandos como buscar dentro de los .php las funciones que usan casi todas las puertas traseras te ahorran horas. Las señales a buscar dentro del código son funciones como eval(, base64_decode(, gzinflate(, str_rot13(, assert(, system(, shell_exec( o preg_replace con el modificador /e. No todas son malas por sí solas (algún plugin legítimo usa alguna), pero varias juntas en un archivo pequeño y raro es un patrón claro. Si no tienes SSH, muchos hostings permiten esa búsqueda desde su administrador de archivos, o puedes descargar la web y buscar en tu ordenador con cualquier editor de código.

Código ofuscado: cómo reconocerlo sin saber programar

No necesitas entender el código para oler que algo va mal. Las puertas traseras casi siempre están ofuscadas: escritas a propósito para que no se entiendan. Aprende a reconocer el aspecto:

• Líneas larguísimas, de miles de caracteres, sin saltos, con letras y números aparentemente aleatorios (eso suele ser texto codificado en base64).
• Bloques con muchísimos chr(), x seguidos de números, o cadenas partidas en trocitos y pegadas con puntos.
• Variables con nombres sin sentido como $_x1a2 o funciones que reciben $_POST, $_GET o $_COOKIE y los meten directamente en eval.
• Código apretado en una sola línea cuando el resto del archivo está bien ordenado.

El código legítimo de WordPress y de los plugins serios está comentado, ordenado y es legible. Cuando abres un archivo y parece que alguien ha querido esconder lo que hace, normalmente es exactamente eso.

Puertas traseras fuera del CMS: cron, .user.ini y el panel del hosting

Aquí es donde la gente se rinde, porque la puerta ni siquiera está en WordPress. Revisa:

• Tareas programadas (cron) en el panel del hosting. Un atacante puede dejar un cron que cada hora vuelve a descargar y colocar el malware. Aunque limpies los archivos, el cron los repone. Mira la lista de tareas programadas del cPanel o del panel que uses y borra las que no reconozcas.
• Archivos .htaccess y .user.ini: se usan para redirigir tráfico o para cambiar la configuración de PHP y cargar código malicioso automáticamente. Un .htaccess con redirecciones raras es, además, la causa típica de que tu web redirija a otra página.
• Reglas de reenvío de correo y cuentas de email creadas en el hosting, que a veces se usan para mantener el acceso o para el spam saliente.

Cuentas de FTP y claves SSH añadidas por el atacante

Una puerta trasera no siempre es un archivo: a veces es un acceso. En el panel del hosting revisa:

• Cuentas de FTP: si hay alguna que tú no creaste, el atacante tiene entrada directa a tus archivos sin pasar por WordPress. Bórrala y cambia la contraseña de la principal.
• Claves SSH autorizadas: mira el archivo ~/.ssh/authorized_keys. Una clave que no reconozcas es una llave de tu casa en manos ajenas.
• Usuarios administradores de WordPress que no reconozcas, y usuarios de la base de datos añadidos.

Cambia todas las contraseñas (WordPress, FTP, base de datos, panel del hosting) después de haber cerrado las puertas, no antes: si lo haces antes de sacar el código malicioso, algunas puertas te capturan las contraseñas nuevas.

Cómo comprobar que ya no queda ninguna

Cerrar la última puerta y estar seguro de que era la última son dos cosas distintas. La comprobación honesta:

1. Vuelve a pasar la búsqueda por patrones sobre toda la web una vez limpiada. Si sale limpia y las fechas de modificación ya no muestran nada raro, buena señal.
2. Vigila los primeros días. La prueba de fuego es el tiempo: si a los dos o tres días no ha vuelto a aparecer nada, es muy probable que cerraras todo. Aquí es donde entra la limpieza completa bien hecha más la vigilancia.
3. Sé sincero con tu límite. Si la web se ha reinfectado dos veces a pesar de tu limpieza, es la señal más clara de que hay una puerta que no estás viendo. Algunas están tan bien escondidas (partidas en tres archivos, o dentro de la base de datos) que sin herramientas de comparación de ficheros es casi imposible dar con ellas. En ese punto, seguir a ciegas cuesta más que pedir una mano.

Cuando no estás seguro de que no quede nada, lo que ayuda no es escanear una vez más, sino que algo vigile los archivos por ti y te avise en cuanto uno cambie. Eso es exactamente lo que hace Pulse: vigila los archivos de tu web y te avisa si algo se modifica, desde 19 EUR al mes. Si la puerta se reabre, lo sabes el mismo día, no cuando Google te vuelve a marcar la web.