Un nuevo bot de SSH ha sido detectado entrando silenciosamente en sistemas Linux, analizando su CPU, GPU y memoria, y luego retirándose sin dejar ningún payload visible.

El comportamiento parece inofensivo a primera vista, pero todo en él apunta a una actividad de minería de criptomonedas cuidadosamente preparada, a la espera del objetivo de hardware adecuado.

En lugar de apresurarse a instalar malware, este bot se toma su tiempo para evaluar si un host comprometido es lo suficientemente potente como para que valga la pena minar en él.

La actividad salió a la luz cuando un honeypot de DShield registró un inicio de sesión automatizado que se comportaba de manera muy diferente a los habituales y ruidosos scripts de carga de una sola línea y de adivinación de contraseñas.

En una sola sesión, el bot entró como root, ejecutó solo dos comandos, analizó el host, probó la escalada de privilegios y se desconectó en cuestión de segundos.

Los analistas del Internet Storm Center señalaron que esta sesión de “solo reconocimiento” no desplegó ningún minero, lo que convirtió al reconocimiento en sí mismo en la parte más interesante del ataque.

Según el informe, el bot de SSH se conectó desde una única dirección IP, se autenticó mediante una contraseña de root débil y se identificó utilizando un cliente SSH basado en Go en lugar de una terminal estándar.

Internet Storm Center dijo en un informe que toda la interacción duró unos ocho segundos, sin dejar ningún binario, ningún gancho de persistencia ni una segunda etapa obvia para que los defensores la analizaran.

Este patrón encaja en una tendencia más amplia donde los atacantes dejan de “infectar cualquier cosa que puedan alcanzar” y, en su lugar, ajustan sus campañas para maximizar el retorno de los recursos de computación.

Se ha observado un comportamiento similar en otras campañas que secuestran servidores Linux y cargas de trabajo en la nube para la minería de Monero, a menudo tras obtener acceso mediante credenciales SSH débiles o servicios mal configurados.

Si quieres explorar amenazas relacionadas, puedes revisar cómo los atacantes reutilizan credenciales SSH débiles para minar Monero.

El bot de SSH analiza la CPU, GPU y RAM de Linux

Una vez que el bot aterriza en un host, no descarga inmediatamente un minero; en su lugar, realiza una encuesta de hardware para calibrar las capacidades de la máquina.

El script recopila el sistema operativo y la versión del kernel, la arquitectura de la CPU, el número de núcleos y la información detallada del modelo de la CPU, y luego etiqueta cada valor con etiquetas como UNAME, ARCH, CPUS, CPU_MODEL, GPU y LAST.

Esa salida estructurada es exactamente lo que un controlador automatizado consumiría más tarde para filtrar los dispositivos de baja potencia y centrarse en los objetivos más rentables.

El bot también ejecuta lspci para buscar una tarjeta gráfica dedicada, comprobando explícitamente si hay una GPU NVIDIA que pueda acelerar las cargas de trabajo de minería.

Además, mide el tiempo de actividad del sistema y extrae el historial de inicios de sesión recientes, lo que da al operador una idea de cuán estable y activamente utilizado está el host antes de comprometerse con un payload más pesado.

Si te interesa el comportamiento general de la minería de criptomonedas en Linux, puedes comparar esta táctica con campañas que utilizan PAM como arma para ocultar mineros, donde los atacantes pasan directamente del acceso a la minería sigilosa.

El segundo comando se centra en la memoria y los privilegios. El bot lee /proc/meminfo, comprueba si la RAM total supera aproximadamente 1 GB y pasa esa prueba a través de sudo utilizando la misma contraseña que acaba de usar para root, sondeando efectivamente si puede elevar privilegios sin que se le solicite la contraseña.

Contar los núcleos de la CPU, inspeccionar el modelo de la CPU, buscar GPUs NVIDIA y aplicar un umbral mínimo de RAM es un triaje clásico de minería de criptomonedas, más que una preparación para la denegación de servicio o un simple espionaje.

Los analistas del Internet Storm Center enfatizan que la ausencia de un payload en la primera sesión no significa que no vaya a venir un ataque.

En cambio, el modelo de “reconocimiento primero” permite a los operadores calificar un host ahora y volver más tarde con un minero a medida, o entregar el objetivo a otra herramienta si el hardware supera sus umbrales.

Un patrón similar aparece en otras campañas donde los atacantes secuestran entornos Linux en todo el mundo para la minería de criptomonedas, nuevamente después de forzar el acceso por SSH o explotar servicios expuestos.

El informe original muestra una vista condensada de la sesión de reconocimiento, desde el inicio de sesión hasta el inventario de hardware y la prueba de privilegios, finalizando con una salida limpia.

El modelo de reconocimiento primero en el que el atacante evalúa a las víctimas potenciales, decide si vale la pena desplegar un minero y solo entonces procede con un payload de segunda etapa.

Por qué importan las sesiones de SSH de solo reconocimiento

El operador del honeypot señala que otra campaña de SSH separada atacó el mismo sensor a principios de mes, utilizando una cadena de carga que descargaba un binario ELF y se unía a una botnet de denegación de servicio.

Esa campaña rotó a través de diferentes direcciones IP y servidores de comando y control, pero su huella HASSH se mantuvo constante, lo que facilitó la agrupación de esas sesiones.

En contraste, el bot de reconocimiento orientado a la minería se presentó con un cliente y un HASSH diferentes, lo que indica un actor distinto y refuerza cómo las huellas de los clientes ayudan a los defensores a separar campañas superpuestas.

Esta distinción resalta una lección defensiva clave: las sesiones que nunca dejan archivos pueden representar aun así la primera mitad de un compromiso serio.

Tratar los inicios de sesión de solo descubrimiento como ruido de fondo inofensivo significa perder la fase de exploración que puede preceder a un seguimiento mucho más ruidoso que transporte mineros u otros payloads.

Para obtener una perspectiva más amplia sobre los ataques automatizados de SSH, puedes examinar cómo un gusano de SSH autopropagable forma botnets, mostrando nuevamente lo rápido que se pueden abusar de las credenciales débiles.

El informe recomienda varios pasos básicos para mitigar este tipo de actividad, comenzando con contraseñas fuertes y únicas para bloquear los inicios de sesión triviales de root.

Desactivar el acceso directo de root por SSH y preferir la autenticación basada en claves elimina la ruta exacta que utilizó este bot y frustra su intento de reutilizar contraseñas en sudo.

Limitar la tasa de inicios de sesión SSH, restringir la exposición mediante VPN o rangos de IP conocidos y alertar sobre el descubrimiento masivo de hardware aumentan las posibilidades de que tales sesiones de reconocimiento sean detectadas e investigadas en lugar de ignoradas.

Monitorear la actividad posterior es igualmente importante. Si un host pasa la prueba de calificación del bot, una sesión posterior puede desplegar silenciosamente un minero, provocar un uso sostenido de la CPU o GPU y conectarse a pools de minería utilizando protocolos de red aparentemente legítimos.

Combinar las huellas del cliente SSH, los patrones de comportamiento y la detección de anomalías en el uso de recursos brinda a los defensores una mejor oportunidad de conectar los puntos entre una pasada de reconocimiento silenciosa hoy y una operación de minería de criptomonedas activa mañana.

Indicadores de Compromiso (IoCs):-

Nota: Las direcciones IP y los dominios han sido neutralizados intencionadamente (por ejemplo, [.]) para evitar la resolución accidental o el hipervínculo. Vuelve a activarlos solo dentro de plataformas de inteligencia de amenazas controladas como MISP, VirusTotal o tu SIEM.