Session ID: ef742862
IP origen: 129.154.[REDACTED].251
Usuario: root
Timestamp: 2026-06-12T08:16:39Z
Cliente SSH: SSH-2.0-PuTTY_Release_0.83 — el único no-Go en sesiones con comandos extensos
La secuencia completa
La sesión ef742862 llegó con credenciales root y, una vez autenticada, ejecutó exactamente siete comandos. Ninguno de ellos descargó software, ninguno estableció persistencia, ninguno exfiltró datos. Los siete comandos tienen un único propósito: eliminar evidencias de acceso.
Qué borra cada comando
La secuencia es metódica. Cubre los principales vectores de evidencia forense de una intrusión SSH:
| Comando | Qué elimina |
|---|---|
| journalctl --vacuum-size=1K | Trunca el journal de systemd a 1 KB, eliminando prácticamente todos los logs del sistema |
| cat /dev/null > /var/log/wtmp | Vacía el registro de sesiones de usuario (usado por last) |
| cat /dev/null > /var/log/btmp | Vacía el registro de intentos de login fallidos (usado por lastb) |
| cat /dev/null > /var/log/lastlog | Vacía el registro del último login de cada usuario |
| cat /dev/null > /var/log/secure | Vacía el log de autenticación SSH (en sistemas Red Hat/CentOS; equivalente a auth.log en Debian) |
| history -c | Borra el historial de comandos de la sesión bash actual |
| history -w | Fuerza la escritura del historial en disco — en este caso, escribe un historial vacío sobre .bash_history |
Lo que no consiguió borrar
Aquí está la parte relevante para los defensores: la secuencia es efectiva en sistemas sin logging centralizado, pero falla en todos los entornos con un SIEM o log shipper.
- /var/log/auth.log — si está siendo ingestado en tiempo real por Filebeat, Fluentd o rsyslog hacia un SIEM externo, el vaciado local no elimina lo que ya se envió.
- journalctl — si usas
journaldconForwardToSyslog=yeso tienes remote journald, el vacuum local no toca los logs remotos. - El honeypot en sí — la sesión completa, con cada comando, quedó registrada en
honeypot.logfuera del filesystem simulado. El atacante no sabía que operaba en un honeypot. - Auditd — si tienes
auditdconfigurado con reglas para loggear accesos a/var/log/, la propia operación de borrado queda auditada.
La secuencia cat /dev/null > /var/log/wtmp seguida de history -c && history -w es una firma altamente específica de comportamiento anti-forensics. Cualquier SIEM que registre ejecuciones de comandos puede alertar sobre ella.
Sigma rule: cmdline contains "cat /dev/null > /var/log" AND cmdline contains "history -c"
El cliente PuTTY como anomalía
Otro indicador interesante: mientras el 99,5% de las conexiones usaron SSH-2.0-Go, esta sesión usó SSH-2.0-PuTTY_Release_0.83. Esto sugiere que podría ser un operador humano (PuTTY es una herramienta GUI para Windows) en lugar del scanner automatizado de la campaña principal. Si es así, hay dos actores distintos: el scanner Go automatizado y al menos un operador humano que sigue manualmente los accesos que consigue el scanner.
Conclusión: el silencio también es una señal
En análisis forense, la ausencia de logs es un indicador de compromiso tan válido como su presencia. Si tus logs de autenticación aparecen truncados o vacíos de repente, no es que "no haya pasado nada" — es que alguien estuvo allí y los borró.
La defensa es simple: nunca confíes solo en logs locales. Si tus logs de autenticación viven únicamente en el disco del servidor comprometido, el atacante que tenga acceso root puede eliminarlos en siete comandos, en menos de diez segundos.
Datos recopilados con fines de investigación en ciberseguridad. Toda la información procede de actividad no solicitada registrada en infraestructura propia.
honeypot CipherSentry · sesión ef742862 · 2026-06-12T08:16:39Z