How do attack teams hide command and control in cloud storage traffic?

How cloud storage traffic becomes a C2 channel

Cloud storage works well for command and control because it looks like ordinary collaboration or backup traffic. Attackers can place tasking, status updates or stolen material in files, objects or metadata, then poll the same service on a schedule that resembles normal sync activity. That makes the traffic harder to separate from legitimate user or application behaviour.

The trick is not that the cloud service is exotic, it is that the service is trusted. HTTPS hides payload contents from simple network inspection, standard API calls look routine, and file operations map cleanly to everyday business use. A defender therefore has to look at behaviour, identity, tenant context and object patterns, not just the destination domain.

Where cloud storage is part of the C2 path, Command and Control (C2) Guide is the best starting point for the broader tradecraft, while Cloud Services Abuse for C2 Guide shows why trusted online services are such effective hiding places for attacker communications.

Why storage-based C2 is hard to spot

Storage services create natural noise: sync clients make frequent requests, users upload and download large objects, and business applications often exchange documents through the same platforms. That normality gives an attacker cover. A small tasking file, a renamed object or a short encoded blob can blend into large volumes of legitimate content unless the defender has strong baselines and data-plane visibility.

The abuse pattern often survives basic controls because it is not trying to break the service. It relies on allowed traffic, allowed authentication paths and allowed object operations. A network team may see only a permitted SaaS or cloud endpoint, while the real signal sits in unusual user agents, odd access timing, unexpected upload frequency or buckets and containers that should not be part of a command path.

For defenders, the key distinction is between transport visibility and behavioural visibility. Content inspection alone is often weak against encrypted uploads, but sequence, frequency, object naming, API mix and tenant context can still reveal a C2 loop.

What defenders should look for in cloud storage C2

Detection works best when you treat cloud storage as a data plane, not just a destination. Look for repeated small reads and writes from the same principal, short-lived objects that appear and disappear quickly, abnormal access from hosts that do not usually use the storage service, and API patterns that do not fit the application’s normal workflow.

• High-frequency polling of the same object or prefix.
• Encodings, compression or encryption that are unnecessary for the business use case.
• New or rare principals accessing storage outside their normal tenant, region or role.
• Uploads and downloads that resemble staging rather than collaboration.
• Storage activity that correlates with beacon-like intervals or suspicious process activity on an endpoint.

Those signals matter even more when the same account can also move data out of the environment. In that case the channel is doing double duty as both control path and exfiltration path, which increases the value of T1530 Data from Cloud Storage Defensive Guide for data-plane logging and anomaly-led hunting, alongside T1567 Exfiltration Over Web Service when the storage service is being abused as a web-based transit layer.

Risk and Threat Considerations

Cloud storage C2 is risky because it collapses command, staging and exfiltration into a service that many environments already trust. Once the attacker can write and read in a legitimate storage tenant, the channel can persist even when perimeter controls are healthy, and the same path may support later theft of data or additional tooling.

Failure mechanism: The environment allows ordinary storage access, so malicious reads and writes blend into approved HTTPS and API traffic, while weak baselines miss the timing, object and principal anomalies that distinguish C2 from normal sync.

Impact: The attacker gains a low-friction control path that is harder to block without disrupting business collaboration, and the same storage relationship can become an exfiltration route or a staging point for later payload delivery.

Practitioner Guidance

What to verify: Confirm which storage services are actually required by endpoints, applications and cloud workloads, then compare that list with observed storage destinations. If a host or service account is reaching a storage tenant or bucket outside its normal business purpose, treat that as a hunting lead rather than a benign integration.

Decision rule: If the same principal both uploads small objects and repeatedly polls them on a schedule, prioritise containment and log review over trying to prove the payload is malicious first. Behavioural patterning is usually the faster discriminator than content inspection in this scenario.

Practitioner takeaway: Storage-based C2 is defeated by narrowing what is allowed, then making the allowed traffic explainable, because once attacker traffic looks like business sync, detection has to move from destination-based blocking to data-plane behaviour analysis.

Related resources from NHI Mgmt Group

• What happens when attackers use Redis replication to hide command-and-control traffic?
• When does cloud service access become a command-and-control risk?
• What should teams do when the attack has already reached command and control?
• What do security teams get wrong about encrypted command and control traffic?