Offensive Security 103: Password Attacks: Admin123 Is Not a Password Strategy

By Tech Corsair

Every security awareness training deck in existence contains a slide about strong passwords. Every organisation on earth has a password policy. And yet, year after year, the most common credential found in breach databases remains some flavour of "password123." The war between password policies and human laziness is civilisation's longest-running conflict, and laziness is winning by a comfortable margin.

This article covers the full spectrum of password attacks -- from the crude brute-force approach (the digital equivalent of trying every key on a keyring) through to the elegant horror of Active Directory credential attacks that can hand an attacker the keys to an entire enterprise. All techniques discussed here are strictly for authorised penetration testing engagements. Doing any of this without written permission is a fast track to a conversation with law enforcement, and orange has never been anyone's colour.

The Fundamentals: How Passwords Get Attacked

Before diving into the exotic stuff, it is worth understanding the basic categories of password attacks. Think of these as the infantry -- unsophisticated, but effective in sufficient numbers.

Brute Force: The "Try Everything" Approach

Brute force is exactly what it sounds like: systematically trying every possible combination of characters until the correct password is found. It is the most computationally expensive approach and the least clever, which is why it is also the most reliable against short passwords.

A four-character numeric PIN has 10,000 possible combinations. A modern GPU can exhaust that search space before a kettle boils. An eight-character alphanumeric password with special characters? That is roughly 6.6 quadrillion combinations. Suddenly brute force looks less appealing -- unless the target chose "Summer2026!" in which case dictionary attacks will get there first.

Dictionary Attacks: Standing on the Shoulders of Breaches Past

Dictionary attacks use pre-compiled wordlists of known passwords, common words, and predictable patterns. The logic is sound: why try every possible combination when most humans pick from a depressingly small pool of options?

The most famous wordlist is rockyou.txt -- 14 million passwords leaked from the RockYou breach in 2009. It remains devastatingly effective because humans have not meaningfully evolved their password habits since then. For more comprehensive coverage, SecLists (maintained by Daniel Miessler) provides categorised wordlists for every occasion, like a sommelier's guide to credential compromise.

Credential Stuffing: Recycling Is Not Always Green

Credential stuffing exploits the universal human habit of reusing passwords across services. An attacker takes username/password pairs from one breach and tries them against other services. When someone uses the same "FluffyCat99!" for their email, their banking, and their corporate VPN, a breach at any one of those services compromises all three.

This attack requires no cracking at all -- just a list and a script. Tools like Hydra and custom scripts make it trivially automatable. It is the reason multi-factor authentication exists, and the reason security teams age prematurely.

Password Spraying: Low and Slow

Password spraying is the inverse of brute force. Instead of trying many passwords against one account, it tries one or two common passwords against many accounts. The beauty (from an attacker's perspective) is that it often flies under the radar of account lockout policies.

Try "CompanyName2026!" against every account in the domain. Then wait thirty minutes. Try "Welcome1!" against every account. Wait again. Somewhere in that organisation, someone -- probably several someones -- has chosen exactly that password because it meets the complexity requirements while requiring the absolute minimum amount of thought.

"Password1!" meets most complexity policies. Upper case? Tick. Lower case? Tick. Number? Tick. Special character? Tick. Minimum eight characters? Tick. Secure? Absolutely not.

Hash Cracking: When You Have the Goods but Cannot Read Them

Passwords are (usually) not stored in plaintext. They are stored as hashes -- one-way mathematical transformations that produce a fixed-length output. The idea is that even if an attacker steals the hash database, they cannot reverse the hashes back to passwords. The reality is somewhat more nuanced.

Hashcat: The GPU-Powered Beast

Hashcat is the industry-standard password recovery tool, and it is terrifyingly good at its job. It leverages GPU acceleration to test billions of hash combinations per second, turning what should be a computationally infeasible problem into a Tuesday afternoon.

Basic NTLM hash cracking with a wordlist:

hashcat -m 1000 hashes.txt /usr/share/wordlists/rockyou.txt

Adding rules for common mutations (appending numbers, capitalising first letters, substituting characters):

hashcat -m 1000 hashes.txt /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule

Cracking Kerberos 5 TGS-REP hashes (Kerberoasting output):

hashcat -m 13100 kerberoast_hashes.txt /usr/share/wordlists/rockyou.txt

Brute-force attack on an eight-character password with all character sets:

hashcat -m 1000 hashes.txt -a 3 ?a?a?a?a?a?a?a?a

The -m flag specifies the hash type (1000 = NTLM, 13100 = Kerberos 5 TGS-REP, 1800 = SHA-512 Unix, and so on). The full list reads like a catalogue of every poor cryptographic decision ever made.

John the Ripper: The Classic

John the Ripper predates Hashcat and remains a staple in every penetration tester's toolkit. It is particularly useful for its format auto-detection and its ability to handle exotic hash formats.

john --wordlist=/usr/share/wordlists/rockyou.txt hashes.txt

With mangling rules:

john --wordlist=/usr/share/wordlists/rockyou.txt --rules=jumbo hashes.txt

Showing cracked passwords:

john --show hashes.txt

John's *2john utilities (e.g., zip2john, ssh2john, keepass2john) are enormously useful for extracting hashes from encrypted files -- because apparently people protect their password databases with passwords like "master123."

Rainbow Tables vs Salted Hashes: Why Salt Matters

A rainbow table is a precomputed lookup table mapping hashes back to their plaintext inputs. Instead of cracking each hash individually, an attacker simply looks it up. For unsalted hashes, this is devastatingly fast.

The defence is salting -- appending a random value to each password before hashing. If the salt is "x7Kp9" and the password is "Password1!", the hash is computed on "Password1!x7Kp9". Every user gets a unique salt, which means an attacker would need a separate rainbow table for every possible salt value. This makes precomputation infeasible and forces attackers back to cracking each hash individually.

Modern algorithms like bcrypt, scrypt, and Argon2 include salting by default and add computational cost (key stretching) to make each hash attempt deliberately slow. An NTLM hash can be tested at billions per second. A bcrypt hash with a reasonable work factor? Perhaps a few thousand per second. That is the difference between cracking a password in minutes and cracking it in centuries.

Systems still using unsalted MD5 or SHA-1 for password storage deserve whatever happens to them. There are no excuses left.

Active Directory Credential Attacks: The Crown Jewels

If basic password attacks are infantry, Active Directory attacks are special forces operations. AD is the beating heart of most enterprise networks, and its authentication protocols -- while cleverly designed -- offer a rich attack surface for anyone who knows where to look.

All of the following techniques require explicit authorisation. Performing these attacks against systems without written permission is illegal in virtually every jurisdiction.

Kerberoasting: Asking Politely for Crackable Hashes

Kerberoasting exploits Kerberos service ticket requests. Any authenticated domain user can request a service ticket (TGS) for any service account with a Service Principal Name (SPN). The ticket is encrypted with the service account's NTLM hash. Request the ticket, take it offline, crack the hash. The domain controller hands it over willingly -- it is a feature, not a bug.

Using Rubeus:

Rubeus.exe kerberoast /outfile:kerberoast_hashes.txt

Using Impacket:

impacket-GetUserSPNs -request -dc-ip 10.10.10.1 domain.local/username:password -outputfile kerberoast_hashes.txt

Then crack with Hashcat as shown above. Service accounts with weak passwords and high privileges are the jackpot here -- and an alarming number of them are set to "ServiceAccount1!" and never rotated.

AS-REP Roasting: Kerberoasting's Younger Sibling

AS-REP Roasting targets accounts that have Kerberos pre-authentication disabled. Without pre-authentication, an attacker can request an Authentication Service Response (AS-REP) for those accounts without providing any credentials at all. The response contains data encrypted with the user's hash, which can be cracked offline.

impacket-GetNPUsers -dc-ip 10.10.10.1 domain.local/ -usersfile users.txt -no-pass -outputfile asrep_hashes.txt

hashcat -m 18200 asrep_hashes.txt /usr/share/wordlists/rockyou.txt

The saving grace is that pre-authentication is enabled by default. The not-saving grace is that some legacy applications require it to be disabled, and nobody ever remembers to re-enable it.

Pass-the-Hash: Who Needs Passwords Anyway?

Pass-the-Hash (PtH) is the attack that makes NTLM authentication developers weep into their keyboards. In Windows NTLM authentication, the hash itself is used to authenticate -- not the plaintext password. An attacker who obtains an NTLM hash can authenticate as that user without ever knowing the actual password.

Using Impacket:

impacket-psexec -hashes aad3b435b51404eeaad3b435b51404ee:e19ccf75ee54e06b06a5907af13cef42 domain.local/administrator@10.10.10.5

Using CrackMapExec:

crackmapexec smb 10.10.10.0/24 -u administrator -H e19ccf75ee54e06b06a5907af13cef42

The hash is the password. This is not a vulnerability so much as a fundamental design property of NTLM, which is why Microsoft has been trying to deprecate it for approximately two decades with limited success.

Pass-the-Ticket: Kerberos Edition

Pass-the-Ticket (PtT) is the Kerberos equivalent of Pass-the-Hash. Instead of an NTLM hash, the attacker steals a Kerberos ticket (TGT or TGS) from memory and uses it to authenticate to other services.

Using Mimikatz:

mimikatz# sekurlsa::tickets /export
mimikatz# kerberos::ptt ticket.kirbi

Using Rubeus:

Rubeus.exe ptt /ticket:ticket.kirbi

Kerberos tickets have expiration times (typically 10 hours for TGTs), so there is a time pressure element. Attackers who have obtained a ticket are essentially on a countdown timer, which adds a certain heist-film tension to the proceedings.

DCSync: Impersonating a Domain Controller

DCSync abuses the Directory Replication Service protocol. Domain controllers replicate data between themselves using this protocol. If an attacker obtains an account with replication privileges (typically Domain Admins, Enterprise Admins, or accounts with the "Replicating Directory Changes" permission), they can impersonate a domain controller and request password hash replication for any account -- including the krbtgt account.

Using Mimikatz:

mimikatz# lsadump::dcsync /domain:domain.local /user:krbtgt

Using Impacket:

impacket-secretsdump -just-dc-ntlm domain.local/admin:password@10.10.10.1

DCSync does not require code execution on the domain controller itself. It is performed remotely, over standard network protocols, and generates surprisingly little noise in default logging configurations. This is the point in a penetration test where the report starts using phrases like "critical finding" and "immediate remediation required."

Golden Tickets: Game Over

A Golden Ticket is a forged Kerberos TGT created using the krbtgt account's NTLM hash. Since the krbtgt hash is used to sign all TGTs in the domain, possessing it allows an attacker to forge tickets for any user, with any group membership, with any expiration time.

mimikatz# kerberos::golden /user:administrator /domain:domain.local /sid:S-1-5-21-... /krbtgt:HASH /ptt

A Golden Ticket grants complete domain dominance and persists until the krbtgt password is reset -- twice (because AD retains the previous password for compatibility). Many organisations have never reset their krbtgt password. Some do not know it can be reset. This is the sort of thing that keeps CISOs awake at three in the morning.

Silver Tickets: The Precision Instrument

A Silver Ticket is a forged Kerberos service ticket (TGS) created using a service account's NTLM hash. Unlike Golden Tickets, Silver Tickets target specific services rather than the entire domain. They are harder to detect because they never touch the domain controller -- authentication happens directly with the target service.

mimikatz# kerberos::golden /user:administrator /domain:domain.local /sid:S-1-5-21-... /target:server.domain.local /service:cifs /rc4:SERVICE_HASH /ptt

Silver Tickets are the scalpel to the Golden Ticket's sledgehammer. Less powerful, but considerably stealthier.

The Wordlist Arsenal

No discussion of password attacks is complete without mentioning the essential wordlists:

• rockyou.txt -- 14 million real passwords; the AK-47 of wordlists -- reliable, available everywhere, and effective against targets who have not heard of password managers
• SecLists -- curated collections including top-10000-passwords.txt, darkweb2017-top10000.txt, and language-specific lists
• CeWL -- generates custom wordlists by spidering a target's website, because people love using their company name as a password
• CUPP (Common User Passwords Profiler) -- builds targeted wordlists based on personal information, for when the target's password is inevitably their dog's name followed by a birth year

cewl https://target-company.com -d 3 -m 6 -w custom_wordlist.txt

Defensive Takeaways

For the blue team members reading this with rising blood pressure:

• Enforce long passphrases over complex-but-short passwords. "correct horse battery staple" is better than "P@ssw0rd!" and everyone knows it
• Deploy multi-factor authentication everywhere. MFA does not make password attacks impossible, but it makes them dramatically harder
• Use Managed Service Accounts (gMSAs) for service accounts to eliminate Kerberoasting targets -- the passwords are 240 characters, randomly generated, and automatically rotated
• Disable NTLM where possible and monitor its use aggressively
• Reset the krbtgt password regularly (and yes, twice)
• Monitor for DCSync -- replication requests from non-DC sources should trigger immediate investigation
• Implement credential tiering -- Domain Admin credentials should never touch workstations

Conclusion

Password attacks occupy a peculiar space in offensive security. The techniques range from the breathtakingly simple (trying "Password1!" against every account) to the technically elegant (forging Kerberos tickets with stolen cryptographic material). What unites them is that they all exploit the same fundamental weakness: the gap between how secure systems could be and how humans actually use them.

The password policy says eight characters, upper case, lower case, number, special character. The user types "Autumn2026!" and considers the matter settled. The penetration tester cracks it in four seconds and writes it up as a finding. The organisation adds "must not contain seasons" to the policy. The user switches to "Monday2026!" and the cycle continues.

The forever war rolls on. Human laziness remains undefeated.

All techniques described in this article are intended for use in authorised security assessments only. Unauthorised access to computer systems is a criminal offence. Obtain written permission before testing. "But Tech Corsair said it was fine" is not a legal defence.