GWS - Google Platforms Phishing
Méthodologie de phishing générique
Phishing dans les groupes Google
Apparemment, par défaut, dans les membres de l'espace de travail peuvent créer des groupes et inviter des personnes à les rejoindre. Vous pouvez ensuite modifier l'e-mail qui sera envoyé à l'utilisateur en ajoutant des liens. L'e-mail proviendra d'une adresse google, il semblera donc légitime et les gens pourraient cliquer sur le lien.
Il est également possible de définir l'adresse FROM comme l'e-mail du groupe Google pour envoyer plus d'e-mails aux utilisateurs du groupe, comme dans l'image suivante où le groupe google--support@googlegroups.com
a été créé et un e-mail a été envoyé à tous les membres du groupe (qui ont été ajoutés sans consentement).
Phishing dans Google Chat
Vous pourriez être en mesure de démarrer une conversation avec une personne en ayant simplement son adresse e-mail ou envoyer une invitation pour 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. S'ils acceptent, ils pourraient penser qu'ils discutent avec le support Google :
Cependant, dans mes tests, les membres invités n'ont même pas reçu d'invitation.
Vous pouvez vérifier comment cela fonctionnait dans le passé sur : https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s
Phishing dans Google Docs
Dans le passé, il était possible de créer un document apparemment légitime et de mentionner dans un commentaire un e-mail (comme @user@gmail.com). Google envoyait un e-mail à cette adresse e-mail pour les informer qu'ils étaient mentionnés dans le document. De nos jours, cela ne fonctionne pas, mais si vous donnez à la victime un 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 :
Les victimes peuvent avoir un mécanisme de protection qui ne permet pas aux e-mails indiquant qu'un document externe leur a été partagé d'atteindre leur e-mail.
Phishing dans Google Agenda
Vous pouvez créer un événement dans le calendrier et ajouter autant d'adresses e-mail de l'entreprise que vous attaquez que vous le souhaitez. Planifiez cet événement dans 5 ou 15 minutes à partir de l'heure actuelle. Rendez l'événement crédible et ajoutez un commentaire et un titre indiquant qu'ils doivent lire quelque chose (avec le lien de phishing).
C'est l'alerte qui apparaîtra dans le navigateur avec un titre de réunion "Licenciement de personnes", vous pourriez donc définir un titre plus orienté phishing (et même changer le nom associé à votre e-mail).
Pour que cela paraisse moins suspect :
Configurez-le de sorte que les destinataires ne puissent pas voir les autres personnes invitées
NE PAS envoyer d'e-mails pour notifier de l'événement. Ainsi, les personnes ne verront que leur avertissement concernant une réunion dans 5 minutes et qu'elles 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.
Phishing de redirection des scripts d'application
Il est possible de créer un script sur https://script.google.com/ et de l'exposer en tant qu'application web accessible par tout le monde qui utilisera le domaine légitime script.google.com
.
Ensuite, avec un code comme le suivant, un attaquant pourrait faire en sorte que le script charge un 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 car le contenu est chargé à l'intérieur d'un iframe.
Phishing OAuth des Scripts d'Application
Il est possible de créer des Scripts d'Application attachés à des documents pour essayer d'obtenir l'accès au jeton OAuth d'une victime, pour plus d'informations consultez :
pageGWS - App ScriptsPhishing des Applications OAuth
Toutes les techniques précédentes peuvent être utilisées pour amener l'utilisateur à accéder à une application OAuth Google qui demandera à l'utilisateur un accès. Si l'utilisateur fait confiance à la source, il pourrait faire confiance à l'application (même si elle demande des autorisations très élevées).
Notez que Google présente une fenêtre d'avertissement indiquant que l'application n'est pas digne de confiance dans plusieurs cas et les administrateurs Workspace peuvent même empêcher les personnes d'accepter les 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 dans GCP et indiquer les étendues (autorisations) dont l'application a besoin pour accéder aux données des utilisateurs. Lorsqu'un utilisateur souhaite utiliser cette application, il lui sera demandé d'accepter que l'application ait accès à leurs données spécifiées dans les étendues.
C'est une manière très attrayante de phisher des utilisateurs non techniques pour qu'ils utilisent 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 de se produire.
Fenêtre d'avertissement pour les Applications non Vérifiées
Comme mentionné précédemment, Google présentera toujours une fenêtre d'avertissement à l'utilisateur pour accepter les autorisations qu'il donne à l'application en son nom. Cependant, si l'application est considérée comme dangereuse, Google affichera d'abord une fenêtre d'avertissement indiquant qu'elle est dangereuse et rendant plus difficile pour l'utilisateur d'accorder les autorisations à l'application.
Cette fenêtre d'avertissement apparaît dans les applications qui :
Utilisent une étendue 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 la fenêtre d'avertissement non vérifiée)
Étendues Intéressantes
Ici vous pouvez trouver une liste de toutes les étendues OAuth Google.
cloud-platform : Afficher et gérer vos données sur plusieurs services de la plateforme Google Cloud. Vous pouvez vous faire passer pour l'utilisateur dans GCP.
admin.directory.user.readonly : Voir et télécharger l'annuaire GSuite de votre organisation. Obtenez les noms, les numéros de téléphone, les URL de calendrier de tous les utilisateurs.
Créer une Application OAuth
Commencez par 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 le mieux à vos besoins
L'interne peut être intéressant si vous avez déjà compromis un utilisateur de l'organisation et que vous créez cette application pour phisher un autre.
Donnez un nom à l'application, un e-mail de support (notez que vous pouvez définir un e-mail de groupe Google pour essayer de vous anonymiser un peu plus), un logo, des domaines autorisés et un autre e-mail pour les mises à jour.
Sélectionnez les étendues OAuth.
Cette page est divisée en autorisations non sensibles, autorisations sensibles et autorisations restreintes. Chaque fois que vous ajoutez une nouvelle autorisation, elle est ajoutée dans sa catégorie. Selon les autorisations demandées, différents avertissements apparaîtront à l'utilisateur indiquant la sensibilité de ces autorisations.
Les deux autorisations
admin.directory.user.readonly
etcloud-platform
sont des autorisations 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'e-mail 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 de créer des identifiants pour une application Web
Définissez les origines Javascript nécessaires et les URI de redirection
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 sur http://localhost:8000
, cliquez sur le bouton Login with Google, vous serez invité avec un message comme celui-ci :
L'application affichera les jetons d'accès et de rafraîchissement qui peuvent être facilement utilisés. Pour plus d'informations sur comment utiliser ces jetons, consultez :
pageGCP - Non-svc PersistanceUtilisation de gcloud
gcloud
Il est possible de faire quelque chose en utilisant gcloud au lieu de la console web, consultez :
pageGCP - ClientAuthConfig PrivescRéférences
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?
Dernière mise à jour