The Identity Kill Chain

Introduction

An identity intrusion has six stages and you only have to stop one of them. This section is that chain and where it is cheapest to break. You will finish able to place any identity alert on the chain, and to say what stopping it at that stage does and does not contain.

The traditional Lockheed Martin kill chain was designed for network-based attacks against on-premises infrastructure. The identity kill chain adapts this model for cloud identity attacks, where the "network" is the Entra ID authentication endpoint, the "weapons" are stolen credentials and tokens, and the "lateral movement" is API access across Microsoft 365 services. The entire chain, from initial access to data exfiltration, can complete in under 30 minutes. That speed is what makes prevention and early detection so critical, there is no time for manual investigation and approval workflows once the chain is in motion.

Stage by stage, then, and what each one costs to break.

  1  Reconnaissance        largely nothing available
  2  Initial access        phishing-resistant, legacy block, CA
  3  Persistence           consent limits, method registration
  4  Privilege escalation  PIM
  5  Lateral movement      least privilege
  6  Exfiltration, impact  detection and containment

Stage 1 has no defensive answer and it is worth saying so plainly rather than budgeting for one. Stage 2 is the cheapest break and the only one that stops everything downstream.

After that the economics turn. Persistence is low cost and bounds the incident to whatever they reached in minutes. Escalation is moderate and caps the ceiling. Lateral movement is expensive, because it is governance work rather than configuration. And by stage 6 you are responding rather than preventing.

The cost rises down the page while the amount contained falls. That is the whole argument for the deployment order in 0.3, and it is unusual: the cheapest control here is also the most complete.

The two trends in that last line run against each other, which is the useful part. Breaking the chain gets more expensive and less complete the later you do it, so the ordering in 0.3 is not a preference about tidiness, it is where the cheap breaks are.

Before the attacker sends a phishing email or launches a spray campaign, they gather information about the target. Identity reconnaissance in the cloud era is remarkably easy because much of the information is publicly accessible.

The Entra ID login page itself leaks information, when a user enters an email address, the page responds differently depending on whether the account exists. Tools like o365creeper and MSOLSpray automate this, testing thousands of email addresses in minutes. LinkedIn provides the email naming format (firstname.lastname@company.com), department structures (which users are in finance: the most valuable BEC targets), and executive names. Microsoft's autodiscover and federation metadata endpoints reveal whether the organization uses Entra ID, whether federation is configured, and the tenant ID. None of this requires authentication.

The sign-in logs record failed authentication attempts from enumeration, but most organizations don't monitor for the distinctive pattern: hundreds of single-attempt failures across many different usernames from the same IP range, each failing with error code 50034 ("User account not found"). The defensive controls at this stage are limited, smart lockout throttles rapid-fire attempts, and the login page can be configured to return generic errors. The real defense at this stage is detection: knowing that enumeration is happening gives you time to heighten monitoring and alert your SOC before the attacker moves to initial access.

Three things make reconnaissance free, and none of them is a misconfiguration.

The sign-in page itself distinguishes a valid username from an invalid one by how it responds, so enumeration needs no credential and produces no failure to alert on. Public records answer tenant existence, federation settings and domain configuration from unauthenticated endpoints, by design. Your own staff publish names, roles and email format on a professional network, which is a business requirement rather than a leak.

What that means for the budget is the point of the section. Reconnaissance is not a stage you defend. It produces no alert worth writing, and effort spent here is effort not spent on stage 2, where the same money stops the whole chain.

Per ei01 what is worth watching is enumeration at volume from one source, and that is a spray precursor rather than reconnaissance in itself.

// EI0.5: username enumeration at volume from one source
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 50034      // user does not exist in the directory
| summarize Tried = dcount(UserPrincipalName) by IPAddress
| where Tried > 20
| order by Tried desc
// 50034 means the name was wrong, so these are guesses, not failures

This is the only stage with no defensive answer, and naming that is more useful than pretending otherwise.

Being explicit about this saves real effort. A stage with no available break should not carry a control, and the honest output of stage 1 is to accept it and spend the attention on the stage where a break stops everything after it.

Read the timeline below before going further. Severity has to be assessed now.

The stage decides the response. Per 0.5 four events in twenty-nine minutes each look minor alone, and the last one is the marker that changes what revoking the session would achieve.

The attacker obtains a valid credential or token using one of the techniques from Section 0.4. AiTM captures the session token after MFA completes, defeated by phishing-resistant authentication and token protection. Password spray guesses common passwords against legacy protocols, defeated by blocking legacy authentication and requiring MFA. MFA fatigue bombards the user with push notifications, defeated by number matching and phishing-resistant methods. Device code flow abuse tricks users into authenticating on the attacker's behalf, defeated by blocking device code flow in Conditional Access.

The sign-in log evidence at this stage is the most actionable. A successful sign-in from a new location, a new device, or an unfamiliar IP address, especially when combined with a risk detection from Identity Protection, is the primary indicator. The SigninLogs table records the authentication method, device details, IP address, location, risk level, and every Conditional Access policy that was evaluated. Identity Protection's RiskLevelDuringSignIn field distinguishes between no risk, low, medium, and high. A medium-risk successful sign-in to a finance account at 3 AM from an IP that has never appeared in your tenant is precisely the signal that should trigger an investigation.

The time window at this stage determines the severity of the incident. From the moment the attacker obtains a valid token, the clock is running. Microsoft's data shows that sophisticated attackers begin persistence activity within 5 minutes of initial access. If your Conditional Access policies block the sign-in or your detection rules fire within minutes, the attack is contained at initial access. If the attacker has 30 minutes of undetected access, they will have established persistence, and the incident becomes a multi-stage compromise requiring remediation across mailbox rules, application consent, and potentially directory roles.

Four things happen at this stage and three of the four are answered by configuration rather than detection.

AiTM session capture is answered by phishing-resistant methods and token protection, per ei02 and ei07. Password spray against legacy protocols is answered by blocking legacy authentication first, because legacy bypasses Conditional Access rather than failing it. MFA fatigue is answered by number matching, then by phishing-resistant methods.

The consent grant is the one that breaks the pattern. It is answered by consent restrictions, per ei09, and no credential is involved anywhere in it, so nothing about authentication strength reaches that row at all.

This is the stage where the chain is cheapest to break, which is the same conclusion the cost column reached from the other direction.

// EI0.5: sign-ins on legacy protocols, which bypass CA entirely
SigninLogs
| where TimeGenerated > ago(30d)
| where ClientAppUsed !in ("Browser", "Mobile Apps and Desktop clients")
| summarize Sign-ins = count(), Users = dcount(UserPrincipalName)
    by ClientAppUsed
| order by ['Sign-ins'] desc
// Any row here is a population no policy evaluated

The distribution across those rows is the point. Three of the four are answered by configuration and one by governance, and none of them is answered by detection, which is why stage 2 is where a deployment gets the most return for the least work.

Within minutes of gaining access, a sophisticated attacker establishes mechanisms that survive the most common remediation actions. This is the stage that separates a nuisance from a serious incident, and it's the stage that most incident response playbooks handle poorly.

Inbox rules forwarding financial emails to an external address survive password resets: the rule operates on incoming mail regardless of how the user authenticates. The attacker creates a rule targeting keywords like "invoice," "wire transfer," "payment," or "bank details" with a forwarding action to an external mailbox. The user sees no evidence of the rule unless they specifically check the rules list.

OAuth application consent grants giving a malicious app Mail.ReadWrite permissions survive password resets and session revocations. The application authenticates with its own credentials through the client credential flow, it never uses the user's password or session at all. The only way to remove this persistence is to explicitly revoke the consent grant in the Enterprise Applications blade.

Service principal credential additions survive everything unless specifically reviewed. The attacker adds a new client secret or certificate to an existing service principal that already has broad permissions. They then authenticate as that service principal independently. The original user's password could be changed a hundred times and the service principal access continues unaffected.

The audit log records every one of these actions, New-InboxRule, Consent to application, Add service principal credentials. The challenge is that they look like legitimate activity unless correlated with the initial access event. This is what a malicious consent grant looks like in the raw audit data:

{
  "ActivityDisplayName": "Consent to application",
  "Category": "ApplicationManagement",
  "Result": "success",
  "InitiatedBy": {
    "user": {
      "userPrincipalName": "c.walker@contoso.com"
    }
  },
  "TargetResources": [
    {
      "displayName": "Teams Productivity Suite",
      "modifiedProperties": [
        {
          "displayName": "ConsentAction.Permissions",
          "newValue": "\"Mail.ReadWrite, Files.Read.All, User.Read\""
        }
      ]
    }
  ],
  "ActivityDateTime": "2025-11-14T09:31:42Z"
}

Eight minutes after the initial AiTM sign-in, the same user grants Mail.ReadWrite and Files.Read.All to an application called "Teams Productivity Suite." The name looks plausible. The permissions are excessive for a productivity tool. This consent grant creates an independent access path that survives every remediation action short of explicit revocation. ARC406 teaches the correlation: anomalous sign-in + persistence action within a short window = high-confidence compromise.

Which is the arithmetic the last section makes explicit.

Four persistence mechanisms, and their common property is the finding.

Registering an additional MFA method puts the attacker's own authenticator on the victim's account, and it survives a password reset completely. A consent grant survives reset and session revocation, per 0.4, because it belongs to an application. A mailbox rule or delegation keeps access to the conversation after the account is secured. An application secret is an identity with no user, no MFA and no interactive logon to alert on, per ei10.

None of the four is a credential. So the standard response of reset and revoke removes none of them, and each has to be looked for specifically, by somebody who knows it exists.

That is why an identity incident does not end when the password changes, and why the closing checklist for one is longer than the closing checklist for an endpoint.

The common property is what makes this stage worth its own checklist. Every item here is persistence that a credential action cannot remove, so an incident closed after a reset and a revocation has addressed the entry route and left the way back open.

With persistence established, the attacker escalates to maximize access. The simplest escalation is adding the compromised account to a privileged directory role. Global Administrator provides unrestricted tenant access. Without PIM, this is a single Graph API call. With PIM, the attacker needs to activate the role, triggering additional verification requirements that produce audit events and create time for detection.

More sophisticated attackers skip role escalation and modify Conditional Access policies instead, adding their IP to a trusted named location, or changing a blocking policy to report-only mode. These modifications are recorded in the audit log as "Update conditional access policy": a routine event in tenants with active security teams. The detection challenge is distinguishing the attacker's policy modification from a legitimate administrator's. EI8 covers Conditional Access change management and the detection rules that catch unauthorized modifications.

The most sophisticated attackers target the application layer. They create application registrations with application-level permissions. Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, Mail.ReadWrite, that don't require user context and don't appear in user sign-in logs.

Without PIM, adding the compromised account to a privileged directory role is a single Graph API call. The privilege was standing, so taking it requires no exploit at all.

With PIM the role is eligible rather than active, so the attacker has to activate it: an approval, a justification, and an audit entry, per ei06. Not impossible. Expensive and loud.

What to watch is the audit log rather than the sign-in log, per ei01: role assignment, group membership change, permission grant, and whether a change record exists for any of them.

It looks legitimate because it is legitimate administration, performed by an account entitled to perform it. The discriminator is contextual: whose account, from where, against which approved change.

// EI0.5: privileged role grants, and who made them
AuditLogs
| where TimeGenerated > ago(30d)
| where Category == "RoleManagement"
| where OperationName startswith "Add member to role"
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| extend Role = tostring(TargetResources[0].displayName)
| extend ViaPIM = OperationName has "PIM"
| project TimeGenerated, Actor, Role, ViaPIM
| order by TimeGenerated desc
// ViaPIM false on a tier-one role is the row this stage is about

PIM does not prevent escalation. It converts a silent action into one that leaves a trail.

That reframing is the honest case for PIM. It does not stop a privileged account being taken, it removes the standing privilege that made taking it silent, so the attacker still gets there and now has to generate an approval and an audit record on the way.

In cloud identity attacks, lateral movement doesn't look like lateral movement on a network. There's no PsExec, no RDP, no SMB traffic. The attacker uses the compromised identity's existing permissions, or newly escalated permissions, to access resources beyond the initial target.

A compromised finance manager's account might have legitimate access to the shared finance SharePoint site, the finance team's Teams channels, shared calendars, and the accounts payable mailbox. The attacker doesn't need to compromise another account: the legitimate permissions provide the access path. With escalated privileges, the scope expands: Exchange Administrator can access any mailbox, SharePoint Administrator can access any site collection, and an application with Mail.ReadWrite can read every user's email.

The evidence is in the OfficeActivity and CloudAppEvents logs, file access patterns, mailbox access, and Teams activity that deviates from the user's baseline. If you know the user normally accesses three SharePoint sites and their own mailbox, access to the CEO's mailbox and the finance team site at 3 AM from a foreign IP is immediately anomalous. The challenge is that many organizations don't have behavioral baselines established, they can't distinguish anomalous access from normal access because they've never defined what normal looks like. EI1 builds this baseline from sign-in logs, and ARC406 covers the governance that keeps permissions matching actual job requirements rather than accumulated access from prior roles.

Lateral movement here is not what the phrase usually means. There is no PsExec, no RDP, no SMB, no network traffic to inspect. Every endpoint control in ARC402 sees nothing, because nothing happens on an endpoint.

What it is instead is the compromised identity using permissions it already had, or ones just escalated to, against other resources: mailboxes, sites, subscriptions.

It is hard to detect because each access is authorized. The identity is entitled, the platform agrees, and per 0.3 the chain hands the next link a fact that is true.

What answers it is least privilege on what the identity can reach at all, per ei12, which is governance work and the most expensive break on the page.

// EI0.5: one identity, many resources, all of it authorized
OfficeActivity
| where TimeGenerated > ago(7d)
| where Operation in ("MailItemsAccessed", "FileAccessed", "FileDownloaded")
| summarize Resources = dcount(OfficeObjectId), Ops = count(),
    First = min(TimeGenerated), Last = max(TimeGenerated) by UserId
| where Resources > 50
| order by Resources desc
// Every row is permitted. The shape is the finding, not any single access

This is the stage where the endpoint course has nothing to contribute, and it is a large part of why both courses exist.

That absence is worth naming precisely. Cloud lateral movement produces no endpoint artifact at all, so an estate with excellent endpoint telemetry and no identity governance can watch an intrusion move across its tenant without a single device reporting anything unusual.

The attacker achieves their objective. The specific impact depends on motivation: financial fraud, data theft, espionage, or destruction.

Business email compromise is the most financially damaging identity attack: the FBI's Internet Crime Report consistently ranks BEC as the highest-loss cybercrime category, with billions of dollars in annual losses. The attacker uses the compromised account to insert themselves into an active invoice payment thread and requests a bank detail change for the next payment. The attack succeeds because the email comes from a legitimate internal account, the conversation thread is real, and the request appears to be a routine payment detail update.

Data exfiltration through SharePoint and OneDrive is the most common data theft method. The attacker downloads files at scale using the OneDrive sync client, Graph API calls, or bulk SharePoint export. The OfficeActivity logs record every file operation, and detection rules in ARC406 monitor for unusual download volumes.

Automatic attack disruption in Defender XDR is Microsoft's response to the speed of these attacks. When Defender XDR detects an in-progress attack with high confidence, correlating identity signals with behavior signals like inbox rule creation followed by mass file download, it can disable the compromised account and revoke all sessions without waiting for a human analyst. This reduces response time from hours to seconds, but it depends on detection signals being available and the automation being correctly configured. ARC406 covers this integration.

// Detect persistence: inbox rules created shortly after anomalous sign-in
// Correlates initial access (stage 2) with persistence (stage 3)
let anomalous_signins = SigninLogs
    | where TimeGenerated > ago(24h)
    | where RiskLevelDuringSignIn in ("medium", "high")
    | where ResultType == "0"
    | project SignInTime = TimeGenerated, UserPrincipalName, IPAddress, RiskLevelDuringSignIn;
OfficeActivity
| where TimeGenerated > ago(24h)
| where Operation == "New-InboxRule"
| join kind=inner anomalous_signins on $left.UserId == $right.UserPrincipalName
| where TimeGenerated > SignInTime
| where TimeGenerated < SignInTime + 2h
| project UserPrincipalName, SignInTime, RiskLevelDuringSignIn, RuleCreatedTime = TimeGenerated, Operation

This query is a preview of the detection methodology in ARC406. It correlates two stages of the kill chain: a risky sign-in (stage 2) followed by inbox rule creation within two hours (stage 3). A user who signs in from an anomalous location and immediately creates a forwarding rule matches the AiTM→BEC pattern precisely. This correlation, initial access signal plus persistence action within a time window, is the foundation of identity detection engineering.

You don't need to stop the attacker at every stage. You need to stop them at one stage, and the earlier, the better. The math is straightforward: preventing initial access stops the entire chain. Detecting persistence limits the blast radius to what the attacker accessed in their first few minutes. Blocking privilege escalation confines the damage to a single user's existing permissions.

If phishing-resistant authentication prevents initial access, stages 3 through 6 never happen. The user clicks the phishing link, the proxy page presents the sign-in flow, the FIDO2 key rejects the domain: no token is issued, no access is granted. The attack is over before it begins. This is why authentication methods (EI2) are the first deployment priority.

If the attacker gets past initial access, because a user without phishing-resistant credentials was targeted, but detection rules catch the persistence mechanisms within minutes, the impact is contained to a single compromised mailbox. The SOC revokes sessions, resets the password, reviews and removes any inbox rules or consent grants, and the incident is a contained compromise rather than a breach.

If persistence succeeds but PIM prevents privilege escalation, the blast radius is limited to the compromised user's existing permissions. The attacker can access what that user can access, but they can't access other mailboxes, modify policies, or gain administrative control.

This course follows this principle. EI2 through EI7 focus on preventing initial access and limiting what an attacker can do. EI9 reduces the blast radius by governing application permissions, and ARC406 continues that into workload identity and lifecycle governance. Detection catches what gets through, and it is also ARC406. architecture where the attacker must defeat multiple controls at multiple stages to succeed.

Read the two columns against each other. Stopping at stage 4 contains the ceiling but not what the original identity could already reach. Stopping at stage 5 contains the spread but not the access already held. By stage 6 the data has moved and containment is not the word for what you are doing.

You do not need to break every stage. Breaking one is enough, and the cheapest break is also the most complete, which is unusual enough to build a plan around rather than a nice observation.

The alignment in that last line is what makes the chain useful rather than just descriptive. The cheapest place to break it is also the place that contains the most, so the deployment order that follows from the chain is the same one 0.3 derives from the component dependencies, arrived at from a completely different direction.

The chain is only useful if you can place a real alert on it, which is one question rather than an analysis.

An identity intrusion has six stages and you only need to break one. Stage 1 has no available break, because enumeration is inferable from public behavior and produces no failure, so naming that is more useful than pretending to defend it. Stage 2 is where the chain is cheapest to break and three of its four routes are answered by configuration rather than detection. Stage 3 is why an incident does not end when the password changes, since an added MFA method, a consent grant and a mailbox rule are all persistence that no credential action removes. Escalation is a single Graph call where privilege is standing, and PIM does not prevent it so much as convert a silent action into one that leaves a trail. And the cheapest break is also the most complete, which is what makes the order worth planning around.