FrameworkGuidesModulesRelease NotesAbout

Living-Off-The-Cloud: How Attackers Abuse Cloud APIs for Stealthy C2

Understand how threat actors leverage legitimate cloud service APIs for command-and-control communications, and learn detection strategies to identify cloud-based C2 channels.

Living-Off-The-Cloud: How Attackers Abuse Cloud APIs for Stealthy C2

The "living off the land" concept — abusing legitimate, pre-installed tools to avoid detection — has been a staple of adversary tradecraft for years. In 2026, that concept has expanded into the cloud. Instead of relying on custom C2 infrastructure that network defenders can identify and block, threat actors increasingly channel command-and-control communications through legitimate cloud service APIs. Microsoft Graph, Google Drive, Slack webhooks, Notion, Dropbox, and AWS S3 all appear in recent incident reports as covert C2 channels.

The challenge for defenders is that blocking these services is often impractical — they are the same tools your organization uses for daily work. This article examines how cloud-based C2 operates, where detection opportunities exist, and how to build monitoring that distinguishes malicious API usage from normal business traffic.

What Changed Recently

Cloud-based C2 is not entirely new. The first documented uses of services like Twitter, Pastebin, and Google Docs for C2 date back to the early 2010s. However, several developments made 2025–26 a tipping point:

  • OAuth token ubiquity — Most enterprise endpoints now have valid OAuth tokens for Microsoft 365, Google Workspace, or both. Malware can reuse these tokens without needing additional credentials.
  • API sophistication — Cloud APIs have become richer and more capable. Microsoft Graph, for example, allows creating draft emails, updating SharePoint list items, and writing to OneDrive files — all of which can serve as covert data channels.
  • TLS everywhere — Cloud API traffic is encrypted by default and terminates at trusted certificate authorities. Deep packet inspection is either impossible or politically difficult in many organizations.
  • Red team tooling maturity — Open-source C2 frameworks now include cloud-based communication modules out of the box. What was once custom development is now a configuration option.

Cloud Services Observed in C2 Channels (2025–26)

| Service | API Used | C2 Pattern | |---|---|---| | Microsoft Graph | OneDrive, Outlook Drafts, Teams | File-based tasking via shared documents, draft messages as command channels | | Google Drive / Sheets | Drive API, Sheets API | Polling shared spreadsheets for commands, uploading results as files | | Slack | Webhooks, Web API | Posting commands to private channels, reading bot messages for tasking | | Notion | API v1 | Database entries as task queues, page content as configuration | | AWS S3 | S3 API | Bucket objects as command-and-response channels | | Dropbox | Dropbox API v2 | File sync as bidirectional communication |

How Cloud-Based C2 Works at a Conceptual Level

The fundamental pattern is consistent across cloud providers:

  1. Initial access and token acquisition — The implant either brings its own API credentials (OAuth app, service account key) or harvests existing tokens from the compromised endpoint.
  2. Check-in / beacon — The implant periodically polls a cloud resource (a file, document, database row, or email draft) for new commands. This polling looks identical to normal application traffic.
  3. Command retrieval — Commands are encoded in the cloud object (base64 in a spreadsheet cell, JSON in a Notion database entry, a renamed file in OneDrive).
  4. Execution and response — The implant executes the command locally and writes the output back to the cloud service through the same API.
  5. Cleanup — Sophisticated implementations delete or modify the cloud objects after reading to reduce forensic artifacts.

The beauty of this approach from an adversary perspective is that the network traffic is indistinguishable from legitimate application usage. The destination IPs belong to Microsoft, Google, or Amazon. The TLS certificates are valid. The HTTP methods and paths match normal API calls.

Where Defenders Can Observe It

Despite the inherent stealth, cloud-based C2 does leave observable traces — you just need to know where to look:

Cloud Access Logs

  • Microsoft 365 Unified Audit Log — Records Graph API operations including file reads/writes, email operations, and Teams activity. Unusual patterns (a service account reading a specific OneDrive file every 30 seconds) stand out when baselined.
  • Google Workspace Admin Logs — API access events show which applications accessed which data and when.
  • AWS CloudTrail — S3 object-level logging captures every GetObject and PutObject call with the source IP and IAM identity.

Endpoint Telemetry

  • Processes making HTTP calls to cloud APIs outside of the normal browser or productivity application context. A PowerShell process calling graph.microsoft.com is suspicious in most environments.
  • OAuth token usage patterns — Token refresh events from unexpected processes or at unusual intervals.
  • DLL loads for HTTP/REST libraries in processes that should not be making web requests.

Network Metadata

  • DNS queries to cloud API endpoints from processes or hosts that do not normally use those services.
  • Unusually consistent polling intervals — legitimate applications have variable timing; C2 beacons tend toward fixed intervals.
  • Data volume analysis — small, regular uploads/downloads to cloud storage that match a command-response pattern.

Common Detection Blind Spots

  1. Blanket trust for cloud domains — Many network monitoring tools whitelist *.microsoft.com, *.googleapis.com, and *.amazonaws.com. This makes cloud-based C2 invisible to network-layer detection.
  2. No application-level logging — Without cloud access logs enabled and forwarded to your SIEM, you have no visibility into what API operations are being performed.
  3. Token theft goes unnoticed — If an implant reuses a legitimate user's OAuth token, the access looks authorized. Without behavioral baselines, this blends in.
  4. Encrypted payloads within encrypted channels — Even with cloud access logging, the content of files and messages may be additionally encrypted by the malware, making content inspection impossible.

Practical Hardening and Monitoring Guidance

For SOC and Detection Engineering Teams

  • Enable and centralize cloud access logs — This is the single most impactful step. Microsoft 365 UAL, Google Workspace audit logs, and AWS CloudTrail with S3 data events should all feed into your SIEM.
  • Build behavioral baselines — Understand which users and applications normally access which cloud APIs, at what frequency, and from which endpoints. Deviations are your primary detection signal.
  • Monitor for OAuth app abuse — Track the creation of new OAuth applications and consent grants. An attacker-registered application with Graph API permissions is a common persistence mechanism.
  • Correlate endpoint and cloud telemetry — If a compromised endpoint makes Graph API calls, the endpoint telemetry (process making the call) and the cloud audit log (Graph API operation) should correlate. Build detections that span both data sources.

For System Administrators

  • Restrict OAuth app registration — Limit who can register applications and grant consent in Azure AD and Google Workspace.
  • Implement Conditional Access policies — Require compliant devices and trusted locations for cloud API access. This does not stop C2 from a compromised compliant device, but it raises the bar.
  • Use Cloud Access Security Brokers (CASBs) — CASBs can inspect cloud API traffic and apply policy, including detecting unusual API usage patterns.

Lab Testing Context

Understanding cloud-based C2 helps you evaluate whether your existing Veil Framework lab exercises adequately cover modern C2 patterns. While the framework's primary focus is payload generation and evasion, the communication channel a payload uses after execution is equally important for detection validation.

For related evasion concepts, the earlier analysis of process injection in 2026 and sandbox evasion techniques provides context on how payloads reach the execution stage before establishing C2.

Related Reading

Your network perimeter logs look clean because the C2 traffic is indistinguishable from your morning email sync. Cloud-based C2 is the natural evolution of living off the land — and your detection strategy needs to evolve with it.