Lesson 1.1: Case Study: Google Sheets C2 Campaign

Compliance Framework Mapping

Introduction

Welcome to Lesson 1.1: Case Study: Google Sheets C2 Campaign! Over the next 45 minutes, we will explore how a trusted, everyday business tool was weaponised for espionage, and what that means for your organisation's defences.

But first, let me tell you about Marcus Webb.

It's 2:30 PM on a Tuesday in October. Marcus, a senior network engineer at a defence contractor in Virginia, is reviewing firewall logs. The office hums with the low drone of servers and the faint smell of stale coffee. His screen is a mosaic of green and amber status lights, a familiar and reassuring sight.

A routine alert flags an outbound connection from a developer's workstation. The destination is a Google API domain—docs.google.com. This isn't unusual; the team uses Google Workspace. But the pattern is odd. It's a short, encrypted burst of data every 90 seconds, like a steady, quiet heartbeat. It doesn't match any known application behaviour.

Marcus tags the event for review and moves on, assuming it's a new feature in a beta application. He makes a note to check with the developer later. That decision, to prioritise other alerts, was the moment. The quiet heartbeat was not an application. It was a live command-and-control channel, and it was already exfiltrating sensitive design documents.

This is the story of a Cyberattack. By the end of this lesson, you'll understand exactly why Marcus never stood a chance, and more importantly, what could have saved him.

Content Section 1: What is a Living-Off-Land C2?

Think of your organisation's network as a city. Traditional malware is like a stranger in a bright orange jacket—easy to spot. A living-off-the-land attack is like a stranger who puts on a local uniform, uses the public buses, and speaks the dialect. They blend in perfectly.

The Google Sheets Campaign

In this campaign, state-backed actors didn't deploy malicious servers. They used Google Sheets as their command centre. Infected machines would call out to a specific, seemingly innocent spreadsheet. The attackers would place their commands—like 'collect files' or 'run this tool'—into cells of that sheet. The malware would read those cells and execute the instructions.

The return traffic, the stolen data, was often hidden within image files uploaded to Google Drive or encoded within legitimate-looking API communications. To network security tools, it all looked like normal, encrypted traffic to google.com—a domain almost always whitelisted.

This method bypassed the primary defence of blocking connections to known bad domains or IP addresses. The infrastructure was Google's, which is trusted, reliable, and globally distributed.

The Strategic Advantage

The business model here isn't about money; it's about access and stealth. The 'cost' for the attacker is a free Google account. The return is persistent, hard-to-detect access to high-value targets.

Research suggests these campaigns are often highly targeted. They focus on sectors like defence, technology, and government. The goal is intellectual property theft and long-term espionage, not a quick ransomware payout.

DORA Article 5 DORA Article 5 requires financial entities to have a full ICT risk management framework. This incident shows why that framework must account for threats that abuse trusted third-party services, not just direct attacks on your own systems.

ISO A.12.6.1 ISO 27001 A.12.6.1 mandates managing technical vulnerabilities. The vulnerability here wasn't in software; it was in the trust and configuration of a cloud service. Your management processes need to cover the misuse of authorised services.

Content Section 2: The Anatomy of the Attack

Understanding the step-by-step flow reveals why it's so effective. Let me show you exactly how Marcus's colleague was compromised.

The Infection Chain

Step 1: Initial Access. It often starts with a spear-phishing email. A contractor receives a message that appears to be from a partner organisation. It contains a link to a document hosted on what looks like a legitimate Google Drive page, but is actually a phishing site.

Step 2: Execution. The contractor enters their Google credentials. The attackers steal them. Alternatively, the link might trigger a drive-by download exploiting a browser vulnerability, dropping a small initial payload.

Step 3: Persistence & C2. The payload runs a script. Its first job is to reach out to a pre-defined Google Sheet ID and read a specific cell, say, 'A1'. The cell contains the next command, like a URL to download a more full-featured tool.

Data Exfiltration

Stolen data isn't sent to a suspicious foreign server. It's packaged into a file—maybe a PNG image with data hidden in the pixel data (steganography)—and uploaded to the attacker's controlled Google Drive account.

From the network's perspective, this is just an upload to drive.google.com. The data is encrypted in transit by TLS, and the destination domain is trusted. Data loss prevention (DLP) systems looking for transfers to unknown sites see nothing wrong.

Why Traditional Defences Fail

Notice what all of these methods have in common. They rely on distinguishing 'bad' from 'good'. This attack operates entirely within the realm of 'good'.

Here’s how common security measures are bypassed:

NIST DE.CM-1 NIST CSF DE.CM-1 requires network monitoring to detect events. This attack forces a shift from looking for 'bad' traffic to looking for *anomalous* patterns within good traffic, like a single machine polling a Google Sheet every 90 seconds indefinitely.

NIS2 Article 21 NIS2 Article 21 mandates risk management measures. Managing the risk from trusted SaaS platforms requires specific policies on configuration, monitoring, and user training that go beyond traditional network security.

Content Section 3: Finding the Signal in the Noise

Marcus's network knew something was wrong. It just couldn't tell him. The clues were there, hidden in patterns of behaviour, not in blacklisted domains.

Network-Level Indicators

Look for beaconing: a machine making regular, periodic HTTPS requests to the same Google Sheets API endpoint at a fixed interval (e.g., every 60, 90, 120 seconds). This is robotic behaviour unlike a human user.

Monitor for unusual volumes of data uploaded to Google Drive from a single user or machine, especially outside of normal working hours or involving file types not typical for that user.

Correlate authentication logs. A user accessing Google Sheets from their workstation in London and, two minutes later, from an IP in a foreign country is a strong indicator of compromised credentials being used by an attacker.

Endpoint-Level Indicators

Process lineage is key. Look for scripting hosts (powershell.exe, cmd.exe, wscript.exe) making network connections to Google APIs. A PowerShell script that downloads content from sheets.google.com is highly suspicious.

Check for the creation of scheduled tasks or persistence mechanisms that are configured to run scripts which contact Google services. The initial payload will often set this up to survive reboots.

Cloud Service Signals

Use Google Workspace audit logs. Look for the creation of new Sheets or Drive files by users that are then quickly shared with external accounts. Review sharing settings on sensitive documents.

Enable and monitor Google's own security alerts for suspicious activity, like logins from unfamiliar locations or devices. The attacker's use of stolen credentials will trigger these alerts if configured.

SOC2 CC7.1 SOC 2 CC7.1 requires detection procedures for new vulnerabilities. This incident shows your monitoring procedures must detect the *misuse* of configured services (like Google Sheets), which is a form of operational vulnerability.

GDPR Article 32 GDPR Article 32 requires appropriate security for personal data. If personal data is exfiltrated via a trusted cloud service, you must demonstrate you had monitoring in place to detect such anomalous use of that service.

Content Section 4: Building Your Evidence File

Compliance isn't about checkboxes. It's about proving you have a thoughtful, operational defence. This lesson turns awareness into auditable evidence.

Evidence Generation

This lesson provides documentation for multiple compliance frameworks:

For DORA Article 5 auditors... For DORA auditors, you can now demonstrate that your ICT risk management framework considers threats from the misuse of trusted third-party ICT services, a key operational risk.

For ISO A.12.6.1 auditors... For ISO 27001 assessors, you can evidence that your vulnerability management process includes reviewing configurations and use patterns of cloud services to prevent their abuse.

For NIST DE.CM-1 auditors... For NIST CSF reviewers, you can show that your network monitoring strategy includes detecting anomalous patterns within allowed traffic to major cloud providers, enhancing your detection capabilities.

Audit Trail

Document your completion of this lesson:

• Lesson title and date completed
• Time invested: approximately 45 minutes
• Key learnings in your own words
• Activity submission reference
• Follow-up actions identified

Conclusion

Let me tell you how Marcus's story ended.

The breach was discovered weeks later by an external threat intelligence firm, not by internal tools. By then, gigabytes of sensitive aerospace design data were gone. Marcus faced a gruelling internal investigation. While he kept his job, the incident stalled a major promotion and cast a shadow over a previously spotless career.

His organisation eventually invested in a dedicated threat-hunting team and deployed a platform that could baseline normal SaaS usage and flag behavioural anomalies. They also tightened policies around external document sharing. These changes came after the fact, a costly lesson learned the hard way.

But it doesn't have to be your story. That's why we're here.

You should now understand how attackers abuse trusted cloud services to bypass traditional defences. You understand the specific network and endpoint behaviours that signal such an attack. You know the compliance controls that mandate this level of monitoring. And you understand how to start assessing your own organisation's exposure.

Next, we'll explore Next, we'll explore Lesson 1.2: The Supply Chain Compromise. We'll look at how attackers are now targeting the software vendors you trust to get a foothold in hundreds of companies at once.

See you there.

Resources

The course materials folder contains downloadable resources for this lesson:

• Lesson 1.1 Quick Reference Card - Summarise the key detection indicators (beaconing patterns, anomalous uploads, script-to-Google-API calls) and immediate response steps for a suspected Google Sheets C2 compromise on a single page.
• Compliance Mapping Worksheet - Map your organisation's controls for monitoring trusted SaaS application usage to the specific DORA, ISO 27001, NIST CSF, NIS2, SOC 2, and GDPR framework requirements referenced in this lesson.
• Risk Assessment Template - Assess your organisation's specific exposure to living-off-the-land C2 threats based on your adoption and use of platforms like Google Workspace, Microsoft 365, and other collaborative SaaS tools.
• Further reading - Links to official framework documentation (NIST, ISO) and threat intelligence reports on adversary use of trusted cloud services for command and control.

Google catches China exploiting its Sheets to launch cyber attacks on US Orgs Defence Masterclass | Threat Intelligence | Lesson 1.1
© LimitedView Limited | 2026