Access attacks and countermeasures

Attackers increasingly log in rather than break in. With a valid identity, their activity looks like normal work, bypasses many network defences and inherits whatever access the victim held. This lesson surveys the main attacks on authentication and authorization, explains why each works and sets out the countermeasures a security manager should insist on. The descriptions are conceptual: the aim is to recognize and defend against these techniques, not to perform them. Throughout, notice how often the strongest single countermeasure is the same: phishing-resistant authentication combined with least privilege and good monitoring.

Attacks on passwords

Brute-force attacks try every possible password for one account; dictionary attacks try likely passwords from word lists and leaked password collections. Both are defeated online by throttling and offline by slow, salted password hashing, as lesson 3 showed. Password spraying inverts the approach: the attacker tries a few very common passwords, such as Winter2026!, against many accounts, staying under per-account lockout thresholds. Credential stuffing uses user name and password pairs leaked from breaches of other sites, relying on reuse; automated tools test millions of pairs through rotating proxies. Large breaches of cloud data platforms in 2024 were widely attributed to stolen credentials used against accounts that lacked multifactor authentication.

Spraying and stuffing are detected by looking across accounts rather than at one: many accounts failing from the same source, the same password attempted against many users, or a surge of successful logins from residential proxy networks. Per-account lockout alone misses spraying and can be turned against users as a denial-of-service weapon.

from collections import defaultdict
attempts = [  # (source address, account, result, password fingerprint)
    ('203.0.113.7', 'alee', 'fail', 'h1'), ('203.0.113.7', 'bdas', 'fail', 'h1'), ('203.0.113.7', 'cfox', 'fail', 'h1'),
    ('203.0.113.7', 'dlin', 'fail', 'h1'), ('203.0.113.7', 'egarcia', 'success', 'h1'), ('203.0.113.7', 'fyu', 'fail', 'h1'),
    ('198.51.100.4', 'alee', 'fail', 'h9'), ('198.51.100.4', 'alee', 'success', 'h2'),
]
by_source = defaultdict(set); by_password = defaultdict(set); successes = defaultdict(list)
for src, acct, result, pw in attempts:
    by_source[src].add(acct); by_password[pw].add(acct)
    if result == 'success':
        successes[src].append(acct)
for src, accts in by_source.items():
    if len(accts) >= 5:
        print(f'{src}: {len(accts)} accounts tried from one source -> likely spraying; successes {successes[src]}')
for pw, accts in by_password.items():
    if len(accts) >= 5:
        print(f'Same password fingerprint {pw} tried on {len(accts)} accounts')
print('Action: force reset and session revocation for', successes['203.0.113.7'], 'and require MFA registration')

203.0.113.7: 6 accounts tried from one source -> likely spraying; successes ['egarcia']
Same password fingerprint h1 tried on 6 accounts
Action: force reset and session revocation for ['egarcia'] and require MFA registration

Phishing and adversary-in-the-middle

Classic phishing tricks users into entering credentials on a fake page. Adversary-in-the-middle phishing, also called AiTM or reverse-proxy phishing, goes further: the fake site relays everything between the user and the real site in real time, so the user sees the genuine login flow, completes multifactor authentication, and the attacker captures both the password and the session cookie that results. Phishing kits that automate this are sold as a service. Because the attacker steals the authenticated session, one-time codes and push approvals provide no protection. Phishing-resistant authenticators do, because their responses are bound to the genuine origin, as lesson 4 explained, and the fake site cannot obtain a usable one.

Consent phishing targets OAuth rather than passwords. The attacker registers an application with a plausible name and tricks a user into granting it permissions, such as reading mail and files, through the genuine identity provider's consent screen. The attacker never learns the password, and resetting it does not revoke the grant. Countermeasures are restricting which applications users may consent to, requiring administrator approval for high-risk permissions, verifying publishers and reviewing granted applications regularly.

Attacks on multifactor authentication and recovery

Where phishing-resistant methods are not used, attackers target the second factor. MFA fatigue, or prompt bombing, floods a user with push requests until one is approved, sometimes combined with a phone call pretending to be IT support. SIM swapping persuades or bribes a mobile carrier to move a victim's number to the attacker's SIM, capturing SMS codes and recovery messages. Help desk social engineering impersonates an employee to have passwords or authenticators reset; a series of widely reported intrusions in 2023 against casino and hospitality companies began with calls to help desks. Countermeasures include number matching for push, phishing-resistant methods, carrier account locks for executives, strict help desk verification through independent channels and alerts to the user whenever an authenticator is added or reset.

Session and token theft

After authentication, a session cookie or token stands in for the user. If an attacker steals it, through AiTM phishing, malware on the endpoint that harvests browser cookies, cross-site scripting or insecure storage, they can replay it from their own machine without knowing the password or passing MFA. Session hijacking also covers predicting or fixing session identifiers, which modern frameworks prevent by issuing random identifiers and regenerating them at login. Countermeasures include short session and token lifetimes, re-evaluating sessions continuously against device and location signals, binding tokens to devices with technologies such as token binding or proof-of-possession, protecting cookies with the Secure, HttpOnly and SameSite attributes, revoking refresh tokens on suspicious activity and detecting impossible travel.

import math
def km(lat1, lon1, lat2, lon2):
    r = 6371.0
    p1, p2 = math.radians(lat1), math.radians(lat2)
    dp, dl = p2 - p1, math.radians(lon2 - lon1)
    a = math.sin(dp / 2) ** 2 + math.cos(p1) * math.cos(p2) * math.sin(dl / 2) ** 2
    return 2 * r * math.asin(math.sqrt(a))
signins = [  # (time in hours, city, lat, lon)
    (9.00, 'Calgary', 51.05, -114.07),
    (9.75, 'Calgary', 51.05, -114.07),
    (10.25, 'Amsterdam', 52.37, 4.90),
]
for (t1, c1, a1, o1), (t2, c2, a2, o2) in zip(signins, signins[1:]):
    d = km(a1, o1, a2, o2); hours = t2 - t1
    speed = d / hours if hours else float('inf')
    verdict = 'impossible travel - challenge or revoke session' if speed > 1000 else 'plausible'
    print(f'{c1} -> {c2}: {d:,.0f} km in {hours:.2f} h = {speed:,.0f} km/h: {verdict}')

Calgary -> Calgary: 0 km in 0.75 h = 0 km/h: plausible
Calgary -> Amsterdam: 7,176 km in 0.50 h = 14,351 km/h: impossible travel - challenge or revoke session

Attacks on Windows authentication

In Windows domains, attackers who gain administrative access to one machine try to harvest credential material from memory and reuse it. Pass-the-hash uses a captured NTLM password hash to authenticate as the user without knowing the password, because NTLM's challenge-response accepts the hash itself. Pass-the-ticket reuses captured Kerberos tickets. Overpass-the-hash uses a hash to request Kerberos tickets. Golden and silver tickets, and Kerberoasting, were described in lesson 5. These techniques let an attacker move laterally until they reach an account with domain-wide privileges. Countermeasures are the tiered administration model, so that privileged credentials are never exposed on lower-tier machines; unique local administrator passwords managed by tools such as Windows LAPS; credential protection features such as Credential Guard; restricting or disabling NTLM; adding privileged users to protected groups that cannot use weak protocols or cached credentials; and monitoring for anomalous authentication patterns.

Authorization attacks and insider misuse

Some attacks target authorization rather than authentication. Privilege escalation exploits misconfiguration or vulnerabilities to gain more rights than granted: vertical escalation reaches higher privilege, such as a user becoming an administrator; horizontal escalation reaches another user's data at the same level, such as the insecure direct object reference in lesson 7. Cloud misconfigurations allow escalation when an identity can, for example, attach a more powerful policy to itself or pass a privileged role to a resource it controls. Insiders, by contrast, need no escalation: they misuse access they legitimately hold, which is why least privilege, separation of duties, monitoring of sensitive data access and prompt removal of access matter so much.

Physical access attacks belong in this domain too. Tailgating and piggybacking follow an authorized person through a controlled door; cloned proximity badges, many of which use older unencrypted technology, can be copied at a distance; and lost badges that are not revoked remain valid. Countermeasures include mantraps or turnstiles at sensitive areas, guards and staff trained to challenge, modern encrypted badge technology, badge plus PIN for high-security doors and immediate revocation of lost badges.

Thinking like a manager

When an exam question describes an access attack, identify which step it defeats. Guessing attacks defeat weak authentication; phishing and AiTM defeat non-phishing-resistant MFA; recovery attacks defeat help desk processes; token theft defeats session controls; credential reuse defeats tiering; insider misuse defeats least privilege. The most comprehensive answers move toward phishing-resistant authentication, least privilege with just-in-time administration, short-lived and bound sessions, strict recovery and detection that looks across accounts and sessions.