Bulk data egress detection for cloud storage

What it stops

This control stops the smash-and-grab. It targets attackers who treat a database or cloud storage bucket like a vending machine. Specifically, it addresses techniques T1530 and T1567.002. The mechanism flags when a single identity reads a volume of data that deviates from its established baseline. This stops the bulk exfiltration of millions of records in a single session. It identifies anomalous read or download volumes from storage accounts. It catches data egress to unfamiliar destinations where the volume exceeds a predefined threshold. A sudden spike in outbound traffic from a production database to an external IP is the primary target here.

What it does not stop

This control is blind to the patient attacker. Low and slow exfiltration bypasses volume triggers entirely. An adversary reading ten records every hour will stay under the radar. It does not stop targeted theft. A single, high-value file containing a password list or a strategic plan creates no bulk read alert. People often assume this stops data breaches; it only stops loud ones. It fails if an attacker compromises an administrative account and lowers the alert threshold before starting the download. Internal movement is also a blind spot. Data moving between two internal servers may not trigger an egress alert if the monitoring focuses solely on the perimeter. The control ignores identity permissions. An identity reading data it has never accessed before will go unnoticed unless that access happens in bulk.

What it looks like when it is working

Working telemetry appears as a high-severity alert in the SIEM. This alert contains a specific identity, a source IP address, and a count of objects read. The logs show a vertical spike in API calls, such as GetObject or Select, within a narrow time window. There is a clear link between the identity and an external destination that has no prior history with the organisation. The analyst sees a discrepancy between the typical daily read volume for that service account and the current surge. The log entries provide the exact name of the storage bucket or database table being drained. It looks like a sudden, unsustainable burst of activity from a normally quiet account.

How to prove it

Run a controlled test this quarter using a non-production identity. Use this identity to read 5,000 distinct objects from a cloud storage bucket within a ten minute window. This must be an authorised operation to avoid triggering a genuine incident response. The pass criterion is the arrival of a high-severity alert in the SOC queue within 15 minutes of the start of the read. Record the exact timestamp when the first object was read and the timestamp when the alert was generated. Record any lag between the log generation and the alert trigger. If the alert takes an hour to arrive, the control has failed despite eventually firing.