From 0b8e86c7229b01b14d400701fff7b4a9b644a2dd Mon Sep 17 00:00:00 2001 From: Translator Date: Wed, 21 Jan 2026 20:31:21 +0000 Subject: [PATCH] Translated ['', 'src/pentesting-cloud/azure-security/az-device-registrat --- .../azure-security/az-device-registration.md | 52 +++++++++---------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/src/pentesting-cloud/azure-security/az-device-registration.md b/src/pentesting-cloud/azure-security/az-device-registration.md index d92b8f621..924dd3670 100644 --- a/src/pentesting-cloud/azure-security/az-device-registration.md +++ b/src/pentesting-cloud/azure-security/az-device-registration.md @@ -1,41 +1,41 @@ -# Az - Device Registration +# Az - Реєстрація пристрою {{#include ../../banners/hacktricks-training.md}} -## Basic Information +## Основна інформація Коли пристрій приєднується до AzureAD, у AzureAD створюється новий об'єкт. -При реєстрації пристрою **користувача просять увійти зі своїм обліковим записом** (запит на MFA, якщо потрібно), потім запитуються токени для служби реєстрації пристроїв і потім з'являється фінальний запит на підтвердження. +Під час реєстрації пристрою **користувача просять увійти у свій обліковий запис** (за потреби з MFA), далі запитуються токени для служби реєстрації пристроїв і наприкінці з'являється запит на підтвердження. -Потім у пристрої генеруються дві пари ключів RSA: **ключ пристрою** (**публічний** ключ), який надсилається до **AzureAD**, і **транспортний** ключ (**приватний** ключ), який зберігається в TPM, якщо це можливо. +Потім на пристрої генеруються два RSA ключові пари: **ключ пристрою** (**публічний** ключ), який відправляється в **AzureAD**, та **транспортний ключ** (**приватний** ключ), який зберігається в TPM, якщо це можливо. -Потім у **AzureAD** генерується **об'єкт** (не в Intune), і AzureAD повертає пристрою **сертифікат**, підписаний ним. Ви можете перевірити, що **пристрій приєднано до AzureAD** та інформацію про **сертифікат** (наприклад, чи захищений він TPM). +Потім в **AzureAD** (не в Intune) створюється **об'єкт**, і AzureAD повертає пристрою **сертифікат**, підписаний ним. Ви можете перевірити, що **пристрій приєднаний до AzureAD** та інформацію про **сертифікат** (наприклад, чи захищений він TPM).: ```bash dsregcmd /status ``` -Після реєстрації пристрою **Primary Refresh Token** запитується модулем LSASS CloudAP і надається пристрою. Разом з PRT також передається **ключ сесії, зашифрований так, щоб тільки пристрій міг його розшифрувати** (використовуючи публічний ключ транспортного ключа), і він **необхідний для використання PRT.** +After the device registration a **Primary Refresh Token** is requested by the LSASS CloudAP module and given to the device. With the PRT is also delivered the **session key encrypted so only the device can decrypt it** (using the public key of the transport key) and it's **needed to use the PRT.** -Для отримання додаткової інформації про те, що таке PRT, перегляньте: +For more information about what is a PRT check: {{#ref}} az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md {{#endref}} -### TPM - Модуль довірчої платформи +### TPM — модуль довіреної платформи -**TPM** **захищає** від витоку ключів **з пристрою, що вимкнений** (якщо захищений PIN-кодом) та від витоку приватних матеріалів з рівня ОС.\ -Але він **не захищає** від **перехоплення** фізичного з'єднання між TPM і ЦП або **використання криптографічних матеріалів** у TPM, поки система працює з процесу з правами **SYSTEM**. +The **TPM** **protects** against key **extraction** from a powered down device (if protected by PIN) and from extracting the private material from the OS layer.\ +But it **doesn't protect** against **sniffing** the physical connection between the TPM and CPU or **using the cryptographic material** in the TPM while the system is running from a process with **SYSTEM** rights. -Якщо ви переглянете наступну сторінку, ви побачите, що **викрадення PRT** може бути використано для доступу як **користувач**, що є чудово, оскільки **PRT розташовані на пристроях**, тому їх можна вкрасти (або, якщо не вкрадені, зловживати для генерації нових підписних ключів): +If you check the following page you will see that **stealing the PRT** can be used to access like a the **user**, which is great because the **PRT is located devices**, so it can be stolen from them (or if not stolen abused to generate new signing keys): {{#ref}} az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md {{#endref}} -## Реєстрація пристрою з токенами SSO +## Registering a device with SSO tokens -Зловмисник міг би запитати токен для служби реєстрації пристроїв Microsoft з скомпрометованого пристрою та зареєструвати його: +It would be possible for an attacker to request a token for the Microsoft device registration service from the compromised device and register it: ```bash # Initialize SSO flow roadrecon auth prt-init @@ -47,17 +47,17 @@ roadrecon auth -r 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 --prt-cookie # Custom pyhton script to register a device (check roadtx) registerdevice.py ``` -Який надасть вам **сертифікат, який ви можете використовувати для запиту PRT у майбутньому**. Таким чином, підтримуючи постійність і **обходячи MFA**, оскільки оригінальний токен PRT, використаний для реєстрації нового пристрою, **вже мав дозволи на MFA**. +Який дасть вам **сертифікат, який ви зможете використати для запиту PRTs у майбутньому**. Отже, це забезпечує персистентність і **обхід MFA**, оскільки оригінальний PRT токен, використаний для реєстрації нового пристрою, **вже мав надані права MFA**. > [!TIP] -> Зверніть увагу, що для виконання цієї атаки вам знадобляться дозволи на **реєстрацію нових пристроїв**. Також реєстрація пристрою не означає, що пристрій буде **дозволено зареєструватися в Intune**. +> Зауважте, що для виконання цієї атаки вам знадобляться права на **реєстрацію нових пристроїв**. Також реєстрація пристрою не означає, що пристрій буде **дозволено зареєструватися в Intune**. > [!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). +> Цю атаку виправили у вересні 2021 року — тепер ви більше не можете реєструвати нові пристрої, використовуючи SSO токени. Однак все ще можливо легітимно реєструвати пристрої (маючи username, password та 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). +Було можливо **запитати device ticket**, **перезаписати** поточний на пристрої, і під час процесу **вкрасти PRT** (тобто немає потреби вкрадати його з TPM). Для детальнішої інформації [**див. цю доповідь**](https://youtu.be/BduCn8cLV1A).
@@ -66,27 +66,27 @@ registerdevice.py ## Перезаписати ключ WHFB -[**Перевірте оригінальні слайди тут**](https://dirkjanm.io/assets/raw/Windows%20Hello%20from%20the%20other%20side_nsec_v1.0.pdf) +[**Перегляньте оригінальні слайди тут**](https://dirkjanm.io/assets/raw/Windows%20Hello%20from%20the%20other%20side_nsec_v1.0.pdf) -Резюме атаки: +Короткий опис атаки: -- Можливо **перезаписати** **зареєстрований ключ WHFB** з **пристрою** через SSO -- Це **обходить захист TPM**, оскільки ключ **перехоплюється під час генерації** нового ключа -- Це також забезпечує **постійність** +- Можливо **перезаписати** зареєстрований ключ **WHFB** з **пристрою** через **SSO** +- Це **обминає захист TPM**, оскільки ключ **перехоплюється під час генерації** нового ключа +- Це також забезпечує **персистентність**
-Користувачі можуть змінювати свою власну властивість searchableDeviceKey через Azure AD Graph, однак атакуючий повинен мати пристрій у тенанті (зареєстрований на льоту або викравши сертифікат + ключ з легітимного пристрою) і дійсний токен доступу для AAD Graph. +Користувачі можуть змінювати власну властивість searchableDeviceKey через Azure AD Graph, однак атакуючий повинен мати пристрій у tenant (зареєстрований на ходу або маючи вкрадений cert + key з легітимного пристрою) та дійсний access token для AAD Graph. Тоді можливо згенерувати новий ключ за допомогою: ```bash roadtx genhellokey -d -k tempkey.key ``` -і потім PATCH інформацію про searchableDeviceKey: +а потім PATCH інформації searchableDeviceKey:
-Можливо отримати токен доступу від користувача через **device code phishing** і зловживати попередніми кроками, щоб **викрасти його доступ**. Для отримання додаткової інформації перевірте: +Можна отримати access token від користувача через **device code phishing** і скористатися попередніми кроками, щоб **вкрасти його доступ**. Для додаткової інформації дивіться: {{#ref}} az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md @@ -94,7 +94,7 @@ az-lateral-movement-cloud-on-prem/az-primary-refresh-token-prt.md
-## References +## Посилання - [https://youtu.be/BduCn8cLV1A](https://youtu.be/BduCn8cLV1A) - [https://www.youtube.com/watch?v=x609c-MUZ_g](https://www.youtube.com/watch?v=x609c-MUZ_g)