AlphaONE Operations

22,468 password hashes.
12,016 recovered.
One afternoon.

After landing Domain Admin on a client network, we dumped every NTLM hash in Active Directory and fed them to our hashcat cluster. Before the day was out, we'd recovered the plaintext credentials for 53.48% of the domain. More than twelve thousand accounts, wide open.

The part that stings: nearly every recovered password was technically compliant. Eight characters minimum. Upper, lower, number, symbol. The audit tool never blinked once while we had the keys to the kingdom.

Here's where the policy fell apart:
-18.5% of recovered passwords hit exactly the 8-character floor, nothing more.
-49.8% had full complexity: letters, a special character, and a digit.
-Only 36% cleared the 12-character bar recommended by PCI DSS 4.0.
-Just 7.6% met the NIST 800-63B Rev 4 single-factor threshold of 15 characters.

Phase 1 used pure mask attacks against the policy requirements: 0.10% recovered. Phase 2 added rockyou with no rules: 1.50% cumulative. Phase 3 layered in the public d3ad0ne ruleset (34,000+ transformations): 13.91%. Phase 4 brought our internal wordlist and custom rules: 50.20% of accounts were unique, for a total of 53.48%.

That proprietary tooling delta tells the whole story. Off-the-shelf public tools left 7,621 passwords standing. Our internal corpus knocked them down in a single phase. No compliance scan, NIST checklist, or audit dashboard can see that gap.

The complete analysis is in the comments: all four phases with full hashcat syntax, length and pattern breakdowns, crack-time projections across five hardware tiers (from a single laptop GPU to our 12-GPU, 4.3 TH/s rig), and framework mapping.

When was the last time someone actually cracked your AD hashes? Not just reviewed the policy. Not just running an audit. Cracked the hashes.

9:00:00 AM, we connected to the network.
9:00:11 AM, we walked away with six domain credential hashes belonging to three separate users.

Eleven seconds. A Monday morning. Before anyone had finished their first cup of coffee.

The technique is LLMNR / NBT-NS poisoning. NBT-NS goes back to the late 1980s and LLMNR to 2007, yet both remain enabled out of the box on every current Windows release, Windows 11 24H2 and Windows Server 2025 included, and we encounter them on internal assessments week after week.

Nothing fancy is required. Drop a laptop onto any available network jack (a conference room, a vacant cubicle, the wall port in the lobby), launch Responder, and sit back. Whenever a Windows host fails to resolve a name through DNS (a typo, an outdated mapped drive, a retired server, a WPAD query, a dead shortcut, or an entry lingering in Office's "Recent Files"), it broadcasts asking the local network for help. Responder happily replies. The Windows client then willingly hands its logged-in user's NTLMv2 credentials over to whatever machine responded.

What happens to those hashes next:

- They get cracked offline (hashcat, mode 5600). During the last engagement, we pulled Domain Admin out of a single captured LLMNR hash using off-the-shelf hardware.
- They get relayed live through ntlmrelayx. A single grabbed authentication produced SAM hash dumps from seven hosts inside the environment. The hash was simply passed along; nothing was cracked; no vulnerability was exploited.
- They get correlated. Hashes we never crack still expose usernames, which machines map to which users, patterns of network behavior, and which accounts hold admin rights based on which relays succeed.

The mitigation has been documented publicly for more than ten years. Yet we keep discovering LLMNR / NBT-NS turned on in roughly nine out of every ten environments we review.

The complete breakdown, covering the Responder switches we used, the NetNTLMv2 capture itself, both the cracking and relaying workflows, the telltale defender-side indicator (Event 3012 in the `Microsoft-Windows-DNS-Client/Operational` log channel), and the full set of GPO, registry, and DHCP fixes, is linked in the comments.

How recently has anyone verified that your network is only replying to the hosts it's supposed to?