Living off the Land: Cloud Storage Exfiltration in Stock Exchange Espionage
Just caught the report from Symantec and Carbon Black regarding the five-month mailbox compromise at a major stock exchange. While the dwell time is concerning, the exfiltration method is the real kicker: routing data through Dropbox and OneDrive to blend in with normal traffic.
This is a classic "Living off the Land" (LotL) scenario in the cloud. By copying the inbox in small, repeated batches, the attackers stayed under the radar of volumetric DLP solutions that typically look for massive data transfers. If you are blocking unknown egress IPs but whitelisting onedrive.com and dropboxapi.com, you are essentially giving them a free pipe.
We need to shift our detection logic to focus on behavioral anomalies rather than just simple volume thresholds. For example, monitoring for unexpected interactions between Outlook data processes and cloud storage sync binaries can be a strong indicator.
Here is a basic KQL query for Microsoft Sentinel/Defender to hunt for processes syncing large volumes of data initiated by automation tools rather than user interaction:
DeviceProcessEvents
| where FileName in~ ("onedrive.exe", "dropbox.exe", "googledrivesync.exe")
| where InitiatingProcessFileName in~ ("powershell.exe", "python.exe", "cmd.exe", "wscript.exe")
| project Timestamp, DeviceName, AccountName, InitiatingProcessCommandLine, ProcessCommandLine
| summarize UploadCount = count() by DeviceName, AccountName, bin(Timestamp, 1h)
| where UploadCount > 50
Given that most orgs rely heavily on these cloud services, how is everyone handling the balance between usability and security? Are you enforcing CASB controls, or relying on behavioral UEBA to catch the slow bleeds?
We dealt with a similar issue last year. Standard DLP was useless because the file sizes were small and the traffic was encrypted SSL to valid domains. We ended up deploying a CASB (Cloud Access Security Broker) to inspect API-level traffic. Specifically, we looked for a high frequency of 'Upload' events via the OneDrive API coming from a single source IP that didn't match the user's known geo-location. It's noisy at first, but once you baseline the user, it works.
Great post. Don't forget to check for OAuth abuse. In cases like this, the attackers often don't compromise the password directly; they phish the user for an OAuth token to a cloud storage app. Once they have the token, they can script the exfiltration without triggering MFA prompts again.
You can audit risky grants in Entra ID with this PowerShell snippet:
Get-MgServicePrincipal -All | Where-Object {$_.Tags -contains 'Hide'} |
ForEach-Object { Get-MgServicePrincipalOauth2PermissionGrant -ServicePrincipalId $_.Id }
This confirms my suspicion that we need to treat 'shadow IT' as a primary attack vector. Employees using personal Dropbox accounts for work files because 'it's easier' creates the perfect cover for espionage. I've started aggressively pushing conditional access policies that require compliant device status before accessing corporate data on personal cloud storage accounts.
Spotting low-and-slow exfiltration requires shifting focus from volume to behavioral anomalies. We often leverage UEBA rules to flag excessive API calls to storage endpoints. If you're in the Microsoft ecosystem, this KQL query for Sentinel helps hunt for users with unusually high upload frequencies in short timeframes:
kusto
OfficeActivity
| where Operation == "FileUploaded"
| summarize UploadCount = count() by UserId, bin(TimeGenerated, 1h)
| where UploadCount > 50
This helps catch the "small batches" approach that standard DLP misses.
Validating the client environment is just as critical as volume. In SCADA, we verify that commands come from known HMIs; similarly, you should check if the API calls are originating from expected client types. Attackers using legitimate OAuth tokens often slip up by leaving generic or script-based User-Agents (like Python-requests). You can hunt for these inconsistencies using a simple query:
kusto AuditLog | where Operation == "FileUploaded" | distinct UserAgent, UserId
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access