C2 Without Owning C2: When Attackers Use Your Trusted Services

TL;DR

Attackers have stopped hosting their own command-and-control infrastructure. Instead, they’re using Google Docs, Slack, Trello, and other trusted SaaS platforms as C2 channels. This isn’t a vulnerability in these services—it’s a fundamental shift in attacker methodology that exploits organizational trust, not technical flaws. Traditional defenses like domain blocking and signature-based detection are blind to this approach because the traffic looks legitimate by design.

Table of Contents

• The Wake-Up Call: When Legitimate Became Malicious
• What Is C2 Without Owning C2?
• The Official Terminology
• Attack Techniques and Patterns
• Why This Isn’t Making Headlines
• The Real Problem: Interpretation, Not Visibility
• Summary
• Sources
• Important Links

The Wake-Up Call: When Legitimate Became Malicious

You’re reviewing SIEM logs and notice an interesting pattern: a workstation making regular API calls to Google Drive. The user is authenticated, the traffic is encrypted over HTTPS, the domain is legitimate, and the EDR shows no malicious process behavior. Everything looks normal.

Except it’s not. That workstation is exfiltrating data through automated Google Drive uploads. The malware isn’t connecting to evil[.]com or some newly registered domain. It’s using your organization’s own Google Workspace account with stolen OAuth tokens.

This is C2 without owning C2—and it’s not a new vulnerability. It’s a new way of thinking about infrastructure.

The Fundamental Shift

For decades, attackers maintained their own command-and-control infrastructure: VPS servers, domain registrations, proxy networks. This created a detectable footprint. Security teams built defenses around these patterns: block suspicious domains, flag unusual outbound connections, detect C2 beaconing.

But what happens when the C2 infrastructure is already inside your trust boundary? When the malicious traffic is indistinguishable from legitimate business operations? When the “malware” is just a PowerShell script using documented APIs?

The answer: traditional defenses become irrelevant.

What Is C2 Without Owning C2?

Let’s break this down without the jargon.

Traditional C2: The Old Model

In the classic model, attackers needed infrastructure:

• Register domains
• Rent servers or compromised hosts
• Configure C2 software (Cobalt Strike, Metasploit, custom frameworks)
• Implement evasion techniques (domain fronting, fast flux DNS)
• Maintain operational security

This created attacker-owned infrastructure that defenders could hunt. Domain reputation services, threat intelligence feeds, and network monitoring were all designed to detect this model.

The problem: Every piece of attacker infrastructure is a potential detection point and forensic lead.

The New Model: Living Off Trusted Services

Modern attackers realized something fundamental: why own infrastructure when you can borrow it?

Instead of running their own C2 servers, they use services that organizations already trust:

• Google Drive / OneDrive: File-based dead drops for commands and exfiltration
• Slack / Microsoft Teams: Real-time messaging for interactive control
• Trello / Notion: Task boards as command queues
• Pastebin / GitHub Gists: Text-based command staging
• Telegram / Discord: Encrypted messaging as control channels

The malware doesn’t connect to attacker infrastructure—it connects to your approved business services. The traffic is legitimate. The domains are trusted. The TLS certificates are valid. Everything looks normal.

Why This Works

Three factors make this approach devastatingly effective:

1. Trust by default: Organizations whitelist these services for business operations
2. Encrypted everywhere: All traffic is over HTTPS; DPI can’t inspect payloads
3. Behavioral camouflage: Automated API calls look identical to legitimate automation

The attacker’s infrastructure isn’t a server in a datacenter—it’s a free account on a trusted platform.

The Official Terminology

The security community has developed precise terminology for these techniques. Understanding them helps you recognize patterns in the wild.

MITRE ATT&CK T1102: Web Service

MITRE ATT&CK T1102 formally documents this technique as “Web Service”—using legitimate external web services for command and control.

The technique description explicitly mentions:

• Cloud storage services (Dropbox, Google Drive)
• Code repositories (GitHub, GitLab)
• Social media platforms (Twitter, Reddit)
• Collaboration tools (Slack, Microsoft Teams)

Key insight: This isn’t exploitation. It’s abuse of intended functionality.

Dead Drop C2

A dead drop is a classic espionage technique where operatives leave messages in agreed-upon locations without direct contact. In digital terms:

1. Attacker uploads commands to Google Drive folder
2. Malware periodically checks folder for new files
3. Malware executes commands and uploads results
4. Attacker retrieves output
5. Both parties never directly communicate

Why it works: No real-time connection means no beaconing signature. The malware could check once per day—or once per week. Patient attackers win.

Living off Trusted Services (LotTS)

An evolution of Living off the Land (LotL), this technique extends the concept beyond local system binaries to cloud services.

Instead of using certutil.exe to download payloads, attackers use:

• Google Drive API to retrieve next-stage payloads
• Slack webhooks to send system information
• Microsoft Graph API to exfiltrate emails

Critical difference: The “land” is no longer just the compromised host—it’s the entire trusted cloud ecosystem.

Reputation Laundering

This is the most elegant aspect: using someone else’s good reputation to hide your bad behavior.

Services like Google, Microsoft, and Slack have:

• Global trust from security solutions
• Massive legitimate user bases
• Encrypted traffic by default
• Minimal logging of API usage

An attacker using Google Drive as C2 inherits Google’s reputation. Their malicious traffic hides in billions of legitimate API calls.

SaaS-Based C2

A straightforward term: using Software-as-a-Service platforms as command-and-control infrastructure.

Examples from real campaigns:

• APT29 (Cozy Bear) using Dropbox API
• Carbanak group using cloud storage for data staging
• Rancor group using Google Drive for payload delivery

These aren’t proof-of-concept demos. These are production techniques from nation-state actors and organized cybercrime groups.

Shadow Persistence

Persistence mechanisms that exist entirely outside the compromised system:

• OAuth tokens stored in cloud services
• API keys in environment variables
• Scheduled tasks calling external webhooks
• Browser extension abuse with cloud sync

Why it matters: Traditional host-based forensics misses persistence mechanisms that live in the cloud. Reimaging the machine doesn’t remove the attacker’s access.

Attack Techniques and Patterns

Let’s examine specific techniques attackers use. These aren’t theoretical—they’re documented in real-world incidents.

Dead Drop Pattern: File-Based Commands

How it works:

Attacker creates a shared folder on OneDrive with a specific naming convention:

Company_Reports_Q1_2026/
├── task_queue/
│   ├── cmd_001.txt
│   └── cmd_002.txt
└── results/
    └── output_001.txt

Malware polls the folder every 6 hours, executes any new command files, and uploads results.

What defenders see:

• Legitimate OneDrive API traffic
• Authenticated user accessing their own files
• Standard file sync behavior
• No suspicious process spawning (PowerShell reads files locally)

Why it bypasses defenses:

• No C2 beaconing signature
• No suspicious domains
• No unusual port usage
• File content is encrypted in transit

Configuration Abuse: OAuth Token Harvesting

Attackers don’t need to crack passwords when they can steal existing authorization tokens.

Real-world scenario:

1. User authenticates to company Slack workspace
2. Attacker phishes user to install “productivity app”
3. App requests OAuth scopes: files:read, channels:history, users:read
4. User approves (it looks legitimate)
5. Attacker now has persistent API access without the user’s password

Defender’s perspective:

• No failed login attempts
• No password spray indicators
• No brute force alerts
• Token use appears as legitimate API activity

Human-Looking Automation

Modern C2 doesn’t beacon every 60 seconds. It mimics human behavior patterns.

Sophisticated timing:

• Checks only during business hours
• Varies intervals (7:15 AM, 9:43 AM, 2:17 PM)
• Pauses during lunch hours
• No activity on weekends
• Matches user’s typical behavior profile

Additional camouflage:

• User-Agent strings matching legitimate browsers
• Requests include cookies and proper headers
• API calls respect rate limits
• Activity correlates with user’s calendar (active during “meetings”)

Why this works: Behavioral analytics look for anomalies. When malicious activity perfectly mimics normal behavior, detection becomes nearly impossible.

Slow-Burn Exfiltration

Patience is the attacker’s weapon against DLP and anomaly detection.

Technique:

• Instead of exfiltrating 10GB of data in one session
• Upload 5MB per day over 6 months
• Spread across multiple cloud services
• Files encrypted before upload
• Filenames appear legitimate (Q1_Revenue_Analysis.xlsx)

What triggers (or doesn’t trigger) alerts:

• ✅ Immediate 10GB upload: Anomaly detected
• ❌ 5MB daily uploads: Below threshold
• ❌ Data encrypted locally: DLP can’t inspect content
• ❌ Gradual baseline shift: System adjusts to “new normal”

Operator-Less Attacks

The ultimate evolution: attacks that run themselves without real-time attacker involvement.

Architecture:

1. Initial compromise via phishing or vulnerability
2. Malware establishes cloud-based persistence
3. Pre-programmed objectives in cloud storage (JSON config files)
4. Autonomous execution based on triggers
5. Results staged in cloud storage
6. Attacker checks in weekly to review progress

Advantages for attackers:

• No C2 beaconing to detect
• No real-time OPSEC mistakes
• Can abandon operation at any time (low risk)
• Difficult to attribute (no active operator behavior)

Defender’s nightmare: You’re hunting an autonomous system that looks like legitimate business automation.

Why This Isn't Making Headlines

You might wonder: If this is so effective, why aren’t we reading about it daily?

It’s Not a Zero-Day

The security media thrives on exploits and CVE numbers. They want:

• Remote Code Execution vulnerabilities
• Authentication bypasses
• Privilege escalation bugs

C2 over trusted services isn’t any of those. There’s:

• No vulnerability to patch
• No CVE to track
• No emergency fix to deploy
• No vendor to blame

It’s abuse of intended functionality. Google Drive is working exactly as designed. Slack’s API is functioning correctly. The problem isn’t a bug—it’s strategy.

It’s Old News (But Also Evergreen)

Security researchers have discussed this for years:

• Dead drop C2 concepts from the 1990s
• Cloud C2 presentations at conferences since 2015
• MITRE documenting T1102 since 2017

But knowing about a technique doesn’t mean you’re defended against it. The gap between awareness and effective defense is measured in years—or never.

Detection Doesn’t Equal Prevention

Many SOC teams know to watch for:

• Unusual Google Drive API usage
• New OAuth app authorizations
• Anomalous cloud storage patterns

But knowing what to look for and having the resources to act are different problems:

• You can’t block Google Drive (business needs it)
• You can’t inspect encrypted API traffic
• You can’t distinguish legitimate automation from malicious automation
• You can’t monitor every cloud service your users might access

The Uncomfortable Truth

The real reason this isn’t making headlines: we don’t have a good solution yet.

Traditional security models assume:

• Perimeter-based defense (C2 crosses the perimeter)
• Signature-based detection (no signatures for legitimate API calls)
• Network monitoring (encryption blinds us)
• Host-based protection (persistence is in the cloud)

This technique breaks all these assumptions simultaneously.

The Real Problem: Interpretation, Not Visibility

Let’s be clear: Security teams CAN see this activity. The problem is they can’t interpret it correctly.

Why Domain Blocking Fails

The defense: Block known-bad domains, use threat intelligence feeds.

Why it fails: Attackers aren’t using malicious domains. They’re using:

• drive.google.com
• api.slack.com
• graph.microsoft.com
• api.telegram.org

You can’t block these without breaking business operations. Even if you could, attackers would simply move to the next trusted service.

Why Antivirus Fails

The defense: Detect known malware signatures, behavioral analysis.

Why it fails: There’s often no executable to scan. The “malware” might be:

• A PowerShell script reading from environment variables
• A Python script using legitimate libraries
• Browser automation via Selenium
• Scheduled tasks calling curl commands

All of these use built-in system tools. AV can’t flag them without massive false positives.

Why EDR Hesitates

Modern EDR can detect suspicious behavior:

• Process creating cloud API connections
• Scripts reading and executing remote content
• Unusual file system activity

But EDR faces a fundamental dilemma: How aggressive to be with detections?

Too aggressive: Block legitimate IT automation, break DevOps pipelines, anger users Too lenient: Miss real threats hiding in normal activity

Most organizations tune EDR toward fewer false positives—which means fewer detections of this technique.

Traffic Analysis Hits a Wall

What you see in network logs:

10:15:23 - workstation-42 -> drive.google.com:443 (HTTPS)
10:16:01 - workstation-42 -> drive.google.com:443 (HTTPS)
10:17:48 - workstation-42 -> drive.google.com:443 (HTTPS)

What you can determine:

• Domain: Trusted ✅
• TLS certificate: Valid ✅
• User: Authenticated ✅
• Pattern: Regular intervals 🤔

What you CANNOT determine without decryption:

• File being uploaded: Command output or legitimate document?
• API endpoint: /files/upload or /files/list?
• Data content: Encrypted payload
• Intent: Malicious or legitimate automation?

The uncomfortable reality: Even with perfect visibility, encrypted traffic remains opaque.

The Interpretation Challenge

Here’s the core issue: Attackers have shifted from creating anomalies to hiding within normalcy.

Traditional threat hunting assumes:

• Bad behavior looks different from good behavior
• Patterns exist to detect
• Anomalies indicate threats

But what if:

• Malicious activity perfectly mimics legitimate activity?
• Attackers use the same tools as your IT team?
• The “pattern” is indistinguishable from business operations?

The problem isn’t visibility—it’s knowing what you’re looking at.

Summary

C2 without owning C2 represents a fundamental shift in attacker methodology. Instead of maintaining detectable infrastructure, modern threat actors abuse trusted SaaS platforms that organizations already rely on. This isn’t a technical vulnerability—it’s a strategic evolution that exploits organizational trust models.

Key takeaways:

• Infrastructure-free C2: Attackers use Google Drive, Slack, Teams, and other trusted services instead of maintaining their own servers
• Dead drop methodology: No real-time beaconing; commands and data staged in cloud storage for asynchronous retrieval
• Reputation laundering: Malicious traffic inherits the trust reputation of legitimate services
• Shadow persistence: OAuth tokens and API keys provide access that survives host reimaging
• Operator-less attacks: Pre-programmed autonomous operations that require minimal attacker interaction
• Detection paradox: Security tools can see the activity but cannot reliably distinguish it from legitimate automation
• Defense gap: Traditional perimeter, signature, and anomaly-based defenses are fundamentally ineffective against this approach

This isn’t a problem that will be solved with a patch or a new signature. It requires rethinking security architecture around context-aware detection, least-privilege API access, and behavioral analytics that understand business operations—not just technical patterns.

The attackers aren’t faster than defenders. They’re more patient. And they understand something critical: in security, the most dangerous threats are the ones that look completely normal.

Sources

1. MITRE ATT&CK T1102 - Web Service

2. Mandiant - APT29 Continues Targeting Microsoft 365

3. FireEye - Carbanak Group Uses Google Services

4. CrowdStrike - Hiding in Plain Sight: Living off Trusted Sites

5. Palo Alto Networks - Unit 42 Cloud Threat Report 2025

6. SANS Institute - Living Off the Cloud: Leveraging Legitimate Services

7. Microsoft Security Blog - OAuth Token Abuse in Enterprise Environments

8. Recorded Future - Dead Drop Resolvers in Modern C2

9. Cisco Talos Intelligence - SaaS-Based Command and Control Infrastructure

10. CISA - Understanding and Defending Against Cloud-Based C2

11. Red Canary - 2025 Threat Detection Report: Web Services

12. Sophos - Cloud Storage Services Abused for Malware Distribution

13. Kaspersky - The Evolution of C2: From Infrastructure to Abuse

14. Proofpoint - OAuth and API Abuse in Targeted Attacks

15. NIST - Special Publication 800-207: Zero Trust Architecture

Important Links

1. MITRE ATT&CK Navigator - Map T1102 techniques to your detection coverage

2. CISA Zero Trust Maturity Model - Framework for implementing Zero Trust to combat these techniques

3. Microsoft Cloud App Security - Monitor OAuth apps and API abuse

4. Google Workspace Alert Center - Detect suspicious Drive and API activity

5. SIGMA Rules Repository - Detection rules including cloud service abuse patterns

6. Awesome Threat Detection - Community-curated threat hunting resources

7. Cloud Security Alliance - SaaS Governance Best Practices - Framework for SaaS security controls

8. OWASP API Security Top 10 - API security risks relevant to C2 over trusted services