Username enumeration

Username enumeration is the act of finding out which accounts exist on a system before attacking their passwords. It is a cheap, high-value preliminary step: it shrinks the brute-force space (we only spend attempts on real users) and, often, a single valid account is already half the intrusion.

The pattern: responses that give it away. The flaw is almost always that the application responds differently depending on whether the user exists. Any observable difference works as an oracle:

• Different login messages ("invalid user" vs "invalid password").
• Password recovery forms that confirm whether the email or user exists.
• Registration pages that warn "that username is already taken".
• Response timing differences (a valid user processes the hash, an invalid one does not).
• Different status code or response length.

How it is exploited. Intercept a legitimate request, replace the user field with a variable and iterate a list filtering by whatever changes. With wfuzz you filter by length (--hh) or by code:

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

Generating the candidate list. From real names (off the website, metadata, LinkedIn) you generate the usual variants (j.smith, jsmith, smithj, john) with username-anarchy:

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

In Windows / AD environments there are protocol-level equivalents: Kerberos (kerbrute userenum, which tells valid users apart by the KDC response), SMB with RID cycling (lookupsid) or RPC. There, enumeration then feeds a password spray, an AS-REP roast or a Kerberoast.

How to detect it. The signature is volume: a single source iterating the username field (login, registration or recovery) with dozens or hundreds of distinct values in a short window, visible as a burst of requests to the same endpoint in the access log, often with a repeating response length/status. A WAF or a per-IP attempt counter flags it; requests arriving from an ordered list (admin, administrator, j.smith…) reinforce the suspicion. In Windows/AD, the protocol oracles leave their own trace (see Kerberos enumeration with 4768 code 0x6, or RID cycling with 4661). The defensive key is counting probes per source, not the isolated request.

Defence. Return identical responses whether or not the user exists (same text, same code, same timing, neutralising the time channel); rate-limit requests and apply CAPTCHA on sensitive forms; never confirm an account's existence on registration or recovery. Related to brute force and, in domains, to Kerberoasting.