Qué archivos temporales pueden contener backdoors en WordPress
En mi experiencia analizando sitios comprometidos, los archivos temporales son uno de los vectores más infrautilizados por los atacantes para alojar backdoors. Mientras los administradores se centran en proteger wp-admin y wp-content/plugins, los malware se esconden en directorios que parecen inofensivos. Te voy a mostrar dónde buscar y cómo evitar que tu WordPress sea el próximo objetivo.
Por qué los atacantes usan archivos temporales
Los archivos temporales ofrecen una ventaja táctica clara: suelen tener permisos más permisivos, se limpian menos frecuentemente (o nunca) y los administradores rara vez los monitorean. Cuando realizo auditorías de seguridad, encuentro backdoors alojados en carpetas tmp porque el atacante sabe que pasarán desapercibidos durante semanas.
Un backdoor en wp-content/plugins/malware.php genera alertas; uno en /tmp/ o en wp-content/cache/ pasa bajo el radar. Esta es la razón por la que debes conocer exactamente dónde WordPress almacena datos temporales y qué permisos tienen esas carpetas.
Directorios WordPress que albergan datos temporales
WordPress utiliza varios directorios para almacenamiento temporal. La mayoría son legítimos, pero todos son potenciales puntos de entrada para malware:
- wp-content/cache/ – Si usas plugins de caché como WP Super Cache o W3 Total Cache, esta carpeta contiene archivos serializados. Un atacante puede inyectar código PHP disfrazado como datos cacheados.
- wp-content/uploads/ – Aunque técnicamente es para medios, los atacantes cargan webshells con extensiones como .php, .phtml o .php5. Si la configuración permite ejecución de scripts, tienes un backdoor operativo.
- wp-content/backup-*/ o wp-content/backups/ – Generado por plugins de backup. Los archivos .sql sin protección pueden contener información sensible; los .tar.gz pueden contener backdoors empaquetados.
- /tmp/ (a nivel de servidor) – No es específico de WordPress, pero los plugins pueden escribir aquí. Si una librería PHP usa /tmp/ sin validación, es un vector de ataque.
- wp-content/upgrade/ – Usado durante actualizaciones de plugins y temas. Un backdoor aquí puede persistir entre actualizaciones si el atacante lo recoloca.
Tipos de backdoors que encontré en archivos temporales
En mis análisis forenses, he documentado varios patrones. Los más comunes son:
Webshells camufladas en cache: El atacante inyecta una función PHP mínima dentro de archivos .php del directorio cache. Por ejemplo, un archivo cache-post-123.php contiene datos legítimos más una línea que ejecuta comandos. Parece un error de caché, pero funciona como un shell interactivo.
Archivos .htaccess malicioso en subdirectorios: Creando un .htaccess en wp-content/cache/ que redirige todas las peticiones .jpg a un PHP oculto. El servidor ejecuta el script malicioso sin que el nombre de archivo lo sugiera.
Backdoors en archivos de sesión de PHP: Si el servidor usa /tmp/ o wp-content/temp/ para sesiones, el atacante puede escribir código en esos archivos si conoce el patrón de nombres. Cuando PHP carga la sesión, ejecuta el código.
Plugins de caché comprometidos: Un módulo de caché nulled o desactualizado que contiene un backdoor integrado. Se actualiza con cada carga de página, ocultándose en los logs.
Cómo detectar backdoors en archivos temporales
La detección manual es tedious pero fundamental. Lo que hago siempre es:
1. Listar archivos por fecha de modificación: Conéctate por SFTP o SSH y ejecuta:
find wp-content/cache -type f -mtime -7
Esto muestra archivos modificados en los últimos 7 días. Un archivo tmp sin cambios esperados es sospechoso.
2. Buscar patrones de código malicioso: Los backdoors suelen contener strings específicos. Ejecuta:
grep -r "eval|base64_decode|system|passthru|exec" wp-content/cache/
Si encuentras estas funciones en archivos que no deberían tenerlas, es una bandera roja.
3. Verificar tamaño de archivos inusual: Un archivo cache debería tener un tamaño predecible. Si wp-content/cache/ contiene archivos de 500KB cuando normalmente son 10KB, investiga.
4. Usar herramientas automatizadas: Wordfence CLI y MalCare escanean estos directorios por defecto. Son más rápidas y fiables que búsquedas manuales.
Configuración de seguridad para archivos temporales
Proteger estas carpetas es tan importante como detectar el malware. Estas son las medidas que siempre recomiendo:
Deshabilitar ejecución de PHP en wp-content/uploads/: Añade esto a un archivo .htaccess en esa carpeta:
<FilesMatch ".php$">
Deny from all
</FilesMatch>
Incluso si el atacante sube un .php, no se ejecutará.
Proteger wp-content/cache/ con permisos restrictivos: El propietario debe ser el usuario del servidor (www-data), con permisos 755 en directorios y 644 en archivos. Un 777 es una invitación abierta.
chmod -R 755 wp-content/cache
chmod -R 644 wp-content/cache/*
Configurar wp-config.php para deshabilitar edición de archivos: Esto impide que un atacante con acceso administrativo inyecte código:
define('DISALLOW_FILE_EDIT', true);
define('DISALLOW_FILE_MODS', true);
Limpiar caches regularmente: Si usas WP Super Cache, configúralo para expirar cada 2-4 horas. Un cache antiguo es un backdoor potencial no detectado.
Logs y monitoreo continuo
La detección pasiva no es suficiente. Necesitas visibilidad activa sobre qué sucede en tus directorios temporales.
Configura logs de acceso a wp-content/ en tu servidor. Con nginx o Apache, puedes registrar cada petición. Busca patrones sospechosos: múltiples 404 seguidos de un 200 exitoso, o accesos a archivos que no deberían existir.
Usa OWASP Web Security Testing Guide como referencia para identificar qué constituyente anómalo en un log.
Si tienes acceso a WP-CLI, ejecuta esto regularmente:
wp eval 'echo date("Y-m-d H:i:s") . ": Check completedn";'
Esto te ayuda a establecer un baseline de cuándo suceden cosas en tu WordPress.
Herramientas recomendadas para auditoría
No debes confiar únicamente en búsquedas manuales. Las herramientas profesionales son más exhaustivas:
- Wordfence Scan – Detecta backdoors en caché y directorios temporales con su motor de firmas.
- Sucuri SiteCheck – Análisis desde la nube, identifica código inyectado en archivos públicos.
- VirusTotal – Carga archivos sospechosos para analizarlos con 70+ motores antimalware.
- Análisis forense local con strings y file – Herramientas Linux para inspeccionar contenido binario de archivos comprometidos.
Limpieza de backdoors encontrados
Si has identificado un backdoor en archivos temporales, el siguiente paso es crítico:
1. No confíes en limpiar solo el archivo. El atacante puede tener acceso administrativo. Cambiar contraseñas de usuarios, revisar permisos de carpetas y buscar múltiples puntos de entrada.
2. Limpia el caché completamente: Vacía wp-content/cache/, asegúrate de que el plugin de caché regenere archivos limpios.
3. Revisa plugins y temas: Si un plugin escribía backdoors en tmp, está comprometido. Desactiva, borra e instala una versión verificada desde el repositorio oficial.
4. Audita cambios recientes: Usa NVD/CVE para verificar si los plugins comprometidos tenían vulnerabilidades conocidas. Esto te ayuda a entender cómo entró el atacante.
Política de seguridad preventiva
La mejor defensa es la prevención. Estos hábitos reducen drásticamente el riesgo:
- Mantén WordPress, plugins y temas siempre actualizados. Los backdoors explotan vulnerabilidades old-day.
- Usa contraseñas fuertes y autenticación de dos factores en wp-admin.
- Instala solo plugins desde el repositorio oficial de WordPress.org. Los temas nulled y plugins crackeados suelen contener backdoors integrados.
- Realiza copias de seguridad semanales (no en el mismo servidor). Son tu única opción si necesitas restaurar después de una infección.
- Limita permisos de carpetas: nunca 777, siempre 755 en directorios y 644 en archivos.
Casos reales que he atendido
Para que entiendas el riesgo real, te cuento dos casos que he analizado:
Caso 1 – Blog de viajes comprometido: El propietario no actualizaba W3 Total Cache desde hacía 18 meses. El plugin tenía una vulnerabilidad de RFI que permitía inyectar código. El backdoor estaba en wp-content/cache/page_cache/index-http-443-example.com-2024-01-15-21-45-12.html. Era invisible porque parecía un archivo legítimo de caché con extensión .html (aunque contenía PHP ejecutable). Lo detecté porque noté que ese archivo se «regeneraba» cada 5 minutos, cuando debería hacerlo cada 24 horas.
Caso 2 – Tienda online comprometida: Un plugin de caché nulled, descargado de un sitio de «plugins gratis». Contenía un backdoor hardcodeado en su función de limpieza de caché. Cada vez que el caché se regeneraba, creaba un archivo webshell en wp-content/uploads/cache_temp/. El atacante tenía acceso de root al servidor.
Ambos casos hubieran sido evitables con actualización regular y verificación de plugins.
Integración con Google Search Console y auditorías de seguridad
Si tu sitio ha sido comprometido, Google lo sabrá. La Search Console mostrará advertencias de «contenido malicioso detectado». Una vez limpies el backdoor:
- Solicita una revisión de seguridad en Google Search Console.
- Envía el sitio a Google Safe Browsing para verificación.
- Usa Sucuri SiteCheck para confirmar que la malaria está limpia.
El tiempo entre infección y limpieza impacta tu SEO y reputación. Cada día cuenta.
Si sospechas que tu WordPress contiene backdoors en archivos temporales, no esperes. Contáctame para una auditoría de seguridad profesional en ManuelFolgar.com/contacto. Realizaré un escaneo forense completo, identificaré todos los puntos de entrada y te proporcionaré un plan de hardening específico para tu configuración.
La seguridad de tu sitio no es un gasto; es una inversión en su continuidad.