Detecting Bulk Exfiltration from Cloud Storage

What it stops This control limits the damage from a loud exfiltration event. It targets the smash-and-grab approach to data theft. A compromised account attempting to sync an entire SharePoint library or a sensitive OneDrive folder to a local machine triggers this. An insider marking 1,000 documents as public in one go is caught here. It stops the most obvious path to total data loss by flagging anomalies in volume and frequency. This forces an attacker to slow down their pace of theft or risk immediate discovery. It breaks the efficiency of automated scripts designed to scrape a directory for every available PDF and XLSX file. By alerting on these spikes, it provides a chance to kill the session before the entire crown jewel repository is gone.

What it does not stop Many assume this prevents all data theft. It does not. A patient attacker avoids bulk thresholds entirely. Downloading one sensitive document every twenty minutes stays under the radar of most threshold-based alerts. This control fails against low and slow exfiltration because the noise floor is too high to flag individual files. Password-protected ZIP archives often bypass the deep packet inspection required for data loss prevention tools to be effective. Moving data between internal accounts first also hides the final exit path. An attacker can move 10GB of data to a staging folder in another account and then leak it slowly from there. Rate-limiting tools like rclone make bulk download alerts useless by mimicking human browsing patterns. Vendor brochures describe this as total visibility, but experience suggests that is marketing fiction.

What it looks like when it is working The result is a high-fidelity alert in the security console. It contains specific telemetry rather than vague warnings. It shows a single user account accessing 500 unique files within a five-minute window from an unfamiliar IP address. It flags a change to sharing permissions on a folder named "Board_Minutes_2024" that now allows external access to an unknown Gmail address. The logs show a sudden spike in FileDownloaded events correlated with a single session ID. A working system produces a ticket with a clear volume of data and a source destination. It does not just say something is wrong; it specifies who took how much and where the data went. This allows a responder to isolate the host without guessing the scope of the breach.

How to prove it Run a controlled exfiltration test this quarter. Create a dedicated test account with standard user permissions. Place 200 files, each exactly 1MB in size, into a OneDrive folder. Use a script or manual process to download all 200 files within a single sixty-second window. This creates a clear spike in telemetry that should trigger any reasonable bulk download threshold. The pass criterion is the generation of a high-severity alert in the SIEM within 15 minutes of the activity. Record the exact start time of the download and the timestamp on the resulting alert to calculate detection lag. Document whether the alert included the specific volume of data transferred or if it was a generic warning.