Observando al ciberactor desde una Honeynet ¿Qué nos dicen los más de 23 millones de eventos capturados en nuestra Honeynet en lo que va del año?

Honeynet ciberseguridad análisis ataques SSH: ¿qué nos dicen más de 23 millones de eventos reales sobre el comportamiento actual de los ciberactores?

Durante 2026 desplegamos una honeynet con el objetivo de observar cómo operan los atacantes sobre infraestructura expuesta a Internet. Este ejercicio de honeynet ciberseguridad análisis ataques SSH nos permitió identificar patrones reales de intrusión, técnicas de post-explotación y campañas activas de malware como Redtail.

El resultado: 23.5 millones de eventos analizados directamente desde Elasticsearch, incluyendo payloads, scripts y múltiples vectores de ataque utilizados en entornos reales.

Dashboard principal de T-Pot. 2 millones de eventos y distribución geográfica de ataques en tiempo real.

Honeynet ciberseguridad análisis ataques SSH: arquitectura y sensores desplegados

T-Pot es una plataforma de honeypots desarrollada originalmente por Deutsche Telekom que integra múltiples sensores en un stack de Docker, con Elasticsearch como backend y Kibana para análisis. En esta arquitectura distribuida desplegamos múltiples sensores que permitieron identificar tráfico hacia servicios como SSH, SMB, HTTP, FTP, entre otros.

HoneypotSimulaEventos en marzo
CowrieSSH/Telnet527,654
HoneytrapPuertos TCP genéricos627,123
HeraldingMúltiples protocolos con captura de credenciales153,052
DionaeaSMB, HTTP, FTP, malware collection86,842
MailoneySMTP relay17,854
H0neytr4pHTTP dinámico7,476
ConPotICS/SCADA2,249
RedishoneypotRedis1,406
ElasticPotElasticsearch758
WordpotWordPress13
P0fFingerprinting pasivo de OS15,459,411
SuricataIDS/IPS de red6,330,593
FattTLS/SSH fingerprinting (JA3/HASSH)272,635

Análisis de ataques SSH en honeynet: anatomía del ataque de diccionario

De los 527,654 eventos de Cowrie (Honeypot de SSH), la distribución por tipo de evento revela la anatomía completa del ataque:

EventIDEventosSignificado
cowrie.session.connect84,380Conexiones SSH totales
cowrie.login.failed71,022Intentos fallidos de credenciales
cowrie.login.success4,727Autenticaciones exitosas
cowrie.command.input44,142Comandos ejecutados post-autenticación
cowrie.session.file_download3,559Payloads descargados
cowrie.session.file_upload99Archivos subidos al honeypot
cowrie.direct-tcpip.request455Tunneling TCP directo

De los datos anteriores, la información nos dice que tuvimos 4,727 autenticaciones exitosas de 84,380 conexiones, lo que indica una tasa de éxito del 5.6%. Es decir, en una infraestructura con credenciales débiles o por defecto, 1 de cada 18 intentos hubiera resultado en compromiso.

honeynet ciberseguridad análisis ataques SSH
Dashboard de Cowrie mostrando la distribución de ataques, IPs únicas y firmas HASSH.

Honeynet ciberseguridad: diccionarios de ataque y targeting a infraestructura blockchain

El análisis de las credenciales probadas revela dos patrones distintos operando en paralelo.

El patrón clásico no sorprende en realidad, root lidera los nombres de usuarios con 18,419 intentos (26% del total), seguido de admin, ubuntu, user, y servicios de base de datos como postgres (1,404), oracle (1,238) y mysql (577). Las contraseñas son igualmente predecibles, 123456 (3,814), 12345678 (2,245), password (1,750), qwerty (988).

El patrón que no esperábamos es el que da origen a esta publicación.

Entre los 30 usernames más frecuentes aparecen, sol (4,081), solana (3,609), solv (1,668), validator (387), lighthouse (329), node (310). Entre las contraseñas, solana (1,265), sol (1,176), validator (609), solv (578), node (441).

Usernames y passwords más frecuentes. “sol” y “solana” compiten en escala con “root” y “admin”.

Esto no es coincidencia, la documentación oficial de Agave Validator sugiere crear un usuario llamado sol para ejecutar el nodo validador. Dado que esto es información pública, los ciberactores la están usando activamente para construir diccionarios especializados dirigidos a infraestructura de blockchain expuesta.

La hipótesis se confirma al cruzar con los logins exitosos: sol sube a posición 2 con 422 éxitos, solana a posición 3 con 331. Hay ciberactores específicamente cazando nodos de Solana expuestos en Internet.

Dos credenciales adicionales merecen mención. 345gs5662d34 aparece como username y password con 205 éxitos , estas credenciales son identificadas por su uso en campañas de ataques de diccionarios desde hace algunos años, pero también n8n con 32 logins exitosos indica que los diccionarios incluyen plataformas de automatización de workflows que han ganado popularidad en los últimos años.

Infraestructura del ciberactor en ataques SSH: uso de cloud legítimo

El análisis de ASNs de origen para los logins exitosos tienen la siguiente distribución:

ASNLogins exitosos
DigitalOcean, LLC1,045
Unmanaged Ltd765
PT Cloud Hosting Indonesia181
OVH SAS132
Microsoft Corporation116
Oracle Corporation32
Google LLC31

Microsoft Azure, Oracle Cloud y Google Cloud aparecen entre los orígenes de logins exitosos contra el honeypot. Lo que significa que sus plataformas de cloud gratuitas o de bajo costo están siendo usadas como infraestructura de ataque. Un ciberactor puede crear una cuenta gratuita en Azure o GCP y tener capacidad de ataque en minutos, con IPs de alta reputación que muchos controles de seguridad no bloquean por país o reputación.

honeynet ciberseguridad análisis ataques SSH
ASNs de origen para logins exitosos. Microsoft, Google y Oracle aparecen entre los atacantes.

Este punto tiene implicaciones directas para las estrategias de bloqueo por geolocalización o por reputación básica de ASN, ya que resultará insuficiente cuando el atacante opera desde infraestructura de proveedores cloud legítimos o que gozan de buena reputación.

Post-explotación en ataques SSH observados en honeynet

De los 44,142 comandos ejecutados post-autenticación, el análisis de frecuencia revela que los comandos más frecuentes tienen prácticamente el mismo conteo (~2,040 cada uno). Esto nos indica que lo observado es una ejecución de un script automatizado que lleva a cabo dicha secuencia con cada sesión exitosa.

La secuencia completa, reconstruida desde los logs es la siguiente:

# Fase 1: Reconocimiento del sistema
uname -a                                              # OS, kernel, arquitectura
uname -m                                              # arquitectura específica
cat /proc/cpuinfo | grep name | wc -l                 # número de CPUs
cat /proc/cpuinfo | grep name | head -n1              # modelo de CPU
free -m | grep Mem | awk '{print $2,$3,$4,$5,$6,$7}'  # memoria disponible
df -h | head -n 2 | awk 'FNR == 2 {print $2;}'        # espacio en disco
lscpu | grep Model                                    # verificación de CPU
ls -lh $(which ls)                                    # versión de binarios
which ls                                              # paths del sistema
whoami                                                # usuario actual
w                                                     # usuarios conectados
top                                                   # procesos activos
crontab -l                                            # tareas programadas

# Fase 2: Eliminación de protecciones en .ssh
cd ~; chattr -ia .ssh; lockr -ia .ssh

# Fase 3: Limpieza de rastros
rm -rf /tmp/secure.sh; rm -rf /tmp/auth.sh
pkill -9 secure.sh; pkill -9 auth.sh
echo > /etc/hosts.deny
pkill -9 sleep

El objetivo de la fase 1 resulta evidente, evaluar la capacidad de cómputo del sistema para minería. Cores de CPU, velocidad, memoria disponible y espacio en disco son exactamente los parámetros que determina un operador de cryptominer antes de desplegar el payload.

El comando de la fase 2, chattr -ia .ssh elimina los atributos immutable y append-only del directorio .ssh. Esto se ejecuta para evadir la posible protección del directorio .ssh con chattr +i que previene modificaciones. Al remover la protección, prepara el sistema para inyectar su llave pública SSH y establecer persistencia en el equipo comprometido, independientemente de posibles cambios de contraseña futuros.

Top 10 comandos post-autenticación. El conteo idéntico en todos confirma ejecución automatizada.

La fase 3 indica que el ciberactor busca posibles scripts relacionados con otras familias de malware, específicamente Mirai Malware, al que se le asocia secure.sh, el comando pkill -9 secure.sh y la eliminación de archivos en /tmp están enfocadas en eliminar otro tipo de malware que pudiera estar en el mismo sistema. Al vaciar el archivo /etc/hosts.deny garantiza que las futuras herramientas de C2 puedan conectarse sin problemas.

Malware Redtail identificado en honeynet ciberseguridad análisis ataques SSH

Del análisis de los 3,559 eventos de descarga de archivos identificamos 9 archivos únicos en el servidor. El comando file sobre cada uno reveló:

Hash (primeros 8 chars)TipoTamañoArquitectura
59c29436ELF 64-bit LSB executable1.8 MBx86-64
048e374bELF 32-bit LSB executable1.7 MBIntel i386
dbb7ebb9ELF 64-bit LSB executable1.5 MBARM aarch64
3625d068ELF 32-bit LSB executable1.2 MBARM EABI5
783adb7aBash script1.9 KBInstaller
d46555afBash script795 BCleaner
a8460f44OpenSSH RSA public key389 BPersistence
0231f8baASCII text20 BCrontab
01ba47191 bytetrivialDescarga fallida

Cuatro binarios ELF para cuatro arquitecturas diferentes, más dos scripts de soporte y una llave SSH pública para generar persistencia en el equipo comprometido.

honeynet ciberseguridad análisis ataques SSH
29/61 motores detectan la llave SSH como maliciosa. Los nombres de submission revelan sistemas reales comprometidos.

El script setup.sh

El script 783adb7a (setup.sh) nos indica el nombre de la familia de malware en su código:

get_random_string() {
  # ...
  echo "redtail"                # fallback del generador de strings
  return 1
}
# ...
cp -r "$CURR"/redtail.* "$i"    # copia los binarios por arquitectura
cat redtail.$ARCH >$FILENAME    # ejecuta el correcto
chmod +x $FILENAME
./$FILENAME ssh                 # lanza payload con argumento 'ssh'
rm -rf redtail.*                # limpia rastros

El malware se llama Redtail. El script detecta la arquitectura del sistema víctima , genera un nombre de archivo aleatorio con punto inicial para ocultarlo, ejecuta el binario correspondiente con el argumento ssh, y elimina todos los archivos originales. La ejecución no deja binarios nombrados redtail.* solo el proceso corriendo bajo un nombre aleatorio.

El script clean.sh

El script d46555af tiene como parte de su código:

systemctl disable c3pool_miner
systemctl stop c3pool_miner
# ...
for user_cron in /var/spool/cron/crontabs/*; do
  [ -f "$user_cron" ] && clean_crontab "$user_cron"
done

c3pool es un pool de minería de Monero. Este script se ejecuta antes del installer para eliminar otro posible malware, específicamente de un grupo que usa c3pool. La función clean_crontab filtra exactamente los patrones más comunes en crontabs maliciosos:

grep -vE 'wget|curl|/dev/tcp|/tmp|\.sh|nc|bash -i|sh -i|base64 -d' "$1"

La llave SSH fue el payload más descargado

El archivo más descargado, 2,208 veces que representa el 62% del total de las descargas, es una llave pública OpenSSH de 389 bytes. En la base de datos de VirusTotal se identifica como maliciosa por 29 de los 61 motores de detección, con detecciones que incluyen:

  • DrWeb: Linux.BtcMine.271
  • Sophos / ZoneAlarm: Linux/Miner-ADV
  • TrendMicro: Trojan.SH.MALKEY.AA
  • AhnLab: Backdoor/Text.CryptoBot

Otro dato interesante que nos arroja la consulta a Virus Total son los nombres del archivo con el que se cargó el archivo:

20260317 → /home/lg/.ssh/authorized_keys
20260312 → /home/n8n/.ssh/authorized_keys
20260310 → /home/ann/.ssh/authorized_keys
20260103 → /home/claude/.ssh/authorized_keys
20260101 → /home/user1/.ssh/authorized_keys
20251230 → /root/.ssh/authorized_keys
20251225 → /home/admin/.ssh/authorized_keys
20251211 → /home/bitcoin/.ssh/authorized_keys
20251219 → /home/exploit/.ssh/authorized_keys

Esta misma llave ha sido inyectada en sistemas comprometidos desde diciembre 2025, con 4,017 envíos a VirusTotal y 135 fuentes únicas que la han reportado. La campaña lleva activa al menos 16 meses usando dicha llave SSH.

Redtail: contexto e inteligencia previa

Pero Redtail no es nuevo, su primera documentación pública data de diciembre 2023, cuando Cyber Security Associates (CSA) lo identificó abusando de Log4Shell (CVE-2021-44228). El investigador Patryk Machowiak publicó en enero 2024 el primer análisis técnico detallado, documentando su uso de XMRig en memoria y comunicación cifrada via ssh-agent.

La familia evolucionó rápidamente. En mayo 2024, Akamai Security Research (Barnett, Kupchik, Zavodchik) documentó una variante que explotaba CVE-2024-3400 en PAN-OS con CVSS 10. Esta variante incorporó pools de minería privados, técnicas anti-análisis (fork múltiple para dificultar debugging, kill activo de GDB), y una configuración de XMRig cifrada embebida directamente en el binario. Los investigadores de Akamai señalaron que el uso de pools privados se asemeja a una táctica del grupo Lazarus, aunque sin atribución confirmada.

En enero 2025, Cody Hales en SANS Internet Storm Center documentó la misma familia desde su honeypot personal entre agosto y noviembre de 2024. Los hashes de clean.sh y setup.sh que capturó son los mismos que capturamos nosotros en 2026. El script d46555af1173d22f07c37ef9c1e0e74fd68db022f2b6fb3ab5388d2c5bc6a98e está referenciado explícitamente en ese diary. El mismo toolset lleva operativo al menos desde octubre 2024.

En noviembre 2025, Mario Candela / Beelzebub Honeypot documentó la primera evidencia de Redtail atacando Docker APIs expuestas (puerto 2375), con el C2 178.16.55.224 (Railnet LLC) y el User-Agent string libredtail-http.

Lo que capturamos en 2026 representa una variante con los binarios ELF sin reportar previamente en Virus Total, muestras nuevas de una campaña de larga duración, activamente mantenida y actualizada.

Secuencia de la cadena de ataque

honeynet ciberseguridad análisis ataques SSH
Cadena de ataque completa de Redtail, reconstruida desde los logs de Cowrie.

Infraestructura del ciberactor

P0f registró 15,459,411 conexiones durante el período, proporcionando el mapa más completo de la infraestructura que es utilizada por los ciberactores. Los ASNs con mayor volumen son:

ASNConexionesTipo
Alsycon B.V.2,207,046Hosting VPS, Países Bajos
DigitalOcean, LLC1,491,640Cloud
OVH SAS1,410,823Cloud / nuestro servidor
InterOuro Telecom818,525ISP residencial, Brasil
EVEO S.A.561,299ISP residencial, Brasil
Contabo GmbH530,945VPS económico, Alemania
BattleHost449,894Hosting gaming/VPS
TOTAL PLAY411,153ISP residencial, México

Alsycon B.V. encabeza la lista con 2.2 millones de conexiones. Alsycon es un proveedor de VPS holandés que aparece documentado en múltiples análisis de honeypots como fuente primaria de brute force SSH. El análisis de este proveedor por un investigador francés en 2025 concluyó que “los servidores de Alsycon se usan casi exclusivamente para brute force SSH”.

La presencia de ISPs residenciales brasileños como InterOuro, EVEO, RVA Telecom, PORTO NET colectivamente suman más de 1.3M conexiones, esto indica que Brasil no es solo tránsito de hosting sino que existen dispositivos IoT o residenciales comprometidos y que están siendo usados activamente como nodos en redes de botnet.

Geográficamente, Brasil lidera con 4,348,683 conexiones P0f, seguido de Estados Unidos (3,610,596) y Países Bajos (2,327,434). México aparece en posición 6 con 418,666 conexiones.

honeynet ciberseguridad análisis ataques SSH
Distribución geográfica de 23.5 millones de conexiones P0f. Brasil y Europa occidental lideran el volumen.

Una nota importante sobre interpretación geográfica, el país de origen de una IP no necesariamente es el país del ciberactor. Los primeros puestos reflejan en gran medida dónde están los datacenters e ISPs con más dispositivos comprometidos o infraestructura de hosting disponible para arrendar. El ciberactor real puede operar desde cualquier lugar.

Indicadores de compromiso (IOCs) derivados del análisis de honeynet

Para los equipos defensivos, listamos los IOCs identificados y cruzados con threat intelligence existente:

Hashes de archivos (SHA256)

# Llave SSH maliciosa (backdoor Redtail)
a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2
Detección VT: 29/61 | Linux.BtcMine.271 | Linux/Miner-ADV | Trojan.SH.MALKEY.AA

# Script cleaner (desinstala c3pool y competidores)
d46555af1173d22f07c37ef9c1e0e74fd68db022f2b6fb3ab5388d2c5bc6a98e
Detección VT: 25/72 (comportamiento malicioso documentado)

# Script installer (setup.sh / Redtail launcher)
783adb7ad6b16fe9818f3e6d48b937c3ca1994ef24e50865282eeedeab7e0d59
Detección VT: 20/57 (comportamiento malicioso documentado)

# Binarios ELF Redtail
59c29436755b0778e968d49feeae20ed65f5fa5e35f9f7965b8ed93420db91e5  (x86-64, 1.8MB)
048e374baac36d8cf68dd32e48313ef8eb517d647548b1bf5f26d2d0e2e3cdc7  (i386, 1.7MB)
dbb7ebb960dc0d5a480f97ddde3a227a2d83fcaca7d37ae672e6a0a6785631e9  (ARM aarch64, 1.5MB)
3625d068896953595e75df328676a08bc071977ac1ff95d44b745bbcb7018c6f  (ARM EABI5, 1.2MB)

Reglas YARA para su identificación

rule Redtail_Installer_Script {
    meta:
        description = "Detecta el script installer de Redtail cryptominer"
        author = "Silent4Labs"
        date = "2026-03-17"
        reference = "https://blog.silent4business.com"
        hash = "783adb7ad6b16fe9818f3e6d48b937c3ca1994ef24e50865282eeedeab7e0d59"
    strings:
        $s1 = "redtail" ascii nocase
        $s2 = "c3pool_miner" ascii
        $s3 = "chattr -ia .ssh" ascii
        $s4 = "get_random_string" ascii
        $s5 = "./$FILENAME ssh" ascii
    condition:
        3 of them
}

rule Redtail_SSH_Backdoor {
    meta:
        description = "Detecta la llave SSH pública usada como backdoor por Redtail"
        author = "Silent4Labs"
        date = "2026-03-17"
        hash = "a8460f446be540410004b1a8db4083773fa46f7fe76fa84219c93daa1669f8f2"
    strings:
        $ssh_rsa = "ssh-rsa AAAAB3NzaC1yc2EAAAABJ" ascii
        $comment = "mdrfckr" ascii
    condition:
        all of them
}

Conclusiones del honeynet ciberseguridad análisis ataques SSH

Este honeynet ciberseguridad análisis ataques SSH confirma que los atacantes operan con automatización, persistencia y targeting específico sobre infraestructura expuesta.

1. Elimina la autenticación por contraseña en SSH. La tasa de éxito del 5.6% que observamos demuestra que la autenticación por contraseña, incluso con contraseñas que parecen razonables, es insuficiente frente a ataques de diccionario especializados. Migra a autenticación exclusiva por llave pública ya que el tiempo de implementación no justifica el riesgo residual.

2. Monitorea chattr -ia .ssh y modificaciones a authorized_keys. Este es el indicador de compromiso más consistente de la campaña Redtail malware. Un proceso que elimina atributos inmutables de .ssh o modifica authorized_keys fuera de tu flujo de gestión de configuración es una alerta de alta fidelidad.

3. No confíes en la geolocalización como control de seguridad. Azure, GCP y OCI aparecen entre los orígenes de logins exitosos. Un ciberactor puede usar infraestructura cloud legítima de cualquier proveedor para atacar. Los controles basados en IP o país son insuficientes para este tipo de amenaza.

4. Si operas infraestructura blockchain (nodos Solana, Ethereum, validadores), asúmete como objetivo específico. Los diccionarios de ataque ya incluyen los usernames que la documentación oficial recomienda para estos nodos.

5. Audita tus archivos authorized_keys. Un archivo de 389 bytes, no detectado por 32 de 61 motores, mantuvo persistencia en cientos de sistemas comprometidos durante más de 16 meses. Ejecuta grep -r "mdrfckr" /home/*/.ssh/ /root/.ssh/ en cada sistema que administres. Si el comando devuelve un resultado, el host está comprometido.

Referencias y contexto del honeynet ciberseguridad análisis ataques SSH

Este análisis utilizó las siguientes fuentes para contextualizar los hallazgos propios:

  • Patryk Machowiak — Primera documentación técnica de Redtail, enero 2024
  • Akamai Security Research (Barnett, Kupchik, Zavodchik) — Análisis de variante PAN-OS CVE-2024-3400, mayo 2024. https://www.akamai.com/blog/security-research/2024-redtail-cryptominer-pan-os-cve-exploit
  • Forescout — Variante via CVE-2024-4577 (PHP CGI), julio 2024. https://www.forescout.com/blog/new-redtail-malware-exploited-via-php-security-vulnerability
  • Cody Hales / SANS Internet Storm Center — Análisis desde honeypot, enero 2025. https://isc.sans.edu/diary/31568 — Los hashes de clean.sh documentados en este diary corresponden a los capturados en nuestra Honeynet.
  • Cybaverse / MSP Corner — Deep dive en tácticas de Redtail, enero 2025. https://www.cloudtango.net/blog/2025/01/10/unveiling-redtail-a-deep-dive-into-cryptocurrency-mining-malware/
  • Mario Candela / Beelzebub Honeypot — Primera evidencia de Redtail en Docker APIs, noviembre 2025. https://itnext.io/redtail-cryptominer-first-evidence-of-docker-api-targeting-c061096443f8
  • Akamai Hunt Team (Yonathan Gilvarg) — Nueva variante Docker con lockout de competidores, septiembre 2025. https://www.akamai.com/blog/security-research/new-malware-targeting-docker-apis-akamai-hunt
  • ASEC / AhnLab — Estadísticas de malware SSH Linux Q4 2025, enero 2026. https://asec.ahnlab.com/en/92004/
  • Innora.ai — Análisis de cryptojacking XMRig en Hetzner Cloud, marzo 2026. https://innora.ai/blog/cloud-cryptojacking-xmrig-hetzner-rescue-mode-analysis
  • Malpedia — Entrada de Redtail como familia de malware. https://malpedia.caad.fkie.fraunhofer.de/details/elf.redtail
  • Agave / Solana Validator Docs — Documentación oficial de best practices para validadores Solana (origen de los usernames objetivo). https://docs.anza.xyz/operations/best-practices/security

Autor

  • Eduardo Salmerón

    Eduardo Salmerón es Ingeniero en Computación por la FES Aragón y cuenta con una sólida formación en ciberseguridad, iniciada con un diplomado en Seguridad de la Información en la UNAM, complementado con cursos en Pruebas de Intrusión y Respuesta a Incidentes. Está certificado como ECIH (Certified Incident Handler). Con más de 10 años de experiencia, ha trabajado como consultor en sectores como el financiero, energético, turismo y retail. Actualmente se desarrolla como Cyber Threat Research en Silent4Business.

Publicar comentario

LinkedIn
Share
×