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.