Inside Cloud Attack Paths: End-to-End Adversary Simulation

Inside Cloud Attack Paths: End-to-End Adversary Simulation

Speakers: Mauricio Velazco (Security Research Team Lead, Microsoft)

Conference: BSides NYC

YouTube: https://www.youtube.com/watch?v=vi7YNZH36ik

Overview

In an increasingly cloud-centric world, traditional cybersecurity defenses are proving insufficient against evolving adversary tactics. Mauricio Velazco's talk, "Inside Cloud Attack Paths: End-to-End Adversary Simulation," at BSides NYC, illuminated a critical shift in the threat landscape: attackers are bypassing endpoint detection and response (EDR) solutions by directly targeting cloud APIs and abusing legitimate permissions. This paradigm shift necessitates a deeper understanding of cloud attack paths, which are chains of legitimate steps an adversary takes by leveraging compromised identities and existing entitlements to achieve a malicious objective, without exploiting zero-days or vulnerabilities.

Velazco, a Security Research Team Lead at Microsoft, emphasized the urgent need for both red teams and blue teams to comprehend how these attack paths are constructed, how they can be simulated in lab environments, and what telemetry they generate. The core of his presentation focused on empowering security practitioners with practical, open-source tools he developed: Batcher, for creating realistic cloud attack paths within Azure/Entra ID lab environments, and MS Invader, for performing end-to-end adversary simulations against those environments. The ultimate goal is to enable organizations to validate their security posture, identify blind spots in logging coverage, and develop robust detections against these modern cloud threats.

The talk provides a compelling argument that as organizations rapidly migrate to the cloud, the sheer volume of users, resources, and configurations inevitably leads to the creation of unintended attack paths. These paths, often overlooked, represent significant risk surfaces that attackers are increasingly exploiting. By offering tangible tools and methodologies, Velazco's session serves as a crucial guide for enhancing cloud security by proactively understanding and defending against these sophisticated, yet legitimate, forms of attack.

Background

▶ Watch: Introduction: Cloud attack paths bypassing EDR (0:00)

The foundational premise of understanding cloud attack paths, as explained by Velazco, is that they represent a sequence of actions an adversary takes by abusing compromised identities and legitimate permissions to achieve a specific goal. Crucially, these paths do not rely on vulnerabilities, exploits, or zero-days. Instead, they exploit misconfigurations, overly permissive entitlements, or forgotten access grants that arise naturally in complex cloud environments.

Three core components are essential for the formation of any attack path:

• Who (Security Principles): These are the identities that attackers compromise. This includes users, app registrations, and service principals within a cloud tenant. Compromise often occurs through techniques like password spraying, adversary-in-the-middle attacks, or token theft.
• What (Permissions/Entitlements): These are the privileges that the compromised identities possess. In the Microsoft cloud ecosystem, this encompasses Entra ID roles (formerly Azure Active Directory roles), Azure RBAC roles (Role-Based Access Control), and specific Graph API permissions or other API permissions.
• Targets: These are the valuable resources or data that attackers aim to access or exfiltrate. Examples include mailboxes, databases, Azure Key Vaults, OneDrive files, virtual machines, or entire tenants.

Velazco illustrated this with a classic example: a compromised user, "Bob," who is the owner of an app registration. If this app registration, running as a service principal, has an Azure RBAC role like VM Contributor, an attacker can effectively execute code on any associated virtual machines. If one of these VMs, say "Gibson01," has a managed identity, an attacker executing code on the VM can steal the token of that managed identity. If this managed identity then has access to a storage account containing sensitive files, a complete attack path is formed: Compromised User -> App Registration Ownership -> Service Principal with VM Contributor -> VM Code Execution -> Managed Identity Token Theft -> Storage Account Access -> Sensitive File Exfiltration. This chain highlights how legitimate configurations, rather than vulnerabilities, create the pathway for compromise.

The individual steps within an attack path are termed attack primitives. These are legitimate capabilities, configurations, or permissions that an adversary abuses to move from one step to another. For instance, to exfiltrate emails, an attacker might leverage the Mail.Read permission via the Microsoft Graph API or a corresponding permission through the Exchange Web Services (EWS) API. These are not exploits but standard functionalities that, when combined with the right access, become powerful tools for an attacker. The problem's existence stems from the sheer complexity and scale of cloud deployments, where configurations are constantly changing, and over-provisioned permissions often go unnoticed, creating a fertile ground for these legitimate-abuse attack paths.

Key Findings

▶ Watch: Attack path components: Identities, permissions, targets (3:00)

The central finding presented by Mauricio Velazco is the dramatic shift in adversary tactics towards cloud-native attack paths that leverage legitimate permissions and cloud APIs, effectively bypassing traditional endpoint-focused defenses. This represents a significant evolution from the malware-driven, endpoint-centric attacks of the past decade. Attackers are no longer necessarily "touching endpoints" or relying on EDR evasion; instead, they are operating entirely within the cloud control plane, using tokens and API calls.

Another key finding is the inherent nature of these attack paths: they are predominantly built upon misconfigurations and legitimate, albeit over-privileged, access grants, rather than zero-day exploits. This means that a robust cloud security posture requires a deep understanding of identity and access management (IAM) relationships, resource configurations, and permission inheritance within the cloud environment. The talk underscores that these "vulnerabilities" are often not flaws in the cloud platform itself, but rather in the way organizations configure and manage their cloud resources and identities.

To address this evolving threat, Velazco presented a crucial contribution: the development and open-sourcing of two practical tools, Batcher and MS Invader. These tools represent a significant finding in the realm of proactive cloud security:

• Batcher enables the programmatic creation of realistic, attackable lab environments within Azure and Entra ID. This capability is vital for security teams to move beyond theoretical understanding and build tangible environments where complex attack paths can be observed and studied.
• MS Invader provides the means to simulate end-to-end adversary movements through these created attack paths. Its ability to generate telemetry from these simulations allows blue teams to empirically validate their detection capabilities, identify logging blind spots, and refine their security operations.

In essence, the talk highlights that effective cloud defense requires a proactive, simulation-driven approach that mirrors actual adversary behavior within the cloud's legitimate operational framework. The open-source availability of Batcher and MS Invader democratizes this capability, making advanced cloud adversary simulation accessible to a broader range of security practitioners.

Technical Deep Dive

▶ Watch: Detailed Azure attack path example: VM to storage (4:00)

The technical core of Velazco's presentation revolves around the architecture and functionality of his two open-source tools, Batcher and MS Invader, designed to facilitate the creation and simulation of cloud attack paths within Microsoft Azure and Entra ID environments.

Batcher: Cloud Environment and Attack Path Creation

Batcher is a Python-based tool designed to populate an Azure/Entra ID tenant with a realistic baseline of identities and resources, and then strategically inject specific attack paths. Its configuration is driven by a simple YAML file, allowing users to define the desired scale and complexity of their lab environment.

Environment Generation:

The Batcher YAML configuration allows for the creation of various identity and resource types:

• Identities: Users, applications, service principals, groups, and administrative units. Batcher randomly generates names for these entities to mimic a real-world, albeit synthetic, environment. For example, a configuration might specify num_users: 50 and num_applications: 20.
• Resources: At present, Batcher supports the creation of Virtual Machines (VMs), Storage Accounts, and Key Vaults. These are also given random names and placed in randomly generated resource groups, providing a diverse and plausible environment. For instance, num_keyvaults: 10.

Attack Path Injection:

The most critical feature of Batcher is its ability to inject specific, pre-defined attack paths into the generated environment. These paths are configured within the same YAML file, instructing Batcher on how to establish the necessary relationships, permissions, and secrets to create exploitable chains. Batcher leverages Terraform in the backend to provision and configure these resources and relationships, ensuring idempotency and clear visibility into the infrastructure-as-code.

Velazco detailed four key attack path examples that Batcher can construct:

1. User to Global Admin (via Entra ID Role):

• Initial Access: A user (e.g., "Bob") is designated as the owner of an app registration.
• Primitive 1 (App Ownership Abuse): As an owner, Bob can add credentials (e.g., a secret) to the app registration. This allows Bob to authenticate as the app registration's underlying service principal.
• Primitive 2 (Privileged Role Assignment): The service principal is then granted the Privileged Role Administrator Entra ID role. This role allows the service principal to assign any Entra ID role, including Global Administrator, to any user.
• Goal: The attacker (via Bob and the service principal) can promote any user, or create a new user (e.g., "Lex Luthor"), and assign them Global Administrator privileges, effectively taking over the tenant.

1. User to Global Admin (via Graph API Permission):

• Initial Access & Primitive 1: Similar to the first path, a user is the owner of an app registration, allowing them to authenticate as its service principal.
• Primitive 2 (Graph API Privilege): Instead of an Entra ID role, the service principal is granted the Microsoft Graph API permission AppRoleAssignment.ReadWrite.All. This highly privileged permission allows the service principal to assign any application role (which includes many Entra ID roles) to any other principal.
• Goal: The attacker can use this permission to grant Global Administrator privileges to themselves or another user.

1. User to Email Exfiltration (via Key Vault Secret):

• Initial Access: A user (e.g., "Paul") is granted permission to read a specific Azure Key Vault.
• Primitive 1 (Key Vault Access): The target Key Vault contains a secret (e.g., a client secret or certificate) for an app registration.
• Primitive 2 (App Authentication & Mail Access): By reading the secret from the Key Vault, the attacker can authenticate as the app registration's service principal. If this service principal has the Mail.Read permission, the attacker can then read emails from mailboxes within the tenant.
• Goal: Exfiltrate sensitive emails.

1. User to File Exfiltration (via VM, Managed Identity, Storage Account, and Certificates):

• Initial Access: A user (e.g., "Tom") has permissions to execute code on a Virtual Machine.
• Primitive 1 (VM Code Execution & Managed Identity Token Theft): The VM has a managed identity. By executing code on the VM, the attacker can steal the access token for this managed identity.
• Primitive 2 (Managed Identity to Storage Account): The managed identity has an Azure RBAC role (e.g., Storage Blob Reader) that grants read access to a specific Storage Account.
• Primitive 3 (Certificate Exfiltration & App Authentication): The Storage Account contains certificate files that can be used to authenticate as another app registration's service principal.
• Primitive 4 (Files Access): This final service principal has the Files.Read.All permission, allowing it to read any files from OneDrive or SharePoint.
• Goal: Exfiltrate sensitive files from OneDrive/SharePoint.

Batcher's ability to programmatically create these complex, multi-hop attack paths is invaluable for setting up realistic testing grounds.

MS Invader: End-to-End Adversary Simulation

MS Invader is the complementary tool, an adversary simulation framework that executes end-to-end attack playbooks against the environments created by Batcher (or any other Azure/Entra ID tenant). Like Batcher, it uses a simple YAML configuration file to define the simulation.

Playbook Definition:

An MS Invader playbook specifies:

• Victims: The initial compromised identities (e.g., specific user accounts) from which the simulation will begin.
• Techniques: A sequence of attack primitives to be executed. MS Invader supports approximately 30-40 unique techniques, which map directly to common adversary actions in the cloud (e.g., enumerate_users, add_application_secret, read_email, list_keyvaults, assign_entra_id_role). Each technique is documented on the GitHub repository.

Telemetry Generation and Validation:

The primary objective of MS Invader is to generate realistic telemetry. As it executes each step of a playbook, it interacts with cloud APIs (Graph API, Azure Resource Manager API, etc.), creating logs within the target tenant. This allows security teams to:

• Validate Detections: Test if existing security information and event management (SIEM) rules or EDR/XDR solutions would detect the simulated adversary activity.
• Identify Blind Spots: Discover areas where logging is insufficient or where current detections fail to trigger, highlighting gaps in security posture.

Example Playbooks:

Velazco demonstrated playbooks for the attack paths created by Batcher:

1. Global Admin Takeover Playbook:

• Initial Phase: Assumes a compromised user. The playbook starts with enumeration steps: enumerate_users, enumerate_groups, enumerate_applications (all via Graph API). This generates baseline telemetry.
• Privilege Escalation:
• add_application_secret: The compromised user, as an app owner, adds a new secret to the app registration.
• authenticate_as_application: Authenticates using the newly added secret.
• assign_entra_id_role: As the service principal with Privileged Role Administrator, assigns a powerful role to itself or another entity.
• create_user: Creates a new user account (e.g., "Lex Luthor").
• assign_entra_id_role: Promotes "Lex Luthor" to Global Administrator.

1. Key Vault Email Exfiltration Playbook:

• Discovery: list_keyvaults, get_keyvault_access_policy.
• Secret Access: add_keyvault_access_policy (if needed), read_keyvault_secret.
• Authentication: authenticate_as_application (using the exfiltrated secret).
• Data Exfiltration: read_emails (using the service principal's Mail.Read permission).

MS Invader provides detailed output for each step, including the actions taken and their results, making it easy to trace the simulated attack and correlate it with generated logs. Both Batcher and MS Invader are designed to be practical, user-friendly tools for red and blue teams to proactively test and improve cloud security.

Demo / Proof of Concept

▶ Watch: Understanding attack primitives: Legitimate actions abused (6:00)

Mauricio Velazco's presentation included compelling live demonstrations of both Batcher and MS Invader, showcasing their practical application in creating and simulating cloud attack paths.

The first demo focused on Batcher, starting with an empty Microsoft Entra ID (Azure AD) and Azure tenant. Velazco displayed a batcher.yaml configuration file, which specified the creation of:

• 50 random users
• 20 random applications (app registrations)
• Various groups and administrative units
• 10 resource groups
• 10 Key Vaults
• A few Virtual Machines and Storage Accounts

Crucially, the YAML also included definitions for the four complex attack paths described earlier, instructing Batcher to inject these specific relationships and permissions into the environment.

Velazco then executed the batcher build command, which orchestrates Terraform in the background to provision all these resources and configure the attack paths. While the process typically takes 5-15 minutes, the demo fast-forwarded to show the populated tenant. He then navigated the Azure portal, demonstrating that the tenant was indeed filled with the specified number of randomly generated users, groups, and resources.

To illustrate an injected attack path, Velazco inspected the Terraform output to identify a specific app registration, "cyber director," that was part of the Key Vault-to-email-exfiltration path. He showed that this app registration had the Mail.Read permission. Critically, it had no direct owners, prompting the question of how an attacker could gain access. Velazco then revealed that the Terraform configuration linked this app registration to a specific Azure Key Vault. Batcher had created a secret for "cyber director" and injected it into this Key Vault. Furthermore, Batcher had granted a randomly generated user read access to this specific Key Vault. This completed the attack path: Compromised User -> Key Vault Read Access -> App Registration Secret -> Authenticate as App Registration -> Mail.Read Permission -> Email Exfiltration. This concrete example visually demonstrated how Batcher constructs these multi-stage attack chains using legitimate cloud features. He briefly touched upon the creation of the VM/Managed Identity/Storage Account/Certificates path, highlighting its complexity.

The second demo showcased MS Invader, simulating end-to-end attacks on the Batcher-created environment. The first simulation targeted the "User to Global Admin" attack path. Velazco presented the MS Invader playbook YAML, which outlined steps like enumerating users and applications, adding a new secret to the target app registration (which the assumed compromised user owned), authenticating as the app registration's service principal, assigning the Privileged Role Administrator role, creating a new user "Lex Luthor," and finally promoting "Lex Luthor" to Global Administrator.

Running the MS Invader playbook (assuming a compromised user with no MFA), the demo fast-forwarded through the execution. Velazco then returned to the Azure portal, showing the real-time results:

• The target app registration now had three roles assigned, indicating the programmatic self-assignment.
• A new secret was visible under the app registration's "Certificates & secrets" blade, proving MS Invader had successfully added it via API calls.
• A new user, "Lex Luthor," was present in the Entra ID tenant, and crucially, was assigned the Global Administrator role. This unequivocally demonstrated a full tenant takeover via a legitimate attack path.

The final MS Invader demo focused on the "Key Vault Email Exfiltration" path. Velazco showed the playbook for this scenario, which included steps to list Key Vaults, add an access policy (if needed), read the secret, authenticate as the app registration, and finally, exfiltrate emails using the Mail.Read permission. After running this playbook, the output showed actual emails that MS Invader had successfully read and exfiltrated from mailboxes within the simulated tenant. The Azure portal confirmed that MS Invader had dynamically added an access policy to the Key Vault during the simulation, enabling the secret retrieval.

These demos powerfully validated the utility of both Batcher for creating realistic, attackable cloud environments and MS Invader for performing automated, end-to-end adversary simulations, generating tangible results and invaluable telemetry for defensive analysis.

Defensive Implications

▶ Watch: Introducing Batcher: Open-source tool for creating attack paths (7:50)

The insights and tools presented by Mauricio Velazco carry profound defensive implications for organizations operating in the cloud. As attackers shift their focus from endpoint malware to cloud API abuse and legitimate permission exploitation, blue teams must fundamentally re-evaluate and adapt their security strategies.

1. Shift from Endpoint to Cloud-Native Security: Traditional EDR solutions, while crucial for endpoints, are largely blind to attacks occurring purely within the cloud control plane. Defenders must invest in Cloud Security Posture Management (CSPM), Cloud Workload Protection Platforms (CWPP), and Cloud Native Application Protection Platforms (CNAPP) to gain visibility and control over cloud configurations, identities, and resource access.

1. Prioritize Identity and Access Management (IAM) Hygiene: The core of cloud attack paths lies in abused identities and permissions. This necessitates a rigorous focus on least privilege, ensuring that users, app registrations, and service principals only have the absolute minimum permissions required for their function. Regular audits of Entra ID roles, Azure RBAC assignments, and Graph API permissions are critical to identify and remediate over-provisioned access. Velazco's examples of Privileged Role Administrator and AppRoleAssignment.ReadWrite.All highlight the extreme danger of such broad permissions.

1. Enhanced Logging and Monitoring: To detect these attacks, comprehensive logging across the entire cloud estate is non-negotiable. This includes:

• Entra ID Audit Logs: For identity-related actions (e.g., user creation, role assignments, application secret management).
• Azure Activity Logs: For resource management operations (e.g., Key Vault access policy changes, VM code execution attempts).
• Microsoft Graph API Logs: To capture specific API calls related to data access (e.g., Mail.Read, Files.Read.All).

Defenders must ensure these logs are ingested into a SIEM and retained for sufficient periods.

1. Robust Detection Engineering: With comprehensive telemetry, security teams can develop specific detections for the attack primitives and patterns demonstrated. Examples include:

• Alerting on new application secrets being added to existing app registrations, especially by non-administrative users.
• Detecting the creation of new users with high-privilege roles (e.g., Global Administrator) or the assignment of such roles to existing users or service principals.
• Monitoring for suspicious access to Key Vaults, particularly the reading of secrets associated with app registrations.
• Identifying unusual API call patterns, such as bulk email exfiltration or unexpected file access from service principals.
• Correlating events across different log sources to identify multi-stage attack paths.

1. Proactive Adversary Simulation and Validation: Tools like Batcher and MS Invader are game-changers for blue teams. Instead of waiting for real attacks, organizations can:

• Build Realistic Labs: Use Batcher to create environments that mirror their production setup, including intentional misconfigurations that could form attack paths.
• Simulate Attacks: Employ MS Invader to execute known adversary techniques and full attack playbooks against these labs.
• Test Detections: Observe if existing security controls and detection rules trigger as expected during simulations.
• Identify Blind Spots: Uncover gaps in logging, telemetry, or detection logic that would allow an attacker to proceed undetected. This iterative process of simulate-detect-refine is crucial for continuous improvement of cloud security posture.

1. Regular Configuration Audits: Beyond automated tools, manual and automated audits of cloud configurations are essential. This includes reviewing app registration ownership, Key Vault access policies, managed identity permissions, and Azure Storage account access. These audits should specifically look for the "forgotten" configurations that often form the initial foothold or lateral movement opportunities in attack paths.

By embracing these defensive implications, organizations can move from a reactive to a proactive security stance, building resilience against the sophisticated, legitimate-abuse attacks targeting their cloud environments.

Key Takeaways

• Cloud Attacks Bypass Traditional Defenses: Modern adversaries are increasingly targeting cloud environments by abusing legitimate permissions and cloud APIs, rendering traditional endpoint-centric defenses like EDR ineffective against these attacks.
• Attack Paths Are Configuration-Based, Not Exploit-Based: Cloud attack paths are primarily chains of legitimate steps exploiting misconfigurations, overly permissive entitlements, and forgotten access grants, rather than relying on zero-day vulnerabilities or exploits.
• Batcher Facilitates Realistic Lab Environments: The open-source tool Batcher enables security teams to programmatically create realistic Azure/Entra ID lab environments, complete with identities, resources, and intentionally injected complex, multi-hop attack paths.
• MS Invader Automates Adversary Simulation: MS Invader, another open-source tool, allows for end-to-end adversary simulation playbooks against these lab environments, generating crucial telemetry to validate existing detections and identify logging blind spots.
• Defenders Must Adapt to Cloud-Native Security: Effective cloud defense requires a fundamental shift towards robust IAM hygiene (least privilege), comprehensive cloud logging (Entra ID, Azure Activity, Graph API), sophisticated detection engineering, and proactive use of adversary simulation tools.
• Proactive Simulation is Key to Resilience: Regularly simulating cloud attack paths in controlled environments is vital for blue teams to understand adversary tactics, test their security posture, and continuously improve their detection and response capabilities against evolving cloud threats.

About the Speaker(s)

Mauricio Velazco is a Security Research Team Lead at Microsoft, where he focuses on understanding and defending against modern adversary techniques in cloud environments. Originally from Peru, he has been based in New York City for 13 years. Velazco is a prominent voice in the security community, actively sharing his research and tools. He is the creator of both Batcher and MS Invader, open-source tools designed to help red and blue teams better understand and simulate cloud attack paths. He maintains an active presence on social media (Twitter/X) and GitHub, where he shares links to his talks, tools, and slides, embodying a commitment to practical security knowledge sharing.