Uphill Security llegó a Hacker News, pero sus datos de credenciales SSH requieren una lectura cuidadosa

Uphill Security presentó 1,53 millones de intentos de inicio de sesión SSH ante los lectores de Hacker News, dejando al descubierto tanto una automatización implacable como un importante conflicto de interpretación. Su red global de honeypots registró 131.922 pares distintos de nombre de usuario y contraseña durante julio de 2026. Sin embargo, esas observaciones no demuestran que las contraseñas procedieran de cuentas reales.

Esa distinción separa una telemetría de amenazas útil de una base de datos de credenciales robadas. El proyecto muestra qué prueban los escáneres automatizados cuando encuentran un servicio SSH expuesto. No muestra qué combinaciones funcionan en otros lugares, quién las recopiló ni si los atacantes las copiaron de filtraciones anteriores.

El debate resultante importa porque los defensores suelen interpretar erróneamente los registros de autenticación fallida. Algunos descartan el tráfico como ruido de fondo inofensivo. Otros consideran cada contraseña intentada como prueba de una campaña activa de compromiso. La realidad se sitúa entre ambas posturas y exige examinar más de cerca el método de recopilación.

La red de honeypots registró 1,53 millones de intentos de inicio de sesión

El proyecto capturó una gran muestra de ataques automatizados contra credenciales SSH, no una colección verificada de contraseñas funcionales.

Uphill Security publicó sus primeros hallazgos el 2 de agosto, cubriendo el primer mes completo de operación de la red. Los hallazgos del honeypot abarcan julio de 2026 y quince servidores dedicados.

Esos servidores utilizaron quince direcciones IPv4 públicas en cinco proveedores de servidores privados virtuales. La mayoría se encontraba en Europa, aunque la infraestructura abarcaba varias regiones del mundo. Cada dirección exponía un honeypot SSH de baja interacción en el puerto TCP 22.

Un honeypot de baja interacción imita lo suficiente de un servicio como para atraer y registrar a los atacantes sin proporcionar un entorno operativo completo. En este caso, aceptaba intentos de autenticación y registraba los nombres de usuario y contraseñas enviados. No permitía que los intrusos operaran dentro de una shell realista.

La red observó 1.531.053 intentos de inicio de sesión desde 6.790 direcciones IP únicas. Esos intentos contenían 12.238 nombres de usuario únicos, 97.621 contraseñas únicas y 131.922 pares distintos de nombre de usuario y contraseña.

El par más común fue root con 123456, intentado 3.861 veces. Otras combinaciones destacadas incluían root con root, password, 12345678, admin y varias secuencias numéricas cortas.

Los atacantes probaron el nombre de usuario root 648.133 veces. Esto representó más del 42 por ciento de todos los intentos de autenticación del conjunto de datos. Los siguientes nombres de usuario más comunes fueron admin, ubuntu, user y test.

La contraseña 123456 apareció 73.592 veces. Otras opciones frecuentes incluían 123, 1234, password, 12345678 y 12345. Estos valores se asemejan a diccionarios consolidados de contraseñas débiles y a valores predeterminados previsibles de dispositivos.

Los resultados demuestran cuán poco reconocimiento necesitan algunos escáneres. Un servidor que expone SSH en su puerto estándar recibe de inmediato intentos contra identidades administrativas genéricas. Un operador no necesita anunciar el sistema ni incluirlo en un directorio público.

Sin embargo, el experimento solo contó intentos de autenticación. Excluyó los escaneos de red y los ataques contra otros protocolos. Tampoco siguió a los intrusos que lograron acceder, ya que el honeypot fue diseñado para recopilar envíos de inicio de sesión, no comportamiento posterior a la autenticación.

Ese límite es crucial. El conjunto de datos describe lo que los escáneres ofrecieron a quince servidores señuelo. No puede revelar directamente cuántos sistemas de producción aceptaron las mismas combinaciones.

Por qué el debate en Hacker News se centró en “harvesting”

El desacuerdo no gira en torno a si las mediciones son reales; se refiere a lo que realmente representan las credenciales enviadas.

Varios comentaristas de Hacker News cuestionaron el uso de “harvesting” en el artículo. Su preocupación era que los bots automatizados proporcionaron las credenciales en vez de perderlas ante el honeypot. La red recopiló entradas de los atacantes, no secretos extraídos de sistemas controlados por atacantes.

Un hilo de discusión sostuvo que la mayoría de las combinaciones eran estadísticamente interesantes, pero operativamente inútiles. Un escáner aleatorio que prueba root:123456 no demuestra que algún servidor no relacionado utilice ese par.

La crítica está bien fundamentada. Una credencial normalmente vincula una identidad declarada con un autenticador que concede acceso a un sistema concreto. Sin el host o servicio correspondiente, un par de nombre de usuario y contraseña carece del contexto necesario para verificarlo.

Incluso las combinaciones inusuales requieren cautela. Un bot podría generarlas a partir de un diccionario, modificar valores predeterminados conocidos, combinar palabras filtradas o reutilizar listas recopiladas en campañas anteriores. El honeypot no puede distinguir esos orígenes solo a partir de sus registros de autenticación.

Por tanto, la palabra “harvesting” puede sugerir más de lo que estableció el experimento. Los lectores podrían inferir que el conjunto de datos contiene contraseñas robadas de sistemas activos. El método publicado no respalda esa conclusión.

Aun así, calificar los datos de inútiles va demasiado lejos. Los envíos repetidos revelan las suposiciones integradas en la infraestructura automatizada de ataque. Muestran qué cuentas esperan encontrar los atacantes, qué valores predeterminados siguen siendo atractivos y con qué agresividad operan determinadas fuentes.

El proyecto también pone de relieve el objetivo de las cuentas de servicio. Junto con root y admin, los escáneres probaron postgres, oracle, git, ftpuser, deploy y deployer. Esos nombres se corresponden con roles comunes de software y prácticas de despliegue.

Algunas entradas parecen estar moldeadas por tendencias tecnológicas actuales. El nombre de usuario claude recibió 5.993 intentos, mientras que solana recibió 8.223. Estas etiquetas no demuestran que hubiera un objetivo específico en la campaña, pero muestran cómo los diccionarios de ataque incorporan términos reconocibles de software y productos.

Una interpretación útil trata cada par enviado como una hipótesis del atacante. El escáner predice que un host podría exponer una cuenta con un nombre determinado y una contraseña débil o predeterminada. La repetición indica confianza, conveniencia o reutilización generalizada en las herramientas de escaneo.

Esto hace que los registros sean valiosos para las pruebas defensivas. Los administradores pueden comparar los nombres de usuario observados con las cuentas locales, confirmar que la autenticación por contraseña está deshabilitada y buscar en los registros patrones concentrados de intentos de adivinación.

Los registros siguen siendo evidencia deficiente para atribuir ataques. Una IP observada podría pertenecer a un servidor comprometido, un proxy, una máquina virtual alquilada o infraestructura controlada mediante otro intermediario. La geografía identifica el registro de la red o una ubicación estimada, no a la persona responsable.

En última instancia, el debate mejora el valor del proyecto. Obliga a los lectores a separar la telemetría sin procesar de afirmaciones de seguridad más sólidas. Esa disciplina importa siempre que un conjunto de datos llamativo llega a una audiencia tecnológica amplia.

La geografía muestra infraestructura, no la identidad del atacante

La distribución de las fuentes traza dónde surgió el tráfico, pero no puede identificar de manera fiable dónde vivían o trabajaban los operadores.

La red de honeypots registró fuentes de conexión en 129 países y 1.334 sistemas autónomos. Un sistema autónomo es una colección de rutas de internet gestionadas por un operador de red.

Asia aportó 4.084 direcciones fuente únicas, o el 60,1 por ciento del total. Europa aportó 1.294, mientras que Norteamérica aportó 832. Las direcciones restantes se asociaron con Sudamérica, África y Oceanía.

El volumen de tráfico dibujó un panorama diferente. Las direcciones europeas generaron 921.439 intentos, o el 60,2 por ciento de todos los inicios de sesión. Las fuentes asiáticas generaron 453.254 intentos pese a representar muchas más direcciones únicas.

El contraste refleja concentración. Las fuentes europeas promediaron 712,1 intentos por dirección observada. Las fuentes norteamericanas promediaron 117,1, mientras que las asiáticas promediaron 111.

A nivel de país, China produjo el mayor número de direcciones únicas, con 1.653. Le siguieron Estados Unidos con 721, India con 458 y Vietnam con 338.

Los Países Bajos lideraron por total de intentos, con 686.449 envíos desde 276 direcciones observadas. Eso representó el 44,8 por ciento de todo el conjunto de datos. China produjo 112.793 intentos y Estados Unidos produjo 72.314.

Esto no significa que residentes neerlandeses llevaran a cabo casi la mitad de la actividad. Los centros de alojamiento, relés, servidores infectados e infraestructura alquilada pueden concentrar tráfico en determinadas regiones de red. Un único clúster de automatización también puede generar muchos más intentos que miles de fuentes menos activas.

Los resultados de los sistemas autónomos refuerzan esa lección. La red de Microsoft contenía el mayor número de direcciones observadas únicas, con 303. Sin embargo, otra red distinta, TechTies, produjo 448.559 intentos desde 110 direcciones.

Los proveedores de nube y alojamiento aparecen en toda la lista de fuentes. DigitalOcean, Oracle, OVH, Alibaba, Tencent, Google y varias redes de telecomunicaciones registraron tráfico. Su presencia no implica participación por parte de esas empresas.

Los atacantes prefieren la infraestructura alojada porque ofrece ancho de banda estable y aprovisionamiento rápido. También comprometen servidores legítimos y usan esas máquinas como nodos de escaneo. Ambos patrones debilitan la atribución simple a nivel de país.

Los datos también contienen un efecto de muestreo. El sesenta por ciento de los honeypots estaba en Europa. La ubicación del servidor puede afectar el enrutamiento, la latencia, la visibilidad para los escáneres y qué campañas encuentran una dirección durante una ventana de observación limitada.

Quince direcciones proporcionan observaciones significativas, pero no un censo representativo del abuso global de SSH. La reputación de una dirección también puede importar. Una IP recién asignada podría atraer tráfico diferente al de una dirección previamente asociada con otro servicio.

La futura expansión del proyecto debería hacer más informativas las comparaciones geográficas. Más direcciones, una distribución regional equilibrada y mediciones mensuales repetidas ayudarían a distinguir patrones duraderos de picos de campañas de corta duración.

Publicar resultados por sensor añadiría otra capa. Si un honeypot recibió la mayor parte del tráfico neerlandés, los investigadores podrían examinar si un escáner apuntó a un rango estrecho de direcciones. Si todos los sensores observaron un comportamiento similar, es probable que la campaña escaneara de forma más amplia.

Para los defensores, la lección operativa es más sencilla que el mapa. Bloquear países enteros basándose en esta muestra crearía una falsa sensación de seguridad. Los límites de tasa, la autenticación basada en claves, las restricciones de cuentas y la monitorización abordan el método de ataque de forma más directa.

En qué se convierten los ataques a credenciales SSH tras un inicio de sesión exitoso

Los intentos fallidos son tráfico de fondo hasta que uno tiene éxito, momento en el que la misma automatización puede convertir un servidor en infraestructura de ataque.

El honeypot no observó comandos posteriores al inicio de sesión, por lo que no puede afirmar qué pretendían hacer después sus escáneres. La investigación independiente sobre incidentes proporciona el contexto que falta.

MITRE clasifica la adivinación de contraseñas como una técnica de acceso a credenciales e identifica SSH en el puerto TCP 22 como un objetivo común. Su entrada sobre adivinación de contraseñas también describe los fallos repetidos seguidos de un posible éxito como un patrón de detección importante.

Una contraseña exitosa hace más que exponer una terminal interactiva. La cuenta podría proporcionar acceso a código fuente, archivos de entorno, claves privadas, tokens de nube, credenciales de bases de datos o sistemas de despliegue.

Los privilegios determinan el daño inmediato. Un inicio de sesión como root otorga a un atacante un control amplio. Una cuenta de servicio restringida aún puede exponer datos valiosos o permitir movimiento lateral mediante permisos de archivos débiles y credenciales heredadas.

Los atacantes también pueden modificar la configuración de autorización de SSH para mantener la persistencia. MITRE documenta la incorporación de claves controladas por el adversario a authorized_keys, incluso a través de interfaces de gestión en la nube. Una clave implantada permite que un intruso regrese después de que cambie la contraseña original.

Microsoft ha documentado malware que comienza con fuerza bruta automatizada contra SSH. Su análisis de amenazas de Linux describe un inicio de sesión exitoso seguido de un script malicioso y un bot controlado mediante IRC.

Esa botnet respaldaba actividades de denegación de servicio distribuida y ejecución arbitraria de comandos. Otros compromisos de Linux utilizan sistemas capturados para minería de criptomonedas, envío de spam, escaneo o tráfico de proxy.

Una investigación independiente sobre ataques a Linux rastreó un compromiso exitoso por fuerza bruta de SSH a través de descargas escalonadas de scripts. El servidor afectado se convirtió después en un punto de lanzamiento para actividades maliciosas más amplias.

Estos casos explican por qué los fallos repetitivos merecen atención. Un escáner puede probar miles de combinaciones débiles a bajo coste. Solo necesita una cuenta expuesta para que ese esfuerzo resulte rentable.

También muestran por qué el conjunto de datos de Uphill Security no debe tratarse como una filtración de contraseñas. La señal importante es el flujo de trabajo automatizado alrededor de esas conjeturas. Los atacantes buscan continuamente sistemas donde las credenciales comunes siguen funcionando.

Los resultados de root revelan el desajuste más claro entre riesgo y comodidad. Los administradores de producción a veces conservan el acceso root para operaciones de emergencia. Los bots asumen que una fracción de esos sistemas también permitirá la autenticación mediante contraseña.

Las cuentas de servicio plantean un problema más sutil. Los equipos pueden crear usuarios git, deploy o de bases de datos para la automatización y luego pasar por alto los permisos de inicio de sesión interactivo. Los antiguos scripts de despliegue pueden conservar contraseñas mucho después de que cambie el flujo de trabajo original.

Deshabilitar un shell interactivo ayuda, pero los administradores deben revisar la configuración completa de SSH. El reenvío de puertos, la ejecución de comandos, la transferencia de archivos y el comportamiento de comandos forzados pueden crear distintas rutas de acceso tras la autenticación.

Los permisos en la nube amplían el posible radio de impacto. Una máquina virtual comprometida podría acceder a metadatos de instancia, identidades adjuntas, servicios internos o secretos de despliegue. La cuenta local puede convertirse en un punto de entrada a un entorno más amplio.

Aquí es donde los datos de honeypots SSH se vuelven útiles desde el punto de vista operativo. Indican a los equipos qué nombres de usuario reciben atención rutinaria y cuánta protección ofrece realmente la falta de visibilidad de un servicio público. También aportan entradas realistas para validar alertas y controles de limitación de tasa.

La pregunta correcta no es si funciona cada combinación intentada. Es si alguna cuenta de producción sigue siendo capaz de aceptar una de ellas.

Los datos respaldan el endurecimiento, pero no conclusiones universales

El experimento refuerza el argumento para eliminar la exposición basada en contraseñas, aunque deja varias preguntas de investigación sin responder.

La respuesta defensiva más clara es exigir autenticación con clave pública para el acceso administrativo por SSH. Una clave privada ofrece mucha más resistencia a las conjeturas en línea que una contraseña elegida por una persona.

CISA aconseja a los administradores exigir autenticación con clave pública cuando sea viable, deshabilitar la autenticación mediante contraseña y limitar los intentos repetidos. Su guía de endurecimiento de SSH también recomienda separar los servicios de administración del tráfico habitual de Internet.

Mover SSH a otro puerto puede reducir los escaneos ruidosos, pero no sustituye los controles de autenticación. Los escáneres amplios pueden descubrir servicios en puertos no estándar. Un cambio de puerto reduce principalmente el tráfico poco sofisticado y el volumen de registros.

Deshabilitar el inicio de sesión directo como root elimina de los accesos basados en contraseña a la identidad más atacada. En su lugar, los administradores deben usar cuentas nominales, privilegios limitados y elevación controlada.

Las cuentas de servicio no utilizadas también merecen revisión. Una cuenta git o deploy debe exponer únicamente las capacidades que requiere su flujo de trabajo. La configuración debe denegar shells, reenvío, subsistemas y comandos que el servicio no necesite.

La limitación de tasa añade otra capa. NIST describe la ralentización como una defensa principal contra las conjeturas de contraseñas en línea. Su guía sobre contraseñas también favorece las listas de bloqueo y las credenciales generadas por máquinas frente a reglas arbitrarias de composición.

Los registros deben vincular los fallos con los éxitos posteriores. Diez mil contraseñas rechazadas desde una dirección pueden ser ruido, pero estar contenidas. Un inicio de sesión exitoso después de fallos repetidos exige una investigación inmediata.

Los equipos también deben supervisar lo que ocurre después de la autenticación. Procesos nuevos, escaneos salientes, ancho de banda inesperado, claves modificadas, tareas programadas, directorios ocultos y conexiones a pools de minería pueden revelar un compromiso.

El aislamiento de red reduce las consecuencias de una alerta no detectada. Las cargas de trabajo públicas no deben recibir acceso sin restricciones a sistemas de administración, bases de datos sensibles ni almacenes de credenciales. El principio de mínimo privilegio importa incluso cuando la autenticación falla.

Sin embargo, el proyecto Uphill Security todavía presenta limitaciones importantes. Quince direcciones IP observadas durante un mes no pueden describir todas las regiones, proveedores ni temporadas. Las campañas comienzan y terminan, mientras los escáneres ajustan sus diccionarios.

El honeypot registró los valores enviados, pero no los validó frente a servicios externos. Esa validación sería éticamente peligrosa y posiblemente ilegal. Los investigadores no deben probar las combinaciones recopiladas contra sistemas no relacionados.

El proyecto también publicó cadenas de credenciales reversibles. Aunque los valores provenían de atacantes, algunos pueden coincidir con contraseñas reales por casualidad o reutilización. Aplicar hash a futuras publicaciones permitiría analizar frecuencias con una exposición innecesaria menor.

El autor ya incluye el hash de contraseñas entre las mejoras previstas. La comparación cruzada con listas de contraseñas conocidas también podría separar las entradas habituales de diccionarios de los valores inusuales. Ese proceso debe utilizar datos de referencia obtenidos de forma legal y responsable.

Una cronología más detallada revelaría la estructura de las campañas. Los investigadores podrían agrupar ráfagas por red de origen, orden de credenciales, comportamiento de conexión y cobertura de sensores. Secuencias similares podrían revelar software de escaneo compartido sin requerir atribución de los atacantes.

Un entorno de mayor interacción podría mostrar qué sucede después de la autenticación, pero implica un riesgo mayor. Ese honeypot debe contener a los intrusos, restringir el abuso saliente e impedir que el señuelo perjudique a otros sistemas.

Esto crea la disyuntiva central del proyecto. Un honeypot simple captura de forma segura telemetría amplia de autenticación, pero carece de profundidad de comportamiento. Un sistema realista proporciona evidencia más rica, al tiempo que aumenta las exigencias de contención, legales y operativas.

Los resultados actuales respaldan un endurecimiento práctico porque los atacantes prueban repetidamente cuentas predecibles. No respaldan afirmaciones sobre tasas globales de compromiso, nacionalidad de los atacantes o la validez en el mundo real de 131.922 pares de credenciales.

Qué observar después de la atención de Hacker News

La siguiente fase debería probar si estos patrones persisten, si las campañas se agrupan entre sensores y qué intentan hacer los bots exitosos tras la autenticación.

La primera señal es la consistencia mensual. Otro período de recopilación puede mostrar si root, admin y las contraseñas numéricas cortas siguen predominando. Clasificaciones estables respaldarían la conclusión de que los diccionarios estándar impulsan gran parte de la actividad.

Los grandes cambios en la clasificación apuntarían a una rotación de campañas. Un aumento repentino de un nombre de usuario específico de un producto podría reflejar una nueva selección de objetivos, un patrón de configuración filtrado o un escáner que recorre repetidamente la red.

La segunda señal es la distribución a nivel de sensor. Las estadísticas por dirección y región revelarían si el tráfico intenso alcanza toda la red o se concentra en una subred. Esa distinción mejoraría la interpretación del pico en los Países Bajos.

Un despliegue geográfico equilibrado reforzaría las comparaciones. La concentración europea actual dificulta generalizar los totales brutos por continente. Más proveedores también podrían reducir la influencia del historial de direcciones de una única empresa de alojamiento.

La tercera señal es el comportamiento controlado posterior a la autenticación. Un entorno cuidadosamente aislado podría aceptar combinaciones señuelo seleccionadas y registrar los primeros comandos emitidos por los atacantes. Eso conectaría las conjeturas de credenciales con objetivos medibles.

La contención debe ser lo primero. El entorno debe bloquear escaneos salientes, spam, tráfico de denegación de servicio y acceso a secretos reales. Los investigadores también necesitarían políticas claras de retención, privacidad y divulgación.

Las futuras publicaciones deberían distinguir, cuando sea posible, entre conjeturas generadas y listas reutilizadas. El análisis de secuencias puede ayudar porque los escáneres suelen enviar credenciales en órdenes coherentes. Hacer coincidir esas secuencias entre direcciones IP puede identificar herramientas compartidas.

Publicar hashes en lugar de contraseñas reversibles también mejoraría el diseño de la investigación. Los lectores podrían comparar valores débiles conocidos mediante procedimientos documentados sin recibir una lista en texto plano de envíos de atacantes.

La respuesta de Hacker News ya ha aportado una corrección útil: los grandes números necesitan etiquetas precisas. «Pares de credenciales enviados» describe con exactitud la evidencia. «Credenciales recopiladas» corre el riesgo de implicar una validez que el experimento nunca comprobó.

Para los operadores, la siguiente acción no depende de investigaciones futuras. Hagan inventario de todos los servicios SSH expuestos a Internet, verifiquen que la autenticación mediante contraseña esté deshabilitada y revisen si las cuentas de servicio permiten más acceso del previsto.

Los equipos deben conservar esas decisiones junto con las notas de incidentes, configuraciones y evidencias de autenticación. Una base de conocimientos de ingeniería con capacidad de búsqueda puede ayudar a mantener conectado el contexto operativo entre documentos locales.

Luego formulen una pregunta directa: si un escáner automatizado prueba root:123456 esta noche, ¿su servidor se limitará a registrar el intento o se convertirá en la infraestructura de otra persona?