Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apparently, by default, in workspace members can create groups and invite people to them. You can then modify the email that will be sent to the user adding some links. The email will come from a google address, so it will look legit and people might click on the link.
It's also possible to set the FROM address as the Google group email to send more emails to the users inside the group, like in the following image where the group google--support@googlegroups.com was created and an email was sent to all the members of the group (that were added without any consent)
You might be able to either start a chat with a person just having their email address or send an invitation to talk. Moreover, it's possible to create a Space that can have any name (e.g. "Google Support") and invite members to it. If they accept they might think that they are talking to Google Support:
In my testing however the invited members didn't even receive an invitation.
You can check how this worked in the past in: https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s
In the past it was possible to create an apparently legitimate document and the in a comment mention some email (like @user@gmail.com). Google sent an email to that email address notifying that they were mentioned in the document. Nowadays, this doesn't work but if you give the victim email access to the document Google will send an email indicating so. This is the message that appears when you mention someone:
Victims might have protection mechanism that doesn't allow that emails indicating that an external document was shared with them reach their email.
You can create a calendar event and add as many email address of the company you are attacking as you have. Schedule this calendar event in 5 or 15 min from the current time. Make the event look legit and put a comment and a title indicating that they need to read something (with the phishing link).
This is the alert that will appear in the browser with a meeting title "Firing People", so you could set a more phishing like title (and even change the name associated with your email).
To make it look less suspicious:
Set it up so that receivers cannot see the other people invited
Do NOT send emails notifying about the event. Then, the people will only see their warning about a meeting in 5mins and that they need to read that link.
Apparently using the API you can set to True that people have accepted the event and even create comments on their behalf.
It's possible to create a script in https://script.google.com/ and expose it as a web application accessible by everyone that will use the legit domain script.google.com.
The with some code like the following an attacker could make the script load arbitrary content in this page without stop accessing the domain:
For example accessing https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec you will see:
Note that a warning will appear as the content is loaded inside an iframe.
It's possible to create App Scripts attached to documents to try to get access over a victims OAuth token, for more information check:
Any of the previous techniques might be used to make the user access a Google OAuth application that will request the user some access. If the user trusts the source he might trust the application (even if it's asking for high privileged permissions).
Note that Google presents an ugly prompt asking warning that the application is untrusted in several cases and Workspace admins can even prevent people accepting OAuth applications.
Google allows to create applications that can interact on behalf users with several Google services: Gmail, Drive, GCP...
When creating an application to act on behalf other users, the developer needs to create an OAuth app inside GCP and indicate the scopes (permissions) the app needs to access the users data. When a user wants to use that application, they will be prompted to accept that the application will have access to their data specified in the scopes.
This is a very juicy way to phish non-technical users into using applications that access sensitive information because they might not understand the consequences. However, in organizations accounts, there are ways to prevent this from happening.
As it was mentioned, google will always present a prompt to the user to accept the permissions they are giving the application on their behalf. However, if the application is considered dangerous, google will show first a prompt indicating that it's dangerous and making it more difficult for the user to grant the permissions to the app.
This prompt appears in apps that:
Use any scope that can access private data (Gmail, Drive, GCP, BigQuery...)
Apps with less than 100 users (apps > 100 a review process is also needed to stop showing the unverified prompt)
Here you can find a list of all the Google OAuth scopes.
cloud-platform: View and manage your data across Google Cloud Platform services. You can impersonate the user in GCP.
admin.directory.user.readonly: See and download your organization's GSuite directory. Get names, phones, calendar URLs of all the users.
Start creating an OAuth Client ID
Go to https://console.cloud.google.com/apis/credentials/oauthclient and click on configure the consent screen.
Then, you will be asked if the user type is internal (only for people in your org) or external. Select the one that suits your needs
Internal might be interesting you have already compromised a user of the organization and you are creating this App to phish another one.
Give a name to the app, a support email (note that you can set a googlegroup email to try to anonymize yourself a bit more), a logo, authorized domains and another email for updates.
Select the OAuth scopes.
This page is divided in non sensitive permissions, sensitive permissions and restricted permissions. Eveytime you add a new permisison it's added on its category. Depending on the requested permissions different prompt will appear to the user indicating how sensitive these permissions are.
Both admin.directory.user.readonly and cloud-platform are sensitive permissions.
Add the test users. As long as the status of the app is testing, only these users are going to be able to access the app so make sure to add the email you are going to be phishing.
Now let's get credentials for a web application using the previously created OAuth Client ID:
Go back to https://console.cloud.google.com/apis/credentials/oauthclient, a different option will appear this time.
Select to create credentials for a Web application
Set needed Javascript origins and redirect URIs
You can set in both something like http://localhost:8000/callback for testing
Get your application credentials
Finally, lets run a web application that will use the OAuth application credentials. You can find an example in https://github.com/carlospolop/gcp_oauth_phishing_example.
Go to http://localhost:8000 click on the Login with Google button, you will be prompted with a message like this one:
The application will show the access and refresh token than can be easily used. For more information about how to use these tokens check:
glcoudIt's possible to do something using gcloud instead of the web console, check:
https://www.youtube-nocookie.com/embed/6AsVUS79gLw - Matthew Bryant - Hacking G Suite: The Power of Dark Apps Script Magic
https://www.youtube.com/watch?v=KTVHLolz6cE - Mike Felch and Beau Bullock - OK Google, How do I Red Team GSuite?
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
