Derivation rules

Delete an activity log alert rule, silencing automated detection triggered by Azure Resource Manager (ARM) control-plane events (resource creation, deletion, policy changes, role assignments). Activity log alerts are distinct from scheduled-query and metric alerts, on their own ARM resource type.

Delete a diagnostic setting on an Azure resource or at subscription scope, stopping export of that resource's (or subscription's) Activity Log and resource logs to a Log Analytics workspace, storage account, or Event Hub. Headline defense-evasion primitive: subsequent attacker API activity goes unrecorded in the monitored scope.

Delete the subscription-level Activity Log export profile (legacy Microsoft.Insights/logProfiles), stopping archive of all ARM management-plane events for the entire subscription.

Delete a metric alert rule, silencing automated detection triggered by metric thresholds (CPU, memory, network, custom metrics). Metric alerts fire independently of log-search alerts and are on distinct ARM resource types.

Delete a scheduled query (log search) alert rule, silencing automated detection based on KQL log queries - disables alerting on specific threat patterns or compliance baselines.

Write or replace a diagnostic setting, redirecting log export to an attacker-controlled destination or selectively excluding categories - a stealthier evasion than deletion because the setting remains present.

Write or replace the subscription Activity Log profile, redirecting export to an attacker-controlled destination or narrowing the captured regions and categories.

A service principal holding Application.ReadWrite.All can add itself as the owner of any app registration, granting it permanent owner-level control (credential addition, configuration change) independent of the original permission grant.

A service principal holding Application.ReadWrite.All (or Directory.ReadWrite.All) can add a password or certificate credential to any app registration or service principal in the tenant and then authenticate as that identity, inheriting all its permissions - the identity-plane equivalent of sts:AssumeRole.

A service principal holding Application.ReadWrite.All or Directory.ReadWrite.All can modify the trust configuration of any app registration by adding a federated identity credential (OIDC trust), allowing an attacker-controlled external issuer to obtain tokens as that app without a static secret.

A service principal holding Group.ReadWrite.All, GroupMember.ReadWrite.All, or Directory.ReadWrite.All can add any principal (including itself) to any Entra group, inheriting that group's RBAC role assignments, Graph app role assignments, and any other entitlements the group carries.

A multi-tenant application registration that has been granted admin consent by a foreign Entra tenant creates a cross-tenant trust allowing the app's SP in the foreign tenant to act under the consented permissions. If the app or its home-tenant SP is compromised, the attacker gains a foothold in the foreign tenant - a lateral-movement primitive.

A service principal holding RoleManagement.ReadWrite.Directory can assign any Entra directory role (including Global Administrator) to any principal, achieving tenant takeover - the app-permission equivalent of holding Privileged Role Administrator.

A service principal holding User.ReadWrite.All (or Directory.ReadWrite.All) can reset any non-protected Entra user's password via PATCH /users/{id} with a new passwordProfile, taking over that user's account and inheriting their RBAC and group memberships.

ANF account with AD join configured contains the machine account password as an AccessKey.

netAppAccounts/write permission on ANF account enables AD join configuration modification.

In-VNet network access to ANF volume enables NFS/SMB data-plane read (ARM volumes/read is metadata-only prerequisite).

listCredentials/action permission on ANF account grants CanReadCredential on the AD join AccessKey.

snapshots/write permission enables snapshot creation/restore, allowing within-subscription data exfiltration.

volumes/write permission on ANF volume enables export policy mutation.

Retrieve the raw SAS key (primaryKey/secondaryKey/connectionStrings) from a Notification Hub authorization rule via ARM listKeys; the DefaultFullSharedAccessSignature key yields hub-wide Send+Manage data-plane access.

Retrieve all PNS credentials (APNS cert/token, FCM API key, WNS packageSid+secret, etc.) from a Notification Hub via ARM pnsCredentials; credentials are reusable outside Azure.

Principal with the networkSecurityGroups/* wildcard (Network Contributor, Contributor, Owner) has full administrative control over the NSG.

An NSG effective inbound rule allows source=Internet (or 0.0.0.0/0) with action=Allow on a specific port - the firewall is open to the public internet for that port. CONDITIONAL(network_reachability): a public IP must also be present on an attached resource for the port to be externally reachable.

An NSG effective inbound Allow rule from Internet/0.0.0.0/0 on a service port, combined with a public IP (or internet-facing LB) on an attached resource, makes that resource internet-reachable: ExposedToInternet.

Principal with join/action on an NSG they control can re-associate (replace) the NSG on a target subnet or NIC, bypassing the original NSG's security rules. This is an NSG-specific escalation primitive that does not decompose into generic can-control or credential chains.

Principal with networkSecurityGroups/write can replace the full NSG rule set, including deleting all existing Deny rules - strictly stronger than securityRules/write alone.

Principal with securityRules/write can add an inbound Allow rule for Internet/0.0.0.0/0, opening previously blocked ports across all subnets and NICs where this NSG is associated.

listKeys or regenerateKey on an Azure OpenAI account retrieves symmetric API keys that authenticate to all model deployments.

Write access to a PaaS resource's privateEndpointConnections lets an attacker approve a PE connection from an attacker-controlled VNet, granting that VNet private network access to the resource - bypassing its public firewall.

An identity with <resource>/privateEndpointConnections/write on a PaaS resource can approve a private endpoint connection from a different subscription. Approving such a connection records a cross-subscription trust: the resource owner has explicitly authorized a network connection from another subscription's VNet, extending the reach of that remote VNet across the subscription boundary.

If the backing PaaS resource (Key Vault, Storage, etc.) has a non-empty autoApprovalSubIds list in its privateEndpointConnections properties, and a PE is created in a subscription matching that list, the connection is auto-approved (no manual approval step required). Creating a PE in that subscription immediately grants the consumer VNet private access to the resource.

An Approved private endpoint connection from a different subscription records an authorization relationship: the resource owner (in the provider subscription) has approved a network connection from an external (consumer) subscription. This models the cross-subscription trust relationship established by the approval.

An Approved private endpoint connection that crosses subscription boundaries extends private network reach across the subscription boundary: a foothold in the consumer VNet (sub A) gains private network access to the PaaS resource in the provider subscription (sub B).

A Microsoft.Network/privateDnsZones/virtualNetworkLinks ARM record directly observes that a private DNS zone is linked to a VNet. This is a structural fact: the zone's DNS records apply to name resolution within that VNet.

Write access to A or CNAME records in a private DNS zone (e.g., privatelink.vaultcore.azure.net) lets an attacker redirect in-VNet FQDN resolution for a PaaS service to an attacker-controlled IP - intercepting credentials or data sent to that service from any linked VNet.

Write access to virtual network links in a private DNS zone lets an attacker link additional VNets to the zone, expanding the blast radius of a compromised or attacker-controlled DNS zone to additional VNets whose resources now resolve PaaS FQDNs via the attacker-influenced zone.

Write access to a private DNS zone object (Microsoft.Network/privateDnsZones/write) grants full administrative control: the identity can replace, delete, or recreate the zone entirely. This is higher-impact than record-level write because it includes zone deletion (DoS) and recreation with attacker-controlled records. Zone write subsumes record write (the can-control linchpin derives Controls from this).

A Microsoft.Network/privateEndpoints ARM record where the PE subscription differs from the backing resource's subscription (cross-subscription connection) directly establishes cross-subscription private reachability. The connection is approved and DNS-configured, so network traffic flows across the subscription boundary.

Write access to a private endpoint's privateDnsZoneGroups lets an attacker re-link the PE to an attacker-controlled private DNS zone, redirecting DNS resolution of the PaaS service FQDN for that specific PE to an arbitrary IP.

An Approved private endpoint with a working private DNS zone group makes the backing PaaS resource (Key Vault, Storage, SQL, etc.) reachable at a private IP from any compute in the same VNet or a peered VNet - bypassing the public firewall.

A Microsoft.Network/privateEndpoints ARM record with provisioningState=Succeeded, connection status=Approved, and a privateDnsZoneGroup attachment directly establishes that the backing PaaS resource is privately reachable from compute in the same or peered VNet. This is a structural fact observed in the PE resource properties.

Write access to a private endpoint object (privateEndpoints/write) grants full control of that PE - NIC, DNS zone groups, and subnet placement - enabling the attacker to reconfigure where private traffic flows.