mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-12 21:13:45 -08:00
Translated ['src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting
This commit is contained in:
Translator
@@ -2,11 +2,11 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## **Від GCP до GWS**
|
||||
## **З GCP до GWS**
|
||||
|
||||
### **Основи делегування на рівні домену**
|
||||
|
||||
Делегування на рівні домену Google Workspace дозволяє об'єкту ідентифікації, або **зовнішньому додатку** з Google Workspace Marketplace, або внутрішньому **обліковому запису служби GCP**, **отримувати доступ до даних у Workspace від імені користувачів**.
|
||||
Делегування на рівні домену Google Workspace дозволяє об'єкту ідентичності, або **зовнішньому додатку** з Google Workspace Marketplace, або внутрішньому **обліковому запису служби GCP**, **отримувати доступ до даних у Workspace від імені користувачів**.
|
||||
|
||||
> [!NOTE]
|
||||
> Це в основному означає, що **облікові записи служби** всередині проектів GCP організації можуть мати можливість **видавати себе за користувачів Workspace** тієї ж організації (або навіть з іншої).
|
||||
@@ -19,12 +19,12 @@ gcp-understanding-domain-wide-delegation.md
|
||||
|
||||
### Компрометація існуючого делегування
|
||||
|
||||
Якщо зловмисник **компрометував доступ до GCP** і **знає дійсну електронну адресу користувача Workspace** (бажано **суперадміністратора**) компанії, він міг би **перерахувати всі проекти**, до яких має доступ, **перерахувати всі облікові записи служби** проектів, перевірити, до яких **облікових записів служби має доступ**, і **повторити** всі ці кроки з кожним обліковим записом служби, за яким він може видавати себе.\
|
||||
Якщо зловмисник **компрометував доступ до GCP** і **знає дійсну електронну адресу користувача Workspace** (бажано **супер адміністратора**) компанії, він міг би **перерахувати всі проекти**, до яких має доступ, **перерахувати всі облікові записи Служби** проектів, перевірити, до яких **облікових записів служби має доступ**, і **повторити** всі ці кроки з кожним обліковим записом Служби, за яким він може видавати себе.\
|
||||
З **переліком всіх облікових записів служби**, до яких він має **доступ**, і списком **електронних адрес Workspace**, зловмисник міг би спробувати **видавати себе за користувача з кожним обліковим записом служби**.
|
||||
|
||||
> [!CAUTION]
|
||||
> Зверніть увагу, що при налаштуванні делегування на рівні домену жоден користувач Workspace не потрібен, тому просто знати **одного дійсного достатньо і необхідно для видавання себе**.\
|
||||
> Однак, **привілеї виданого користувача будуть використані**, тому якщо це суперадміністратор, ви зможете отримати доступ до всього. Якщо у нього немає доступу, це буде марно.
|
||||
> Однак, **привілеї виданого користувача будуть використані**, тому якщо це Супер Адміністратор, ви зможете отримати доступ до всього. Якщо у нього немає доступу, це буде марно.
|
||||
|
||||
#### [GCP Generate Delegation Token](https://github.com/carlospolop/gcp_gen_delegation_token)
|
||||
|
||||
@@ -42,10 +42,10 @@ python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-ke
|
||||
|
||||
1. **Перерахувати GCP проекти** за допомогою Resource Manager API.
|
||||
2. Ітерація по кожному ресурсу проекту та **перерахування ресурсів облікових записів сервісу GCP**, до яких має доступ початковий IAM користувач, використовуючи _GetIAMPolicy_.
|
||||
3. Ітерація по **кожній ролі облікового запису сервісу** та знаходження вбудованих, базових і кастомних ролей з дозволом _**serviceAccountKeys.create**_ на цільовому ресурсі облікового запису сервісу. Слід зазначити, що роль редактора за замовчуванням має цей дозвіл.
|
||||
3. Ітерація по **кожній ролі облікового запису сервісу** та знаходження вбудованих, базових і кастомних ролей з дозволом _**serviceAccountKeys.create**_ на цільовому ресурсі облікового запису сервісу. Слід зазначити, що роль Editor за замовчуванням має цей дозвіл.
|
||||
4. Створення **нового `KEY_ALG_RSA_2048`** приватного ключа для кожного ресурсу облікового запису сервісу, який знайдено з відповідним дозволом у політиці IAM.
|
||||
5. Ітерація по **кожному новому обліковому запису сервісу та створення `JWT`** **об'єкта** для нього, який складається з облікових даних приватного ключа SA та області OAuth. Процес створення нового _JWT_ об'єкта буде **ітерацією по всім існуючим комбінаціям областей OAuth** з списку **oauth_scopes.txt**, щоб знайти всі можливості делегування. Список **oauth_scopes.txt** оновлюється всіма областями OAuth, які ми вважаємо релевантними для зловживання ідентичностями Workspace.
|
||||
6. Метод `_make_authorization_grant_assertion` вказує на необхідність оголосити цільового користувача робочого простору, який називається _subject_, для генерації JWT під DWD. Хоча це може здаватися, що вимагає конкретного користувача, важливо усвідомити, що **DWD впливає на кожну ідентичність у домені**. Отже, створення JWT для **будь-якого користувача домену** впливає на всі ідентичності в цьому домені, відповідно до нашої перевірки комбінацій. Простими словами, одного дійсного користувача Workspace достатньо для продовження.\
|
||||
5. Ітерація по **кожному новому обліковому запису сервісу та створення об'єкта `JWT`**, який складається з облікових даних приватного ключа SA та OAuth області. Процес створення нового об'єкта _JWT_ буде **ітерацією по всім існуючим комбінаціям OAuth областей** з списку **oauth_scopes.txt**, щоб знайти всі можливості делегування. Список **oauth_scopes.txt** оновлюється всіма OAuth областями, які ми вважаємо релевантними для зловживання ідентичностями Workspace.
|
||||
6. Метод `_make_authorization_grant_assertion` вказує на необхідність оголосити **цільового користувача робочого простору**, відомого як _subject_, для генерації JWT під DWD. Хоча це може здаватися, що вимагає конкретного користувача, важливо усвідомити, що **DWD впливає на кожну ідентичність у домені**. Отже, створення JWT для **будь-якого користувача домену** впливає на всі ідентичності в цьому домені, відповідно до нашої перевірки комбінацій. Простими словами, одного дійсного користувача Workspace достатньо для продовження.\
|
||||
Цей користувач може бути визначений у файлі _config.yaml_ DeleFriend. Якщо цільовий користувач робочого простору ще не відомий, інструмент полегшує автоматичну ідентифікацію дійсних користувачів робочого простору, скануючи користувачів домену з ролями на GCP проектах. Важливо зазначити (знову), що JWT є специфічними для домену і не генеруються для кожного користувача; отже, автоматичний процес націлений на одну унікальну ідентичність на домен.
|
||||
7. **Перерахувати та створити новий токен доступу** для кожного JWT та перевірити токен за допомогою tokeninfo API.
|
||||
|
||||
@@ -80,9 +80,9 @@ pip install --upgrade --user oauth2client
|
||||
Зловмисник, який має можливість **створювати облікові записи служб у проекті GCP** та **привілеї супер адміністратора в GWS, може створити нову делегацію, що дозволяє СА наслідувати деяких користувачів GWS:**
|
||||
|
||||
1. **Генерація нового облікового запису служби та відповідної пари ключів:** У GCP нові ресурси облікових записів служб можуть бути створені або інтерактивно через консоль, або програмно за допомогою прямих API викликів та CLI інструментів. Це вимагає **ролі `iam.serviceAccountAdmin`** або будь-якої кастомної ролі, оснащеної **дозволом `iam.serviceAccounts.create`**. Після створення облікового запису служби ми перейдемо до генерації **пов'язаної пари ключів** (**дозвіл `iam.serviceAccountKeys.create`**).
|
||||
2. **Створення нової делегації**: Важливо розуміти, що **тільки роль супер адміністратора має можливість налаштувати глобальну делегацію на рівні домену в Google Workspace** і делегацію на рівні домену **не можна налаштувати програмно,** її можна створити та налаштувати **вручну** через консоль Google Workspace.
|
||||
2. **Створення нової делегації:** Важливо розуміти, що **тільки роль супер адміністратора має можливість налаштувати глобальну делегацію на рівні домену в Google Workspace** і делегацію на рівні домену **не можна налаштувати програмно,** її можна створити та налаштувати **вручну** через консоль Google Workspace.
|
||||
- Створення правила можна знайти на сторінці **API controls → Manage Domain-Wide delegation in Google Workspace Admin console**.
|
||||
3. **Прикріплення привілеїв OAuth scopes**: При налаштуванні нової делегації Google вимагає лише 2 параметри: ідентифікатор клієнта, який є **OAuth ID ресурсу облікового запису служби GCP**, та **OAuth scopes**, які визначають, які API виклики потрібні для делегації.
|
||||
3. **Прикріплення привілеїв OAuth scopes:** При налаштуванні нової делегації Google вимагає лише 2 параметри: ідентифікатор клієнта, який є **OAuth ID ресурсу облікового запису служби GCP**, та **OAuth scopes**, які визначають, які API виклики потрібні для делегації.
|
||||
- **Повний список OAuth scopes** можна знайти [**тут**](https://developers.google.com/identity/protocols/oauth2/scopes), але ось рекомендація: `https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid`
|
||||
4. **Дії від імені цільової особи:** На цьому етапі у нас є функціонуючий делегований об'єкт у GWS. Тепер, **використовуючи приватний ключ облікового запису служби GCP, ми можемо виконувати API виклики** (в межах, визначених у параметрі OAuth scope), щоб активувати його та **діяти від імені будь-якої особи, яка існує в Google Workspace**. Як ми дізналися, обліковий запис служби генеруватиме токени доступу відповідно до своїх потреб і згідно з дозволами, які він має для REST API додатків.
|
||||
- Перевірте **попередній розділ** для деяких **інструментів** для використання цієї делегації.
|
||||
@@ -124,14 +124,14 @@ gcloud beta identity groups preview --customer <org-cust-id>
|
||||
|
||||
### Зловживання обліковими даними Gcloud
|
||||
|
||||
Ви можете знайти додаткову інформацію про потік `gcloud` для входу в:
|
||||
Ви можете знайти додаткову інформацію про процес входу в `gcloud` у:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-persistence/gcp-non-svc-persistance.md
|
||||
../gcp-persistence/gcp-non-svc-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
Як пояснено там, gcloud може запитувати область **`https://www.googleapis.com/auth/drive`**, що дозволить користувачу отримати доступ до диска користувача.\
|
||||
Якщо ви атакуючий і фізично скомпрометували комп'ютер користувача, а **користувач все ще увійшов** зі своїм обліковим записом, ви можете увійти, згенерувавши токен з доступом до диска, використовуючи:
|
||||
Як атакуючий, якщо ви фізично скомпрометували комп'ютер користувача і **користувач все ще увійшов** зі своїм обліковим записом, ви могли б увійти, згенерувавши токен з доступом до диска, використовуючи:
|
||||
```bash
|
||||
gcloud auth login --enable-gdrive-access
|
||||
```
|
||||
@@ -148,11 +148,11 @@ gcloud auth login --enable-gdrive-access
|
||||
|
||||
### Доступ до привілейованих користувачів GCP
|
||||
|
||||
Якщо зловмисник має повний доступ до GWS, він зможе отримати доступ до груп з привілейованим доступом до GCP або навіть до користувачів, тому перехід від GWS до GCP зазвичай є більш "простим" лише тому, що **користувачі в GWS мають високі привілеї над GCP**.
|
||||
Якщо зловмисник має повний доступ до GWS, він зможе отримати доступ до груп з привілейованим доступом до GCP або навіть до користувачів, тому перехід від GWS до GCP зазвичай є більш "простим", просто тому що **користувачі в GWS мають високі привілеї над GCP**.
|
||||
|
||||
### Підвищення привілеїв Google Groups
|
||||
|
||||
За замовчуванням користувачі можуть **вільно приєднуватися до груп Workspace Організації** і ці групи **можуть мати призначені дозволи GCP** (перевірте свої групи на [https://groups.google.com/](https://groups.google.com/)).
|
||||
За замовчуванням користувачі можуть **вільно приєднуватися до груп Workspace Організації** і ці групи **можуть мати призначені дозволи GCP** (перевірте свої групи в [https://groups.google.com/](https://groups.google.com/)).
|
||||
|
||||
Зловживаючи **google groups privesc**, ви можете мати можливість підвищити привілеї до групи з якимось видом привілейованого доступу до GCP.
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/phishing-met
|
||||
|
||||
Очевидно, за замовчуванням, у workspace учасники [**можуть створювати групи**](https://groups.google.com/all-groups) **та запрошувати людей до них**. Ви можете змінити електронну пошту, яка буде надіслана користувачу, **додавши деякі посилання.** **Електронна пошта буде надіслана з адреси google**, тому вона виглядатиме **легітимно**, і люди можуть натиснути на посилання.
|
||||
|
||||
Також можливо встановити адресу **FROM** як **електронну пошту групи Google**, щоб надіслати **більше електронних листів користувачам всередині групи**, як на наступному зображенні, де група **`google--support@googlegroups.com`** була створена, і **електронний лист був надісланий всім членам** групи (які були додані без будь-якої згоди)
|
||||
Також можливо встановити адресу **FROM** як **електронну пошту Google групи**, щоб надіслати **більше електронних листів користувачам всередині групи**, як на наступному зображенні, де група **`google--support@googlegroups.com`** була створена, і **електронний лист був надісланий всім членам** групи (які були додані без будь-якої згоди)
|
||||
|
||||
<figure><img src="../../../images/image (5) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -41,7 +41,7 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/phishing-met
|
||||
|
||||
Ви можете **створити подію в календарі** і додати стільки електронних адрес компанії, яку ви атакуєте, скільки у вас є. Заплануйте цю подію в календарі на **5 або 15 хвилин** від поточного часу. Зробіть подію виглядати легітимно і **додайте коментар та заголовок, вказуючи, що їм потрібно щось прочитати** (з **фішинговим посиланням**).
|
||||
|
||||
Це попередження, яке з'явиться в браузері з заголовком зустрічі "Звільнення людей", тому ви можете встановити більш фішинговий заголовок (і навіть змінити ім'я, пов'язане з вашою електронною поштою).
|
||||
Це попередження, яке з'явиться в браузері з заголовком зустрічі "Звільнення людей", тому ви могли б встановити більш фішинговий заголовок (і навіть змінити ім'я, пов'язане з вашою електронною поштою).
|
||||
|
||||
<figure><img src="../../../images/image (8).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -54,7 +54,7 @@ https://book.hacktricks.wiki/en/generic-methodologies-and-resources/phishing-met
|
||||
## App Scripts Redirect Phishing
|
||||
|
||||
Можливо створити скрипт на [https://script.google.com/](https://script.google.com/) і **викласти його як веб-додаток, доступний для всіх**, який використовуватиме легітимний домен **`script.google.com`**.\
|
||||
З деяким кодом, подібним до наступного, зловмисник може змусити скрипт завантажувати довільний вміст на цій сторінці без зупинки доступу до домену:
|
||||
З деяким кодом, подібним до наступного, зловмисник може змусити скрипт завантажувати довільний вміст на цю сторінку без зупинки доступу до домену:
|
||||
```javascript
|
||||
function doGet() {
|
||||
return HtmlService.createHtmlOutput(
|
||||
@@ -82,23 +82,23 @@ gws-app-scripts.md
|
||||
Будь-яка з попередніх технік може бути використана, щоб змусити користувача отримати доступ до **Google OAuth application**, яка **запитуватиме** у користувача деякі **доступи**. Якщо користувач **довіряє** **джерелу**, він може **довіряти** **додатку** (навіть якщо він запитує високі привілейовані дозволи).
|
||||
|
||||
> [!NOTE]
|
||||
> Зверніть увагу, що Google показує непривабливий запит, попереджаючи, що додаток не є надійним у кількох випадках, і адміністратори Workspace можуть навіть заборонити людям приймати OAuth додатки.
|
||||
> Зверніть увагу, що Google показує непривабливе вікно з попередженням, що додаток ненадійний у кількох випадках, і адміністратори Workspace можуть навіть заборонити людям приймати OAuth додатки.
|
||||
|
||||
**Google** дозволяє створювати додатки, які можуть **взаємодіяти від імені користувачів** з кількома **сервісами Google**: Gmail, Drive, GCP...
|
||||
|
||||
Коли створюється додаток, щоб **діяти від імені інших користувачів**, розробник повинен створити **OAuth app всередині GCP** і вказати області (дозволи), які додаток потребує для доступу до даних користувачів.\
|
||||
Коли **користувач** хоче **використовувати** цей **додаток**, йому буде **запропоновано** **прийняти**, що додаток матиме доступ до їхніх даних, зазначених в областях.
|
||||
|
||||
Це дуже привабливий спосіб **фішингу** нетехнічних користувачів, щоб змусити їх використовувати **додатки, які отримують доступ до чутливої інформації**, оскільки вони можуть не розуміти наслідків. Однак в облікових записах організацій є способи запобігти цьому.
|
||||
Це дуже привабливий спосіб **фішингу** нетехнічних користувачів для використання **додатків, які отримують доступ до чутливої інформації**, оскільки вони можуть не розуміти наслідків. Однак в облікових записах організацій є способи запобігти цьому.
|
||||
|
||||
### Unverified App prompt
|
||||
|
||||
Як було згадано, Google завжди буде показувати **запит користувачу на прийняття** дозволів, які вони надають додатку від свого імені. Однак, якщо додаток вважається **небезпечним**, Google спочатку покаже **запит**, вказуючи, що він **небезпечний** і **ускладнюючи** користувачу надання дозволів додатку.
|
||||
Як було згадано, Google завжди показуватиме **вікно для користувача для прийняття** дозволів, які вони надають додатку від їхнього імені. Однак, якщо додаток вважається **небезпечним**, Google спочатку покаже **вікно**, яке вказує, що воно **небезпечне** і **ускладнює** користувачу надання дозволів додатку.
|
||||
|
||||
Цей запит з'являється в додатках, які:
|
||||
Це вікно з'являється в додатках, які:
|
||||
|
||||
- Використовують будь-яку область, яка може отримати доступ до приватних даних (Gmail, Drive, GCP, BigQuery...)
|
||||
- Додатки з менш ніж 100 користувачами (додатки > 100 також потребують процесу перевірки, щоб зупинити показ неперевіреного запиту)
|
||||
- Додатки з менш ніж 100 користувачами (додатки > 100 також потребують процесу перевірки, щоб зупинити показ вікна ненадійного додатку)
|
||||
|
||||
### Interesting Scopes
|
||||
|
||||
@@ -109,24 +109,24 @@ gws-app-scripts.md
|
||||
|
||||
### Create an OAuth App
|
||||
|
||||
**Почніть створювати OAuth Client ID**
|
||||
**Почніть створення OAuth Client ID**
|
||||
|
||||
1. Перейдіть на [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient) і натисніть на налаштування екрану згоди.
|
||||
2. Потім вам буде запропоновано, чи є **тип користувача** **внутрішнім** (тільки для людей у вашій організації) чи **зовнішнім**. Виберіть той, який відповідає вашим потребам
|
||||
2. Потім вам буде запропоновано, чи є **тип користувача** **внутрішнім** (тільки для людей у вашій організації) чи **зовнішнім**. Виберіть той, який відповідає вашим потребам.
|
||||
- Внутрішній може бути цікавим, якщо ви вже скомпрометували користувача організації і створюєте цей додаток, щоб фішити іншого.
|
||||
3. Дайте **ім'я** додатку, **електронну пошту підтримки** (зверніть увагу, що ви можете вказати електронну пошту googlegroup, щоб спробувати трохи анонімізувати себе), **логотип**, **дозволені домени** та іншу **електронну пошту** для **оновлень**.
|
||||
3. Дайте **ім'я** додатку, **електронну пошту підтримки** (зверніть увагу, що ви можете встановити електронну пошту googlegroup, щоб спробувати анонімізувати себе трохи більше), **логотип**, **дозволені домени** та іншу **електронну пошту** для **оновлень**.
|
||||
4. **Виберіть** **OAuth області**.
|
||||
- Ця сторінка поділена на неделікатні дозволи, делікатні дозволи та обмежені дозволи. Щоразу, коли ви додаєте новий дозвіл, він додається до своєї категорії. В залежності від запитуваних дозволів різні запити з'являться користувачу, вказуючи, наскільки чутливими є ці дозволи.
|
||||
- Ця сторінка поділена на неделікатні дозволи, делікатні дозволи та обмежені дозволи. Кожного разу, коли ви додаєте новий дозвіл, він додається до своєї категорії. В залежності від запитуваних дозволів різні вікна з'являться для користувача, вказуючи, наскільки чутливими є ці дозволи.
|
||||
- Як **`admin.directory.user.readonly`**, так і **`cloud-platform`** є делікатними дозволами.
|
||||
5. **Додайте тестових користувачів.** Поки статус додатку є тестовим, лише ці користувачі зможуть отримати доступ до додатку, тому переконайтеся, що **додали електронну пошту, яку ви будете фішити**.
|
||||
|
||||
Тепер давайте отримати **облікові дані для веб-додатку**, використовуючи **раніше створений OAuth Client ID**:
|
||||
|
||||
1. Поверніться на [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient), цього разу з'явиться інша опція.
|
||||
2. Виберіть **створити облікові дані для веб-додатку**
|
||||
3. Встановіть необхідні **Javascript origins** та **redirect URIs**
|
||||
- Ви можете вказати в обох щось на кшталт **`http://localhost:8000/callback`** для тестування
|
||||
4. Отримайте свої облікові дані **додатку**
|
||||
2. Виберіть **створити облікові дані для веб-додатку**.
|
||||
3. Встановіть необхідні **Javascript origins** та **redirect URIs**.
|
||||
- Ви можете встановити в обох щось на зразок **`http://localhost:8000/callback`** для тестування.
|
||||
4. Отримайте свої облікові дані **додатку**.
|
||||
|
||||
Нарешті, давайте **запустимо веб-додаток, який використовуватиме облікові дані OAuth додатку**. Ви можете знайти приклад на [https://github.com/carlospolop/gcp_oauth_phishing_example](https://github.com/carlospolop/gcp_oauth_phishing_example).
|
||||
```bash
|
||||
@@ -139,10 +139,10 @@ python3 app.py --client-id "<client_id>" --client-secret "<client_secret>"
|
||||
|
||||
<figure><img src="../../../images/image (333).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Додаток покаже **токен доступу та оновлення**, які можна легко використовувати. Для отримання додаткової інформації про **те, як використовувати ці токени, перевірте**:
|
||||
Додаток покаже **токен доступу та токен оновлення**, які можна легко використовувати. Для отримання додаткової інформації про **те, як використовувати ці токени, перевірте**:
|
||||
|
||||
{{#ref}}
|
||||
../../gcp-security/gcp-persistence/gcp-non-svc-persistance.md
|
||||
../../gcp-security/gcp-persistence/gcp-non-svc-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
#### Використання `glcoud`
|
||||
@@ -156,6 +156,6 @@ python3 app.py --client-id "<client_id>" --client-secret "<client_secret>"
|
||||
## Посилання
|
||||
|
||||
- [https://www.youtube-nocookie.com/embed/6AsVUS79gLw](https://www.youtube-nocookie.com/embed/6AsVUS79gLw) - Метью Брайант - Хакінг G Suite: Сила темної магії Apps Script
|
||||
- [https://www.youtube.com/watch?v=KTVHLolz6cE](https://www.youtube.com/watch?v=KTVHLolz6cE) - Майк Фелч і Боу Буллок - ОК Google, як мені провести Red Team для GSuite?
|
||||
- [https://www.youtube.com/watch?v=KTVHLolz6cE](https://www.youtube.com/watch?v=KTVHLolz6cE) - Майк Фелч і Боу Буллок - ОК Google, як мені провести Red Team GSuite?
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user