Project 21: Custom Wordlists for Defensive Testing

Module: Module 3: Defensive Tooling, Hardening & CTF Practice  |  Level: Beginner  | 
Primary tool: CeWL + Hashcat rules  |  Estimated time: 45–75 minutes

Objective: Build a targeted wordlist the way a real attacker would, then use it to demonstrate why policy matters.

Free lab environment

OverTheWire: Bandit (free wargame) — https://overthewire.org/wargames/bandit/

OverTheWire’s Bandit wargame is a free, legal, SSH-accessible series of levels built specifically for practicing authentication and credential-handling techniques safely. Sign in with the level credentials provided on the site; no account or payment required.

Lab workflow

1. Set up CeWL + Hashcat rules and confirm it is installed correctly with a harmless test run.
2. Generate or obtain your test material against a website you own, and OverTheWire Bandit — never point a credential-attack tool at a system you don’t have explicit authorization to test.
3. Run your attack/measurement to build a targeted wordlist the way a real attacker would, then use it to demonstrate why policy matters, using conservative rate limits so you understand what a real, cautious attacker (or a defensive test) actually looks like in logs.
4. Record the exact timing and success/failure counts — these numbers are what a detection rule would actually be built on.
5. From the defensive side, identify the specific log field or alert that would have caught this activity, and write the detection logic in plain English.
6. Summarize what a stronger control (rate limiting, longer minimum length, MFA) would have changed in your results.

Evidence & screenshot requirements

Submit the following with your report (see this module’s practical assignment for exact upload details):

• your CeWL-generated wordlist excerpt
• the crack result difference between a generic list (rockyou.txt) and your targeted list against the same test hash

Expected deliverable

A concise lab-report entry containing: scope/target, exact commands or payloads used, your key
observation, the required screenshots above, and — where applicable — the specific remediation for what
you found. Vague answers (“sanitize input”, “use a firewall”) without naming the exact mechanism will not
receive full credit.

Safety & authorization

Only test the specific free lab target named above, or infrastructure you personally own. Do not target
third-party systems, real user accounts, or production services without explicit written authorization.
Never deploy anything from this project outside an isolated lab environment.