The Cyber Kill Chain in Azure: Mapping Attacker Stages to Defender Controls

Last Updated on May 15, 2026 by Arnav Sharma

The Cyber Kill Chain was introduced by Lockheed Martin in 2011 as a framework for understanding how adversaries conduct intrusion campaigns. Fifteen years later it remains one of the most useful mental models in defensive security, not because it describes how every attack works, but because it provides a structured way to ask the most important question in incident response: at what stage could this attack have been stopped?

This article applies the kill chain framework specifically to Azure environments, mapping each stage to the real attack techniques used against Azure infrastructure and the Microsoft Defender controls designed to interrupt them.

---

Why the Kill Chain Still Matters in 2026

Criticism of the kill chain model usually focuses on its origins in APT-style nation-state attacks and its linearity. Real attacks are not always linear. Attackers skip stages, loop back, and operate in parallel. Modern frameworks like MITRE ATT&CK provide more granular technique coverage.

The kill chain’s value in 2026 is not in modelling attacker behaviour with precision. It is in modelling defender investment. Each stage of the kill chain represents a defensive opportunity. An organisation that can interrupt attacks at multiple stages is more resilient than one that relies on a single control at a single stage. When that single control fails, the attack proceeds uncontested.

For Azure environments specifically, the kill chain provides a useful audit: at each stage, does the organisation have a detection and response capability, not just a preventive control?

---

Stage 1: Reconnaissance

What attackers look for in Azure targets

Before attacking an Azure environment, adversaries gather information about the tenant’s structure, exposed services, and identity configuration. Sources include LinkedIn (to identify Entra ID admin accounts and their email formats), Azure service endpoints discoverable via passive DNS, and public GitHub repositories containing Azure resource names, subscription IDs, or accidentally committed credentials.

Shodan and similar tools index Azure-hosted services with open management ports (RDP on port 3389, SSH on port 22, Azure Kubernetes Service API servers) that expose attack surface directly.

Defender control at this stage

Microsoft Defender External Attack Surface Management (EASM) continuously discovers and monitors internet-exposed Azure assets from an attacker’s perspective, surfacing exposed management interfaces, expired certificates, and misconfigured services before they are found by adversaries. It is the reconnaissance stage viewed from the inside out.

The primary hardening actions at this stage are removing all public internet exposure on management ports (replacing with Azure Bastion), auditing GitHub repositories for committed secrets using Defender for DevOps, and reviewing Entra ID conditional access policies to ensure admin account email addresses are not guessable from the organisation’s standard email format.

---

Stage 2: Weaponisation

How attackers prepare Azure-targeting payloads

Weaponisation in Azure attacks typically involves one of three preparation activities: crafting a phishing email containing a reverse proxy link (Evilginx or similar) that captures Entra ID session tokens rather than just credentials, preparing a malicious OAuth application that requests excessive permissions through the Azure consent framework, or building a credential-stuffing list from leaked credential databases matched against the target organisation’s email domain.

AI-assisted weaponisation is measurably present in 2026 attack campaigns. Generative AI tools are used to improve phishing lure quality, draft convincing spear-phishing content, and support faster reconnaissance, reducing the skill barrier for targeted Azure attacks.

Defender control at this stage

Weaponisation is the hardest kill chain stage to defend directly, as it occurs entirely outside the defender’s visibility. The compensating controls are at the next stage (delivery): phishing-resistant authentication that renders session token capture ineffective, and tenant-wide OAuth application consent policies that prevent users from granting permissions to unverified applications.

---

Stage 3: Delivery

Attack delivery vectors targeting Azure tenants

Phishing remains the dominant delivery mechanism. In Azure-targeted attacks, the specific delivery pattern is usually a business email compromise lure directing a target to a Microsoft-themed login page hosted on a compromised domain with a valid TLS certificate. The goal is either credential capture or, in more sophisticated attacks, Adversary-in-the-Middle (AiTM) session token theft that bypasses standard MFA.

The second delivery vector is supply chain compromise through third-party integrations. Organisations that have granted partner or vendor applications delegated permissions in Entra ID provide an indirect delivery path: compromise the vendor, use their legitimate delegated access to reach the target tenant.

Defender control at this stage

Microsoft Defender for Office 365 Plan 2 provides attack simulation training and real-time phishing detection with Safe Links and Safe Attachments. For AiTM attacks specifically, the control is Conditional Access token binding, which limits token reuse to the device and network from which authentication originally occurred, making stolen session tokens significantly less useful to an attacker operating from a different location.

Entra ID’s Cross-Tenant Access Settings provide controls over which external tenants can access your environment via B2B collaboration, directly addressing the supply chain delivery vector.

---

Stage 4: Exploitation

How attackers exploit Azure identity and services

In most Azure attacks, exploitation does not involve a vulnerability exploit in the traditional sense. The most common exploitation mechanism is abuse of legitimate Azure services with legitimate credentials. An attacker who has captured an Entra ID session token has full access to every Azure resource that the token’s account is authorised to access. No CVE, no exploit code, just a valid authenticated session.

When traditional exploitation does occur in Azure contexts, it is usually against Azure VM operating systems (unpatched vulnerabilities on Windows Server or Linux VMs) or against web applications running in Azure App Service.

Defender control at this stage

Microsoft Defender for Endpoint on all Azure VMs and Arc-connected servers provides exploit detection through process tree analysis, memory scanning, and behaviour-based detections. Defender Vulnerability Management provides continuous vulnerability assessment with prioritised remediation guidance.

For identity-based exploitation, Entra ID Protection’s risk detection engine identifies risky sign-ins (unfamiliar location, token replay, impossible travel) and can automatically trigger remediation actions including requiring step-up MFA or blocking the session pending admin review.

---

Stage 5: Installation

Persistence mechanisms in Azure environments

Once an attacker has initial access to an Azure tenant, they establish persistence to survive credential changes and session expiry. In Azure, persistence mechanisms include adding a new owner to an Entra ID application registration (survives the compromised user’s password reset), creating a new Entra ID service principal with credentials controlled by the attacker, modifying Conditional Access policies to exclude attacker-controlled accounts from MFA requirements, and deploying Azure automation runbooks that periodically re-establish access.

The persistence mechanisms that are hardest to detect are those that blend with legitimate administrative activity. A new service principal created during an incident may be indistinguishable from one created by a legitimate administrator, absent a baseline of expected service principal creation activity.

Defender control at this stage

Microsoft Sentinel’s Entra ID connector ingests audit logs that capture every privileged operation in the tenant, including application registration changes, service principal creation, and Conditional Access policy modifications. The key analytics rules are alerts for Conditional Access policy changes outside of change windows, new credentials added to existing service principals, and new owner assignments on high-privilege application registrations.

Entra ID’s Access Reviews provide a periodic mechanism to identify and remove stale or unexpected privileged assignments, including the persistence artifacts an attacker may have left in place.

---

Stage 6: Command and Control

C2 patterns in Azure-targeted attacks

Attackers operating inside an Azure environment use Azure’s own services for command and control, specifically to blend their traffic with legitimate Azure API calls. Common patterns include using Azure Storage blob containers as dead drops for command instructions, using Azure Functions as C2 relay infrastructure, and using legitimate cloud management APIs (Azure Resource Manager) to issue commands to compromised resources.

The challenge in detecting Azure-native C2 is that it generates traffic that looks identical to legitimate Azure administrative operations at the network level. Detection requires behavioural analysis, not signature-based detection.

Defender control at this stage

Microsoft Defender for Cloud Apps (formerly Cloud App Security) provides user behaviour analytics (UEBA) for Azure and Microsoft 365 services, identifying anomalous API call patterns, unusual download volumes from SharePoint or OneDrive, and resource management operations inconsistent with a user’s historical behaviour. Sentinel’s UEBA features provide similar analytics at the tenant level, correlating identity behaviour across Entra ID, Azure Resource Manager, and connected data sources.

---

Stage 7: Actions on Objectives

What attackers do once established in Azure

The attacker’s final objectives in Azure environments typically fall into three categories: data exfiltration (sensitive data from Azure Storage, databases, or Microsoft 365 workloads), ransomware deployment (encryption or exfiltration for extortion), or persistent access for intelligence collection.

Data exfiltration from Azure is the dominant pattern in 2026 as attackers shift from encryption to pure extortion. An attacker with storage account access can exfiltrate terabytes of data using AzCopy or the Azure Storage REST API in ways that generate minimal alerting in environments without anomalous data egress detection.

Defender control at this stage

Microsoft Purview Data Loss Prevention provides policy-based controls that block or audit bulk data movements from SharePoint, Teams, and Exchange. For Azure Storage, Defender for Storage generates alerts for anomalous blob access patterns including large download volumes, access from unfamiliar geographic locations, and access using SAS tokens that are about to expire (a common attacker technique to act before token invalidation).

Azure Private Link and data exfiltration prevention policies in Azure Firewall restrict outbound data movement to approved destinations, removing the public internet as an exfiltration channel for workloads in the network perimeter.

---

The Kill Chain as a Defence Investment Framework

The practical use of the kill chain for security architects is gap analysis across all seven stages. An organisation that has strong controls at stages 3, 4, and 5 but no visibility at stage 7 will detect and stop most opportunistic attacks while remaining vulnerable to a patient attacker who has already established persistence.

The highest-leverage defensive investment, based on current Azure attack patterns, is at stages 3 and 5: delivery prevention through phishing-resistant MFA and AiTM-resistant token binding, and installation detection through Sentinel analytics on privileged Entra ID operations.

Organisations that can answer “how would we detect an attacker at each stage?” with a specific control, alert, and response procedure, rather than a general statement about their security programme, have operationalised the kill chain in the way that actually improves resilience.