China Hacked 53 Organisations Using Google Sheets as Its Command-and-Control Server. Google Just Shut It Down.

Abhishek Gautam··6 min read

Quick summary

Chinese espionage group UNC2814 used Google Sheets to hide C2 traffic as normal cloud document activity. Mandiant caught it. Here is how the attack worked.

Google's Mandiant threat intelligence unit has disclosed and disrupted one of the more technically sophisticated cyberespionage campaigns of 2026. The story matters beyond the usual "nation-state hacker" headline because of the technique used: the attackers hid their command-and-control infrastructure inside Google Sheets.

If you build applications on cloud infrastructure, or you are responsible for security monitoring in an organisation that uses Google Workspace, this is directly relevant to how you think about cloud service traffic.

The campaign: UNC2814 and GRIDTIDE

The threat group is tracked as UNC2814. Google's Threat Intelligence Group (GTIG), formerly Mandiant, named the backdoor deployed GRIDTIDE. The campaign was active from at least 2017 through early 2026, targeting:

  • Telecommunications companies in Africa, Asia, and the Americas
  • Government agencies in 42 countries
  • 53 confirmed compromised organisations
  • Data stolen: full names, phone numbers, dates of birth, voter IDs, national identification numbers

The scale — 53 organisations, 42 countries, 9 years active — makes this one of the larger publicly disclosed espionage operations. The longevity suggests the C2 technique was effective at evading detection for years.

The technical method: using Google Sheets as a C2

This is the part that should interest every security-conscious developer.

Traditional command-and-control (C2) infrastructure looks like this: compromised machine → custom protocol → attacker-controlled server → instructions back to machine. Security tools detect this by watching for unusual outbound connections to unknown IP addresses or domains.

GRIDTIDE bypassed this detection model entirely. Instead of a custom C2 server, the backdoor connected to a Google Sheets document. The attack flow:

  • Initial compromise (phishing or supply chain) installs GRIDTIDE on the target machine
  • GRIDTIDE makes regular HTTPS requests to the Google Sheets API — indistinguishable from a user syncing a spreadsheet
  • Attackers update cells in the spreadsheet with encoded commands
  • GRIDTIDE reads the cell values, decodes them, and executes the instructions
  • Results are written back to different cells in the same spreadsheet

From a network monitoring perspective, the outbound traffic looks identical to a Google Workspace user accessing their documents. The source IP is a Google IP address. The protocol is standard HTTPS. There is no unusual domain. There is no custom port.

This technique is called "living off trusted infrastructure" or "abusing legitimate web services for C2." It is not new — attackers have used Dropbox, GitHub, Slack, and Twitter for C2 in various campaigns. But the sophistication here is the persistence: this ran for nine years.

What Google did to stop it

Google's response had two components:

  • Account termination: The Google accounts used to host the C2 spreadsheets were identified and terminated, severing the communication channel.
  • Detection deployment: Google Workspace security policies were updated to detect this pattern — repeated, programmatic, API-based access to spreadsheets with no human interaction pattern, writing and reading structured data at regular intervals.

This illustrates the structural difficulty with this attack class: to defeat it, the cloud provider itself has to take action. Network-level defenders at the target organisation could not have blocked "traffic to Google" without blocking all Google Workspace functionality.

What this means for developers

If you build applications that connect to Google Sheets (or any cloud service), consider the monitoring implications:

  • Your application's cloud service traffic is now indistinguishable from C2 traffic using the same technique
  • Security operations teams are starting to look at cloud service API access patterns, not just raw network destinations
  • Applications that access cloud services should document expected access patterns so anomalies can be identified

If you are responsible for organisational security:

  • Audit which applications in your environment access Google Sheets, Docs, Drive, or other cloud storage APIs
  • Distinguish between user-initiated and programmatic access — the latter deserves more scrutiny
  • Consider whether your monitoring can identify structured, non-human interaction patterns with cloud services

If you are building security tooling:

  • The GRIDTIDE technique represents a class of C2 evasion that requires cloud-provider cooperation to defeat at the network level
  • Detection at the endpoint (GRIDTIDE's behaviour on the compromised machine) is more tractable than detection at the network layer

The data stolen and why it matters

The campaign targeted voter IDs and national identification numbers alongside standard contact data. This data profile is consistent with two use cases: building voter databases for influence operation targeting, and building identity profiles for future targeted phishing or compromise operations.

The combination of phone numbers, full names, national IDs, and voter registration data from 42 countries is an intelligence asset with long-term value — names change, but national ID numbers typically do not.

The 42-country distribution, concentrated in Africa and Asia, aligns with regions where Chinese infrastructure investment (Belt and Road) and diplomatic engagement has been most active. Governments in these regions are both counterparty to Chinese economic relationships and potential targets for political intelligence collection.

The Google Sheets C2 takeaway

The core lesson from GRIDTIDE is architectural: defenders cannot rely on blocking "unusual" network traffic when attackers are deliberately generating "usual" network traffic. The distinction between legitimate cloud service use and adversarial cloud service use is behaviour, not destination.

Detection requires:

  • Endpoint behaviour analysis (what is the process doing on the machine?)
  • API usage pattern analysis (is the access pattern consistent with human use?)
  • Cross-correlation across organisations (is this spreadsheet accessed by machines across multiple organisations?)

None of these are trivial to implement. GRIDTIDE ran for nine years before being disrupted. The next campaign using this technique — or a variant using Microsoft OneDrive, Notion, or another trusted service — may already be running.

ShareX / TwitterLinkedIn

Written by

Abhishek Gautam

Full Stack Developer & Software Engineer based in Delhi, India. Building web applications and SaaS products with React, Next.js, Node.js, and TypeScript. 8+ projects deployed across 7+ countries.

Free Weekly Briefing

The AI & Dev Briefing

One honest email a week — what actually matters in AI and software engineering. No noise, no sponsored content. Read by developers across 30+ countries.

No spam. Unsubscribe anytime.