The four dimensions of Subject analysis
On this page
Every entity in the alert deserves a balanced read across four dimensions. The dimensions are not a checklist; they are the questions that prevent a Subject assessment from missing something obvious.
How the dimensions work together
The four dimensions are independent questions about the same entity 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 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 1,600 km (1,000 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 with no matching HR or provisioning record (or one that was supposed to be off-boarded last week) is its own story. Asking the user is a contact with rules of its own: see Talking to people during triage.
Investigate the session
Map the authentication path: source IP, intermediate identity providers, MFA Multi-Factor Authentication (MFA) Security system requiring two or more verification methods to grant access, combining something you know, have, or are. Not all MFA is equal. OTP codes, SMS and push approvals can be relayed by adversary-in-the-middle phishing proxies, worn down by push bombing (MFA fatigue), or bypassed by SIM swap and help-desk resets. A stolen session token skips MFA entirely. Phishing-resistant factors (FIDO2 security keys, passkeys, certificate-based auth) bind the login to the real site's origin and defeat AiTM. In triage, "MFA was satisfied" is evidence about the factor, not about the person. outcome, session tokens issued. Look for unusually long sessions or the same token Token A piece of data a system accepts as proof of an authenticated session or a granted permission. Several senses: hardware or OTP token (an authentication factor); session cookie; OAuth access and refresh tokens; Entra Primary Refresh Token; Windows access token (the security context of a process). Triage-critical: a stolen session or refresh token replays without the password or MFA (AiTM phishing, infostealers), so containment means revoking sessions and refresh tokens, not only resetting the password. presented from more than one location, the usual sign of a hijacked session. Anomalies in any of these reshape the assessment. Know what a reset does and does not end: a password reset alone does not reliably revoke refresh tokens, session cookies, or Kerberos tickets already issued. Access tokens stay valid until they expire (60 to 90 minutes by default in Entra ID) unless the resource enforces Continuous Access Evaluation. Refresh tokens last far longer (up to 90 days by default in Entra ID, renewed each time they are used), and a Kerberos ticket-granting ticket lasts 10 hours by default, renewable for up to 7 days. A compromised identity can still be live after its password changes, so revocation is explicit and verified.
Investigative techniques
Each technique below 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. Impossible travel often arrives pre-scored by the identity provider (Microsoft Entra ID Protection’s Atypical travel and Impossible travel, Okta’s Velocity behavior), depending on licensing and configuration. Treat it as strong but not conclusive: VPN egress and in-flight Wi-Fi produce it too.
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 Password Spraying Trying a small number of common passwords against many accounts to avoid lockouts. (many accounts hit with the same common password Password A shared secret used to authenticate. A correct password proves only that someone had it: passwords are phished, reused, sprayed and sold from infostealer logs. A password reset alone does not evict an attacker who holds a session or refresh token. See Token. ) often surface as many accounts each failing once or twice from the same source: Windows event 4625 (failed logon) on the target host, 4771 or 4776 on domain controllers, or Entra ID sign-in error 50126 and Okta failed-authentication events in the cloud. Per-account lockout thresholds miss the pattern, because no single account fails often.
Network source inspection
Identify logins from anonymizers, Tor exit nodes, and known hostile infrastructure, but a clean residential IP proves nothing: attackers rent residential proxy networks precisely to blend in with home broadband (Midnight Blizzard did this against Microsoft). Frequent source-IP change is weak on its own, because mobile carriers, CGNAT, privacy relays such as iCloud Private Relay, and SASE/ZTNA egress all produce it. Corporate egress cuts the other way: behind a VPN concentrator or a forward proxy, every remote user appears to sign in from the same few company addresses, so a “known” IP proves little too. Weigh it alongside device and session continuity.
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. Number matching blunts plain push fatigue, so attackers now pair the prompts with a phone call that talks the user through approving, or with a help-desk reset.
MFA method and device registration
Above all, check for MFA methods or devices registered or changed around the alert (the Entra ID audit activity “User registered security info”, the Okta event user.mfa.factor.activate). Attackers enroll their own authenticator immediately after a phish or a help-desk reset, and the new method survives a password reset (T1098.005 Device Registration). A method the user did not ask for triggers the identity-persistence sweep, which checks the other anchors an attacker leaves behind.
Mapping to MITRE ATT&CK
The ATT&CK techniques most worth recognizing in Authentication, with what each tends to look like in the logs. 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. IDs current as of ATT&CK v19.2 (August 2026).
| Technique | ID | What it looks like in logs |
|---|---|---|
| Valid Accounts, including Cloud Accounts | T1078, T1078.004 | A successful sign-in with the right password and MFA, from a device, location, or ASN the account has never used. Nothing fails. |
| Brute Force: Password Spraying | T1110.003 | Many accounts, one or two failures each, from one source or a rotating proxy pool. |
| Brute Force: Credential Stuffing | T1110.004 | Many accounts, each tried with a different leaked password; a high failure rate with scattered successes. |
| Modify Authentication Process | T1556 | Audit-log changes to authentication policy, federation settings, or authentication modules, not sign-ins. |
| Multi-Factor Authentication Request Generation | T1621 | Repeated push prompts denied or ignored, then one approval (MFA fatigue). |
| Steal Web Session Cookie | T1539 | An interactive, MFA-satisfied sign-in from an adversary-in-the-middle proxy’s IP, carrying the user’s own credentials. |
| Use Alternate Authentication Material: Web Session Cookie | T1550.004 | The same session presented from a new IP and device with no authentication event. |
| Use Alternate Authentication Material: Application Access Token | T1550.001 | Non-interactive sign-ins or API calls on a token, from an IP or client the user never authenticated from. |
| Forge Web Credentials | T1606 | Tokens accepted with no matching sign-in at the identity provider at all, as when a token is forged from a stolen signing key (the Storm-0558 pattern). |
| Account Manipulation: Device Registration | T1098.005 | A new MFA method or device registered shortly after a risky sign-in or a help-desk reset. |
Cloud-identity patterns you’ll see today
Exploited vulnerabilities are now the most common way in (31% of breaches in the 2026 Verizon DBIR), but credential and session abuse shows up somewhere in a large share of breaches (roughly four in ten, by industry summaries of the same report), and much of it runs through the identity provider. Subject does not need the protocol mechanics to triage these. It needs to recognize the pattern and know which entity the pattern adds to the map. The field-level depth (sign-in log anatomy, the device-code and session-replay signals, role-assumption chains) lives in Cloud and identity logs.
| Pattern | What it adds to the Subject map | ATT&CK |
|---|---|---|
| OAuth consent-grant abuse | An application identity with its own grant and refresh tokens, consented by the user or from a hijacked session. Password resets and MFA changes do not touch it (see OAuth apps). New secrets or certificates added to an existing app are the same pattern from the other side. | T1528, T1671; T1098.001 |
| AiTM Adversary-in-the-Middle (AiTM) A phishing technique in which a kit relays the victim's real sign-in through an attacker-run proxy, capturing the password and the session cookie the identity provider issues after MFA. The attacker then replays the cookie from their own infrastructure, so MFA is satisfied once, by the victim, and never asked again. Push, SMS and OTP factors do not stop it; phishing-resistant factors (FIDO2 security keys, passkeys) do, because they are bound to the real site's origin. Triage tells: a sign-in from a hosting ASN minutes after the user's own, the same session presented from two networks, and a newly registered lookalike domain in the click path. ATT&CK T1557, ATT&CK T1539. session theft | A session born in an interactive, MFA-satisfied sign-in from a hosting IP minutes after a link click, then replayed from somewhere else. Profile the session next to the account; the same proxy IP finds the kit’s other victims. | T1539, then T1550.004 |
| Device-code phishing Device Code Phishing Tricking a user into entering an attacker-generated device code on the real Microsoft or other IdP sign-in page, which hands the attacker tokens for the user's account. No fake site and no password capture are involved. Used at scale by Storm-2372 from 2024. Blocking the device code flow where it is not needed is the main control. | A device-code sign-in the user did not start, often followed by a new device registration. The user authenticates on the genuine page, so phishing-resistant MFA does not stop it; blocking the flow where it is not needed does. | T1528, then T1550.001 |
| Token replay | Non-interactive sign-ins or API calls on a token from an IP or client the user never authenticated from. | T1550.001, T1550.004 |
| Forged tokens and federation Federation Linking identity across independent systems or organizations so that a trusted identity provider authenticates users on behalf of services it does not operate, typically via SAML or OIDC. Matters in triage because every relying service delegates authentication to the identity provider: a compromise there, such as a stolen signing key used to forge assertions (Golden SAML), can mint access to any federated service. trust abuse | Tokens with no matching sign-in at the identity provider at all: minted from a stolen signing key (the Storm-0558 pattern) or through a federated domain or token-signing certificate an admin changed (Golden SAML). The identity provider’s configuration becomes a subject in its own right. | T1606, T1606.002, T1484.002 |
| Kerberos ticket theft and Kerberoasting Kerberoasting Requesting Kerberos service tickets for accounts with SPNs and cracking them offline to recover the service account's password, which then enables privilege escalation, persistence or lateral movement. Since Microsoft's CVE-2026-20833 hardening (enforced April 2026, rollback removed July 2026), domain controllers issue AES service tickets by default to accounts with no explicit msDS-SupportedEncryptionTypes, and AES tickets are far slower to crack. In event 4769, a Ticket Encryption Type of 0x17 (RC4-HMAC) is now a strong signal, and service accounts still explicitly configured for RC4 are the prime targets. (on-premises) | A stolen ticket-granting ticket replayed with no password touched, or one account requesting service tickets (event 4769) for many accounts that carry a service principal name in a short window. AES tickets crack too, so the encryption type does not clear it. | T1550.003, T1558.003 |
Any user who reached the credential step of a phishing kit is credential-exposed until the password is reset, sessions are revoked, and MFA methods are reviewed.
The platform sources for an authentication question (Windows and AD security events, Entra ID and Okta sign-in logs, CloudTrail), with a starting Sentinel query, are in Where to look, by platform. The protocol mechanics behind the patterns above, including Kerberos tickets and AD delegation, are in Identity attacks at protocol depth.
Example: token replay seen only in non-interactive sign-ins
Microsoft Entra ID Protection flags an anomalous token for kpatel. Her interactive sign-in log shows one clean sign-in at 07:58 from her managed laptop, MFA satisfied. Read alone, Authentication looks fine.
The non-interactive sign-in log tells a different story. From 10:41, refresh-token sign-ins for the same account reach Exchange Online and SharePoint from a hosting-provider ASN in another country, with a different device and no interactive sign-in from that address at all. The SessionId on those sign-ins matches the 07:58 session.
Every sign-in “succeeded”, and the Authentication dimension still fails: the credentials passed, but the session is being used from somewhere the user never authenticated. The matching SessionId is what turns the hypothesis of a replayed token (T1550.001) into evidence.
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.
Effective permissions
Look up what the entity can actually do: nested group memberships, inherited cloud policies, active PIM or just-in-time elevations. Compare that against the role’s documented intent. (Building the RBAC 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 and running entitlement reviews is program work; use them if they exist.)
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.
Recent entitlement changes
Check recent changes to the entity’s roles, groups, or access levels. Unauthorized activity shortly after a promotion, a transfer, or off-boarding often reflects privilege misuse or insider risk, and a grant made minutes before the alerting action is a lead in its own right.
Toxic access pairings (segregation-of-duties conflicts)
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. Your GRC or identity governance (IGA) tool may already flag segregation-of-duties violations; check it before reasoning from scratch.
Administrative oversight
Flag administrative activity outside approved change windows. Treat a service account performing interactive actions as a likely compromise until proven otherwise (see Entity types). Shared-account use breaks policy and destroys attribution, so investigate it as both a documentation and a security problem.
Classifying access by sensitivity
Authorization analysis works better when the organization classifies its data, and the systems that hold or move it, by sensitivity. 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:
- Restricted: crown jewels. Customer data, financial records, source code for critical systems, secrets. Access is logged, peer-reviewed, and time-bound.
- Confidential: sensitive operations. Production infrastructure 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.
- Internal: standard business. Internal collaboration tools, project workspaces, day-to-day applications. Default access for the role.
- Public: 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 Restricted access, Authorization gets weighted differently than the same alert on Public 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?
Do not confuse these sensitivity classes with AD and Entra administrative tiering, where Tier 0 means the identity systems themselves (domain controllers, the identity provider, PKI). Any alert touching that tier is critical regardless of data classification.
Where to look: Authorization
| Platform | Sources and events |
|---|---|
| Windows and AD | Security log 4728, 4732, and 4756 (member added to a security-enabled global, local, or universal group); 4720 (account created) |
| Microsoft Entra ID | AuditLogs “Add member to role” and “Add member to group”; PIM role activations; “Consent to application” and app-role assignments for apps |
| AWS | CloudTrail AttachUserPolicy, AttachRolePolicy, PutRolePolicy, UpdateAssumeRolePolicy, CreateAccessKey |
Behavior
The behavior dimension compares the entity’s overall conduct to its own history and its peers. Alert’s validation already asked whether this one signal is normal for the environment and for the entity; Behavior widens the lens from the alerting event to everything this identity has been doing. 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 signals below are a quick pass worth running on every entity even when the full framework is not warranted; the framework page develops baselines and the anomaly families in depth.
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
Misuse of permissions the entity legitimately holds: allowed, but the volume, target, or timing does not match 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.
Where to look: Behavior
Start with whatever already holds the entity’s history: a UEBA entity timeline or peer analytics if the SOC runs one (in Microsoft Sentinel, the BehaviorAnalytics table). Without one, build the comparison by hand and read the alert window against both the entity and its peers.
| Question | Sources |
|---|---|
| Does the alert window match the entity’s own history? | UEBA entity timeline; otherwise a 30-day query of the entity’s sign-ins, process launches, and data access |
| Do its peers do the same? | The same query run for two or three peers in the same role, team, or host class |
| Has its reach been creeping? | First-seen dates per application, host, repository, and data store over the past 30 to 90 days |
| Is it moving more data than usual? | Daily volumes from file and SaaS audit logs, DLP events, and mailbox audit (MailItemsAccessed in Microsoft 365) |
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.
- SSO movement: which additional applications this identity reached through federated sign-in during the window. A burst of first-time SSO app access after a suspicious sign-in is lateral movement across federated identities.
- Access dependencies: which downstream services this entity’s actions affect (a developer who deploys → which production systems get changes).
- Trust relationships: federated identity providers, roles the entity can assume (AWS IAM), service accounts it can impersonate (GCP), service principals or app registrations it owns or holds credentials for (Entra ID), and API keys it owns. Read the trust in both directions: who can become this identity matters as much as what it can become. In Active Directory, delegation is a trust path too: a service configured for unconstrained delegation holds the tickets of everyone who authenticates to it, so “web server compromised” can mean “every admin who signed in to it while their ticket is still valid is captured too.”
Relationship mapping steps
Relationship mapping Relationship Mapping Charting how an entity connects to others (users to hosts, hosts to services, accounts to groups, apps to grants) to see what a compromise could reach. In ASSURED it is the relationships dimension of Subject analysis. See Four Dimensions. is its own small methodology, and its 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. Attack-path tools (BloodHound CE for AD and Entra ID, Cartography or PMapper for AWS, Defender for Identity lateral movement paths) precompute this graph; if your team runs one, query the entity’s outbound paths before building anything by hand. At triage, the analyst pulls this entity’s slice of the graph, 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. Ask: has this entity touched this system before, and do its peers?
Measure changes
Query this entity’s interaction volume and counterparties over the past 30 days and compare the alert window against it: a jump in new counterparties or data volume is the signal, and may indicate reconnaissance, insider activity, or staging 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.
Where to look: Relationships
| Question | Sources |
|---|---|
| What can this identity reach? | The attack-path graph if one exists; group and role memberships; AWS trust policies; Entra ID app ownership and credentials |
| Where did it go through SSO? | IdP sign-in logs grouped by application, first-seen per app |
| Which hosts did it log on to? | Windows 4624 logon type 3 and 10 on the destination hosts; 4648 on the source host |
| Which roles did it assume? | CloudTrail AssumeRole chains (sourceIdentity, role session name); Entra ID AADServicePrincipalSignInLogs and AADManagedIdentitySignInLogs |
Example: how relationships expose lateral movement
A finance team user, dlin, signs in on their laptop at 09:14. Normal. The laptop then authenticates against a domain controller Domain Controller A server that hosts the Active Directory database (NTDS.dit, including every account's password hashes) and runs the Kerberos KDC for its domain. It is Tier 0: an attacker with DC-level access, or replication rights used via DCSync, owns the domain. Any unexpected interactive logon, new service or replication request involving a DC warrants escalation. at 09:16. Normal for a typical workday. At 09:18, a developer’s workstation logs event 4624, logon type 3, with the finance laptop as the source and dlin as the account (or, worse, the finance laptop logs 4648, an explicit-credential logon with an admin account). 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: user accounts, endpoints, applications and services, network identifiers.
Read entity typesTechnical details verified . Product names, defaults and retention change; check your own tenant.