You’re a GD Thief!

Introducing a tool for exfiltrating all of the things from a Google Drive

GD-Thief

I am a Master’s of Information Security Engineering student at SANS Technology Institute (STI). I was doing my reading the other night for my SEC 530: Defensible Security Architecture and Engineering course and got into the topics of Data Classification and Data Loss Prevention (DLP). This material covered the many different methods of classifying data and of implementing DLP from a detections perspective. I am professional Red Teamer, and thus began thinking about the many different times that I had hacked my way into a victim’s Google Drive (GD) and exfiltrated data and was never detected. I then started thinking of ways that I could test DLP detections on data leaving GD. How could I best show the impact of lack of DLP detections on data leaving a GD? Most of the time I just manually searched and pillaged through a GD when looking for sensitive data to exfiltrate. What if I could develop an app that would allow me to programmatically, and easily exfiltrate an entire drive, or even just exfiltrate files that contain sensitive data? This would allow me to test DLP detections an exfiltrate data at a large enough scale to show maximum impact to the organization.

This is what I did. Enter GD-Thief.

What is GD-Thief?

Have you ever been on a Red Team Operation where you have access to a victim’s G-Suite, you are rifling through the victim’s GD, and you wished you had a way to quickly download all of the files? Well that’s what GD-Thief does. GD-Thief is a script I wrote in python that allows the Red Teamer to download every file in the victim’s drive. But, wait there’s more!

GD-Thief not only downloads all of the files in the victim’s drive, but it also downloads all of the files from drives shared with the victim, and all of the drives in the victim’s corporate domain that the victim has access to. So, you are getting it all! But, wait there’s more!

GD-Thief allows for the Red Teamer to only search for files that contain specific strings via a wordlist. So, if you want to look for only files that contain the words, “password,” “username,” or “pastrami” just add the words to your wordlist/dictionary and GD-Thief will search all of the files for these keywords within the file’s entire content, and download only those files of interest. But, wait there’s more!

You think searching text file content for words of interest is cool, what if I told you GD-Thief performs Optical Character Recognition (OCR) to search for the same specified strings in image files and pictures. Yeah, so if the victim took a picture of the menu at their local Capriotti’s sandwich shop and stored it in their GD, GD-Thief will find the “pastrami.”

How does it work?

GD-Thief uses the Google Drive API to make calls to the victim’s GD. The Red Teamer will need to create an external, testing, Google App, get an API key for the App, give the App permissions to access the required GD APIs, and will need to add the victim’s Gmail address to the list of application testers. I will explain how all of this is done in the tutorial below.

Now, adding testers to the application’s tester list does not inform the individual that you add that they have been added to the list. They do not need to give permission to be, acknowledge that they are, nor authorize that they be added to the tester list. I find this to be a security issue, and disclosed this to Google on April 23rd, 2021. Google responded on April 26th, 2021 and stated that this is did not meet their criteria for abuse, it is intended behavior and that it would not be fixed.

Security Bug Reported 4/23/21
Google’s response
Google won’t fix

Yes, the attacker must already have access to the victim’s Google account in order to use this application to do harm, but as an extra layer of security, for detection and alerting purposes, or for an early-warning purpose this just might allow the victim to become aware that they are under attack. Especially if it required the target to authorize being added to the tester list using two-factor authentication (2FA).

A Very Effective Attack Path

Getting access to a target’s Google account can be accomplished fairly easy. I have accomplished this on MANY Red Team operations via a Machine-in-the-Middle (MitM) attack using EvilGinx2 to create a fake Okta page for the target organization. EvilGinx2 basically proxies the authentication traffic sent to the fake web application page (Okta in this case) and forwards it to the real web application page using the credentials provided by the victim. It logs the victim in to the real web application and sends the credentials to the attacker controlled, EvilGinx2 server. This even bypasses 2FA. Let us discuss how this works in greater detail:

EvilGinx2 Attack Path

Now that you have an Okta session, you are almost guaranteed to have a G-Suite session, and thus a GD session as long as the victim organization hosts a Google, Okta tile in their Okta portal. Now you are good to go exfiltrating files from the victim’s GD.

A Tutorial for Using GD-Thief

Before you ever get a session on a victim’s Google account as described above, you need to do a few things. First you’ll need Python3. Next you’ll need to download GD-Thief from GitHub:

git clone https://github.com/antman1p/GD-Thief.git

Next you’ll need to get the Google API, Python libraries:

pip install — upgrade google-api-python-client google-auth-httplib2 google-auth-oauthlib

Now you will need to follow the steps below to give GD-Thief access to the GD API.

Create a new Google Cloud Platform (GCP) project

Steps to get the Google API Access Token needed for connecting to the API

Create a new project

6. In the Project Name field, enter a descriptive name for your project.

7. (Optional) To edit the Project ID, click Edit. The project ID can't be changed after the project is created, so choose an ID that meets your needs for the lifetime of the project.

8. Click Create. The console navigates to the Dashboard page and your project is created within a few minutes.

Name the project

Enable a Google Workspace API

API & Services Library

3. Click Enable APIs and Services. The "Welcome to API Library" page appears.

4. In the search field, enter "Google Drive".

5. Click the Google Drive API to. The API page appears.

Search for GD API

6. Click Enable. The Overview page appears.

Enable GD API

Configure OAuth Consent Screen

Configure Consent Screen

3. Click the External user type for your app.

4. Click Create. A second "OAuth consent screen" screen appears.

OAuth External Application Consent

5. Fill out the form: Enter an Application Name in the App name field. Enter your burner email address in the User support email field. Enter your burner email address in the Developer contact information field.

Application Info

6. Click Save and Continue. The "Scopes" page appears.

Save Application Info

7. Click Add or Remove Scopes. The "Update selected scopes" page appears.

Add or Remove Scopes

8. Check all of the Google Drive the scopes to use in the app. GD scopes cover 2 pages, so click the next page and ensure that you check them all.

Check all GD API Scopes

9. Click Update. A list of scopes for your app appears.

Update Scope
Scope list

10. Click Save and Continue. The "Edit app registration" page appears.

Save Scope

11. Click Save and Continue. The "OAuth consent screen" appears.

Create a credential

Create OAuth Client ID Credentials

2. Click the Application type drop-down list and select Desktop Application.

3. In the name field, type a name for the credential. This name is only shown in the Cloud Console.

Select “Desktop App,” name it, and create

4. Click Create. The OAuth client created screen appears. This screen shows the Client ID and Client secret.

5. Click OK. The newly created credential appears under "OAuth 2.0 Client IDs."

OAuth Client created

6. Click the download button to the right of the newly-created OAuth 2.0 Client ID. This copies a client secret JSON file to your desktop. Note the location of this file.

7. Rename the client secret JSON file to “credentials.json” and move it to the gd_thief/credentials directory.

Add the victim’s Google account to the Application’s Test Users

In order to be able to run this script against the victim, you will need to add their Google account to the Test Users list for the App you just created.

This is the part that I reported to Google since it does not inform the user you add to this list that they have been added to an application for testing, nor does it require their authorization.

3. Enter the victim’s Gmail address in the email address field.

4. Click the save button.

Add test user

First Time running gd_thief

Upon gaining access to a Target’s Google account, you can run gd_thief

Using GD-Thief

Usage for GD-Thief is pretty simple. I won’t rewrite the usage here since it is fully described on the GD-Thief, GitHub README and in the application help, but just make sure you are using Python3.

python3 gd-thief.py …

Wrapping up

Hopefully this tool comes in handy for you on your next Red Team operation, or for a DLP penetration test. Next, I would like to add functionality for a search option that uses Snort’s Sensitive Data Processor regex to find sensitive data in the GD like credit card numbers, social security numbers, email addresses, etc.…

For more Google API abuse, checkout my blog post and tool for Google Calendar Phishing:

Gone Calishing: A Red Team Approach to Weaponizing Google Calendar

https://github.com/antman1p/G-Calisher

A special thanks to my good friend Cedric Owens for helping me with the threading on this app. The mass download FLIES now!

As always, thanks for reading!