From 06a75782280324e3f4ba9ce9855f75d1790b17b7 Mon Sep 17 00:00:00 2001 From: Translator Date: Mon, 10 Feb 2025 23:34:21 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/azure-security/az-basic-information/RE --- .../az-basic-information/README.md | 106 +++++++++--------- .../az-oauth-apps-phishing.md | 27 +++-- 2 files changed, 70 insertions(+), 63 deletions(-) diff --git a/src/pentesting-cloud/azure-security/az-basic-information/README.md b/src/pentesting-cloud/azure-security/az-basic-information/README.md index 6300d1dd4..acbf9a5ad 100644 --- a/src/pentesting-cloud/azure-security/az-basic-information/README.md +++ b/src/pentesting-cloud/azure-security/az-basic-information/README.md @@ -8,12 +8,12 @@ ### Групи управління -- Вони можуть містити **інші групи управління або підписки**. -- Це дозволяє **застосовувати контроль управління** такі як RBAC та Azure Policy один раз на рівні групи управління, і вони будуть **успадковані** всіма підписками в групі. +- Вона може містити **інші групи управління або підписки**. +- Це дозволяє **застосовувати контроль управління** такі як RBAC та Azure Policy один раз на рівні групи управління і мати їх **успадкованими** всіма підписками в групі. - **10,000 груп управління** можуть підтримуватися в одному каталозі. - Дерево груп управління може підтримувати **до шести рівнів глибини**. Це обмеження не включає кореневий рівень або рівень підписки. - Кожна група управління та підписка можуть підтримувати **тільки одного батька**. -- Навіть якщо можна створити кілька груп управління, **існує лише 1 коренева група управління**. +- Навіть якщо кілька груп управління можуть бути створені, **існує лише 1 коренева група управління**. - Коренева група управління **містить** всі **інші групи управління та підписки** і **не може бути переміщена або видалена**. - Всі підписки в межах однієї групи управління повинні довіряти **одному й тому ж Entra ID орендарю.** @@ -21,7 +21,7 @@ ### Azure Підписки -- Це ще один **логічний контейнер, де можуть працювати ресурси** (ВМ, БД…) і за які буде виставлено рахунок. +- Це ще один **логічний контейнер, де можуть бути запущені ресурси** (VMs, DBs…) і за які буде виставлено рахунок. - Його **батьком** завжди є **група управління** (і це може бути коренева група управління), оскільки підписки не можуть містити інші підписки. - Він **довіряє лише одному Entra ID** каталогу. - **Дозволи**, застосовані на рівні підписки (або будь-якого з її батьків), **успадковуються** всіма ресурсами всередині підписки. @@ -42,7 +42,7 @@ - `/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}` -Для віртуальної машини з назвою myVM у групі ресурсів `myResourceGroup` під підпискою ID `12345678-1234-1234-1234-123456789012`, Azure Resource ID виглядає так: +Для віртуальної машини з назвою myVM в групі ресурсів `myResourceGroup` під підпискою ID `12345678-1234-1234-1234-123456789012`, Azure Resource ID виглядає так: - `/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM` @@ -75,7 +75,7 @@ Entra Domain Services розширює можливості Entra ID, пропо - Вказати властивості - Тип користувача за замовчуванням - “**Гість**” -### Стандартні дозволи для членів та гостей +### Дефолтні дозволи для членів та гостей Ви можете перевірити їх у [https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions](https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions), але серед інших дій член зможе: @@ -84,35 +84,35 @@ Entra Domain Services розширює можливості Entra ID, пропо - Створювати групи безпеки - Читати неприховані членства груп - Додавати гостей до власних груп -- Створювати новий додаток (_може бути вимкнено_) +- Створювати нові додатки (_може бути вимкнено_) - Додавати до 50 пристроїв до Azure (_може бути вимкнено_) > [!NOTE] > Пам'ятайте, що для перерахунку ресурсів Azure користувачеві потрібен явний дозвіл. -### Стандартні налаштовувані дозволи для користувачів +### Дефолтні налаштовувані дозволи для користувачів - **Члени (**[**документи**](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,7 +122,7 @@ Entra Domain Services розширює можливості Entra ID, пропо Є **2 типи груп**: -- **Безпекові**: Цей тип групи використовується для надання членам доступу до додатків, ресурсів та призначення ліцензій. Членами можуть бути користувачі, пристрої, службові принципали та інші групи. +- **Безпека**: Цей тип групи використовується для надання членам доступу до додатків, ресурсів та призначення ліцензій. Членами можуть бути користувачі, пристрої, службові принципали та інші групи. - **Microsoft 365**: Цей тип групи використовується для співпраці, надаючи членам доступ до спільної поштової скриньки, календаря, файлів, сайту SharePoint тощо. Членами групи можуть бути лише користувачі. - Це матиме **електронну адресу** з доменом орендаря EntraID. @@ -133,7 +133,7 @@ Entra Domain Services розширює можливості Entra ID, пропо ### **Службові принципали** -**Службовий принципал** - це **ідентифікація**, створена для **використання** з **додатками**, хостинговими службами та автоматизованими інструментами для доступу до ресурсів Azure. Цей доступ **обмежений ролями, призначеними** службовому принципалу, що дає вам контроль над **тим, які ресурси можуть бути доступні** і на якому рівні. З міркувань безпеки завжди рекомендується **використовувати службові принципали з автоматизованими інструментами**, а не дозволяти їм входити з ідентифікацією користувача. +**Службовий принципал** є **ідентифікацією**, створеною для **використання** з **додатками**, хостинговими службами та автоматизованими інструментами для доступу до ресурсів Azure. Цей доступ **обмежений ролями, призначеними** службовому принципалу, що дає вам контроль над **тим, які ресурси можуть бути доступні** і на якому рівні. З міркувань безпеки завжди рекомендується **використовувати службові принципали з автоматизованими інструментами**, а не дозволяти їм входити з ідентифікацією користувача. Можливо **безпосередньо увійти як службовий принципал**, згенерувавши йому **секрет** (пароль), **сертифікат** або надавши **федеративний** доступ до сторонніх платформ (наприклад, Github Actions). @@ -142,43 +142,43 @@ Entra Domain Services розширює можливості Entra ID, пропо ### Реєстрації додатків -**Реєстрація додатка** - це конфігурація, яка дозволяє додатку інтегруватися з Entra ID та виконувати дії. +**Реєстрація додатка** є конфігурацією, яка дозволяє додатку інтегруватися з Entra ID та виконувати дії. #### Ключові компоненти: -1. **Ідентифікатор додатка (Client ID):** Унікальний ідентифікатор для вашого додатка в Azure AD. +1. **Ідентифікатор додатка (Client ID):** Унікальний ідентифікатор для вашого додатку в Azure AD. 2. **URI перенаправлення:** URL-адреси, куди Azure AD надсилає відповіді на аутентифікацію. -3. **Сертифікати, секрети та федеративні облікові дані:** Можливо згенерувати секрет або сертифікат для входу як службовий принципал додатка або надати федеративний доступ до нього (наприклад, Github Actions). +3. **Сертифікати, секрети та федеративні облікові дані:** Можливо згенерувати секрет або сертифікат для входу як службовий принципал додатку або надати федеративний доступ до нього (наприклад, Github Actions). 1. Якщо **сертифікат** або **секрет** згенеровано, особа може **увійти як службовий принципал** за допомогою CLI-інструментів, знаючи **ідентифікатор додатка**, **секрет** або **сертифікат** та **орендар** (домен або ID). -4. **Дозволи API:** Визначає, до яких ресурсів або API додаток може отримати доступ. -5. **Налаштування аутентифікації:** Визначає підтримувані потоки аутентифікації додатка (наприклад, OAuth2, OpenID Connect). +4. **API Дозволи:** Визначає, до яких ресурсів або API додаток може отримати доступ. +5. **Налаштування аутентифікації:** Визначає підтримувані потоки аутентифікації додатку (наприклад, OAuth2, OpenID Connect). 6. **Службовий принципал**: Службовий принципал створюється, коли створюється додаток (якщо це робиться з веб-консолі) або коли він встановлюється в новому орендарі. -1. **Службовий принципал** отримає всі запитувані дозволи, з якими він був налаштований. +1. **Службовий принципал** отримає всі запитані дозволи, з якими він був налаштований. -### Стандартні дозволи на згоду +### Дефолтні дозволи згоди **Згода користувачів на додатки** - **Не дозволяти згоду користувачів** - Адміністратор буде потрібен для всіх додатків. -- **Дозволити згоду користувачів на додатки від перевірених видавців, для вибраних дозволів (рекомендується)** -- Усі користувачі можуть дати згоду на дозволи, класифіковані як "низький вплив", для додатків від перевірених видавців або додатків, зареєстрованих в цій організації. -- **Стандартні** дозволи низького впливу (хоча вам потрібно прийняти, щоб додати їх як низькі): +- **Дозволити згоду користувачів на додатки від перевірених видавців, внутрішніх додатків та додатків, що запитують лише вибрані дозволи (рекомендується)** +- Усі користувачі можуть давати згоду на додатки, що запитують лише дозволи, класифіковані як "низький вплив", додатки від перевірених видавців та додатки, зареєстровані в орендарі. +- **Дефолтні** дозволи низького впливу (хоча вам потрібно прийняти, щоб додати їх як низькі): - User.Read - увійти та прочитати профіль користувача - offline_access - підтримувати доступ до даних, до яких користувачі надали доступ - openid - увійти користувачів - profile - переглядати основний профіль користувача - email - переглядати електронну адресу користувача - **Дозволити згоду користувачів на додатки (за замовчуванням)** -- Усі користувачі можуть дати згоду на будь-який додаток для доступу до даних організації. +- Усі користувачі можуть давати згоду на будь-який додаток для доступу до даних організації. -**Запити на згоду адміністратора**: за замовчуванням **Ні** +**Запити на згоду адміністратора**: За замовчуванням **Ні** - Користувачі можуть запитувати згоду адміністратора на додатки, на які вони не можуть дати згоду - Якщо **Так**: Можливо вказати Користувачів, Групи та Ролі, які можуть давати згоду на запити - Налаштуйте також, чи отримуватимуть користувачі електронні сповіщення та нагадування про закінчення терміну -### **Керована ідентичність (метадані)** +### **Керована ідентичність (Метадані)** Керовані ідентичності в Azure Active Directory пропонують рішення для **автоматичного управління ідентичністю** додатків. Ці ідентичності використовуються додатками для **підключення** до **ресурсів**, сумісних з аутентифікацією Azure Active Directory (**Azure AD**). Це дозволяє **усунути необхідність жорсткого кодування облікових даних хмари** в коді, оскільки додаток зможе звертатися до **служби метаданих**, щоб отримати дійсний токен для **виконання дій** як вказана керована ідентичність в Azure. @@ -193,7 +193,7 @@ Entra Domain Services розширює можливості Entra ID, пропо Це просто **таблиця в Azure для фільтрації службових принципалів** та перевірки додатків, які були призначені. -**Це не ще один тип "додатка",** в Azure немає жодного об'єкта, який є "підприємницьким додатком", це просто абстракція для перевірки службових принципалів, реєстрацій додатків та керованих ідентичностей. +**Це не ще один тип "додатку",** в Azure немає жодного об'єкта, який є "підприємницьким додатком", це просто абстракція для перевірки службових принципалів, реєстрацій додатків та керованих ідентичностей. ### Адміністративні одиниці @@ -231,7 +231,7 @@ Entra Domain Services розширює можливості Entra ID, пропо ### Вбудовані ролі -[З документації: ](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 приклади **вбудованих ролей для ресурсів Compute**: @@ -239,7 +239,7 @@ Entra Domain Services розширює можливості Entra ID, пропо | ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ | | [Virtual Machine User Login](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). @@ -253,10 +253,10 @@ Entra Domain Services розширює можливості Entra ID, пропо - Принципал з виключеним дозволом не зможе його використовувати, навіть якщо дозвіл надається в іншому місці - Можливо використовувати підстановочні знаки - Використовуваний формат - JSON -- `actions` стосуються дозволів на управлінські операції над ресурсами, таких як створення, оновлення або видалення визначень ресурсів і налаштувань. -- `dataActions` - це дозволи на операції з даними в межах ресурсу, що дозволяє вам читати, записувати або видаляти фактичні дані, що містяться в ресурсі. +- `actions` стосуються дозволів на управлінські операції над ресурсами, таких як створення, оновлення або видалення визначень ресурсів та налаштувань. +- `dataActions` є дозволами на операції з даними в межах ресурсу, що дозволяє вам читати, записувати або видаляти фактичні дані, що містяться в ресурсі. - `notActions` та `notDataActions` використовуються для виключення конкретних дозволів з ролі. Однак **вони не забороняють їх**, якщо інша роль надає їх, принципал матиме їх. -- `assignableScopes` - це масив обсягів, де роль може бути призначена (такі як групи управління, підписки або групи ресурсів). +- `assignableScopes` є масивом обсягів, де роль може бути призначена (такі як групи управління, підписки або групи ресурсів). Приклад JSON дозволів для кастомної ролі: ```json @@ -290,14 +290,14 @@ Entra Domain Services розширює можливості Entra ID, пропо ``` ### Permissions order -- Щоб **принципал мав доступ до ресурсу**, йому потрібно явно надати роль (будь-яким чином), **яка надає йому це дозволення**. -- Явне **заперечення має пріоритет** над роллю, що надає дозволення. +- Щоб **суб'єкт мав доступ до ресурсу**, йому потрібно надати явну роль (будь-яким чином), **яка надає йому це право**. +- Явне **заперечення має пріоритет** над роллю, що надає це право.

https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10

### Global Administrator -Global Administrator — це роль з Entra ID, яка надає **повний контроль над орендою Entra ID**. Однак за замовчуванням вона не надає жодних дозволів на ресурси Azure. +Global Administrator — це роль з Entra ID, яка надає **повний контроль над орендою Entra ID**. Однак за замовчуванням вона не надає жодних прав на ресурси Azure. Користувачі з роллю Global Administrator мають можливість '**підвищити' до ролі User Access Administrator Azure в кореневій групі управління**. Таким чином, Global Administrators можуть керувати доступом у **всіх підписках Azure та групах управління.**\ Це підвищення можна здійснити в кінці сторінки: [https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/\~/Properties](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties) @@ -306,26 +306,26 @@ Global Administrator — це роль з Entra ID, яка надає **повн ### Assignments Conditions & MFA -Згідно з **[документацією](https://learn.microsoft.com/en-us/azure/role-based-access-control/conditions-role-assignments-portal)**: Наразі умови можуть бути додані до вбудованих або користувацьких призначень ролей, які мають **дії з даними блобів або дії з даними черг**. +Згідно з **[документацією](https://learn.microsoft.com/en-us/azure/role-based-access-control/conditions-role-assignments-portal)**: Наразі умови можуть бути додані до вбудованих або користувацьких призначень ролей, які мають **дії з даними блобів або дій з даними черг**. ### Deny Assignments Так само, як і призначення ролей, **заперечення** використовуються для **контролю доступу до ресурсів Azure**. Однак **заперечення** використовуються для **явного заперечення доступу** до ресурсу, навіть якщо користувачу було надано доступ через призначення ролі. **Заперечення** мають пріоритет над **призначеннями ролей**, що означає, що якщо користувачу надано доступ через призначення ролі, але йому також явно заперечено доступ через заперечення, заперечення матиме пріоритет. -Так само, як і призначення ролей, **заперечення** застосовуються до певної області, що вказує на постраждалі принципали та дозволи, які заперечуються. Більше того, у випадку заперечень можливо **запобігти успадкуванню заперечення** дітьми ресурсів. +Так само, як і призначення ролей, **заперечення** застосовуються до певної області, що вказує на постраждалі суб'єкти та права, які заперечуються. Більше того, у випадку заперечень можливо **запобігти успадкуванню заперечення** від дочірніх ресурсів. ### Azure Policies -**Azure Policies** — це правила, які допомагають організаціям забезпечити відповідність їх ресурсів певним стандартам і вимогам. Вони дозволяють **забезпечувати або перевіряти налаштування ресурсів в Azure**. Наприклад, ви можете запобігти створенню віртуальних машин в несанкціонованому регіоні або забезпечити, щоб усі ресурси мали певні теги для відстеження. +**Azure Policies** — це правила, які допомагають організаціям забезпечити відповідність їх ресурсів певним стандартам і вимогам. Вони дозволяють **застосовувати або перевіряти налаштування на ресурсах в Azure**. Наприклад, ви можете запобігти створенню віртуальних машин в несанкціонованому регіоні або забезпечити, щоб усі ресурси мали певні теги для відстеження. Azure Policies є **проактивними**: вони можуть зупинити створення або зміну ресурсів, які не відповідають вимогам. Вони також є **реактивними**, дозволяючи вам знаходити та виправляти існуючі ресурси, які не відповідають вимогам. -#### **Key Concepts** +#### **Ключові концепції** -1. **Policy Definition**: Правило, написане в JSON, яке вказує, що дозволено або вимагається. -2. **Policy Assignment**: Застосування політики до певної області (наприклад, підписка, група ресурсів). -3. **Initiatives**: Збірка політик, об'єднаних для ширшого застосування. -4. **Effect**: Вказує, що відбувається, коли політика спрацьовує (наприклад, "Заперечити", "Аудит" або "Додати"). +1. **Визначення політики**: Правило, написане в JSON, яке вказує, що дозволено або вимагається. +2. **Призначення політики**: Застосування політики до певної області (наприклад, підписка, група ресурсів). +3. **Ініціативи**: Збірка політик, об'єднаних для ширшого застосування. +4. **Ефект**: Вказує, що відбувається, коли політика спрацьовує (наприклад, "Заперечити", "Аудит" або "Додати"). **Деякі приклади:** diff --git a/src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-oauth-apps-phishing.md b/src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-oauth-apps-phishing.md index 5488cded6..21c0deebc 100644 --- a/src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-oauth-apps-phishing.md +++ b/src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-oauth-apps-phishing.md @@ -25,16 +25,16 @@ - Якщо фішинговий користувач є адміністратором, який може **надавати згоду на будь-який застосунок з будь-якими дозволами**, застосунок також може **запитувати привілейовані дозволи**. - **Authenticated**: Після компрометації принципала з достатніми привілеями, **створіть застосунок всередині облікового запису** та **фішинг** деякого **привілейованого** користувача, який може приймати привілейовані OAuth дозволи. - У цьому випадку ви вже можете отримати доступ до інформації каталогу, тому дозвіл `User.ReadBasic.All` більше не є цікавим. -- Вам, ймовірно, цікаві **дозволи, які вимагають надання згоди адміністратором**, оскільки звичайний користувач не може надати жодних дозволів для OAuth застосунків, тому вам потрібно **фішити лише тих користувачів** (більше про те, які ролі/дозволи надають цей привілей пізніше). +- Вам, ймовірно, цікаві **дозволи, які вимагають надання згоди адміністратором**, оскільки звичайний користувач не може надати жодних дозволів для OAuth застосунків, тому вам потрібно **фішити лише тих користувачів** (більше про те, які ролі/дозволи надають це право пізніше). -### Користувачам дозволено надавати згоду +### Користувачі можуть надавати згоду Зверніть увагу, що вам потрібно виконати цю команду від користувача всередині орендаря, ви не можете знайти цю конфігурацію орендаря з зовнішнього. Наступна команда CLI може допомогти вам зрозуміти дозволи користувачів: ```bash az rest --method GET --url "https://graph.microsoft.com/v1.0/policies/authorizationPolicy" ``` -- Користувачі можуть давати згоду на всі додатки: Якщо всередині **`permissionGrantPoliciesAssigned`** ви можете знайти: `ManagePermissionGrantsForSelf.microsoft-user-default-legacy`, тоді користувачі можуть приймати кожен додаток. -- Користувачі можуть давати згоду на додатки від перевірених видавців або вашої організації, але тільки на дозволи, які ви виберете: Якщо всередині **`permissionGrantPoliciesAssigned`** ви можете знайти: `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team`, тоді користувачі можуть приймати кожен додаток. +- Користувачі можуть давати згоду на всі додатки: Якщо всередині **`permissionGrantPoliciesAssigned`** ви можете знайти: `ManagePermissionGrantsForSelf.microsoft-user-default-legacy`, тоді користувачі можуть приймати будь-який додаток. +- Користувачі можуть давати згоду на додатки від перевірених видавців або вашої організації, але тільки на дозволи, які ви виберете: Якщо всередині **`permissionGrantPoliciesAssigned`** ви можете знайти: `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team`, тоді користувачі можуть приймати будь-який додаток. - **Вимкнути згоду користувача**: Якщо всередині **`permissionGrantPoliciesAssigned`** ви можете знайти тільки: `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-chat` та `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team`, тоді користувачі не можуть давати згоду. Можна знайти значення кожної з коментованих політик у: @@ -62,8 +62,8 @@ az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/0d60 Атака включає кілька етапів, націлених на загальну компанію. Ось як це може відбуватися: 1. **Реєстрація домену та хостинг додатка**: Зловмисник реєструє домен, що нагадує надійний сайт, наприклад, "safedomainlogin.com". Під цим доменом створюється піддомен (наприклад, "companyname.safedomainlogin.com") для хостингу додатка, призначеного для захоплення кодів авторизації та запиту токенів доступу. -2. **Реєстрація додатка в Azure AD**: Зловмисник потім реєструє багатокористувацький додаток у своєму Azure AD Tenant, називаючи його на честь цільової компанії, щоб виглядати легітимно. Вони налаштовують URL-адресу перенаправлення додатка на піддомен, що хостить шкідливий додаток. -3. **Налаштування дозволів**: Зловмисник налаштовує додаток з різними дозволами API (наприклад, `Mail.Read`, `Notes.Read.All`, `Files.ReadWrite.All`, `User.ReadBasic.All`, `User.Read`). Ці дозволи, після їх надання користувачем, дозволяють зловмиснику витягувати чутливу інформацію від імені користувача. +2. **Реєстрація додатка в Azure AD**: Зловмисник потім реєструє багатокористувацький додаток у своєму Azure AD Tenant, називаючи його на честь цільової компанії, щоб виглядати легітимно. Вони налаштовують URL-адресу перенаправлення додатка, щоб вона вказувала на піддомен, що хостить шкідливий додаток. +3. **Налаштування дозволів**: Зловмисник налаштовує додаток з різними дозволами API (наприклад, `Mail.Read`, `Notes.Read.All`, `Files.ReadWrite.All`, `User.ReadBasic.All`, `User.Read`). Ці дозволи, після надання користувачем, дозволяють зловмиснику витягувати чутливу інформацію від імені користувача. 4. **Розповсюдження шкідливих посилань**: Зловмисник створює посилання, що містить ідентифікатор клієнта шкідливого додатка, і ділиться ним з цільовими користувачами, обманюючи їх на надання згоди. ## Приклад атаки @@ -116,18 +116,25 @@ https://graph.microsoft.com/v1.0/me/onenote/notebooks \ ``` ## Інші інструменти -- [**365-Stealer**](https://github.com/AlteredSecurity/365-Stealer)**:** Перевірте [https://www.alteredsecurity.com/post/introduction-to-365-stealer](https://www.alteredsecurity.com/post/introduction-to-365-stealer), щоб дізнатися, як його налаштувати. +- [**365-Stealer**](https://github.com/AlteredSecurity/365-Stealer)**:** Перегляньте [https://www.alteredsecurity.com/post/introduction-to-365-stealer](https://www.alteredsecurity.com/post/introduction-to-365-stealer), щоб дізнатися, як його налаштувати. - [**O365-Attack-Toolkit**](https://github.com/mdsecactivebreach/o365-attack-toolkit) ## Пост-експлуатація ### Фішинг Пост-експлуатація -Залежно від запитуваних дозволів, ви можете **отримати доступ до різних даних орендаря** (список користувачів, груп... або навіть змінювати налаштування) та **інформації користувача** (файли, нотатки, електронні листи...). Тоді ви можете використовувати ці дозволи для виконання цих дій. +Залежно від запитуваних дозволів, ви можете **отримати доступ до різних даних орендаря** (список користувачів, груп... або навіть змінити налаштування) та **інформації користувача** (файли, нотатки, електронні листи...). Потім ви можете використовувати ці дозволи для виконання цих дій. -### Пост-експлуатація додатків +### Entra ID Додатки Адміністратор -Перевірте розділи Додатків та Службових Принципів на сторінці: +Якщо вам вдалося якимось чином скомпрометувати Entra ID принципал, який може керувати Додатками в Entra ID, і є додатки, які використовуються користувачами орендаря. Адміністратор зможе **змінити дозволи, які запитує додаток, і додати нову дозволену адресу перенаправлення для крадіжки токенів**. +- Зверніть увагу, що можливо **додати URI перенаправлення** (немає потреби видаляти реальний) і потім надіслати HTTP посилання, використовуючи URI перенаправлення зловмисника, так що коли користувач слідує за посиланням, аутентифікація відбувається автоматично, і зловмисник отримує токен. +- Також можливо змінити дозволи, які запитує додаток, щоб отримати більше дозволів від користувачів, але в цьому випадку користувачеві потрібно буде **знову прийняти запит** (навіть якщо він вже був увійшов). +- Щоб виконати цю атаку, зловмиснику **НЕ ПОТРІБНО** контролювати код додатка, оскільки він може просто надіслати посилання для входу в додаток користувачу з новою URL-адресою в параметрі **`redirect_uri`**. + +### Додаток Пост Експлуатація + +Перегляньте розділи Додатків та Сервісних Принципалів на сторінці: {{#ref}} ../az-privilege-escalation/az-entraid-privesc/