Lesson 1.1: Case Study: Google Sheets Espionage Campaign

Compliance Framework Mapping

Introduction

Welcome to Lesson 1.1: Case Study: Google Sheets Espionage Campaign! Over the next 45 minutes, we will explore how a state-linked threat actor turned a common collaboration tool into a global surveillance platform, targeting telecommunications and government bodies.

But first, let me tell you about Marcus Webb.

It's 10:30 on a Tuesday in October. Marcus Webb, a senior network engineer at a European telecoms provider in Brussels, is reviewing a quarterly performance report. The office hums with the low murmur of colleagues and the faint scent of coffee. His screen is a mosaic of network diagrams and data logs.

An email notification pops up. It's from a colleague he met at a conference last year, sharing what looks like a project planning document. The subject line is innocuous: 'Follow-up on our discussion re: infrastructure resilience.' The email body is brief, polite, and contains a link to a Google Sheet. Marcus clicks it.

The sheet opens in his browser. It looks legitimate—a simple Gantt chart with placeholder text. Nothing happens. No warnings, no prompts. He closes the tab and gets back to work. He never stood a chance.

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: The Unseen Campaign

Imagine a spy who doesn't break into your office but instead leaves a notebook in a public library, waiting for you to write your secrets in it. That's the essence of this campaign. It wasn't a smash-and-grab; it was a patient, open invitation.

A Global Operation

This wasn't a random attack. Research suggests the campaign was linked to a China-nexus threat actor, specifically targeting telecommunications companies and government entities. The goal was sustained espionage.

The attackers didn't focus on one region. They cast a wide net, with victims identified across 42 different countries. This indicates a strategic, intelligence-gathering operation with broad geopolitical objectives.

The choice of telecoms is telling. These organisations form the backbone of national communication. Compromising them provides a unique vantage point into the data and communications of millions, including government officials and critical infrastructure operators.

The Delivery Mechanism

The primary tool was Google Sheets. The attackers sent emails with links to these documents. Because Google's domain is trusted and ubiquitous, the links rarely triggered email security filters.

When a target like Marcus clicked the link, the sheet would load. Embedded within it was a malicious script. This script could communicate with attacker-controlled servers, acting as a beacon and a command channel, all while looking like a normal, cloud-hosted document.

DORA Article 5-17 DORA requires financial entities to have strong ICT risk management. This incident shows how risk isn't just about your own systems, but extends to the third-party services, like cloud productivity suites, that your staff use every day.

ISO A.8.1 ISO 27001 A.8.1 mandates that assets are identified and ownership assigned. In this case, the data an employee accesses and inputs into a third-party cloud sheet is still an organisational asset that needs protection.

Content Section 2: The Technical Deception

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

The Attack Flow

Step 1: Reconnaissance. The attackers identified targets like Marcus—engineers in telecoms. They crafted a believable pretext, often referencing past professional contact.

Step 2: Delivery. A phishing email arrives with a link to a Google Sheet. The email is well-written and relevant, increasing the chance of a click.

Step 3: Execution. The sheet loads. A script within it activates. This script doesn't attack Marcus's computer directly. Instead, it phones home to a server controlled by the attackers, establishing a connection.

Step 4: Persistence & Theft. Through this channel, the attackers can send commands. They might task the script with stealing session cookies from the victim's browser, capturing data entered into the sheet, or even probing the internal network from the victim's logged-in browser session.

Living-off-the-Cloud

This technique is sometimes called 'living-off-the-cloud.' The attackers use legitimate, trusted cloud services as their infrastructure. There's no malware file to scan, no suspicious domain to block initially. The malicious activity is wrapped in the guise of normal Google traffic.

The command and control servers weren't on shady domains; they were often other compromised websites or cloud instances. This makes detection based on reputation or blocklists very difficult until the pattern is understood.

Why Traditional Defences Stumble

Notice what all of these methods have in common. They rely on spotting something known-bad. This attack hides in plain sight, using nothing but trusted, allowed services in a malicious way.

Standard security tools are built for a different kind of attack. Here’s how this campaign gets past them:

NIST PR.IP-12 NIST CSF PR.IP-12 calls for a vulnerability management plan. This incident highlights a non-technical vulnerability: the trust and lack of controls around how staff use sanctioned cloud applications, which must be addressed by policy and training.

NIS2 Article 21 NIS2 mandates risk management measures. For essential entities like telecoms, this means assessing risks from supply chains and third-party services, including the SaaS platforms that have become integral to operations.

Content Section 3: Finding the Signal in the Noise

Marcus's computer knew something was wrong. The network saw the connections. It just couldn't tell him. Detection requires looking for subtle anomalies in otherwise normal behaviour.

Network-Level Indicators

Look for Google Sheets documents making network calls to non-Google domains. While sheets can import data, a call to an unknown or newly registered domain is a major red flag.

Monitor the volume and timing of requests. A sheet that makes frequent, small calls to an external server at regular intervals may be beaconing, checking for commands.

SSL inspection can reveal the full URL. A request from a Google Sheet to a path like '/c2/collect' or '/api/register' is clearly malicious, but you need to be able to see it.

Endpoint-Level Indicators

Browser forensics is key. Examine browser extensions and scripts running in tabs. A process tied to a Google Sheets tab making anomalous network requests is suspect.

Monitor for unusual processes spawned by the browser. While the initial attack is fileless, follow-on actions might attempt to run scripts or executables delivered through the C2 channel.

User & Behavioural Signals

This is where User and Entity Behaviour Analytics (UEBA) can help. A user who never accesses Google Sheets suddenly creating or clicking links to them is an anomaly.

Correlate email clicks with subsequent network activity. Security tools that can link Marcus clicking a link in an email at 10:30 to a new, persistent outbound connection from his browser session at 10:31 provide critical context.

SOC2 CC6.1 SOC 2 CC6.1 requires logical access controls to protect assets. This incident shows that logical access extends to web sessions. Monitoring and controlling what those authenticated sessions are allowed to do—like which external sites a browser tab can contact—is part of logical security.

GDPR Article 32 GDPR Article 32 requires appropriate security for personal data. If an employee's compromised browser session is used to access customer databases, that personal data is at risk. Measures to detect and prevent such session compromise are part of GDPR security obligations.

Content Section 4: Building Your Evidence

Compliance isn't about a checklist; it's about proving you've thought through the risks. This lesson provides the raw material for that proof.

Evidence Generation

This lesson provides documentation for multiple compliance frameworks:

For DORA Article 5-17 auditors... For DORA auditors, you can now demonstrate that staff training and risk assessments consider threats from the misuse of third-party ICT services, specifically cloud-based collaboration tools.

For ISO A.8.1 auditors... For ISO 27001 assessors, you can evidence that the organisation has identified data processed in third-party cloud applications as an asset requiring protection, as shown in this threat analysis.

For NIST PR.IP-12 auditors... For NIST CSF reviewers, you can show that vulnerability management processes have been expanded to include user-centric vulnerabilities and SaaS configuration risks, informed by real-world campaigns.

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 (e.g., schedule a meeting with the security team to discuss cloud app policies)

Conclusion

Let me tell you how Marcus's story ended.

Six weeks later, a threat intelligence alert flagged anomalous traffic from his workstation to a server in a foreign country. The investigation traced it back to that Google Sheet. His network access was revoked immediately. He faced a disciplinary review, not for malice, but for a lapse in judgement that cost the company. The personal stress was significant.

His organisation eventually implemented a new security gateway that could inspect and control traffic from sanctioned cloud apps. They also rolled out mandatory, scenario-based training on cloud phishing. The policy on external document links was rewritten to be stricter. It was a costly lesson learned after the fact.

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

You should now understand how trusted cloud platforms can be weaponised for espionage. You understand the 'living-off-the-cloud' technique and why it bypasses common defences. You know the key behavioural and technical indicators that can reveal such a campaign. And you understand how to start building policies and controls to address this modern threat.

Next, we'll explore Next, we'll explore Lesson 1.2: The Supply Chain Backdoor. We'll look at how attackers are compromising one vendor to reach hundreds of targets, and what your procurement team needs to ask before signing a contract.

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 (like Sheets calling non-Google domains) and immediate response steps (isolate endpoint, revoke OAuth/browser sessions) for the Google Sheets espionage technique on a single page.
• Compliance Mapping Worksheet - Map your organisation's controls for cloud application security and user awareness training against the DORA, NIST CSF, and ISO 27001 requirements highlighted by this case study.
• Risk Assessment Template - Assess your organisation's specific exposure to 'living-off-the-cloud' threats based on your sanctioned SaaS applications and the user behaviours identified in this lesson.
• Further reading - Links to official framework documentation (e.g., NIST SP 800-53) and threat intelligence reports on nation-state cloud-based espionage campaigns for deeper research.

China-linked hackers used Google Sheets to spy on telecoms and governments across 42 countries Defence Masterclass | Threat Intelligence | Lesson 1.1
© LimitedView Limited | 2026