Threat Hunting Exercise: Analyzing Firewall Cloud Storage IP Range Exfiltration Dataset
This hunt uses a simulated perimeter firewall dataset (firewall_cloud_exfil_2022-10-23T193000.json) capturing T1567.002: Exfiltration to Cloud Storage, where an attacker uploads staged data over HTTPS to an unsanctioned, newly-provisioned cloud storage bucket, blending into the large volume of legitimate encrypted traffic to major cloud provider IP ranges.
Step 1: Hypothesis Formation
Hypothesis: A host generates a large, sustained outbound HTTPS data transfer (high egress-to-ingress byte ratio) to a cloud-provider IP range (AWS/Azure/GCP) that does not correspond to any of the organization's sanctioned, allow-listed storage endpoints (by SNI/hostname), immediately following access to a large volume of sensitive files - indicating exfiltration to an unsanctioned cloud storage destination rather than legitimate SaaS/cloud usage. Indicators:
- Outbound HTTPS session to a cloud-provider IP range with SNI/TLS-hostname not present in the organization's sanctioned-cloud-services allow-list.
- Highly asymmetric byte ratio (egress far exceeding ingress) inconsistent with typical browsing or API-consumption traffic.
- The destination bucket/hostname pattern resembles auto-generated cloud storage naming (e.g.,
s3.amazonaws.com/randomstring) rather than a known corporate SaaS tenant domain. - Timing correlates tightly with prior large-volume local file access (archive creation, mass file reads) on the source host.
Null Hypothesis: An employee is using a personal-but-approved cloud storage service for a legitimate, policy-compliant purpose (e.g., sharing large design files with an external vendor via a sanctioned exception). Invalidate by checking the destination against the CASB sanctioned-app inventory and any documented data-sharing exception.
Rationale: Because cloud-provider IP ranges carry enormous volumes of entirely legitimate traffic, IP-based blocking is impractical; SNI/hostname-based allow-listing combined with byte-ratio anomaly detection is required to catch exfiltration attempts that deliberately hide within "normal-looking" HTTPS cloud traffic.
Step 2: Data Sources and Scope
- Sources: Perimeter firewall/proxy logs with TLS SNI inspection; CASB (Cloud Access Security Broker) sanctioned-app inventory; endpoint file-access telemetry.
- Scope: ~2022-10-23T19:30:00-20:15:00 UTC; Host: WKS-ENG-052 (10.65.3.28); Destination SNI:
f7x9k2m1.s3.us-east-2.amazonaws.com(unsanctioned bucket). - SIEM Queries (Splunk/ELK):
index=firewall dest_asn IN ("AMAZON","MICROSOFT","GOOGLE") | stats sum(bytes_out) as egress, sum(bytes_in) as ingress by src_ip, sni | where egress > (ingress*10) AND egress > 500000000- Sanctioned-app check:
| lookup casb_sanctioned_apps sni OUTPUT is_sanctioned | where is_sanctioned=false - File-access correlation:
index=edr host="WKS-ENG-052" (file_op="archive_create" OR file_count>1000) earliest=-30m
Step 3: Key Findings
Parsed events (5 shown) confirm WKS-ENG-052 uploaded 4.7 GB to an unsanctioned, auto-named S3 bucket over 40 minutes, immediately after a mass archive-creation operation against the engineering source-code repository.
| Timestamp (UTC) | Host | Event | Detail | IOC/Why Suspicious? |
|---|---|---|---|---|
| 2022-10-23 19:28:11 | WKS-ENG-052 | (EDR file event) | Process 7z.exe archived C:\repos\core-platform\ (2.1 GB source tree) into backup.7z | Staging IOC: mass archive creation of a proprietary source-code repository immediately precedes the network transfer, suggesting deliberate data preparation for exfiltration. |
| 2022-10-23 19:32:47 | WKS-ENG-052 | Firewall (allow, TCP/443) | TLS session to 52.219.100.14, SNI f7x9k2m1.s3.us-east-2.amazonaws.com | Unsanctioned-Destination IOC: SNI does not match any entry in the CASB sanctioned-cloud-services inventory; bucket name is auto-generated/random rather than a recognizable corporate tenant. |
| 2022-10-23 19:32:47 - 20:11:03 | WKS-ENG-052 | Firewall (aggregate) | Session totals: 4.7 GB egress, 340 KB ingress (ratio ~14,000:1) | Byte-Ratio IOC: this extreme upload-dominant ratio is characteristic of a bulk data upload, not typical browsing, streaming, or API polling traffic. |
| 2022-10-23 20:11:05 | WKS-ENG-052 | (EDR process check) | curl.exe with --upload-file backup.7z command line, run from PowerShell_ISE.exe parent, not a browser | Tooling IOC: a scripted command-line upload rather than interactive browser-based file sharing further indicates deliberate, automated exfiltration. |
| - | - | (CASB check) | The account has no active session or OAuth grant to any organization-sanctioned AWS S3 tenant | Confirms the destination bucket is entirely outside the organization's sanctioned cloud storage footprint. |
Validation:
- Timeline: mass source-code archive creation, immediately followed by a large, asymmetric-ratio upload to an unsanctioned, auto-named S3 bucket via a scripted
curlcommand - a complete and deliberate exfiltration chain. - False Positives: no CASB sanctioned-app entry or documented data-sharing exception covers this destination bucket.
- Correlation: pre-transfer file staging, unsanctioned destination, extreme byte-ratio, and scripted (non-browser) upload tooling jointly confirm intentional data exfiltration to unsanctioned cloud storage.
Step 4: Recommendations & Next Steps
- Immediate Response: Isolate WKS-ENG-052, preserve the
backup.7zartifact and full session logs for forensic scoping, engage AWS Trust & Safety/legal to attempt bucket takedown or preservation request, and audit the user's access and recent activity for insider-threat versus external-compromise attribution. - Detection: Sigma-style rule:
title: Unsanctioned Cloud Storage Bulk Upload→selection: dest_asn IN ('AMAZON','MICROSOFT','GOOGLE') AND is_sanctioned=false AND bytes_out > 500000000 AND egress_ingress_ratio > 20→condition: selection. - Pro Tip: Deploy TLS SNI/hostname-based allow-listing for all cloud-provider destinations at the proxy layer (rather than IP-based rules, which are useless against shared cloud infrastructure) - pair this with DLP content inspection on any newly observed SNI in a cloud-provider range, since a bucket/hostname never seen before on the network is inherently higher-risk than established, recurring corporate SaaS traffic.
Hypothesis confirmed - an engineering workstation archived the entire core-platform source-code repository and uploaded 4.7 GB to an unsanctioned, randomly-named S3 bucket via a scripted command-line tool, bypassing browser-based DLP controls entirely!