If you’re monitoring a network with internet access, it’s almost inevitable that you’re going to see a lot of traffic to and from Google servers. Blending in with Google traffic by using Google as a relay may help an attacker avoid detection.

How could an attacker use Google as a relay? One way is with the Drive API, which allows automation of uploading and downloading of data through Google Drive. The API is simple and quick enough to allow for relatively solid communication between two systems. SSH, Metasploit Meterpreter sessions, and more can be relayed through Google’s servers using this API.

I’ve created a script called google_socks.py as a proof of concept. The script starts up a Python socket object, and each set of new data from the socket is pushed to drive as a new file of a specific name. Each script knows what files to read due to their names. The below diagram illustrates how two systems can communicate via this method.

The client on the left read files named “File 2”, and creates new files named “File 1”. The client on the right does the opposite. When using this method, the two sockets should be able to function as if they were directly connected, but with additional latency.

Just how well does this work? Let’s look at a few demos:

Basic Data Transfer and Shell

https://youtu.be/obtjoDRLcRs

In this video, both google_socks.py scripts listen on local ports for Netcat clients. The scripts then forward data between their sockets and Google Drive, allowing the Netcat clients to communicate.

The argument “-P 0.2” specifies a polling interval of 0.2 seconds, “-j 0” specifies 0 polling randomization (aka jitter), and “-c 0” tells the script to use the zeroth set of credentials stored in the script. Doing these things helps prevent API request rate limiting, which happens when one API client sends more than 10 queries per second to the server.

SSH

There is a tradeoff involved with using Google Drive as a relay. You get high throughput, but high latency as well. This becomes more noticeable when using things where small packets need to be sent and received in quick succession, like SSH.

https://youtu.be/oBCCU9al3Fs

In the above video there is one instance of google_socks.py listening on the local port 9090, and one instance which connects to a remote SSH server on port 22. The SSH client then connects to local port 9090, and the traffic is forwarded through Google Drive to the remote SSH server.

Meterpreter

https://youtu.be/dF2DzehDeKo

Linux Host: 192.168.56.1

Windows VM: 192.168.56.101

Kali VM: 192.168.56.102

In this demo, Meterpreter communicates with a multi-handler via Google Drive. The Kali VM produces a Meterpreter payload which connects to the Linux Host at 192.168.56.1 port 9090. The Linux host listens on 192.168.56.1 port 9090, then forwards the data to Google Drive. Another google_socks.py script relays data from Drive to the mutli handler on the Kali VM at 192.168.56.102 port 9090.

The payload is executed on the Windows VM and the Meterpreter session opens. It takes a moment for things to load fully so that meterpreter accepts commands, which is why the process list command fails initially. The screenshot command is run, and it works perfectly.

Want to try this out yourself? You can download the PoC script here on my github.

You’ll need to run –setup, which will explain how to set up API access for yourself.

Here are some good resources on the python client library:

Ready to learn more?

Level up your skills with affordable classes from Antisyphon!

Pay-What-You-Can Training

Available live/virtual and on-demand

Google Docs becomes Google SOCKS: C2 Over Google Drive

2 Comments