Mapping the Invisible: Using Graph Analysis to Find Cloud Privilege Escalation Paths

TLDR: Cloud environments are complex webs of identities, permissions, and assets that traditional scanners often fail to map accurately. By treating your cloud infrastructure as a graph, you can identify non-obvious privilege escalation paths that span multiple services and domains. This post explains how to build and query an asset graph to visualize these attack vectors before an adversary does.

Security researchers often treat cloud environments as a collection of isolated services. We look at an S3 bucket, a Lambda function, or an IAM role as individual entities. But attackers do not see it that way. They see a web of connections. If they compromise a low-privilege service account, they are not looking for a single vulnerability; they are looking for the next hop in a chain that leads to domain dominance.

The real-world risk is that most organizations have no idea how their identities and assets are actually connected. You might have a hardened production environment, but if a developer has a misconfigured CI/CD pipeline that shares a service principal with a test environment, you have a bridge that bypasses your primary security controls. This is where graph-based analysis changes the game for both red and blue teams.

The Mechanics of a Breach Path

A breach path is simply a sequence of atomic actions that an attacker uses to move from an initial foothold to a high-value target. In a cloud environment, these paths are defined by the relationships between identities and resources.

Consider the common scenario of an Azure Function. When you deploy one, it often requires a storage account to persist its code and configuration. If that storage account is misconfigured or if the function has excessive permissions, an attacker who gains code execution on the function can pivot to the storage account. From there, they might find secrets, access keys, or even more code that grants them further reach into the environment.

This is not just a theoretical risk. Research presented at DEF CON 31 and BSides Portland 2024 has highlighted how write access to storage accounts can lead to full privilege escalation on Azure App Services. If you are a pentester, your goal is to map these relationships. You are looking for the "edges" in the graph: the USES relationship between a function and a storage account, or the HAS_ROLE relationship between a user and a key vault.

Building Your Own Asset Graph

To perform this analysis, you need to ingest your cloud configuration data into a graph database. Tools like Neo4j are the industry standard for this because they allow you to store nodes and edges and query them using powerful languages like Cypher.

The process involves three steps: inventory, transformation, and querying. First, you pull your cloud metadata using native APIs or tools like the Azure Resource Graph. Second, you transform this relational data into a graph-friendly triple representation: Subject, Predicate, Object. For example, (User)-[HAS_ROLE]->(StorageAccount).

If you are not interested in building from scratch, you can look at existing ontologies. BloodHound is the most famous example of this, but you can also explore the Microsoft Security Graph Schemas to see how they model these relationships.

Querying for Risk

Once your data is in the graph, you can start asking complex questions. Instead of scanning for a single misconfiguration, you can query for a chain of events. Using GQL or Gremlin, you can write a query that looks for a specific pattern:

MATCH (u:User)-[:HAS_ROLE]->(sa:StorageAccount)-[:CONNECTED_TO]->(fa:FunctionApp)-[:HAS_IDENTITY]->(ad:ADObject)
WHERE u.role = 'high'
RETURN u, sa, fa, ad

This query identifies users with high-privilege roles who have a path to an AD object through a storage account and a function app. If you find this path, you have found a critical vulnerability in your architecture.

The Defensive Reality

Defenders should use these graphs to prioritize their remediation efforts. You cannot fix everything, but you can fix the paths that lead to your most sensitive assets. If you see a path that allows a guest user to reach a Key Vault, that is your highest priority.

Remember that your map will always be incomplete. It is an approximation of reality, not reality itself. However, an incomplete map is infinitely better than no map at all. As you explore your environment, you will find new connections and new risks. Use this to refine your graph and your defensive posture.

Stop looking at your cloud environment as a list of resources. Start looking at it as a graph. The moment you see the connections, you will see the vulnerabilities that were hiding in plain sight. Whether you are hunting for bugs or trying to secure your own infrastructure, the path to the treasure is already there. You just need to draw the map.