Nobody queried your database, but the whole copy is gone
An attacker with RDS permissions does not need SQL to steal your data. They snapshot the database and share it to an account they control. Here is the back door, and how to close it.
You can have perfect query logging and still lose the whole database, because the copy never leaves as a query.
What it is
With RDS permissions, an attacker creates a snapshot of a production database, then modifies the snapshot attributes to share it with an external AWS account they control, or briefly makes it public. The other account restores the snapshot into its own database and reads everything at leisure. No SQL runs against your instance and nothing egresses your VPC. This is T1537 (transfer data to a cloud account).
Why it works
A snapshot is an independent, point-in-time copy. Changing the live database master password does nothing to it, because the snapshot already exists. The sharing step is a quiet attribute change that is easy to miss.
How to detect it
In CloudTrail, look for CreateDBSnapshot followed by ModifyDBSnapshotAttribute that adds an unknown AWS account or sets the snapshot public, from a principal that does not normally manage snapshots.
The fix that holds
Deny snapshot sharing and public snapshots with service control policies. Encrypt snapshots with KMS keys that are not shared cross-account, so a shared snapshot is useless without the key. Restrict who can create and modify snapshot attributes, and alert on any change that adds an external account.
Practice it
We built an RDS snapshot exfiltration scenario in GraphLattice Range so teams learn to spot the share and lock the back door before the copy is restored elsewhere.