GWS - Google Platforms Phishing
Last updated
Last updated
Apprenez et pratiquez le hacking AWS :Formation HackTricks AWS Red Team Expert (ARTE) Apprenez et pratiquez le hacking GCP : Formation HackTricks GCP Red Team Expert (GRTE)
Apparemment, par défaut, dans Workspace, les membres peuvent créer des groupes 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.
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)
Vous pourriez être en mesure de démarrer une discussion avec une personne simplement 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 :
Cependant, lors de mes tests, 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
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 :
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.
Vous pouvez créer un événement de calendrier et ajouter autant d'adresses email de l'entreprise que vous avez. 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).
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).
Pour le rendre moins suspect :
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 à True que les personnes ont accepté l'événement et même créer des commentaires en leur nom.
Il est possible de créer un script sur 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 :
Par exemple, en accédant à https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec, vous verrez :
Notez qu'un avertissement apparaîtra lorsque le contenu sera chargé à l'intérieur d'une iframe.
Il est possible de créer des scripts d'application attachés à des documents pour essayer d'accéder au token OAuth d'une victime. Pour plus d'informations, consultez :
GWS - App ScriptsN'importe laquelle des techniques précédentes peut être utilisée pour amener l'utilisateur à accéder à une application OAuth Google qui demande à l'utilisateur certains accès. Si l'utilisateur fait confiance à la source, il peut faire confiance à l'application (même si elle demande des autorisations très privilégiées).
Notez que Google présente un prompt peu attrayant avertissant que l'application est non fiable dans plusieurs cas, et les administrateurs de Workspace peuvent même empêcher les gens d'accepter des applications OAuth.
Google permet de créer des applications qui peuvent interagir au nom des utilisateurs avec plusieurs services Google : 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.
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.
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.
Ce prompt apparaît dans les applications qui :
Utilisent un scope qui peut 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é)
Ici, vous pouvez trouver une liste de tous les scopes OAuth de Google.
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, URL de calendrier de tous les utilisateurs.
Commencez à créer un ID client OAuth
Allez sur https://console.cloud.google.com/apis/credentials/oauthclient et cliquez sur configurer l'écran de consentement.
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.
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.
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 à sa catégorie. En fonction des 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.
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.
Maintenant, obtenons des identifiants pour une application web en utilisant l'ID client OAuth précédemment créé :
Retournez sur https://console.cloud.google.com/apis/credentials/oauthclient, une option différente apparaîtra cette fois.
Sélectionnez créer des identifiants pour une application web.
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.
Obtenez vos identifiants d'application.
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.
Allez à http://localhost:8000, cliquez sur le bouton Connexion avec Google, vous serez invité avec un message comme celui-ci :
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 :
GCP - Token PersistanceglcoudIl est possible de faire quelque chose en utilisant gcloud au lieu de la console web, consultez :
GCP - ClientAuthConfig Priveschttps://www.youtube-nocookie.com/embed/6AsVUS79gLw - Matthew Bryant - Hacking G Suite : Le pouvoir de la magie des scripts d'applications sombres
https://www.youtube.com/watch?v=KTVHLolz6cE - Mike Felch et Beau Bullock - OK Google, comment puis-je Red Team GSuite ?
Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE) Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)
