Derivation rules
2,433 declarative match → where → emit rules
(1,787 derived, 646 explicit).
Filter by cloud, emitted edge, node type, or text.
DocumentDB cluster snapshot is shared for restore with a specific external AWS account via rds:DescribeDBClusterSnapshotAttributes (restore attribute contains account ID).
rds:ModifyDBClusterSnapshotAttribute allows a principal to make a DocumentDB cluster snapshot shareable (publicly if ValuesToAdd=['all'], or to a specific account if ValuesToAdd=[<account-id>]). Any restoring account can then call rds:RestoreDBClusterFromSnapshot to exfiltrate a full database copy.
DocumentDB cluster snapshot is publicly restorable (restore attribute contains 'all') via rds:DescribeDBClusterSnapshotAttributes.
A principal in the snapshot's restore-authorized account with rds:RestoreDBClusterFromSnapshot can restore a shared DocumentDB cluster snapshot to a new cluster, obtaining full read access to all original data without network access to the source cluster.
Resetting the password of a domain-admin directory user yields privilege escalation to domain-admin access over all domain-joined resources.
iam:PassRole for a DAX service role + dax:CreateCluster creates a DAX cluster executing DynamoDB requests as the passed role - AWS-specific single-action PassRole pattern.
A principal with access to a DAX cluster (dax:GetItem / dax:Query / dax:Scan / dax:BatchGetItem) reads DynamoDB data through the cache, inheriting the DAX cluster's attached IAM role's DynamoDB permissions.
dynamodb:UpdateContinuousBackups (enable PITR) + dynamodb:ExportTableToPointInTime yields full-table exfiltration even if PITR is currently disabled - two-step escalation.
dynamodb:ExportTableToPointInTime (requires PITR enabled) writes a complete table snapshot to a caller-specified S3 bucket - full table exfiltration in one API call.
dynamodb:PutResourcePolicy allows rewriting the table/stream resource policy, enabling self-grant of data-plane access or cross-account grant - a direct privilege escalation primitive.
dynamodb:GetItem / Query / Scan grants item-level read access to the table, including any secrets or sensitive data stored as item attributes.
dynamodb:RestoreTableFromBackup restores a table from an on-demand backup; reading it requires separate GetItem/Scan/Query permission on the restored table ARN (CONDITIONAL path).
dynamodb:RestoreTableToPointInTime creates a new table from PITR; reading it requires separate GetItem/Scan/Query permission on the restored table ARN (CONDITIONAL path).
dynamodb:GetShardIterator + dynamodb:GetRecords on a DynamoDB Stream yields real-time access to all item-level changes, including full item images depending on StreamViewType.
dynamodb:PutItem / UpdateItem / DeleteItem / BatchWriteItem / TransactWriteItems grant item-level write access, enabling data poisoning (stream injection), TTL manipulation, and denial-of-service.
An EventBridge custom bus resource policy granting events:PutEvents to a principal in another account establishes cross-account publish trust; the external principal can inject events that trigger compute consumers in this account.
An EventBridge custom bus policy granting events:PutEvents to Principal '*' is publicly writable; any internet actor can inject events and potentially trigger compute consumers.
events:RetrieveConnectionCredentials returns the raw OAuth2/API-key credential stored in an EventBridge Connection; anyone with this action can read the credential.
An EventBridge Connection with API_KEY, OAUTH_CLIENT_CREDENTIALS, or BASIC auth contains a stored credential used to authenticate API destination calls.
pipes:CreatePipe + iam:PassRole lets a principal create an EventBridge Pipe with a chosen target and execution role - a persistent source-to-target data flow.
pipes:UpdatePipe lets a principal change an existing Pipe's target, enrichment, source filter, or execution role - re-routing or re-escalating persistent data flow.
events:PutEvents on a custom event bus lets a principal inject events that can match rules and trigger compute consumers.
events:PutPermission allows a principal to rewrite a custom bus resource policy, injecting cross-account trust or public access.
events:PutRule + events:PutTargets on a bus lets a principal create/modify rules and set invocation targets and roles - a rule-based persistence and trigger creation primitive.
An EventBridge rule assumes its invocation RoleArn (via events.amazonaws.com) to call targets that require IAM authorization; code running as that rule effectively runs as the invocation role.
A firing EventBridge rule invokes its configured target (Lambda, Step Functions, ECS, SQS, another bus, etc.) with the event payload.
scheduler:CreateSchedule lets a principal create a persistent cron/rate/one-time schedule that fires and invokes a target as the chosen execution role - a schedule-based persistence primitive.
An EventBridge Scheduler schedule assumes its Target.RoleArn (via scheduler.amazonaws.com) at each fire; anyone who can modify the schedule or the role effectively runs as that role on a cadence.
scheduler:UpdateSchedule lets a principal change an existing schedule's target ARN, execution role, or schedule expression - re-routing or re-timing execution.
events:StartReplay re-delivers archived events to a target bus, triggering matching enabled rules - a CanWriteData equivalent that bypasses events:PutEvents.
ec2:CopySnapshot called from an attacker account (on a shared snapshot) or with a destination in another account copies snapshot data cross-boundary.
CreateSnapshot + ModifySnapshotAttribute(add=<external account>) lets an attacker ship a full disk image to an account they control. The rule matches on the CanWrite capability on a volume and confirms effective IAM permissions for both snapshot creation and cross-account sharing.
A snapshot is shared to an external AWS account via ec2:DescribeSnapshotAttribute.
EBS direct API read on a cross-account shared snapshot constitutes data exfiltration: the caller reads another account's disk data from their own account without ever launching an EC2 instance in the source account. This rule chains CanReadData on a cross-account snapshot into CanExfiltrate.
ebs:ListSnapshotBlocks + ebs:GetSnapshotBlock give block-level read of snapshot data without mounting - no EC2 footprint required. This rule matches on direct IAM capability evaluation, not on materialized HasPermission edges (which may not exist for wildcard-scoped ebs: permissions).
ebs:StartSnapshot + ebs:PutSnapshotBlock + ebs:CompleteSnapshot allows an attacker to synthesize a malicious disk image for supply-chain attacks (trojanized AMI distribution). The written snapshot can be shared via ModifySnapshotAttribute to distribute the malicious disk cross-account. This rule matches on direct IAM capability evaluation, not on PENDING snapshot nodes (which are transient and not present in the graph at rule-evaluation time).
A principal with ec2:ModifySnapshotAttribute can make a snapshot world-readable (any AWS account can CreateVolume from it).
ModifySnapshotAttribute on an existing snapshot to add a cross-account createVolumePermission entry - data exfiltration without CreateSnapshot.
A snapshot of a volume from an instance with an instance profile (IAM role) may contain credentials, SSH keys, or other secrets on the disk. This edge is ONLY emitted when forensic evidence confirms credential material on the disk image, not from structural probability alone. The preconditions are: (1) the volume was attached to an instance with an ExecutesAs role, (2) a snapshot exists of that volume, and (3) forensic scanning or manual inspection has detected credential patterns on the disk.