Threat actors exfiltrating data through legitimate cloud storage services present a specific detection challenge: the traffic is encrypted, the services are on every corporate allowlist, and the upload APIs look identical to normal user behaviour. T1567.002 (Exfiltration to Cloud Storage) is consistently present in post-incident analysis of ransomware pre-staging, insider threat cases, and espionage operations. The question is not whether attackers are using OneDrive, SharePoint, Google Drive, Box, and Dropbox to exfiltrate data — they are — but how to distinguish attacker uploads from the thousands of legitimate ones that happen every day.

Why Cloud Storage APIs Are the Preferred Exfiltration Channel

The operational appeal is obvious. Cloud storage APIs use HTTPS over port 443, which passes through most corporate proxies without inspection. The destination domains (.sharepoint.com, drive.google.com, upload.box.com) are on every cloud allowlist. Many endpoint security products have explicit exemptions for major cloud storage providers. And if your SIEM is ingesting NetFlow or proxy logs, a multi-gigabyte upload to OneDrive looks identical to a legitimate SharePoint document sync.

The secondary appeal is attribution complexity. An attacker staging data in a free personal Dropbox or Google Drive account introduces a layer of indirection — the exfiltration endpoint is a consumer cloud service with no obvious attacker infrastructure associated with it.

Detection Approach: Layer Your Signals

No single signal reliably distinguishes attacker exfiltration from legitimate uploads. The reliable approach combines volume anomalies, behavioural baselines, and context signals across log sources.

Signal 1: Upload Volume Anomaly

The most useful starting point is identifying accounts that upload significantly more than their personal baseline. User behaviour baselines take time to establish, but the investment pays off.

KQL — Microsoft Sentinel (Microsoft 365 logs):

let Threshold = 3.0; // standard deviations above user baseline
let LookbackDays = 30;
let BaselineWindow = 14d;
let DetectionWindow = 1d;
let Baseline = OfficeActivity
| where TimeGenerated > ago(LookbackDays + 1d) and TimeGenerated < ago(DetectionWindow)
| where Operation in ("FileUploaded", "FileSyncUploadedFull", "FileModified")
| summarize AvgDailyBytes = avg(FileSize), StdDevBytes = stdev(FileSize) by UserId;
OfficeActivity
| where TimeGenerated > ago(DetectionWindow)
| where Operation in ("FileUploaded", "FileSyncUploadedFull", "FileModified")
| summarize TotalBytes = sum(FileSize), FileCount = count() by UserId
| join kind=inner Baseline on UserId
| where TotalBytes > AvgDailyBytes + (Threshold * StdDevBytes)
| project UserId, TotalBytes, FileCount, AvgDailyBytes, StdDevBytes
| order by TotalBytes desc

Signal 2: Upload to Personal or Unknown Tenant

Legitimate SharePoint uploads go to your corporate tenant. An employee uploading to a personal OneDrive or an external tenant they don’t normally interact with is a meaningful signal.

KQL — Microsoft Sentinel:

let CorporateTenants = dynamic(["yourdomain.sharepoint.com", "yourdomain-my.sharepoint.com"]);
OfficeActivity
| where TimeGenerated > ago(1d)
| where Operation in ("FileUploaded", "FileSyncUploadedFull")
| where not(SiteUrl has_any (CorporateTenants))
| project TimeGenerated, UserId, SiteUrl, FileName, FileSize, ClientIP
| order by FileSize desc

Signal 3: CLI or API Upload Without Browser

Browser-initiated uploads generate specific user-agent strings. CLI tools (rclone, gdrive, onedrive-cli, the Graph API SDK, Box CLI) produce different user-agent patterns and often omit standard browser headers entirely. API-based uploads at volume are worth flagging.

Sigma — Proxy / Web Gateway:

title: Rclone or Box CLI Cloud Storage Upload
status: experimental
logsource:
  category: proxy
detection:
  selection:
    cs-user-agent|contains:
      - 'rclone'
      - 'box-python-sdk'
      - 'googledrivefs'
      - 'OneDriveClient'
      - 'go-http-client'
  destination_domain|endswith:
      - '.box.com'
      - 'drive.google.com'
      - '.sharepoint.com'
      - 'api.onedrive.com'
  http_method: 'PUT'
  condition: selection
falsepositives:
  - Legitimate IT automation using cloud storage APIs
level: medium
tags:
  - attack.exfiltration
  - attack.t1567.002

Signal 4: Off-Hours Upload of Sensitive File Types

Legitimate document sync does not stop at 5pm, but large uploads of compressed archives (.zip, .7z, .tar.gz) or bulk exports of sensitive file types (.db, .bak, .pst, .csv containing PII) between midnight and 6am are worth investigating.

KQL — Microsoft Sentinel:

let SensitiveExtensions = dynamic([".zip", ".7z", ".tar", ".gz", ".rar", ".pst", ".bak", ".db", ".mdb", ".csv"]);
OfficeActivity
| where TimeGenerated > ago(7d)
| where hourofday(TimeGenerated) between (0 .. 6)
| where Operation in ("FileUploaded", "FileSyncUploadedFull")
| where FileName has_any (SensitiveExtensions)
| summarize FileCount = count(), TotalBytes = sum(FileSize) by UserId, bin(TimeGenerated, 1h)
| where FileCount > 10 or TotalBytes > 104857600 // 100 MB threshold
| order by TotalBytes desc

Signal 5: Network — High-Volume Upload to Cloud Storage After Lateral Movement

The most useful correlation is combining upload volume with preceding lateral movement or privilege escalation events. If a user account uploads 2 GB to Google Drive four hours after being used to run net localgroup administrators or BloodHound, the context changes the alert tier.

let ExfilEvents = OfficeActivity
| where TimeGenerated > ago(1d)
| where Operation in ("FileUploaded", "FileSyncUploadedFull")
| summarize ExfilBytes = sum(FileSize) by UserId, bin(TimeGenerated, 1h)
| where ExfilBytes > 52428800; // 50 MB in an hour
let LateralEvents = SecurityEvent
| where TimeGenerated > ago(1d)
| where EventID in (4624, 4648, 4728) // logon, explicit creds, group membership change
| summarize LateralCount = count() by TargetUserName, bin(TimeGenerated, 1h);
ExfilEvents
| join kind=inner LateralEvents on $left.UserId == $right.TargetUserName
| where ExfilEvents.TimeGenerated > LateralEvents.TimeGenerated
| project UserId, ExfilBytes, LateralCount

UEBA Correlation and Risk Scoring

Pure rule-based detection on cloud storage exfiltration generates significant noise. User and Entity Behaviour Analytics (UEBA) platforms that build per-user baselines substantially reduce false positives. Key features to configure:

  • Upload volume baseline per user, per application: A developer who uses Google Drive heavily every day needs a different threshold than a finance user who rarely touches it.
  • Peer group comparison: A user in legal who uploads 5 GB when their peer group averages 200 MB is more suspicious than an IT admin doing the same.
  • Velocity scoring: Ten uploads in ten minutes scores differently than ten uploads spread across a workday, even at the same total volume.

Offline Preparation: Rclone Forensics

rclone deserves specific mention. It is the tool of choice for threat actors staging data from Linux and Windows endpoints. Configuration files (.config/rclone/rclone.conf on Linux, %APPDATA%\rclone\rclone.conf on Windows) contain plaintext cloud storage credentials and remote configurations. An rclone.conf found on a compromised endpoint is strong evidence of exfiltration preparation even if the actual transfer is not visible in network logs.

Host-based Sigma rule:

title: Rclone Configuration File Created or Modified
status: stable
logsource:
  product: windows
  category: file_event
detection:
  selection:
    TargetFilename|contains:
      - '\rclone\rclone.conf'
      - '\AppData\Roaming\rclone'
  condition: selection
falsepositives:
  - Legitimate rclone usage by IT operations (document and baseline)
level: high
tags:
  - attack.exfiltration
  - attack.t1567.002
  - attack.t1020

DLP Integration

Native DLP in Microsoft Purview, Google Workspace DLP, and Netskope/CASB solutions complement SIEM-based detection by inspecting content rather than metadata. Configure DLP policies for:

  • Bulk download followed by upload to personal tenant (requires correlation across Microsoft 365 DLP and SharePoint activity logs)
  • Archive files containing sensitive content classifications
  • Upload of files matching PII, financial data, or IP classification labels to external services

DLP alone will miss encrypted archives and file types it cannot inspect. The combination of volume anomaly detection (SIEM/UEBA) plus content inspection (DLP/CASB) provides complementary coverage.

References