Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/

src/pentesting-cloud/azure-security/README.md

@@ -10,30 +10,30 @@ az-basic-information/
 
 ## Методологія Azure Pentester/Red Team
 
-Щоб провести аудит середовища AZURE, дуже важливо знати: які **послуги використовуються**, що **експонується**, хто має **доступ** до чого, і як внутрішні служби Azure та **зовнішні служби** з'єднані.
+Для аудиту середовища AZURE дуже важливо знати: які **послуги використовуються**, що **експонується**, хто має **доступ** до чого, і як внутрішні Azure сервіси та **зовнішні сервіси** з'єднані.
 
 З точки зору Red Team, **перший крок для компрометації середовища Azure** - це отримати деякі **облікові дані** для Azure AD. Ось кілька ідей, як це зробити:
 
 - **Витоки** в github (або подібних) - OSINT
 - **Соціальна** інженерія
 - Повторне використання **паролів** (витоки паролів)
-- Вразливості в Azure-розміщених додатках
+- Вразливості в Azure-Hosted Applications
 - [**Server Side Request Forgery**](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf) з доступом до метаданих
 - **Читання локальних файлів**
 - `/home/USERNAME/.azure`
 - `C:\Users\USERNAME\.azure`
 - Файл **`accessTokens.json`** в `az cli` до 2.30 - січень 2022 - зберігав **токени доступу у відкритому тексті**
-- Файл **`azureProfile.json`** містить **інформацію** про увійшого користувача.
+- Файл **`azureProfile.json`** містить **інформацію** про увійшлого користувача.
 - **`az logout`** видаляє токен.
-- Старі версії **`Az PowerShell`** зберігали **токени доступу** у **відкритому** тексті в **`TokenCache.dat`**. Він також зберігає **ServicePrincipalSecret** у **відкритому** тексті в **`AzureRmContext.json`**. Команда **`Save-AzContext`** може бути використана для **зберігання** **токенів**.\
+- Старі версії **`Az PowerShell`** зберігали **токени доступу** у **відкритому** тексті в **`TokenCache.dat`**. Він також зберігає **ServicePrincipalSecret** у **відкритому** тексті в **`AzureRmContext.json`**. Командлет **`Save-AzContext`** можна використовувати для **зберігання** **токенів**.\
 Використовуйте `Disconnect-AzAccount`, щоб видалити їх.
 - 3-ті сторони **зламані**
 - **Внутрішній** співробітник
-- [**Загальний фішинг**](https://book.hacktricks.xyz/generic-methodologies-and-resources/phishing-methodology) (облікові дані або Oauth App)
+- [**Звичайне фішинг**](https://book.hacktricks.xyz/generic-methodologies-and-resources/phishing-methodology) (облікові дані або Oauth App)
 - [Фішинг аутентифікації за кодом пристрою](az-unauthenticated-enum-and-initial-entry/az-device-code-authentication-phishing.md)
 - [Azure **Password Spraying**](az-unauthenticated-enum-and-initial-entry/az-password-spraying.md)
 
-Навіть якщо ви **не компрометували жодного користувача** всередині Azure-оренди, яку ви атакуєте, ви можете **зібрати деяку інформацію** з неї:
+Навіть якщо ви **не компрометували жодного користувача** всередині Azure тенанту, який ви атакуєте, ви можете **зібрати деяку інформацію** з нього:
 
 {{#ref}}
 az-unauthenticated-enum-and-initial-entry/
@@ -59,12 +59,12 @@ https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/clou
 
 <figure><img src="../../images/image (268).png" alt=""><figcaption></figcaption></figure>
 
-У випадках, коли у вас є деякі дійсні облікові дані, але ви не можете увійти, ось кілька загальних захистів, які можуть бути на місці:
+У випадках, коли у вас є дійсні облікові дані, але ви не можете увійти, ось кілька загальних захистів, які можуть бути на місці:
 
 - **IP-білий список** -- Вам потрібно зламати дійсний IP
-- **Гео обмеження** -- Знайдіть, де живе користувач або де знаходяться офіси компанії, і отримайте IP з того ж міста (або країни принаймні)
+- **Гео обмеження** -- Дізнайтеся, де живе користувач або де знаходяться офіси компанії, і отримайте IP з того ж міста (або країни принаймні)
 - **Браузер** -- Можливо, лише браузер з певної ОС (Windows, Linux, Mac, Android, iOS) дозволений. Дізнайтеся, яку ОС використовує жертва/компанія.
-- Ви також можете спробувати **зламати облікові дані Service Principal**, оскільки вони зазвичай менш обмежені, а їх вхід менш перевіряється.
+- Ви також можете спробувати **зламати облікові дані Service Principal**, оскільки вони зазвичай менш обмежені, і їх вхід менш перевіряється.
 
 Після обходу ви можете повернутися до вашої початкової налаштування і все ще мати доступ.
 
@@ -77,7 +77,7 @@ https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/clou
 > [!CAUTION]
 > Дізнайтеся, **як встановити** az cli, AzureAD та Az PowerShell у розділі [**Az - Entra ID**](az-services/az-azuread.md).
 
-Однією з перших речей, які вам потрібно знати, є **хто ви** (в якому середовищі ви знаходитесь):
+Одне з перших, що вам потрібно знати, це **хто ви** (в якому середовищі ви знаходитесь):
 
 {{#tabs }}
 {{#tab name="az cli" }}
@@ -120,13 +120,13 @@ Get-AzRoleAssignment -SignInName test@corp.onmicrosoft.com # For current user
 {{#endtabs }}
 
 > [!CAUTION]
-> Одна з найважливіших команд для перерахунку Azure - це **`Get-AzResource`** з Az PowerShell, оскільки вона дозволяє вам **дізнатися про ресурси, які ваш поточний користувач може бачити**.
+> Одна з найважливіших команд для перерахунку Azure - це **`Get-AzResource`** з Az PowerShell, оскільки вона дозволяє вам **дізнатися, які ресурси ваш поточний користувач може бачити**.
 >
 > Ви можете отримати ту ж інформацію в **веб-консолі**, перейшовши за посиланням [https://portal.azure.com/#view/HubsExtension/BrowseAll](https://portal.azure.com/#view/HubsExtension/BrowseAll) або шукаючи "Усі ресурси".
 
 ### ENtra ID Enumeration
 
-За замовчуванням будь-який користувач повинен мати **достатньо прав для перерахунку** таких речей, як користувачі, групи, ролі, служби-принципали... (перевірте [стандартні дозволи AzureAD](az-basic-information/#default-user-permissions)).\
+За замовчуванням будь-який користувач повинен мати **достатньо прав для перерахунку** таких речей, як користувачі, групи, ролі, служби... (перевірте [стандартні дозволи AzureAD](az-basic-information/#default-user-permissions)).\
 Тут ви можете знайти посібник:
 
 {{#ref}}
@@ -135,7 +135,7 @@ az-services/az-azuread.md
 
 > [!NOTE]
 > Тепер, коли ви **маєте деяку інформацію про свої облікові дані** (і якщо ви червона команда, сподіваюся, ви **не були виявлені**). Час з'ясувати, які сервіси використовуються в середовищі.\
-> У наступному розділі ви можете перевірити деякі способи **перерахунку деяких загальних сервісів.**
+> У наступному розділі ви можете перевірити кілька способів **перерахувати деякі загальні сервіси.**
 
 ## App Service SCM
 
@@ -147,7 +147,7 @@ az-services/az-azuread.md
 
 ## Azure DevOps
 
-Azure DevOps відокремлений від Azure. Він має репозиторії, конвеєри (yaml або реліз), дошки, вікі та інше. Групи змінних використовуються для зберігання значень змінних і секретів.
+Azure DevOps відокремлений від Azure. Він має репозиторії, конвеєри (yaml або release), дошки, вікі та інше. Групи змінних використовуються для зберігання значень змінних і секретів.
 
 ## Debug | MitM az cli
 

src/pentesting-cloud/azure-security/az-basic-information/README.md

@@ -10,12 +10,12 @@
 
 - Вона може містити **інші групи управління або підписки**.
 - Це дозволяє **застосовувати контроль управління** такі як RBAC та Azure Policy один раз на рівні групи управління і мати їх **успадкованими** всіма підписками в групі.
-- **10,000 груп управління** можуть підтримуватися в одному каталозі.
-- Дерево груп управління може підтримувати **до шести рівнів глибини**. Це обмеження не включає кореневий рівень або рівень підписки.
+- **10,000 груп** управління можуть підтримуватися в одному каталозі.
+- Дерево групи управління може підтримувати **до шести рівнів глибини**. Це обмеження не включає кореневий рівень або рівень підписки.
 - Кожна група управління та підписка можуть підтримувати **тільки одного батька**.
 - Навіть якщо кілька груп управління можуть бути створені, **існує лише 1 коренева група управління**.
 - Коренева група управління **містить** всі **інші групи управління та підписки** і **не може бути переміщена або видалена**.
-- Усі підписки в межах однієї групи управління повинні довіряти **одному й тому ж орендарю Entra ID.**
+- Всі підписки в межах однієї групи управління повинні довіряти **одному й тому ж орендарю Entra ID.**
 
 <figure><img src="../../../images/image (147).png" alt=""><figcaption><p><a href="https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png">https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png</a></p></figcaption></figure>
 
@@ -23,14 +23,14 @@
 
 - Це ще один **логічний контейнер, де можуть бути запущені ресурси** (ВМ, БД…) і за які буде виставлено рахунок.
 - Його **батьком** завжди є **група управління** (і це може бути коренева група управління), оскільки підписки не можуть містити інші підписки.
-- Він **довіряє лише одному каталогу Entra ID**
-- **Дозволи**, застосовані на рівні підписки (або будь-якого з її батьків), **успадковуються** всіма ресурсами всередині підписки
+- Він **довіряє лише одному каталогу Entra ID**.
+- **Дозволи**, застосовані на рівні підписки (або будь-якого з її батьків), **успадковуються** всіма ресурсами всередині підписки.
 
 ### Групи ресурсів
 
-[З документів:](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) Група ресурсів є **контейнером**, який містить **пов'язані ресурси** для рішення Azure. Група ресурсів може включати всі ресурси для рішення або лише ті **ресурси, які ви хочете керувати як групою**. Загалом, додавайте **ресурси**, які мають **один життєвий цикл**, до однієї групи ресурсів, щоб ви могли легко розгортати, оновлювати та видаляти їх як групу.
+[З документації:](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) Група ресурсів є **контейнером**, який містить **пов'язані ресурси** для рішення Azure. Група ресурсів може включати всі ресурси для рішення або лише ті **ресурси, які ви хочете керувати як групою**. Загалом, додавайте **ресурси**, які мають **один життєвий цикл**, до однієї групи ресурсів, щоб ви могли легко розгортати, оновлювати та видаляти їх як групу.
 
-Усі **ресурси** повинні бути **всередині групи ресурсів** і можуть належати лише до однієї групи, і якщо група ресурсів видаляється, всі ресурси всередині неї також видаляються.
+Всі **ресурси** повинні бути **всередині групи ресурсів** і можуть належати лише до однієї групи, і якщо група ресурсів видаляється, всі ресурси всередині неї також видаляються.
 
 <figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUfe8U30iP_vdZCvxX4g8nEPRLoo7v0kmCGkDn1frBPn3_GIoZ7VT2LkdsVQWCnrG_HSYNRRPM-1pSECUkbDAB-9YbUYLzpvKVLDETZS81CHWKYM4fDl3oMo5-yvTMnjdLTS2pz8U67xUTIzBhZ25MFMRkq5koKY=s2048?key=gSyKQr3HTyhvHa28Rf7LVA" alt=""><figcaption><p><a href="https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&#x26;ssl=1">https://i0.wp.com/azuredays.com/wp-content/uploads/2020/05/org.png?resize=748%2C601&#x26;ssl=1</a></p></figcaption></figure>
 
@@ -42,7 +42,7 @@
 
 - `/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}`
 
-Для віртуальної машини з ім'ям myVM у групі ресурсів `myResourceGroup` під підпискою ID `12345678-1234-1234-1234-123456789012`, ідентифікатор ресурсу Azure виглядає так:
+Для віртуальної машини з назвою myVM в групі ресурсів `myResourceGroup` під підпискою ID `12345678-1234-1234-1234-123456789012`, ідентифікатор ресурсу Azure виглядає так:
 
 - `/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM`
 
@@ -50,7 +50,7 @@
 
 ### Azure
 
-Azure є комплексною **хмарною обчислювальною платформою Microsoft, що пропонує широкий спектр послуг**, включаючи віртуальні машини, бази даних, штучний інтелект та зберігання. Вона слугує основою для хостингу та управління додатками, створення масштабованих інфраструктур і виконання сучасних навантажень у хмарі. Azure надає інструменти для розробників та ІТ-фахівців для створення, розгортання та управління додатками та послугами безперешкодно, задовольняючи різноманітні потреби від стартапів до великих підприємств.
+Azure є комплексною **хмарною обчислювальною платформою Microsoft, що пропонує широкий спектр послуг**, включаючи віртуальні машини, бази даних, штучний інтелект та зберігання. Вона слугує основою для хостингу та управління додатками, створення масштабованих інфраструктур і виконання сучасних навантажень у хмарі. Azure надає інструменти для розробників та ІТ-фахівців для безперешкодного створення, розгортання та управління додатками та послугами, задовольняючи різноманітні потреби від стартапів до великих підприємств.
 
 ### Entra ID (раніше Azure Active Directory)
 
@@ -84,7 +84,7 @@ Entra ID є хмарною **послугою управління іденти
 - Створювати групи безпеки
 - Читати неприховані членства груп
 - Додавати гостей до власних груп
-- Створювати нові додатки (_може бути вимкнено_)
+- Створювати новий додаток (_може бути вимкнено_)
 - Додавати до 50 пристроїв до Azure (_може бути вимкнено_)
 
 > [!NOTE]
@@ -93,26 +93,26 @@ Entra ID є хмарною **послугою управління іденти
 ### Дефолтні налаштовувані дозволи для користувачів
 
 - **Члени (**[**документи**](https://learn.microsoft.com/en-gb/entra/fundamentals/users-default-permissions#restrict-member-users-default-permissions)**)**
-- Реєстрація додатків: За замовчуванням **Так**
-- Обмежити неадміністративним користувачам створення орендарів: За замовчуванням **Ні**
-- Створення груп безпеки: За замовчуванням **Так**
-- Обмежити доступ до порталу адміністрування Microsoft Entra: За замовчуванням **Ні**
+- Реєстрація додатків: за замовчуванням **Так**
+- Обмежити неадміністративним користувачам створення орендарів: за замовчуванням **Ні**
+- Створення груп безпеки: за замовчуванням **Так**
+- Обмежити доступ до порталу адміністрування Microsoft Entra: за замовчуванням **Ні**
 - Це не обмежує доступ API до порталу (тільки веб)
-- Дозволити користувачам підключати робочий або шкільний обліковий запис до LinkedIn: За замовчуванням **Так**
-- Показати, щоб користувач залишався підписаним: За замовчуванням **Так**
-- Обмежити користувачів від відновлення ключа BitLocker для їхніх власних пристроїв: За замовчуванням Ні (перевірте в налаштуваннях пристрою)
-- Читати інших користувачів: За замовчуванням **Так** (через Microsoft Graph)
+- Дозволити користувачам підключати робочий або шкільний обліковий запис до LinkedIn: за замовчуванням **Так**
+- Показати, щоб користувач залишався підписаним: за замовчуванням **Так**
+- Обмежити користувачів від відновлення ключа BitLocker для їхніх власних пристроїв: за замовчуванням Ні (перевірте в налаштуваннях пристрою)
+- Читати інших користувачів: за замовчуванням **Так** (через Microsoft Graph)
 - **Гості**
 - **Обмеження доступу для користувачів-гостей**
 - **Користувачі-гості мають такий же доступ, як і члени**, надає всі дозволи користувачів-членів користувачам-гостям за замовчуванням.
 - **Користувачі-гості мають обмежений доступ до властивостей та членств об'єктів каталогу (за замовчуванням)** обмежує доступ гостей лише до їхнього власного профілю користувача за замовчуванням. Доступ до інформації про інших користувачів та групи більше не дозволяється.
-- **Доступ користувачів-гостей обмежений до властивостей та членств їхніх власних об'єктів каталогу** є найобмежувальнішим.
+- **Доступ користувачів-гостей обмежений до властивостей та членств їхніх власних об'єктів каталогу** є найбільш обмежувальним.
 - **Гості можуть запрошувати**
-- **Будь-хто в організації може запрошувати користувачів-гостей, включаючи гостей та неадміністраторів (найбільш інклюзивно) - За замовчуванням**
+- **Будь-хто в організації може запрошувати користувачів-гостей, включаючи гостей та неадміністраторів (найбільш інклюзивно) - за замовчуванням**
 - **Користувачі-члени та користувачі, призначені на конкретні адміністративні ролі, можуть запрошувати користувачів-гостей, включаючи гостей з правами членів**
 - **Тільки користувачі, призначені на конкретні адміністративні ролі, можуть запрошувати користувачів-гостей**
 - **Ніхто в організації не може запрошувати користувачів-гостей, включаючи адміністраторів (найбільш обмежувально)**
-- **Зовнішні користувачі можуть залишити**: За замовчуванням **Правда**
+- **Зовнішні користувачі можуть залишити**: за замовчуванням **Правда**
 - Дозволити зовнішнім користувачам залишити організацію
 
 > [!TIP]
@@ -122,20 +122,20 @@ Entra ID є хмарною **послугою управління іденти
 
 Є **2 типи груп**:
 
-- **Безпека**: Цей тип групи використовується для надання членам доступу до додатків, ресурсів та призначення ліцензій. Користувачі, пристрої, службові принципали та інші групи можуть бути членами.
+- **Безпека**: Цей тип групи використовується для надання членам доступу до додатків, ресурсів та призначення ліцензій. Членами можуть бути користувачі, пристрої, службові принципали та інші групи.
 - **Microsoft 365**: Цей тип групи використовується для співпраці, надаючи членам доступ до спільної поштової скриньки, календаря, файлів, сайту SharePoint тощо. Членами групи можуть бути лише користувачі.
 - Це матиме **електронну адресу** з доменом орендаря EntraID.
 
-Є **2 типи членств**:
+Є **2 типи членства**:
 
 - **Призначене**: Дозволяє вручну додавати конкретних членів до групи.
 - **Динамічне членство**: Автоматично керує членством за допомогою правил, оновлюючи включення групи, коли змінюються атрибути членів.
 
 ### **Службові принципали**
 
-**Службовий принципал** - це **ідентифікація**, створена для **використання** з **додатками**, хостинговими службами та автоматизованими інструментами для доступу до ресурсів Azure. Цей доступ **обмежений ролями, призначеними** службовому принципалу, що дає вам контроль над **тим, які ресурси можуть бути доступні** і на якому рівні. З міркувань безпеки завжди рекомендується **використовувати службові принципали з автоматизованими інструментами**, а не дозволяти їм входити з ідентифікацією користувача.
+**Службовий принципал** - це **ідентифікація**, створена для **використання** з **додатками**, хостингованими службами та автоматизованими інструментами для доступу до ресурсів Azure. Цей доступ **обмежений ролями, призначеними** службовому принципалу, що дає вам контроль над **тим, які ресурси можуть бути доступні** і на якому рівні. З міркувань безпеки завжди рекомендується **використовувати службові принципали з автоматизованими інструментами**, а не дозволяти їм входити з ідентифікацією користувача.
 
-Можливо **безпосередньо увійти як службовий принципал**, згенерувавши йому **секрет** (пароль), **сертифікат** або надавши **федеративний** доступ до сторонніх платформ (наприклад, Github Actions) через нього.
+Можливо **безпосередньо увійти як службовий принципал**, створивши для нього **секрет** (пароль), **сертифікат** або надавши **федеративний** доступ до сторонніх платформ (наприклад, Github Actions).
 
 - Якщо ви виберете **автентифікацію за паролем** (за замовчуванням), **збережіть згенерований пароль**, оскільки ви не зможете отримати до нього доступ знову.
 - Якщо ви виберете автентифікацію за сертифікатом, переконайтеся, що **додаток матиме доступ до приватного ключа**.
@@ -148,10 +148,10 @@ Entra ID є хмарною **послугою управління іденти
 
 1. **Ідентифікатор додатка (Client ID):** Унікальний ідентифікатор для вашого додатка в Azure AD.
 2. **URI перенаправлення:** URL-адреси, куди Azure AD надсилає відповіді на аутентифікацію.
-3. **Сертифікати, секрети та федеративні облікові дані:** Можливо згенерувати секрет або сертифікат для входу як службовий принципал додатка або надати федеративний доступ до нього (наприклад, Github Actions).&#x20;
+3. **Сертифікати, секрети та федеративні облікові дані:** Можливо згенерувати секрет або сертифікат для входу як службовий принципал додатка або надати федеративний доступ до нього (наприклад, Github Actions).
 1. Якщо **сертифікат** або **секрет** згенеровано, особа може **увійти як службовий принципал** за допомогою CLI-інструментів, знаючи **ідентифікатор додатка**, **секрет** або **сертифікат** та **орендар** (домен або ID).
 4. **API Дозволи:** Визначає, до яких ресурсів або API додаток може отримати доступ.
-5. **Налаштування автентифікації:** Визначає підтримувані потоки автентифікації додатка (наприклад, OAuth2, OpenID Connect).
+5. **Налаштування аутентифікації:** Визначає підтримувані потоки аутентифікації додатка (наприклад, OAuth2, OpenID Connect).
 6. **Службовий принципал**: Службовий принципал створюється, коли створюється додаток (якщо це робиться з веб-консолі) або коли він встановлюється в новому орендарі.
 1. **Службовий принципал** отримає всі запитувані дозволи, з якими він був налаштований.
 
@@ -160,32 +160,32 @@ Entra ID є хмарною **послугою управління іденти
 **Згода користувачів на додатки**
 
 - **Не дозволяти згоду користувачів**
-- Для всіх додатків буде потрібен адміністратор.
+- Адміністратор буде потрібен для всіх додатків.
 - **Дозволити згоду користувачів на додатки від перевірених видавців, для вибраних дозволів (рекомендується)**
 - Усі користувачі можуть дати згоду на дозволи, класифіковані як "низький вплив", для додатків від перевірених видавців або додатків, зареєстрованих в цій організації.
-- **За замовчуванням** низько впливові дозволи (хоча вам потрібно прийняти, щоб додати їх як низькі):
+- **Дефолтні** дозволи низького впливу (хоча вам потрібно прийняти, щоб додати їх як низькі):
 - User.Read - увійти та прочитати профіль користувача
 - offline_access - підтримувати доступ до даних, до яких користувачі надали доступ
-- openid - входити користувачів
+- openid - увійти користувачів
 - profile - переглядати основний профіль користувача
 - email - переглядати електронну адресу користувача
 - **Дозволити згоду користувачів на додатки (за замовчуванням)**
 - Усі користувачі можуть дати згоду на будь-який додаток для доступу до даних організації.
 
-**Запити на згоду адміністратора**: За замовчуванням **Ні**
+**Запити на згоду адміністратора**: за замовчуванням **Ні**
 
 - Користувачі можуть запитувати згоду адміністратора на додатки, на які вони не можуть дати згоду
 - Якщо **Так**: Можливо вказати Користувачів, Групи та Ролі, які можуть давати згоду на запити
-- Налаштуйте також, чи отримуватимуть користувачі електронні сповіщення та нагадування про закінчення терміну&#x20;
+- Налаштуйте також, чи отримуватимуть користувачі електронні сповіщення та нагадування про закінчення терміну дії&#x20;
 
 ### **Керована ідентичність (Метадані)**
 
-Керовані ідентичності в Azure Active Directory пропонують рішення для **автоматичного управління ідентичністю** додатків. Ці ідентичності використовуються додатками для **підключення** до **ресурсів**, сумісних з автентифікацією Azure Active Directory (**Azure AD**). Це дозволяє **усунути необхідність жорсткого кодування облікових даних хмари** в коді, оскільки додаток зможе звертатися до **служби метаданих**, щоб отримати дійсний токен для **виконання дій** як вказана керована ідентичність в Azure.
+Керовані ідентичності в Azure Active Directory пропонують рішення для **автоматичного управління ідентичністю** додатків. Ці ідентичності використовуються додатками для **підключення** до **ресурсів**, сумісних з аутентифікацією Azure Active Directory (**Azure AD**). Це дозволяє **усунути необхідність жорсткого кодування облікових даних хмари** в коді, оскільки додаток зможе звертатися до **служби метаданих**, щоб отримати дійсний токен для **виконання дій** як вказана керована ідентичність в Azure.
 
 Існує два типи керованих ідентичностей:
 
 - **Призначена системою**. Деякі служби Azure дозволяють вам **увімкнути керовану ідентичність безпосередньо на екземплярі служби**. Коли ви увімкнете керовану ідентичність, призначену системою, **службовий принципал** створюється в орендарі Entra ID, довіреному підписці, де розташований ресурс. Коли **ресурс** **видаляється**, Azure автоматично **видаляє** **ідентичність** за вас.
-- **Призначена користувачем**. Також можливо, щоб користувачі генерували керовані ідентичності. Вони створюються всередині групи ресурсів в межах підписки, і службовий принципал буде створений в EntraID, довіреному підписці. Потім ви можете призначити керовану ідентичність одному або **кільком екземплярам** служби Azure (кільком ресурсам). Для керованих ідентичностей, призначених користувачем, **ідентичність управляється окремо від ресурсів, які її використовують**.
+- **Призначена користувачем**. Також можливо, щоб користувачі генерували керовані ідентичності. Вони створюються всередині групи ресурсів в межах підписки, і службовий принципал буде створено в EntraID, довіреному підписці. Потім ви можете призначити керовану ідентичність одному або **кільком екземплярам** служби Azure (кільком ресурсам). Для керованих ідентичностей, призначених користувачем, **ідентичність управляється окремо від ресурсів, які її використовують**.
 
 Керовані ідентичності **не генерують вічні облікові дані** (як паролі або сертифікати) для доступу як службовий принципал, прикріплений до них.
 
@@ -193,7 +193,7 @@ Entra ID є хмарною **послугою управління іденти
 
 Це просто **таблиця в Azure для фільтрації службових принципалів** та перевірки додатків, які були призначені.
 
-**Це не інший тип "додатка",** в Azure немає жодного об'єкта, який є "підприємницьким додатком", це просто абстракція для перевірки службових принципалів, реєстрацій додатків та керованих ідентичностей.
+**Це не ще один тип "додатку",** в Azure немає жодного об'єкта, який є "підприємницьким додатком", це просто абстракція для перевірки службових принципалів, реєстрацій додатків та керованих ідентичностей.
 
 ### Адміністративні одиниці
 
@@ -201,22 +201,22 @@ Entra ID є хмарною **послугою управління іденти
 
 Приклад:
 
-- Сценарій: Компанія хоче, щоб регіональні ІТ-адміністратори управляли лише користувачами у своєму регіоні.
+- Сценарій: Компанія хоче, щоб регіональні ІТ-адміністратори управляли лише користувачами у своїй власній області.
 - Реалізація:
 - Створіть адміністративні одиниці для кожного регіону (наприклад, "Північна Америка AU", "Європа AU").
 - Заповніть AU користувачами з їхніх відповідних регіонів.
 - AU можуть **містити користувачів, групи або пристрої**
 - AU підтримують **динамічні членства**
 - AU **не можуть містити AU**
-- Призначити адміністративні ролі:
+- Призначте адміністративні ролі:
 - Надати роль "Адміністратор користувачів" регіональному ІТ-персоналу, обмежену до AU їхнього регіону.
-- Результат: Регіональні ІТ-адміністратори можуть управляти обліковими записами користувачів у своєму регіоні, не впливаючи на інші регіони.
+- Результат: Регіональні ІТ-адміністратори можуть управляти обліковими записами користувачів у межах свого регіону, не впливаючи на інші регіони.
 
 ### Ролі Entra ID
 
 - Для управління Entra ID існують деякі **вбудовані ролі**, які можуть бути призначені принципалам Entra ID для управління Entra ID
 - Перевірте ролі в [https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)
-- Найпривілейованішою роллю є **Глобальний адміністратор**
+- Найбільш привілейована роль - **Глобальний адміністратор**
 - У описі ролі можна побачити її **деталізовані дозволи**
 
 ## Ролі та дозволи
@@ -232,20 +232,20 @@ Entra ID є хмарною **послугою управління іденти
 | **Власник**                  | <ul><li>Повний доступ до всіх ресурсів</li><li>Може управляти доступом для інших користувачів</li></ul> | Усі типи ресурсів |
 | ----------------------------- | ---------------------------------------------------------------------------------------- | ------------------ |
 | **Співробітник**             | <ul><li>Повний доступ до всіх ресурсів</li><li>Не може управляти доступом</li></ul>              | Усі типи ресурсів |
-| **Читач**                    | • Перегляд усіх ресурсів                                                                     | Усі типи ресурсів |
-| **Адміністратор доступу користувачів** | <ul><li>Перегляд усіх ресурсів</li><li>Може управляти доступом для інших користувачів</li></ul>           | Усі типи ресурсів |
+| **Читач**                    | • Перегляд всіх ресурсів                                                                     | Усі типи ресурсів |
+| **Адміністратор доступу користувачів** | <ul><li>Перегляд всіх ресурсів</li><li>Може управляти доступом для інших користувачів</li></ul>           | Усі типи ресурсів |
 
 ### Вбудовані ролі
 
-[З документів: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Контроль доступу на основі ролей Azure (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) має кілька **вбудованих ролей Azure**, які ви можете **призначити** **користувачам, групам, службовим принципалам та керованим ідентичностям**. Призначення ролей - це спосіб контролювати **доступ до ресурсів Azure**. Якщо вбудовані ролі не відповідають конкретним потребам вашої організації, ви можете створити свої власні [**кастомні ролі Azure**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**.**
+[З документації: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure рольова модель доступу (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) має кілька **вбудованих ролей Azure**, які ви можете **призначити** користувачам, групам, службовим принципалам та керованим ідентичностям. Призначення ролей - це спосіб контролю **доступу до ресурсів Azure**. Якщо вбудовані ролі не відповідають конкретним потребам вашої організації, ви можете створити свої власні [**кастомні ролі Azure**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**.**
 
-**Вбудовані** ролі застосовуються лише до **ресурсів**, для яких вони **призначені**, наприклад, перевірте ці 2 приклади **вбудованих ролей** для ресурсів **Обчислення**:
+**Вбудовані** ролі застосовуються лише до **ресурсів**, для яких вони **призначені**, наприклад, перевірте ці 2 приклади **вбудованих ролей для ресурсів обчислення**:
 
 | [Читач резервного копіювання диска](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader)                 | Надає дозвіл резервному сховищу виконувати резервне копіювання диска.      | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
 | ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ |
-| [Вхід користувача віртуальної машини](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | Перегляд віртуальних машин у порталі та вхід як звичайний користувач. | fb879df8-f326-4884-b1cf-06f3ad86be52 |
+| [Користувач віртуальної машини](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | Перегляд віртуальних машин у порталі та вхід як звичайний користувач. | fb879df8-f326-4884-b1cf-06f3ad86be52 |
 
-Ці ролі також можуть **призначатися над логічними контейнерами** (такими як групи управління, підписки та групи ресурсів), і принципали, які підпадають під їхній вплив, матимуть їх **над ресурсами всередині цих контейнерів**.
+Ці ролі також можуть **призначатися над логічними контейнерами** (такими як групи управління, підписки та групи ресурсів), і принципали, на яких це вплине, матимуть їх **над ресурсами всередині цих контейнерів**.
 
 - Знайдіть тут список з [**усіма вбудованими ролями Azure**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles).
 - Знайдіть тут список з [**усіма вбудованими ролями Entra ID**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference).
@@ -292,47 +292,47 @@ Entra ID є хмарною **послугою управління іденти
 }
 }
 ```
-### Permissions order
+### Порядок дозволів
 
 - Щоб **суб'єкт мав доступ до ресурсу**, йому потрібно явно надати роль (будь-яким чином), **яка надає йому це дозволення**.
 - Явне **призначення ролі заборони має пріоритет** над роллю, що надає дозволення.
 
 <figure><img src="../../../images/image (191).png" alt=""><figcaption><p><a href="https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10">https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10</a></p></figcaption></figure>
 
-### Global Administrator
+### Глобальний адміністратор
 
-Global Administrator — це роль з Entra ID, яка надає **повний контроль над орендою Entra ID**. Однак за замовчуванням вона не надає жодних дозволів на ресурси Azure.
+Глобальний адміністратор — це роль з Entra ID, яка надає **повний контроль над орендою Entra ID**. Однак за замовчуванням вона не надає жодних дозволів на ресурси Azure.
 
-Користувачі з роллю Global Administrator мають можливість '**підвищити' до ролі User Access Administrator Azure в кореневій групі управління**. Таким чином, Global Administrators можуть керувати доступом у **всіх підписках Azure та групах управління.**\
+Користувачі з роллю глобального адміністратора мають можливість '**підвищити' до ролі адміністратора доступу користувачів Azure в кореневій групі управління**. Таким чином, глобальні адміністратори можуть керувати доступом у **всіх підписках Azure та групах управління.**\
 Це підвищення можна здійснити в кінці сторінки: [https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/\~/Properties](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties)
 
 <figure><img src="../../../images/image (349).png" alt=""><figcaption></figcaption></figure>
 
-### Azure Policies
+### Політики Azure
 
-**Azure Policies** — це правила, які допомагають організаціям забезпечити відповідність їх ресурсів певним стандартам і вимогам. Вони дозволяють **застосовувати або перевіряти налаштування на ресурсах в Azure**. Наприклад, ви можете заборонити створення віртуальних машин в несанкціонованому регіоні або забезпечити, щоб усі ресурси мали певні теги для відстеження.
+**Політики Azure** — це правила, які допомагають організаціям забезпечити відповідність їх ресурсів певним стандартам і вимогам. Вони дозволяють **забезпечувати або перевіряти налаштування ресурсів в Azure**. Наприклад, ви можете заборонити створення віртуальних машин в несанкціонованому регіоні або забезпечити, щоб усі ресурси мали певні теги для відстеження.
 
-Azure Policies є **проактивними**: вони можуть зупинити створення або зміну несумісних ресурсів. Вони також є **реактивними**, дозволяючи вам знаходити та виправляти існуючі несумісні ресурси.
+Політики Azure є **проактивними**: вони можуть зупинити створення або зміну ресурсів, які не відповідають вимогам. Вони також є **реактивними**, дозволяючи вам знаходити та виправляти існуючі ресурси, що не відповідають вимогам.
 
-#### **Key Concepts**
+#### **Ключові концепції**
 
-1. **Policy Definition**: Правило, написане в JSON, яке визначає, що дозволено або вимагається.
-2. **Policy Assignment**: Застосування політики до конкретної області (наприклад, підписка, група ресурсів).
-3. **Initiatives**: Збірка політик, згрупованих разом для ширшого застосування.
-4. **Effect**: Визначає, що відбувається, коли політика спрацьовує (наприклад, "Заборонити", "Аудит" або "Додати").
+1. **Визначення політики**: Правило, написане в JSON, яке вказує, що дозволено або вимагається.
+2. **Призначення політики**: Застосування політики до конкретної області (наприклад, підписка, група ресурсів).
+3. **Ініціативи**: Збірка політик, об'єднаних для ширшого застосування.
+4. **Ефект**: Вказує, що відбувається, коли політика спрацьовує (наприклад, "Заборонити", "Аудит" або "Додати").
 
 **Деякі приклади:**
 
 1. **Забезпечення відповідності певним регіонам Azure**: Ця політика забезпечує, щоб усі ресурси розгорталися в певних регіонах Azure. Наприклад, компанія може захотіти, щоб усі її дані зберігалися в Європі для відповідності GDPR.
 2. **Забезпечення стандартів іменування**: Політики можуть забезпечувати дотримання стандартів іменування для ресурсів Azure. Це допомагає в організації та легкому ідентифікуванні ресурсів за їхніми іменами, що корисно в великих середовищах.
 3. **Обмеження певних типів ресурсів**: Ця політика може обмежити створення певних типів ресурсів. Наприклад, політика може бути встановлена для заборони створення дорогих типів ресурсів, таких як певні розміри ВМ, для контролю витрат.
-4. **Забезпечення політик тегування**: Теги — це пари ключ-значення, пов'язані з ресурсами Azure, які використовуються для управління ресурсами. Політики можуть забезпечувати, щоб певні теги були присутні, або мали конкретні значення, для всіх ресурсів. Це корисно для відстеження витрат, власності або категоризації ресурсів.
+4. **Забезпечення політик тегування**: Теги — це пари ключ-значення, пов'язані з ресурсами Azure, які використовуються для управління ресурсами. Політики можуть забезпечувати, щоб певні теги були присутні, або мали певні значення, для всіх ресурсів. Це корисно для відстеження витрат, власності або категоризації ресурсів.
 5. **Обмеження публічного доступу до ресурсів**: Політики можуть забезпечувати, щоб певні ресурси, такі як облікові записи зберігання або бази даних, не мали публічних кінцевих точок, забезпечуючи, щоб вони були доступні лише в межах мережі організації.
-6. **Автоматичне застосування налаштувань безпеки**: Політики можуть використовуватися для автоматичного застосування налаштувань безпеки до ресурсів, таких як застосування конкретної групи безпеки мережі до всіх ВМ або забезпечення, щоб усі облікові записи зберігання використовували шифрування.
+6. **Автоматичне застосування налаштувань безпеки**: Політики можуть використовуватися для автоматичного застосування налаштувань безпеки до ресурсів, таких як застосування певної групи безпеки мережі до всіх ВМ або забезпечення, щоб усі облікові записи зберігання використовували шифрування.
 
-Зверніть увагу, що Azure Policies можуть бути прикріплені до будь-якого рівня ієрархії Azure, але вони **зазвичай використовуються в кореневій групі управління** або в інших групах управління.
+Зверніть увагу, що політики Azure можуть бути прикріплені до будь-якого рівня ієрархії Azure, але вони **зазвичай використовуються в кореневій групі управління** або в інших групах управління.
 
-Azure policy json example:
+Приклад політики Azure json:
 ```json
 {
 "policyRule": {
@@ -354,7 +354,7 @@ Azure policy json example:
 
 В Azure **дозволи можуть бути призначені будь-якій частині ієрархії**. Це включає управлінські групи, підписки, групи ресурсів та окремі ресурси. Дозволи **спадкуються** від вміщених **ресурсів** сутності, до якої вони були призначені.
 
-Ця ієрархічна структура дозволяє ефективно та масштабовано управляти доступом до дозволів.
+Ця ієрархічна структура дозволяє ефективно та масштабовано управляти дозволами доступу.
 
 <figure><img src="../../../images/image (26).png" alt=""><figcaption></figcaption></figure>
 
@@ -363,7 +363,7 @@ Azure policy json example:
 **RBAC** (контроль доступу на основі ролей) - це те, що ми вже бачили в попередніх розділах: **Призначення ролі суб'єкту для надання йому доступу** до ресурсу.\
 Однак у деяких випадках ви можете захотіти надати **більш детальне управління доступом** або **спростити** управління **сотнями** призначень ролей.
 
-Azure **ABAC** (контроль доступу на основі атрибутів) базується на Azure RBAC, додаючи **умови призначення ролей на основі атрибутів** у контексті конкретних дій. _Умова призначення ролі_ - це **додаткова перевірка, яку ви можете за бажанням додати до вашого призначення ролі** для надання більш детального контролю доступу. Умова фільтрує дозволи, надані в рамках визначення ролі та призначення ролі. Наприклад, ви можете **додати умову, яка вимагає, щоб об'єкт мав певний тег для читання об'єкта**.\
+Azure **ABAC** (контроль доступу на основі атрибутів) базується на Azure RBAC, додаючи **умови призначення ролі на основі атрибутів** у контексті конкретних дій. _Умова призначення ролі_ - це **додаткова перевірка, яку ви можете за бажанням додати до свого призначення ролі** для надання більш детального контролю доступу. Умова фільтрує дозволи, надані в рамках визначення ролі та призначення ролі. Наприклад, ви можете **додати умову, яка вимагає, щоб об'єкт мав певний тег для читання об'єкта**.\
 Ви **не можете** явно **заборонити** **доступ** до конкретних ресурсів **за допомогою умов**.
 
 ## Посилання

src/pentesting-cloud/azure-security/az-basic-information/az-tokens-and-public-applications.md

@@ -1,60 +1,60 @@
-# Az - Tokens & Public Applications
+# Az - Токени та Публічні Застосунки
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Basic Information
+## Основна Інформація
 
 Entra ID - це хмарна платформа управління ідентифікацією та доступом (IAM) від Microsoft, яка слугує основною системою аутентифікації та авторизації для таких сервісів, як Microsoft 365 та Azure Resource Manager. Azure AD реалізує фреймворк авторизації OAuth 2.0 та протокол аутентифікації OpenID Connect (OIDC) для управління доступом до ресурсів.
 
 ### OAuth
 
-**Ключові учасники в OAuth 2.0:**
+**Ключові Учасники в OAuth 2.0:**
 
-1. **Сервер ресурсів (RS):** Захищає ресурси, що належать власнику ресурсу.
-2. **Власник ресурсу (RO):** Зазвичай кінцевий користувач, який володіє захищеними ресурсами.
-3. **Клієнтський додаток (CA):** Додаток, що намагається отримати доступ до ресурсів від імені власника ресурсу.
-4. **Сервер авторизації (AS):** Видає токени доступу клієнтським додаткам після їх аутентифікації та авторизації.
+1. **Сервер Ресурсів (RS):** Захищає ресурси, що належать власнику ресурсу.
+2. **Власник Ресурсу (RO):** Зазвичай кінцевий користувач, який володіє захищеними ресурсами.
+3. **Клієнтський Застосунок (CA):** Застосунок, що намагається отримати доступ до ресурсів від імені власника ресурсу.
+4. **Сервер Авторизації (AS):** Видає токени доступу клієнтським застосункам після їх аутентифікації та авторизації.
 
-**Обсяги та згода:**
+**Обсяги та Згода:**
 
 - **Обсяги:** Дрібні дозволи, визначені на сервері ресурсів, які вказують рівні доступу.
-- **Згода:** Процес, за допомогою якого власник ресурсу надає клієнтському додатку дозвіл на доступ до ресурсів з конкретними обсягами.
+- **Згода:** Процес, за допомогою якого власник ресурсу надає клієнтському застосунку дозвіл на доступ до ресурсів з конкретними обсягами.
 
 **Інтеграція з Microsoft 365:**
 
-- Microsoft 365 використовує Azure AD для IAM і складається з кількох "первинних" OAuth додатків.
-- Ці додатки глибоко інтегровані та часто мають взаємозалежні відносини сервісів.
-- Щоб спростити користувацький досвід і підтримувати функціональність, Microsoft надає "неявну згоду" або "попередню згоду" цим первинним додаткам.
-- **Неявна згода:** Деяким додаткам автоматично **надається доступ до конкретних обсягів без явного схвалення користувача або адміністратора**.
+- Microsoft 365 використовує Azure AD для IAM і складається з кількох "первинних" OAuth застосунків.
+- Ці застосунки глибоко інтегровані та часто мають взаємозалежні відносини сервісів.
+- Щоб спростити користувацький досвід і підтримувати функціональність, Microsoft надає "неявну згоду" або "попередню згоду" цим первинним застосункам.
+- **Неявна Згода:** Деяким застосункам автоматично **надається доступ до конкретних обсягів без явного схвалення користувача або адміністратора**.
 - Ці попередньо погоджені обсяги зазвичай приховані як від користувачів, так і від адміністраторів, що робить їх менш видимими в стандартних інтерфейсах управління.
 
-**Типи клієнтських додатків:**
+**Типи Клієнтських Застосунків:**
 
-1. **Конфіденційні клієнти:**
+1. **Конфіденційні Клієнти:**
 - Мають свої власні облікові дані (наприклад, паролі або сертифікати).
 - Можуть **надійно аутентифікувати себе** на сервері авторизації.
-2. **Публічні клієнти:**
+2. **Публічні Клієнти:**
 - Не мають унікальних облікових даних.
 - Не можуть надійно аутентифікуватися на сервері авторизації.
-- **Безпекове наслідок:** Зловмисник може видавати себе за публічний клієнтський додаток при запиті токенів, оскільки немає механізму для сервера авторизації, щоб перевірити легітимність додатка.
+- **Безпекове Значення:** Зловмисник може видавати себе за публічний клієнтський застосунок при запиті токенів, оскільки немає механізму для перевірки легітимності застосунку на сервері авторизації.
 
-## Authentication Tokens
+## Токени Аутентифікації
 
 Існує **три типи токенів**, що використовуються в OIDC:
 
-- [**Токени доступу**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** Клієнт представляє цей токен серверу ресурсів для **доступу до ресурсів**. Він може використовуватися лише для конкретної комбінації користувача, клієнта та ресурсу і **не може бути відкликаний** до закінчення терміну дії - тобто 1 година за замовчуванням.
-- **ID токени**: Клієнт отримує цей **токен від сервера авторизації**. Він містить основну інформацію про користувача. Він **прив'язаний до конкретної комбінації користувача та клієнта**.
-- **Токени оновлення**: Надаються клієнту разом з токеном доступу. Використовуються для **отримання нових токенів доступу та ID токенів**. Він прив'язаний до конкретної комбінації користувача та клієнта і може бути відкликаний. За замовчуванням термін дії становить **90 днів** для неактивних токенів оновлення та **немає терміну дії для активних токенів** (з токена оновлення можливо отримати нові токени оновлення).
-- Токен оновлення повинен бути прив'язаний до **`aud`**, до деяких **обсягів** та до **орендаря**, і він повинен мати можливість генерувати токени доступу лише для цього aud, обсягів (і не більше) та орендаря. Однак це не так для **токенів додатків FOCI**.
+- [**Токени Доступу**](https://learn.microsoft.com/en-us/azure/active-directory/develop/access-tokens)**:** Клієнт представляє цей токен серверу ресурсів для **доступу до ресурсів**. Він може використовуватися лише для конкретної комбінації користувача, клієнта та ресурсу і **не може бути відкликаний** до закінчення терміну дії - тобто 1 година за замовчуванням.
+- **ID Токени**: Клієнт отримує цей **токен від сервера авторизації**. Він містить основну інформацію про користувача. Він **прив'язаний до конкретної комбінації користувача та клієнта**.
+- **Токени Оновлення**: Надаються клієнту разом з токеном доступу. Використовуються для **отримання нових токенів доступу та ID токенів**. Він прив'язаний до конкретної комбінації користувача та клієнта і може бути відкликаний. За замовчуванням термін дії становить **90 днів** для неактивних токенів оновлення та **немає терміну дії для активних токенів** (з токена оновлення можливо отримати нові токени оновлення).
+- Токен оновлення повинен бути прив'язаний до **`aud`**, до деяких **обсягів** та до **орендаря**, і він повинен мати можливість генерувати токени доступу лише для цього aud, обсягів (і не більше) та орендаря. Однак це не так для **токенів застосунків FOCI**.
 - Токен оновлення зашифрований, і лише Microsoft може його розшифрувати.
 - Отримання нового токена оновлення не відкликає попередній токен оновлення.
 
 > [!WARNING]
 > Інформація для **умовного доступу** **зберігається** всередині **JWT**. Тому, якщо ви запитуєте **токен з дозволеної IP-адреси**, ця **IP** буде **збережена** в токені, і тоді ви зможете використовувати цей токен з **недозволеної IP для доступу до ресурсів**.
 
-### Access Tokens "aud"
+### Токени Доступу "aud"
 
-Поле, вказане в полі "aud", є **сервером ресурсів** (додатком), що використовується для виконання входу.
+Поле, вказане в полі "aud", є **сервером ресурсів** (застосунком), що використовується для виконання входу.
 
 Команда `az account get-access-token --resource-type [...]` підтримує такі типи, і кожен з них додасть конкретний "aud" у результативний токен доступу:
 
@@ -65,13 +65,13 @@ Entra ID - це хмарна платформа управління ідент
 
 <summary>приклади aud</summary>
 
-- **aad-graph (Azure Active Directory Graph API)**: Використовується для доступу до застарілого Azure AD Graph API (депрецированого), який дозволяє додаткам читати та записувати дані каталогу в Azure Active Directory (Azure AD).
+- **aad-graph (Azure Active Directory Graph API)**: Використовується для доступу до застарілого Azure AD Graph API (депрецированого), який дозволяє застосункам читати та записувати дані каталогу в Azure Active Directory (Azure AD).
 - `https://graph.windows.net/`
 
 * **arm (Azure Resource Manager)**: Використовується для управління ресурсами Azure через API Azure Resource Manager. Це включає операції, такі як створення, оновлення та видалення ресурсів, таких як віртуальні машини, облікові записи зберігання тощо.
 - `https://management.core.windows.net/ or https://management.azure.com/`
 
-- **batch (Azure Batch Services)**: Використовується для доступу до Azure Batch, сервісу, який дозволяє ефективно виконувати великомасштабні паралельні та високопродуктивні обчислювальні програми в хмарі.
+- **batch (Azure Batch Services)**: Використовується для доступу до Azure Batch, сервісу, який дозволяє ефективно виконувати великомасштабні паралельні та високопродуктивні обчислювальні застосунки в хмарі.
 - `https://batch.core.windows.net/`
 
 * **data-lake (Azure Data Lake Storage)**: Використовується для взаємодії з Azure Data Lake Storage Gen1, який є масштабованим сервісом зберігання даних та аналітики.
@@ -88,13 +88,13 @@ Entra ID - це хмарна платформа управління ідент
 
 </details>
 
-### Access Tokens Scopes "scp"
+### Обсяги Токенів Доступу "scp"
 
 Обсяг токена доступу зберігається всередині ключа scp всередині JWT токена доступу. Ці обсяги визначають, до чого має доступ токен доступу.
 
-Якщо JWT дозволено контактувати з конкретним API, але **не має обсягу** для виконання запитуваної дії, він **не зможе виконати дію** з цим JWT.
+Якщо JWT дозволено контактувати з конкретним API, але **не має обсягу** для виконання запитаної дії, він **не зможе виконати дію** з цим JWT.
 
-### Get refresh & access token example
+### Приклад отримання токена оновлення та доступу
 ```python
 # Code example from https://github.com/secureworks/family-of-client-ids-research
 import msal
@@ -121,7 +121,6 @@ device_flow
 pprint(azure_cli_bearer_tokens_for_graph_api)
 
 
-
 # DECODE JWT
 def decode_jwt(base64_blob: str) -> Dict[str, Any]:
 """Decodes base64 encoded JWT blob"""
@@ -147,7 +146,7 @@ pprint(new_azure_cli_bearer_tokens_for_graph_api)
 ```
 ## FOCI Tokens Privilege Escalation
 
-Раніше згадувалося, що токени оновлення повинні бути прив'язані до **scopes**, з якими вони були згенеровані, до **додатку** та **орендаря**, для яких вони були згенеровані. Якщо будь-яка з цих меж буде порушена, можливо підвищити привілеї, оскільки буде можливим генерувати токени доступу до інших ресурсів і орендарів, до яких користувач має доступ, і з більшими scopes, ніж це було спочатку передбачено.
+Раніше згадувалося, що токени оновлення повинні бути прив'язані до **областей** (scopes), з якими вони були згенеровані, до **додатку** та **орендаря** (tenant), для якого вони були згенеровані. Якщо будь-яка з цих меж буде порушена, можливо підвищити привілеї, оскільки буде можливим генерувати токени доступу до інших ресурсів і орендарів, до яких користувач має доступ, і з більшою кількістю областей, ніж це було спочатку передбачено.
 
 Більше того, **це можливо з усіма токенами оновлення** в [Microsoft identity platform](https://learn.microsoft.com/en-us/entra/identity-platform/) (облікові записи Microsoft Entra, особисті облікові записи Microsoft та соціальні облікові записи, такі як Facebook і Google), оскільки, як зазначають [**документи**](https://learn.microsoft.com/en-us/entra/identity-platform/refresh-tokens): "Токени оновлення прив'язані до комбінації користувача та клієнта, але **не прив'язані до ресурсу або орендаря**. Клієнт може використовувати токен оновлення для отримання токенів доступу **в будь-якій комбінації ресурсу та орендаря**, де він має на це дозвіл. Токени оновлення зашифровані, і лише платформа ідентичності Microsoft може їх читати."
 
@@ -157,7 +156,7 @@ pprint(new_azure_cli_bearer_tokens_for_graph_api)
 
 ### Get different scope
 
-Продовжуючи попередній приклад коду, у цьому коді запитується новий токен для іншого scope:
+Продовжуючи попередній приклад коду, у цьому коді запитується новий токен для іншої області:
 ```python
 # Code from https://github.com/secureworks/family-of-client-ids-research
 azure_cli_bearer_tokens_for_outlook_api = (
@@ -174,7 +173,7 @@ scopes=[
 )
 pprint(azure_cli_bearer_tokens_for_outlook_api)
 ```
-### Отримати різні клієнти та області дії
+### Отримати різні клієнти та області
 ```python
 # Code from https://github.com/secureworks/family-of-client-ids-research
 microsoft_office_client = msal.PublicClientApplication("d3590ed6-52b3-4102-aeff-aad2292ab01c")

src/pentesting-cloud/azure-security/az-device-registration.md

@@ -10,7 +10,7 @@
 
 Потім у пристрої генеруються дві пари ключів RSA: **ключ пристрою** (**публічний** ключ), який надсилається до **AzureAD**, і **транспортний** ключ (**приватний** ключ), який зберігається в TPM, якщо це можливо.
 
-Потім у **AzureAD** генерується **об'єкт** (не в Intune), і AzureAD повертає пристрою **сертифікат**, підписаний ним. Ви можете перевірити, що **пристрій приєднано до AzureAD** та інформацію про **сертифікат** (наприклад, чи захищений він TPM).
+Потім у **AzureAD** створюється **об'єкт** (не в Intune), і AzureAD повертає пристрою **сертифікат**, підписаний ним. Ви можете перевірити, що **пристрій приєднано до AzureAD** та інформацію про **сертифікат** (наприклад, чи захищений він TPM).
 ```bash
 dsregcmd /status
 ```
@@ -22,12 +22,12 @@ dsregcmd /status
 az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
 {{#endref}}
 
-### TPM - Модуль довірчої платформи
+### TPM - Довірчий модуль платформи
 
 **TPM** **захищає** від витоку ключів **з витягування** з вимкненого пристрою (якщо захищено PIN-кодом) та від витягування приватних матеріалів з рівня ОС.\
 Але він **не захищає** від **перехоплення** фізичного з'єднання між TPM і ЦП або **використання криптографічних матеріалів** у TPM, поки система працює з процесу з правами **SYSTEM**.
 
-Якщо ви переглянете наступну сторінку, ви побачите, що **викрадення PRT** може бути використано для доступу як **користувач**, що чудово, оскільки **PRT знаходиться на пристроях**, тому його можна вкрасти з них (або, якщо не вкрасти, зловживати для генерації нових ключів підпису):
+Якщо ви переглянете наступну сторінку, ви побачите, що **викрадення PRT** може бути використано для доступу як **користувач**, що є чудово, оскільки **PRT розташовані на пристроях**, тому їх можна вкрасти (або, якщо не вкрадені, зловживати для генерації нових підписних ключів):
 
 {{#ref}}
 az-lateral-movement-cloud-on-prem/pass-the-prt.md
@@ -47,7 +47,7 @@ roadrecon auth -r 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 --prt-cookie <cookie>
 # Custom pyhton script to register a device (check roadtx)
 registerdevice.py
 ```
-Який надасть вам **сертифікат, який ви можете використовувати для запиту PRT у майбутньому**. Таким чином, підтримуючи постійність і **обминаючи MFA**, оскільки оригінальний токен PRT, використаний для реєстрації нового пристрою, **вже мав дозволи на MFA**.
+Який надасть вам **сертифікат, який ви можете використовувати для запиту PRT у майбутньому**. Таким чином, підтримуючи стійкість і **обминаючи MFA**, оскільки оригінальний токен PRT, використаний для реєстрації нового пристрою, **вже мав надані дозволи MFA**.
 
 > [!TIP]
 > Зверніть увагу, що для виконання цієї атаки вам знадобляться дозволи на **реєстрацію нових пристроїв**. Також реєстрація пристрою не означає, що пристрій буде **дозволено зареєструватися в Intune**.
@@ -55,7 +55,7 @@ registerdevice.py
 > [!CAUTION]
 > Цю атаку виправили у вересні 2021 року, оскільки ви більше не можете реєструвати нові пристрої, використовуючи токени SSO. Однак все ще можливо легітимно реєструвати пристрої (маючи ім'я користувача, пароль і MFA, якщо потрібно). Перевірте: [**roadtx**](https://github.com/carlospolop/hacktricks-cloud/blob/master/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-roadtx-authentication.md).
 
-## Перезапис квитка пристрою
+## Перезаписування квитка пристрою
 
 Було можливим **запросити квиток пристрою**, **перезаписати** поточний квиток пристрою і під час процесу **викрасти PRT** (тому немає потреби викрадати його з TPM. Для отримання додаткової інформації [**перевірте цю доповідь**](https://youtu.be/BduCn8cLV1A).
 
@@ -64,7 +64,7 @@ registerdevice.py
 > [!CAUTION]
 > Однак це було виправлено.
 
-## Перезапис ключа WHFB
+## Перезаписати ключ WHFB
 
 [**Перевірте оригінальні слайди тут**](https://dirkjanm.io/assets/raw/Windows%20Hello%20from%20the%20other%20side_nsec_v1.0.pdf)
 
@@ -72,9 +72,13 @@ registerdevice.py
 
 - Можливо **перезаписати** **зареєстрований ключ WHFB** з **пристрою** через SSO
 - Це **обминає захист TPM**, оскільки ключ **перехоплюється під час генерації** нового ключа
-- Це також забезпечує **постійність**
+- Це також забезпечує **стійкість**
 
-<figure><img src="../../images/image
+<figure><img src="../../images/image (34).png" alt=""><figcaption></figcaption></figure>
+
+Користувачі можуть змінювати свою власну властивість searchableDeviceKey через Azure AD Graph, однак атакуючий повинен мати пристрій у тенанті (зареєстрований на льоту або викравши сертифікат + ключ з легітимного пристрою) і дійсний токен доступу для AAD Graph.
+
+Тоді можливо згенерувати новий ключ за допомогою:
 ```bash
 roadtx genhellokey -d <device id> -k tempkey.key
 ```
@@ -82,7 +86,7 @@ roadtx genhellokey -d <device id> -k tempkey.key
 
 <figure><img src="../../images/image (36).png" alt=""><figcaption></figcaption></figure>
 
-Можливо отримати токен доступу від користувача через **фішинг за допомогою коду пристрою** і зловживати попередніми кроками, щоб **викрасти його доступ**. Для отримання додаткової інформації перегляньте:
+Можливо отримати токен доступу від користувача через **фішинг за допомогою коду пристрою** і зловживати попередніми кроками, щоб **викрасти його доступ**. Для отримання додаткової інформації перевірте:
 
 {{#ref}}
 az-lateral-movement-cloud-on-prem/az-phishing-primary-refresh-token-microsoft-entra.md

src/pentesting-cloud/azure-security/az-enumeration-tools.md

@@ -47,13 +47,13 @@ pwsh
 brew update
 brew upgrade powershell
 ```
-## Основні інструменти для перерахунку
+## Основні інструменти перерахунку
 
 ### az cli
 
 [**Azure Command-Line Interface (CLI)**](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli) - це кросплатформений інструмент, написаний на Python для управління та адміністрування (більшості) ресурсів Azure та Entra ID. Він підключається до Azure та виконує адміністративні команди через командний рядок або скрипти.
 
-Слідуйте за цим посиланням для [**інструкцій з установки¡**](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli#install).
+Слідкуйте за цим посиланням для [**інструкцій з установки¡**](https://learn.microsoft.com/en-us/cli/azure/install-azure-cli#install).
 
 Команди в Azure CLI структуровані за шаблоном: `az <service> <action> <parameters>`
 
@@ -95,9 +95,9 @@ $env:HTTP_PROXY="http://127.0.0.1:8080"
 
 Azure PowerShell - це модуль з cmdlet для управління ресурсами Azure безпосередньо з командного рядка PowerShell.
 
-Слідуйте за цим посиланням для [**інструкцій з установки**](https://learn.microsoft.com/en-us/powershell/azure/install-azure-powershell).
+Слідкуйте за цим посиланням для [**інструкцій з установки**](https://learn.microsoft.com/en-us/powershell/azure/install-azure-powershell).
 
-Команди в модулі Azure PowerShell AZ структуровані так: `<Action>-Az<Service> <parameters>`
+Команди в модулі Azure PowerShell AZ структуровані як: `<Action>-Az<Service> <parameters>`
 
 #### Debug | MitM Az PowerShell
 
@@ -105,11 +105,11 @@ Azure PowerShell - це модуль з cmdlet для управління ре
 ```bash
 Get-AzResourceGroup -Debug
 ```
-Щоб виконати **MitM** для інструмента та **перевірити всі запити**, які він надсилає вручну, ви можете встановити змінні середовища `HTTPS_PROXY` та `HTTP_PROXY` відповідно до [**документації**](https://learn.microsoft.com/en-us/powershell/azure/az-powershell-proxy).
+Щоб виконати **MitM** для інструменту та **перевірити всі запити**, які він надсилає вручну, ви можете встановити змінні середовища `HTTPS_PROXY` та `HTTP_PROXY` відповідно до [**документації**](https://learn.microsoft.com/en-us/powershell/azure/az-powershell-proxy).
 
 ### Microsoft Graph PowerShell
 
-Microsoft Graph PowerShell — це кросплатформений SDK, який забезпечує доступ до всіх API Microsoft Graph, включаючи сервіси, такі як SharePoint, Exchange та Outlook, за допомогою єдиного кінцевого пункту. Він підтримує PowerShell 7+, сучасну аутентифікацію через MSAL, зовнішні ідентичності та розширені запити. Зосереджуючись на доступі з найменшими привілеями, він забезпечує безпечні операції та регулярно отримує оновлення, щоб відповідати останнім функціям API Microsoft Graph.
+Microsoft Graph PowerShell - це кросплатформений SDK, який забезпечує доступ до всіх API Microsoft Graph, включаючи сервіси, такі як SharePoint, Exchange та Outlook, за допомогою єдиного кінцевого пункту. Він підтримує PowerShell 7+, сучасну аутентифікацію через MSAL, зовнішні ідентичності та розширені запити. Зосереджуючись на доступі з найменшими привілеями, він забезпечує безпечні операції та регулярно отримує оновлення, щоб відповідати останнім функціям API Microsoft Graph.
 
 Слідуйте за цим посиланням для [**інструкцій з установки**](https://learn.microsoft.com/en-us/powershell/microsoftgraph/installation).
 
@@ -117,13 +117,13 @@ Microsoft Graph PowerShell — це кросплатформений SDK, яки
 
 #### Налагодження Microsoft Graph PowerShell
 
-Використовуючи параметр **`-Debug`**, можна побачити всі запити, які надсилає інструмент:
+Використовуючи параметр **`-Debug`**, можна побачити всі запити, які інструмент надсилає:
 ```bash
 Get-MgUser -Debug
 ```
 ### ~~**AzureAD Powershell**~~
 
-Модуль Azure Active Directory (AD), який зараз **застарілий**, є частиною Azure PowerShell для управління ресурсами Azure AD. Він надає cmdlet для завдань, таких як управління користувачами, групами та реєстраціями додатків в Entra ID.
+Модуль Azure Active Directory (AD), тепер **застарілий**, є частиною Azure PowerShell для управління ресурсами Azure AD. Він надає cmdlet для завдань, таких як управління користувачами, групами та реєстрацією додатків в Entra ID.
 
 > [!TIP]
 > Це замінено на Microsoft Graph PowerShell

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/README.md

@@ -1,64 +1,64 @@
-# Az - Lateral Movement (Cloud - On-Prem)
+# Az - Бічний Рух (Хмара - На місці)
 
-## Az - Lateral Movement (Cloud - On-Prem)
+## Az - Бічний Рух (Хмара - На місці)
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-### On-Prem machines connected to cloud
+### На місцевих машинах, підключених до хмари
 
-Є різні способи, як машина може бути підключена до хмари:
+Існують різні способи підключення машини до хмари:
 
-#### Azure AD joined
+#### Приєднано до Azure AD
 
 <figure><img src="../../../images/image (259).png" alt=""><figcaption></figcaption></figure>
 
-#### Workplace joined
+#### Приєднано до робочого місця
 
 <figure><img src="../../../images/image (222).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv7UHXsAArdhn?format=jpg&#x26;name=large">https://pbs.twimg.com/media/EQZv7UHXsAArdhn?format=jpg&#x26;name=large</a></p></figcaption></figure>
 
-#### Hybrid joined
+#### Гібридне приєднання
 
 <figure><img src="../../../images/image (178).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv77jXkAAC4LK?format=jpg&#x26;name=large">https://pbs.twimg.com/media/EQZv77jXkAAC4LK?format=jpg&#x26;name=large</a></p></figcaption></figure>
 
-#### Workplace joined on AADJ or Hybrid
+#### Приєднано до робочого місця на AADJ або Гібридному
 
 <figure><img src="../../../images/image (252).png" alt=""><figcaption><p><a href="https://pbs.twimg.com/media/EQZv8qBX0AAMWuR?format=jpg&#x26;name=large">https://pbs.twimg.com/media/EQZv8qBX0AAMWuR?format=jpg&#x26;name=large</a></p></figcaption></figure>
 
-### Tokens and limitations <a href="#tokens-and-limitations" id="tokens-and-limitations"></a>
+### Токени та обмеження <a href="#tokens-and-limitations" id="tokens-and-limitations"></a>
 
-В Azure AD є різні типи токенів з конкретними обмеженнями:
+В Azure AD існують різні типи токенів з конкретними обмеженнями:
 
-- **Access tokens**: Використовуються для доступу до API та ресурсів, таких як Microsoft Graph. Вони прив'язані до конкретного клієнта та ресурсу.
-- **Refresh tokens**: Видаються додаткам для отримання нових токенів доступу. Вони можуть використовуватися лише додатком, якому вони були видані, або групою додатків.
-- **Primary Refresh Tokens (PRT)**: Використовуються для єдиного входу на пристроях, приєднаних до Azure AD, зареєстрованих або гібридних. Вони можуть використовуватися в процесах входу через браузер та для входу в мобільні та настільні додатки на пристрої.
-- **Windows Hello for Business keys (WHFB)**: Використовуються для безпарольної аутентифікації. Використовуються для отримання Primary Refresh Tokens.
+- **Токени доступу**: Використовуються для доступу до API та ресурсів, таких як Microsoft Graph. Вони прив'язані до конкретного клієнта та ресурсу.
+- **Токени оновлення**: Видаються додаткам для отримання нових токенів доступу. Вони можуть використовуватися лише додатком, якому вони були видані, або групою додатків.
+- **Основні токени оновлення (PRT)**: Використовуються для єдиного входу на пристроях, приєднаних до Azure AD, зареєстрованих або гібридно приєднаних. Вони можуть використовуватися в потоках входу через браузер та для входу в мобільні та настільні додатки на пристрої.
+- **Ключі Windows Hello for Business (WHFB)**: Використовуються для безпарольної аутентифікації. Вони використовуються для отримання основних токенів оновлення.
 
-Найцікавіший тип токена - це Primary Refresh Token (PRT).
+Найцікавіший тип токена - це основний токен оновлення (PRT).
 
 {{#ref}}
 az-primary-refresh-token-prt.md
 {{#endref}}
 
-### Pivoting Techniques
+### Техніки Півотування
 
 Від **зламаної машини до хмари**:
 
-- [**Pass the Cookie**](az-pass-the-cookie.md): Вкрасти Azure cookies з браузера та використовувати їх для входу
+- [**Pass the Cookie**](az-pass-the-cookie.md): Вкрасти куки Azure з браузера та використовувати їх для входу
 - [**Dump processes access tokens**](az-processes-memory-access-token.md): Вивантажити пам'ять локальних процесів, синхронізованих з хмарою (як excel, Teams...) та знайти токени доступу у відкритому тексті.
 - [**Phishing Primary Refresh Token**](az-phishing-primary-refresh-token-microsoft-entra.md)**:** Фішинг PRT для його зловживання
 - [**Pass the PRT**](pass-the-prt.md): Вкрасти PRT пристрою для доступу до Azure, видаючи себе за нього.
-- [**Pass the Certificate**](az-pass-the-certificate.md)**:** Згенерувати сертифікат на основі PRT для входу з одного пристрою на інший
+- [**Pass the Certificate**](az-pass-the-certificate.md)**:** Згенерувати сертифікат на основі PRT для входу з однієї машини на іншу
 
-Від компрометації **AD** до компрометації **Cloud** та від компрометації **Cloud** до компрометації **AD**:
+Від компрометації **AD** до компрометації **Хмари** та від компрометації **Хмари** до компрометації **AD**:
 
 - [**Azure AD Connect**](azure-ad-connect-hybrid-identity/)
-- **Ще один спосіб переходу з хмари на On-Prem - це** [**зловживання Intune**](../az-services/intune.md)
+- **Інший спосіб півотування з хмари на місце** [**зловживання Intune**](../az-services/intune.md)
 
 #### [Roadtx](https://github.com/dirkjanm/ROADtools)
 
 Цей інструмент дозволяє виконувати кілька дій, таких як реєстрація машини в Azure AD для отримання PRT, та використовувати PRT (легітимні або вкрадені) для доступу до ресурсів різними способами. Це не прямі атаки, але це полегшує використання PRT для доступу до ресурсів різними способами. Знайдіть більше інформації на [https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/](https://dirkjanm.io/introducing-roadtools-token-exchange-roadtx/)
 
-## References
+## Посилання
 
 - [https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/](https://dirkjanm.io/phishing-for-microsoft-entra-primary-refresh-tokens/)
 

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-arc-vulnerable-gpo-deploy-script.md

@@ -1,19 +1,19 @@
-# Az - Arc вразливий GPO Deploy Script
+# Az - Arc вразливий GPO Деплой Скрипт
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 ### Виявлення проблем
 
-Azure Arc дозволяє інтеграцію нових внутрішніх серверів (приєднаних до домену) в Azure Arc за допомогою методу об'єкта групової політики. Для цього Microsoft надає набір інструментів для розгортання, необхідний для ініціювання процедури приєднання. У файлі ArcEnableServerGroupPolicy.zip можна знайти наступні скрипти: DeployGPO.ps1, EnableAzureArc.ps1 та AzureArcDeployment.psm1.
+Azure Arc дозволяє інтегрувати нові внутрішні сервери (приєднані до домену) в Azure Arc за допомогою методу об'єкта групової політики. Для цього Microsoft надає набір інструментів для розгортання, необхідний для ініціювання процедури приєднання. У файлі ArcEnableServerGroupPolicy.zip можна знайти такі скрипти: DeployGPO.ps1, EnableAzureArc.ps1 та AzureArcDeployment.psm1.
 
 При виконанні скрипт DeployGPO.ps1 виконує такі дії:
 
 1. Створює GPO для приєднання серверів Azure Arc у локальному домені.
 2. Копіює скрипт приєднання EnableAzureArc.ps1 на вказану мережеву папку, створену для процесу приєднання, яка також містить пакет установника Windows.
 
-При запуску цього скрипта адміністраторам систем потрібно надати два основні параметри: **ServicePrincipalId** та **ServicePrincipalClientSecret**. Крім того, потрібні інші параметри, такі як домен, FQDN сервера, що хостить спільну папку, та ім'я спільної папки. Додаткові деталі, такі як ідентифікатор орендаря, група ресурсів та інша необхідна інформація також повинні бути надані скрипту.
+При запуску цього скрипта адміністраторам систем потрібно надати два основні параметри: **ServicePrincipalId** та **ServicePrincipalClientSecret**. Крім того, потрібні інші параметри, такі як домен, FQDN сервера, що хостить загальний доступ, та ім'я загального доступу. Додаткові деталі, такі як ідентифікатор орендаря, група ресурсів та інша необхідна інформація також повинні бути надані скрипту.
 
-Зашифрований секрет генерується в каталозі AzureArcDeploy на вказаній спільній папці за допомогою шифрування DPAPI-NG. Зашифрований секрет зберігається у файлі з назвою encryptedServicePrincipalSecret. Доказ цього можна знайти у скрипті DeployGPO.ps1, де шифрування виконується шляхом виклику ProtectBase64 з $descriptor та $ServicePrincipalSecret як вхідними даними. Дескриптор складається з SID груп комп'ютерів домену та контролерів домену, що забезпечує, що ServicePrincipalSecret може бути розшифрований лише контролерами домену та групами безпеки комп'ютерів домену, як зазначено в коментарях до скрипту.
+Зашифрований секрет генерується в каталозі AzureArcDeploy на вказаному загальному доступі за допомогою шифрування DPAPI-NG. Зашифрований секрет зберігається у файлі з назвою encryptedServicePrincipalSecret. Доказ цього можна знайти у скрипті DeployGPO.ps1, де шифрування виконується шляхом виклику ProtectBase64 з $descriptor та $ServicePrincipalSecret як вхідними даними. Дескриптор складається з SID груп комп'ютерів домену та контролерів домену, що забезпечує, що ServicePrincipalSecret може бути розшифрований лише групами безпеки контролерів домену та комп'ютерів домену, як зазначено в коментарях до скрипту.
 ```powershell
 # Encrypting the ServicePrincipalSecret to be decrypted only by the Domain Controllers and the Domain Computers security groups
 $DomainComputersSID = "SID=" + $DomainComputersSID
@@ -54,7 +54,7 @@ $ebs
 ```
 Альтернативно, ми можемо використовувати [SecretManagement.DpapiNG](https://github.com/jborean93/SecretManagement.DpapiNG).
 
-На цьому етапі ми можемо зібрати залишкову інформацію, необхідну для підключення до Azure з файлу ArcInfo.json, який зберігається на тому ж мережевому загальному доступі, що й файл encryptedServicePrincipalSecret. Цей файл містить такі деталі, як: TenantId, servicePrincipalClientId, ResourceGroup та інше. З цією інформацією ми можемо використовувати Azure CLI для автентифікації як скомпрометований сервісний принципал.
+На цьому етапі ми можемо зібрати залишкову інформацію, необхідну для підключення до Azure з файлу ArcInfo.json, який зберігається на тому ж мережевому загальному доступі, що й файл encryptedServicePrincipalSecret. Цей файл містить деталі, такі як: TenantId, servicePrincipalClientId, ResourceGroup та інше. З цією інформацією ми можемо використовувати Azure CLI для автентифікації як скомпрометований сервісний принципал.
 
 ## References
 

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-local-cloud-credentials.md

@@ -1,16 +1,16 @@
-# Az - Local Cloud Credentials
+# Az - Локальні Облікові Дані Хмари
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## Local Token Storage and Security Considerations
+## Локальне Зберігання Токенів та Розгляд Безпеки
 
-### Azure CLI (Command-Line Interface)
+### Azure CLI (Інтерфейс Командного Рядка)
 
 Токени та чутливі дані зберігаються локально Azure CLI, що викликає занепокоєння щодо безпеки:
 
-1. **Access Tokens**: Зберігаються у відкритому вигляді в `accessTokens.json`, розташованому за адресою `C:\Users\<username>\.Azure`.
-2. **Subscription Information**: `azureProfile.json`, у тій же директорії, містить деталі підписки.
-3. **Log Files**: Папка `ErrorRecords` у `.azure` може містити журнали з відкритими обліковими даними, такі як:
+1. **Токени Доступу**: Зберігаються у відкритому вигляді в `accessTokens.json`, розташованому за адресою `C:\Users\<username>\.Azure`.
+2. **Інформація про Підписку**: `azureProfile.json`, у тій же директорії, містить деталі підписки.
+3. **Лог-файли**: Папка `ErrorRecords` у `.azure` може містити журнали з відкритими обліковими даними, такими як:
 - Виконані команди з вбудованими обліковими даними.
 - URL-адреси, доступ до яких здійснювався за допомогою токенів, що потенційно розкриває чутливу інформацію.
 
@@ -18,22 +18,22 @@
 
 Azure PowerShell також зберігає токени та чутливі дані, до яких можна отримати доступ локально:
 
-1. **Access Tokens**: `TokenCache.dat`, розташований за адресою `C:\Users\<username>\.Azure`, зберігає токени доступу у відкритому вигляді.
-2. **Service Principal Secrets**: Ці дані зберігаються у незашифрованому вигляді в `AzureRmContext.json`.
-3. **Token Saving Feature**: Користувачі мають можливість зберігати токени за допомогою команди `Save-AzContext`, яку слід використовувати обережно, щоб запобігти несанкціонованому доступу.
+1. **Токени Доступу**: `TokenCache.dat`, розташований за адресою `C:\Users\<username>\.Azure`, зберігає токени доступу у відкритому вигляді.
+2. **Секрети Сервісного Принципала**: Ці дані зберігаються у незашифрованому вигляді в `AzureRmContext.json`.
+3. **Функція Збереження Токенів**: Користувачі мають можливість зберігати токени за допомогою команди `Save-AzContext`, яку слід використовувати обережно, щоб запобігти несанкціонованому доступу.
 
-## Automatic Tools to find them
+## Автоматичні Інструменти для їх Пошуку
 
 - [**Winpeas**](https://github.com/carlospolop/PEASS-ng/tree/master/winPEAS/winPEASexe)
 - [**Get-AzurePasswords.ps1**](https://github.com/NetSPI/MicroBurst/blob/master/AzureRM/Get-AzurePasswords.ps1)
 
-## Security Recommendations
+## Рекомендації з Безпеки
 
-Враховуючи зберігання чутливих даних у відкритому вигляді, важливо захистити ці файли та директорії, дотримуючись таких рекомендацій:
+Враховуючи зберігання чутливих даних у відкритому вигляді, важливо забезпечити безпеку цих файлів та директорій шляхом:
 
-- Обмежити права доступу до цих файлів.
-- Регулярно моніторити та перевіряти ці директорії на наявність несанкціонованого доступу або несподіваних змін.
-- Використовувати шифрування для чутливих файлів, де це можливо.
-- Освітлювати користувачів про ризики та найкращі практики обробки такої чутливої інформації.
+- Обмеження прав доступу до цих файлів.
+- Регулярного моніторингу та аудиту цих директорій на предмет несанкціонованого доступу або несподіваних змін.
+- Використання шифрування для чутливих файлів, де це можливо.
+- Освіти користувачів щодо ризиків та найкращих практик обробки таких чутливих даних.
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-certificate.md

@@ -9,13 +9,13 @@
 У спрощених термінах:
 
 - Машина (клієнт), що ініціює з'єднання, **потребує сертифікат від Azure AD для користувача**.
-- Клієнт створює заголовок JSON Web Token (JWT), що містить PRT та інші деталі, підписує його, використовуючи похідний ключ (з використанням сеансового ключа та контексту безпеки), і **надсилає його до Azure AD**.
-- Azure AD перевіряє підпис JWT, використовуючи сеансовий ключ клієнта та контекст безпеки, перевіряє дійсність PRT і **відповідає** з **сертифікатом**.
+- Клієнт створює заголовок JSON Web Token (JWT), що містить PRT та інші деталі, підписує його, використовуючи похідний ключ (з використанням ключа сесії та контексту безпеки), і **надсилає його до Azure AD**.
+- Azure AD перевіряє підпис JWT, використовуючи ключ сесії клієнта та контекст безпеки, перевіряє дійсність PRT і **відповідає** з **сертифікатом**.
 
 У цьому сценарії, після збору всієї необхідної інформації для атаки [**Pass the PRT**](pass-the-prt.md):
 
 - Ім'я користувача
-- Ідентифікатор орендаря
+- ID орендаря
 - PRT
 - Контекст безпеки
 - Похідний ключ
@@ -28,8 +28,8 @@ RequestCert.py [-h] --tenantId TENANTID --prt PRT --userName USERNAME --hexCtx H
 ```bash
 Main.py [-h] --usercert USERCERT --certpass CERTPASS --remoteip REMOTEIP
 ```
-## References
+## Посилання
 
-- Для отримання додаткової інформації про те, як працює Pass the Certificate, перегляньте оригінальну публікацію [https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597](https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597)
+- Для отримання додаткової інформації про те, як працює Pass the Certificate, перегляньте оригінальний пост [https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597](https://medium.com/@mor2464/azure-ad-pass-the-certificate-d0c5de624597)
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-pass-the-cookie.md

@@ -4,7 +4,7 @@
 
 ## Чому куки?
 
-Браузерні **куки** є чудовим механізмом для **обходу аутентифікації та MFA**. Оскільки користувач вже аутентифікований в додатку, **сеанс куки** може бути використаний для **доступу до даних** як цей користувач, без необхідності повторної аутентифікації.
+Браузерні **куки** є чудовим механізмом для **обходу аутентифікації та MFA**. Оскільки користувач вже аутентифікований в додатку, сесійний **кук** може бути використаний для **доступу до даних** як цей користувач, без необхідності повторної аутентифікації.
 
 Ви можете побачити, де знаходяться **браузерні куки** в:
 
@@ -14,13 +14,13 @@ https://book.hacktricks.xyz/generic-methodologies-and-resources/basic-forensic-m
 
 ## Атака
 
-Складна частина полягає в тому, що ці **куки зашифровані** для **користувача** через Microsoft Data Protection API (**DPAPI**). Це зашифровано за допомогою криптографічних [ключів, прив'язаних до користувача](https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords), до яких належать куки. Ви можете знайти більше інформації про це в:
+Складна частина полягає в тому, що ці **куки зашифровані** для **користувача** через Microsoft Data Protection API (**DPAPI**). Це зашифровано за допомогою криптографічних [ключів, пов'язаних з користувачем](https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords), до яких належать куки. Ви можете знайти більше інформації про це в:
 
 {{#ref}}
 https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords
 {{#endref}}
 
-З Mimikatz в руках, я можу **екстрагувати куки користувача**, навіть якщо вони зашифровані, за допомогою цієї команди:
+З Mimikatz в руках, я можу **екстрактувати куки користувача**, навіть якщо вони зашифровані, за допомогою цієї команди:
 ```bash
 mimikatz.exe privilege::debug log "dpapi::chrome /in:%localappdata%\google\chrome\USERDA~1\default\cookies /unprotect" exit
 ```

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md

@@ -2,6 +2,6 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-**Перегляньте пост на** [**https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) хоча інший пост, що пояснює те ж саме, можна знайти за посиланням [**https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30**](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30)
+**Перегляньте пост за адресою** [**https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/) хоча інший пост, що пояснює те ж саме, можна знайти за адресою [**https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30**](https://posts.specterops.io/requesting-azure-ad-request-tokens-on-azure-ad-joined-machines-for-browser-sso-2b0409caad30)
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/az-processes-memory-access-token.md

@@ -4,12 +4,12 @@
 
 ## **Основна інформація**
 
-Як пояснено в [**цьому відео**](https://www.youtube.com/watch?v=OHKZkXC4Duw), деяке програмне забезпечення Microsoft, синхронізоване з хмарою (Excel, Teams...), може **зберігати токени доступу у відкритому тексті в пам'яті**. Тому просто **дампінг** **пам'яті** процесу та **grep для JWT токенів** може надати вам доступ до кількох ресурсів жертви в хмарі, обминаючи MFA.
+Як пояснено в [**цьому відео**](https://www.youtube.com/watch?v=OHKZkXC4Duw), деяке програмне забезпечення Microsoft, синхронізоване з хмарою (Excel, Teams...), може **зберігати токени доступу у відкритому вигляді в пам'яті**. Тому просто **дампінг** **пам'яті** процесу та **grep для JWT токенів** може надати вам доступ до кількох ресурсів жертви в хмарі, обминаючи MFA.
 
 Кроки:
 
-1. Дамп процесів Excel, синхронізованих з користувачем EntraID, за допомогою вашого улюбленого інструменту.
-2. Виконайте: `string excel.dmp | grep 'eyJ0'` і знайдіть кілька токенів у виході
+1. Дампуйте процеси Excel, синхронізовані з користувачем EntraID, за допомогою вашого улюбленого інструменту.
+2. Запустіть: `string excel.dmp | grep 'eyJ0'` і знайдіть кілька токенів у виході
 3. Знайдіть токени, які вас найбільше цікавлять, і запустіть інструменти над ними:
 ```bash
 # Check the identity of the token
@@ -30,6 +30,6 @@ curl -s -H "Authorization: Bearer <token>" 'https://graph.microsoft.com/v1.0/sit
 ┌──(magichk㉿black-pearl)-[~]
 └─$ curl -o <filename_output> -L -H "Authorization: Bearer <token>" '<@microsoft.graph.downloadUrl>'
 ```
-**Зверніть увагу, що такі токени доступу також можуть бути знайдені всередині інших процесів.**
+**Зверніть увагу, що такі типи токенів доступу також можна знайти всередині інших процесів.**
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-cloud-kerberos-trust.md

@@ -8,21 +8,21 @@
 
 ### Довіра
 
-Коли встановлюється довіра з Azure AD, **створюється контролер домену тільки для читання (RODC) в AD.** **Обліковий запис комп'ютера RODC**, названий **`AzureADKerberos$`**. Також є вторинний обліковий запис `krbtgt`, названий **`krbtgt_AzureAD`**. Цей обліковий запис містить **ключі Kerberos**, які використовуються для квитків, що створює Azure AD.
+Коли встановлюється довіра з Azure AD, **створюється контролер домену тільки для читання (RODC) в AD.** **Обліковий запис комп'ютера RODC** називається **`AzureADKerberos$`**. Також є вторинний обліковий запис `krbtgt`, названий **`krbtgt_AzureAD`**. Цей обліковий запис містить **ключі Kerberos**, які використовуються для квитків, що створює Azure AD.
 
 Отже, якщо цей обліковий запис буде скомпрометовано, може бути можливим видавати себе за будь-якого користувача... хоча це не зовсім вірно, оскільки цьому обліковому запису заборонено створювати квитки для будь-якої загальної привілейованої групи AD, такої як Domain Admins, Enterprise Admins, Administrators...
 
 > [!CAUTION]
-> Однак у реальному сценарії будуть привілейовані користувачі, які не входять до цих груп. Тому **новий обліковий запис krbtgt, якщо буде скомпрометовано, може бути використаний для видавання себе за них.**
+> Однак у реальному сценарії будуть привілейовані користувачі, які не входять до цих груп. Тому **новий обліковий запис krbtgt, якщо буде скомпрометований, може бути використаний для видавання себе за них.**
 
 ### Kerberos TGT
 
-Більше того, коли користувач аутентифікується в Windows, використовуючи гібридну ідентичність, **Azure AD видасть частковий квиток Kerberos разом з PRT.** TGT є частковим, оскільки **AzureAD має обмежену інформацію** про користувача в локальному AD (таку як ідентифікатор безпеки (SID) та ім'я).\
+Більше того, коли користувач аутентифікується в Windows, використовуючи гібридну ідентичність, **Azure AD** видасть **частковий квиток Kerberos разом з PRT.** TGT є частковим, оскільки **AzureAD має обмежену інформацію** про користувача в on-prem AD (таку як ідентифікатор безпеки (SID) та ім'я).\
 Windows може потім **обміняти цей частковий TGT на повний TGT**, запитуючи квиток служби для служби `krbtgt`.
 
 ### NTLM
 
-Оскільки можуть бути служби, які не підтримують аутентифікацію Kerberos, а лише NTLM, можливо запитати **частковий TGT, підписаний за допомогою вторинного ключа `krbtgt`**, включаючи поле **`KERB-KEY-LIST-REQ`** у частині **PADATA** запиту, а потім отримати повний TGT, підписаний первинним ключем `krbtgt`, **включаючи NT хеш у відповіді**.
+Оскільки можуть бути служби, які не підтримують аутентифікацію Kerberos, але підтримують NTLM, можливо запитати **частковий TGT, підписаний за допомогою вторинного ключа `krbtgt`**, включаючи поле **`KERB-KEY-LIST-REQ`** у частині **PADATA** запиту, а потім отримати повний TGT, підписаний первинним ключем `krbtgt`, **включаючи NT хеш у відповіді**.
 
 ## Зловживання Cloud Kerberos Trust для отримання прав Domain Admin <a href="#abusing-cloud-kerberos-trust-to-obtain-domain-admin" id="abusing-cloud-kerberos-trust-to-obtain-domain-admin"></a>
 
@@ -37,8 +37,8 @@ Windows може потім **обміняти цей частковий TGT н
 Успіх атаки та отримання привілеїв Domain Admin залежать від виконання певних передумов:
 
 - Можливість змінювати облікові записи через Synchronization API є критично важливою. Це можна досягти, маючи роль Глобального адміністратора або володіючи обліковим записом синхронізації AD Connect. Альтернативно, роль адміністратора гібридної ідентичності також підійде, оскільки вона надає можливість керувати AD Connect і створювати нові облікові записи синхронізації.
-- Наявність **гібридного облікового запису** є необхідною. Цей обліковий запис повинен бути придатним для зміни з деталями облікового запису жертви і також повинен бути доступним для аутентифікації.
-- Ідентифікація **цільового облікового запису жертви** в Active Directory є необхідністю. Хоча атаку можна виконати на будь-якому обліковому записі, який вже синхронізовано, тенант Azure AD не повинен мати реплікованих локальних ідентифікаторів безпеки, що вимагає зміни не синхронізованого облікового запису для отримання квитка.
+- Наявність **гібридного облікового запису** є необхідною. Цей обліковий запис повинен бути готовим до зміни з деталями облікового запису жертви та також повинен бути доступним для аутентифікації.
+- Ідентифікація **цільового облікового запису жертви** в Active Directory є необхідністю. Хоча атаку можна виконати на будь-якому обліковому записі, який вже синхронізовано, орендар Azure AD не повинен мати реплікованих ідентифікаторів безпеки on-prem, що вимагає зміни не синхронізованого облікового запису для отримання квитка.
 - Крім того, цей обліковий запис повинен мати еквівалентні привілеї адміністратора домену, але не повинен бути членом типових груп адміністраторів AD, щоб уникнути генерації недійсних TGT AzureAD RODC.
 - Найбільш підходящою ціллю є **обліковий запис Active Directory, що використовується службою синхронізації AD Connect**. Цей обліковий запис не синхронізується з Azure AD, залишаючи його SID як життєздатну ціль, і він за своєю суттю має еквівалентні привілеї адміністратора домену через свою роль у синхронізації хешів паролів (за умови, що синхронізація хешів паролів активна). Для доменів з експрес-встановленням цей обліковий запис має префікс **MSOL\_**. Для інших випадків обліковий запис можна визначити, перерахувавши всі облікові записи, наділені привілеями реплікації каталогу на об'єкті домену.
 

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-default-applications.md

@@ -4,6 +4,6 @@
 
 **Перевірте техніку на:** [**https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/**](https://dirkjanm.io/azure-ad-privilege-escalation-application-admin/)**,** [**https://www.youtube.com/watch?v=JEIR5oGCwdg**](https://www.youtube.com/watch?v=JEIR5oGCwdg) та [**https://www.youtube.com/watch?v=xei8lAPitX8**](https://www.youtube.com/watch?v=xei8lAPitX8)
 
-У блозі обговорюється вразливість ескалації привілеїв в Azure AD, що дозволяє адміністраторам додатків або скомпрометованим обліковим записам синхронізації On-Premise підвищувати привілеї, призначаючи облікові дані додаткам. Вразливість, що виникає через "дизайнерську" поведінку Azure AD у обробці додатків та службових принципів, особливо впливає на стандартні додатки Office 365. Хоча проблема була повідомлена, Microsoft не вважає її вразливістю через документування поведінки призначення адміністративних прав. Пост надає детальні технічні відомості та радить регулярно переглядати облікові дані службових принципів в середовищах Azure AD. Для отримання більш детальної інформації ви можете відвідати оригінальний блог.
+У блозі обговорюється вразливість підвищення привілеїв в Azure AD, яка дозволяє адміністраторам додатків або скомпрометованим обліковим записам синхронізації On-Premise підвищувати привілеї, призначаючи облікові дані додаткам. Вразливість, що виникає через "дизайнерську" поведінку Azure AD у обробці додатків та службових принципів, особливо впливає на стандартні додатки Office 365. Хоча проблема була повідомлена, Microsoft не вважає її вразливістю через документування поведінки призначення адміністративних прав. Пост надає детальні технічні відомості та радить регулярно переглядати облікові дані службових принципів в середовищах Azure AD. Для отримання більш детальної інформації ви можете відвідати оригінальний блог.
 
 {{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/az-synchronising-new-users.md

@@ -2,7 +2,7 @@
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-## Синхронізація користувачів AzureAD до on-prem для ескалації з on-prem до AzureAD
+## Синхронізація користувачів AzureAD з on-prem для ескалації з on-prem до AzureAD
 
 Щоб синхронізувати нового користувача з **AzureAD до on-prem AD**, необхідні такі вимоги:
 
@@ -19,7 +19,7 @@ Get-MsolUser -SerachString admintest | select displayname, lastdirsynctime, prox
 > [!CAUTION]
 > Зверніть увагу, що для виконання цієї атаки вам **не потрібен Domain Admin**, вам просто потрібні права для **створення нових користувачів**.
 >
-> Також, це **не обійде MFA**.
+> Крім того, це **не обійде MFA**.
 >
 > Більше того, було повідомлено, що **синхронізація облікових записів більше не можлива для облікових записів адміністраторів**.
 

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/federation.md

@@ -1,16 +1,16 @@
-# Az - Federation
+# Az - Федерація
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-## Basic Information
+## Основна інформація
 
-[З документації:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)**Федерація** - це колекція **доменів**, які встановили **довіру**. Рівень довіри може варіюватися, але зазвичай включає **аутентифікацію** і майже завжди включає **авторизацію**. Типова федерація може включати **кілька організацій**, які встановили **довіру** для **спільного доступу** до набору ресурсів.
+[З документів:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)**Федерація** - це колекція **доменів**, які встановили **довіру**. Рівень довіри може варіюватися, але зазвичай включає **аутентифікацію** і майже завжди включає **авторизацію**. Типова федерація може включати **кілька організацій**, які встановили **довіру** для **спільного доступу** до набору ресурсів.
 
-Ви можете **федеративно з'єднати ваше локальне** середовище **з Azure AD** і використовувати цю федерацію для аутентифікації та авторизації. Цей метод входу забезпечує, що вся **аутентифікація користувачів відбувається на місці**. Цей метод дозволяє адміністраторам впроваджувати більш суворі рівні контролю доступу. Федерація з **AD FS** та PingFederate доступна.
+Ви можете **федеративно з'єднати ваше локальне** середовище **з Azure AD** і використовувати цю федерацію для аутентифікації та авторизації. Цей метод входу забезпечує, що вся **аутентифікація користувачів відбувається локально**. Цей метод дозволяє адміністраторам впроваджувати більш суворі рівні контролю доступу. Федерація з **AD FS** та PingFederate доступна.
 
 <figure><img src="../../../../images/image (154).png" alt=""><figcaption></figcaption></figure>
 
-В основному, у Федерації вся **аутентифікація** відбувається в **локальному** середовищі, і користувач отримує SSO у всіх довірених середовищах. Тому користувачі можуть **доступати** **хмарні** додатки, використовуючи свої **локальні облікові дані**.
+В основному, у Федерації вся **аутентифікація** відбувається в **локальному** середовищі, і користувачі отримують SSO у всіх довірених середовищах. Тому користувачі можуть **доступати** **хмарні** додатки, використовуючи свої **локальні облікові дані**.
 
 **Мова розмітки безпеки (SAML)** використовується для **обміну** всією інформацією про аутентифікацію та авторизацію між постачальниками.
 
@@ -25,9 +25,9 @@
 <figure><img src="../../../../images/image (121).png" alt=""><figcaption></figcaption></figure>
 
 1. Спочатку користувач отримує доступ до програми (Постачальник послуг або SP, наприклад, консоль AWS або веб-клієнт vSphere). Цей крок може бути пропущений, що призводить до безпосереднього переходу клієнта до IdP (Постачальник ідентичності) залежно від конкретної реалізації.
-2. Потім SP визначає відповідний IdP (наприклад, AD FS, Okta) для аутентифікації користувача. Потім він формує SAML (Мова розмітки безпеки) AuthnRequest і перенаправляє клієнта до вибраного IdP.
+2. Потім SP визначає відповідний IdP (наприклад, AD FS, Okta) для аутентифікації користувача. Потім він формує запит SAML (Мова розмітки безпеки) AuthnRequest і перенаправляє клієнта до вибраного IdP.
 3. IdP бере на себе аутентифікацію користувача. Після аутентифікації IdP формує SAMLResponse і пересилає його до SP через користувача.
-4. Нарешті, SP оцінює SAMLResponse. Якщо валідація пройшла успішно, що означає довірчі відносини з IdP, користувачу надається доступ. Це завершує процес входу, дозволяючи користувачу використовувати сервіс.
+4. Нарешті, SP оцінює SAMLResponse. Якщо валідація пройшла успішно, що означає довірчі відносини з IdP, користувачу надається доступ. Це позначає завершення процесу входу, що дозволяє користувачу використовувати сервіс.
 
 **Якщо ви хочете дізнатися більше про аутентифікацію SAML та поширені атаки, перейдіть за посиланням:**
 
@@ -35,13 +35,13 @@
 https://book.hacktricks.xyz/pentesting-web/saml-attacks
 {{#endref}}
 
-## Pivoting
+## Півтування
 
 - AD FS є моделлю ідентичності на основі заяв.
-- "..заяви - це просто твердження (наприклад, ім'я, ідентичність, група), зроблені про користувачів, які використовуються в основному для авторизації доступу до заявлених додатків, розташованих будь-де в Інтернеті."
+- "..заяви - це просто твердження (наприклад, ім'я, особа, група), зроблені про користувачів, які використовуються в основному для авторизації доступу до заявлених додатків, розташованих де завгодно в Інтернеті."
 - Заяви для користувача записуються всередині SAML токенів і потім підписуються для забезпечення конфіденційності IdP.
 - Користувач ідентифікується за допомогою ImmutableID. Він є глобально унікальним і зберігається в Azure AD.
-- ImmutableID зберігається на місці як ms-DS-ConsistencyGuid для користувача і/або може бути отриманий з GUID користувача.
+- ImmutableID зберігається локально як ms-DS-ConsistencyGuid для користувача і/або може бути отриманий з GUID користувача.
 - Більше інформації в [https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims)
 
 **Атака Golden SAML:**
@@ -54,22 +54,22 @@ https://book.hacktricks.xyz/pentesting-web/saml-attacks
 
 ### Golden SAML
 
-Процес, в якому **Постачальник ідентичності (IdP)** генерує **SAMLResponse** для авторизації входу користувача, є надзвичайно важливим. Залежно від конкретної реалізації IdP, **відповідь** може бути **підписана** або **зашифрована** за допомогою **приватного ключа IdP**. Ця процедура дозволяє **Постачальнику послуг (SP)** підтвердити автентичність SAMLResponse, забезпечуючи, що він дійсно був виданий довіреним IdP.
+Процес, у якому **Постачальник ідентичності (IdP)** генерує **SAMLResponse** для авторизації входу користувача, є надзвичайно важливим. Залежно від конкретної реалізації IdP, **відповідь** може бути **підписана** або **зашифрована** за допомогою **приватного ключа IdP**. Ця процедура дозволяє **Постачальнику послуг (SP)** підтвердити автентичність SAMLResponse, забезпечуючи, що він дійсно був виданий довіреним IdP.
 
-Можна провести паралель з [атакою золотого квитка](https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/golden-ticket), де ключ, що аутентифікує ідентичність і дозволи користувача (KRBTGT для золотих квитків, приватний ключ підпису токенів для золотого SAML), може бути маніпульований для **підробки об'єкта аутентифікації** (TGT або SAMLResponse). Це дозволяє видавати себе за будь-якого користувача, надаючи несанкціонований доступ до SP.
+Можна провести паралель з [атакою золотого квитка](https://book.hacktricks.xyz/windows-hardening/active-directory-methodology/golden-ticket), де ключ, що аутентифікує особу та права користувача (KRBTGT для золотих квитків, приватний ключ підпису токенів для золотого SAML), може бути маніпульований для **підробки об'єкта аутентифікації** (TGT або SAMLResponse). Це дозволяє видавати себе за будь-якого користувача, надаючи несанкціонований доступ до SP.
 
 Золоті SAML мають певні переваги:
 
-- Їх можна **створити віддалено**, без необхідності бути частиною домену або федерації.
+- Вони можуть бути **створені віддалено**, без необхідності бути частиною домену або федерації.
 - Вони залишаються ефективними навіть при **включеній двофакторній аутентифікації (2FA)**.
 - Приватний ключ підпису токенів **не оновлюється автоматично**.
 - **Зміна пароля користувача не анулює** вже згенерований SAML.
 
 #### AWS + AD FS + Golden SAML
 
-[Служби федерації Active Directory (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>) - це служба Microsoft, яка полегшує **безпечний обмін інформацією про ідентичність** між довіреними бізнес-партнерами (федерація). Вона в основному дозволяє доменній службі ділитися ідентичностями користувачів з іншими постачальниками послуг у федерації.
+[Служби федерації Active Directory (AD FS)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>) - це служба Microsoft, яка полегшує **безпечний обмін інформацією про особу** між довіреними бізнес-партнерами (федерація). Вона дозволяє службі домену ділитися ідентичностями користувачів з іншими постачальниками послуг у федерації.
 
-З AWS, що довіряє скомпрометованому домену (в федерації), цю вразливість можна експлуатувати для потенційного **отримання будь-яких дозволів у середовищі AWS**. Атака вимагає **приватного ключа, що використовується для підпису SAML об'єктів**, подібно до необхідності мати KRBTGT в атаці золотого квитка. Доступ до облікового запису користувача AD FS є достатнім для отримання цього приватного ключа.
+З AWS, що довіряє скомпрометованому домену (в федерації), цю вразливість можна експлуатувати для потенційного **отримання будь-яких прав у середовищі AWS**. Атака вимагає **приватного ключа, що використовується для підпису SAML об'єктів**, подібно до необхідності мати KRBTGT в атаці золотого квитка. Доступ до облікового запису користувача AD FS є достатнім для отримання цього приватного ключа.
 
 Вимоги для виконання атаки Golden SAML включають:
 
@@ -81,9 +81,9 @@ https://book.hacktricks.xyz/pentesting-web/saml-attacks
 - Ім'я сесії ролі в AWS
 - Ідентифікатор облікового запису Amazon
 
-_Тільки елементи, виділені жирним шрифтом, є обов'язковими. Інші можна заповнити за бажанням._
+_Тільки елементи, виділені жирним, є обов'язковими. Інші можуть бути заповнені за бажанням._
 
-Щоб отримати **приватний ключ**, необхідний доступ до **облікового запису користувача AD FS**. Звідти приватний ключ можна **експортувати з особистого сховища** за допомогою таких інструментів, як [mimikatz](https://github.com/gentilkiwi/mimikatz). Щоб зібрати іншу необхідну інформацію, ви можете використовувати Microsoft.Adfs.Powershell snapin наступним чином, переконавшись, що ви увійшли як користувач ADFS:
+Щоб отримати **приватний ключ**, необхідний доступ до **облікового запису користувача AD FS**. Звідти приватний ключ можна **експортувати з особистого сховища** за допомогою таких інструментів, як [mimikatz](https://github.com/gentilkiwi/mimikatz). Щоб зібрати іншу необхідну інформацію, ви можете використовувати модуль Microsoft.Adfs.Powershell наступним чином, переконавшись, що ви увійшли як користувач ADFS:
 ```powershell
 # From an "AD FS" session
 # After having exported the key with mimikatz
@@ -114,7 +114,7 @@ python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -
 ```
 <figure><img src="../../../../images/image (128).png" alt=""><figcaption></figcaption></figure>
 
-### Локально -> хмара
+### На місці -> хмара
 ```powershell
 # With a domain user you can get the ImmutableID of the target user
 [System.Convert]::ToBase64String((Get-ADUser -Identity <username> | select -ExpandProperty ObjectGUID).tobytearray())
@@ -145,7 +145,7 @@ Export-AADIntADFSSigningCertificate
 # Impersonate the user
 Open-AADIntOffice365Portal -ImmutableID "aodilmsic30fugCUgHxsnK==" -Issuer http://deffin.com/adfs/services/trust -PfxFileName C:\users\adfsadmin\Desktop\ADFSSigningCertificate.pfx -Verbose
 ```
-## References
+## Посилання
 
 - [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed)
 - [https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/azure-ad-connect-hybrid-identity/phs-password-hash-sync.md

@@ -2,42 +2,42 @@
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-## Basic Information
+## Основна інформація
 
 [З документації:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-phs) **Синхронізація хешів паролів** є одним із методів входу, що використовується для досягнення гібридної ідентичності. **Azure AD Connect** синхронізує хеш, хешу, пароля користувача з локальної інстанції Active Directory до хмарної інстанції Azure AD.
 
 <figure><img src="../../../../images/image (173).png" alt=""><figcaption></figcaption></figure>
 
-Це **найпоширеніший метод**, що використовується компаніями для синхронізації локального AD з Azure AD.
+Це **найпоширеніший метод**, який використовують компанії для синхронізації локального AD з Azure AD.
 
-Всі **користувачі** та **хеш паролів** синхронізуються з локального AD до Azure AD. Однак, **паролі в чистому вигляді** або **оригінальні** **хеші** не надсилаються до Azure AD.\
+Всі **користувачі** та **хеш паролів** синхронізуються з локального AD до Azure AD. Однак, **паролі у відкритому тексті** або **оригінальні** **хеші** не надсилаються до Azure AD.\
 Більше того, **вбудовані** групи безпеки (як-от адміністратори домену...) **не синхронізуються** з Azure AD.
 
-**Синхронізація хешів** відбувається кожні **2 хвилини**. Однак, за замовчуванням, **терміни дії паролів** та **терміни дії облікових записів** **не синхронізуються** в Azure AD. Тому користувач, чий **локальний пароль прострочений** (не змінений), може продовжувати **доступ до ресурсів Azure** за допомогою старого пароля.
+**Синхронізація хешів** відбувається кожні **2 хвилини**. Однак, за замовчуванням, **терміни дії паролів** та **акаунтів** **не синхронізуються** в Azure AD. Тому користувач, чий **локальний пароль прострочений** (не змінений), може продовжувати **доступ до ресурсів Azure** за допомогою старого пароля.
 
 Коли локальний користувач хоче отримати доступ до ресурсу Azure, **автентифікація відбувається в Azure AD**.
 
-**PHS** потрібен для функцій, таких як **Захист ідентичності** та AAD Domain Services.
+**PHS** є необхідним для функцій, таких як **Захист ідентичності** та AAD Domain Services.
 
-## Pivoting
+## Півотування
 
-Коли PHS налаштовано, деякі **привілейовані облікові записи** автоматично **створюються**:
+Коли PHS налаштовано, деякі **привілейовані акаунти** автоматично **створюються**:
 
-- Обліковий запис **`MSOL_<installationID>`** автоматично створюється в локальному AD. Цьому обліковому запису надається роль **Облікові записи синхронізації каталогу** (див. [документацію](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)), що означає, що він має **дозволи на реплікацію (DCSync) в локальному AD**.
-- Обліковий запис **`Sync_<name of on-prem ADConnect Server>_installationID`** створюється в Azure AD. Цей обліковий запис може **скидати пароль будь-якого користувача** (синхронізованого або лише хмарного) в Azure AD.
+- Акаунт **`MSOL_<installationID>`** автоматично створюється в локальному AD. Цей акаунт отримує роль **Акаунтів синхронізації директорії** (див. [документацію](https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#directory-synchronization-accounts-permissions)), що означає, що він має **дозволи на реплікацію (DCSync) в локальному AD**.
+- Акаунт **`Sync_<name of on-prem ADConnect Server>_installationID`** створюється в Azure AD. Цей акаунт може **скидати пароль будь-якого користувача** (синхронізованого або лише хмарного) в Azure AD.
 
-Паролі двох попередніх привілейованих облікових записів **зберігаються в SQL сервері** на сервері, де **встановлено Azure AD Connect.** Адміністратори можуть витягувати паролі цих привілейованих користувачів у чистому вигляді.\
+Паролі двох попередніх привілейованих акаунтів **зберігаються на SQL сервері** на сервері, де **встановлено Azure AD Connect.** Адміністратори можуть витягувати паролі цих привілейованих користувачів у відкритому тексті.\
 База даних розташована в `C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf`.
 
 Можливо витягти конфігурацію з однієї з таблиць, одна з яких зашифрована:
 
 `SELECT private_configuration_xml, encrypted_configuration FROM mms_management_agent;`
 
-**Зашифрована конфігурація** зашифрована за допомогою **DPAPI** і містить **паролі користувача `MSOL_*`** в локальному AD та пароль **Sync\_\*** в AzureAD. Тому, компрометуючи ці дані, можна підвищити привілеї до AD та AzureAD.
+**Зашифрована конфігурація** зашифрована за допомогою **DPAPI** і містить **паролі користувача `MSOL_*`** в локальному AD та пароль **Sync\_\*** в AzureAD. Тому, компрометуючи їх, можна підвищити привілеї до AD та AzureAD.
 
 Ви можете знайти [повний огляд того, як ці облікові дані зберігаються та розшифровуються в цій доповіді](https://www.youtube.com/watch?v=JEIR5oGCwdg).
 
-### Finding the **Azure AD connect server**
+### Знаходження **сервера Azure AD connect**
 
 Якщо **сервер, на якому встановлено Azure AD connect**, приєднаний до домену (рекомендується в документації), його можна знайти за допомогою:
 ```powershell
@@ -47,7 +47,7 @@ Get-ADUser -Filter "samAccountName -like 'MSOL_*'" - Properties * | select SamAc
 #Azure AD module
 Get-AzureADUser -All $true | ?{$_.userPrincipalName -match "Sync_"}
 ```
-### Зловживання MSOL\_\*
+### Зловживання MSOL\_*
 ```powershell
 # Once the Azure AD connect server is compromised you can extract credentials with the AADInternals module
 Get-AADIntSyncCredentials
@@ -82,7 +82,7 @@ Set-AADIntUserPassword -SourceAnchor "3Uyg19ej4AHDe0+3Lkc37Y9=" -Password "JustA
 
 # Now it's possible to access Azure AD with the new password and op-prem with the old one (password changes aren't sync)
 ```
-Також можливо **змінити паролі лише для користувачів хмари** (навіть якщо це неочікувано)
+Також можливо **змінити паролі лише для користувачів хмари** (навіть якщо це несподівано)
 ```powershell
 # To reset the password of cloud only user, we need their CloudAnchor that can be calculated from their cloud objectID
 # The CloudAnchor is of the format USER_ObjectID.
@@ -91,14 +91,14 @@ Get-AADIntUsers | ?{$_.DirSyncEnabled -ne "True"} | select UserPrincipalName,Obj
 # Reset password
 Set-AADIntUserPassword -CloudAnchor "User_19385ed9-sb37-c398-b362-12c387b36e37" -Password "JustAPass12343.%" -Verbosewers
 ```
-Цілком можливо вивантажити пароль цього користувача.
+Також можливо скинути пароль цього користувача.
 
 > [!CAUTION]
-> Іншим варіантом було б **призначити привілейовані дозволи службі**, що **Sync** користувач має **дозволи** робити, а потім **отримати доступ до цієї служби** як спосіб підвищення привілеїв.
+> Інший варіант полягає в тому, щоб **призначити привілейовані дозволи службовому принципалу**, що **Sync** користувач має **дозволи** на це, а потім **отримати доступ до цього службового принципалу** як спосіб підвищення привілеїв.
 
-### Безшовний SSO
+### Seamless SSO
 
-Можливо використовувати безшовний SSO з PHS, який вразливий до інших зловживань. Перевірте це в:
+Можливо використовувати Seamless SSO з PHS, який вразливий до інших зловживань. Перевірте це в:
 
 {{#ref}}
 seamless-sso.md

src/pentesting-cloud/azure-security/az-lateral-movement-cloud-on-prem/pass-the-prt.md

@@ -8,21 +8,21 @@
 az-primary-refresh-token-prt.md
 {{#endref}}
 
-### Перевірте, чи у вас є PRT
+### Перевірте, чи маєте ви PRT
 ```
 Dsregcmd.exe /status
 ```
-У розділі SSO State ви повинні побачити **`AzureAdPrt`**, встановлений на **YES**.
+У розділі SSO State ви повинні бачити **`AzureAdPrt`**, встановлений на **YES**.
 
 <figure><img src="../../../images/image (140).png" alt=""><figcaption></figcaption></figure>
 
-У тому ж виході ви також можете побачити, чи **пристрій приєднано до Azure** (у полі `AzureAdJoined`):
+У тому ж виході ви також можете побачити, чи **пристрій приєднано до Azure** (в полі `AzureAdJoined`):
 
 <figure><img src="../../../images/image (135).png" alt=""><figcaption></figcaption></figure>
 
 ## PRT Cookie
 
-PRT cookie насправді називається **`x-ms-RefreshTokenCredential`** і це JSON Web Token (JWT). JWT містить **3 частини**, **заголовок**, **корисне навантаження** та **підпис**, розділені `.` і всі закодовані в base64, безпечному для URL. Типовий PRT cookie містить наступний заголовок і тіло:
+PRT cookie насправді називається **`x-ms-RefreshTokenCredential`** і це JSON Web Token (JWT). JWT містить **3 частини**, **заголовок**, **вантаж** і **підпис**, розділені `.` і всі закодовані в base64, безпечному для URL. Типовий PRT cookie містить наступний заголовок і тіло:
 ```json
 {
 "alg": "HS256",
@@ -34,30 +34,30 @@ PRT cookie насправді називається **`x-ms-RefreshTokenCredent
 "request_nonce": "AQABAAAAAAAGV_bv21oQQ4ROqh0_1-tAPrlbf_TrEVJRMW2Cr7cJvYKDh2XsByis2eCF9iBHNqJJVzYR_boX8VfBpZpeIV078IE4QY0pIBtCcr90eyah5yAA"
 }
 ```
-Актуальний **Primary Refresh Token (PRT)** інкапсульований у **`refresh_token`**, який зашифрований ключем під контролем Azure AD, що робить його вміст непрозорим і нездешевним для нас. Поле **`is_primary`** позначає інкапсуляцію основного токена оновлення в цьому токені. Щоб забезпечити прив'язку куки до конкретної сесії входу, `request_nonce` передається зі сторінки `logon.microsoftonline.com`.
+Актуальний **Primary Refresh Token (PRT)** інкапсульований у **`refresh_token`**, який зашифрований ключем під контролем Azure AD, що робить його вміст непрозорим і нездешифровуваним для нас. Поле **`is_primary`** позначає інкапсуляцію первинного токена оновлення в цьому токені. Щоб забезпечити прив'язку куки до конкретної сесії входу, `request_nonce` передається зі сторінки `logon.microsoftonline.com`.
 
 ### Потік куки PRT з використанням TPM
 
 Процес **LSASS** надішле до TPM **KDF context**, а TPM використає **session key** (зібраний під час реєстрації пристрою в AzureAD і збережений у TPM) та попередній контекст для **виведення** **ключа**, і цей **виведений ключ** використовується для **підписання куки PRT (JWT).**
 
-**KDF context** - це nonce з AzureAD та PRT, що створює **JWT**, змішаний з **контекстом** (випадкові байти).
+**KDF context** - це nonce з AzureAD і PRT, що створює **JWT**, змішаний з **контекстом** (випадкові байти).
 
-Отже, навіть якщо PRT не може бути витягнутий, оскільки він знаходиться всередині TPM, можливо зловживати LSASS для **запиту виведених ключів з нових контекстів і використання згенерованих ключів для підписання куків**.
+Отже, навіть якщо PRT не можна витягти, оскільки він знаходиться всередині TPM, можливо зловживати LSASS для **запиту виведених ключів з нових контекстів і використання згенерованих ключів для підписання куки**.
 
 <figure><img src="../../../images/image (31).png" alt=""><figcaption></figcaption></figure>
 
 ## Сценарії зловживання PRT
 
 Як **звичайний користувач**, можливо **запитати використання PRT**, звернувшись до LSASS за даними SSO.\
-Це можна зробити як **рідні додатки**, які запитують токени у **Web Account Manager** (брокер токенів). WAM передає запит до **LSASS**, який запитує токени, використовуючи підписане твердження PRT. Або це можна зробити за допомогою **браузерних (веб) потоків**, де **PRT cookie** використовується як **заголовок** для автентифікації запитів до сторінок входу Azure AS.
+Це можна зробити, як **рідні додатки**, які запитують токени у **Web Account Manager** (посередник токенів). WAM передає запит до **LSASS**, який запитує токени, використовуючи підписане твердження PRT. Або це можна зробити за допомогою **браузерних (веб) потоків**, де **PRT cookie** використовується як **заголовок** для автентифікації запитів до сторінок входу Azure AS.
 
 Як **SYSTEM** ви могли б **викрасти PRT, якщо він не захищений** TPM або **взаємодіяти з ключами PRT у LSASS**, використовуючи крипто API.
 
-## Приклади атак Pass-the-PRT
+## Приклади атаки Pass-the-PRT
 
 ### Атака - ROADtoken
 
-Для отримання додаткової інформації про цей спосіб [**перевірте цей пост**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/). ROADtoken запустить **`BrowserCore.exe`** з правильного каталогу та використає його для **отримання куки PRT**. Цю куки потім можна використовувати з ROADtools для автентифікації та **отримання постійного токена оновлення**.
+Для отримання додаткової інформації про цей спосіб [**перевірте цей пост**](https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/). ROADtoken запустить **`BrowserCore.exe`** з правильного каталогу та використає його для **отримання куки PRT**. Цю куки можна потім використовувати з ROADtools для автентифікації та **отримання постійного токена оновлення**.
 
 Щоб згенерувати дійсну куки PRT, перше, що вам потрібно, це nonce.\
 Ви можете отримати це за допомогою:
@@ -96,9 +96,9 @@ roadrecon auth --prt-cookie <prt_cookie>
 # Connect
 Connect-AzureAD --AadAccessToken <token> --AccountId <acc_ind>
 ```
-### Attack - Using roadrecon
+### Атака - Використання roadrecon
 
-### Attack - Using AADInternals and a leaked PRT
+### Атака - Використання AADInternals та витоку PRT
 
 `Get-AADIntUserPRTToken` **отримує PRT токен користувача** з комп'ютера, приєднаного до Azure AD або гібридного приєднання. Використовує `BrowserCore.exe` для отримання PRT токена.
 ```powershell
@@ -136,7 +136,7 @@ $AT = Get-AADIntAccessTokenForAzureCoreManagement -PRTToken $prtToken
 # Verify access and connect with Az. You can see account id in mimikatz prt output
 Connect-AzAccount -AccessToken $AT -TenantID <tenant-id> -AccountId <acc-id>
 ```
-Перейдіть за посиланням [https://login.microsoftonline.com](https://login.microsoftonline.com), очистіть всі куки для login.microsoftonline.com та введіть новий куки.
+Перейдіть на [https://login.microsoftonline.com](https://login.microsoftonline.com), очистіть всі куки для login.microsoftonline.com і введіть новий куки.
 ```
 Name: x-ms-RefreshTokenCredential
 Value: [Paste your output from above]
@@ -146,18 +146,18 @@ HttpOnly: Set to True (checked)
 Тоді перейдіть на [https://portal.azure.com](https://portal.azure.com)
 
 > [!CAUTION]
-> Решта повинна бути за замовчуванням. Переконайтеся, що ви можете оновити сторінку, і кукі не зникне, якщо це станеться, ви могли зробити помилку і вам доведеться пройти процес знову. Якщо ні, то все має бути добре.
+> Решта повинна бути за замовчуванням. Переконайтеся, що ви можете оновити сторінку, і кукі не зникне, якщо це станеться, ви могли зробити помилку і повинні пройти процес знову. Якщо ні, то все має бути добре.
 
-### Attack - Mimikatz
+### Атака - Mimikatz
 
-#### Steps
+#### Кроки
 
 1. **PRT (Primary Refresh Token) витягується з LSASS** (Local Security Authority Subsystem Service) і зберігається для подальшого використання.
-2. **Наступним витягується Session Key**. Оскільки цей ключ спочатку видається, а потім повторно шифрується локальним пристроєм, це вимагає розшифровки за допомогою майстер-ключа DPAPI. Докладну інформацію про DPAPI (Data Protection API) можна знайти в цих ресурсах: [HackTricks](https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords), а для розуміння його застосування зверніться до [Pass-the-cookie attack](az-pass-the-cookie.md).
+2. **Наступним витягується Session Key**. Оскільки цей ключ спочатку видається, а потім повторно шифрується локальним пристроєм, це вимагає розшифровки за допомогою DPAPI masterkey. Докладну інформацію про DPAPI (Data Protection API) можна знайти в цих ресурсах: [HackTricks](https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation/dpapi-extracting-passwords), а для розуміння його застосування зверніться до [Pass-the-cookie attack](az-pass-the-cookie.md).
 3. Після розшифровки Session Key, **отримуються похідний ключ і контекст для PRT**. Вони є критично важливими для **створення кукі PRT**. Зокрема, похідний ключ використовується для підписання JWT (JSON Web Token), що складає кукі. Докладне пояснення цього процесу надано Дірком-Яном, доступне [тут](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/).
 
 > [!CAUTION]
-> Зверніть увагу, що якщо PRT знаходиться всередині TPM, а не всередині `lsass`, **mimikatz не зможе його витягти**.\
+> Зверніть увагу, що якщо PRT знаходиться всередині TPM і не всередині `lsass`, **mimikatz не зможе його витягти**.\
 > Однак, буде можливим **отримати ключ з похідного ключа з контексту** з TPM і використовувати його для **підписання кукі (перевірте опцію 3).**
 
 Ви можете знайти **докладне пояснення виконаного процесу** для витягнення цих деталей тут: [**https://dirkjanm.io/digging-further-into-the-primary-refresh-token/**](https://dirkjanm.io/digging-further-into-the-primary-refresh-token/)
@@ -187,7 +187,7 @@ Invoke-Mimikatz -Command '"privilege::debug" "sekurlsa::cloudap"'
 > [!NOTE]
 > Якщо ви не бачите жодних даних PRT, це може бути тому, що у вас **немає жодних PRT** через те, що ваш пристрій не приєднаний до Azure AD, або ви **використовуєте стару версію** Windows 10.
 
-Щоб **розшифрувати** ключ сесії, вам потрібно **підвищити** свої привілеї до **SYSTEM**, щоб працювати в контексті комп'ютера і мати можливість використовувати **майстер-ключ DPAPI для його розшифровки**. Ви можете використовувати наступні команди для цього:
+Щоб **розшифрувати** ключ сесії, вам потрібно **підвищити** свої привілеї до **SYSTEM**, щоб працювати в контексті комп'ютера, щоб мати можливість використовувати **майстер-ключ DPAPI для його розшифровки**. Ви можете використовувати наступні команди для цього:
 ```
 token::elevate
 dpapi::cloudapkd /keyvalue:[PASTE ProofOfPosessionKey HERE] /unprotect
@@ -196,7 +196,7 @@ dpapi::cloudapkd /keyvalue:[PASTE ProofOfPosessionKey HERE] /unprotect
 
 #### Варіант 1 - Повний Mimikatz
 
-- Тепер ви хочете скопіювати обидва значення Context:
+- Тепер ви хочете скопіювати значення Context:
 
 <figure><img src="../../../images/image (210).png" alt=""><figcaption></figcaption></figure>
 
@@ -219,12 +219,12 @@ HttpOnly: Set to True (checked)
 ```
 - Потім перейдіть на [https://portal.azure.com](https://portal.azure.com)
 
-> [!CAUTION]
-> Решта повинна бути за замовчуванням. Переконайтеся, що ви можете оновити сторінку, і кукі не зникне, якщо це станеться, ви могли зробити помилку і вам доведеться пройти процес знову. Якщо ні, то все має бути в порядку.
+> [!УВАГА]
+> Решта повинна бути за замовчуванням. Переконайтеся, що ви можете оновити сторінку, і кукі не зникне, якщо це станеться, ви могли зробити помилку і вам доведеться пройти процес знову. Якщо ні, то все має бути добре.
 
-#### Option 2 - roadrecon using PRT
+#### Варіант 2 - roadrecon з використанням PRT
 
-- Спочатку оновіть PRT, який буде збережено в `roadtx.prt`:
+- Спочатку оновіть PRT, що зберегти його в `roadtx.prt`:
 ```bash
 roadtx prt -a renew --prt <PRT From mimikatz> --prt-sessionkey <clear key from mimikatz>
 ```
@@ -235,9 +235,9 @@ roadtx describe < .roadtools_auth
 ```
 <figure><img src="../../../images/image (44).png" alt=""><figcaption></figcaption></figure>
 
-#### Option 3 - roadrecon використовуючи похідні ключі
+#### Варіант 3 - roadrecon з використанням похідних ключів
 
-Маючи контекст і похідний ключ, вивантажений за допомогою mimikatz, можливо використовувати roadrecon для генерації нового підписаного cookie з:
+Маючи контекст і похідний ключ, вивантажений за допомогою mimikatz, можна використовувати roadrecon для генерації нового підписаного cookie з:
 ```bash
 roadrecon auth --prt-cookie <cookie> --prt-context <context> --derives-key <derived key>
 ```

src/pentesting-cloud/azure-security/az-permissions-for-a-pentest.md

@@ -2,6 +2,6 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-Щоб розпочати тести, ви повинні мати доступ з користувачем з **правами читача над підпискою** та **глобальною роллю читача в AzureAD**. Якщо навіть у цьому випадку ви **не можете отримати доступ до вмісту облікових записів зберігання**, ви можете виправити це за допомогою **ролі учасника облікового запису зберігання**.
+Щоб розпочати тести, ви повинні мати доступ з користувачем з **правами читача над підпискою** та **глобальною роллю читача в AzureAD**. Якщо навіть у цьому випадку ви **не можете отримати доступ до вмісту облікових записів зберігання**, ви можете виправити це за допомогою **ролі Співробітник облікового запису зберігання**.
 
 {{#include ../../banners/hacktricks-training.md}}