Cloud-Based C2
Cloud-based C2 uses legitimate cloud services as the command channel — OneDrive, SharePoint, GitHub, Slack, Dropbox, Google Drive, and Twitter have all been used as C2 channels by both nation-state actors and red teams. The technique (called "living off trusted sites" or LOTS) works because connections to these services are almost never blocked and traffic to them is encrypted TLS, routing through CDNs with certificates from major CAs. Detection requires thinking beyond IP/domain reputation toward behavioral analysis.
A threat actor uses a SharePoint folder as their C2 channel. The implant polls the folder for new files every 5 minutes — new files contain encoded commands. After executing, the implant writes the output to a different file in the same folder. In PCAP: regular HTTPS connections to tenant.sharepoint.com every 5 minutes from a compromised workstation. Every connection is legitimate SharePoint traffic with a valid Microsoft certificate. The only anomaly is the regularity — 0% jitter, exactly every 300 seconds — and the user whose account it uses never opens SharePoint manually.
Cloud C2 Platform Detection Strategies
| Platform | How It's Used as C2 | Detection Approach |
|---|---|---|
| OneDrive / SharePoint | Poll folder for command files, upload output files | Beaconing to sharepoint.com on fixed interval, no human browsing context |
| GitHub | Read commands from Gist or repo commits, push output as new commits | API access (api.github.com) without user-agent from browser, fixed interval |
| Slack | Post commands to channel, read output from bot messages | Slack API (slack.com/api) from non-browser process, beaconing interval |
| Google Drive | Poll shared folder for command files, upload output | Drive API (www.googleapis.com/drive) from non-browser, regular interval |
| Dropbox | Same pattern as Drive | API access (api.dropboxapi.com) from non-browser |
| Twitter/X | Read commands from specific tweets, post output as replies | Twitter API from internal host — unusual and rare for enterprise |
| Telegram | Bot receives commands from operator, sends output back | api.telegram.org access from non-browser, any corporate access is suspicious |
Cloud C2 Detection
#!/bin/bash
PCAP="$1"
echo "=== API-like User-Agents to cloud storage (non-browser = suspicious) ==="
# Real user-agent = browser string. API access = python-requests, Go-http-client, curl, etc.
tshark -r "$PCAP" -n \
-Y "http.user_agent" \
-T fields \
-E separator="\t" \
-e ip.src \
-e http.host \
-e http.user_agent \
| grep -E "(sharepoint|github|slack|dropbox|googleapis|telegram|onedrive)" \
| grep -iv "mozilla\|chrome\|safari\|firefox" \
| sort | uniq -c | sort -rn | head -20
echo ""
echo "=== Beaconing intervals to known cloud APIs ==="
tshark -r "$PCAP" -n \
-Y "tls.handshake.type==1" \
-T fields \
-E separator="\t" \
-e frame.time_epoch \
-e ip.src \
-e tls.handshake.extensions_server_name \
| grep -E "(sharepoint|github\.com|api\.github|slack\.com|googleapis|dropbox)" \
| awk -F'\t' '
{
key=$2"\t"$3
if (key in last_ts) {
interval = $1 - last_ts[key]
counts[key]++
intervals[key] += interval
sq_intervals[key] += interval*interval
}
last_ts[key] = $1
}
END {
for (k in counts) {
n = counts[k]
if (n >= 5) {
mean = intervals[k]/n
# CV approximation
printf "n=%d mean=%.0fs %s\n", n, mean, k
}
}
}
' | sort -t= -k2 -n | head -20
echo ""
echo "=== Telegram bot API access (unusual from enterprise) ==="
tshark -r "$PCAP" -n \
-Y "tls.handshake.extensions_server_name contains \"telegram\"" \
-T fields \
-E separator="\t" \
-e frame.time_epoch -e ip.src -e tls.handshake.extensions_server_name \
| head -20
echo ""
echo "=== GitHub API from non-developer machines ==="
tshark -r "$PCAP" -n \
-Y "http.host == \"api.github.com\" and not http.user_agent contains \"Mozilla\"" \
-T fields \
-E separator="\t" \
-e frame.time_epoch -e ip.src -e http.user_agent -e http.request.uri \
| head -20
When a legitimate user opens SharePoint in Chrome, the SNI is tenant.sharepoint.com and the User-Agent is a full Chrome browser string (e.g., Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36...). When a cloud C2 implant polls SharePoint using the Microsoft Graph API or SharePoint REST API, the User-Agent might be python-requests/2.28.0, a custom application string, or nothing. Real enterprise users access cloud services through browsers. API-based access from workstation IPs that are not developer machines is the behavioral anomaly. Combined with beaconing (the regular poll interval), it narrows to a very small false positive set. Correlation with endpoint telemetry — which process made the connection — is the final confirmation.
Q & A
Q: The attacker is using legitimate Slack workspaces as C2. Our company uses Slack. How do I detect this without disrupting our legitimate Slack use?
Distinguishing malicious Slack C2 from legitimate Slack use purely from PCAP/network logs is very difficult because both produce TLS connections to slack.com. The distinguishing factors that may be visible: (1) API access pattern: legitimate Slack users connect via the Slack desktop app or browser (Chrome/Firefox/Electron User-Agent). An implant making API calls will have a non-browser User-Agent. (2) Beaconing: the Slack desktop app connects continuously (WebSocket). An implant polling a Slack channel on a 5-minute interval produces a regular check-in pattern that the app doesn't. (3) Source process: endpoint telemetry showing the Slack network connection originated from powershell.exe or a non-Slack process is the definitive signal. (4) Slack's own audit logs: Slack Enterprise has audit logs showing every API token used, every message posted, and which bot/user made each action. If you're investigating a Slack C2 incident, these logs are far more complete than network forensics. Contact your Slack workspace admin to pull the relevant audit logs — they'll show exactly which OAuth token was used for C2 activity.