EI0.6 The Identity Kill Chain

From reconnaissance to data exfiltration

The traditional cyber kill chain (Lockheed Martin's model) 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 "command and control" is legitimate Microsoft 365 API access.

Understanding each stage reveals two things: first, where your defensive controls should intercept the attack, and second, what evidence each stage produces in the Entra ID logs. The Defense Design Method applies at every stage — each has a specific attack technique, a specific control, and a specific verification query.

Stage 1: Reconnaissance

Before the attacker sends a phishing email or launches a password spray, they gather information about the target organization. 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 login page responds differently depending on whether the account exists in the tenant. An attacker can enumerate valid accounts by submitting email addresses and observing the response — a technique known as user enumeration. Tools like o365creeper and MSOLSpray automate this process, testing thousands of email addresses in minutes. The sign-in logs record these failed authentication attempts, but most organizations do not monitor for the pattern: hundreds of single-attempt failures across many different usernames from the same IP range, each failing with "User does not exist."

// Detect account enumeration — multiple failed sign-ins across many accounts from few IPs
// This pattern indicates reconnaissance or early-stage password spray
SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType != 0                    // Failed sign-ins only
| summarize 
    FailedAccounts = dcount(UserPrincipalName),  // How many different accounts were attempted
    TotalAttempts = count(),                      // Total failed attempts
    AttemptedUsers = make_set(UserPrincipalName, 10)  // Sample of targeted accounts
    by IPAddress
| where FailedAccounts > 10                // Threshold: 10+ different accounts from same IP
| where TotalAttempts > 20                 // With at least 20 total attempts
| order by FailedAccounts desc
// Results: IPs targeting many accounts = likely enumeration or spray
// Normal users fail against 1-2 accounts (typos), not 10+

Stage 2: Initial access

The attacker has identified their targets and chosen their technique. The initial access stage is where the attacker obtains a valid credential or token. This is the stage where the broadest set of defensive controls apply — and where the Defense Design Method has the most impact.

The techniques covered in EI0.5 all operate at this stage: AiTM credential phishing captures the session token after MFA (defeated by phishing-resistant authentication + token protection), password spray guesses common passwords across many accounts (defeated by blocking legacy auth + smart lockout + MFA), MFA fatigue bombards the user with push notifications (defeated by number matching + phishing-resistant auth), and credential stuffing uses credentials from other breaches (defeated by banned password lists + MFA).

Stage 3: Persistence

Within the first few minutes of access, a sophisticated attacker establishes persistence mechanisms that will survive the most common remediation actions. This is the stage that separates a nuisance from a serious incident.

The most common persistence mechanisms in Entra ID environments are inbox rules (forwarding financial emails to an external address — survives password reset), OAuth application consent (granting a malicious app Mail.ReadWrite — survives password reset and session revocation), service principal credential addition (adding a client secret to an existing SP — survives everything unless specifically reviewed), and in advanced attacks, federation trust manipulation (modifying the SAML signing certificate to forge tokens — survives everything including tenant-wide password resets).

Stage 4: Privilege escalation

With persistence established, the attacker escalates to maximize access. The specific techniques depend on the attacker's sophistication and objectives.

At the most basic level, the attacker attempts to add the compromised account to a privileged directory role — Global Administrator provides unrestricted access to the entire tenant. If PIM is not enabled, this is a single Graph API call or a few clicks in the portal. If PIM is enabled, the attacker needs to activate the role, which triggers the additional verification requirements that PIM enforces (MFA, justification, approval). This is why PIM exists — not to prevent privilege escalation entirely, but to add barriers that slow the attacker and produce audit events that detection rules can catch.

Stage 5: Lateral movement

In cloud identity attacks, lateral movement does not look like lateral movement on a network. There is no PsExec, no RDP, no SMB traffic. Instead, the attacker uses the compromised identity's permissions — or newly escalated permissions — to access resources beyond the initial target.

A compromised finance manager's account might have access to the shared finance SharePoint site, the finance team's Teams channels, other team members' shared calendars, and (if the organization uses shared mailboxes) the accounts payable mailbox. The attacker does not need to compromise another user's account to access these resources — the legitimate permissions of the compromised account provide access.

Stage 6: Data exfiltration and impact

The final stage is where the attacker achieves their objective. The specific impact depends on the attacker's motivation: financial fraud (BEC wire transfer manipulation), data theft (downloading sensitive documents), espionage (reading executive communications), or destruction (deleting data, disabling accounts, ransomware deployment).

Business email compromise is the most financially damaging identity attack. The attacker uses the compromised account to insert themselves into an active financial conversation — typically an invoice payment thread — and redirects the payment to an attacker-controlled bank account. The FBI's Internet Crime Report consistently ranks BEC as the highest-loss cybercrime category, with billions of dollars in annual losses. 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 change.

Breaking the chain: where this course intervenes

The kill chain model reveals an important principle: you do not need to stop the attacker at every stage. You need to stop them at one stage — and the earlier, the better.

If you prevent initial access through phishing-resistant authentication and strong conditional access policies, stages 3-6 never happen. If the attacker gets past initial access but your detection rules catch the persistence mechanisms within minutes, the impact is contained. If the attacker establishes persistence but PIM prevents privilege escalation, the blast radius is limited to the compromised user's existing permissions.

This course is designed around this principle. The early modules (EI2 through EI7) focus on preventing initial access and limiting what an attacker can do if they get in. The later modules (EI9, EI10, EI12) reduce the blast radius by governing permissions and access. The detection modules (EI13, EI14) catch anything that gets through the preventive controls. And the capstone (EI17) assembles all of these into a layered architecture where the attacker must defeat multiple controls at multiple stages to succeed.