Qué archivos temporales eliminan los hackers para borrar rastros

Qué archivos temporales eliminan los hackers para borrar rastros de sus ataques

Cuando un atacante compromete tu sitio web, lo primero que hace después de establecer acceso es limpiar el escenario del crimen. En mi experiencia analizando webs infectadas, los hackers son metódicos: eliminan logs, borran históricos de acceso y destruyen archivos temporales que evidencian su presencia. Entender cuáles son estos archivos es crucial para detectar intrusiones y recuperarte más rápido.

En este artículo te muestro exactamente qué archivos buscan los atacantes para cubrir sus huellas y cómo puedes proteger tu sitio WordPress o PrestaShop implementando controles que dificulten esta tarea.

Los archivos temporales que eliminan los hackers

Logs de acceso del servidor web (access.log y error.log)

El primer objetivo de cualquier atacante es silenciar el registro de actividad. Los archivos access.log y error.log del servidor (Apache, Nginx) contienen la prueba de sus movimientos: direcciones IP de origen, rutas accedidas, intentos fallidos, todo.

Cuando analizo un sitio comprometido, busco gaps sospechosos en los logs de acceso: saltos temporales de horas o días sin registro es una bandera roja. Los hackers utilizan comandos como:

• rm /var/log/apache2/access.log (en Linux/Apache)
• echo "" > /var/log/apache2/error.log (vaciar sin borrar)
• Truncamiento de logs vía webshell para evitar permisos root

Algunos hosting permite rotación automática de logs. Si tu proveedor no lo hace, configúralo con logrotate para crear snapshots que el atacante no pueda eliminar retroactivamente.

Logs de aplicación de WordPress (debug.log)

WordPress almacena errores en wp-content/debug.log cuando tienes WP_DEBUG activado. Este archivo es una mina de oro para forensics: registra intentos fallidos de plugins, errores SQL, incluso algunos patrones de ataques de fuerza bruta.

Yo siempre reviso este log en auditorías de seguridad. Los atacantes lo saben y lo borran. Si encuentro que existe en tu repositorio .git pero no en el servidor actual, es indicio de limpieza.

Lo que recomiendo siempre: envía los logs de WordPress a un servidor remoto (syslog externo, Cloudflare Logpush, o Similar). Así, aunque borren el archivo local, tú conservas el registro en infraestructura que no controlan.

Archivos de sesión de usuarios (.php sessions)

Las sesiones de PHP se almacenan típicamente en /var/lib/php/sessions/ o /tmp/ (depende de la configuración de session.save_path). Cada archivo corresponde a un usuario conectado.

Los hackers que comprometen una cuenta de administrador o editor crean sesiones backdooreadas que persisten incluso si cambias la contraseña. Borran archivos de sesión antiguos para evitar que detectes cuándo accedieron realmente.

Búsqueda por timestamp: si todos tus archivos de sesión tienen fechas recientes y faltan históricos, hay problema. Yo siempre reviso ls -lat /var/lib/php/sessions/ | head -20 en auditorías.

Archivos temporales de PHP (/tmp, /var/tmp)

Algunos malwares usan directorios temporales del sistema como almacén temporal para:

• Descargar payloads adicionales
• Almacenar datos exfiltrados (credenciales, bases de datos)
• Compilar shells o exploits

Atacantes sofisticados borran estos archivos cada 24 horas con tareas programadas cron para no dejar evidencia. En mi experiencia, revisar /tmp es donde encuentro backups de configuración, scripts SQL, listas de password hashes.

Cookies y datos en navegador (browser cache/storage)

Aunque técnicamente no están en el servidor, si el ataque incluye malware de cliente (keylogger, skimmer como Magecart), los hackers eliminan:

• Cookies de sesión del back-office
• IndexedDB con datos sensibles
• LocalStorage con tokens JWT

Esto es raro verlo borrado del servidor, pero algunos backdoors sofisticados inyectan scripts que limpian datos del lado cliente para ocultar que hubo acceso administrativo.

Histórico de historial de FTP y SSH (.bash_history, .ssh/authorized_keys)

Si el atacante accedió vía FTP o SSH (porque vulneró credenciales débiles), borra:

• ~/.bash_history (historial de comandos ejecutados)
• ~/.ssh/authorized_keys (puede contener sus propias claves backdoor)
• /var/log/auth.log (registro de intentos SSH)

El comando clásico es simplemente: history -c && rm ~/.bash_history. Si tu servidor no tiene registro de estos eventos en un syslog centralizado, pierdes la trazabilidad completa.

Archivos de cache de aplicación (.htacache, object-cache, cache files)

WordPress genera cachés en wp-content/cache/ y directorios similares. Los atacantes los borran porque:

• Contienen versiones en caché de archivos que modificaron
• Algunos plugins de cache almacenan información sensible (credenciales API, claves de base de datos)
• El timestamp del cache revela cuándo accedieron a un archivo

Si uso Wordfence CLI para auditoría y detecto discrepancias entre los timestamps de archivos fuente y sus caches, es probable intrusión con posterior limpieza.

Cómo detectar que han limpiado archivos temporales

Analiza anomalías de timestamps

Los archivos de un sitio limpio tienen cronología lógica: el tema se actualiza en una fecha, plugins después, posts más recientemente. Si ves:

• Un archivo principal (wp-config.php) modificado hace 3 meses
• Pero todos los logs borrados o vacíos desde esa fecha
• Y archivos de sesión completamente nuevos

Hay limpieza de evidencia. Uso comandos como find /home/usuario/public_html -type f -mtime -90 -ls para ver qué cambió en los últimos 3 meses.

Revisa permisos y propietarios anómalos

Cuando un atacante elimina archivos y recreates logs vacíos, a veces cometete errores de permisos:

• Logs con propiedad www-data:www-data en lugar de root:root
• Archivos de caché con timestamps todos iguales (borrados y recreados de una vez)
• Directorios /tmp con archivos de propietario web en lugar del sistema

Un comando revelador: ls -la /var/log/ | grep apache y verificar que los propietarios sean root o el usuario del servicio, no web.

Busca caches externos y backups

Si tú realizas backups automáticos del sitio (recomendación: hacerlo), esos backups capturan logs antes de la limpieza. Compara:

• El backup de hace 7 días: ¿contiene logs completos?
• El sitio actual: ¿logs vacíos desde una fecha específica?

Esa brecha temporal es el período de ataque. También Google almacena en caché versiones antiguas del sitio: búsqueda en site:tudominio.com en Google puede mostrar archivos que ahora están ocultos.

Usa herramientas de análisis forense

En auditorías profesionales, yo utilizo:

• Sucuri SiteCheck: detecta inyecciones y malware incluso si los logs fueron limpiados
• MalCare Forensics: analiza modificaciones de archivos incluso borrados (si hay inodos disponibles)
• WP-CLI auditor: escanea integridad de core, temas, plugins contra repositorios oficiales
• WHOIS histórico: búsqueda de dominios secundarios o DNS modifications que el atacante pudo haber hecho

Cómo proteger tus archivos temporales y logs

Centraliza logs fuera del servidor principal

La medida más efectiva es hacer que los logs sean imposibles de borrar desde el servidor comprometido. Opciones:

• Syslog remoto: configura /etc/rsyslog.d/ para enviar logs a un servidor externo en tiempo real
• Cloudflare Logpush: si usas Cloudflare, descarga logs en bucket S3 automáticamente
• ELK Stack o Similar: Elasticsearch + Logstash + Kibana en infraestructura separada
• Servicio de monitoreo: Datadog, New Relic, o lo que ofrezca tu hosting

Yo lo recomiendo siempre a clientes: si los logs están fuera del servidor comprometido, el atacante no puede eliminarlos. Es el control preventivo número uno.

Protege directorios temporales con permisos estrictos

En WordPress:

• Establece wp-content/ con permisos 755 para directorios, 644 para archivos
• Crea un directorio privado wp-private/ fuera de document root para datos sensibles
• Usa define('WP_TEMP_DIR', '/home/usuario/.private/tmp'); en wp-config.php para redirigir temporales

En PrestaShop:

• Asegura permisos en /var/log/ y directorios cache
• Deshabilita ejecución de PHP en /tmp/ con reglas .htaccess o nginx.conf

Implementa rotación de logs inmutable

Configura logrotate con timestamp y compresión:

/var/log/apache2/*.log {
    daily
    rotate 90
    compress
    delaycompress
    missingok
    notifempty
    create 640 root adm
    sharedscripts
}

Los logs rotados son más difíciles de borrar sin dejar evidencia. Además, mantén al menos 90 días de histórico.

Usa monitoring en tiempo real de integridad de archivos

Herramientas como AIDE, Tripwire, o el módulo audit de Linux monitorizan cambios. Si detectan que se borró un archivo log, alertan inmediatamente.

Configuración básica con auditd:

• auditctl -w /var/log/apache2/ -p wa -k log_changes
• Cada escritura o atributo modificado en logs se registra en /var/log/audit/audit.log

Backup inmutable de logs

Realiza backups diarios de logs a almacenamiento que no se puede modificar retroactivamente. Opciones:

• S3 con versionado y object lock
• Snapshots de volumen EBS/Azure con retención mínima 30 días
• Backup a NAS con snapshots read-only

Deshabilita edición de archivos en WordPress

Aunque esto protege temas y plugins más que logs, añade una capa preventiva. En wp-config.php:

define('DISALLOW_FILE_MODS', true);
define('DISALLOW_FILE_EDIT', true);

Si el atacante consigue acceso via wp-admin, no puede modificar archivos directamente desde el editor del administrador.

Cómo actuar si sospechas que han limpiado logs

Paso 1: Aísla el servidor inmediatamente

Desconecta del acceso público, pero NO apagues. La memoria volátil (RAM) contiene procesos activos que pueden revelar qué se ejecuta.

Paso 2: Preserva la memoria y el sistema de archivos

Si es posible, crea una copia forense del disco completo antes de hacer cambios. En cloud:

• AWS: snapshot de volumen EBS
• DigitalOcean/Linode: snapshot del servidor
• VPS compartido: backup inmediato via control panel

Paso 3: Busca archivos recuperables

Herramientas como extundelete o recoverjpeg pueden recuperar archivos borrados si los inodos no han sido sobrescritos. Comando:

extundelete /dev/sda1 --restore-file var/log/apache2/access.log

Paso 4: Revisa registros ISP y datos de terceros

Si tu hosting usa WAF (Cloudflare, Sucuri), esos logs persisten. También Google Search Console registra cambios detectados en tu sitio. Google Search Console es una fuente valiosa de auditoría.

Paso 5: Recurre a profesionales

Si sospechas intrusión avanzada, no intentes recuperarte solo. En ManuelFolgar.com realizamos auditorías forenses completas incluyendo recuperación de logs borrados, análisis de malware y hardening posterior.

Resumen: protege tus evidencias de ataque

Los hackers eliminan archivos temporales, logs y caches porque saben que son su rastro digital. Si no tomas medidas preventivas, un atacante sofisticado puede comprometer tu sitio durante semanas sin que dejes evidencia.

Las medidas clave son:

• Centralizar logs fuera del servidor comprometible
• Implementar rotación y backup inmutable de registros
• Monitorizar cambios en tiempo real con AIDE o auditd
• Aplicar permisos estrictos a directorios temporales
• Mantener backups completos y verificables del sitio

La detección de intrusiones no comienza cuando encuentras un malware visible. Comienza cuando proteges tus propias evidencias para poder investigar después. Cada log centralizado, cada backup inmutable, cada snapshot de volumen es una oportunidad de recuperarte más rápido cuando ocurra un ataque.

Si necesitas implementar estos controles en tu WordPress o PrestaShop, o sospechas que ya hay acceso no autorizado, contáctame para una auditoría de seguridad profesional. Analizaré logs, buscaré puertas traseras y configuraremos defensas que te permitan dormir tranquilo.