Resumen

  • APNIC observó 2.621 IP de origen ejecutar el mismo comando después de entrar por SSH en un honeypot. La orden eliminaba ~/.ssh, escribía una clave en authorized_keys y ajustaba los permisos.
  • Con la clave instalada, la contraseña deja de ser necesaria para esa vía. APNIC publica la huella SHA-256 y afirma que cualquier servidor que la tenga en authorized_keys está comprometido.

La contraseña consigue la entrada. La clave se queda con una copia.

En el informe de una semana de su honeynet reconstruido, APNIC registra 2.621 IP de origen que ejecutaron el mismo comando después de iniciar sesión por SSH. La orden borra el directorio ~/.ssh existente, escribe una clave controlada por el atacante en authorized_keys y establece los permisos. APNIC resume el efecto sin rodeos: instalada la clave, ya no hace falta la contraseña.

La primera sesión abre el acceso. Después, una clave pública nueva sustituye el registro de confianza de la cuenta. El comando borra primero el directorio que guardaba las claves SSH y escribe la autorización nueva. La cuenta recibe una vía de entrada que su operador nunca concedió.

El honeynet observó esa secuencia en sus propios señuelos. El contexto importa porque define una evidencia concreta: una acción repetida después del acceso y un indicador que cualquier operador puede buscar. APNIC publica la huella SHA256:MkYY9qiVsFGBC5WkjoClCkwEFW5iSjcGQF7m4n4H7Cw; el comentario de la clave termina en mdrfckr. La instrucción de APNIC es clara: un servidor con esa clave en authorized_keys está comprometido.

Entre el 21 y el 27 de septiembre, 9.669 IP de origen intentaron iniciar sesión por SSH y 2.621 ejecutaron la orden tras acceder. APNIC registra por separado 8.797 IP que dejaron archivos en sus sensores, con 506 archivos distintos. El informe no publica la intersección entre ambos grupos; cada medición conserva su propio perímetro.

La contraseña y la clave pública son vías de acceso separadas. Cambiar la contraseña actualiza la primera; la clave plantada sigue autorizada mientras permanezca en authorized_keys y el servidor acepte ese método.

La respuesta empieza por la evidencia: buscar la huella en todos los archivos authorized_keys, revisar cambios inesperados en ~/.ssh y determinar qué hizo la sesión. Si aparece la clave, APNIC clasifica el servidor como comprometido. Retirar el acceso no autorizado, delimitar los cambios, restaurar las claves legítimas desde un inventario confiable y renovar las contraseñas expuestas.

El honeynet de APNIC observa SSH, Telnet, Windows y otros servicios simulados. La secuencia clave muestra cómo un inicio de sesión deja una credencial que el operador nunca emitió.

Fuente: informe semanal de APNIC sobre su honeynet.