Detecting C2 and Data Exfiltration Over Legitimate Services: Discord, GitHub, and Cloud Storage
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Domain blocklists fail against living-off-trusted-sites attacks by design. When an attacker routes C2 traffic through GitHub's API or exfiltrates credentials to a legitimate file hosting service, your DNS firewall and web proxy see traffic to a domain they already trust. Detection requires behavioral analysis, looking at what data is being sent, from what process, at what frequency, and in what size, not at the destination domain. The TanStack supply chain payload used this technique successfully against organizations with mature perimeter security.
The LOTS Landscape: Which Services Are Being Abused
The most commonly abused legitimate services for C2 and exfiltration as of 2026, in order of frequency:
GitHub: Repository commits as dead drops for C2 commands. GraphQL API for bidirectional communication. Gists for storing exfiltrated data. The TanStack payload used GitHub GraphQL dead drops.
Discord: Webhooks for outbound data exfiltration. Bot API for bidirectional C2. Discord is particularly common in commodity malware because webhooks are trivially easy to set up and free.
Cloud storage (S3, Azure Blob, GCS): Exfiltration to attacker-controlled buckets that appear as legitimate cloud traffic. The bucket belongs to the attacker but the domain (s3.amazonaws.com) is trusted by every firewall.
Telegram: Bot API for C2 in numerous malware families. Telegram messages can carry file attachments for exfiltration.
Google services (Docs, Drive, Forms): C2 via Google Forms submissions. Exfiltration via Google Drive API. Traffic is HTTPS to google.com, essentially unblockable without blocking all Google services.
Pastebin and similar services: Read-only C2 where the compromised host polls a paste URL for commands.
Detection Strategy 1: Process-to-Domain Correlation
The behavioral anomaly in LOTS attacks is not the destination domain, it is which process on which machine is communicating with that domain, and how.
In Microsoft Defender for Endpoint, this query identifies processes making large outbound connections to cloud storage services:
DeviceNetworkEvents
| where RemoteUrl has_any (
"github.com", "api.github.com",
"discord.com", "discordapp.com",
"getsession.org", "t.me"
)
| where InitiatingProcessFileName !in~ (
"git.exe", "code.exe", "chrome.exe",
"firefox.exe", "safari", "Discord.exe"
)
| where SentBytes > 10000 // Alert on processes sending more than 10KB to these services
| summarize TotalSent = sum(SentBytes), Connections = count()
by InitiatingProcessFileName, RemoteUrl, DeviceName
| sort by TotalSent desc
This surfaces processes like node.exe, python.exe, or powershell.exe making large uploads to GitHub or Discord, a significant anomaly unless your developers are explicitly running tools that do this.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Detection Strategy 2: Upload Volume Anomaly Detection
Legitimate use of cloud services from developer machines tends to be interactive and variable. Malware exfiltration tends to be:
- Timed (triggered at infection time or on a schedule)
- Consistent in size (the same credential file paths produce similar-sized payloads)
- Brief (credential exfil is a one-time or low-frequency operation)
In Splunk, build a baseline of normal upload volumes per process:
index=network sourcetype=zeek_conn
| eval dest_is_cloud = if(match(id.resp_h, "github|discord|amazonaws|getsession"), 1, 0)
| where dest_is_cloud=1
| stats avg(resp_bytes) as avg_bytes, stdev(resp_bytes) as sd_bytes
by id.orig_h, proto
| where sd_bytes > 0
Alert when an individual connection's byte count is more than 3 standard deviations above the host's historical mean for that service category. This catches one-time large exfils that would not appear in frequency-based detections.
Detection Strategy 3: GitHub API Behavioral Analysis
GitHub API abuse for C2 and dead drops has a distinctive traffic pattern. Legitimate developer use of the GitHub API involves authentication tokens, targets repositories the developer owns or contributes to, and is driven by interactive user actions. C2 use involves:
- Polling at fixed intervals (GET requests to the same commit, gist, or file URL every N seconds)
- Commits from machines that are not developer workstations (build servers, accidentally infected endpoints)
- Authenticated API requests from processes that have no business interacting with GitHub (a web server process making GitHub API calls)
KQL detection for GitHub polling C2 patterns:
DeviceNetworkEvents
| where RemoteUrl startswith "https://api.github.com"
| where InitiatingProcessFileName !in~ ("git.exe", "code.exe", "gh.exe")
| summarize
RequestCount = count(),
UniqueUrls = dcount(RemoteUrl),
FirstSeen = min(Timestamp),
LastSeen = max(Timestamp)
by InitiatingProcessFileName, DeviceName, bin(Timestamp, 1h)
| where RequestCount > 20 and UniqueUrls <= 3 // Many requests to few URLs = polling
| sort by RequestCount desc
Detection Strategy 4: Zeek Network Behavioral Signatures
At the network layer, Zeek can detect LOTS patterns without application-layer visibility:
Anomalous upload size to trusted domains: Create a Zeek script that tracks cumulative upload bytes per source IP per destination domain per hour. Alert when an internal host uploads more than your defined threshold to a single domain outside of normal business hours or from a server-class host:
global upload_tracker: table[addr, string] of count &default=0;
event connection_state_remove(c: connection)
{
local host = cat(c$id$resp_h);
if (/github\.com|discord\.com|getsession\.org/ in host)
{
upload_tracker[c$id$orig_h, host] += c$orig$size;
if (upload_tracker[c$id$orig_h, host] > 1000000) # 1MB threshold
NOTICE([$note=Notice::Weird,
$msg=fmt("Large upload to trusted service: %s -> %s (%d bytes)",
c$id$orig_h, host, upload_tracker[c$id$orig_h, host])]);
}
}
Discord webhook exfiltration pattern: Discord webhook URLs follow the pattern discord.com/api/webhooks/{id}/{token}. Alert on POST requests to this URL pattern from any non-Discord application.
Response: When You Detect LOTS-Based Exfiltration
When you confirm LOTS-based exfiltration, the response differs from traditional C2 because you cannot block the domain.
-
Block at the process level, not the domain level. Use your EDR to restrict network access for the specific malicious process, not the destination domain. Blocking github.com prevents your developers from working.
-
Request rate limiting at the proxy layer. If you have an outbound proxy, you can apply per-source-IP rate limits to specific API endpoints (discord.com/api/webhooks, api.github.com/gists) without blocking the service entirely.
-
Identify the exfiltrated content. Review the captured traffic (if you have SSL inspection) or the process's file access logs to determine what was sent. For GitHub dead drops, check whether the attacker-controlled repository is still accessible, if so, the commands issued to the compromised host are visible in commit history.
-
Request takedown of attacker infrastructure. Discord has a security team that responds to webhook abuse reports. GitHub has an abuse reporting process for malicious repositories. Submitting a takedown request disrupts the C2 infrastructure for other victims of the same malware family.
The bottom line
LOTS attacks are undetectable by domain reputation alone and are increasingly the default for sophisticated malware. The detection shift required is from destination-based to behavior-based: which process is talking to which service, how often, and how much data is it sending. The KQL and Splunk queries in this guide surface the anomalies that blocklists miss.
Frequently asked questions
Should I block Discord and GitHub at the perimeter to prevent LOTS attacks?
Only if your organization has no legitimate use for those services. For most organizations, blocking them disrupts legitimate work without eliminating the attack vector, attackers will switch to Google Docs, OneDrive, or another trusted service. Behavioral detection is more effective than categorical blocking.
Does TLS inspection help detect LOTS exfiltration?
Yes, significantly. TLS inspection allows your proxy to see the actual content of requests to HTTPS services, enabling detection of encoded credential data in request bodies. Without TLS inspection, you are limited to metadata-based detection (destination URL patterns, request frequency, byte counts). TLS inspection is operationally complex and introduces its own risks, deploy it selectively for the highest-risk service categories.
What is the difference between LOTS and living-off-the-land (LOTL)?
LOTL (living-off-the-land) refers to using legitimate OS binaries and tools (PowerShell, certutil, mshta) for malicious purposes instead of dropping custom malware. LOTS (living-off-trusted-sites) refers to using legitimate internet services for C2 and exfiltration. Both techniques evade detection by blending into normal activity, but at different layers, LOTL at the endpoint, LOTS at the network.
How do I detect GitHub gist-based C2?
Alert on repeated GET requests to gist.github.com from the same source IP at regular intervals from non-browser processes. The pattern signature is: non-interactive process, fixed polling interval (every 30-300 seconds), same URL, no corresponding user session activity on GitHub.
Which legitimate services are most commonly abused for LOTS command-and-control?
The most frequently observed services in malware incident reports: Discord webhooks (used as C2 channels by commodity RATs including AsyncRAT, dcRAT), Telegram Bot API (direct C2 via bot messaging), GitHub Gists (command dead-drops where each commit contains attacker instructions), Google Forms and Sheets (data exfiltration via form submissions or Sheets API writes), Dropbox and OneDrive APIs (file staging for exfil), and Pastebin (read-only dead-drops for C2 configuration). The service choice often reflects the target organization's allowed outbound traffic -- an attacker who knows you block Discord will pivot to a service your proxy permits.
How do I build a SIEM rule that detects upload-volume anomalies to cloud services without generating excessive false positives for legitimate CI/CD traffic?
Scope the anomaly detection to non-CI/CD source hosts first. Assign your build servers and CD pipeline agents a named asset group or IP range and exclude that group from the upload volume baseline. For endpoints in scope, calculate a per-host rolling 7-day average of upload bytes to each cloud service category (GitHub, Discord, Telegram, cloud storage). Alert only when a single connection from a non-CI host exceeds 3x that host's historical mean for the destination category and occurs outside of the host's normal working hours window. Layer in a process name filter -- legitimate developer use of GitHub from a workstation typically comes from browser processes or git.exe, not from node.exe or python.exe. The combination of source-host type, process name, time of day, and per-destination volume delta cuts false positives dramatically while preserving sensitivity to the behavioral patterns that characterize malware exfiltration.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.