GWS - Google Platforms Phishing

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

Ogólna metodologia Phishing

Phishing Methodology - HackTricks

Google Groups Phishing

Najwyraźniej domyślnie w workspace członkowie can create groups and invite people to them. Możesz potem modyfikować wiadomość e-mail, która zostanie wysłana do użytkownika, dodając w niej linki. Ta wiadomość będzie pochodzić z adresu google, więc będzie wyglądać legit i ludzie mogą kliknąć w link.

Możliwe jest też ustawienie adresu FROM jako Google group email, aby wysyłać więcej wiadomości do użytkowników w grupie, jak na poniższym obrazie, gdzie grupa google--support@googlegroups.com została utworzona i wiadomość została wysłana do wszystkich członków grupy (którzy zostali dodani bez ich zgody)

Google Chat Phishing

Możesz być w stanie albo start a chat z osobą mając jedynie ich adres e-mail, albo wysłać invitation to talk. Co więcej, można create a Space, które może mieć dowolną nazwę (np. “Google Support”) i invite do niego członków. Jeśli zaakceptują, mogą pomyśleć, że rozmawiają z Google Support:

Tip

W moich testach jednak zaproszeni członkowie nie otrzymali nawet zaproszenia.

Możesz sprawdzić, jak to działało wcześniej tutaj: https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s

Google Doc Phishing

Kiedyś można było stworzyć pozornie legit dokument i w komentarzu wspomnieć jakiś email (np. @user@gmail.com). Google wysyłało e-mail na ten adres informując, że zostali wspomniani w dokumencie.
Obecnie to nie działa, ale jeśli przyznasz adresowi e-mail ofiary dostęp do dokumentu, Google wyśle o tym powiadomienie. Oto komunikat, który pojawia się, gdy wspomnisz kogoś:

Tip

Ofiary mogą mieć mechanizmy ochronne, które nie pozwalają, aby wiadomości wskazujące, że zewnętrzny dokument został z nimi udostępniony, dotarły na ich skrzynkę e-mail.

Google Calendar Phishing

Możesz create a calendar event i dodać tyle adresów e-mail z atakowanej firmy, ile posiadasz. Zaplanuj to wydarzenie kalendarza na 5 lub 15 min od bieżącego czasu. Spraw, by wydarzenie wyglądało legit i dodaj komentarz i tytuł wskazujący, że muszą coś przeczytać (z phishing link).

To jest alert, który pojawi się w przeglądarce z tytułem spotkania “Firing People”, więc możesz ustawić bardziej phishingowy tytuł (i nawet zmienić nazwę powiązaną z Twoim e-mailem).

Aby wyglądało to mniej podejrzanie:

  • Ustaw to tak, żeby odbiorcy nie widzieli innych zaproszonych osób
  • DO NOT wysyłaj wiadomości powiadamiających o wydarzeniu. Wtedy ludzie zobaczą jedynie ostrzeżenie o spotkaniu za 5 minut i że muszą przeczytać ten link.
  • Najwyraźniej używając API możesz ustawić na True, że people zaakceptowali wydarzenie, a nawet tworzyć komentarze w ich imieniu.

App Scripts Redirect Phishing

Możliwe jest stworzenie skryptu na https://script.google.com/ i expose it as a web application accessible by everyone, który będzie używać legit domeny script.google.com.
Przy użyciu pewnego kodu jak poniżej, atakujący mógłby sprawić, że skrypt załaduje dowolną treść na tej stronie bez przestania korzystać z tej domeny:

function doGet() {
return HtmlService.createHtmlOutput(
'<meta http-equiv="refresh" content="0;url=https://cloud.hacktricks.wiki/en/pentesting-cloud/workspace-security/gws-google-platforms-phishing/index.html#app-scripts-redirect-phishing">'
).setXFrameOptionsMode(HtmlService.XFrameOptionsMode.ALLOWALL)
}

For example accessing https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec you will see:

Tip

Należy zwrócić uwagę, że pojawi się ostrzeżenie, ponieważ zawartość jest ładowana wewnątrz iframe.

App Scripts OAuth Phishing

It’s possible to create App Scripts attached to documents to try to get access over a victims OAuth token, for more information check:

GWS - App Scripts

OAuth Apps Phishing

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

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.

Komunikat o niezweryfikowanej aplikacji

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)

Interesujące zakresy

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.

Create an OAuth App

Start creating an OAuth Client ID

  1. Go to https://console.cloud.google.com/apis/credentials/oauthclient and click on configure the consent screen.
  2. 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.
  1. 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.
  2. 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.
  1. 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:

  1. Go back to https://console.cloud.google.com/apis/credentials/oauthclient, a different option will appear this time.
  2. Select to create credentials for a Web application
  3. Set needed Javascript origins and redirect URIs
  • You can set in both something like http://localhost:8000/callback for testing
  1. 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.

git clone ttps://github.com/carlospolop/gcp_oauth_phishing_example
cd gcp_oauth_phishing_example
pip install flask requests google-auth-oauthlib
python3 app.py --client-id "<client_id>" --client-secret "<client_secret>"

Przejdź do http://localhost:8000, kliknij przycisk Login with Google, pojawi się monit z wiadomością podobną do tej:

Aplikacja pokaże access and refresh token, które można łatwo wykorzystać. Więcej informacji o tym, jak używać tych tokenów, sprawdź:

GCP - Token Persistence

Użycie glcoud

Można też wykonać pewne działania używając gcloud zamiast konsoli webowej, sprawdź:

GCP - ClientAuthConfig Privesc

Zabezpieczenia aplikacji OAuth

Domyślnie jest skonfigurowane, że każdy użytkownik w organizacji Workspace może zaakceptować dowolną aplikację OAuth z dowolnymi uprawnieniami, ale można to ograniczyć tylko do aplikacji, które żądają podstawowych informacji potrzebnych do Sign in with Google lub nie zezwalać na żadne aplikacje firm trzecich.

Co więcej, nawet jeśli zablokuje się zaufanie do zewnętrznych aplikacji firm trzecich, można zezwolić na zaufanie dowolnym aplikacjom wewnętrznym (aplikacjom utworzonym w organizacji). To zaufanie jest ustawione domyślnie.

OAuth Consent Grant Abuse: Detection & Response (Admin Reports)

Kiedy użytkownik autoryzuje aplikację OAuth, Google Workspace zapisuje to w Admin Reports OAuth Token Audit Activity (nazwa aplikacji token) z events.name ustawionym na authorize. Te zdarzenia są najlepszą telemetrią do wykrywania consent phishing i śledzenia client ID oraz scopes, które zostały przyznane.

Kluczowe pola do wyodrębnienia z zdarzenia audytu:

  • id.time, id.customerId
  • actor.email, actor.profileId
  • ipAddress, networkInfo.regionCode, networkInfo.subdivisionCode
  • events[0]['parameters'] wartości dla client_id, app_name, scope, scope_data

Najpierw ustal bazę (zmniejsz hałas): zbuduj inwentarz istniejących client ID i scopes, a następnie ustaw alerty dla nowych/rzadkich zgód.

gam all users print tokens todrive

Pomysły na detekcję (nowa/rzadka aplikacja + ryzykowne zakresy):

  • Wyzwól alert, jeśli client_id nie znajduje się na zatwierdzonej allowliście i nie był widoczny w ciągu ostatnich X dni (np. 90).
  • Wyzwól alert, jeśli przyznany scope obejmuje wysokiego ryzyka lub rzadkie zakresy, szczególnie te, które pozwalają na masowy dostęp do danych lub wpływ na łańcuch dostaw, takie jak:
  • https://mail.google.com/
  • https://www.googleapis.com/auth/gmail.readonly
  • https://www.googleapis.com/auth/drive
  • https://www.googleapis.com/auth/drive.readonly
  • https://www.googleapis.com/auth/chat.messages
  • https://www.googleapis.com/auth/chromewebstore
client_id NOT IN approved_client_ids
AND client_id NOT IN last_seen_90d
AND scope CONTAINS any(high_risk_scopes OR rare_scopes)

Reakcja / ograniczenie:

  • Unieważnij tokens dla złośliwego OAuth client ID:
gam all users delete tokens clientId <client_id>
  • Zablokuj OAuth client ID w Admin Console, cofając aplikacji dostęp do Google data.

Threat hunting pivots:

  • Wypisz aplikacje zewnętrzne, na które wyraziło zgodę mniej niż N użytkowników (rzadkie przyjęcie).
  • Sprawdź nazwę aplikacji, wydawcę, uprawnienia/zakresy oraz unikalny identyfikator aplikacji.
  • Szukaj uśpionych aplikacji, które nagle zaczynają używać ryzykownych uprawnień (możliwe dalsze działania, np. internal phishing lub kradzież danych).

Środki zaradcze:

  • Ogranicz dostęp wszystkich aplikacji stron trzecich (tylko zatwierdzone przez administratora).
  • Zezwól na ograniczony dostęp, aby użytkownicy mogli wyrażać zgodę tylko na podstawowe informacje profilu „Sign in with Google”.

Źródła

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks