Building the Cross-Cloud Kill Chain: A DE's Playbook for AWS, Azure & GCP Detections

Building the Cross-Cloud Kill Chain: A DE's Playbook for AWS, Azure & GCP Detections

Speakers: Gowthamaraj, Threat Detection Engineer, Meta

Conference: Cloud Village

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

Overview

In an era where enterprises increasingly adopt multi-cloud strategy, securing diverse cloud environments has become a paramount challenge for defenders. This talk by Gowthamaraj, a Threat Detection Engineer at Meta, delves into the intricacies of building robust detection mechanisms against sophisticated cross-cloud kill chains. It highlights how attackers perceive and exploit the integrated, yet often disparate, nature of multi-cloud deployments, moving seamlessly between platforms like AWS, Azure, and GCP. The core premise is that the traditional, siloed approach to cloud security is no longer sufficient; a unified, contextual, and automated defense strategy is imperative.

The presentation unpacks the attacker's playbook, demonstrating how an initial compromise in one cloud platform can cascade into a full-scale breach across an entire multi-cloud estate. By dissecting real-world inspired attack scenarios—from phishing for initial access to lateral movement and data exfiltration across different cloud providers—Gowthamaraj illustrates the critical blind spots that current security practices often overlook. The talk then pivots to a detailed defensive framework, emphasizing the need for centralized log visibility, data normalization, contextual enrichment, and high-fidelity correlation rules to effectively detect and respond to these complex threats.

Ultimately, this session serves as a practical guide for security practitioners, particularly Threat Detection Engineers, on how to anticipate, detect, and mitigate the risks inherent in multi-cloud environments. It underscores that effective defense in the multi-cloud era demands a holistic view of the attack surface, a deep understanding of inter-cloud trust relationships, and an agile, automated response capability that can keep pace with evolving attacker tactics.

Background

▶ Watch: Introduction: Multi-cloud strategy and defender challenges (0:00)

The evolution of cloud computing has fundamentally reshaped enterprise IT infrastructure. What began a decade ago as a choice between a primary cloud provider—be it AWS, Azure, or GCP—has matured into a sophisticated landscape where multi-cloud strategy is the norm. Data from Flexera indicates that a staggering 89% of organizations now leverage a multi-cloud approach, often utilizing different providers for specialized workloads; for instance, AWS for instances and S3, GCP for database workloads, and Azure for identity management. This distributed model, while offering business agility and resilience, introduces significant complexity from a security perspective.

This complexity is a boon for attackers. They don't view cloud environments as isolated AWS, Azure, or GCP instances; rather, they perceive them as a single, interconnected entity. Their kill chains are designed to exploit the inherent trust relationships and misconfigurations that often exist between these platforms, which are typically established for business convenience. Gartner reports that 99% of cloud security incidents are attributable to customer faults, primarily misconfigurations, rather than zero-day vulnerabilities in the cloud provider's infrastructure. This statistic underscores the critical responsibility of security practitioners to secure their own deployments.

The primary attack vector in this complex landscape is compromised credentials. Attackers frequently gain initial access not through sophisticated exploits, but by abusing misconfigured permissions or by obtaining valid credentials through phishing or other social engineering tactics. Once inside, they leverage the trust relationships built between cloud environments—such as an Azure Active Directory (now Entra ID) acting as an Identity Provider (IDP) for AWS or GCP—to move laterally and escalate privileges across the entire multi-cloud estate. The challenge for defenders is that security teams are often siloed, with experts in AWS IAM potentially missing critical risky sign-ins originating from Entra ID, creating significant blind spots.

To counter these sophisticated, cross-cloud threats, Gowthamaraj proposes a six-step action plan: first, map the trust relationships to understand the true attack surface; second, unify and centralize logs from all cloud providers to build cross-cloud visibility; third, enrich logs with context (user roles, department, resource criticality); fourth, develop high-fidelity correlation rules that span across cloud boundaries; fifth, automate the response to reduce manual effort and alert fatigue; and finally, establish a continuous feedback loop for improvement. This comprehensive approach is essential for moving beyond fragmented cloud security to a truly unified and effective defense.

Key Findings

▶ Watch: Six-step action plan for cross-cloud defense (4:00)

The talk "Building the Cross-Cloud Kill Chain" reveals several critical findings that challenge conventional cloud security wisdom and offer a roadmap for more effective defense:

• The "Convenient Fiction" of Cloud Mental Models: The speaker asserts that the traditional view of cloud as a single, monolithic provider (AWS, Azure, or GCP) is a "convenient fiction." The reality is a pervasive multi-cloud strategy, with 89% of organizations leveraging multiple providers. This fundamental shift necessitates a re-evaluation of security paradigms.
• Attackers See a Unified Attack Surface: Unlike many siloed defense teams, attackers view the multi-cloud environment as a single, interconnected entity. They actively seek and exploit trust relationships, misconfigurations, and gaps between different cloud providers to extend their kill chain, rather than focusing on vulnerabilities within a single platform.
• Compromised Credentials Drive Multi-Cloud Breaches: The number one attack vector remains compromised credentials. The talk emphasizes that 99% of cloud incidents stem from customer misconfigurations, and these often lead to credential compromise or abuse, which then facilitates lateral movement across clouds.
• Exploiting Features, Not Just Vulnerabilities: A significant finding is that attackers often abuse legitimate business features, such as SSO (Single Sign-On) configured between Entra ID and AWS, or the storage of sensitive configuration files like TF state files in S3 buckets. These are not zero-day vulnerabilities but rather intended functionalities that, when misconfigured or left exposed, become critical pivot points for attackers.
• Blind Spots in Cross-Cloud Trust: The presentation highlights how internal trust relationships, such as allow-listing traffic between Azure and GCP for business purposes, can become critical blind spots for data exfiltration. Attackers can leverage these trusted pathways to bypass traditional perimeter-based detections.
• The Imperative of Cross-Cloud Visibility and Normalization: Effective defense hinges on centralizing and normalizing logs from all cloud providers (e.g., CloudTrail, Entra ID logs, Cloud Audit Log). The adoption of standards like OCSF (Open Cybersecurity Schema Framework) is presented as crucial for translating disparate log formats into a common language, enabling coherent cross-cloud analysis.
• Contextual Enrichment is Key for High-Fidelity Detections: Raw security events are often noisy. The talk stresses that true high-fidelity detections come from enriching events with extensive context—details about the user (department, role, country), the resource (criticality, public exposure), and integrating threat intelligence. This context transforms isolated events into actionable security stories.
• Automated, Identity-Centric Response is Non-Negotiable: Given the speed and complexity of cross-cloud attacks, manual investigation leads to alert fatigue and delayed response. The talk advocates for an automated, identity-centric response framework that can quickly validate alerts, check for false positives, and trigger immediate containment actions like revoking sessions or invalidating tokens.
• Baselining as a Proactive Detection Strategy: Beyond rule-based detections, the talk introduces baselining user and group behavior across clouds as a powerful method to identify anomalous activities. Detecting deviations from established "normal" behavior can uncover subtle lateral movements and credential abuses that might otherwise go unnoticed.

Technical Deep Dive

▶ Watch: Story Time: Real-world inspired cross-cloud attack chain overview (6:00)

The core of Gowthamaraj's presentation lies in dissecting the technical intricacies of a cross-cloud kill chain from an attacker's perspective, followed by a detailed blueprint for defensive countermeasures.

Attacker's Playbook: Building the Cross-Cloud Kill Chain

The talk illustrates a compelling attack scenario, drawing inspiration from real-world breaches, that spans across Azure, AWS, and GCP:

1. Initial Access – Azure (Entra ID) Compromise:

• Phishing: The attack begins with a targeted phishing campaign, often via SMS, against developers. The goal is to trick them into entering credentials and MFA (Multi-Factor Authentication) codes on a malicious site.
• Adversary-in-the-Middle (AiTM): Attackers employ a reverse proxy, an adversary-in-the-middle (AiTM) tool, to intercept credentials and MFA tokens. This allows them to capture a valid session token.
• Azure Login: With the stolen session, attackers log into the company's Azure (Entra ID) account. They typically use a VPN or other obfuscation techniques to hide their origin IP address, a common tactic to evade basic IP-based blocking. The initial login might trigger a "risky sign-in" alert, but without context or automated response, such alerts often become noise.

1. Lateral Movement – Azure to AWS:

• SSO Exploitation: Many organizations use Entra ID for Single Sign-On (SSO) to access other cloud services, including AWS. When the attacker has a valid Azure session, they can access the "My Apps" portal and click on the AWS sign-on application.
• SAML Assertion: This action triggers Entra ID to generate a SAML assertion, a digitally signed XML document containing temporary access credentials.
• AWS Temporary Token: The attacker intercepts this SAML assertion and passes it directly to AWS. AWS, trusting Entra ID as the Identity Provider, validates the assertion and grants the attacker a temporary security token, effectively giving them access to the associated AWS account. This is not a vulnerability but an abuse of a legitimate business feature.

1. Lateral Movement – AWS to GCP:

• S3 Enumeration: Once in AWS, the attacker enumerates S3 buckets, searching for sensitive files.
• TF State Files: A common target is TF state files (e.g., gcp_prod.tfstate) used by Terraform. These files often contain highly sensitive information, including GCP private keys or service account keys, which grant programmatic access to GCP projects.
• GCP Access: With the stolen GCP service account key, the attacker gains full access to the associated GCP project. Given that automation often uses lenient permissions, this can grant extensive control over GCP resources.

1. Endgame:

• Data Exfiltration: Attackers can exfiltrate data from Azure to GCP. This often bypasses existing Azure-to-internet exfiltration detections, as internal cloud-to-cloud traffic (e.g., Azure to GCP) is frequently allow-listed as trusted. From GCP, the data can then be downloaded to the attacker's local machine via another blind spot.
• Persistence: To maintain access, attackers can use the acquired permissions to create new IAM (Identity and Access Management) users or service accounts within any of the compromised cloud environments, ensuring continued access even if the initial session is revoked.

Defender's Playbook: Scaling Detections and Response

To counter such sophisticated attacks, Gowthamaraj outlines a robust defensive strategy centered on visibility, normalization, contextual enrichment, and automation:

1. Visibility and Centralized Logging:

• Collect Everything: The foundational step is to collect comprehensive logs from all cloud providers: AWS CloudTrail (for API activity), Entra ID sign-in and audit logs (for identity events), and GCP Cloud Audit Log (for activity across GCP services).
• Centralize Logs: Consolidating these logs into a single data lake (e.g., a SIEM or specialized platform) is crucial. This centralization reduces latency for cross-cloud queries and simplifies the execution of correlated detections across disparate data sources.

1. Normalization with OCSF:

• Common Schema: Raw logs from different clouds have varied formats. Normalization is essential to translate these into a common language. The speaker advocates for OCSF (Open Cybersecurity Schema Framework), which maps diverse events (e.g., AssumeRole in AWS, signin in Azure) to a unified authentication log event type. This simplifies rule writing and ensures consistency.

1. Detection and Enrichment:

• Scenario-Based Hunting: Instead of isolated log monitoring, defenders must hunt for scenarios by combining multiple events.
• Contextual Enrichment: Alerts become actionable with context. For a user ID, enrich with department, role, country, and whether it's a service or user account. For a resource, determine if it's a production database, a critical S3 bucket, or publicly accessible. This transforms "User X accessed File Y" into "Junior engineer from Marketing accessed production thread files in Terraform."
• Threat Intelligence Integration: Incorporate threat intelligence feeds (IPs, domains) to add weight to investigations, identifying if suspicious activity is linked to known malicious actors.

1. Sample Detections (KQL Examples):

• High-Risk User Sign-in (Azure) Correlated with Assume Role (AWS):
• Logic: Detects a high-risk user sign-in event from Entra ID followed by an AssumeRoleWithSAML or AssumeRole event in AWS.
• Triggers:
• Azure: Risky user sign-on log for the AWS application.
• AWS: AssumeRoleWithSAML or AssumeRole event from CloudTrail.
• Conditions: The UserPrincipal (user ID) must be the same, and the events must occur from the same IP address within a short time window (e.g., 15 minutes to an hour).
• KQL Example (Conceptual):

This creates a high-confidence alert, as it correlates suspicious identity activity with actual access in a different cloud.

• Anonymous Service Account Key Usage (AWS to GCP via TF State):
• Logic: Identifies a federated login into AWS, followed by access to S3 buckets containing TF state files, potentially leading to GCP access.
• Triggers:
• AWS: AssumeRoleWithSAML (federated login) event from CloudTrail.
• AWS: GetObject event on an S3 bucket from CloudTrail.
• Conditions: The GetObject event targets a key ending with .tfstate (or similar critical configuration files). The user ARN from the AssumeRole event correlates with the user performing GetObject within a defined time window (e.g., 15 minutes). Subsequent activity in GCP using a newly acquired service account key from that TF state file would be the final correlation point.
• KQL Example (Conceptual):

• Baselining Cross-Cloud Activity:
• Logic: Detects deviations from a user's or group's normal cross-cloud behavior.
• Method: Establish a baseline of typical activities (e.g., Developer Z usually accesses S3 buckets A, B, C from Azure, but now accesses S3 bucket X, which is highly sensitive and never accessed before by this user or group).
• Enrichment: Determine the criticality of the accessed resource and the sensitivity of the user's credentials.
• Technology: This often involves machine learning (ML) models or advanced behavioral analytics to identify statistical anomalies.

Demo / Proof of Concept

▶ Watch: Initial access: Phishing and session hijacking with AiTM (6:50)

While the talk "Building the Cross-Cloud Kill Chain" did not feature a live, interactive technical demonstration or a software-based proof of concept, it effectively presented a detailed "story time" attack scenario. This narrative walkthrough served as a conceptual proof of concept, illustrating a plausible and technically sound multi-cloud kill chain inspired by real-world breaches.

The speaker meticulously described each step of the hypothetical attack, from initial phishing and adversary-in-the-middle (AiTM) compromise of Azure credentials, through lateral movement leveraging Entra ID SSO to gain access to AWS, and finally, exploiting misconfigured S3 buckets containing TF state files to pivot into GCP. This comprehensive narrative, complete with specific attacker actions and motivations, functioned as a highly effective educational demonstration of how such cross-cloud attacks unfold and the critical vulnerabilities they exploit. The subsequent defensive strategies and KQL examples were then directly tied back to detecting and responding to the actions outlined in this detailed attack scenario.

Defensive Implications

▶ Watch: Lateral movement: Abusing Entra ID SSO to AWS (8:00)

Effective defense against cross-cloud kill chains necessitates a proactive, automated, and identity-centric approach. The talk emphasizes several key defensive implications:

1. Automated, Identity-Centric Response:

• Trigger: The process begins with a high-fidelity alert generated by the cross-cloud detection rules. For example, a "high-risk user sign-in from Azure correlated with AssumeRole in AWS."
• Enrichment: Automation plays a crucial role in enriching the alert context. This involves querying Graph API for more user details (e.g., department, role) from Entra ID, checking HR databases for additional user information, and retrieving specific IAM permissions held by the user in AWS or GCP. The criticality of these permissions can be assessed using predefined mappings or even LLMs (Large Language Models).
• False Positive Check: Before any containment action, an automated false positive check is vital to prevent business disruption. For instance, if a DevOps user routinely performs cross-cloud deployments from AWS to GCP, this activity might be allow-listed or categorized as legitimate. Automation can check against such known patterns to close benign alerts.
• Containment/Kill Switch: If the alert is validated as malicious, immediate automated containment is crucial. In Azure, this could involve revoking all sign-in sessions for the compromised user. In AWS, invalidating all active tokens for the user would force re-authentication, effectively cutting off the attacker's current access. These actions drastically reduce the attacker's dwell time.
• Follow-up and Collaboration: The final step in automation is to create structured follow-up actions. This includes automatically generating incident tickets in systems like Jira or ServiceNow, pre-populating them with all gathered context and enrichment data. Furthermore, notifying relevant security and operations teams via internal messaging platforms (e.g., Slack) facilitates rapid collaboration and investigation.

1. Scaling to Your Environment:

• Map Trust Relationships: The hardest, yet most critical, initial step is to comprehensively map all trust relationships across your multi-cloud environment. An example given is a Jenkins CI/CD pipeline in GCP that uses a service account key to deploy code to AWS. Understanding this trust allows defenders to anticipate abuse scenarios.
• Identify Abuse Scenarios: Once trust is mapped, identify how an attacker could abuse it. For instance, if the Jenkins CI/CD in GCP is compromised (a common CVE target), an attacker could steal the GCP service account token and then use it to assume roles in AWS, potentially updating IAM role policies for persistence.
• Write Specific Detections: Based on abuse scenarios, craft targeted detections. For the Jenkins example, a detection could look for AssumeRole events in AWS originating from the Jenkins principal in GCP, specifically correlating with suspicious actions like UpdateAssumeRolePolicy or unauthorized resource creation. The key is to correlate unusual activity after the initial cross-cloud access.
• Create Playbooks for Investigators: For every high-fidelity alert, provide a clear playbook for security investigators. This playbook should guide them through gathering additional context, confirming the incident, and executing manual response steps if necessary.
• Implement Optional Containment Plans: Depending on the criticality of the alert and the organization's risk tolerance, specific containment plans can be pre-defined. This might range from immediate automated kill switches (e.g., disabling a GCP service account, reverting an AWS role) to a more manual, human-approved process for highly sensitive scenarios. The goal is to have a clear, documented response for every major threat scenario.

By implementing these defensive strategies, organizations can move from a reactive, fragmented security posture to a proactive, integrated, and highly automated defense capable of effectively combating the complexities of cross-cloud kill chains.

Key Takeaways

• Multi-Cloud is the New Norm; Security Must Evolve: The vast majority of organizations operate in a multi-cloud environment, and security strategies must reflect this reality by moving beyond siloed, single-cloud defenses to a unified, comprehensive approach.
• Attackers Exploit Trust Gaps, Not Just Vulnerabilities: Attackers leverage legitimate business features like SSO and inter-cloud trust relationships, along with misconfigurations, to move laterally across AWS, Azure, and GCP, highlighting the need for defenders to understand and secure these connections.
• Visibility and Normalization are Foundational: Centralizing logs from all cloud providers (CloudTrail, Entra ID, Cloud Audit Log) and normalizing them using standards like OCSF are critical first steps to achieving cross-cloud visibility and enabling effective correlation.
• High-Fidelity Detections Require Cross-Cloud Correlation and Rich Context: Isolated alerts are noisy. Effective detection relies on correlating events across different cloud providers within specific timeframes and enriching them with detailed user, resource, and threat intelligence context to identify true attack scenarios.
• Automated, Identity-Centric Response is Essential: To combat alert fatigue and minimize attacker dwell time, security teams must automate response actions, including contextual enrichment, false-positive checks, and immediate containment measures like revoking sessions or invalidating tokens.
• Proactive Baselining Detects Anomalies: Beyond rule-based detections, baselining normal user and group activity across cloud environments can help identify deviations and anomalous cross-cloud lateral movements or credential abuses that might otherwise go unnoticed.

About the Speaker(s)

Gowthamaraj is a Threat Detection Engineer at Meta, where he focuses on building robust security defenses. He holds a Master's degree from Carnegie Mellon University (CMU) and brings a unique blend of offensive and defensive security expertise to his role, including several offensive security certifications. He believes that understanding attacker methodologies is crucial for developing efficient and effective detection strategies. Gowthamaraj is also recognized for his contributions to the security community, having discovered several CVEs (Common Vulnerabilities and Exposures) and regularly sharing his insights through blog posts on Medium. Outside of his professional endeavors, he enjoys playing badminton and NBA with friends.