Listen to this Post
Introduction:
Authentication is the first line of defense in any organization, yet it remains the most frequently exploited attack vector. From Pass-the-Hash to MFA fatigue, understanding these 10 authentication attacks—their exploitation mechanics, business risks, and the countermeasures that actually block them—is critical for cybersecurity professionals preparing for CISSP or securing enterprise environments.
Learning Objectives:
- Identify and differentiate between 10 common authentication attacks including credential stuffing, Pass-the-Ticket, and rainbow table attacks.
- Implement platform-specific mitigation commands (Windows/Linux) and security controls to block each attack.
- Apply risk-based countermeasures such as least privilege, password rotation, SMB signing, and conditional access policies.
You Should Know
- Pass‑the‑Hash (PtH) – The Windows Credential Theft That Bypasses Passwords
Attackers don’t need your plaintext password—just the NTLM hash. PtH extracts the hash from memory (using tools like Mimikatz) and reuses it to authenticate to other systems, moving laterally across the domain. This attack exploits Windows’ legacy NTLM authentication, where the hash itself is sufficient for access. The risk: complete compromise of Confidentiality and Integrity of credentials, leading to privilege escalation.
Step‑by‑step – How attackers execute PtH & how to block it:
- Extract NTLM hash (attacker perspective – for defensive learning only):
`mimikatz.exe “privilege::debug” “sekurlsa::logonpasswords” exit`
- Use the hash to authenticate to a remote system:
`mimikatz.exe “sekurlsa::pth /user:Administrator /domain:target.local /ntlm:” exit`
3. Mitigation – Disable NTLM where possible (Windows):
- Group Policy: `Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → Network security: Restrict NTLM: Incoming NTLM traffic` → Set to `Deny all accounts`
- PowerShell: `Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Control\Lsa” -Name “RestrictNTLMIncoming” -Value 2`
- Enable SMB signing to prevent relay and PtH lateral movement:
`Set-SmbServerConfiguration -RequireSecuritySignature $true -EnableSMB2Protocol $true`
- Apply Least Privilege – Run admin accounts only on dedicated workstations (PAW) and rotate local admin passwords via LAPS.
-
Pass‑the‑Ticket (PtT) – Kerberos Golden & Silver Tickets in Active Directory
Instead of hashes, PtT steals a valid Kerberos Ticket Granting Ticket (TGT) or service ticket from memory (LSASS). Attackers can then forge Golden Tickets (if KRBTGT hash is stolen) to impersonate any user, including domain admins. The risk is Total Compromise of Active Directory forest.
Step‑by‑step – Detection and defense:
1. Extract Kerberos tickets (defensive simulation):
`mimikatz.exe “privilege::debug” “sekurlsa::tickets /export” exit`
2. Inject a stolen TGT into current session:
`mimikatz.exe “kerberos::ptt [0;3e4][email protected]” exit`
- List cached tickets (Linux): `klist` (Windows): `klist sessions`
4. Mitigation – Golden Ticket defense:
- Change KRBTGT password twice (Microsoft recommends script):
`$NewPwd = ConvertTo-SecureString -String ‘NewComplexPwd’ -AsPlainText -Force`
`Set-ADAccountPassword -Identity krbtgt -NewPassword $NewPwd -Reset`
Then restart all domain controllers and reset again (double-hop reset invalidates existing tickets).
– Enable Protected Users group membership – disables NTLM, Kerberos delegation, and restricts TGT lifetime to 4 hours.
- Monitor Event IDs – 4769 (Kerberos service ticket request anomalies), 4768 (TGT request with unusual encryption types).
-
Credential Stuffing & Password Spraying – The Scalable Login Attacks
Credential stuffing uses breached username/password pairs from data leaks (e.g., HaveIBeenPwned) against multiple services. Password spraying tries one common password (e.g., Spring2025!) across many accounts to avoid lockout policies. Both rely on password reuse and weak password policies.
Step‑by‑step – Testing and hardening:
1. Simulate password spraying (authorized testing):
Linux (Hydra): `hydra -L usernames.txt -p “Winter2025!” target.com http-post-form “/login:user=^USER^&pass=^PASS^:F=Invalid” -t 1 -w 10`
(The `-t 1` prevents lockouts by using a single thread.)
- Check for breached passwords – Azure AD Password Protection:
`Install-Module -Name MSOnline`
`Connect-MsolService`
`Set-MsolPasswordPolicy -DomainName target.com -LockoutThreshold 3 -LockoutObservationWindowInMinutes 30`
3. Enforce banned password lists (custom):
Azure: `New-AzureADPasswordProtectionCustomBanList -Name “SeasonalWords” -CustomBanWords @(“Summer2024″,”Winter2025”)`
4. Implement rate limiting on login endpoints (IIS/NGINX):
NGINX:
limit_req_zone $binary_remote_addr zone=login:10m rate=3r/m;
server { location /login { limit_req zone=login burst=1 nodelay; } }
- Risk mitigation – MFA, conditional access (block impossible travel), and user education to avoid password reuse.
-
Rainbow Table & Dictionary Attack – Cracking Hashes Efficiently
Rainbow tables are precomputed hash chains that reverse a hash to its plaintext in seconds. Dictionary attacks use wordlists (rockyou.txt) to guess common passwords. Salting (random per-password data) renders rainbow tables useless.
Step‑by‑step – Offensive simulation & defensive hashing:
1. Generate a rainbow table (for educational defense):
`rtgen md5 loweralpha 1 7 0 1000 4000 0` (uses rainbowcrack suite)
- Crack a hash with dictionary (John the Ripper):
`john –wordlist=/usr/share/wordlists/rockyou.txt –format=nt hash.txt`
- Defense – Use salted hashes (Linux shadow file already uses salt):
Generate SHA-512 salted hash: `openssl passwd -6 -salt xyz789 MyPassword` - Modern standard – Argon2 for password storage (Linux):
`argon2 id -t 4 -m 20 -p 4 -l 32 -r` (time=4, memory=2^20 KB, parallel=4) -
Enforce strong password policies – minimum 12 characters, exclude dictionary words. Windows:
`secedit /export /cfg secpolicy.inf`
Edit `PasswordComplexity=1`, `MinimumPasswordLength=12`
`secedit /configure /db secedit.sdb /cfg secpolicy.inf /overwrite`
- MFA Fatigue (MFA Bombing) & Session Hijacking – Bypassing Multi-Factor
MFA fatigue floods a user’s authenticator app or push notification (e.g., Microsoft Authenticator) with prompts until the user accidentally approves. Session hijacking steals a valid session cookie via XSS, MITM, or malware, completely bypassing both password and MFA.
Step‑by‑step – Attack and countermeasures:
1. Session hijacking (demonstration with stolen cookie):
Browser dev tools → Application → Cookies → Copy session cookie.
On attacker machine, inject cookie using EditThisCookie extension or curl:
`curl -b “sessionid=stolen_value” https://target.com/dashboard`
- Mitigation – Bind cookies to fingerprint + short TTL:
Python (Flask):
from flask import Flask, request, make_response
@app.after_request
def set_cookie_attributes(response):
response.set_cookie('session', httponly=True, secure=True, samesite='Strict', max_age=900)
return response
- Block MFA fatigue – Require number matching (Microsoft Entra ID):
PowerShell: `Set-MgPolicyAuthenticationMethodPolicy -AuthenticationMethodConfiguration @(‘{“@odata.type”:”microsoft.graph.microsoftAuthenticatorAuthenticationMethodConfiguration”,”displayName”:”Microsoft Authenticator”,”state”:”enabled”,”featureSettings”:{“displayAppInformationRequiredState”:{“state”:”enabled”},”displayLocationRequiredState”:{“state”:”enabled”},”numberMatchingRequiredState”:{“state”:”enabled”}}}’)`
Alternatively, enforce OATH TOTP with a fixed 30-second window and reject duplicate codes.
- Additional control – Conditional Access policy: “Require compliant device” ensures session token is tied to device certificate.
-
User training – Never approve an unexpected MFA prompt; report it immediately as an attack.
-
Phishing & Brute Force – The Classic Duo Still Breaching Organizations
Phishing remains the 1 initial access vector, luring users to fake login pages. Brute force systematically tries all combinations (e.g., a-z, 0-9) but is slower than dictionary attacks. Their risk is credential disclosure and unauthorized access.
Step‑by‑step – Hardening and monitoring:
1. Detect brute force (Linux – Fail2ban):
Install: `sudo apt install fail2ban`
Configure `/etc/fail2ban/jail.local`:
[bash] enabled = true maxretry = 5 bantime = 3600 findtime = 600
`sudo systemctl restart fail2ban`
- Windows brute force detection – Account lockout audit:
`auditpol /set /subcategory:”Logon/Logoff” /success:enable /failure:enable`
View lockouts: `Get-EventLog -LogName Security -InstanceId 4740`
- Anti‑phishing – Deploy DMARC, DKIM, SPF (email authentication):
Check current records: `nslookup -type=txt _dmarc.target.com`
Set DMARC quarantine: `v=DMARC1; p=quarantine; rua=mailto:[email protected]`
- Enable SmartScreen (Microsoft Defender) or Google Safe Browsing API.
-
User awareness – Simulated phishing campaigns (e.g., Gophish open source):
`docker run -d -p 3333:3333 -p 80:80 -p 443:443 –name gophish gophish/gophish` -
Cloud & API Authentication Hardening – Modern Extensions
While not listed explicitly, authentication attacks now heavily target OAuth tokens, API keys, and cloud identity providers. Credential stuffing against Azure AD, session hijacking of JWT tokens, and MFA fatigue via push notifications are rampant.
Step‑by‑step – Securing cloud authentication:
1. Revoke compromised tokens (Azure CLI):
`az ad user revoke-sign-in-sessions –id [email protected]`
- Enforce Conditional Access – Sign-in frequency (every 4 hours) and device compliance:
`New-AzureADMSConditionalAccessPolicy -DisplayName “Require compliant devices” -Conditions … -GrantControls BuiltInControls=”CompliantDevice”`
3. API key rotation (AWS example):
`aws iam update-access-key –access-key-id AKIA… –status Inactive`
`aws iam create-access-key –user-name api-user` → replace in application, then delete old key.
- JWT hardening – Use short expiry (15 min) and store refresh tokens server-side with rotation:
Node.js: `jwt.sign(payload, secret, { expiresIn: ‘900s’, algorithm: ‘RS256’ })` - Detect anomalous logins – Azure Sentinel / Microsoft 365 Defender:
`SigninLogs | where RiskLevelDuringSignin == “medium” or “high”`
What Undercode Says:
- Authentication is not binary – MFA alone fails against session hijacking and MFA fatigue; layering device posture, anomaly detection, and user education is mandatory.
- Windows legacy protocols (NTLM, Kerberos without armor) remain the weakest links – Disable NTLM, implement Protected Users, and monitor for golden ticket attacks religiously.
- Risk-based approach > technical depth for CISSP – Knowing what the attack exploits, which security property (CIA) it targets, and which control stops it is more valuable than memorizing NTLM internals. Pass-the-Hash breaks Confidentiality; least privilege and password rotation restore it.
Prediction:
By 2028, phishing-resistant MFA (WebAuthn/FIDO2 passkeys) will replace push-based MFA, slashing MFA fatigue attacks by 90%. Simultaneously, AI-driven password spraying will adapt to lockout policies in real-time, forcing organizations to adopt passwordless authentication (Windows Hello for Business, Azure AD certificate-based auth). Pass-the-Hash will persist until all legacy Windows systems are retired—predicted to take until 2030 in hybrid environments. The CISSP exam will increasingly test risk-based scenarios with these modern attacks, pivoting from pure knowledge to incident response decision-making under time pressure.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Biren Bastien – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
