SHEETCREEP's command-and-control traffic goes to sheets.googleapis.com over HTTPS to Google IPs. At the network level, it is indistinguishable from an employee editing a spreadsheet. At Tech86, we analyzed this campaign because it represents the current frontier of C2 evasion — and why detection must happen at the endpoint.
The Sheet Attack campaign and the discovery
According to Zscaler, SHEETCREEP was observed starting in September 2025, with public disclosure in January 2026 during the "Sheet Attack" campaign targeting the Indian government. In June 2026, Securonix published analysis of an evolved variant and accessed the active C2 spreadsheet — with 91 tabs. That number circulated as "91 victims," but the actual breakdown, per Securonix's analysis of the C2 spreadsheet, tells a different story: 28 tabs were automated sandboxes, 17 were security researcher labs, 17 were potential real targets (only 1 high-confidence), 16 were empty tabs (likely blocked by AV), 3 miscellaneous category tabs, 1 default tab, 1 analysis VM, and 8 tabs with undetermined activity. Saying "91 victims" without this breakdown is misleading.
The attribution is moderate confidence. Zscaler assesses it may be a new APT group linked to Pakistan or a subgroup of APT36 (Transparent Tribe). The indicators point in that direction — victimology focused on the Indian government, operations originating from Pakistan, cloud abuse consistent with ElizaRAT and earlier campaigns like Operation FlightNight — but there are differences: new evasion techniques (Geo-IP, User-Agent), different tooling, and distinct PDF metadata.
The mechanism: a spreadsheet as a C2 panel
SHEETCREEP is a lightweight C# RAT at approximately 20 KB. Each victim gets a dedicated tab in the spreadsheet with the format username-hostname-4charhash. Column A receives operator commands in Base64. Column B stores command output in Base64. Column C records timestamps. The RAT queries the spreadsheet every 3 seconds via Sheets API v4 over HTTPS. Authentication uses a GCP service account with an RSA-2048 key embedded in the binary to generate OAuth2 JWTs.
It is elegant in its simplicity. The operator writes commands in a cell, the RAT reads, executes, and writes the result in the adjacent cell. Everything travels through Google's API, over HTTPS, to Google IPs. No dedicated server. No suspicious domain. No owned infrastructure.
Two variants, two operational generations
The original variant, documented by Zscaler, used TripleDES ECB encryption, executed commands via hidden cmd.exe, and kept configuration in plaintext. The evolved variant, identified by Securonix, introduced XOR obfuscation with the key "discrete", in-process PowerShell runspace (no child powershell.exe process), and GCP service account authentication.
The evolution is significant. TripleDES ECB to XOR with a hardcoded key is not a cryptographic improvement — it is operational pragmatism: XOR is harder to detect via static signature analysis, while TripleDES requires System.Security.Cryptography references that are obvious indicators. In-process PowerShell eliminates the most obvious artifact: a child powershell.exe process. The GCP service account replaces user credentials, reducing the risk of revocation. Each change closes a detection window.
Zscaler also found indicators of AI-generated code in SHEETCREEP. If confirmed, this represents a milestone: a South Asian APT using AI to generate operational malware code.
The detection challenge that shifts the paradigm
All SHEETCREEP C2 traffic goes to sheets.googleapis.com over HTTPS to Google IPs (AS15169). At the network level, it is indistinguishable from legitimate Google Workspace traffic. Your company probably allows this traffic. Your firewall does not block it. Your IDS does not detect it. Your SIEM does not alert on it.
Detection must focus on the endpoint. Non-browser processes making sustained connections to Google APIs are the first signal. Anomalous scheduled tasks — like WindowsVaultSyncService with the description "Windows Edge Core Update Task Machine Discord Update" — are the second. Suspicious file paths like %LOCALAPPDATA%\Microsoft\Vault\vaultsvc.exe with Hidden+System attributes are the third. OAuth2 service account authentication originating from binaries outside corporate context is the fourth.
The anti-forensics compound the problem. If the RAT detects analysis tools like dnSpy, Wireshark, or Network Monitor, it forces a reboot via Restart-Computer -Force. The dropper self-deletes and replaces itself with a decoy PDF. The binary receives Hidden+System attributes. This means the analysis window is short and the investigator needs protection before starting analysis.
Historical context: evolution, not novelty
Google Sheets as C2 is not new. GC2-sheet appeared in 2021. google_RAT also in 2021. APT41 used GC2 in 2022, as documented by Google TAG in 2023. What is new in SHEETCREEP is the adoption by a South Asian APT with operational improvements: service account authentication, dedicated tabs per victim, XOR obfuscation, in-process PowerShell, and aggressive anti-forensics.
The trend is clear. Advanced threats are migrating to legitimate SaaS infrastructure as C2 channels. The traffic is allowed by default. The infrastructure is free or cheap. Network-level detection is nearly impossible. The focus must be on the endpoint.
Why EDR is the answer
At Tech86, the SHEETCREEP campaign reinforces what we have advocated for a long time: detection of C2 based on legitimate SaaS infrastructure must happen at the endpoint. Our EDR monitors non-browser processes making sustained connections to SaaS APIs, detects scheduled tasks with anomalous descriptions, identifies binaries in suspicious paths with concealment attributes, and correlates out-of-context OAuth2 authentication.
When C2 hides in legitimate Google Workspace traffic, the network cannot see it. The endpoint can. And EDR is the tool that turns what the endpoint sees into response action.
The attacker evolved. Your detection needs to be where the attacker cannot hide: in the process, in the binary, in endpoint behavior.