Derivation rules
2,433 declarative match → where → emit rules
(1,787 derived, 646 explicit).
Filter by cloud, emitted edge, node type, or text.
A Private Link Service configured to accept connections from other tenants (via properties.autoApproval or explicit allowedSubscriptions from cross-tenant subscriptions) records a cross-tenant network trust. A PE from a different tenant connecting to this PLS extends network reachability and access across the tenant boundary.
When a consumer PE is Approved and connected to an attacker-controlled Private Link Service, network traffic from the consumer VNet is routed to the attacker's backend. This models the realized traffic-interception attack scenario (distinct from the write capability).
Write access to a Private Link Service (PLS) lets an attacker create or modify a PLS that fronts an attacker-controlled backend. This edge models the control-plane write capability (can create/modify a PLS), not the data-plane traffic interception (which is conditional on a consumer connecting to it).
Delete a policy assignment, removing the guardrail at that scope. For Deny-effect assignments this unblocks all previously-denied ARM operations at the scope. Destructive impact (cover-tracks); not modeled as escalation.
A policy assignment with a system-assigned managed identity produces an ExecutesAs edge: remediation tasks run as that system MI. Extracted from the assignment's identity.principalId field.
A policy assignment with one or more user-assigned managed identities produces ExecutesAs edges for each. Extracted from the assignment's identity.userAssignedIdentities map (keys are MI resource IDs).
Write a policy assignment with deployIfNotExists or modify effect, specifying a managed identity (system- or user-assigned) that the remediation engine uses to deploy ARM templates or modify resources. This is modeled as CanModifyConfiguration on the remediation task (BuildWorker): writing the assignment modifies the identity binding and ARM template that the remediation task will execute. Downstream, can-execute-as execute-as-via-config-identity-swap combines this with CanPassIdentity(MI) to derive CanExecuteAs(MI).
Modify an existing policy assignment's parameters, scope, or enforcement mode to weaken or disable its guardrail effect (e.g., set enforcementMode=DoNotEnforce to turn a Deny assignment into an audit-only posture, or narrow the scope). Applies to any effect type. This is governance evasion - separate from the execution-path rule (rule 1) which targets deployIfNotExists/modify assignments with a bound MI.
Overwrite a custom policy definition to change its effect from Deny (or Audit) to Disabled or Audit, neutralizing a guardrail that applies wherever that definition is assigned - potentially subscription-wide or org-wide. This is a stealthy defense-evasion primitive that modifies the definition rather than creating a visible exemption.
Write a policy exemption to remove a resource or scope from Azure Policy enforcement (governance evasion). For Deny-effect assignments this may unblock previously-denied ARM operations. This is a control-bypass / cover-tracks primitive - it does NOT directly grant access to the exempted resource.
An Azure Policy remediation task (modeled as BuildWorker - the ARM deployment runner) executes as the managed identity bound in the policy assignment's identity block. Zero-cost structural fact; can-execute-as execute-as-via-code-modify and cicd-chains cicd-modify-buildspec-executes-as consume this to produce CanExecuteAs.
Overwrite a custom policy set definition (initiative) to change the effect of bundled policy rules from Deny (or Audit) to Disabled or Audit, neutralizing a guardrail that applies wherever that initiative is assigned - potentially subscription-wide or org-wide. An initiative can bundle multiple deployIfNotExists or Deny rules; overwriting one has the same org-wide blast radius as modifying a single policyDefinition. This is a stealthy defense-evasion primitive.
Explicitly trigger a policy remediation task via Microsoft.PolicyInsights/remediations/write; the remediation executes as the assignment's bound MI. This is a direct trigger path that does not require policyAssignments/write if the assignment already has a remediation MI configured.
Admin read access to the database (CanReadData) enables full exfiltration via pg_dump (PostgreSQL) or mysqldump (MySQL).
ARM write on the server resource sets/resets the native administrator password, enabling full DB access after network reach.
Admin password reset capability (CanModifyConfiguration to server config) plus network reachability to the DB endpoint yields full data-plane read of all databases.
Admin password reset capability plus network reachability yields full data-plane write access (INSERT, UPDATE, DELETE, DROP) on all databases.
Entra admin assignment (CanModifyConfiguration) plus network reachability to the DB endpoint yields full data-plane read of all databases via Entra token authentication.
Entra AD administrator assignment permission allows designating an Entra principal for DB admin access via token authentication when activeDirectoryAuth is enabled.
Firewall write permission on a public-access server allows creating an allow-all rule, exposing the DB endpoint to the internet.
PostgreSQL/MySQL Flexible Server with publicNetworkAccess Enabled and an internet-wide firewall rule exposes the DB endpoint to the public internet.
An identity with ARM Contributor or Owner permission on a Microsoft.Purview/accounts resource holds the implicit Root Collection Admin role in Purview (assigned at account creation). This cross-plane escalation enables data-plane privilege escalation: the ARM admin can manage Purview role assignments, self-assign Data Curator, and control access within the data-plane.
An identity with ARM Contributor or Owner permission on a Microsoft.Purview/accounts resource is automatically granted the Purview Root Collection Admin role within the account at creation. This is an ARM control-plane to Purview data-plane escalation: ARM admin authority over the account resource carries over to data-plane administrative capability. Per Microsoft documentation, the account creator is assigned Root Collection Admin in Purview, enabling role assignment and privilege escalation within the Purview scope.
A principal holding Purview Data Reader (or higher-privilege roles: Data Curator, Data Source Administrator, Collection Admin) with network reachability to the Purview account can enumerate all catalog assets, classifications, scan results, and data lineage via the Purview REST API, enabling reconnaissance of sensitive data sources and classifications across the organization.
A principal holding the Purview Collection Admin role can assign Purview RBAC roles (including Data Curator, Data Source Administrator, Collection Admin) to any other principal or to themselves via the Purview role assignment API. This enables privilege escalation within the Purview account: a Collection Admin can self-assign additional roles, elevate another compromised principal, or revoke access from other admins.
A principal is assigned the Purview Collection Admin role within a Purview account. Collection Admin allows managing collections and assigning Purview RBAC roles to other principals within the account (data-plane administrative capability).
A principal is assigned the Purview Data Curator role within a Purview account. Data Curator allows read and write access to catalog assets, classifications, and glossary terms (data-plane write access).
A principal is assigned the Purview Data Reader role within a Purview account. This assignment is visible via the Purview REST API policyElements endpoint and materializes an explicit HasRole edge (Identity -> Role). The principal can read catalog assets, classifications, and scan results (data-plane access).
A principal is assigned the Purview Data Source Administrator role. Data Source Admin manages scan credentials, data sources, and integration runtimes (data-plane operational capability, includes write permissions).
ARM write (redis/write) permission grants full control-plane administration: firewall rules, authentication settings, port configuration, managed identity, and deletion.
Cache with authnotrequired=true and publicNetworkAccess=Enabled allows anonymous internet access to the Redis data-plane with full commands.
Retrieving the cache access key via listKeys/action yields full data-plane read of all cached data, subject to network reachability of the Redis endpoint.
Retrieving the cache access key via listKeys/action yields full data-plane write of all cached data (SET, DEL, FLUSHDB, CONFIG SET), subject to network reachability of the Redis endpoint.
The Redis access keys are exposed via the cache resource whenever a principal with listKeys/action can retrieve them. This is a structural credential-exposure edge: the cache itself exposes the keys as a resource-level property, coupled with a principal's CanReadCredential permission.
A principal with listKeys/action permission can retrieve the Redis access key via ARM, gaining read access to the credential.
Cache for Redis with publicNetworkAccess=Enabled and no IP firewall rules exposes the Redis data-plane port 6380 (SSL) to the public internet.
A firewall rule allowing 0.0.0.0–255.255.255.255 explicitly exposes the Redis data-plane endpoint to the entire public internet.
regenerateKey/action allows rotating the Redis access keys, enabling session revocation and credential rotation for persistence. Treated as control capability.
redis/write permission allows attaching/replacing the managed identity used for CMK (data-at-rest encryption).
redis/write permission allows modifying cache configuration including authentication settings, port exposure, TLS version, and managed identity for CMK.