Why Identity Became the Preferred Attack Surface
The security industry's investment in endpoint hardening over the past decade has changed attacker behavior in a predictable way. EDR platforms now catch a large fraction of common exploitation techniques at the endpoint level — shellcode injection, reflective DLL loading, memory-mapped file abuse. The behavioral engines in CrowdStrike Falcon and SentinelOne have genuine detection coverage against the techniques that were reliable initial access vectors five years ago.
Attackers adapted by moving the initial access stage off the endpoint entirely. Compromising credentials — through phishing, credential stuffing, infostealer malware, or OAuth abuse — achieves initial access in a way that does not touch the endpoint detection layer at all. An attacker who logs into your Okta tenant with a legitimate stolen credential does not trigger an EDR detection. They look like a user.
This shift is well-documented in observed breach patterns from the past two years. The dominant initial access technique is no longer endpoint exploitation — it is valid account compromise (T1078), achieved through a growing variety of identity-layer techniques that most mid-market SOC teams do not have adequate detection coverage for. Understanding the current identity attack surface requires mapping each technique vector to its observable event signature and identifying which require cross-source correlation to detect reliably.
Credential Stuffing and Password Spray at Scale
Credential stuffing (T1110.004) and password spray (T1110.003) are high-volume techniques that remain effective because a significant fraction of users reuse passwords across services, and because the credential databases from prior breaches are readily available. Attackers automate these at scale: thousands of credential pairs tested against a target's authentication endpoint over hours or days, distributed across IP address ranges to avoid rate limiting.
The observable signatures differ between the two techniques. Credential stuffing produces a pattern of authentication attempts where the username set is large (testing many accounts) but each account sees few attempts — often just one or two — because the attacker is testing specific password matches from breach databases. Active Directory Event ID 4625 (failed logon) will fire, but the per-account frequency may be low enough to avoid threshold-based alerting tuned for brute force.
Password spray produces the inverse pattern: a small username set (typically a list of valid accounts obtained through OSINT or directory enumeration) each tested against a short list of common passwords. The per-account 4625 frequency is still low, but the temporal pattern — many accounts receiving failed logon attempts in a narrow time window — is distinguishable from normal operational noise if you are looking at the aggregate rather than the per-account view.
The detection logic for both patterns requires viewing authentication failures at the tenant level rather than the account level. Okta System Log provides the user.session.start and user.authentication.auth_via_mfa event types with outcome status that captures both successful and failed authentications. The signal is in the cross-account temporal clustering, not in any individual account's failure count.
MFA Fatigue and Conditional Access Bypass
MFA fatigue attacks (technically a subset of T1621 — MFA Request Generation) exploit push-notification-based MFA implementations. The attacker, having obtained valid credentials through phishing or credential theft, repeatedly triggers MFA push notifications to the victim's device. Most users who receive an unexpected push notification at 2 AM will eventually approve it to make it stop, or approve it by mistake when their phone lights up while they are doing something else.
This technique became significantly more prevalent as organizations broadly adopted MFA but chose push notification implementations (Duo Push, Microsoft Authenticator push, Okta Verify push) over more phishing-resistant options like FIDO2/WebAuthn hardware tokens or certificate-based authentication. Push MFA is far easier to deploy and maintain — and correspondingly easier to abuse.
The detection signal for MFA fatigue is in the pattern of push requests before a successful authentication. An Okta System Log sequence showing multiple user.authentication.auth_via_mfa events with outcome FAILURE (user denied or timed out) followed by a SUCCESS outcome — particularly at unusual hours or from a new device — is the canonical pattern. Entra ID sign-in logs show the same pattern through the authenticationRequirement field and the step-up authentication event sequence.
The cross-source correlation value is in connecting this pattern with any concurrent EDR or endpoint event on the victim's device. If the MFA fatigue sequence is preceded by a process execution event on the same user's laptop that matches an infostealer profile (T1555.003 credential access from browser credential store), the sequence confirms an active compromise rather than a confused user accidentally approving a rogue push.
OAuth Application Consent Abuse
OAuth application consent abuse (T1550.001 in the ATT&CK framework's "Use Alternate Authentication Material" category) is a technique that gets less attention than credential stuffing but has become significantly more prevalent in Microsoft 365 and Google Workspace environments. The attack vector: a threat actor registers a legitimate-looking OAuth application and sends the target user a consent request. If the user approves the request — which is often phrased as a routine permission request from a legitimate-sounding app name — the attacker receives a persistent OAuth token with the approved scopes. No password is captured. No credential needs to be maintained. The token persists until it is revoked.
The detection signal lives in Entra ID audit logs and the Microsoft 365 unified audit log under the Consent to application and Add app role assignment to user event types. The challenge is that legitimate OAuth consent events occur constantly in active Microsoft 365 environments — users routinely approve integrations for productivity tools, HR platforms, and development environments. The signal is in the specific combination of: unfamiliar publisher identity, consent to mail read/write scopes or user directory read access, and absence of the application from a pre-approved application catalog.
This technique is particularly difficult to detect from identity logs alone because the consent event itself is a normal operational action. Cross-source correlation with EDR becomes relevant when the OAuth consent event is preceded by a phishing link click event on the same user's endpoint — visible in browser telemetry or network proxy logs. The identity event in isolation looks like a user installing a new app. The identity event correlated with a prior suspicious outbound HTTP event from the same user's endpoint maps to an active phishing-to-consent sequence.
Session Token Theft and Cross-Geography Reuse
Session token theft (T1539, T1550.001) has become the dominant technique for bypassing MFA entirely. Once an attacker obtains a valid session token — through an adversary-in-the-middle proxy, through infostealer malware that reads browser credential stores, or through an XSS/token exfiltration vulnerability — they can reuse that token from a different geography without triggering an MFA challenge. The identity provider sees a valid, authenticated session and does not require re-authentication unless a conditional access policy detects the token reuse anomaly.
Okta and Entra ID both have varying levels of anomalous location detection built in — Okta's ThreatInsight and Entra's Identity Protection risk scoring can flag impossible travel events (authentication from two geographies within a time window inconsistent with physical travel). However, these detections have well-known bypass techniques: attackers who use residential proxy networks, who target accounts with infrequent travel patterns (lower geographic baseline fidelity), or who time their reuse to coincide with the victim's typical working hours in a compatible time zone.
The cross-source value is in correlating the geographic anomaly with concurrent CloudTrail activity. A session token reused from Eastern Europe will generate Okta events from the anomalous geography, AND will subsequently trigger CloudTrail API calls from that same geography. The combination of Okta geographic anomaly + CloudTrail activity from the same IP range within a short window is a much stronger signal than either observation alone — because it confirms that the anomalous authentication was followed by real resource access, rather than being an access attempt that failed or that the user's VPN configuration explains.
Active Directory: The Persistent Lateral Movement Substrate
For mid-market organizations that maintain hybrid identity — Okta or Entra for cloud SSO but on-premises Active Directory for Windows domain authentication — the AD event log remains a critical detection source for post-initial-access lateral movement.
Kerberoasting (T1558.003) targets service principal names (SPNs) registered in Active Directory. An attacker with any domain user account can enumerate SPNs and request service tickets for them — the ticket request is a normal Kerberos operation, and the resulting ticket can be taken offline for password hash cracking. The detection signal is in the pattern of AS-REQ and TGS-REQ events in the Security event log: a user account requesting Kerberos service tickets for SPNs that they have no operational reason to access, particularly for service accounts with high privilege levels.
Pass-the-hash (T1550.002) and pass-the-ticket (T1550.003) generate distinct Event ID signatures. Logon type 3 (network logon) combined with logon process "NtLmSsp" and authentication package "NTLM" on a non-standard port is the canonical pass-the-hash Event ID 4624 pattern. Pass-the-ticket evidence appears as TGT or TGS usage from a host that did not originate the original authentication — visible in the Security log as Event ID 4769 (Kerberos service ticket request) with a source address that does not match the expected host for the account's normal authentication pattern.
These AD event patterns are particularly valuable in cross-source correlation because they represent the lateral movement stage of the kill chain — the stage that typically occurs between initial access (visible in Okta/Entra logs) and privilege escalation or data staging (visible in CloudTrail). An Okta anomalous authentication event → AD lateral movement event (4624 logon type 9 or 4769 anomalous TGS request) → CloudTrail AssumeRole with elevated permissions constitutes a three-stage kill-chain sequence that no single source can surface on its own.
What Adequate Coverage Actually Requires
This is not to say that every mid-market team can achieve comprehensive identity attack surface coverage with modest resources. Some vectors — particularly OAuth consent abuse in complex multi-tenant Microsoft 365 environments, and session token theft via sophisticated adversary-in-the-middle proxies — require detection logic that goes beyond standard log monitoring. FIDO2/WebAuthn adoption, which eliminates the MFA fatigue vector entirely, is a preventive control that is more effective than any detection approach for that specific technique.
The coverage priority for most mid-market teams should be: (1) cross-account authentication anomaly detection in the identity provider, (2) AD lateral movement detection via Event ID monitoring, and (3) identity-to-cloud correlation for the initial access-to-cloud session establishment sequence. These three capabilities cover the dominant kill-chain paths observed in mid-market intrusions — and they are achievable with existing identity and cloud audit log sources without additional tooling, given entity resolution and temporal correlation applied to the existing event streams.
The identity attack surface expanded materially in 2024–2025 as attackers responded to improved endpoint detection by moving initial access upstream. The detectable evidence of these techniques exists in the logs your identity and cloud infrastructure already generate. Connecting those signals — with entity resolution, temporal windowing, and cross-source correlation — is what turns the existing log data into a functioning detection layer for the identity kill-chain.