Cracking 60% of Passwords in a Single Afternoon

Eight hundred and forty-seven hashes. Five hundred and twelve cracked. One afternoon.

Passwords are the oldest authentication mechanism in computing. They are also, by a considerable margin, the most frequently compromised. Despite decades of policy evolution — minimum lengths, complexity requirements, rotation mandates, breach database checks — passwords remain the path of least resistance for attackers and the most persistent source of findings on our penetration tests.

The reason is not that organisations fail to implement password policies. Most do. The reason is that the policies themselves — eight characters, one uppercase, one number, one special character, rotate every ninety days — produce passwords that are predictably structured, trivially crackable, and yet technically compliant. The policy is satisfied. The password is weak. The compliance checkbox is ticked. The domain is compromised.

On this engagement, we obtained the password hashes for every domain account and cracked sixty per cent of them in a single afternoon — five hundred and twelve passwords from eight hundred and forty-seven accounts. The cracking did not require exotic hardware or novel techniques. It required a mid-range GPU, a publicly available wordlist, and knowledge of the patterns that human beings use when forced to create passwords that meet complexity rules.

The Engagement Brief

The client was an insurance company with approximately eight hundred and fifty staff across a headquarters and two regional offices. They operated a mature IT environment — on-premises Active Directory, Microsoft 365 hybrid identity, Intune-managed endpoints, and a security operations team that monitored a SIEM. Their password policy was the industry standard: minimum eight characters, must contain uppercase, lowercase, numeric, and special characters, with a ninety-day rotation cycle.

We had been engaged to conduct an internal network penetration test. Credential capture and password cracking were within scope. The client was interested in understanding the real-world strength of their password policy — not the theoretical strength implied by the complexity rules, but the actual resistance of their users' passwords to a determined attacker.

We began by capturing credentials on the wire.

Credential Capture — Poisoning the Network

Before cracking passwords, you need password hashes. There are several methods to obtain them in a Windows Active Directory environment. The most common during an internal penetration test — and the one we employed first — exploits legacy name resolution protocols that Windows systems still use by default.

LLMNR (Link-Local Multicast Name Resolution) and NBT-NS (NetBIOS Name Service) are fallback name resolution protocols. When a Windows system cannot resolve a hostname via DNS, it broadcasts a query on the local network using LLMNR or NBT-NS, asking: does anyone know where [hostname] is? Any device on the network can respond. An attacker responds with their own IP address, and the requesting system sends its authentication credentials — in the form of a NetNTLMv2 hash — to the attacker.

Seventy-three unique NetNTLMv2 hashes captured in four hours of passive collection. Each hash represented a domain user whose workstation had attempted to resolve a non-existent hostname — a mistyped server name, a stale drive mapping, a legacy shortcut pointing to a decommissioned system — and had broadcast the query on the network. Our tool answered the query and received their authentication hash.

LLMNR and NBT-NS poisoning is a well-documented attack that has been a standard finding on penetration tests for over a decade. Microsoft has provided guidance on disabling both protocols via Group Policy. Many organisations have not done so. This client had not.

The Full Domain — DCSync

The seventy-three captured hashes were valuable, but they represented only a sample of the organisation's password landscape. To assess the full domain password posture, we needed every hash.

Through a separate attack path during the engagement — a chain involving a misconfigured service account with replication rights, identified through BloodHound analysis — we obtained DCSync privileges. DCSync allows an attacker to request the password hash for any domain account directly from a domain controller, replicating the behaviour of a secondary domain controller requesting synchronisation.

We extracted the NTLM hash for every account in the domain.

Eight hundred and forty-seven accounts. Seven hundred and forty-three active users, fifty-eight service accounts, and forty-six disabled accounts that had not been removed from the directory. The NTLM hashes — unlike the NetNTLMv2 hashes captured via Responder — are direct password hashes that can be cracked offline or used directly in pass-the-hash attacks.

We loaded the hashes into our cracking workstation and began.

The Cracking Methodology

Password cracking is not random guessing. It is structured, iterative, and informed by decades of research into how human beings construct passwords. The most effective cracking strategies mirror the mental shortcuts that people use when creating passwords under complexity constraints.

We used a four-phase approach, progressing from the fastest and most targeted attacks to broader, more computationally expensive techniques.

Five hundred and twelve passwords cracked. Sixty per cent of the domain. Three hours of GPU time on a single consumer graphics card. The cost of the attack hardware was approximately fifteen hundred pounds.

The Anatomy of Cracked Passwords

The cracked passwords were not random strings that happened to be weak. They were the predictable output of human beings attempting to satisfy complexity rules with the minimum possible cognitive effort. The patterns were consistent, systematic, and deeply informative about the gap between password policy and password reality.

The dominant pattern — Season + Year + Special Character — accounted for nearly one in five cracked passwords. This pattern is a direct consequence of ninety-day password rotation. When users are forced to change their password every quarter, they adopt a mnemonic strategy: pick the current season, append the year, add an exclamation mark. The password satisfies every complexity rule. It also changes predictably — Summer2025! becomes Autumn2025! becomes Winter2025! becomes Spring2026! — a cycle that any attacker who cracks one iteration can predict forwards and backwards.

The second pattern — personal nouns with trailing numbers and symbols — reflects how people create memorable passwords. A football team, a pet's name, a child's name, a favourite band — followed by digits and a special character to satisfy the complexity requirement. These are trivially crackable because the base word is drawn from a small, enumerable dictionary, and the trailing modifications follow a handful of predictable patterns.

The company name pattern deserves particular attention. Sixty-three users — over twelve per cent of the cracked passwords — used the company name, the city where the office is located, or one of the company's brand names as the basis of their password. This pattern is the first one any penetration tester targets with a custom wordlist, because it is the first one any employee tries when forced to create a new password at their desk.

Service Accounts — The Unrotated

The fifty-eight service accounts in the domain were assessed separately. Service account passwords are typically set once during deployment and rarely changed — they are not subject to the ninety-day rotation policy because changing them risks breaking the services they support.

Seventy-two per cent of service accounts were cracked — a higher rate than user accounts. The oldest unchanged password was nearly eight years old. Over half of service account passwords had not been changed in more than three years. The passwords followed the same predictable patterns as user passwords, but without the quarterly rotation that at least forces users to create a new predictable password periodically.

Several of the cracked service accounts had elevated privileges — local administrator on servers, SQL sysadmin, backup operator, or membership in privileged Active Directory groups. A cracked service account password is particularly dangerous because service accounts are often excluded from MFA requirements, are not monitored for anomalous logon behaviour, and their credentials can be used for pass-the-hash attacks without ever needing to crack them.

Why Password Policies Produce Weak Passwords

The client's password policy was the de facto industry standard. Eight characters. Complexity enabled. Ninety-day rotation. It is the policy recommended by legacy compliance frameworks, implemented by default in Active Directory, and found in the majority of organisations we assess.

It is also, demonstrably, inadequate. Not because it is not enforced — it is. But because the passwords it produces, when created by human beings under real-world conditions, are systematically crackable.

What the Evidence Actually Says

The password policy debate has been settled by the evidence. NIST Special Publication 800-63B, updated in 2024, provides the most authoritative current guidance. The National Cyber Security Centre (NCSC) has published complementary guidance for UK organisations. Both sources agree on the fundamental principles, and both diverge significantly from the traditional eight-character-complexity-rotation model.

The key recommendations are clear. Increase minimum length to fourteen or fifteen characters. A fifteen-character password — even without complexity requirements — is exponentially harder to crack than an eight-character password with complexity. Length defeats hardware. Complexity defeats humans.

Eliminate mandatory rotation. NIST explicitly recommends against periodic password rotation unless there is evidence that a password has been compromised. Rotation drives the seasonal and sequential patterns that dominate the cracked password corpus. Removing rotation removes the incentive to create easily incremented passwords.

Encourage passphrases. The NCSC's 'three random words' strategy — combining three unrelated words into a passphrase like correct horse battery staple — produces passwords that are long (20+ characters), memorable, and resistant to dictionary attacks because the combination of words is unpredictable. A passphrase is easier to remember than a complex eight-character password and exponentially harder to crack.

Check passwords against breach databases. Services such as the Have I Been Pwned API allow organisations to check proposed passwords against a database of billions of known compromised passwords. If a user attempts to set a password that has appeared in a previous breach, the system should reject it — regardless of its length or complexity. The sixty-seven passwords we cracked in Phase 1 (known breached passwords) would have been blocked by this single control.

Technique Mapping

Recommendations and Hardening

Disabling LLMNR and NBT-NS is a zero-cost, zero-risk change that eliminates the most common credential capture vector on internal networks. It is a single Group Policy setting. There is no legitimate business requirement for these protocols in any modern environment — DNS provides all necessary name resolution. This setting should have been applied a decade ago.

Increasing minimum password length to fourteen characters is the single most impactful change to password security. An eight-character NTLM hash can be exhaustively searched in hours. A fourteen-character hash cannot be exhaustively searched with current hardware within any practical timeframe. Length defeats computational power in a way that complexity rules cannot.

Group Managed Service Accounts (gMSA) solve the service account password problem entirely. gMSAs are Active Directory accounts whose passwords are automatically generated (120+ character random strings), automatically rotated (every 30 days by default), and never known to any human. They eliminate the 'svc_backup / Backup2017!' problem because no human is involved in setting or managing the password.

MFA is the strategic answer. All of the cracking techniques described in this article produce a password. If the password alone is not sufficient to authenticate — if a second factor is required — then the cracked password has limited value. MFA does not make passwords unnecessary, but it makes their compromise survivable.

The policy said the passwords were strong. The GPU said otherwise.

Eight hundred and forty-seven passwords. Every one compliant with the organisation's policy. Every one containing uppercase, lowercase, a number, and a special character. Every one changed within the last ninety days. Every one meeting the requirements that the policy — and by extension, the compliance framework — defined as 'strong'.

Five hundred and twelve of them cracked in three hours.

The gap between policy compliance and actual security is nowhere wider than in password management. A password can satisfy every rule in the policy and still be cracked in seconds, because the rules measure the wrong things. They measure length in characters rather than entropy in bits. They measure the presence of character classes rather than the absence of predictable patterns. They measure how often passwords change rather than how resistant they are to cracking.

The evidence is clear. Length over complexity. Passphrases over passwords. Breach checking over rotation. MFA over all of it. The tools to implement every one of these recommendations exist today, in the same Active Directory and Entra ID platforms that every organisation already runs.

Until next time — stay sharp, stay curious, and go crack your own hashes. If you do not like what you find, neither will your auditors.