Executive Summary

Identity attacks increasingly occur after authentication rather than before it. Attackers steal session tokens, abuse legitimate access, and operate inside trusted sessions that traditional security controls rarely inspect. As Identity Threat Detection and Response (ITDR) becomes a core security discipline, organisations must shift from monitoring authentication events alone to continuously validating authenticated sessions. This article examines the identity telemetry gaps that allow credential theft to evade detection and outlines practical approaches for building operational identity monitoring capabilities.

The Existential Blind Spot: The Adversary-in-the-Middle (AitM) Session Paradox

The modern enterprise SOC faces a quiet, structural crisis: our detection logic is heavily optimized for the "Authentication Gate," while modern adversaries are completely bypassing the gate by stealing the keys after the lock has already turned.

When an attacker deploys an Adversary-in-the-Middle (AitM) phishing framework (such as Evilginx), they are no longer aiming for legacy static credentials or simple push-notification fatigue. Instead, they position their infrastructure as a reverse proxy to clone an actively authenticated Session Cookie or JWT Token that has already completed your enterprise multi-factor authentication (MFA) challenges.

The Trap of the Pristine Authentication Event

When this hijacked session token is replayed from the attacker's command-and-control infrastructure, your identity provider (IdP) logs look pristine. The telemetry reads as a successful, fully authorized, and MFA-validated session because the complex Conditional Access (CA) logic and authentication gates already executed and passed on the legitimate user's endpoint.

If a SOC team only monitors the point-of-authentication telemetry (the door opening), they are entirely blind. Traditional anomaly logic fails because the attacker is operating within the trusted boundaries of a valid corporate agent.

Security Primitive Comparison: Why Legacy Controls Miss Post-Auth Identity Theft

EDR (Endpoint Detection & Response)

→ Detection Focus: Malicious processes, file operations, exploit behavior on endpoints

→ Blind Spot: Cloud authentication occurs entirely outside endpoint visibility. Token theft via phishing happens in browser before EDR-detectable execution.

→ Why It Fails: Attackers replay stolen session tokens from external infrastructure. Victim endpoint may be offline. No malicious process to detect.

SIEM (Batch Processing Model)

→ Detection Focus: Log aggregation and correlation across infrastructure, typically batch-processed

→ Blind Spot: Lacks identity-specific correlation rules. Generic anomaly detection fails because successful authentication is expected behavior.

→ Why It Fails: Without enrichment (IP reputation, geolocation, device fingerprint), cannot distinguish legitimate remote access from credential theft. Alert fatigue from false positives.

Legacy IAM Architecture

→ Detection Focus: Authentication gate monitoring (login success/failure)

→ Blind Spot: Post-authentication session validation. No continuous assessment of session legitimacy after MFA completes.

→ Why It Fails: AitM attacks steal tokens after authentication gate passes. IdP logs show pristine, MFA-validated sessions. Gate-focused monitoring is architecturally blind to session hijacking.

Moving Beyond the Gate: Session Graph Anomaly Detection

To intercept modern identity theft before lateral movement or exfiltration occurs, SOCs must evolve their detection focus from static authentication properties to Continuous Session Graph Validation. Operational threat hunting must pivot to tracking behavioral consistency mid-session across the active token's lifecycle.

High-fidelity detection rules must be tuned to alert on subtle mid-session anomalies, including:

→ TLS Fingerprint Mismatches: A sudden change in the JA3/JA4 or Client Hello TLS fingerprint within an ongoing, authenticated session identifier.

→ Transient User-Agent Drift: Drastic alterations in browser user-agent strings or underlying OS signatures occurring mid-session while using a single session ID.

→ Concurrent Geographic Polling: A single session token making programmatic API calls or resource queries across distinct, geographically isolated IP spaces concurrently. This is a signature behavior of cloud-hosted adversary automation mimicking an employee's session.

Until security teams stop treating a valid session token as absolute proof of an untampered user, attackers will continue to rent legitimate access through our multi-million dollar identity stacks without tripping a single perimeter alarm.

Attack Chain / Threat Analysis

Identity-based attacks follow predictable patterns across the kill chain. Understanding each stage enables SOC teams to implement detection controls at multiple interception points.

Initial Access (MITRE ATT&CK T1078: Valid Accounts)

Attackers obtain legitimate credentials through phishing (T1566), credential stuffing (using breached credential databases), MFA fatigue attacks (T1621: Multi-Factor Authentication Request Generation), or social engineering of helpdesk personnel. Initial access generates authentication telemetry: successful logins from unusual geolocations, authentication outside normal user patterns, or MFA approval following multiple rejections. This represents credential theft and privilege abuse visible in identity provider logs.

Telemetry indicators: Azure AD Sign-In Logs show authentication from new IP ranges, impossible travel scenarios (authentication from geographically distant locations within impossible timeframes), or first-time device registrations. Okta System Logs capture user.session.start events with anomalous context (residential ISP, VPN exit nodes, TOR infrastructure).

Execution / Privilege Escalation (MITRE ATT&CK T1078.004: Cloud Accounts, T1548: Abuse Elevation Control Mechanism)

Once authenticated, attackers escalate privileges to access sensitive resources. Privilege escalation generates distinct telemetry: role assignments, group membership modifications, and conditional access policy changes visible in audit logs.

Telemetry indicators: Azure AD Audit Logs record "Add member to role" events, particularly for Global Administrator, Privileged Role Administrator, or Application Administrator roles. AWS CloudTrail logs AttachUserPolicy, PutUserPolicy, and AssumeRole API calls. Okta captures user.account.privilege.grant events. These technical events represent the core detection surface for privilege abuse.

Persistence (MITRE ATT&CK T1136: Create Account, T1098: Account Manipulation)

Attackers establish persistence by creating backdoor accounts, registering additional MFA devices to compromised accounts, generating long-lived access tokens, or modifying authentication policies to weaken security controls. Persistence mechanisms ensure continued access even if initial compromise vector is remediated.

Telemetry indicators: User creation events (Azure AD: "Add user", AWS: CreateUser), MFA device registration (user.mfa.factor.activate in Okta, "Register security info" in Azure AD), API token generation (system.api_token.create), OAuth application consent grants, and service principal credential additions.

Command & Control (MITRE ATT&CK T1071: Application Layer Protocol)

Identity-based attacks use legitimate cloud infrastructure for C2, making network-based detection ineffective. Attackers authenticate to cloud management consoles (Azure Portal, AWS Console, Okta Admin) or use API access with stolen credentials. C2 traffic appears as normal SaaS application traffic over HTTPS.

Telemetry indicators: Administrative console access from unusual sources, API activity patterns inconsistent with user role (developers accessing billing APIs, finance users querying infrastructure logs), and high-volume API calls indicating automation or scripting.

Objectives: Data Exfiltration, Ransomware, Espionage (MITRE ATT&CK T1567: Exfiltration Over Web Service, T1486: Data Encrypted for Impact)

Attackers leverage compromised identity to access sensitive data (customer records, intellectual property, financial data), deploy ransomware across cloud and on-premises infrastructure, or conduct long-term espionage. Cloud-native attacks enable massive-scale data access without traditional exfiltration indicators (large network transfers).

Telemetry indicators: Bulk file access patterns (SharePoint, OneDrive, S3), database query volumes exceeding baselines, large-scale permission grants (sharing files externally), backup deletion (preventing ransomware recovery), and multi-region resource deployment (cryptomining, C2 infrastructure).

Human and Process Vulnerabilities (MITRE ATT&CK T1656: Impersonation)

Helpdesk social engineering remains the highest-risk identity attack vector. Attackers impersonate executives or employees, fabricate urgency scenarios, and exploit trust-based verification processes. Human operators lack the context to distinguish sophisticated impersonation from legitimate requests. Organisations with weak identity governance processes enable attacks: no mandatory delays for high-risk operations, same helpdesk agent performing verification and execution, no segregation of duties for privilege grants, and emergency override procedures lacking audit trails.

Process failure indicators: Privilege escalation requests during non-business hours, urgency-justified verification bypasses, single-channel authentication (phone-only verification), lack of callback verification to pre-registered numbers, privilege escalation occurring within minutes of helpdesk ticket closure, weekend/holiday administrative activity without pre-approved change tickets, and privilege grants without corresponding HR role changes or access review approvals.

Identity Telemetry Sources and Critical Log Events

Identity infrastructure generates diverse telemetry across authentication, authorisation, and account management operations. SOC teams must understand which log sources contain actionable threat intelligence and which specific events indicate compromise.

Azure Active Directory (Microsoft Entra ID) Telemetry

Azure AD serves as the identity backbone for Microsoft 365 and Azure environments. Critical telemetry sources include Sign-In Logs (interactive and non-interactive authentication events), Audit Logs (administrative actions and configuration changes), Risky Sign-Ins (Identity Protection detections), and Provisioning Logs (account lifecycle events).

High-value events for detection: UserLoggedIn (Event 4624 equivalent), FailedUserLogon (repeated failures indicating credential stuffing), UserPasswordChanged (especially outside business hours), Add member to role (privilege escalation), Update conditional access policy (authentication bypass attempts), Register security info (MFA device registration), and Update user (account attribute modifications).

Okta System Log Telemetry

Okta centralises authentication for SaaS applications and enterprise resources. The System Log captures authentication events, administrative actions, and policy enforcement decisions with millisecond-level precision. Critical events include user.session.start for successful authentication with context (IP, device, location), user.authentication.auth_via_mfa for MFA challenge and response events, user.account.privilege.grant for administrative role assignment, system.api_token.create for API token generation indicating potential automation abuse, policy.rule.update for authentication policy modifications, user.mfa.factor.activate for new MFA device enrollment, and user.account.lock for account lockout events that may indicate brute force attempts. Okta logs include rich context: client IP address, geolocation, device fingerprint, user agent, authentication method, and outcome. This context enables correlation with threat intelligence and detection of anomalous access patterns.

Additional High-Value Identity Telemetry Sources

Beyond Azure AD and Okta, organisations should monitor identity-related telemetry from cloud platforms, directory services, privileged access systems, and remote access infrastructure.

High-value sources include:

\ AWS CloudTrail IAM events for role assumptions, policy changes, access key usage, and privileged activity.

\ Google Workspace audit logs covering administrative actions, authentication events, OAuth token usage, and privileged role assignments.

\ Active Directory event logs including authentication activity, Kerberos operations, privileged group membership changes, and account modifications.

\ Privileged Access Management (PAM) platforms such as CyberArk, BeyondTrust, and Delinea, which provide visibility into privileged credential usage, password vault activity, and administrative sessions.

\ VPN and remote access platforms including Cisco AnyConnect, Palo Alto GlobalProtect, and Zscaler Private Access, which provide geographic, network, and access context for remote authentication activity.

Effective identity monitoring requires visibility across the entire authentication ecosystem rather than relying solely on identity provider logs.

Operational Challenges for SOC and Security Teams

Scale and Data Management

Identity systems generate enormous authentication volumes. Collection is straightforward. Operational analysis is the challenge. Many organisations successfully ingest identity logs but fail to create detections that convert telemetry into actionable alerts.

Behavioural Baseline Complexity

Identity monitoring depends on understanding normal authentication behaviour. Remote work, role changes, and privileged account usage make static baselines ineffective. Detection programs require continuously evolving behavioural models.

Correlation and Context Challenges

Authentication telemetry gains value when enriched with HR data, asset inventories, threat intelligence, geolocation context, and device reputation. Without enrichment, analysts lack sufficient context to distinguish compromise from legitimate activity.

Multi-Cloud Identity Complexity

Modern authentication flows span Azure AD, Okta, AWS IAM, Google Workspace, and on-premises Active Directory. Effective monitoring requires visibility across these trust relationships rather than isolated log analysis.

Visibility Gaps and Why Existing Controls Fail

Despite collecting identity logs, most organisations face systematic visibility gaps that prevent effective threat detection. Understanding why standard security controls fail to detect identity-based attacks is essential for building effective monitoring capabilities.

Why Standard EDR Will Not See Identity Layer Attacks

Endpoint Detection and Response (EDR) platforms excel at detecting malicious processes, file operations, and exploit behavior. However, identity attacks occur at the authentication layer, before endpoints are involved or using legitimate endpoint activity.

Credential theft via phishing: When a user enters credentials into a phishing site, the compromise occurs in the browser before any EDR-detectable malicious process executes. The attacker authenticates from external infrastructure using valid credentials. EDR on the victim's endpoint sees normal browser activity.

Cloud-based authentication: SaaS application authentication occurs entirely in cloud identity providers. Users authenticate to Okta, which federates to Salesforce, Google Workspace, or AWS. EDR agents on user endpoints have no visibility into these cloud authentication decisions.

Token theft and replay attacks (cloud variants): Attackers steal authentication tokens (OAuth access tokens, SAML assertions, JWT bearer tokens, Azure AD refresh tokens) and replay them from attacker-controlled infrastructure. Modern cloud attacks leverage Pass-the-Cookie (T1539: Steal Web Session Cookie) and Token Theft/Replay (T1528: Steal Application Access Token) rather than legacy on-premises Pass-the-Token (T1550.002). The victim endpoint may be offline or clean while the attacker uses stolen tokens to access cloud resources. EDR sees nothing because the attack doesn't touch monitored endpoints. Microsoft Entra ID defenses include Token Protection (binding tokens to device certificates), Continuous Access Evaluation (CAE) to revoke compromised sessions in real-time, and strict Conditional Access policies requiring device compliance and trusted network locations to prevent session hijacking and service principal/workload identity abuses.

Why SIEM Detection Fails Without Specialized Identity Rules

SIEM platforms ingest identity logs but most deployments lack detection rules tuned for identity attack patterns. Generic anomaly detection fails because identity attacks often use valid credentials in ways that appear legitimate.

Successful authentication is not inherently suspicious: Unlike malware execution or network scanning, successful authentication is the expected outcome. SIEM correlation rules must detect subtle anomalies: authentication from new geographic region, login during unusual hours, privilege escalation following helpdesk ticket, or MFA enrollment from unrecognized device.

Lack of identity-specific correlation rules: Most SIEM deployments include out-of-box rules for malware, network intrusion, and vulnerability exploitation. Few include comprehensive identity attack detection rules. SOC teams must custom-build detection logic for credential stuffing, impossible travel, privilege abuse, and MFA bypass techniques.

Missing enrichment context: Identity logs contain IP addresses, user agents, and timestamps but lack threat intelligence context. Without IP reputation lookups, geolocation enrichment, and device fingerprint analysis, SOC analysts cannot distinguish malicious authentication from legitimate remote access.

Alert fatigue from false positives: Overly sensitive identity alerts (any login from new IP address, any authentication outside business hours) generate overwhelming false positive rates. Analysts ignore or disable these alerts. Effective identity monitoring requires tuned detection logic that accounts for legitimate business context.

Why Traditional Security Validation Misses Identity Risk

Traditional security validation focuses on software vulnerabilities, infrastructure weaknesses, and point-in-time assessments. Identity attacks often exploit authentication workflows, privilege management processes, and trust relationships rather than technical flaws.

Vulnerability scanners cannot assess conditional access policies, excessive privilege assignments, weak MFA enrollment processes, or federated identity trust relationships. Similarly, penetration tests provide only a snapshot of identity security at a single moment in time while identity environments continuously change through onboarding, privilege modifications, policy updates, and cloud integrations.

As a result, organisations can perform well in traditional security assessments while remaining highly exposed to credential theft, session hijacking, and privilege abuse.

Why Security Awareness Training Doesn't Prevent Credential Phishing

Security awareness training educates users to recognize phishing emails and suspicious authentication requests. However, sophisticated phishing campaigns and social engineering attacks bypass training through high-fidelity impersonation and psychological manipulation.

Phishing evolution outpaces training: Adversary-in-the-middle (AitM) phishing proxies real authentication pages in real-time, defeating training that teaches users to "check the URL." Users see legitimate domains and valid SSL certificates while attackers intercept credentials and session tokens.

Fatigue and attention limitations: Users make dozens of authentication decisions daily. Training cannot maintain perfect vigilance across every MFA push notification, every password reset email, every authentication prompt. Attackers exploit moments of inattention, urgency, or cognitive overload.

Technical controls required: Training is necessary but insufficient. Effective defense requires technical controls that make phishing difficult or impossible: phishing-resistant MFA (FIDO2), conditional access policies that block authentication from unexpected locations, and real-time telemetry monitoring that detects compromise even when users fall for attacks.

Identity attacks use authorized mechanisms: valid credentials, legitimate applications, proper authentication flows. Traditional security controls designed to detect technical exploitation cannot see this activity. Purpose-built identity telemetry monitoring is required.

Indicators & Warning Signs in Identity Telemetry

Identity telemetry contains distinct patterns that indicate compromise. The following indicators are intended as inputs for SIEM correlation rules and analyst runbooks.

Authentication Behavior Anomalies

→ Privilege escalation requests during non-business hours: Especially Friday evenings, weekends, holidays

→ Multiple MFA device registration requests: Particularly for high-privilege accounts

→ New administrative account creation outside change control: Unscheduled account provisioning without corresponding ticket history

→ Rapid privilege use after helpdesk interaction: Immediate access to sensitive systems following identity verification

→ Geographic login anomalies with "travel" justification: Consecutive logins from impossible travel distances

→ Access to cloud identity management consoles: Unexpected Azure AD, Okta, or similar platform access

→ Bulk data access patterns immediately after authentication: Large volume file access within first hour of session

Identity Verification Inconsistencies

→ Single-channel identity verification: All verification occurring over phone without out-of-band confirmation

→ Knowledge-based authentication only: No cryptographic or possession-based factors required

→ Urgency claims with authority references: "The CEO needs this immediately" or "I'm traveling and locked out"

→ Reluctance to use standard verification channels: Refusal or excuses avoiding corporate video conferencing or callback procedures

→ Newly created accounts accessing high-value targets: Accounts less than 48 hours old with administrative privileges

Device and Network Infrastructure Indicators

→ New device registrations from unfamiliar endpoints: MFA device adds from unrecognized browser fingerprints or IP ranges

→ VPN connections from unexpected geolocations: First-time connections from countries not in employee travel history

→ Cloud console access from residential ISPs: Administrative access from non-corporate networks

→ Identity provider policy modifications: Changes to MFA requirements, conditional access policies, or authentication methods

How to Integrate Identity Telemetry Monitoring into SOC Workflows

Operationalizing identity telemetry monitoring requires integrating log collection, correlation rules, behavioral analytics, and response workflows into existing SOC operations. The following strategies provide actionable implementation paths for security teams.

Monitoring Strategies

Deploy identity-focused SIEM use cases: Configure alerts for privilege escalation during non-business hours, new MFA device registrations, administrative account creation outside change windows, and cloud identity platform access from unusual sources. These detection rules should be documented in SIEM platforms following NIST SP 800-61 Computer Security Incident Handling guidelines.

Implement User and Entity Behavior Analytics (UEBA): Baseline normal authentication patterns, access behaviors, and privilege usage. Flag deviations including impossible travel, unusual resource access, and temporal anomalies. Per CISA guidance on insider threat programs, behavioral monitoring must account for legitimate business context.

Enable enhanced logging for identity infrastructure: Ensure full audit logging for Azure AD, Okta, and other identity providers. Capture MFA device registration events, policy modifications, privilege changes, and group membership updates. Retention should align with incident response requirements (NIST recommends minimum 90 days for authentication logs).

Detection Use Cases

The following are example SIEM correlation rules. Thresholds should be adjusted to reflect your organisation's baseline behaviour.

Use Case 1 - Helpdesk-initiated privilege escalation: Alert when helpdesk ticket closure timestamp occurs within 5 minutes of privilege escalation or MFA device registration. Correlate ServiceNow/Jira ticket data with Azure AD/Okta audit logs.

Use Case 2 - Temporal attack pattern detection: Flag privilege escalation requests occurring Friday 5 PM to Monday 8 AM, during federal holidays, or outside core business hours (9 AM to 5 PM local time). Integrate with HR systems for holiday calendars.

Use Case 3 - Geographic authentication anomalies: Alert on authentication from new countries/regions within 24 hours of helpdesk interaction. Require secondary verification for impossible travel scenarios (as defined in MITRE ATT&CK T1078 detection guidance).

Identity Verification Improvements

Implement out-of-band verification policy: Require callback to pre-registered phone number (stored offline in HR system) for all privilege escalation requests. No exceptions for urgency or authority. Transition from SMS/phone-based MFA to cryptographic hardware keys (FIDO2: YubiKey, Titan, etc.) for administrative accounts to eliminate social engineering of MFA registration. Enforce strict Microsoft Entra ID registration campaigns and Conditional Access controls during credential registration to block unauthorized MFA binding. Document procedures in helpdesk runbooks per NIST SP 800-53 IA-2 (Identification and Authentication) controls and align with OMB M-22-09 federal Zero Trust requirements.

Eliminate knowledge-based authentication: Remove security questions and personal information-based verification. OSINT renders these ineffective. Replace with possession-based (hardware token) and biometric factors where possible.

Endpoint Controls

Enforce conditional access policies: Require managed device compliance for cloud identity management access. Prevent administrative actions from unmanaged endpoints. Configure per Microsoft Zero Trust framework or equivalent cloud provider guidance.

Implement privileged access workstations (PAWs): Restrict administrative access to hardened, dedicated systems. Follows CIS Controls v8 (Control 4.6) and CISA best practices for privileged access management.

Process Changes

Institute mandatory delays for high-risk operations: Build 2-hour minimum delay into privilege escalation workflows. Urgency cannot override. Creates detection window and eliminates attacker's time advantage.

Separate verification and execution: Require different helpdesk agent to verify identity than agent who executes privilege changes. Prevents single point of social engineering failure.

Implement no-human-override policies: System-enforced controls that cannot be bypassed regardless of claimed authority or urgency. Cryptographic authentication cannot be socially engineered.

Weekend/holiday privilege freeze: Disable non-emergency privilege escalation during high-risk temporal windows. Requires C-level approval for exceptions.

Industry Considerations

Identity telemetry monitoring has become a cross-sector security requirement rather than an industry-specific capability. While attack objectives differ, the underlying problem remains consistent: attackers increasingly target identity infrastructure because authentication systems sit between users and critical resources.

Technology providers face supply-chain and privileged access risks. Financial institutions focus on account takeover and transaction fraud. Healthcare organisations monitor access to regulated patient data. Critical infrastructure operators must protect operational technology environments from credential-based intrusion. Government agencies and defence contractors require enhanced monitoring of privileged identities and federated access relationships.

Despite these differences, the operational requirement remains the same. Organisations must detect compromised credentials, session hijacking, privilege escalation, and policy manipulation before attackers establish persistence or reach sensitive assets.

Broader Trend Implications

Shift from Prevention to Detection: Perfect prevention is unachievable. Credentials will be compromised. The operational imperative shifts to detecting compromise within minutes rather than preventing every attack. Real-time identity telemetry monitoring enables this capability.

Rise of ITDR: Identity Threat Detection and Response (ITDR) is emerging as a distinct security discipline. UEBA platforms, identity security posture management (ISPM) tools, and cloud identity provider integrations now form dedicated identity monitoring stacks separate from traditional SIEM and EDR.

Session-Centric Security: Authentication validation is no longer sufficient. Continuous session monitoring detects token theft, session hijacking, and mid-session anomalies that occur after authentication completes.

Summary

The following assessment is based on observed deployment patterns across enterprise environments.

The core failure is not visibility. Most enterprises already collect identity telemetry from Azure AD, Okta, Google Workspace, Active Directory, and cloud infrastructure. The failure is operational ownership.

Identity teams manage authentication platforms. SOC teams manage detection and response. Identity telemetry often falls between both functions, creating a monitoring gap that attackers routinely exploit.

As identity-based attacks continue shifting toward session theft, token replay, privilege abuse, and cloud-native persistence, organisations that operationalise identity telemetry gain a significant defensive advantage. The challenge is no longer collecting logs. The challenge is converting identity data into actionable detection capability.

Where this evolves:

Predictive identity risk scoring replaces reactive detection. Real-time risk assessment for every authentication based on device posture, behavioral history, and threat context. High-risk authentications trigger step-up verification before resource access.

Autonomous response integration reduces latency. Impossible travel terminates sessions automatically. MFA fatigue triggers account locks. Privilege escalation during off-hours initiates approval workflows. Response drops from minutes to milliseconds.

Identity Threat Detection and Response (ITDR) is steadily becoming a primary detection discipline rather than a niche identity function. As attackers continue shifting toward credential theft, session hijacking, and cloud-native access abuse, organisations that operationalise identity telemetry gain a significant defensive advantage. The objective is no longer perfect prevention. It is reducing the gap between compromise and detection until stolen credentials become operationally useless to attackers.

Further Reading

Our latest vulnerability intelligence articles and deep dives.

Related Analysis

Ensure you understand the latest KEV intelligence to cover off any potential gaps in your remediation activities. 

Frequently Asked Questions (FAQs)

1. Why is identity telemetry often missed in SOC monitoring?
Most SOCs collect identity logs but don’t operationalise them with detection rules or behavioural analytics. As a result, authentication data is stored for compliance but not actively used to detect post-authentication attacks or session abuse.

2. What is the biggest blind spot in detecting identity-based attacks?
The biggest blind spot is post-authentication activity. Attackers often steal session tokens after MFA is completed, meaning they operate inside valid sessions that appear legitimate in standard identity provider logs.

3. How do attackers bypass MFA without triggering alerts?
Attackers use techniques like adversary-in-the-middle (AitM) phishing to intercept session cookies or tokens after MFA succeeds. Since the session is already authenticated, identity systems log it as a normal, trusted login.

4. What identity telemetry signals are most useful for detecting compromise?
High-value signals include impossible travel, mid-session device or browser changes, unusual privilege escalation events, new MFA device registrations, and concurrent session activity from geographically distant IPs.

Subscribe to get our intelligence articles as soon as we publish!

About This Report

Attribution Note

This analysis is based on publicly available reporting and security research summaries. Some technical details may change as additional information becomes available. 

Author Information

Timur Mehmet | Founder & Lead Editor

Timur is a veteran Information Security professional with a career spanning over three decades. Since the 1990s, he has led security initiatives across high-stakes sectors, including Finance, Telecommunications, Media, and Energy. Professional qualifications over the years have included CISSP, ISO27000 Auditor, ITIL and technologies such as Networking, Operating Systems, PKI, Firewalls. For more information including independent citations and credentials, visit our About page.

Contact: This email address is being protected from spambots. You need JavaScript enabled to view it.

Editorial Standards

This article adheres to Hackerstorm.com's commitment to accuracy, independence, and transparency:

• Fact-Checking: All statistics and claims are verified against primary sources and authoritative reports
• Source Transparency: Original research sources and citations are provided in the References section below
• No Conflicts of Interest: This analysis is independent and not sponsored by any vendor or organization
• Corrections Policy: We correct errors promptly and transparently. Report inaccuracies to This email address is being protected from spambots. You need JavaScript enabled to view it.

Editorial Policy: Ethics, Non-Bias, Fact Checking and Corrections

Learn More: About Hackerstorm.com | FAQs

Source Transparency

→ CISA. Cybersecurity Advisories. https://www.cisa.gov/news-events/cybersecurity-advisories

→ NIST. SP 800-53 Rev. 5. https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final

→ NIST. SP 800-61 Rev. 2. https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final

→ NIST. Cybersecurity Framework 2.0. https://www.nist.gov/cyberframework

→ Mandiant. M-Trends 2025. https://www.mandiant.com/m-trends

→ Unit 42. Global Incident Response Report. https://www.paloaltonetworks.com/unit42/incident-response

→ MITRE. ATT&CK Framework. https://attack.mitre.org

→ Microsoft. Azure AD Security Documentation. Available at learn.microsoft.com

→ Okta. System Log API Documentation. Available at developer.okta.com

→ Google Cloud. Workspace Security Best Practices. Available at cloud.google.com

→ AWS. CloudTrail and IAM Security. Available at docs.aws.amazon.com

→ CIS. CIS Controls v8. https://www.cisecurity.org/controls/v8

→ CISA. Cybersecurity Performance Goals. https://www.cisa.gov/cross-sector-cybersecurity-performance-goals

→ OMB. Memorandum M-22-09. https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf

→ SANS Institute. Identity and Access Management Training. Available at sans.org

→ Gartner. Identity Threat Detection and Response (ITDR) Market Analysis (2024). Available at gartner.com

→ Forrester. Zero Trust Security Research (2024). Available at forrester.com