One export call, the whole table: DynamoDB point-in-time exfiltration

DynamoDB holds high-value structured data, and a single point-in-time export copies a whole table to S3 without touching the table’s read capacity. That makes it a quiet, fast path to bulk data theft.

How the attack works

An over-permissioned application role with wildcard dynamodb actions either runs sustained full-table Scan calls or invokes ExportTableToPointInTime, copying the entire table to an attacker-readable S3 bucket. The export lands in an S3 prefix the actor can reach, staging the full data set, and the objects are then read and pulled out of the account’s controls. CloudTrail records the export call and, with data events enabled, the item-level reads and the S3 retrieval. This is Data from Cloud Storage, T1530, and Transfer Data to Cloud Account, T1537.

Why it works

The role holds wildcard permissions far beyond the keyed GetItem and Query the application actually needs. The export path is especially dangerous because it copies the whole table without consuming read capacity or following normal item-level access patterns, so capacity-based defenses never see it.

How to fix it

Throttling the table does nothing to an export that ignores read capacity, and an STS session cannot be revoked one token at a time. Scope the role’s dynamodb actions to least privilege, attach a deny on the token issue time to cut the live session, and lock down the destination S3 bucket so staged objects cannot be retrieved. For the class fix, inventory all roles with broad dynamodb actions, scope each to specific keyed operations and tables, and alert on Scan, ExportTableToPointInTime, and cross-table access.

Practice it

We built this as a GraphLattice Range scenario so security teams can rehearse spotting a full-table export, revoking the session by issue time, and confirming from CloudTrail whether the data was retrieved.