For years I used OneRuleToRuleThemAll for every AD hash cracking session. In January 2023, its own creator published a better version. I was ignoring it.

MITRE ATT&CK: T1110.002 — Brute Force: Password Cracking

Not intentionally. The old rule was in my workflow, it worked well enough, and I had no reason to go looking. That is exactly the problem. The tool you default to because it has always been good enough is the one you never audit.

The new rule is called OneRuleToRuleThemStill. It was published in January 2023 by the same researcher who built the original — stealthsploit, from in.security. Same crack rate. Fewer rules. Faster sessions. Here is what changed and why you should care.

What Is a Hashcat Rule and Why Does It Matter for AD Hash Cracking?

A hashcat rule is a transformation applied to every wordlist entry before testing it against a hash, turning base words like password into corporate variants like Password1, p@ssw0rd, or Spring2026! without storing those mutations explicitly.

Before the comparison, a quick grounding for anyone newer to this.

A hashcat rule is a transformation applied to every word in a wordlist before testing it against a hash. $1 appends the digit 1. c capitalizes the first letter. s@a substitutes every a with @. Rules let you turn password into Password1, p@ssw0rd, PASSWORD!, or thousands of other mutations — without storing those mutations explicitly in the wordlist.

Rules are where corporate password cracking happens. Real breach wordlists already contain password. What they do not contain is Spring2026! or Welcome123 — the patterns that dominate corporate environments because administrators set them and never rotate them. Rules derive those patterns from base words.

OneRuleToRuleThemAll became the standard because it was trained on massive real-world password datasets and had extraordinarily high crack rates. The problem is that it accumulated rules over time — including duplicates and rules that never actually cracked anything.

How Does OneRuleToRuleThemStill Compare to OneRuleToRuleThemAll?

Both rules achieve identical crack rates across 25 million test passwords — OneRuleToRuleThemStill simply removes 623 rules that cracked nothing and 1,912 duplicates, making each session faster with zero coverage loss.

	OneRuleToRuleThemAll	OneRuleToRuleThemStill
Rules	~52,000 (50,088 deduped)	49,465
Lifeboat crack rate (~4.3M passwords)	63.36%	63.36%
LastFM crack rate (~21M passwords)	69.8%	69.8%
Duplicate rules removed	—	1,912
Rules that cracked nothing	—	623 eliminated
Published	~2019	January 2023
Creator	stealthsploit (in.security)	Same creator

Source: in.security — OneRuleToRuleThemStill (January 2023)

The crack rate is identical. That is the key data point. Across 4.3 million Lifeboat passwords and 21 million LastFM passwords, the two rules produce the same coverage. OneRuleToRuleThemStill achieves that coverage with 623 fewer rules that contributed nothing — they were tested against 25 million real passwords and cracked zero of them — and 1,912 duplicate rules removed.

The upgrade is not about finding more passwords. It is about not wasting time on transformations that have been empirically shown to crack nothing.

How Do You Download and Use OneRuleToRuleThemStill with Hashcat?

Download the rule with wget from the stealthsploit repository and pass it with -r OneRuleToRuleThemStill.rule — mode 1000 for NTLM, mode 13100 for Kerberoasting RC4 hashes.

Download the rule directly from the repository:

wget https://raw.githubusercontent.com/stealthsploit/OneRuleToRuleThemStill/main/OneRuleToRuleThemStill.rule

NTLM hashes with all-h.txt

hashcat -m 1000 -O hashes.txt all-h.txt -r OneRuleToRuleThemStill.rule

Mode 1000 is NTLM. The -O flag enables optimized kernels for a throughput improvement — use it when you know your passwords are under 32 characters, which they almost always are in corporate environments.

Kerberoasting hashes (RC4)

hashcat -m 13100 -O kerberoast.hashes all-h.txt -r OneRuleToRuleThemStill.rule

Mode 13100 is Kerberos 5 TGS-REP etype 23 — the RC4-HMAC ticket produced when a service account supports RC4. These crack at similar speeds to NTLM on modern hardware.

Check estimated time before committing

Before starting a long session, estimate the keyspace:

hashcat -m 1000 hashes.txt all-h.txt -r OneRuleToRuleThemStill.rule --keyspace

This returns the number of candidates without running any cracking. Divide by your hardware's hash rate (visible from a short -n 1 test run) and you have a time estimate. Useful before leaving a session overnight.

What Is the Correct Wordlist Ordering for AD Hash Cracking Engagements?

The correct order is: hashmob.medium with no rules first, then all-h.txt with no rules, then all-h.txt + OneRuleToRuleThemStill, then all_in_one.txt only if earlier sessions did not crack target accounts.

Rules are not the first step. Running a 50,000-rule mutation on a large wordlist immediately is slower than starting with direct hits.

This is the sequence that consistently performs in real internal assessments:

hashmob.medium — no rules. Zero time investment. Catches passwords that appear verbatim in recent breach aggregates. If someone reused a breach password, you have it in minutes.
all-h.txt — no rules. A curated wordlist of real passwords. Runs in roughly 16 minutes against a typical domain hash dump on a mid-range GPU. This is where administrator-set defaults appear (Welcome1, Passw0rd, company name + year).
all-h.txt + OneRuleToRuleThemStill. Mutations on real passwords. This is where corporate patterns crack. The base word Welcome plus rules produces Welcome1, Welcome123, Welcome2026!. The base word Spring plus rules produces Spring2026!. If accounts have been set following internal conventions that mutate real words, this is where you find them.
all_in_one.txt. Large aggregated wordlist, only if the above sessions did not crack target accounts.

Rules matter more in corporate environments than in consumer breach contexts precisely because corporate passwords are not random — they follow internal conventions that administrators enforced, and those conventions are mutations of recognizable words.

What Is the Practical Performance Gain of OneRuleToRuleThemStill?

The practical gain is not more coverage but fewer wasted cycles — 623 empirically useless rules removed means slightly faster sessions and confidence that every transformation in the file was validated against 25 million real passwords.

The rule itself is not magic. Rules are transformations — capitalize the first letter, append digits, substitute letters with symbols. What makes OneRuleToRuleThemStill better than the original is not what it adds, but what it removes: 623 rules that never cracked a single hash across 25 million test passwords. CPU cycles spent on hopeless transformations are CPU cycles not spent on the ones that crack.

The practical result: if a cracking session with the old rule took 4 hours, the same session with OneRuleToRuleThemStill runs slightly faster — fewer rules means fewer candidates per word. Over a career of assessments, and especially on hardware where parallelism is constrained, that compounds.

The deeper gain is confidence. When you know the rules in your file were validated against real password datasets and the ones that contributed nothing were removed, you trust the coverage. You are not running dead weight.

Where Does ADscan Fit in the Hash Cracking Workflow?

ADscan automatically saves all Kerberoasting and NTLM hashes to the workspace indexed by account, so you export directly to hashcat and reimport cracked credentials with full attack-path context for the client report.

ADscan saves Kerberoasting hashes and NTLM hashes to the workspace automatically after each collection command. You do not manage output files manually — the workspace tracks them.

With ADscan PRO, when you run adscan deliver, cracked credentials are pulled from the workspace and embedded in the client report. Each cracked account appears with its role in the domain, its attack path context — which escalation paths it enables, which groups it reaches — and the remediation guidance. The finding section is generated automatically from the evidence collected during the engagement.

You crack the hash. ADscan builds the narrative around it.