mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['', 'src/pentesting-cloud/azure-security/az-lateral-movement
This commit is contained in:
Translator
+16
-16
@@ -4,44 +4,44 @@
|
||||
|
||||
## Basiese Inligting
|
||||
|
||||
In ouer Exchange Hybrid-ontwerpe kon die on-prem Exchange-implementering as dieselfde Entra-toepassingsidentiteit verifieer wat deur Exchange Online gebruik is. As 'n aanvaller die Exchange-bediener gekompromitteer het, die hybrid-sertifikaat se private sleutel uitgepluk het en 'n OAuth client-credentials-vloei uitgevoer het, kon hulle first-party tokens bekom met Exchange Online-privilegie-konteks.
|
||||
In erfenis Exchange Hybrid-ontwerpe kon die on-prem Exchange-implementering verifieer as dieselfde Entra-toepassingsidentiteit wat deur Exchange Online gebruik is. As 'n aanvaller die Exchange-bediener gekompromitteer het, die hybrid sertifikaat private sleutel onttrek het, en 'n OAuth client-credentials flow uitgevoer het, kon hulle first-party tokens met Exchange Online-privilegie-konteks bekom.
|
||||
|
||||
Die praktiese risiko het nie tot posbus-toegang beperk gebly nie. Omdat Exchange Online wye back-end vertrouensverhoudings gehad het, kon hierdie identiteit met addisionele Microsoft 365-dienste interakteer en, in ouer gedrag, benut word vir dieper tenant-kompromittering.
|
||||
Die praktiese risiko het nie tot mailbox access beperk gebly nie. Omdat Exchange Online wye back-end trust-verhoudings gehad het, kon hierdie identiteit met addisionele Microsoft 365-dienste interaksie hê en, in ouer gedrag, benut word vir dieper tenant compromise.
|
||||
|
||||
## Aanvalspaaie en Tegniese Vloei
|
||||
|
||||
### Wysig Federasiekonfigurasie via Exchange
|
||||
### Wysig federasie-konfigurasie via Exchange
|
||||
|
||||
Exchange-tokens het histories toestemmings gehad om domein-/federasie-instellings te skryf. Vanaf 'n aanvallersperspektief het dit direkte manipulering van gefedereerde domeinvertrouensdata moontlik gemaak, insluitend token-signing-sertifikaatlyste en konfigurasievlagte wat MFA-claim-aanvaarding vanaf on-prem federasie-infrastruktuur beheer het.
|
||||
Exchange tokens het histories permissies gehad om domain/federation settings te skryf. Vanuit 'n aanvallersperspektief het dit direkte manipulasie van federated domain trust-data moontlik gemaak, insluitend token-signing certificate lists en konfigurasievlae wat MFA-claim acceptance vanaf on-prem federation infrastructure beheer het.
|
||||
|
||||
Dit beteken 'n gekompromitteerde Exchange Hybrid-bediener kon gebruik word om ADFS-styl identiteitsnabootsing te plaas of te versterk deur federasie-konfigurasie vanaf die wolk te verander, selfs wanneer die aanvaller slegs vanaf on-prem Exchange-kompromittering begin het.
|
||||
Dit beteken 'n gekompromitteerde Exchange Hybrid-bediener kon gebruik word om ADFS-style impersonation te beplan of te versterk deur federasie-konfigurasie van die cloud-kant te verander, selfs wanneer die aanvaller slegs vanaf on-prem Exchange-kompromise begin het.
|
||||
|
||||
### ACS Actor Tokens en Diens-tot-Diens Identiteitsnabootsing
|
||||
### ACS Actor Tokens en Service-to-Service Impersonation
|
||||
|
||||
Exchange se hybride auth-pad het Access Control Service (ACS) actor tokens gebruik met `trustedfordelegation=true`. Daardie actor-tokens is toe ingebed in 'n tweede, ongetekende service-token wat die teiken-gebruikeridentiteit in 'n aanvallerbeheerde gedeelte gedra het. Omdat die buitenste token ongeteken was en die actor-token wyd gedelegeer het, kon die aanroeper teiken-gebruikers ruil sonder om weer te verifieer.
|
||||
Exchange se hybrid auth-pad het Access Control Service (ACS) actor tokens gebruik met `trustedfordelegation=true`. Daardie actor tokens is toe ingebed in 'n tweede, unsigned service token wat die teiken-gebruiker se identiteit in 'n aanvaller-beheerde afdeling gedra het. Omdat die buitenste token unsigned was en die actor token breed gedelegeer het, kon die aanroeper teiken-gebruikers ruil sonder herverifikasie.
|
||||
|
||||
In praktyk, sodra die actor-token verkry is, het die aanvaller 'n langlewende impersonasie-primitive gehad (tipies ongeveer 24 uur) wat moeilik was om mid-lewe te herroep. Dit het gebruikersimpersonasie oor Exchange Online en SharePoint/OneDrive APIs moontlik gemaak, insluitend eksfiltrasie van hoë-waarde data.
|
||||
In die praktyk, sodra die actor token bekom is, het die aanvaller 'n langlewende impersonation primitive gehad (tipies ongeveer 24 uur) wat moeilik mid-lifetime te beëindig was. Dit het gebruikersimpersonering oor Exchange Online en SharePoint/OneDrive APIs moontlik gemaak, insluitend high-value data exfiltration.
|
||||
|
||||
Histories het dieselfde patroon ook teen `graph.windows.net` gewerk deur 'n impersonasie-token te bou met die slagoffer se `netId`-waarde. Dit het direkte Entra-administratiewe aksie as ewekansige gebruikers toegelaat en volledige-tenant oorname-workflows (byvoorbeeld die skep van 'n nuwe Global Administrator-rekening) moontlik gemaak.
|
||||
Histories het dieselfde patroon ook teen `graph.windows.net` gewerk deur 'n impersonation token te bou met die slagoffer se `netId`-waarde. Dit het direkte Entra administratiewe aksie as willekeurige gebruikers verleen en volledige-tenant takeover-workflows moontlik gemaak (byvoorbeeld die skep van 'n nuwe Global Administrator account).
|
||||
|
||||
## Wat Nie Meer Werk Nie
|
||||
|
||||
Die `graph.windows.net`-impersonasiepad via Exchange Hybrid actor-tokens is reggestel. Die ou "Exchange to arbitrary Entra admin over Graph" ketting moet as verwyder beskou word vir hierdie spesifieke token-roete.
|
||||
Die `graph.windows.net` impersonation-pad via Exchange Hybrid actor tokens is reggestel. Die ou "Exchange to arbitrary Entra admin over Graph" ketting moet as verwyder beskou word vir hierdie spesifieke token-roete.
|
||||
|
||||
Dit is die belangrikste korrigering om te noem wanneer die aanval gedokumenteer word: hou die Exchange/SharePoint-impersonasie-risiko apart van die nou-gepatchte Graph-impersonasie-eskalasie.
|
||||
Dit is die belangrikste korreksie wanneer die aanval gedokumenteer word: hou die Exchange/SharePoint impersonation-risiko apart van die nou-gepatchte Graph impersonation escalation.
|
||||
|
||||
## Wat Nog Steeds Saakmaak in die Praktijk
|
||||
## Wat Nog Steeds Saak Maak in die Praktijk
|
||||
|
||||
As 'n organisasie steeds 'n ouer of onvolledige hybride konfigurasie met gedeelde vertroue en blootgestelde sertifikaatmateriaal loop, kan Exchange/SharePoint-impersonasie steeds ernstige gevolge hê. Die misbruikhoek van federasiekonfigurasie kan ook relevant bly, afhangende van tenant-opstelling en migrasietoestand.
|
||||
As 'n organisasie steeds 'n ou of onvolledige hybrid-konfigurasie met gedeelde trust en blootgestelde sertifikaatmateriaal draai, kan die impak van Exchange/SharePoint impersonation steeds ernstig bly. Die misbruikhoek van federasie-konfigurasie kan ook relevant bly, afhangend van tenant-opstelling en migrasiestaat.
|
||||
|
||||
Microsoft se langtermyn-mitigasie is om die on-prem en Exchange Online-identiteite te skei sodat die shared-service-principal trust-path nie meer bestaan nie. Omgewings wat daardie migrasie voltooi het, verminder hierdie aanvalsvlak aansienlik.
|
||||
Microsoft se langtermyn-mitigasie is om die on-prem en Exchange Online-identiteite te skei sodat die shared-service-principal trust-pad nie meer bestaan nie. Omgewings wat daardie migrasie voltooi het, verminder hierdie aanvalsvlak beduidend.
|
||||
|
||||
## Opsporingsnotas
|
||||
|
||||
Wanneer hierdie tegniek misbruik word, kan ouditgebeurtenisse identiteitsongelukke toon waar die user principal name ooreenstem met 'n geïmpersonifieerde gebruiker terwyl die vertoon-/bron-konteks na Exchange Online-aktiwiteit wys. Daardie gemengde identiteitspatroon is 'n hoë-waarde jagsein, hoewel verdedigers geldige Exchange-admin-werkvloei moet baselijn om vals positiewe te verminder.
|
||||
Wanneer hierdie techniek misbruik word, kan audit events identiteit-onversoenbaarhede toon waar die user principal name ooreenstem met 'n geïmpersonifiseerde gebruiker terwyl die display/source-konteks na Exchange Online-aktiwiteit wys. Daardie gemengde identiteitspatroon is 'n waardevolle opsporingssein, alhoewel verdedigers legitieme Exchange-admin-workflows behoort te baselien om vals positiewe te verminder.
|
||||
|
||||
## Verwysings
|
||||
|
||||
- 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}}
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Generic Phishing Methodology
|
||||
## Generiese Phishing Methodology
|
||||
|
||||
{{#ref}}
|
||||
https://book.hacktricks.wiki/en/generic-methodologies-and-resources/phishing-methodology/index.html
|
||||
@@ -10,51 +10,51 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/phishing-met
|
||||
|
||||
## Google Groups Phishing
|
||||
|
||||
Blykens, standaard kan werkruimte lede [**groepe skep**](https://groups.google.com/all-groups) **en mense na hulle nooi**. Jy kan dan die e-pos wat aan die gebruiker gestuur sal word **wysig deur 'n paar skakels by te voeg.** Die **e-pos sal van 'n google adres kom**, so dit sal **legitiem** lyk en mense mag op die skakel klik.
|
||||
Skynbaar, standaard kan workspace-lede [**can create groups**](https://groups.google.com/all-groups) **and invite people to them**. Jy kan dan die e-pos wat aan die gebruiker gestuur sal word wysig deur **'n paar skakels by te voeg.** Die **e-pos sal van 'n google adres kom**, so dit sal **legit** lyk en mense mag op die skakel klik.
|
||||
|
||||
Dit is ook moontlik om die **FROM** adres as die **Google groep e-pos** in te stel om **meer e-posse aan die gebruikers binne die groep** te stuur, soos in die volgende beeld waar die groep **`google--support@googlegroups.com`** geskep is en 'n **e-pos aan al die lede** van die groep gestuur is (wat sonder enige toestemming bygevoeg is)
|
||||
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>
|
||||
|
||||
## Google Chat Phishing
|
||||
|
||||
Jy mag in staat wees om of **'n gesprek te begin** met 'n persoon net deur hul e-pos adres te hê of 'n **uitnodiging om te praat** te stuur. Boonop is dit moontlik om **'n Ruimte te skep** wat enige naam kan hê (bv. "Google Support") en **lede na dit uit te nooi**. As hulle aanvaar, mag hulle dink dat hulle met Google Support praat:
|
||||
Jy kan moontlik óf 'n klets begin met 'n persoon slegs met hul e-posadres óf 'n uitnodiging om te praat stuur. Verder is dit moontlik om 'n Space te skep wat enige naam kan hê (bv. "Google Support") en lede daaraan uit te nooi. As hulle aanvaar, mag hulle dink dat hulle met Google Support praat:
|
||||
|
||||
<figure><img src="../../../images/image (6).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
> [!TIP]
|
||||
> **In my toetse het die uitgenooide lede egter glad nie 'n uitnodiging ontvang nie.**
|
||||
> **In my testing however the invited members didn't even receive an invitation.**
|
||||
|
||||
Jy kan kyk hoe dit in die verlede gewerk het in: [https://www.youtube.com/watch?v=KTVHLolz6cE\&t=904s](https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s)
|
||||
Jy kan sien hoe dit voorheen gewerk het by: [https://www.youtube.com/watch?v=KTVHLolz6cE\&t=904s](https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s)
|
||||
|
||||
## Google Doc Phishing
|
||||
|
||||
In die verlede was dit moontlik om 'n **blijkbaar legitieme dokument** te skep en in 'n kommentaar **'n e-pos te noem (soos @user@gmail.com)**. Google **het 'n e-pos na daardie e-pos adres gestuur** om te laat weet dat hulle in die dokument genoem is.\
|
||||
Tans werk dit nie, maar as jy **die slagoffer se e-pos toegang tot die dokument gee**, sal Google 'n e-pos stuur wat dit aandui. Dit is die boodskap wat verskyn wanneer jy iemand noem:
|
||||
In die verlede was dit moontlik om 'n **skynbaar legitime dokument** te skep en dan in 'n kommentaar **'n e-posadres te noem (bv. @user@gmail.com)**. Google **het 'n e-pos na daardie e-posadres gestuur** om te rapporteer dat hulle in die dokument genoem is.\
|
||||
Tans werk dit nie meer nie, maar as jy die slagoffer e-postoegang tot die dokument gee, sal Google 'n e-pos stuur wat dit aandui. Dit is die boodskap wat verskyn wanneer jy iemand noem:
|
||||
|
||||
<figure><img src="../../../images/image (7).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
> [!TIP]
|
||||
> Slagoffers mag 'n beskermingsmeganisme hê wat nie toelaat dat e-posse wat aandui dat 'n eksterne dokument met hulle gedeel is, hul e-pos bereik nie.
|
||||
> Slagoffers kan beskermingsmeganismes hê wat nie toelaat dat e-posse wat aandui dat 'n eksterne dokument met hulle gedeel is, by hul e-pos aankom nie.
|
||||
|
||||
## Google Calendar Phishing
|
||||
|
||||
Jy kan **'n kalender gebeurtenis skep** en soveel e-pos adresse van die maatskappy wat jy aanval, byvoeg as wat jy het. Skeduleer hierdie kalender gebeurtenis in **5 of 15 min** vanaf die huidige tyd. Laat die gebeurtenis legitiem lyk en **sit 'n kommentaar en 'n titel wat aandui dat hulle iets moet lees** (met die **phishing skakel**).
|
||||
Jy kan 'n kalendergebeurtenis skep en soveel e-posadresse van die maatskappy wat jy aanval byvoeg as wat jy het. Skeduleer hierdie kalendergebeurtenis oor **5 of 15 min** van nou af. Laat die gebeurtenis legitim lyk en **sit 'n kommentaar en 'n titel wat aandui dat hulle iets moet lees** (met die **phishing link**).
|
||||
|
||||
Dit is die waarskuwing wat in die blaaier sal verskyn met 'n vergadering titel "Firing People", so jy kan 'n meer phishing-agtige titel stel (en selfs die naam wat met jou e-pos geassosieer is, verander).
|
||||
Dit is die waarskuwing wat in die blaaier sal verskyn met die vergaderingstitel "Firing People", so jy kan 'n meer phishing-agtige titel stel (en selfs die naam wat met jou e-pos geassosieer word verander).
|
||||
|
||||
<figure><img src="../../../images/image (8).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Om dit minder verdag te laat lyk:
|
||||
|
||||
- Stel dit op sodat **ontvangers nie die ander mense wat genooi is, kan sien nie**
|
||||
- Moet **nie e-posse stuur wat oor die gebeurtenis kennis gee nie**. Dan sal die mense net hul waarskuwing oor 'n vergadering in 5min sien en dat hulle daardie skakel moet lees.
|
||||
- Blykbaar kan jy met die API stel dat **mense** die gebeurtenis **aanvaar** het en selfs **kommentaar namens hulle skep**.
|
||||
- Stel dit so in dat **ontvangers nie die ander uitgenooi persone kan sien nie**
|
||||
- Moet **NIET e-posse stuur wat oor die gebeurtenis inlig** nie. Dan sal die mense net hul waarskuwing oor 'n vergadering oor 5 minute sien en dat hulle daardie skakel moet lees.
|
||||
- Klaarblyklik kan jy deur die API te gebruik op **True** stel dat **mense** die gebeurtenis **aanvaar** het en selfs **kommentaar namens hulle** skep.
|
||||
|
||||
## App Scripts Redirect Phishing
|
||||
|
||||
Dit is moontlik om 'n skrip in [https://script.google.com/](https://script.google.com/) te skep en **dit as 'n webtoepassing bloot te stel wat deur almal toeganklik is** wat die legitieme domein **`script.google.com`** sal gebruik.\
|
||||
Met 'n paar kode soos die volgende kan 'n aanvaller die skrip laat laai arbitrêre inhoud op hierdie bladsy sonder om die domein te stop:
|
||||
Dit is moontlik om 'n script te skep op [https://script.google.com/](https://script.google.com/) en dit as 'n webtoepassing wat deur almal toeganklik is bloot te stel wat die legit domein **`script.google.com`** sal gebruik.\
|
||||
Met 'n paar reëls kode soos die volgende kan 'n aanvaller die script laat laai arbitrêre inhoud op hierdie blad sonder om die domaine te verlaat:
|
||||
```javascript
|
||||
function doGet() {
|
||||
return HtmlService.createHtmlOutput(
|
||||
@@ -62,16 +62,16 @@ return HtmlService.createHtmlOutput(
|
||||
).setXFrameOptionsMode(HtmlService.XFrameOptionsMode.ALLOWALL)
|
||||
}
|
||||
```
|
||||
Byvoorbeeld, deur toegang te verkry tot [https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec](https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec) sal jy sien:
|
||||
For example accessing [https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec](https://script.google.com/macros/s/AKfycbwuLlzo0PUaT63G33MtE6TbGUNmTKXCK12o59RKC7WLkgBTyltaS3gYuH_ZscKQTJDC/exec) you will see:
|
||||
|
||||
<figure><img src="../../../images/image (4) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
> [!TIP]
|
||||
> Let daarop dat 'n waarskuwing sal verskyn terwyl die inhoud binne 'n iframe gelaai word.
|
||||
> Let wel dat 'n waarskuwing sal verskyn omdat die inhoud binne 'n iframe gelaai word.
|
||||
|
||||
## App Scripts OAuth Phishing
|
||||
|
||||
Dit is moontlik om App Scripts aan dokumente te koppel om te probeer toegang te verkry tot 'n slagoffer se OAuth-token, vir meer inligting, kyk:
|
||||
Dit is moontlik om App Scripts aan dokumente te koppel om te probeer toegang te kry tot die slagoffer se OAuth-token; vir meer inligting, sien:
|
||||
|
||||
{{#ref}}
|
||||
gws-app-scripts.md
|
||||
@@ -79,83 +79,141 @@ gws-app-scripts.md
|
||||
|
||||
## OAuth Apps Phishing
|
||||
|
||||
Enige van die vorige tegnieke kan gebruik word om die gebruiker toegang te laat verkry tot 'n **Google OAuth-toepassing** wat die gebruiker om **toegang** sal vra. As die gebruiker die **bron** **vertrou**, kan hy die **toepassing** **vertrou** (selfs al vra dit vir hoë bevoorregte toestemmings).
|
||||
Enige van die vorige tegnieke kan gebruik word om die gebruiker te laat toegang kry tot 'n **Google OAuth application** wat die gebruiker sekere **access** sal **request**. As die gebruiker die **source** **trusts**, kan hy dalk ook die **application** vertrou (selfs al vra dit hoogs bevoorregte toestemmings).
|
||||
|
||||
> [!NOTE]
|
||||
> Let daarop dat Google 'n lelike prompt aanbied wat waarsku dat die toepassing in verskeie gevalle nie vertrou word nie, en Workspace-administrateurs kan selfs voorkom dat mense OAuth-toepassings aanvaar.
|
||||
> Let wel dat Google in verskeie gevalle 'n opvallende waarskuwing wys wat aandui dat die toepassing onbetroubaar is, en Workspace-admins kan selfs verhinder dat mense OAuth applications aanvaar.
|
||||
|
||||
**Google** laat toe om toepassings te skep wat kan **interaksie hê namens gebruikers** met verskeie **Google-dienste**: Gmail, Drive, GCP...
|
||||
**Google** laat toe om toepassings te skep wat namens gebruikers met verskeie **Google services** kan werk: Gmail, Drive, GCP...
|
||||
|
||||
Wanneer 'n toepassing geskep word om **namens ander gebruikers op te tree**, moet die ontwikkelaar 'n **OAuth-toepassing binne GCP** skep en die skope (toestemmings) aan dui wat die toepassing nodig het om toegang tot die gebruikersdata te verkry.\
|
||||
Wanneer 'n **gebruiker** daardie **toepassing** wil **gebruik**, sal hulle gevra word om te **aanvaar** dat die toepassing toegang tot hul data sal hê soos gespesifiseer in die skope.
|
||||
Wanneer 'n ontwikkelaar 'n toepassing skep om namens ander gebruikers te optree, moet hy 'n **OAuth app inside GCP** skep en die scopes (toestemmings) aandui wat die app benodig om toegang tot die gebruiker se data te kry. Wanneer 'n **user** daardie **application** wil **use**, sal hulle **prompted** word om te **accept** dat die toepassing toegang tot hul data sal hê soos in die scopes gespesifiseer.
|
||||
|
||||
Dit is 'n baie aantreklike manier om **phish** nie-tegniese gebruikers om **toepassings te gebruik wat sensitiewe inligting toegang gee** omdat hulle dalk nie die gevolge verstaan nie. Dit is egter in organisasies se rekeninge moontlik om te voorkom dat dit gebeur.
|
||||
Dit is 'n baie doeltreffende manier om nie-tegniese gebruikers te phish om toepassings te gebruik wat toegang tot sensitiewe inligting het, omdat hulle moontlik nie die gevolge verstaan nie. In organisasie-rekeninge bestaan daar egter metodes om dit te verhoed.
|
||||
|
||||
### Onverifieerde App-prompt
|
||||
### Unverified App prompt
|
||||
|
||||
Soos genoem, sal Google altyd 'n **prompt aan die gebruiker aanbied om die** toestemmings wat hulle aan die toepassing gee, te aanvaar. As die toepassing egter as **gevaarlik** beskou word, sal Google **eerste** 'n **prompt** toon wat aandui dat dit **gevaarlik** is en **dit moeiliker maak** vir die gebruiker om die toestemmings aan die toepassing te gee.
|
||||
Soos genoem, sal Google altyd 'n **prompt to the user to accept** die toestemmings wat hulle namens hulle aan die toepassing gee. As die toepassing egter as **dangerous** beskou word, sal Google eers 'n **prompt** wys wat aandui dat dit **dangerous** is en dit vir die gebruiker moeiliker maak om die toestemmings aan die app te verleen.
|
||||
|
||||
Hierdie prompt verskyn in toepassings wat:
|
||||
This prompt appears in apps that:
|
||||
|
||||
- Enige skoop gebruik wat toegang tot privaat data kan verkry (Gmail, Drive, GCP, BigQuery...)
|
||||
- Toepassings met minder as 100 gebruikers (toepassings > 100 'n hersieningsproses is ook nodig om die onverifieerde prompt te stop)
|
||||
- Use any scope that can access private data (Gmail, Drive, GCP, BigQuery...)
|
||||
- Apps with less than 100 users (vir apps met > 100 gebruikers is 'n review-proses ook nodig om die unverified prompt te laat ophou verskyn)
|
||||
|
||||
### Interessante Skope
|
||||
### Interesting Scopes
|
||||
|
||||
[**Hier**](https://developers.google.com/identity/protocols/oauth2/scopes) kan jy 'n lys van al die Google OAuth-skope vind.
|
||||
[**Hier**](https://developers.google.com/identity/protocols/oauth2/scopes) you can find a list of all the Google OAuth scopes.
|
||||
|
||||
- **cloud-platform**: Beskou en bestuur jou data oor **Google Cloud Platform**-dienste. Jy kan die gebruiker in GCP naboots.
|
||||
- **admin.directory.user.readonly**: Sien en laai jou organisasie se GSuite-gids af. Kry name, telefone, kalender-URL's van al die gebruikers.
|
||||
- **cloud-platform**: Sien en bestuur jou data oor **Google Cloud Platform**-dienste. Jy kan die gebruiker in GCP naboots/namens die gebruiker optree.
|
||||
- **admin.directory.user.readonly**: Sien en aflaai jou organisasie se GSuite-gids. Kry name, telefoonnommers en kalender-URL's van alle gebruikers.
|
||||
|
||||
### Skep 'n OAuth App
|
||||
### Create an OAuth App
|
||||
|
||||
**Begin om 'n OAuth Client ID te skep**
|
||||
**Start creating an OAuth Client ID**
|
||||
|
||||
1. Gaan na [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient) en klik op configure the consent screen.
|
||||
2. Dan sal jy gevra word of die **gebruiker tipe** **intern** (slegs vir mense in jou org) of **ekstern** is. Kies die een wat by jou behoeftes pas
|
||||
- Intern mag interessant wees as jy reeds 'n gebruiker van die organisasie gecompromitteer het en jy hierdie App skep om 'n ander een te phish.
|
||||
3. Gee 'n **naam** aan die app, 'n **ondersteunings e-pos** (let daarop dat jy 'n googlegroup e-pos kan stel om jouself 'n bietjie meer te anonimiseer), 'n **logo**, **geautoriseerde domeine** en 'n ander **e-pos** vir **opdaterings**.
|
||||
4. **Kies** die **OAuth skope**.
|
||||
- Hierdie bladsy is verdeel in nie-sensitiewe toestemmings, sensitiewe toestemmings en beperkte toestemmings. Elke keer as jy 'n nuwe toestemming byvoeg, word dit in sy kategorie bygevoeg. Afhangende van die aangevraagde toestemmings, sal verskillende prompts aan die gebruiker verskyn wat aandui hoe sensitief hierdie toestemmings is.
|
||||
- Beide **`admin.directory.user.readonly`** en **`cloud-platform`** is sensitiewe toestemmings.
|
||||
5. **Voeg die toetsgebruikers by.** Solank as die status van die app toets is, sal slegs hierdie gebruikers toegang tot die app hê, so maak seker om **die e-pos wat jy gaan phish** by te voeg.
|
||||
1. Gaan na [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient) en klik op 'configure the consent screen'.
|
||||
2. Daarna sal jy gevra word of die **user type** **internal** (slegs vir mense in jou org) of **external** is. Kies die een wat by jou behoeftes pas.
|
||||
- Internal kan interessant wees as jy reeds 'n gebruiker van die organisasie gekompromitteer het en jy hierdie App skep om nog 'n gebruiker te phish.
|
||||
3. Gee 'n **name** aan die app, 'n **support email** (let wel: jy kan 'n googlegroup email gebruik om jou identiteit effens te anonimiseer), 'n **logo**, **authorized domains** en nog 'n **email** vir **updates**.
|
||||
4. **Select** die **OAuth scopes**.
|
||||
- Hierdie bladsy is verdeel in non sensitive permissions, sensitive permissions en restricted permissions. Elke keer wat jy 'n nuwe permission byvoeg, word dit in sy kategorie geplaas. Afhangend van die versoekte permissions sal verskillende prompts aan die gebruiker vertoon word wat aandui hoe sensitief daardie permissions is.
|
||||
- Beide **`admin.directory.user.readonly`** en **`cloud-platform`** is sensitive permissions.
|
||||
5. **Add the test users.** Solank die app se status op testing is, sal net daardie gebruikers toegang tot die app hê — maak dus seker jy **add the email you are going to be phishing**.
|
||||
|
||||
Nou kom ons **kry kredensiale vir 'n webtoepassing** met behulp van die **voorheen geskepte OAuth Client ID**:
|
||||
Nou kry ons **credentials for a web application** met behulp van die **previously created OAuth Client ID**:
|
||||
|
||||
1. Gaan terug na [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient), 'n ander opsie sal hierdie keer verskyn.
|
||||
2. Kies om **kredensiale vir 'n webtoepassing te skep**
|
||||
3. Stel nodige **Javascript oorspronge** en **herlei URI's** in
|
||||
- Jy kan in albei iets soos **`http://localhost:8000/callback`** vir toetsing stel
|
||||
4. Kry jou toepassing se **kredensiale**
|
||||
1. Gaan terug na [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient); 'n verskillende opsie sal hierdie keer verskyn.
|
||||
2. Kies om **create credentials for a Web application**.
|
||||
3. Stel die nodige **Javascript origins** en **redirect URIs** in.
|
||||
- Jy kan in albei iets soos **`http://localhost:8000/callback`** vir toetsing gebruik.
|
||||
4. Kry jou application **credentials**.
|
||||
|
||||
Laastens, laat ons **'n webtoepassing uitvoer wat die OAuth-toepassing se kredensiale sal gebruik**. Jy kan 'n voorbeeld vind in [https://github.com/carlospolop/gcp_oauth_phishing_example](https://github.com/carlospolop/gcp_oauth_phishing_example).
|
||||
Laastens, laat ons 'n web application laat loop wat die OAuth application credentials sal gebruik. Jy kan 'n voorbeeld vind by [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>"
|
||||
```
|
||||
Gaan na **`http://localhost:8000`** en klik op die Login with Google-knoppie, jy sal **gevra** word met 'n boodskap soos hierdie:
|
||||
Gaan na **`http://localhost:8000`**, klik op die Login with Google-knoppie, jy sal 'n boodskap soos hierdie sien:
|
||||
|
||||
<figure><img src="../../../images/image (333).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Die toepassing sal die **toegang en hernu token** wys wat maklik gebruik kan word. Vir meer inligting oor **hoe om hierdie tokens te gebruik, kyk**:
|
||||
Die toepassing sal die **access and refresh token** wys wat maklik gebruik kan word. Vir meer inligting oor **hoe om hierdie tokens te gebruik, sien**:
|
||||
|
||||
{{#ref}}
|
||||
../../gcp-security/gcp-persistence/gcp-non-svc-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
#### Gebruik `glcoud`
|
||||
#### Using `glcoud`
|
||||
|
||||
Dit is moontlik om iets te doen met gcloud in plaas van die webkonsol, kyk:
|
||||
Dit is moontlik om iets met gcloud te doen in plaas van die webkonsol, sien:
|
||||
|
||||
{{#ref}}
|
||||
../../gcp-security/gcp-privilege-escalation/gcp-clientauthconfig-privesc.md
|
||||
{{#endref}}
|
||||
|
||||
## Verwysings
|
||||
#### OAuth app protections
|
||||
|
||||
Volgens verstek is dit gekonfigureer sodat enige gebruiker binne 'n Workspace-organisasie **can accecpt any OAuth app with any permissions**, maar dit is moontlik om dit te beperk tot slegs apps wat net die basiese inligting wat vir Sign in with Google nodig is versoek, of om geen derdeparty-apps toe te laat nie.
|
||||
|
||||
Verder, selfs al word dit nie toegelaat om eksterne derdeparty-apps te vertrou nie, is dit moontlik om te **vertrou enige interne apps** (apps geskep binne die organisasie). Hierdie vertroue is by **verstek** gekonfigureer.
|
||||
|
||||
<figure><img src="../../../images/workspace_oauth.png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### OAuth Consent Grant Abuse: Opsporing & Respons (Admin Reports)
|
||||
|
||||
Wanneer 'n gebruiker 'n OAuth app magtig, teken Google Workspace dit op in die **Admin Reports OAuth Token Audit Activity** (application name `token`) met `events.name` gestel op `authorize`. Hierdie events is die beste telemetrie om consent phishing te ontdek en die client ID en scopes wat toegeken is, op te spoor.
|
||||
|
||||
Sleutelvelde om uit die ouditgebeurtenis te onttrek:
|
||||
|
||||
- `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`
|
||||
|
||||
**Begin met 'n basislyn (verminder geraas):** bou 'n inventaris van bestaande client IDs en scopes, en waarsku dan oor nuwe/seldsame toestemmings.
|
||||
```bash
|
||||
gam all users print tokens todrive
|
||||
```
|
||||
**Opsporingsidees (new/rare app + risky scopes):**
|
||||
|
||||
- Waarsku as `client_id` **nie in 'n goedgekeurde allowlist is nie** en **nie in die laaste X dae gesien is nie** (bv. 90).
|
||||
- Waarsku as die toegekende `scope` **high-risk or rare** scopes insluit, veral dié wat bulk data toegang of supply-chain impact moontlik maak, soos:
|
||||
- `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)
|
||||
```
|
||||
**Reaksie / inperking:**
|
||||
|
||||
- Herroep tokens vir die kwaadwillige OAuth client ID:
|
||||
```bash
|
||||
gam all users delete tokens clientId <client_id>
|
||||
```
|
||||
- Blokkeer die OAuth client ID in die Admin Console deur die toepassing se toegang tot Google-data in te trek.
|
||||
|
||||
**Threat hunting pivots:**
|
||||
|
||||
- Lys external apps waaraan minder as N gebruikers toestemming verleen het (seldsame aanneming).
|
||||
- Kontroleer app-naam, publisher, permissions/scopes, en unieke application ID.
|
||||
- Soek na dormant apps wat skielik risky permissions begin gebruik (moontlike opvolgaksies soos internal phishing of data theft).
|
||||
|
||||
**Maatreëls:**
|
||||
|
||||
- Beperk alle third-party app access (slegs admin-goedgekeur).
|
||||
- Laat beperkte toegang toe sodat gebruikers slegs toestemming kan gee vir basiese “Sign in with Google” profielinligting.
|
||||
|
||||
## References
|
||||
|
||||
- [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 en Beau Bullock - OK Google, Hoe doen ek 'n 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}}
|
||||
|
||||
Reference in New Issue
Block a user