Transforming Identity Protection: Innovating with AI and Attack Paths

Transforming Identity Protection: Innovating with AI and Attack Paths

Speakers: Filipi Pires, Head of Identity Advocate, Seagura

Conference: Cloud Village

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

Overview

In this insightful talk from Cloud Village, Filipi Pires, Head of Identity Advocate at Segura, delves into the critical and often overlooked realm of identity protection in cloud environments, particularly focusing on machine identities. The presentation, titled "Transforming Identity Protection: Innovating with AI and Attack Paths," highlights how misconfigurations and insufficient privilege management, especially concerning non-human identities, create significant vulnerabilities that attackers readily exploit. Pires not only dissects the theoretical underpinnings of attack paths and high-value targets but also demonstrates a potent attack vector against AWS Identity and Access Management (IAM) to underscore the urgency of robust identity governance.

Pires's talk serves as a stark reminder that while much attention is paid to human users, the proliferation of cloud services, containers, and APIs means that machine identities — encompassing tokens, secrets, keys, and API access — now represent a vast and complex attack surface. He argues that traditional security approaches often fall short in managing these dynamic identities, leading to pervasive misconfigurations that become prime targets for adversaries. The core message is clear: understanding and proactively mitigating these identity-based attack paths is paramount for securing modern cloud infrastructures.

The presentation culminates in a discussion of innovative solutions, including the application of Artificial Intelligence (AI), to gain visibility and automate the remediation of these complex attack paths. Pires introduces open-source tools and his company's own community-driven platform, emphasizing the need for practical, actionable strategies that security professionals can implement to enhance their cloud security posture. This talk is essential for anyone involved in cloud security, identity management, or risk assessment, providing both a theoretical framework and concrete examples of modern cloud exploitation.

Background

▶ Watch: Speaker introduction and role at Segura (0:00)

The landscape of identity in computing has evolved significantly. Traditionally, security focused on human identity, which involves users, passwords, and multi-factor authentication. However, the rise of cloud computing, microservices, and DevOps has ushered in an era dominated by machine identity. These non-human identities include API keys, access tokens, secrets, service accounts, container identities, and server roles. Managing these identities presents unique challenges because they are often dynamically provisioned, highly numerous, and integrated across various cloud providers, making them difficult to track and secure.

A pervasive problem in cloud security is misconfiguration. Pires cites alarming statistics: 90% of cloud breaches stem from misconfigurations, and 30% are linked to compromised accounts. Furthermore, a significant majority (70-80%) of organizations operate in multi-cloud environments, complicating consistent security policy enforcement across different platforms like AWS, Azure, GCP, and OCI. This complexity often leads to security gaps, particularly in privilege access management (PAM) and secret management, where a lack of proper governance can expose sensitive resources.

Pires emphasizes the importance of foundational security principles, such as least privilege and just-in-time provisioning access. The principle of least privilege dictates that any identity (human or machine) should only be granted the minimum necessary permissions to perform its intended function for the shortest possible duration. Just-in-time access extends this by providing temporary, time-bound access, reducing the window of opportunity for attackers. He also highlights the AWS Well-Architected Framework, a set of best practices for building secure, high-performing, resilient, and efficient infrastructure in the cloud. Pires notes that while many use AWS, a surprisingly small percentage are familiar with this critical framework, indicating a significant knowledge gap in adopting secure cloud architectures.

The concept of a high-value target is introduced, borrowed from military terminology, referring to a person or resource whose compromise would significantly impact an organization's mission. In technology, this often translates to individuals with elevated privileges or critical systems. Understanding attack vectors (the means an attacker uses to gain access, e.g., misconfiguration, phishing) and attack surfaces (the sum of all possible entry points) is crucial. Pires then defines an attack path as the chain of events an attacker follows to achieve their objective, often visualized as a graph. A chokepoint is a critical node in an attack path where multiple paths converge, representing a high-impact target or a crucial point for defensive intervention. This theoretical framework sets the stage for demonstrating how seemingly minor misconfigurations can be chained together to achieve significant compromise, especially when targeting machine identities with broad permissions.

Key Findings

▶ Watch: Defining machine identity versus human identity (2:40)

The central finding of Filipi Pires's talk is the critical vulnerability introduced by broadly scoped AWS IAM policies, particularly those granting the CreatePolicyVersion action with an overly permissive Resource definition. Pires demonstrates that an attacker, even with limited initial access to an AWS account, can leverage this specific misconfiguration to escalate privileges to full administrative control over the entire AWS organization. This highlights a significant blind spot in many cloud security strategies, where the granular impact of specific IAM actions, when combined with broad resource access, is often underestimated.

Pires illustrates how the CreatePolicyVersion action, which allows for the creation of new versions of an existing IAM policy, becomes a powerful tool for privilege escalation when the Resource element is set to (all resources) or even policy/ (all policies). An attacker with this permission can create a new policy version that grants themselves full administrative access ("Effect": "Allow", "Action": "", "Resource": "") and then attach this new policy to their existing identity or another compromised identity. This effectively bypasses existing least-privilege controls and grants unfettered access across the account, and potentially, the entire AWS organization if the initial permission allowed for policy creation at that level.

Furthermore, the talk underscores the broader issue of machine identity sprawl and the difficulty in managing the thousands of policies and roles across complex cloud environments. Pires points out that while default policies often simplify deployment, they frequently come with overly broad permissions, making them ripe for exploitation. This finding emphasizes that the problem isn't just about identifying if an identity has too much access, but how seemingly innocuous permissions can be chained together to achieve a high-impact compromise, forming a critical attack path. The demonstration serves as a concrete example of how the theoretical concepts of attack vectors, high-value targets, and chokepoints manifest in real-world cloud exploitation scenarios.

Technical Deep Dive

▶ Watch: Just-in-time access as a key protection strategy (4:00)

Pires's technical deep dive centers on AWS Identity and Access Management (IAM) and the intricate ways policies can be misconfigured to create critical vulnerabilities. AWS IAM policies are JSON documents that define permissions, consisting of key elements:

• Effect: Specifies whether the policy Allows or Denys access.
• Action: Defines the specific AWS service actions that are allowed or denied (e.g., ec2:DescribeInstances, s3:GetObject).
• Resource: Specifies the AWS resources to which the action applies. This can be a specific ARN (Amazon Resource Name) or a wildcard * to denote all resources of a certain type or all resources entirely.

Pires presents a seemingly benign IAM policy allowing ec2:DescribeInstances on Resource: *. He asks the audience if this policy is secure, leading to the "it depends" answer. While this specific policy might be necessary for a Cloud Security Posture Management (CSPM) tool, it would be highly dangerous if granted to, for example, a finance or HR employee. This illustrates the critical need for contextual analysis of permissions.

The core of the exploit lies in a specific IAM action: CreatePolicyVersion. Pires demonstrates that if an IAM user or role possesses the iam:CreatePolicyVersion action with a broad Resource definition (e.g., arn:aws:iam:::policy/ or simply *), it can be abused to achieve full administrative access.

Here's a breakdown of the technical attack path:

1. Initial Access & Information Gathering: An attacker gains initial access, perhaps through a compromised API key or secret found via a crawler (as mentioned by Pires). They use aws configure to set up their CLI with these credentials. Initial commands like aws iam list-users or aws iam list-policies might fail with "Access Denied," indicating limited permissions.
2. Identifying the Vulnerable Policy: The attacker discovers that their compromised identity has a policy attached that grants iam:CreatePolicyVersion on a broadly scoped resource. Pires creates a custom policy with:

This policy, named "attack demo" in the demonstration, allows the principal to create new versions of any existing IAM policy.

1. Crafting a Malicious Policy Version: The attacker then crafts a new policy version that grants full administrative access. This can be a standard AWS managed policy ARN, or a custom JSON policy like:

This JSON grants all actions on all resources.

1. Privilege Escalation via CreatePolicyVersion: Using the AWS CLI, the attacker executes a command similar to:

By creating a new, malicious version of an existing policy (to which the attacker implicitly has CreatePolicyVersion rights) and setting it as the default, any identity using that policy now inherits the full administrative permissions. The speaker explicitly states that a simple Google search for "how to create big access in AWS" can provide the necessary full-access JSON.

1. Organizational Compromise: Pires further highlights the distinction between account-level and organization-level access. If the CreatePolicyVersion permission was granted at the organizational level (e.g., through an AWS Organizations Service Control Policy or a delegated administrator account), an attacker could potentially create or modify policies that affect multiple accounts within the organization, leading to a widespread compromise. The speaker demonstrates escalating from a single account to full organizational access, showing how an initial foothold can be leveraged to gain control over multiple interconnected accounts.

This attack path demonstrates a critical chokepoint vulnerability. While CreatePolicyVersion might seem harmless in isolation, its interaction with broad Resource permissions allows for a complete bypass of the least-privilege principle, leading to full compromise.

Demo / Proof of Concept

▶ Watch: Understanding 'High Value Targets' in cloud security (5:40)

Filipi Pires's demonstration vividly illustrates the practical implications of the described IAM misconfiguration. The demo begins by simulating an attacker gaining initial access to an AWS account through leaked credentials.

1. Credential Acquisition: Pires mentions creating a Python crawler to find access keys, secrets, and GCP APIs in public or private environments (with a strong caveat for educational use only). Once these credentials are obtained, the attacker can use the AWS Command Line Interface (CLI).
2. Initial CLI Setup and Access Attempts: The attacker uses aws configure to input the acquired AWS Access Key ID and AWS Secret Access Key. The region and output format can be left as default or specified. Pires then attempts to execute commands like aws iam list-users and aws iam list-policies. Crucially, these commands initially result in "Access Denied" errors, confirming that the compromised credentials have very limited permissions, seemingly adhering to a least-privilege model.
3. Creating the Vulnerable Policy: Pires then switches to the perspective of a misconfigured environment. He demonstrates creating a custom IAM policy in the AWS UI. This policy, named "attack demo," is intentionally crafted to be vulnerable: it grants only the iam:CreatePolicyVersion action, but crucially, it applies to Resource: arn:aws:iam:::policy/ (or even a broader ). This means the identity associated with this policy can create new versions for any* IAM policy within the account.
4. Privilege Escalation:

• The speaker explains how an attacker, having identified the CreatePolicyVersion permission, would then search online (e.g., Google) for a JSON policy that grants full administrative access ("Effect": "Allow", "Action": "", "Resource": "").
• Using the AWS CLI, the attacker executes aws iam create-policy-version against an existing policy (that the CreatePolicyVersion permission applies to), providing the full-access JSON as the new policy document and setting it as the default version.
• This action effectively imbues the existing policy with full administrative permissions.

1. Confirming Escalated Access: After the create-policy-version command is successful, Pires re-runs aws iam list-users and aws iam list-policies. This time, instead of "Access Denied," the commands execute successfully, listing all users and policies within the AWS account. This visually confirms the successful privilege escalation from a limited CreatePolicyVersion permission to full administrative control.
2. Organizational Impact: Pires emphasizes that this escalation, if performed on an account with organizational-level permissions or if the initial policy was broadly scoped across an AWS Organization, could grant access to all accounts within that organization. He highlights the distinction between account-level and organization-level access, demonstrating how an attacker can move from a single compromised account to a broader organizational takeover.

The demo effectively transitions from a theoretical explanation of IAM policies to a concrete, step-by-step exploit, leaving no doubt about the severity of this specific misconfiguration and the ease with which it can be exploited using readily available tools and information.

Defensive Implications

▶ Watch: Managing developer privileges: The VS Code example (6:20)

The insights from Filipi Pires's talk provide critical guidance for defenders aiming to secure their cloud environments, especially against identity-based attacks. The primary defensive implication revolves around rigorously implementing least privilege and just-in-time access for all identities, both human and machine.

1. Strict IAM Policy Scoping: The most immediate and crucial step is to meticulously review and audit all IAM policies. The use of Resource: * (wildcard) should be treated as a critical security concern and eliminated wherever possible. Instead, policies should specify exact ARNs for the resources they intend to affect. For actions like iam:CreatePolicyVersion, the Resource element must be extremely narrow, ideally limiting it to specific policies that are safe to modify, or denying it entirely for non-administrative roles.
2. Understand the AWS Well-Architected Framework: Organizations must invest in educating their teams, particularly developers and architects, on the AWS Well-Architected Framework, especially its security pillar. Adhering to these best practices can prevent many common misconfigurations that lead to vulnerabilities.
3. Automated Cloud Security Posture Management (CSPM): Given the complexity and scale of cloud environments, manual audits are insufficient. Implementing robust CSPM tools is essential to continuously discover, monitor, and remediate misconfigurations across all cloud providers (AWS, Azure, GCP, OCI). These tools can identify overly permissive policies, exposed secrets, and other high-risk configurations.
4. Attack Path Analysis Tools: Pires strongly advocates for tools that can visualize and analyze potential attack paths. He mentions Cartography, an open-source tool that uses a Neo4j graph database to map assets and their relationships across AWS, Azure, and GCP, helping identify hidden attack paths. Another specific tool mentioned is AWS Prowler, an open-source security tool that helps perform security assessments, audits, incident response, and continuous monitoring.
5. Leveraging AI for Visibility and Remediation: Pires introduces his company's tool, Segura's Attack Path version (community edition), which integrates with AWS, Azure, GCP, and OCI. This tool provides:

• Visibility: It visualizes complex attack paths without requiring knowledge of graph databases or query languages.
• AI-driven Insights: An "AI Secret Intelligence" feature identifies high-critical recommendations and provides actionable insights for remediation.
• Automated Remediation Code: For identified vulnerabilities, the tool can generate ready-to-use CloudFormation or Terraform code to fix the misconfigurations, significantly accelerating the remediation process. This is particularly valuable for organizations with limited security staff.

1. Continuous Monitoring and Alerting: Implement continuous monitoring for changes to IAM policies, especially those granting CreatePolicyVersion or other high-risk actions. Alerts should be configured for any unauthorized modifications or attempts to escalate privileges.
2. Secret Management Best Practices: The talk underscores the risk of leaked credentials. Organizations should use dedicated secret management services (e.g., AWS Secrets Manager, HashiCorp Vault) and ensure that secrets are never hardcoded in source code or configuration files. Regular rotation of credentials is also crucial.
3. Developer Education and Secure DevOps: Developers are often the ones provisioning resources and defining IAM policies. Comprehensive training on secure coding practices, IAM best practices, and the principle of least privilege is vital to shift security left in the development lifecycle.

By adopting these defensive strategies, organizations can significantly reduce their attack surface, mitigate the risk of privilege escalation, and build a more resilient cloud security posture against sophisticated identity-based threats.

Key Takeaways

• Machine Identities are the New Battleground: The proliferation of cloud services means non-human identities (tokens, secrets, API keys) are a vast and often overlooked attack surface, requiring dedicated security strategies.
• Misconfigurations Drive Cloud Breaches: A staggering 90% of cloud breaches originate from misconfigurations, highlighting the critical need for meticulous governance and continuous auditing of cloud environments.
• iam:CreatePolicyVersion is a High-Risk Action: Granting iam:CreatePolicyVersion with a broad Resource scope (e.g., or policy/) in AWS IAM policies creates a severe privilege escalation vulnerability, allowing attackers to gain full administrative access.
• Least Privilege and Just-in-Time Access are Non-Negotiable: Implementing strict least privilege and just-in-time provisioning for all identities is fundamental to minimizing the window of opportunity for attackers and limiting the blast radius of a compromise.
• Attack Path Analysis is Crucial for Visibility: Understanding how attackers chain seemingly minor misconfigurations into impactful attack paths is vital. Tools like Cartography and Segura's platform help visualize these complex relationships across multi-cloud environments.
• AI-Driven Solutions Enhance Remediation: Leveraging AI for security insights and automated remediation (e.g., generating CloudFormation/Terraform code) can significantly accelerate the identification and fixing of critical misconfigurations, especially in large, complex cloud infrastructures.

About the Speaker(s)

Filipi Pires is the Head of Identity Advocate at Segura, a company focused on cloud identity protection. Originally from Brazil, he is a seasoned cybersecurity professional who travels extensively, with bases in Portugal and the US. Pires is deeply involved in the cybersecurity community, serving as part of the Red Team Village, an organizer for BSides Porto, and the founder of a community in Brazil dedicated to spreading knowledge about offensive security. He also acts as an advisor for Hyis Cyber, an initiative aimed at helping individuals enter the cybersecurity field, reflecting his commitment to giving back to the community that has shaped his career. His role at Segura involves investigating malware and threats to inform the development of new product technologies.