Username enumeration

La enumeración de usuarios consiste en averiguar qué cuentas existen en un sistema antes de atacar sus contraseñas. Es un paso previo barato y muy rentable: reduce el espacio de la fuerza bruta (solo gastamos intentos en usuarios reales) y, a menudo, una cuenta válida ya es media intrusión.

El patrón: respuestas que delatan. El fallo casi siempre está en que la aplicación responde distinto según el usuario exista o no. Cualquier diferencia observable sirve de oráculo:

• Mensajes distintos en el login ("usuario incorrecto" vs "contraseña incorrecta").
• Formularios de recuperación de contraseña que confirman si el correo o el usuario existe.
• Páginas de registro que avisan "ese usuario ya está en uso".
• Diferencias de tiempo de respuesta (un usuario válido procesa el hash, uno inválido no).
• Distinto código de estado o longitud de la respuesta.

Cómo se explota. Se intercepta una petición legítima, se sustituye el campo del usuario por una variable y se itera una lista filtrando por aquello que cambie. Con wfuzz se filtra por longitud (--hh) o por código:

wfuzz -u 'http://<domain>' -d 'user_name=FUZZ&action=forgot' -w <userlist.txt> --hh=<len_base>

Generar la lista de candidatos. A partir de nombres reales (de la web, de metadatos, de LinkedIn) se generan las variantes habituales (j.smith, jsmith, smithj, john) con username-anarchy:

username-anarchy --input-file <names> > userlist.txt

En entornos Windows / AD existen oráculos equivalentes a nivel de protocolo: Kerberos (kerbrute userenum, que distingue usuarios válidos por la respuesta del KDC), SMB con RID cycling (lookupsid) o RPC. Allí la enumeración alimenta luego un password spraying, un AS-REP roasting o un Kerberoasting.

Cómo detectarlo. La firma es el volumen: un mismo origen iterando el campo de usuario (login, registro o recuperación) con decenas o cientos de valores distintos en poco tiempo, visible como una ráfaga de peticiones al mismo endpoint en el log de acceso, a menudo con una longitud/estado de respuesta que se repite. Un WAF o un contador de intentos por IP lo marca; que las peticiones lleguen de una lista ordenada (admin, administrator, j.smith…) refuerza la sospecha. En Windows/AD, los oráculos de protocolo dejan su propio rastro (ver enumeración por Kerberos con 4768 código 0x6, o el RID cycling con 4661). La clave defensiva es contar sondas por origen, no la petición aislada.

Defensa. Respuestas idénticas existan o no el usuario (mismo texto, mismo código, mismo tiempo, neutralizando el canal temporal); limitar el ritmo de peticiones (rate limiting) y aplicar CAPTCHA en formularios sensibles; no confirmar nunca la existencia de una cuenta en registro o recuperación. Relacionado con fuerza bruta y, en dominios, con Kerberoasting.