The four dimensions of Subject analysis
How the dimensions work together
The four dimensions are independent questions about the same Entity Any discrete actor or object that evidence can attach to during an investigation: a user account, a host, a process, an IP address, a domain, a file. Triage decomposes an alert into its entities and asks what each one was doing; the same idea gives UEBA its E. . Authentication asks how the entity got in. Authorization asks what the entity is allowed to do. Behavior asks what the entity is actually doing. Relationships ask what the entity is connected to.
When all four agree (authenticated normally, acted within its permissions, in line with its history, with relationships that match the role), the Subject assessment passes quickly. When even one disagrees, the disagreement is the lead.
Authentication
The first dimension evaluates how the entity proved who it was. The job is not to assume the Credential Whatever the system accepts as proof of identity: a password, an API key, an OAuth token, a Kerberos ticket, an NTLM hash. Credentials are the highest-value loot in most intrusions; their theft is usually the pivot point. was used legitimately. The job is to evaluate the credentials themselves and the context they were used in.
Detect anomalies
Compare login data, geolocation, and device fingerprints to historical norms. Impossible-travel patterns (a login from two cities 1000 miles apart within 30 minutes), brand-new devices, or sources from anonymizing services are first-pass signals.
Validate identity
Cross-reference the account against HR records, identity provider data, and role definitions. A login from an account that has not been provisioned (or that was supposed to be off-boarded last week) is its own story.
Investigate the session
Map the authentication path: source IP, intermediate identity providers, MFA Multi-factor authentication. A login that required something beyond a password, typically a one-time code, an authenticator app prompt, a security key, or a biometric. MFA materially raises the cost of credential theft, but it can be defeated by phishing, MFA fatigue, or token replay. outcome, session tokens issued. Anomalies in any of these reshape the verdict.
Seven investigative techniques
The dimension breaks down into seven techniques. Each one is a different question about the same authentication event.
Geolocation & device analysis
Evaluate logins for access from unfamiliar locations or devices not typically associated with the user. Outliers in geography or device history often signal credential misuse.
Login patterns review
Investigate spikes in failed logins or rapid successions of attempts, especially when followed by a successful login. Brute force and Password Spraying Trying a small number of common passwords against many accounts to avoid lockouts. (many accounts hit with the same common Password A secret word or phrase used to authenticate a user or system. ) often surface as a burst of 4625 failed logon events on Windows.
Network source inspection
Identify logins from anonymizing services, Tor exit nodes, or known hostile infrastructure. Frequent source IP changes often point to evasion tactics or compromised hosts.
Identity change correlation
Check recent changes to user roles or access levels when investigating anomalies. Unauthorized activity shortly after promotions, transfers, or off-boarding often reflects privilege misuse or insider risk.
Session behavior review
Look for unusually long sessions or Token A small piece of data or code that is used to authenticate or authorize access to a system or resource. reuse across locations. These behaviors often indicate hijacked sessions or token abuse following credential compromise.
SSO movement detection
Monitor federated login flows for lateral movement. Unauthorized access to additional systems via SSO can reveal deeper compromise and privilege escalation across federated identities.
MFA event auditing
Review authentication prompts for signs of excessive challenges, fallback method use, or repeated failures. These anomalies may indicate phishing, MFA fatigue, or bypass attempts.
Mapping to MITRE ATT&CK
The ATT&CK techniques most worth recognizing in Authentication: T1078 Valid Accounts (legitimate credentials used by an attacker, including T1078.004 Cloud Accounts), T1110 Brute Force (and its sub-techniques for password spraying, credential stuffing), T1556 Modify Authentication Process, T1621 Multi-Factor Authentication Request Generation (MFA fatigue), T1539 Steal Web Session Cookie, and T1550.001 Application Access Token (token theft/replay; when the token was forged from a stolen signing key, the Storm-0558 pattern, the forging step itself is T1606 Forge Web Credentials). Every authentication anomaly is worth a one-line answer to “which technique does this look like” because it gives the rest of the SOC a shared vocabulary.
Cloud-identity patterns you’ll see today
Modern intrusions disproportionately route through identity-provider abuse rather than endpoint compromise. The four patterns below dominate Microsoft Entra ID, Okta, and Google Workspace incidents you’ll triage today:
🔑 OAuth consent-grant abuse
The attacker registers a malicious application and tricks a user into granting it OAuth permissions (often Mail.Read, Files.ReadWrite, offline_access). No password is stolen; the consent itself is the foothold. Detect via consent-grant audit events with unusual app publishers, broad scopes, or recent app-registration ages. Maps to T1528 Steal Application Access Token.
🎫 Token replay / forged tokens
An attacker presents a stolen or forged bearer/refresh token to bypass primary authentication and MFA. The token may be lifted from a compromised endpoint, stolen via AiTM phishing, or forged using a stolen signing key (the Storm-0558 pattern). Detect via token-binding anomalies, unusual aud claims, sign-ins with no associated interactive login, and refresh-token usage from new locations. Replaying the token maps to T1550.001 Application Access Token; forging it maps to T1606 Forge Web Credentials.
🌍 Impossible travel
The geolocation signal from step 01, scored provider-side: Entra ID Identity Protection and Okta ThreatInsight flag it directly, so it often arrives pre-detected. Treat as a strong but not conclusive signal: VPN, mobile-carrier routing, and travel-while-active can produce false-positives. Maps to T1078.004 Valid Accounts: Cloud Accounts.
📲 Device-code phishing and AiTM session theft
The OAuth 2.0 device-authorization flow is exploited by attackers prompting the user to “enter this code on your other device” while the attacker’s device receives the token. Adversary-in-the-middle (AiTM) toolkits (EvilProxy, Tycoon) sit between user and IdP, capturing session cookies after legitimate MFA. Both defeat OTP and push-based MFA; phishing-resistant FIDO2 stops the AiTM credential replay, which is exactly why attackers pivot to flows like device code that sidestep it. Detect via unusual device-code grants, new-device sign-ins right after MFA succeeds, and session-cookie use from IPs the user never authenticated from. Maps to T1528 Steal Application Access Token (device-code phishing, with the stolen token replayed via T1550.001 Application Access Token) and T1539 Steal Web Session Cookie (AiTM).
The on-prem counterpart: Kerberos tickets and AD delegation
Cloud flows get the attention, but most enterprises still run Active Directory, where authentication is ticket-based: a logon yields a Ticket Granting Ticket (TGT), and the TGT buys service tickets for each system the account touches. Two Subject-relevant consequences. First, tickets are credentials: a stolen TGT impersonates the account until it expires with no password ever touched, and a Kerberoasting burst (many RC4 service-ticket requests for SPN-bearing service accounts) is credential theft in progress. Second, delegation is a trust path: a service configured for unconstrained delegation holds the TGTs of everyone who authenticates to it, so “web server compromised” can quietly mean “the admin who logged in last week is captured too.” When the entity lives in AD, its delegation configuration and recent ticket-grant pattern belong on the relationship map alongside group memberships.
Authorization
Authorization asks whether the action the entity took was permitted, and whether the permissions themselves are appropriate.
The dimension is easy to under-evaluate. An action that maps cleanly to the user’s role looks fine in a glance. The deeper question is whether the role grants too much, or whether the role was modified recently to permit this exact action.
Permission mapping
Define expected access via a centralized RBAC Role-Based Access Control. A model where permissions are granted to roles rather than to individual users, and users inherit permissions by being assigned roles. RBAC makes access reviewable at the role level rather than per-user. matrix. Periodic entitlement reviews confirm each role still matches its function.
Privilege management
During triage, evaluate whether the entity’s actions exceed its assigned privilege level. Look for elevation, excessive grants, or chained permissions that effectively make the role admin.
Toxic access pairings
Two permissions that are reasonable individually but dangerous together. The classic finance case: someone with both “approve invoice” and “modify vendor bank account.” Each is normal in a role; the combination is fraud risk.
Administrative oversight
Flag administrative activity that happens outside approved change windows. Investigate shared account use or service accounts performing interactive actions; both indicate a workflow that did not follow policy.
Tiered access classification
Authorization analysis works better when the organization maintains a tiered data classification model that maps to access boundaries. Building that model is data-governance and security-program work, done long before any alert fires; the analyst’s job is to know whether one exists and read the alert against it. A common pattern:
- Tier 0, Crown jewels. Customer data, financial records, source code for critical systems, secrets. Access is logged, peer-reviewed, and time-bound.
- Tier 1, Sensitive operations. Production Infrastructure The systems, networks, and services that computing runs on. In triage the word points two directions: the organization's infrastructure is what alerts fire on, and attacker infrastructure is the set of C2 servers, domains, and staging hosts an adversary operates, which pivoting on indicators is meant to map. , payment workflows, employee data. Access requires explicit role assignment and is reviewed quarterly.
- Tier 2, Standard business. Internal collaboration tools, project workspaces, day-to-day applications. Default access for the role.
- Tier 3, Open. Public-facing or non-sensitive information. Unrestricted: any authenticated employee can reach the internal portion, and the rest is public by design.
When an alert touches an entity’s Tier 0 access, Authorization gets weighted differently than the same alert on Tier 3 access. Where no classification model exists, the analyst approximates the same question by hand for the specific access in front of them: how bad would this be if it were hostile?
Behavior
The behavior dimension compares current activity to the entity’s historical norm: not “is this unusual in the environment” (the Alert chapter’s question) but “is this unusual for this specific identity.” This dimension is deep enough that it has its own sub-page. The behavioral framework covers the full workflow, from establishing baselines to peer-group comparison; the four signals below are the short version, worth checking on every entity even when the full framework is not warranted.
Baseline comparison
What does this entity normally do? When? With whom? Sudden access to unfamiliar sensitive systems, operating outside normal hours, or repeating tasks at unusual cadence are all baseline deviations worth investigating.
Privilege misuse
Actions that suggest elevation or misuse of existing permissions. The entity is allowed to do this, but the way they are doing it (volume, target, timing) is inconsistent with the role’s intent.
Access scope drift
Gradual expansion into new systems, tools, or data categories outside the entity’s historical norm. Each step alone looks like onboarding. The trajectory is the signal.
Behavioral staging
Methodical but slow deviations: low-risk systems explored before high-value ones, file collection before exfiltration. Each step normalizes the next.
Relationships
The relationships dimension maps the connections between the entity and other identities, systems, and data. Compromise rarely lives in one identity. It lives in the graph the identity participates in.
What relationships look like in telemetry
- Communication patterns. Who this entity emails, messages, or shares documents with.
- Authentication graph. Which systems this entity logs into, and which other entities log into the same systems.
- Access dependencies. Which downstream services this entity’s actions affect (a developer who deploys → which production systems get changes).
- Trust relationships. Federated identity providers, service principals the entity assumes, API keys the entity owns.
Four steps of relationship mapping
Relationship Mapping The process of identifying and visualizing connections between entities like users, systems, or processes. is its own small methodology, and its four steps split across two altitudes. Step 01 is platform work: the connection graph is assembled by the identity and analytics layer (the IdP, the SIEM, UEBA tooling) before any alert fires, and no analyst builds it per-case. Steps 02 through 04 are the triage moves, run as queries against that pre-built graph for the entity in question. Knowing which altitude you are at keeps a junior from reading step 01 as their job at minute 12.
Analyze connections program layer
The environment maintains a map of relationships between users, systems, and data, built by linking identities and entities across telemetry. This baseline captures normal communication and access patterns. At triage, the analyst pulls this entity’s slice of it, or approximates one from IdP and access logs when no platform maintains it.
Identify deviations
Compare current interactions against peer groups and typical workflows to find unauthorized or unusual access attempts. Early detection of these anomalies prioritizes investigation and reduces overall risk.
Measure changes
Monitor changes in communication frequency and volume to identify subtle shifts in behavior. Sudden variations may indicate reconnaissance, insider activity, or preparation for an attack.
Analyze sequences
Study the timing and order of activities to uncover coordinated actions signaling lateral movement or staged attacks. Recognizing these temporal patterns helps connect isolated alerts into a wider incident.
Example: how relationships expose lateral movement
A finance team user authenticates from their laptop at 09:14. Normal. The laptop then authenticates against a Domain Controller A server that responds to security authentication requests in a Windows domain environment. at 09:16. Normal for a typical workday. The domain controller authentication is followed at 09:18 by a successful logon from that same laptop to a developer’s workstation. That is the signal. The finance user’s identity touched a workstation that the user has never interacted with before, and that workstation is in a different department.
Single-entity analysis would have closed this at the laptop. Relationship mapping is what extends the question into “what else does this identity now reach?”
Key Takeaway
The four dimensions are how an entity becomes a profile. Most Subject failures come from skipping a dimension. The strongest Subject assessments work through all four explicitly, even when one of them is obviously fine, because the act of confirming “fine” is the documentation that defends the verdict later.
Next up
Entity types
Every kind of identity has its own analysis pattern. Users, endpoints, applications, services, network identifiers.
Read entity types