Skip to main content
Style:
Size:

Chapter 5: Practical Controls for Human Risks (Phishing, Insider Threats)

You can build the most beautiful Zero Trust architecture in the world, with perfect automated HR provisioning and flawless Role-Based Access Control. But if Alice from Finance clicks on a frantic email that says, "URGENT: Update your HR portal password," and she types her credentials into a fake website... your architecture is in serious trouble.

When dealing with human workloads, Identity and Access Management is fundamentally about mitigating the inherent flaws of the human brain. We are distracted, we are trusting, we want to be helpful, and sometimes, we are disgruntled.

Let's look at the two biggest human risks—Phishing and Insider Threats—and how we use our 5 Pillars to build practical, un-bypassable controls against them.

Risk 1: Phishing (The External Threat)​

Phishing remains the number one way attackers breach corporate networks. As the old cybersecurity adage goes: Attackers don't hack in; they log in.

The Problem with Legacy MFA & The AiTM Threat​

In the past, organizations believed SMS OTPs or mobile authenticator push notifications solved identity threats. They do not. Modern threat actors leverage three distinct bypass techniques:

  1. Adversary-in-the-Middle (AiTM) Phishing: Attackers deploy reverse proxies (e.g., Evilginx) sitting between the victim and the legitimate IdP. When the user completes authentication, the proxy captures the issued HTTP session cookie / token.
  2. MFA Fatigue (Push Bombing): Attackers spam a target's mobile device with dozens of consecutive MFA push notifications at 3:00 AM until the exhausted user approves one to silence the phone. (Mitigated by MFA Number Matching / Contextual Push).
  3. OAuth Consent Phishing (Illicit Consent Grants): Attackers do not steal credentials; they trick users into authorizing a malicious OAuth enterprise application (e.g., "Productivity Doc Reader"). Once authorized, the app receives offline OAuth tokens granting persistent access to emails, files, and cloud data without ever triggering MFA again.

The Rise of Infostealers & Session Cookie Theft (Pass-the-Cookie)​

A critical modern attack vector that bypasses even the strongest authentication is Infostealer Malware (e.g., Lumma, RedLine, Racoon). If an employee downloads malicious software, the infostealer extracts authenticated session cookies and local tokens directly from browser SQLite databases (Cookies, Web Data).

Because the session is already authenticated, the attacker imports the stolen cookie into their own browser and accesses corporate SaaS applications instantly—completely bypassing passwords, FIDO2 hardware keys, and MFA prompts.

Visual Logic: AiTM Phishing vs. FIDO2 Defense​

The Solution (Control): FIDO2, Passkeys & Token Binding​

To neutralize AiTM phishing and session hijacking, modern architectures deploy multi-layered controls:

  • FIDO2 / WebAuthn Hardware Keys: Cryptographic hardware (e.g., YubiKeys). The browser and authenticator bind the authentication response cryptographically to the exact TLS origin (Origin: https://login.microsoftonline.com). If an AiTM proxy is hosted on login.micros0ft-secure.com, the hardware challenge mathematically fails.
  • Passkeys (Synced vs. Device-Bound): Modern WebAuthn implementations distinguish between:
    • Synced Passkeys: Private keys synced via cloud keychains (Apple iCloud Keychain, Google Password Manager). Ideal for consumer and standard enterprise convenience.
    • Device-Bound Passkeys: Private keys locked inside dedicated hardware (TPM / hardware security keys) that cannot be exported. Mandatory for high-privilege administrators.
  • Continuous Access Evaluation & Token Binding (DPoP): To defeat Infostealer session cookie theft, the IdP dynamically binds session tokens to the physical device's cryptographic TPM using DPoP (RFC 9449), rendering exfiltrated session cookies non-functional on external machines.

Interactive Simulator: Phishing Defense Mapper​

See how different IAM controls interrupt an Adversary-in-the-Middle (AiTM) attack chain step-by-step:

Phishing Defense Mapper

See how different IAM controls interrupt an Adversary-in-the-Middle (AiTM) attack chain.

Attack Chain Timeline
Click 'Simulate AiTM Attack' to view defense behavior.

Risk 2: The Insider Threat (The Internal Enemy)​

Phishing assumes the human is an unwitting victim. The Insider Threat assumes the human is the attacker.

Imagine Bob is a database administrator who is furious because he was passed over for a promotion. He decides to download the entire customer database onto a USB drive and sell it to a competitor before he quits on Friday afternoon.

  • The Problem: Bob isn't hacking the network. He has legitimate access. He is using his own credentials, from his own approved laptop, during normal business hours. Your Zero Trust network proxy sees absolutely nothing wrong.
  • The Solution (Process & Control): Separation of Duties (SoD) and Just-in-Time (JIT) Access.

Separation of Duties (SoD)​

Never let one single human hold all the keys to a critical process.

  • The Concept: Bob might have the ability to write a script that exports the database, but he should never have the ability to execute that script on the production server without a second person (like his manager) digitally approving it.
  • The Check: If the IAM system sees Bob trying to hold both the "Creator" and "Approver" roles simultaneously, it flags it as a "Toxic Combination" and denies the access.

Just-in-Time (JIT) Access​

Even administrators should have zero standing privileges by default.

  • The Concept: Bob normally has the exact same access level as a standard employee. When he actually needs to perform database maintenance, he logs into a Privileged Access Management (PAM) portal and requests "DB Admin" rights.
  • The Control: The access is granted for exactly 2 hours (a time-bound token), and every single keystroke he makes during that window is recorded for audit. When the time is up, his privileges instantly drop back down to zero.

The 5 Pillars of Human Risk Mitigation​

Let’s map this back to our core framework to close out the Human Workload section:

  1. People: Training is necessary, but we must assume people will eventually fail. The CEO is just as likely to click a sophisticated phishing link as a first-year intern.
  2. Process: Implement strict Separation of Duties to ensure no single human can cause a catastrophic network event alone.
  3. Technology: Utilize FIDO2 standards (hardware keys/biometrics) for all authentication, and Privileged Access Management (PAM) systems for recording administrative sessions.
  4. Control: Time-bound access (JIT) and Phishing-Resistant MFA are mandatory for critical roles.
  5. Impact: By restricting standing privileges (JIT) and requiring a second pair of eyes (SoD), the blast radius of a rogue or compromised human is severely limited.

Consultant's Corner: The "VIP Exception"​

The quickest way to completely ruin your IAM program is to grant security exceptions to executives.

If the CEO or a board member says, "I hate using the YubiKey, just give me a password and SMS text," you must hold the line. This is where you leverage the Impact pillar.

Explain it to them in business terms: The CEO has access to the company's financial data, upcoming merger plans, and confidential HR records. If their account is compromised via a simple AiTM phishing attack, the blast radius isn't just an IT headache—it is a company-ending event that will make national news.

Security controls must always be applied based on the risk of the identity, not the rank of the human. No exceptions.

💡 Scenario & Solution: Bypassing Hardware FIDO2 via Infostealer Session Theft and the CAE/Token-Binding Countermeasure​

The Scenario: An executive uses a hardware YubiKey with FIDO2 enforcement for all corporate SaaS logins. While traveling, the executive downloads an infected PDF viewer from a malicious link. Within seconds, an infostealer malware binary executes in user-space, copies the active Google Workspace and AWS SSO session cookies from Google Chrome's local storage, and transmits them to a command-and-control server in Eastern Europe. The attacker imports the cookie string into their browser and accesses executive emails without triggering a password prompt or FIDO2 challenge.

Why It Happened: FIDO2 secures the authentication ceremony (exchanging credentials for a session), but does not intrinsically protect the resulting session bearer token from being exfiltrated from the client endpoint.

The Architecture Solution:

  1. DPoP (Demonstrating Proof-of-Possession / RFC 9449) & Device-Bound Tokens: Enforce browser and app token binding to the device's hardware TPM enclave. When the attacker attempts to replay the stolen cookie on another computer, the request is rejected because the client cannot sign the DPoP HTTP request with the hardware private key.
  2. Continuous Access Evaluation (CAE) with IP/Risk Signals: Configure the IdP to terminate sessions immediately if an active session token is presented from an untrusted ASN/IP that deviates from the endpoint's established EDR tunnel.
  3. Endpoint EDR + App Isolation: Deploy Enterprise Browser extensions with sandboxed credential storage and automated infostealer detection.