Translated ['', 'src/pentesting-cloud/azure-security/az-lateral-movement

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-exchange-hybrid-impersonation.md

@@ -4,44 +4,44 @@
 
 ## Informations de base
 
-Dans les architectures Exchange Hybrid legacy, le déploiement Exchange on-prem pouvait s'authentifier en tant que la même identité d'application Entra utilisée par Exchange Online. Si un attaquant compromettait le serveur Exchange, extrayait la clé privée du certificat hybride et effectuait un flux OAuth client-credentials, il pouvait obtenir des first-party tokens avec le contexte de privilèges d'Exchange Online.
+Dans les architectures Exchange Hybrid héritées, le déploiement Exchange sur site (on-prem) pouvait s'authentifier en tant que la même identité d'application Entra utilisée par Exchange Online. Si un attaquant compromettait le serveur Exchange, extrayait la clé privée du certificat hybride et effectuait un flux OAuth client-credentials, il pouvait obtenir des tokens first-party avec le contexte de privilèges d'Exchange Online.
 
-Le risque pratique ne se limitait pas à l'accès aux boîtes aux lettres. Comme Exchange Online avait de larges relations de confiance back-end, cette identité pouvait interagir avec d'autres services Microsoft 365 et, dans des comportements plus anciens, être exploitée pour une compromission plus profonde du tenant.
+Le risque pratique ne se limitait pas à l'accès aux boîtes aux lettres. Parce qu'Exchange Online disposait de larges relations de confiance back-end, cette identité pouvait interagir avec d'autres services Microsoft 365 et, dans un comportement plus ancien, pouvait être exploitée pour une compromission plus profonde du tenant.
 
-## Voies d'attaque et flux technique
+## Voies d'attaque et déroulement technique
 
-### Modifier la configuration de fédération via Exchange
+### Modification de la configuration de fédération via Exchange
 
-Les Exchange tokens avaient historiquement des permissions pour écrire les paramètres de domaine/fédération. Du point de vue de l'attaquant, cela permettait la manipulation directe des données de confiance de domaine fédéré, y compris les listes de certificats de signature de token et les flags de configuration qui contrôlaient l'acceptation des revendications MFA depuis l'infrastructure de fédération on-prem.
+Historiquement, les tokens Exchange avaient la permission d'écrire les paramètres de domaine/fédération. Du point de vue d'un attaquant, cela permettait la manipulation directe des données de confiance des domaines fédérés, y compris les listes de certificats de signature de token et les flags de configuration qui contrôlaient l'acceptation des MFA-claim depuis l'infrastructure de fédération on-prem.
 
-Cela signifie qu'un serveur Exchange Hybrid compromis pouvait être utilisé pour orchestrer ou renforcer une usurpation de type ADFS en modifiant la configuration de fédération depuis le côté cloud, même si l'attaque avait débuté uniquement par une compromission Exchange on-prem.
+Cela signifie qu'un serveur Exchange Hybrid compromis pouvait être utilisé pour préparer ou renforcer une impersonation de type ADFS en modifiant la config de fédération depuis le cloud, même si l'attaquant avait démarré uniquement par une compromission Exchange sur site.
 
-### ACS Actor Tokens and Service-to-Service Impersonation
+### ACS Actor Tokens et impersonation service-to-service
 
-Le chemin d'auth hybride d'Exchange utilisait Access Control Service (ACS) actor tokens avec `trustedfordelegation=true`. Ces actor tokens étaient ensuite intégrés dans un second service token non signé qui portait l'identité de l'utilisateur ciblé dans une section contrôlée par l'attaquant. Parce que le token externe n'était pas signé et que l'actor token délégait largement, l'appelant pouvait remplacer les utilisateurs cibles sans se réauthentifier.
+Le chemin d'auth hybride d'Exchange utilisait des Access Control Service (ACS) actor tokens avec `trustedfordelegation=true`. Ces actor tokens étaient ensuite incorporés dans un second service token non signé qui portait l'identité de l'utilisateur cible dans une section contrôlée par l'attaquant. Parce que le token externe était non signé et que l'actor token déléguait largement, l'appelant pouvait remplacer les utilisateurs cibles sans se ré-authentifier.
 
-En pratique, une fois l'actor token obtenu, l'attaquant disposait d'une primitive d'usurpation durable (typiquement autour de 24 heures) difficile à révoquer en plein cycle de vie. Cela permettait l'usurpation d'utilisateurs à travers les APIs Exchange Online et SharePoint/OneDrive, y compris l'exfiltration de données à forte valeur.
+En pratique, une fois l'actor token obtenu, l'attaquant disposait d'un primitive d'impersonation longue durée (souvent autour de 24 heures) difficile à révoquer en cours de vie. Cela permettait l'impersonation d'utilisateurs à travers les APIs Exchange Online et SharePoint/OneDrive, y compris l'exfiltration de données à forte valeur.
 
-Historiquement, le même schéma fonctionnait aussi contre `graph.windows.net` en construisant un token d'usurpation avec la valeur `netId` de la victime. Cela permettait une action administrative Entra directe en tant qu'utilisateurs arbitraires et autorisait des workflows de takeover total du tenant (par exemple, la création d'un nouveau compte Global Administrator).
+Historiquement, le même schéma fonctionnait aussi contre `graph.windows.net` en construisant un token d'impersonation avec la valeur `netId` de la victime. Cela fournissait des actions administratives Entra directes en tant qu'utilisateurs arbitraires et permettait des workflows de prise de contrôle complète du tenant (par exemple, la création d'un nouveau compte Global Administrator).
 
 ## Ce qui ne fonctionne plus
 
-Le chemin d'usurpation `graph.windows.net` via les Exchange Hybrid actor tokens a été corrigé. L'ancienne chaîne "Exchange to arbitrary Entra admin over Graph" doit être considérée comme supprimée pour cette route de token spécifique.
+Le chemin d'impersonation via `graph.windows.net` par les Exchange Hybrid actor tokens a été corrigé. L'ancienne chaîne "Exchange vers un Entra admin arbitraire via Graph" doit être considérée comme supprimée pour cette route de token spécifique.
 
-C'est la correction la plus importante à signaler dans la documentation de l'attaque : séparer le risque d'usurpation Exchange/SharePoint de l'escalade d'usurpation Graph maintenant patchée.
+Ceci est la correction la plus importante lors de la documentation de l'attaque : garder le risque d'impersonation Exchange/SharePoint séparé de l'escalade d'impersonation Graph désormais patchée.
 
-## Ce qui peut encore être pertinent en pratique
+## Ce qui peut encore importe en pratique
 
-Si une organisation exécute encore une configuration hybrid ancienne ou incomplète avec une confiance partagée et du matériel de certificat exposé, l'impact de l'usurpation Exchange/SharePoint peut rester sévère. L'angle d'abus de la configuration de fédération peut aussi rester pertinent selon la configuration du tenant et l'état de migration.
+Si une organisation exécute encore une configuration hybrid ancienne ou incomplète avec une confiance partagée et du matériel de certificat exposé, l'impact d'impersonation Exchange/SharePoint peut rester sévère. L'angle d'abus de la configuration de fédération peut aussi rester pertinent selon la configuration du tenant et l'état de migration.
 
-La mitigation long terme de Microsoft consiste à séparer les identités on-prem et Exchange Online afin que le chemin de confiance du shared-service-principal n'existe plus. Les environnements ayant réalisé cette migration réduisent matériellement cette surface d'attaque.
+La mitigation long terme de Microsoft est de séparer les identités on-prem et Exchange Online afin que le chemin de confiance du service principal partagé n'existe plus. Les environnements ayant complété cette migration réduisent substantiellement cette surface d'attaque.
 
 ## Notes de détection
 
-Lorsque cette technique est abusée, les événements d'audit peuvent montrer des discordances d'identité où le user principal name correspond à un utilisateur usurpé tandis que le contexte d'affichage/source pointe vers une activité Exchange Online. Ce schéma d'identité mixte est un signal de chasse à haute valeur, bien que les défenseurs devraient baseliner les workflows légitimes d'Exchange-admin pour réduire les faux positifs.
+Quand cette technique est abusée, les événements d'audit peuvent montrer des mismatchs d'identité où le user principal name correspond à un utilisateur impersonné tandis que le contexte d'affichage/source pointe vers une activité Exchange Online. Ce pattern d'identité mixte est un signal de chasse hautement utile, bien que les défenseurs doivent baseliner les workflows légitimes d'admin Exchange pour réduire les faux positifs.
 
 ## Références
 
-- https://www.youtube.com/watch?v=rzfAutv6sB8
+- [https://www.youtube.com/watch?v=rzfAutv6sB8](https://www.youtube.com/watch?v=rzfAutv6sB8)
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/workspace-security/gws-google-platforms-phishing/README.md

@@ -1,60 +1,60 @@
-# GWS - Phishing sur les plateformes Google
+# GWS - Google Platforms Phishing
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Méthodologie de phishing générique
+## Generic Phishing Methodology
 
 {{#ref}}
 https://book.hacktricks.wiki/en/generic-methodologies-and-resources/phishing-methodology/index.html
 {{#endref}}
 
-## Phishing sur Google Groups
+## Google Groups Phishing
 
-Apparemment, par défaut, dans workspace, les membres [**peuvent créer des groupes**](https://groups.google.com/all-groups) **et inviter des personnes à ceux-ci**. Vous pouvez ensuite modifier l'email qui sera envoyé à l'utilisateur **en ajoutant des liens.** L'**email proviendra d'une adresse google**, donc il aura l'air **légitime** et les gens pourraient cliquer sur le lien.
+Apparemment, par défaut, dans workspace, les membres [**can create groups**](https://groups.google.com/all-groups) **and invite people to them**. Vous pouvez ensuite modifier l'e-mail qui sera envoyé à l'utilisateur **en y ajoutant des liens.** L'**email proviendra d'une adresse Google**, il paraîtra donc **légitime** et les gens pourraient cliquer sur le lien.
 
-Il est également possible de définir l'adresse **FROM** comme l'**email du groupe Google** pour envoyer **plus d'emails aux utilisateurs à l'intérieur du groupe**, comme dans l'image suivante où le groupe **`google--support@googlegroups.com`** a été créé et un **email a été envoyé à tous les membres** du groupe (qui ont été ajoutés sans aucun consentement)
+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)
 
 <figure><img src="../../../images/image (5) (1).png" alt=""><figcaption></figcaption></figure>
 
-## Phishing sur Google Chat
+## Google Chat Phishing
 
-Vous pourriez être en mesure de **démarrer un chat** avec une personne juste en ayant son adresse email ou d'envoyer une **invitation à discuter**. De plus, il est possible de **créer un Espace** qui peut avoir n'importe quel nom (par exemple "Support Google") et **inviter** des membres à celui-ci. S'ils acceptent, ils pourraient penser qu'ils parlent au Support Google :
+Vous pouvez démarrer un chat avec une personne en ayant simplement son adresse e-mail ou envoyer une invitation à discuter. De plus, il est possible de créer un Space qui peut porter n'importe quel nom (p.ex. "Google Support") et d'inviter des membres. S'ils acceptent, ils pourraient penser qu'ils parlent au support Google :
 
 <figure><img src="../../../images/image (6).png" alt=""><figcaption></figcaption></figure>
 
 > [!TIP]
-> **Cependant, lors de mes tests, les membres invités n'ont même pas reçu d'invitation.**
+> **Dans mes tests, cependant, les membres invités n'ont même pas reçu d'invitation.**
 
-Vous pouvez vérifier comment cela a fonctionné dans le passé ici : [https://www.youtube.com/watch?v=KTVHLolz6cE\&t=904s](https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s)
+You can check how this worked in the past in: [https://www.youtube.com/watch?v=KTVHLolz6cE\&t=904s](https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s)
 
-## Phishing sur Google Doc
+## Google Doc Phishing
 
-Dans le passé, il était possible de créer un **document apparemment légitime** et dans un commentaire **mentionner un email (comme @user@gmail.com)**. Google **a envoyé un email à cette adresse email** pour notifier qu'ils avaient été mentionnés dans le document.\
-Aujourd'hui, cela ne fonctionne plus mais si vous **donnez à la victime un accès email au document**, Google enverra un email l'indiquant. Voici le message qui apparaît lorsque vous mentionnez quelqu'un :
+Autrefois, il était possible de créer un **document apparemment légitime** puis, dans un commentaire, **mentionner une adresse e-mail (par ex. @user@gmail.com)**. Google **envoyait un e-mail à cette adresse** pour notifier qu'elle avait été mentionnée dans le document.\
+De nos jours, cela ne fonctionne plus, mais si vous **donnez à la victime l'accès par e-mail au document**, Google enverra un e-mail l'indiquant. Voici le message qui apparaît lorsque vous mentionnez quelqu'un :
 
 <figure><img src="../../../images/image (7).png" alt=""><figcaption></figcaption></figure>
 
 > [!TIP]
-> Les victimes pourraient avoir un mécanisme de protection qui n'autorise pas que les emails indiquant qu'un document externe a été partagé avec elles atteignent leur email.
+> Les victimes peuvent avoir des mécanismes de protection qui empêchent que ces e-mails indiquant qu'un document externe leur a été partagé n'atteignent leur boîte.
 
-## Phishing sur Google Calendar
+## Google Calendar Phishing
 
-Vous pouvez **créer un événement de calendrier** et ajouter autant d'adresses email de l'entreprise que vous attaquez. Planifiez cet événement de calendrier dans **5 ou 15 minutes** à partir de l'heure actuelle. Faites en sorte que l'événement ait l'air légitime et **mettez un commentaire et un titre indiquant qu'ils doivent lire quelque chose** (avec le **lien de phishing**).
+Vous pouvez **create a calendar event** et ajouter autant d'adresses e-mail de la société que vous attaquez que vous avez. Programmez cet événement **dans 5 ou 15 minutes** à partir de l'heure actuelle. Faites en sorte que l'événement paraisse légitime et **ajoutez un commentaire et un titre indiquant qu'ils doivent lire quelque chose** (avec le **phishing link**).
 
-Voici l'alerte qui apparaîtra dans le navigateur avec un titre de réunion "Licenciement de personnes", donc vous pourriez définir un titre plus orienté phishing (et même changer le nom associé à votre email).
+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).
 
 <figure><img src="../../../images/image (8).png" alt=""><figcaption></figcaption></figure>
 
-Pour le rendre moins suspect :
+To make it look less suspicious:
 
-- Configurez-le de sorte que **les destinataires ne puissent pas voir les autres personnes invitées**
-- **NE pas envoyer d'emails notifiant de l'événement**. Ainsi, les gens ne verront que leur avertissement concernant une réunion dans 5 minutes et qu'ils doivent lire ce lien.
-- Apparemment, en utilisant l'API, vous pouvez définir sur **True** que **les personnes** ont **accepté** l'événement et même créer **des commentaires en leur nom**.
+- Configurez-le de façon à ce que **les destinataires ne puissent pas voir les autres personnes invitées**
+- Ne **PAS envoyer d'e-mails informant de l'événement**. Ainsi, les personnes verront uniquement leur alerte concernant une réunion dans 5 minutes et qu'elles doivent consulter ce lien.
+- Apparemment, en utilisant l'API vous pouvez définir à **True** que **les personnes** ont **accepté** l'événement et même créer des **commentaires en leur nom**.
 
-## Phishing par redirection de scripts d'application
+## App Scripts Redirect Phishing
 
-Il est possible de créer un script sur [https://script.google.com/](https://script.google.com/) et **de l'exposer comme une application web accessible par tous** qui utilisera le domaine légitime **`script.google.com`**.\
-Avec un code comme le suivant, un attaquant pourrait faire en sorte que le script charge du contenu arbitraire sur cette page sans cesser d'accéder au domaine :
+Il est possible de créer un script sur [https://script.google.com/](https://script.google.com/) et de **l'exposer comme une application web accessible par tous** qui utilisera le domaine légitime **`script.google.com`**.\
+Avec un code comme le suivant, un attaquant pourrait faire charger du contenu arbitraire dans cette page tout en continuant d'accéder au domaine :
 ```javascript
 function doGet() {
 return HtmlService.createHtmlOutput(
@@ -62,100 +62,159 @@ return HtmlService.createHtmlOutput(
 ).setXFrameOptionsMode(HtmlService.XFrameOptionsMode.ALLOWALL)
 }
 ```
-Pour accéder à [https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec](https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec), vous verrez :
+Par exemple, en accédant à [https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec](https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec) vous verrez :
 
 <figure><img src="../../../images/image (4) (1).png" alt=""><figcaption></figcaption></figure>
 
 > [!TIP]
-> Notez qu'un avertissement apparaîtra lorsque le contenu sera chargé dans un iframe.
+> Notez qu'un avertissement apparaîtra car le contenu est chargé à l'intérieur d'un iframe.
 
-## Phishing OAuth des App Scripts
+## App Scripts OAuth Phishing
 
-Il est possible de créer des App Scripts attachés à des documents pour essayer d'accéder au token OAuth d'une victime, pour plus d'informations, consultez :
+It's possible to create App Scripts attached to documents to try to get access over a victims OAuth token, for more information check:
 
 {{#ref}}
 gws-app-scripts.md
 {{#endref}}
 
-## Phishing des Apps OAuth
+## OAuth Apps Phishing
 
-N'importe laquelle des techniques précédentes peut être utilisée pour amener l'utilisateur à accéder à une **application Google OAuth** qui **demande** à l'utilisateur certains **accès**. Si l'utilisateur **fait confiance** à la **source**, il pourrait **faire confiance** à l'**application** (même si elle demande des autorisations très privilégiées).
+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]
-> Notez que Google présente un prompt peu engageant avertissant que l'application est non fiable dans plusieurs cas et que les administrateurs de Workspace peuvent même empêcher les gens d'accepter des applications OAuth.
+> 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** permet de créer des applications qui peuvent **interagir au nom des utilisateurs** avec plusieurs **services Google** : Gmail, Drive, GCP...
+**Google** allows to create applications that can **interact on behalf users** with several **Google services**: Gmail, Drive, GCP...
 
-Lors de la création d'une application pour **agir au nom d'autres utilisateurs**, le développeur doit créer une **application OAuth à l'intérieur de GCP** et indiquer les scopes (permissions) dont l'application a besoin pour accéder aux données des utilisateurs.\
-Lorsqu'un **utilisateur** souhaite **utiliser** cette **application**, il sera **invité** à **accepter** que l'application aura accès à ses données spécifiées dans les scopes.
+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.
 
-C'est un moyen très juteux de **phisher** des utilisateurs non techniques en les amenant à utiliser des **applications qui accèdent à des informations sensibles** car ils pourraient ne pas comprendre les conséquences. Cependant, dans les comptes d'organisations, il existe des moyens d'empêcher cela.
+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.
 
-### Avertissement d'Application Non Vérifiée
+### Unverified App prompt
 
-Comme mentionné, Google présentera toujours un **prompt à l'utilisateur pour accepter** les permissions qu'il accorde à l'application en son nom. Cependant, si l'application est considérée comme **dangereuse**, Google affichera **d'abord** un **prompt** indiquant qu'elle est **dangereuse** et **rendant plus difficile** pour l'utilisateur d'accorder les permissions à l'application.
+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.
 
-Ce prompt apparaît dans les applications qui :
+This prompt appears in apps that:
 
-- Utilisent un scope pouvant accéder à des données privées (Gmail, Drive, GCP, BigQuery...)
-- Applications avec moins de 100 utilisateurs (pour les applications > 100, un processus de révision est également nécessaire pour arrêter d'afficher le prompt non vérifié)
+- 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)
 
-### Scopes Intéressants
+### Interesting Scopes
 
-[**Ici**](https://developers.google.com/identity/protocols/oauth2/scopes) vous pouvez trouver une liste de tous les scopes OAuth de Google.
+[**Here**](https://developers.google.com/identity/protocols/oauth2/scopes) you can find a list of all the Google OAuth scopes.
 
-- **cloud-platform** : Voir et gérer vos données à travers les services de **Google Cloud Platform**. Vous pouvez usurper l'identité de l'utilisateur dans GCP.
-- **admin.directory.user.readonly** : Voir et télécharger le répertoire GSuite de votre organisation. Obtenez les noms, téléphones, URLs de calendrier de tous les utilisateurs.
+- **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.
 
-### Créer une Application OAuth
+### Create an OAuth App
 
-**Commencez à créer un ID Client OAuth**
+**Start creating an OAuth Client ID**
 
-1. Allez sur [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient) et cliquez sur configurer l'écran de consentement.
-2. Ensuite, on vous demandera si le **type d'utilisateur** est **interne** (uniquement pour les personnes de votre organisation) ou **externe**. Sélectionnez celui qui convient à vos besoins.
-- Interne peut être intéressant si vous avez déjà compromis un utilisateur de l'organisation et que vous créez cette application pour en phisher un autre.
-3. Donnez un **nom** à l'application, un **email de support** (notez que vous pouvez définir un email de groupe Google pour essayer de vous anonymiser un peu plus), un **logo**, des **domaines autorisés** et un autre **email** pour les **mises à jour**.
-4. **Sélectionnez** les **scopes OAuth**.
-- Cette page est divisée en permissions non sensibles, permissions sensibles et permissions restreintes. Chaque fois que vous ajoutez une nouvelle permission, elle est ajoutée dans sa catégorie. Selon les permissions demandées, différents prompts apparaîtront pour l'utilisateur indiquant à quel point ces permissions sont sensibles.
-- Les permissions **`admin.directory.user.readonly`** et **`cloud-platform`** sont des permissions sensibles.
-5. **Ajoutez les utilisateurs de test.** Tant que le statut de l'application est en test, seuls ces utilisateurs pourront accéder à l'application, alors assurez-vous d'**ajouter l'email que vous allez phisher**.
+1. Go to [https://console.cloud.google.com/apis/credentials/oauthclient](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.
+3. 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**.
+4. **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.
+5. **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**.
 
-Maintenant, obtenons des **identifiants pour une application web** en utilisant l'**ID Client OAuth précédemment créé** :
+Now let's get **credentials for a web application** using the **previously created OAuth Client ID**:
 
-1. Retournez sur [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient), une option différente apparaîtra cette fois.
-2. Sélectionnez pour **créer des identifiants pour une application Web**.
-3. Définissez les **origines Javascript** et les **URI de redirection** nécessaires.
-- Vous pouvez définir dans les deux quelque chose comme **`http://localhost:8000/callback`** pour les tests.
-4. Obtenez vos **identifiants d'application**.
+1. Go back to [https://console.cloud.google.com/apis/credentials/oauthclient](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
+4. Get your application **credentials**
 
-Enfin, exécutons une **application web qui utilisera les identifiants de l'application OAuth**. Vous pouvez trouver un exemple sur [https://github.com/carlospolop/gcp_oauth_phishing_example](https://github.com/carlospolop/gcp_oauth_phishing_example).
+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](https://github.com/carlospolop/gcp_oauth_phishing_example).
 ```bash
 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>"
 ```
-Allez à **`http://localhost:8000`**, cliquez sur le bouton Login with Google, vous serez **invité** avec un message comme celui-ci :
+Allez sur **`http://localhost:8000`**, cliquez sur le bouton Login with Google, vous serez **invité·e** par un message comme celui-ci :
 
 <figure><img src="../../../images/image (333).png" alt=""><figcaption></figcaption></figure>
 
-L'application affichera le **jeton d'accès et le jeton de rafraîchissement** qui peuvent être facilement utilisés. Pour plus d'informations sur **comment utiliser ces jetons, consultez** :
+L'application affichera les **access and refresh token** qui peuvent être facilement utilisés. Pour plus d'informations sur **la façon d'utiliser ces tokens**, consultez :
 
 {{#ref}}
 ../../gcp-security/gcp-persistence/gcp-non-svc-persistence.md
 {{#endref}}
 
-#### Utilisation de `glcoud`
+#### Using `glcoud`
 
-Il est possible de faire quelque chose en utilisant gcloud au lieu de la console web, consultez :
+Il est possible de faire la même chose en utilisant gcloud au lieu de la console web ; consultez :
 
 {{#ref}}
 ../../gcp-security/gcp-privilege-escalation/gcp-clientauthconfig-privesc.md
 {{#endref}}
 
+#### Protections des apps OAuth
+
+Par défaut, il est configuré que tout utilisateur d'une organisation Workspace **peut accept any OAuth app with any permissions**, mais il est possible de restreindre cela aux seules apps qui demandent uniquement les informations de base nécessaires pour Sign in with Google, ou de ne pas autoriser de third-party apps.
+
+De plus, même en n'autorisant pas la confiance envers des third-party apps externes, il est possible d'autoriser la confiance envers n'importe quelle internal apps (apps créées au sein de l'organisation). Cette confiance est configurée par défaut.
+
+<figure><img src="../../../images/workspace_oauth.png" alt=""><figcaption></figcaption></figure>
+
+### OAuth Consent Grant Abuse: Detection & Response (Admin Reports)
+
+Lorsqu'un utilisateur autorise une OAuth app, Google Workspace l'enregistre dans l'Admin Reports OAuth Token Audit Activity (application name `token`) avec `events.name` égal à `authorize`. Ces événements constituent la meilleure télémétrie pour détecter le consent phishing et suivre le client ID et les scopes qui ont été accordés.
+
+Champs clés à extraire de l'événement d'audit :
+
+- `id.time`, `id.customerId`
+- `actor.email`, `actor.profileId`
+- `ipAddress`, `networkInfo.regionCode`, `networkInfo.subdivisionCode`
+- `events[0]['parameters']` values for `client_id`, `app_name`, `scope`, `scope_data`
+
+**Commencez par une baseline (réduire le bruit) :** constituez un inventaire des client IDs et des scopes existants, puis alertez sur les consents nouveaux/rares.
+```bash
+gam all users print tokens todrive
+```
+**Idées de détection (new/rare app + risky scopes):**
+
+- Alerter si un `client_id` **n'est pas dans une allowlist approuvée** et **n'a pas été observé au cours des X derniers jours** (par ex., 90).
+- Alerter si le `scope` accordé inclut des scopes **à haut risque ou rares**, en particulier ceux qui permettent un accès en masse aux données ou un impact sur la chaîne d'approvisionnement, tels que:
+- `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`
+```text
+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)
+```
+**Réponse / confinement:**
+
+- Révoquer les tokens pour le OAuth client ID malveillant:
+```bash
+gam all users delete tokens clientId <client_id>
+```
+- Bloquer l'ID client OAuth dans l'Admin Console en révoquant l'accès de l'application aux données Google.
+
+**Pivots pour la chasse aux menaces :**
+
+- Lister les applications externes consenties par moins de N utilisateurs (adoption rare).
+- Examiner le nom de l'application, l'éditeur, les permissions/scopes et l'ID d'application unique.
+- Rechercher des applications dormantes qui utilisent soudainement des permissions risquées (actions secondaires possibles comme phishing interne ou vol de données).
+
+**Mesures d'atténuation :**
+
+- Restreindre tout accès aux applications tierces (approuvées uniquement par l'admin).
+- Autoriser un accès limité afin que les utilisateurs ne puissent consentir qu'aux informations de profil basiques “Sign in with Google”.
+
 ## Références
 
 - [https://www.youtube-nocookie.com/embed/6AsVUS79gLw](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](https://www.youtube.com/watch?v=KTVHLolz6cE) - Mike Felch et Beau Bullock - OK Google, How do I Red Team GSuite?
+- [https://www.youtube.com/watch?v=KTVHLolz6cE](https://www.youtube.com/watch?v=KTVHLolz6cE) - Mike Felch and Beau Bullock - OK Google, How do I Red Team GSuite?
+- [https://redcanary.com/blog/threat-detection/google-workspace-oauth-attack/](https://redcanary.com/blog/threat-detection/google-workspace-oauth-attack/)
+- [https://github.com/GAM-team/GAM](https://github.com/GAM-team/GAM)
 
 {{#include ../../../banners/hacktricks-training.md}}