How China's UNC2814 Used Google Sheets as a Hacking Command Centre — And Got Caught

What Happened

Google's Threat Intelligence Group disclosed on February 25, 2026 that a threat actor tracked as UNC2814 — assessed with moderate-to-high confidence as a Chinese state-sponsored actor — had been running a long-term intrusion campaign named GRIDTIDE since at least 2023. The campaign targeted telecommunications organisations primarily, with confirmed compromises in 53 organisations spanning 42 countries, and suspected infections in more than 20 additional organisations.

The defining characteristic of GRIDTIDE is the use of the Google Sheets API as a command-and-control (C2) channel. Rather than establishing communication with a dedicated attacker-controlled server — which would create suspicious network traffic and trigger security tool alerts — the implanted backdoor communicated exclusively with Google Sheets. Commands were written into spreadsheet cells as Base64-encoded strings. The backdoor read those cells on a schedule, decoded and executed the commands, and wrote results back to the sheet.

From the perspective of a network monitoring tool, this traffic looks identical to any employee or business application accessing Google's APIs.

Google has terminated all UNC2814 Cloud projects, revoked Sheets API access tokens associated with the campaign, and sinkholed the domains used in the operation. The company explicitly warns that it expects UNC2814 to resume operations using fresh infrastructure.

The Technique: SaaS APIs as C2 Channels

Traditional malware C2 infrastructure requires attackers to maintain servers, register domains, and manage SSL certificates. This infrastructure is visible: it generates DNS lookups to unusual domains, establishes connections to IP addresses with no business purpose, and often fails to blend with legitimate enterprise traffic. Modern threat intelligence and network detection tools are built to find it.

SaaS API C2 inverts this. Instead of establishing a connection to c2.attacker.com, the malware calls sheets.googleapis.com — the same endpoint your organisation's finance team, HR platform, and sales CRM are also calling hundreds of times per day. The traffic pattern, the destination IP, the TLS certificate — all of it is indistinguishable from legitimate business operations.

The GRIDTIDE implementation used the standard Google Sheets API v4. The backdoor — once implanted on a target system — would:

1. Authenticate to a Google account under attacker control using an OAuth token embedded in the implant
2. Read a specific cell range in a designated spreadsheet on a polling schedule (likely every few minutes)
3. Decode Base64-encoded command strings from cells
4. Execute commands — which included host reconnaissance, file upload/download, and arbitrary bash execution
5. Write command output back to the same spreadsheet for the operator to retrieve

The entire C2 loop — command delivery and result exfiltration — travels over Google's infrastructure, authenticated with Google's OAuth system, to destinations with Google's IP addresses and certificates.

Why This Is Hard to Detect

Standard web monitoring creates allow-lists of destinations (googleapis.com, google.com) and blocks unknown domains. GRIDTIDE's traffic passes every allow-list by design. Deep packet inspection on TLS-encrypted traffic to Google APIs requires certificate pinning bypass or TLS inspection infrastructure that many organisations don't have.

The technique isn't unique to Google Sheets. The same approach has been used with GitHub repositories (commands stored as commits or issues), Microsoft OneDrive (commands stored as files), Slack API (commands posted to channels), and Telegram bots. Any platform that provides an authenticated API with a reading/writing primitive can serve as a C2 channel. What makes Google Sheets particularly effective is its ubiquity in enterprise environments — blocking or alerting on Sheets API traffic would generate enormous noise.

What GRIDTIDE Did Once Inside

The GRIDTIDE backdoor is described as a lightweight implant with four primary capabilities:

• Host reconnaissance — system information gathering (hostname, OS version, running processes, network configuration, installed software)
• File upload — exfiltrate files from compromised hosts to attacker-controlled storage
• File download — push additional tooling or payloads to compromised hosts
• Arbitrary bash execution — run any shell command, with output returned via the Sheets channel

The arbitrary bash execution capability makes the initial implant essentially a full remote access tool — with file staging and command execution, the attacker can deploy additional specialised tooling on demand. The light initial implant minimises detection surface (fewer processes, fewer files, no persistent binary to scan) while maintaining the capability to escalate at any time.

Telecommunications targets are consistent with Chinese state espionage priorities: telco infrastructure provides access to call records, metadata, subscriber data, and in some deployments, lawful intercept capabilities. The same targeting pattern has appeared in multiple Chinese APT campaigns since 2022.

The Disruption — And Why It's Temporary

Google's response on February 25 was comprehensive at the infrastructure level: terminated Cloud projects associated with the campaign, revoked all OAuth tokens belonging to the attacker-controlled accounts, sinkholed the domains used in GRIDTIDE operations.

This disruption is meaningful — it severs the C2 channel for currently active implants. Backdoors on compromised hosts that poll for commands from the now-revoked spreadsheets will receive errors and go silent.

But Google itself notes the limitation: "Google expects resumption with new infrastructure." Creating a new Google account to replace the terminated ones takes minutes. Updating the OAuth token embedded in the implant requires pushing a new payload to already-compromised hosts — which is trivially achievable for a threat actor that has already established persistence. The infrastructure disruption imposes operational cost and delay, not permanent defeat.

More fundamentally, the technique itself is unaffected. The pattern of using Google Sheets (or any other SaaS API) as a C2 channel will be used again — by UNC2814 with new accounts, and by other threat actors who have observed that it works.

How to Detect SaaS C2 — Including GRIDTIDE

Detecting SaaS API C2 is harder than detecting traditional C2, but not impossible. The key is shifting detection from destination-based blocking to behaviour-based anomaly detection.

1. Baseline and Alert on Google API Access by Process

In a managed enterprise environment, you know which processes legitimately call Google APIs: your browser, email client, Google Drive sync agent, and specific authorised applications. When a process that has no business calling Google APIs starts making repeated, scheduled requests to sheets.googleapis.com, that's an anomaly worth investigating.

Endpoint detection and response (EDR) tools that log process network activity can feed this detection. The key log field is: which process made the API call? Google Drive sync calling Sheets APIs is expected. bash or an unrecognised binary doing it is not.

2. Watch for Scheduled/Polling API Call Patterns

C2 communication tends to be periodic — the implant polls the command channel on a schedule. Legitimate user interaction with Google Sheets is burst-based and irregular (humans don't check spreadsheets at exactly 3-minute intervals). A process that makes exactly N requests to googleapis.com every X minutes is exhibiting machine behaviour, not human behaviour. Anomaly detection on API call timing regularity can surface this.

3. Monitor OAuth Token Authorisations

GRIDTIDE implants authenticate via Google OAuth tokens embedded at compile time (or updated via the download capability). Watch your Google Workspace admin logs for new OAuth applications requesting Sheets API access that don't correspond to approved applications in your inventory. The GRIDTIDE tokens were associated with attacker-controlled Google accounts — not your domain — but OAuth token grants from personal Gmail accounts to Google Workspace resources can also be a signal.

4. Correlate API Access with User Activity

If a host is accessing Google Sheets APIs at 03:00 local time with no logged-on user, that's suspicious regardless of the destination. Correlating network API calls with user session activity is a high-signal detection approach for automated implants that operate on their own schedule.

5. Threat Intel Matching on Known IOCs

Google has not yet published the full indicator list for GRIDTIDE, but IOCs from the disruption (account identifiers, spreadsheet IDs, domain names) will likely appear in threat intelligence feeds within 24-48 hours. Subscribe to Google's Threat Intelligence Group advisories and apply IOCs to your SIEM retroactively — check historical logs for the past 30-90 days for matches.

For Security Testers: SaaS C2 as an Attack Pattern to Test For

From a penetration testing and bug bounty perspective, SaaS API C2 detection gaps represent a real class of security control failure. If you're testing an organisation's detection capabilities (red team engagement, assume-breach exercise), demonstrating that you can maintain persistence and issue commands through Google Sheets — and never trigger a single alert — is a compelling finding.

Tools like C3 and similar custom C2 frameworks support SaaS channel adapters. More importantly, any red team that isn't testing whether the client can detect SaaS-channelled C2 is leaving a major detection gap unexplored.

For blue team practitioners assessing your own organisation's detection capability: set up a test Google account, write a simple script that polls a Sheets spreadsheet for commands using the Sheets API, run it from an endpoint, and check whether any alerts fire. The answer for most organisations will be: nothing. That's the finding.

The detection gaps identified above (process-based API monitoring, timing regularity, OAuth authorisation logging) can form the basis of practical detections — but many organisations have none of them in place. Validating that gap with a controlled test is the first step to closing it.

SaaS C2 Is Mainstream Now

UNC2814's use of Google Sheets is part of a broader shift in APT and financially-motivated attacker tradecraft: the migration of C2 infrastructure to platforms the defender can't block without breaking their business.

The platforms used as C2 channels in disclosed campaigns since 2023 include: Google Sheets, Google Drive, GitHub (issues and commits), Microsoft OneDrive, Slack, Telegram, Discord, Trello, and Notion. Each platform was chosen because it's in the allow-list of every enterprise perimeter and every EDR policy.

This trend has a name in the research community: Living Off Trusted Sites (LOTS) — an extension of the original Living Off The Land (LOTL) concept, which described attackers using legitimate OS tools (PowerShell, WMI, certutil) rather than custom malware. LOTS extends this to network destinations: use legitimate cloud infrastructure rather than attacker-owned servers.

The defensive implication is uncomfortable: perimeter-based detection built on destination reputation is increasingly insufficient against sophisticated attackers. Detection needs to move toward behavioural analysis at the endpoint — what processes are calling which APIs, with what patterns — rather than relying on network-level blocking of "bad" destinations.

Frequently Asked Questions