diff --git a/src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md b/src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md
index 64bc275cb..317651f64 100644
--- a/src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md
+++ b/src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting/README.md
@@ -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.
 
diff --git a/src/pentesting-cloud/workspace-security/gws-google-platforms-phishing/README.md b/src/pentesting-cloud/workspace-security/gws-google-platforms-phishing/README.md
index 4b272503f..d61bd6552 100644
--- a/src/pentesting-cloud/workspace-security/gws-google-platforms-phishing/README.md
+++ b/src/pentesting-cloud/workspace-security/gws-google-platforms-phishing/README.md
@@ -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}}