The Identity Kill Chain

From reconnaissance to exfiltration

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 1: Reconnaissance

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.

Stage 2: Initial access

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.

Stage 3: Persistence

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. EI13 teaches the correlation: anomalous sign-in + persistence action within a short window = high-confidence compromise.

Stage 4: Privilege escalation

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.

Stage 5: Lateral movement

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 EI12 ensures that permissions reflect actual job requirements rather than accumulated access from prior roles.

Stage 6: Data exfiltration and impact

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 EI13 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. EI16 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 EI13. 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.

Breaking the chain

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, EI10, and EI12 reduce the blast radius by governing permissions. EI13 and EI14 catch anything that gets through. EI17 assembles everything into a layered architecture where the attacker must defeat multiple controls at multiple stages to succeed.