Blog

Identity Is the New Perimeter

Network perimeters died when workforces went remote and cloud services became the norm. Firewalls and VPNs still matter, but the access decisions that actually matter happen at the identity layer. When an attacker steals credentials or hijacks a session, every firewall rule in the world won’t stop them from doing exactly what the legitimate user does.

Microsoft’s 2025 Identity Security Report found that identity-based attacks account for over 80% of security incidents in enterprise environments. The attack surface isn’t your DMZ anymore — it’s your Active Directory, your OAuth flows, your session tokens, and your MFA implementation.

Credential Stuffing and Password Spray Attacks

How They Work

Credential stuffing takes leaked username/password pairs from data breaches and tries them against other services. Attackers assume (correctly) that people reuse passwords. Tools like Sentry MBA and BlackBullet automate this at scale with rotating proxies and browser fingerprint spoofing.

Password spraying takes the opposite approach — instead of many passwords against one account, it tries a few common passwords (Password1!, Summer2024!, Welcome123) against many accounts. This avoids account lockouts that would trigger with brute force.

Real-World Impact

The 2024 Ticketmaster breach exposed 560 million customer records. Attackers got in through a credential stuffing attack on a cloud environment, then moved laterally to the database. Snowflake customers were hit through stolen employee credentials that had no MFA.

Detection commands for your web server access logs:

# Find potential credential stuffing (many failed logins from same IP)
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# Find password spray (login attempts with same password hash pattern)
grep "login_failed" /var/log/auth.log | awk '{print $NF}' | sort | uniq -c | sort -rn

Session Hijacking Techniques

Session Fixation

The attacker sets the victim’s session ID before they authenticate. If the application doesn’t regenerate the session ID after login, the attacker keeps their pre-set ID — which is now an authenticated session. This is why every authentication flow must call session_regenerate_id(true) in PHP or the equivalent in your framework.

Token Theft via XSS

Even with HttpOnly cookies protecting session tokens, many applications store JWTs or API tokens in localStorage where any XSS vulnerability can read them. A single reflected XSS in a comment field or search parameter gives an attacker the token they need to impersonate the user.

Session Replay

If session tokens are transmitted without proper binding, an attacker who captures a token (via network sniffing or log access) can replay it. This is why session tokens need to be bound to the TLS channel, the client fingerprint, or both.

OAuth and OIDC Token Attacks

Token Leakage via Referrer Headers

OAuth tokens passed as URL query parameters get leaked in the Referer header when the user navigates to an external link. If your OAuth callback puts the token in the URL, any third-party resource on your page can capture it. Always use the POST body or Authorization header for token delivery.

CSRF on OAuth Flows

Without proper state parameter validation, an attacker can initiate an OAuth flow on behalf of a victim and bind the victim’s account to the attacker’s OAuth identity. The state parameter must be a cryptographically random value stored in the session and validated on callback.

Token Substitution

If your API accepts access tokens without validating the audience (aud) claim, an attacker can use a token issued for a different application to access yours. Always validate aud, iss, and exp claims on every token.

MFA Bypass Methods

SIM Swapping

An attacker convinces a mobile carrier to port the victim’s phone number to a SIM they control. This gives them access to SMS-based OTP codes. T-Mobile, Verizon, and AT&T all report thousands of SIM swap complaints monthly.

MFA Fatigue Attacks

The attacker spams the victim with MFA push notifications — dozens per minute, at all hours. Eventually the victim hits “Approve” just to make it stop. This is how the Uber breach of 2022 happened. The attacker bought compromised contractor credentials on the dark web, then bombarded the contractor with MFA prompts until they approved.

Adversary-in-the-Middle with Evilginx

Evilginx is a reverse proxy that sits between the victim and the real login page. It captures the session cookie after the victim completes the full MFA flow — the victim sees nothing wrong. This defeats SMS OTPs, authenticator app codes, and even some push notifications. The only thing that reliably stops it is phishing-resistant authentication.

Passkeys and Phishing-Resistant Auth

WebAuthn/FIDO2 passkeys solve the phishing problem fundamentally. Instead of a shared secret (password), the device holds a private key that never leaves it. Authentication requires a cryptographic signature from that key, and the browser binds the signature to the actual domain — not a lookalike. Evilginx can’t intercept this because the private key never traverses the network.

Passkeys are now supported in Chrome, Safari, Firefox, iOS, Android, Windows, and macOS. Major providers like Google, Apple, Microsoft, and GitHub support passkey login. Adoption is accelerating because it’s both more secure and more convenient than passwords.

Practical Hardening Checklist for Developers

• Session Management: Regenerate session IDs after login. Set SameSite=Strict or Lax. Use short session lifetimes for sensitive operations. Store tokens in HttpOnly, Secure, SameSite cookies — never localStorage.
• Token binding: Bind session tokens to the TLS session or client fingerprint. Invalidate tokens on password change and MFA events.
• CORS configuration: Never use Access-Control-Allow-Origin: * with credentials. Explicitly list allowed origins.
• OAuth hardening: Use PKCE (Proof Key for Code Exchange) for all OAuth flows, including server-side. Validate state, aud, and iss. Deliver tokens via POST body, not URL parameters.
• MFA implementation: Support FIDO2/passkeys as the primary MFA method. Rate-limit MFA attempts. Implement number matching for push notifications to prevent fatigue attacks.
• Account recovery: Don’t use security questions (they’re trivially guessable). Require MFA re-authentication for email/password changes. Implement account lockout with exponential backoff.

Pass-the-Hash and Pass-the-Ticket Attacks

In Active Directory environments, authentication isn’t just about passwords — it’s about the artifacts those passwords generate. Two of the most devastating attacks in enterprise networks exploit this directly: Pass-the-Hash (PtH) and Pass-the-Ticket (PtT).

Pass-the-Hash: NTLM Without the Password

When a user authenticates via NTLM, the client never sends the plaintext password over the wire. Instead, it sends an NTLM hash — a MD4 digest of the UTF-16LE encoded password. Here’s the problem: AD domain controllers never verify the password itself during NTLM auth. They verify the hash. If an attacker extracts an NTLM hash from memory (via Mimikatz, LSASS dumps, or NTDS.dit extraction), they can present that hash directly to authenticate as the user — no cracking required.

# Extracting NTLM hashes with mimikatz (attacker perspective)
privilege::debug
sekurlsa::logonpasswords

# Using the hash directly with Impacket
impacket-psexec -hashes :8846f7eaee8fb117ad06bdd830b7586c DOMAIN/admin@10.0.0.5

This attack is devastating because it bypasses password complexity entirely. A 30-character passphrase hashes the same way — if you have the hash, the password is irrelevant. Lateral movement becomes trivial: compromise one server, dump LSASS, pivot to every system where that account has local admin.

Kerberos Ticket Attacks: Golden and Silver

Kerberos, AD’s preferred authentication protocol, uses tickets — specifically Ticket-Granting Tickets (TGTs) and Service Tickets. Attackers learned to forge these.

A Golden Ticket attack requires the KRBTGT account’s NTLM hash (extracted from a domain controller). With it, an attacker can forge TGTs for any user, including enterprise admins, effectively becoming a persistent, undetectable domain administrator.

A Silver Ticket is more targeted — it forges Service Tickets for a specific service on a specific machine using that machine’s account NTLM hash. Less powerful than a Golden Ticket but harder to detect, since it doesn’t touch the domain controller.

Detection and Mitigation

Detect PtH by monitoring for logon type 9 (New Credentials) with no corresponding LSASS password read, unusual NTLM usage when Kerberos should be available, and credential relay patterns. For Kerberos attacks, monitor KRBTGT mutations (alert on any changes), track ticket anomalies (TGT requests outside business hours, encrypted with RC4 instead of AES256). Mitigation: rotate KRBTGT passwords twice (critical — must be done in two passes with 12+ hour intervals), enforce SMB signing, use Credential Guard and LSA Protection on Windows 10+, and transition aggressively to managed identities where possible.

Cloud Identity Attacks

Cloud environments flipped the identity model. Instead of on-premises AD controlling access, identity providers like AWS IAM, Azure AD (now Entra ID), and GCP IAM became the new control plane — and a new attack surface.

AWS IAM Privilege Escalation

AWS IAM is notoriously complex, and misconfigurations are the norm rather than the exception. Attackers chain seemingly innocuous permissions to escalate privileges:

• iam:PassRole + lambda:CreateFunction: Create a Lambda with an admin role, invoke it — instant privilege escalation.
• iam:CreateAccessKey on another user’s credentials: steal persistent access.
• iam:AttachUserPolicy: directly grant yourself admin rights.
• sts:AssumeRole chaining: hop between roles, each granting slightly more access until you reach a high-privilege target.

Azure AD and Hybrid Identity Attacks

Azure AD’s hybrid identity model — synchronizing on-premises AD with cloud identity via Azure AD Connect — creates a bridge attackers love to cross. Password Hash Sync (PHS) attacks are particularly dangerous: if an attacker obtains on-premises password hashes, they automatically have valid cloud credentials when PHS is enabled. Service Principal abuse is another growing vector. Azure AD applications register Service Principals with certificates or client secrets for programmatic access. Attackers enumerate these (often over-privileged, never rotated) and use them for persistent cloud access that doesn’t require interactive login.

Cross-Cloud Identity Federation

Organizations increasingly use identity federation across clouds — SAML assertions, OIDC tokens, and AWS IAM Identity Center bridging to Azure AD. Each federation endpoint is a trust relationship that attackers can exploit. A compromised SAML signing key in one cloud can grant access to another. Cross-account role assumption in AWS, when misconfigured with wildcard principals ("Principal": {"AWS": "*"}), becomes an open door.

Passwordless Authentication: How It Actually Works

Passkeys and FIDO2/WebAuthn represent a fundamental shift in authentication — from shared secrets to asymmetric cryptography. Understanding the mechanics reveals why they’re resistant to the attacks discussed throughout this post.

The WebAuthn Protocol Under the Hood

When a user registers a passkey: the browser sends a navigator.credentials.create() request with a challenge (random bytes from the server). The authenticator (TPM, secure enclave, hardware key) generates an asymmetric key pair — Ed25519 or ECDSA P-256. The private key never leaves the authenticator. The authenticator signs a statement with its manufacturer attestation key. The public key, credential ID, and attestation object are sent to the server and stored.

During authentication, the server sends a new challenge. The authenticator signs it with the private key. The server verifies with the stored public key. No shared secret, no hash to steal, no phishing possible — the authenticator verifies the domain cryptographically.

Authenticator Types

Platform authenticators are built into devices: Apple Secure Enclave, Windows Hello (TPM-backed), Android Titan M2. Roaming authenticators are hardware security keys (YubiKey, Feitian) that work across devices via USB, NFC, or BLE. Synced passkeys (Apple iCloud Keychain, Google Password Manager) replicate credentials across devices using end-to-end encrypted cloud storage — convenient, but the security depends on the cloud sync provider’s implementation.

Implementation Pitfalls

Common mistakes include: skipping attestation verification (allows fake authenticators), accepting legacy algorithms (RS1, unsupported curves), not enforcing user verification (allows someone who stole your unlocked phone to authenticate), and storing credential IDs without proper origin binding. The biggest practical mistake is treating passkeys as a drop-in replacement without updating recovery flows — if a user loses all devices with synced passkeys, you need a secure recovery mechanism that doesn’t re-introduce phishing risk.

Identity Threat Detection and Response (ITDR)

Gartner introduced ITDR as a distinct security category in 2022, recognizing that identity systems had become critical infrastructure — and critical attack targets — without dedicated detection and response capabilities. Traditional SIEMs and EDR tools monitor endpoints and networks; ITDR monitors identity itself.

Core Capabilities

Behavioral analytics baselines normal identity behavior — when users authenticate, from where, to what Resources, and using what methods. Deviations trigger alerts: a user authenticating from two continents within minutes, a service account suddenly accessing new resources, an admin creating accounts at 3 AM. Credential usage anomaly detection identifies impossible travel, unusual token refresh patterns, and credential stuffing indicators (rapid sequential auth failures followed by success). Privilege escalation detection monitors role changes, permission modifications, and suspicious just-in-time access requests.

The ITDR Stack

CrowdStrike Falcon Identity correlates identity telemetry with endpoint detection. Okta ThreatInsight sits at the identity provider layer, analyzing authentication patterns across the entire Okta customer base. Silverfort provides identity protection for legacy systems that don’t natively support MFA by intercepting authentication requests at the network layer. Semperis focuses on AD and Entra ID, detecting directory-level attacks including Golden Ticket patterns and unauthorized schema modifications.

The key insight of ITDR is that identity is the control plane of modern infrastructure. If you can’t detect attacks on the control plane, all the endpoint and network security in the world won’t help.

Zero Trust Identity Architecture

Zero Trust isn’t a product — it’s an architecture that treats identity as the primary enforcement point. The old model: VPN in, trust everyone inside. The new model: verify every request, every time, regardless of network location.

Identity-Aware Proxies and BeyondCorp

Google’s BeyondCorp model, published in 2014, demonstrated that internal network position is not a meaningful trust signal. Users access internal applications through identity-aware proxies (IAPs) that evaluate identity, device posture, and context on every request — no VPN required. Cloudflare Access, Okta Access Gateway, and Microsoft Entra Private Access implement similar patterns.

Implementing Zero Trust Identity

A practical implementation layers several controls:

1. Conditional Access Policies: Don’t just check credentials — check location, device compliance, risk score, and time. Block or step-up authentication based on policy.
2. Device Trust: Require managed devices with valid certificates, up-to-date OS, and compliant security software. Unmanaged devices get limited access or no access.
3. Risk-Based Authentication: Use real-time risk signals (impossible travel, new device, anomalous behavior) to dynamically adjust authentication requirements. Low risk = passwordless. High risk = step-up with MFA or block.
4. Session-Level Controls: Don’t just authenticate at login. Re-evaluate trust continuously throughout the session. If risk signals change mid-session (user moves to a new location, new process launches), enforce re-authentication or terminate the session.

The goal isn’t to make authentication harder — it’s to make the right authentication decisions automatically based on context. Zero trust identity is the convergence of identity verification, device compliance, and behavioral analytics into a single enforcement layer.

Conclusion

Identity attacks are the dominant threat vector because they exploit the fundamental trust model of most applications: authenticate once, access everything. The tools to defend against this exist — passkeys, PKCE, proper session management, token validation — but they require deliberate implementation. Every session token stored in localStorage, every OAuth flow without PKCE, and every MFA push without number matching is an open door.

Reference: <a href="https://owasp.
See also: OWASP Cheat Sheets.org/www-project-top-ten/” target=”_blank” rel=”noopener noreferrer”>OWASP Top 10