Botnet SSH por dentro: 121,222 ataques en 7 días

Construimos el software que entregamos y además lo operamos. Esa segunda mitad es la que la mayoría de los estudios devuelve junto con el código fuente, y es de donde sale este artículo: Appluex mantiene infraestructura de producción, tanto de aplicaciones que construimos nosotros como de aplicaciones que construyó otro y dejó funcionando, lo que significa que también leemos los registros, atendemos las alertas y auditamos las máquinas. Esta es una de esas auditorías, publicada completa.

Esta empezó con dos clientes, en el mismo mes, que llamaron por dos problemas distintos y terminaron pidiendo lo mismo. El primero tenía un servidor de producción que dejaba de responder cada pocos días. Nadie sabía explicar por qué, y el procedimiento de trabajo se había convertido en silencio en reiniciarlo. Ya que estábamos adentro, también hicieron una pregunta justa sobre la máquina: ¿está expuesta en algún lado la IP de origen? Es una buena pregunta, porque un servidor detrás de un CDN pierde casi toda su protección en el momento en que se filtra su dirección real.

El segundo cliente venía de un lugar completamente distinto, con otro proveedor, otro stack y otro negocio, y describía la misma realidad diaria con otras palabras. El servidor andaba bien, después andaba lento, después alguien lo reiniciaba y volvía a andar bien. Ninguno de los dos pidió una auditoría de seguridad. Los dos pidieron que averiguáramos por qué su servidor no se mantenía en pie.

Ya habíamos visto esa forma antes. Con los años nos han entregado otros servidores de clientes que simplemente iban lentos, donde la respuesta anterior había sido comprar más memoria. Eso funciona, durante cosa de una semana. Después la máquina vuelve a ir lenta y la siguiente conversación es sobre comprar más memoria otra vez. Cuando un arreglo se degrada con calendario, lo que se redimensionó no era lo que estaba mal, así que antes de recomendar hardware hacemos el paso aburrido primero y leemos los registros.

En la primera máquina, siete días de registros contenían 121,222 intentos fallidos de inicio de sesión SSH desde 925 direcciones IP distintas. No fue un ataque dirigido. Es la radiación de fondo normal de internet, que resulta ser mucho más pesada de lo que imagina la mayoría de quienes operan un servidor, y que nadie en ninguna de las dos conversaciones había mirado jamás.

Los números

La última fila es la que importa. No cero durante la semana. Cero durante toda la vida de la máquina.

El servidor del segundo cliente, medido el mismo día

Todo lo anterior viene de la máquina del primer cliente. Medimos el servidor del segundo cliente el mismo día: otro dueño, otra región, otro propósito, otro software, ningún nombre DNS compartido, nada que los conecte públicamente. Si este tráfico fuera dirigido a alguien, los dos deberían verse muy distintos.

Las tasas diarias quedan a menos del 10% una de otra. Dos máquinas que no comparten nada, ni siquiera el dueño, reciben el mismo ritmo de ataque, que es la evidencia más clara disponible de que nadie eligió a ninguna de las dos. El segundo servidor vio incluso el doble de direcciones distintas en la cuarta parte del tiempo.

Y las mismas máquinas aparecieron en ambos: dos direcciones de 2.57.121.0/24 atacaron al primero y al segundo. No son dos campañas que se parecen, es una campaña que encontró a los dos.

Pero adivinaban cosas distintas

Aquí los dos divergen, y es el resultado más interesante de todo el ejercicio. Al primer servidor lo sondearon con una lista genérica de infraestructura: deploy, ansible, puppet, oracle, minecraft. Al segundo, con una lista de criptomonedas: admin (1,445), ubuntu (417), wallet (292), crypto (216), bitcoin (157), solana (138), ethereum (125), blockchain (120).

Esos seis nombres de cripto suman 1,048 intentos y casi no aparecen en el primer servidor. Ninguna distribución de Linux crea esas cuentas. Son cuentas que crea una persona que corre un nodo, un bot de trading o una integración con un exchange, y alguien apuesta a que una máquina con una cuenta así tiene una contraseña débil. ubnt es otra apuesta distinta: el usuario por defecto de los routers Ubiquiti.

Así que la botnet no corre un solo script en todas partes: corre variantes, y cada servidor recibe la que le llegue.

El único ajuste que sacó a un servidor de casi toda la campaña

En el primer servidor, root fue atacado 26,419 veces. En el segundo, una.

La diferencia es una línea: el segundo tiene PermitRootLogin no. Cuando sshd rechaza root de plano, el intento nunca llega a ser una adivinanza de contraseña y el host deja de valer la pena para esa parte de la campaña. Los ajustes más baratos no solo defienden: te sacan de categorías enteras de tráfico.

No es un atacante. Es infraestructura alquilada

Del tráfico que pudimos atribuir, el 84.6% provino de IPs de centros de datos y no de conexiones residenciales. Este es el dato más útil de todo el conjunto. No son computadoras domésticas infectadas. Son máquinas virtuales que alguien alquiló, por docenas, específicamente para esto.

Se nota en cómo se agrupan las direcciones. Los ataques no llegaron desde 925 lugares dispersos. Llegaron en bloques. Un solo bloque, 109.160.32.0/24, produjo 51,785 intentos desde 25 hosts distintos dentro del mismo /24: el 43% de todo, desde lo que en la práctica es un estante en un centro de datos.

Siguiendo el rastro hasta una empresa real

Los datos de registro son públicos y llegan más lejos de lo que la gente espera. Siguiendo ese /24 a través de RIPE: el bloque se llama GBTCloud, lo anuncia AS197170, TechTies Inc., su dirección registrada está en Cornelius, Carolina del Norte, y sus objetos de mantenimiento resuelven a Global Communication Net Plc, un Registro Local de Internet de RIPE en Sofía, Bulgaria, cuyo contacto de abuso sí funciona: abuse@gcn.bg.

Nada de eso es ilegal. Todo eso hace más difícil que prospere una denuncia, que es precisamente el motivo de organizarlo así.

Qué estaban adivinando

Se probaron 4,201 nombres de usuario distintos. Los más frecuentes fueron admin (1,572), ubuntu (1,468), user (949), oracle (443), test (430), debian (417) y deploy (391). Es una lista de palabras comercial, sin cambios en años, rociada contra todo.

Vale la pena mirar qué contiene: ubuntu y debian, las cuentas por defecto de las imágenes en la nube. deploy, ansible, puppet y git, las cuentas de servicio que la automatización crea y nadie audita. minecraft y steam, porque los servidores de juegos los administra gente que no es administradora de sistemas. Y claude, intentado 150 veces: las listas ya incluyen nombres de herramientas de IA, suponiendo que alguien creó una cuenta de servicio así con una contraseña débil.

Los nombres de usuario revelan la intención

Esa lista no es aleatoria, y sus categorías se corresponden con lo que busca el operador:

• Cuentas por defecto de la nube (ubuntu, debian, pi): una apuesta a que el usuario por defecto de la imagen todavía tiene contraseña.
• Cuentas de servicio de automatización (deploy, ansible, puppet, chef, git). Esta es la categoría valiosa. Esas cuentas suelen existir, a menudo tienen sudo o llaves de despliegue, y con frecuencia se crean una vez con una contraseña compartida que nadie rota. Una cuenta deploy comprometida no es un servidor: es el pipeline, y todo aquello a lo que ese pipeline publica.
• Restos de desarrollo abandonados (test, dev, student, guest, aa, a): cuentas creadas para una tarde y nunca eliminadas.
• Nombres que no pertenecen a ninguna distribución (binux, wkh, panda). No son cuentas por defecto en ningún lado. La lectura razonable es que son cuentas de persistencia dejadas por malware anterior, lo que significa que parte de esta campaña no busca servidores seguros que vulnerar, sino servidores que alguien más ya vulneró.

Una segunda campaña, en paralelo, buscando credenciales

SSH era solo la mitad. Los registros web del mismo host mostraron un esfuerzo automatizado aparte con un objetivo mucho más específico: 474 peticiones buscando archivos de secretos, en 104 variantes distintas de ruta de un solo nombre de archivo.

/.env            /v1/.env          /v2/.env
/staging/.env    /production/.env  /portal/.env
/secrets.env     /ses.env          /sendgrid.env
/uploads../.env  /userfiles/x?path=../../.env
/.git/HEAD       /phpinfo.php      /wp-admin/install.php

Hay que leer los nombres de archivo, no las rutas. ses.env y sendgrid.env llevan el nombre de proveedores concretos de envío de correo. No buscan configuración en general: quieren credenciales de envío de correo, porque una llave robada de SES o SendGrid se monetiza el mismo día como relay de spam operando sobre la reputación de otra persona.

El resto completa el cuadro. Las variantes con ../ son traversal de directorios contra fallos conocidos de frameworks. Las peticiones a .git/HEAD comprueban si el sitio se desplegó copiando un repositorio al servidor, lo que expondría todo su historial de código, incluido lo que se subió por accidente.

El hilo común entre ambas campañas es el mismo: el objetivo son las credenciales, no el servidor. El servidor es solo donde se guardan.

Por qué: cuánto vale realmente un servidor comprometido

Es tentador suponer que quien ataca un servidor pequeño tiene algo personal. Casi nadie lo tiene. Existe un mercado de hosts comprometidos, y una máquina vale la pena por razones que no tienen nada que ver con quién es su dueño:

• Minería de criptomonedas. La opción de menor esfuerzo. Tu CPU, sus monedas, tu electricidad y tu factura de hosting.
• Ampliar la botnet. Un host comprometido se pone a buscar más hosts. Casi seguro es la razón de que el 84.6% de las direcciones que nos atacaron fueran máquinas de centros de datos y no computadoras domésticas: buena parte de los atacantes son ellos mismos víctimas previas, reclutadas para buscar a la siguiente. La campaña se autofinancia en máquinas.
• Reventa de ancho de banda como proxy. El tráfico se vende a servicios que necesitan que las peticiones salgan de algún lugar poco llamativo: fraude publicitario, scraping, relleno de credenciales contra terceros. Te conviertes en el remitente del abuso de otro.
• Relay de spam y phishing. El motivo de que esas sondas .env nombren proveedores de correo. Un servidor con reputación de IP limpia, o mejor, una llave robada de un servicio de correo establecido, vale dinero real para una operación de phishing.
• Saltar a la cuenta de nube, que es la cara. Los servidores de aplicaciones modernos guardan credenciales del proveedor en disco para que la aplicación pueda usarlas. Quien las lee ya no tiene un servidor: tiene una cuenta. Capacidad de levantar instancias a tu nombre, alcanzar buckets de almacenamiento y, en el peor arreglo, alcanzar las copias de seguridad de los mismos datos que acaba de cifrar. Aquí una molestia se convierte en un evento que termina con una empresa, y es la razón de que la búsqueda de credenciales sea más peligrosa que la fuerza bruta.

Nada de esto requiere que alguien haya oído hablar de ti. Esa es la parte que conviene interiorizar: no te están apuntando, te están enumerando, y la economía funciona a una escala donde una tasa de éxito mínima sobre millones de hosts es un negocio rentable.

El volumen va en aumento

Totales diarios a lo largo de la ventana: 15,448, luego 14,986, 16,024, 16,735, 18,339, 17,285 y 21,764 el último día completo. Eso es un aumento del 41% del primer día al último. Sea lo que sea esto, no está bajando.

¿Era esto lo que tumbaba los servidores?

Esta es la pregunta que los dos clientes hicieron de verdad, y merece una respuesta directa antes que una satisfactoria. En parte, y menos de lo que las cifras en crudo hacen parecer. Vale la pena seguir el orden honesto, porque es el mismo que merece cualquier máquina que hay que reiniciar con calendario.

Esta parte no está en discusión. Cada uno de esos intentos es una conexión TCP real, un intercambio de llaves real, un proceso sshd que nace, una consulta a PAM y una línea escrita en disco. A unos 200 intentos por minuto, eso es un proceso naciendo y muriendo unas tres veces por segundo, a toda hora, por un trabajo que no produce nada. Súmale las 474 peticiones web buscando archivos de secretos, el registro que todo eso genera y el crecimiento del journal que viene con ello. En un VPS pequeño donde una aplicación, una base de datos y un proxy inverso ya se reparten la memoria, eso es un impuesto permanente para el que nadie dimensionó la máquina, y es invisible en el lugar donde la gente mira, porque un panel muestra tu aplicación, no el tráfico que tu aplicación nunca ve.

Primera pregunta: ¿la máquina ya es de otro?

Un servidor que anda bien, se pone lento, se reinicia y vuelve a andar bien es la descripción de manual de un host comprometido, y por eso la auditoría empezó ahí y no por una instancia más grande. Una máquina que está minando en silencio, haciendo de proxy para el tráfico de alguien o retransmitiendo spam se comporta igual que una máquina que se quedó chica: está ocupada, se pone más lenta con el paso del día, y un reinicio parece arreglarlo porque el reinicio mata lo que estuviera corriendo. Si había persistencia instalada, vuelve en unas horas, que es lo que hace que el arreglo parezca temporal.

Las señales son concretas, y ninguna necesita herramientas especiales:

• Carga sin nada que mostrar a cambio. CPU ocupada o carga alta mientras la aplicación atiende casi nada de tráfico. Los mineros suelen ir deliberadamente limitados, y algunos se pausan cuando se abre una sesión de terminal, así que un servidor que se ve tranquilo justo cuando entras y va caliente el resto del tiempo es una señal, no un consuelo.
• Salida de datos que no cuadra con tus visitantes. El ancho de banda de salida es lo más difícil de esconder para un intruso, porque la reventa de proxy y el relay de spam están hechos de eso. Mira a qué se está conectando la máquina, no solo quién se conecta a ella.
• Procesos en lugares equivocados. Nombres plausibles corriendo desde /tmp, /dev/shm o /var/tmp. Pregúntale al gestor de paquetes de quién es un binario antes de alarmarte: si el archivo llegó por apt, no es un rootkit, que es exactamente la falsa alarma que se publica más abajo en este artículo.
• Persistencia que nadie escribió. Unidades y temporizadores de systemd desconocidos, entradas de cron, líneas en authorized_keys o una cuenta nueva. Ahí es donde vive una intrusión real, porque el malware que no sobrevive a un reinicio es malware que se muere el martes.
• Huecos en los registros. Un historial de autenticación que se corta y vuelve, o un journal más pequeño que la ventana que dice cubrir.

En las dos máquinas la respuesta fue que no. Cero inicios de sesión por contraseña exitosos en toda la vida de cada servidor, cada binario privilegiado perteneciente a un paquete, y ninguna unidad, temporizador o llave que nadie pudiera explicar. Esa es la explicación cara descartada en una hora, y esa hora vale la pena: un servidor comprometido no es un problema de rendimiento, es un incidente, y lo que cuesta dinero rara vez es el servidor. Son las credenciales del proveedor guardadas en su disco, que es justo para lo que servía la búsqueda de archivos .env de más arriba.

¿Entonces qué los ponía lentos?

Fallas de capacidad corrientes y sin glamour, que es la respuesta habitual una vez que el compromiso queda descartado. La firma de reiniciar cada pocos días acota rápido, porque apunta a algo que se acumula y no a algo que simplemente es demasiado chico:

• Memoria que nunca se devuelve. Un proceso de trabajo que pierde unos megabytes por petición no falla en ningún punto visible. Llena la máquina en días, y entonces el kernel empieza a matar lo más grande, que suele ser la base de datos. El kernel lo dice en texto plano (Out of memory: Killed process) y casi nadie lo mira, porque el registro de la aplicación solo muestra el síntoma: una consulta que falló sin motivo.
• Sin swap. Las imágenes de nube suelen venir sin nada, así que no hay amortiguador entre andar bien y morir. Una máquina con algo de swap se pone lenta bajo presión; una máquina sin nada pasa de sana a no responder sin nada en medio.
• Discos llenos de registros. Journald y los logs de acceso sin límite se comen el volumen, y un disco lleno se convierte en fallas que no se parecen en nada a un disco lleno: una base de datos que queda en solo lectura, subidas que fallan, sesiones que desaparecen. Aquí es donde el tráfico de ataque se suma, porque buena parte de esas líneas se escriben por cuenta de gente que intenta entrar.
• Pools dimensionados para un día tranquilo. Límites de conexiones y de trabajadores que están bien hasta que algo los deja abiertos, y a partir de ahí cada petición nueva espera detrás de las que ya están trabadas.
• Una máquina que era la correcta hace dos años. La carga creció, la instancia no, y la diferencia se le echa al software.

Un reinicio limpia todo eso de golpe. Por eso funciona, y por eso hay que repetirlo: reinicia la acumulación sin tocar lo que acumula. Reiniciar un servidor con calendario no es un arreglo, es una medición que nadie ha anotado.

También es la respuesta a la historia de la memoria. Ponerle más RAM a una máquina cuyo problema real es una fuga, un registro que crece sin límite o una carga constante que nadie ha medido compra exactamente lo que les compró a aquellos otros clientes: unos días buenos, hasta que el espacio nuevo se llena al mismo ritmo que el viejo. Un síntoma que vuelve con calendario es una causa que se regenera, y ninguna cantidad de hardware jubila una causa.

Esta parte no la vamos a afirmar. No podemos correr la misma semana dos veces con la botnet quitada, así que nadie puede entregarte honestamente un número diciendo que el ataque causó tal porcentaje de los reinicios. En las dos máquinas la inestabilidad tenía más de una causa, y algunas eran problemas corrientes de aplicación que no tienen nada que ver con este artículo. Lo que sí puede hacer una auditoría es descartar la explicación cara, eliminar las causas que se pueden eliminar y dejar atrás una lista más corta y más honesta. Esta causa era medible, era constante, creció un 41% en una sola semana, y ninguno de los dos dueños sabía que existía.

Por qué nada de eso funcionó

Cero inicios de sesión por contraseña exitosos, jamás, contra 121,222 intentos en una semana. No porque la contraseña fuera fuerte, sino porque todos los accesos a esa máquina siempre usaron una llave SSH, y una llave no se adivina con una lista de palabras.

Pero conviene ser honestos, porque aquí está la lección real: el servidor todavía tenía la autenticación por contraseña habilitada y todavía permitía iniciar sesión como root. Nadie usaba contraseñas. Simplemente seguían siendo posibles. Se había puesto un cuidado enorme en ocultar el servidor detrás de un CDN y restringir sus puertos web a los rangos del CDN. Todo eso protege el puerto 443. Mientras tanto el puerto 22 estaba abierto a todo internet, aceptando contraseñas, para root.

La solución, y los dos detalles fáciles de arruinar

Primero: los archivos drop-in se leen en orden y gana el primer valor. En Ubuntu, cloud-init escribe 50-cloud-init.conf con PasswordAuthentication yes. SSH toma el primer valor que obtiene, así que un archivo llamado 90-hardening.conf se lee después y se ignora en silencio. El nuestro está numerado 10. Una configuración que se ve bien, valida bien y no hace nada es peor que no tener configuración.

Segundo: PermitRootLogin prohibit-password, no no. prohibit-password permite que root entre por llave, que es como se conecta la mayoría de los despliegues. no bloquea root por completo, y si tu automatización entra como root, acabas de dejarte fuera de tu propio servidor.

El procedimiento seguro: respalda la configuración, valida con sshd -t antes de recargar, programa una reversión automática en cinco minutos, usa reload y no restart, abre una conexión completamente nueva para comprobar que funciona, y solo entonces cancela la reversión. El tercer paso es el que todos se saltan, y convierte “me quedé fuera de producción” en “espero cinco minutos”.

Una falsa alarma que vale la pena publicar

Durante el escaneo, la auditoría de binarios SUID marcó /usr/lib/cargo/bin/sudo, /usr/bin/sudo.ws y binarios llamados gnuuname, gnuid o gnumv. Binarios privilegiados en un directorio inesperado, más copias renombradas de utilidades base, es casi la descripción de manual de un rootkit.

Son completamente legítimos. Ubuntu 26.04 incluye sudo-rs y la reescritura uutils de coreutils, que toman los nombres por defecto mediante alternatives y renombran los originales de GNU con el prefijo gnu. Un comando lo resuelve: dpkg -S. Si un archivo pertenece a un paquete, llegó por el gestor de paquetes. Comprobar la pertenencia antes de dar la alarma es la diferencia entre una auditoría y un simulacro de incendio.

Qué hacer al respecto

• Desactiva la autenticación por contraseña. Este solo cambio vuelve irrelevante toda la campaña.
• Confirma que tu configuración se está leyendo de verdad. sshd -T imprime los valores en efecto. Confía en eso, no en el archivo que editaste.
• Root solo por llave, con prohibit-password.
• Instala fail2ban y pon tu propia dirección en la lista de exclusión.
• Lee tus registros de autenticación una vez. El volumen sorprende la primera vez.
• Si usas un CDN, verifica que el origen no sea accesible directamente y que tu lista de rangos del CDN esté actualizada.

La conclusión tranquilizadora es que la defensa aquí es vieja, aburrida y completamente efectiva. 121,222 intentos, 925 hosts, cuatro mil nombres de usuario, una campaña en ascenso en diez países, y todo quedó derrotado de antemano por usar llaves SSH. Los atacantes no son sofisticados. Son pacientes y numerosos, y cuentan con la pequeña cantidad de servidores que todavía aceptan una contraseña.

En qué quedaron los dos servidores

Las dos máquinas ahora rechazan contraseñas de plano, permiten root solo por llave, y descartan a los reincidentes en el firewall antes de que sshd los vea siquiera. La campaña contra ellas no se ha detenido ni se va a detener. Simplemente ya no llega a nada que pueda contestarle, y ya no le cuesta a cada máquina un proceso por intento. Lo que queda en cada lista después de eso es trabajo de ingeniería corriente sobre las aplicaciones mismas, que es un problema mucho mejor que un reinicio inexplicable cada pocos días.

El resumen honesto fue el mismo para los dos clientes. A ninguno de los dos servidores lo habían penetrado. Los dos estaban gastando una parte medible de sí mismos en tráfico que nadie había mirado nunca, y los dos estaban a un archivo de configuración sin leer de estar realmente expuestos en lugar de solamente ocupados.

Por qué publicamos algo así

Una auditoría vale lo que cambia. Esta produjo una lista corta de correcciones sobre la infraestructura que operamos y las aplicamos todas el mismo día, que es el estándar con el que tratamos cada máquina que tocamos. Lanzar una aplicación es la primera mitad del trabajo. Saber qué le está pasando a las tres de la mañana, seis meses después, es la mitad que decide si sigue en pie.

Si tienes software en producción y nunca has leído tus propios registros de autenticación, esa es la hora mejor invertida de este mes. Y si prefieres que alguien lo haga a fondo, ese es trabajo que hacemos, tanto para aplicaciones que construimos nosotros como para las que no.

Metodología: las cifras se midieron desde los registros de autenticación de dos hosts Linux de producción que operamos, en ventanas de siete días y de veintiocho horas respectivamente, ambas terminando el 14 de septiembre de 2026, enriquecidas con geolocalización de IP pública y registros de RIPE/ARIN. La atribución se detiene en los datos públicos de registro: no escaneamos, sondeamos ni nos conectamos a ninguna máquina atacante, lo que sería acceso no autorizado a sistemas de terceros sin importar lo que hayan hecho primero, y buena parte de esas máquinas son ellas mismas víctimas. Se omiten deliberadamente los detalles que identifican a nuestros hosts, sus redes o sus administradores.