Spraying and brute force are not the same attack — they use inverse strategies.
Traditional brute force targets one account with many passwords — systematically iterating through the full keyspace until a match is found. This is what account lockout policies are designed to stop.
Password spraying targets many accounts with one (or a few) passwords. The lockout threshold never triggers on any single account because each account receives only one or two attempts. Spraying is specifically engineered to avoid the defense that stops brute force.
The exam often presents both as variations of the same concept. They are not. The distinction determines which defense applies:
- Brute force (online) → account lockout policy stops it
- Spraying → account lockout does NOT stop it; MFA does
Offline brute force does not interact with the victim's authentication endpoint at any point during the cracking phase.
Once an attacker has the hash file, the entire cracking operation happens on the attacker's hardware. The victim's authentication system receives zero login attempts during this phase. No authentication logs are generated. No lockouts occur. The first time the authentication system is contacted is after cracking completes — when the attacker uses the recovered credentials to log in.
This has two important implications the exam tests:
- Account lockout policies provide zero protection against offline brute force — there are no login attempts to lock out.
- The critical defensive window for offline brute force is preventing hash file acquisition AND making the hash computationally expensive — not controlling the login endpoint.
A stored password hash cannot be decrypted — ever. It can only be brute-forced forward.
Encryption is a two-way operation: encrypt with a key, decrypt with a key. Given the key, the original data is recoverable. Hash functions are one-way: the transformation is mathematically designed to be irreversible. Given only the hash output, there is no algorithm that can recover the input — this is the pre-image resistance property.
What attackers do instead: they compute the hash of candidate passwords and compare the results to stored hashes. This is not decryption — it is forward computation and comparison. The distinction matters because:
- "Decrypting" implies the attacker needs the key — there is no key for hashing
- "Cracking" the hash means finding an input that produces the same output — by trying candidates
- An exam answer that says "the attacker decrypts the password hash" is always wrong
MFA doesn't make offline brute force fail — it makes a successful crack useless.
MFA does not stop an attacker from cracking a hash. If an attacker steals the hash file and runs bcrypt cracking against it, and finds that alice's password is "Sunflower2019," the cracking succeeded. MFA had no effect on that process.
What MFA prevents is the authentication step after cracking. When the attacker tries to log in as alice with "Sunflower2019," the system also requires a TOTP code or push notification. The attacker doesn't have alice's phone. Authentication fails despite knowing the correct password.
This is why MFA is described as the universal backstop — it doesn't harden the cracking process; it removes the value of cracking entirely. The recovered password becomes useless for authentication.
Performance Task
You are conducting a security assessment for a regional bank. Your review produces three findings related to password management. For each finding, identify the specific vulnerability or attack it represents, explain the risk, and provide the precise remediation.
The bank's internal HR portal stores employee credentials in an older database table. Upon examination, the password column contains values such as: jsmith | Summer2022! and mjones | Welcome123. The development team explains that "the passwords are protected by the database login — you need credentials to read the table."
Questions: What vulnerability is present? What is wrong with the development team's reasoning? What is the remediation?
Vulnerability: Plaintext password storage ("in the clear"). Passwords are stored exactly as typed — unencrypted, immediately readable to anyone with database read access.
Why the reasoning is wrong: Database access controls protect the database login — not the content once accessed. Any SQL injection vulnerability, compromised DBA account, insider threat, or backup file exposure immediately yields all credentials in fully usable form. The protection is a single point of failure. Additionally, credential reuse means the exposed passwords likely grant access to many other systems beyond this portal. There is no computational barrier between the attacker and the passwords.
Remediation: (1) The application must be updated to hash passwords before storage using a strong algorithm (bcrypt or Argon2). This requires a redesign of the authentication logic — not a configuration change. (2) Force an immediate password reset for all HR portal accounts. (3) Assume all stored credentials are compromised — notify affected employees to change passwords on any service where they reused the same password. (4) Conduct a broader audit for other systems using the same application framework.
The bank's Active Directory environment shows a configuration of 10-attempt account lockout. Reviewing authentication logs from the prior month, an analyst finds that on a Tuesday at 2:15 AM, every single Active Directory account (1,200 accounts) received exactly two failed login attempts within a 45-minute window. The same two passwords were tried: "Summer2024" and "Bank2024!". No accounts were locked out. The bank's SIEM generated no alert.
Questions: What attack occurred? Why did the lockout policy not prevent it? Why did the SIEM not alert? What controls would have detected or prevented this?
Attack: Password spraying. The attacker tried two passwords ("Summer2024" — a seasonal common pattern; "Bank2024!" — an organization-specific common password) across all 1,200 accounts. Each account received exactly 2 of its 10 allowed attempts — well below the lockout threshold.
Why lockout failed: Account lockout triggers on N consecutive failures on one account. Spraying distributes failures across all accounts. No account approached the 10-attempt threshold, so no lockout fired. The lockout policy was correctly configured but is not designed to stop this attack pattern.
Why SIEM didn't alert: The SIEM likely had rules based on per-account failure counts — standard brute force detection. Spraying's horizontal pattern (many accounts, few attempts each) didn't match any existing alert rule. The attack was invisible to per-account monitoring.
Controls that would have helped: (1) MFA on all Active Directory accounts — the attacker's most likely goal was VPN, Outlook Web Access, or remote desktop access; MFA renders any successful password spray useless. (2) Common-password blocklist — prevent users from setting "Summer2024" or "Bank2024!" at password creation time (pattern-based: seasonal words + year, company name + year are known spray targets). (3) SIEM rule: alert when the same password produces authentication failures across more than 50 distinct accounts within a 60-minute window — this is the spray signature.
The bank's web banking application stores customer passwords as SHA-256 hashes without salting. A penetration tester demonstrates that after obtaining the password table (simulating a SQL injection breach), they can crack 40% of the passwords within 4 hours using a GPU-equipped workstation and a combined wordlist/rainbow table attack. The security team proposes adding account lockout to the web banking login as the remediation.
Questions: What attack is being demonstrated? Why is the proposed remediation incorrect? What are the two correct remediations for this specific vulnerability?
Attack: Offline brute force combined with rainbow table lookup. SHA-256 without salting is fast to compute (~10 billion hashes/sec on a GPU) and allows precomputed rainbow tables — if two users share the same password, they share the same hash, which can be looked up in a table rather than cracked. The 40% success rate in 4 hours demonstrates this is viable at production scale.
Why the proposed remediation is wrong: Account lockout applies to the live authentication endpoint. Offline brute force never contacts the authentication system during the cracking phase — the attacker is working entirely on a local copy of the hash file. Adding lockout to the login page has zero effect on an attack that doesn't use the login page. The security team is solving for online brute force when offline brute force is the demonstrated threat.
Correct remediations:
(1) Replace SHA-256 with bcrypt or Argon2 for password hashing. bcrypt at cost factor 12 reduces GPU cracking speed from ~10 billion/sec (SHA-256) to ~20,000/sec — a 500,000× slowdown. Passwords that crack in 4 hours with SHA-256 now take decades with bcrypt. This addresses the offline speed advantage directly.
(2) Add per-user salting. Unique random salts for each password hash defeat rainbow table lookups (the table would need to be rebuilt for every possible salt) and prevent batch cracking of shared passwords (each account's hash must be attacked individually). These two controls together — slow algorithm + salting — are the complete remediation for offline brute force risk. Account lockout remains a valid control for online brute force, but it does not address the demonstrated vulnerability.