Az - डिवाइस पंजीकरण

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

Basic Information

जब कोई डिवाइस AzureAD में शामिल होता है तो AzureAD में एक नया ऑब्जेक्ट बनाया जाता है।

डिवाइस को रजिस्टर करते समय, user is asked to login with his account (जरूरत होने पर MFA मांगा जाएगा), उसके बाद यह device registration service के लिए tokens का अनुरोध करता है और फिर अंतिम पुष्टि का prompt दिखाता है।

फिर, डिवाइस में दो RSA keypairs जनरेट किए जाते हैं: The device key (public key) जो AzureAD को भेजा जाता है और transport key (private key) जो संभव हो तो TPM में स्टोर किया जाता है।

फिर, object AzureAD में जनरेट किया जाता है (not in Intune) और AzureAD डिवाइस को इसका द्वारा साइन किया गया एक certificate वापस देता है। आप यह जांच सकते हैं कि device is AzureAD joined और certificate के बारे में जानकारी (जैसे कि क्या यह TPM द्वारा प्रोटेक्टेड है).:

dsregcmd /status

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.

For more information about what is a PRT check:

Az - Primary Refresh Token (PRT)

TPM - ट्रस्टेड प्लेटफ़ॉर्म मॉड्यूल

TPM पावर-ऑफ डिवाइस से (यदि PIN से सुरक्षित हो) कुंजी निकालने और OS लेयर से प्राइवेट सामग्री निकालने के प्रयासों के खिलाफ रक्षा करता है।
लेकिन यह TPM और CPU के बीच भौतिक कनेक्शन को sniffing करने या सिस्टम चलने के दौरान SYSTEM अधिकारों वाले प्रोसेस से TPM में मौजूद cryptographic material का उपयोग करने के खिलाफ सुरक्षा नहीं करता।

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):

Az - Primary Refresh Token (PRT)

Registering a device with SSO tokens

It would be possible for an attacker to request a token for the Microsoft device registration service from the compromised device and register it:

# Initialize SSO flow
roadrecon auth prt-init
.\ROADtoken.exe <nonce>

# Request token with PRT with PRT cookie
roadrecon auth -r 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9 --prt-cookie <cookie>

# Custom pyhton script to register a device (check roadtx)
registerdevice.py

जिससे आपको एक प्रमाणपत्र मिलेगा जिसे आप भविष्य में PRTs के लिए अनुरोध करने के लिए इस्तेमाल कर सकते हैं। इसलिए persistence बनाए रखना और bypassing MFA संभव हो जाता है क्योंकि नए डिवाइस को रजिस्टर करने के लिए उपयोग किया गया मूल PRT टोकन पहले से ही MFA permissions granted था।

Tip

ध्यान रहें कि इस attack को करने के लिए आपको register new devices की permissions चाहिए होंगी। इसके अलावा, किसी डिवाइस को रजिस्टर करना यह नहीं दर्शाता कि डिवाइस को allowed to enrol into Intune किया जाएगा।

Caution

This attack was fixed in September 2021 as you can no longer register new devices using a SSO tokens. However, it’s still possible to register devices in a legit way (having username, password and MFA if needed). Check: roadtx.

एक डिवाइस टिकट को ओवरराइट करना

यह संभव था कि आप request a device ticket, डिवाइस के मौजूदा टिकट को overwrite करें, और इस flow के दौरान steal the PRT करें (तो TPM से इसे steal करने की ज़रूरत नहीं रहती)। अधिक जानकारी के लिए check this talk.

Caution

हालाँकि, इसे fix कर दिया गया।

WHFB key को ओवरराइट करना

Check the original slides here

Attack summary:

  • यह संभव है कि SSO के माध्यम से किसी device से registered WHFB key को overwrite किया जा सके
  • यह TPM protection को defeat करता है क्योंकि नई key के generation के दौरान key को sniffed किया जाता है
  • यह persistence भी प्रदान करता है

Users अपने own searchableDeviceKey property को Azure AD Graph के माध्यम से modify कर सकते हैं, हालांकि attacker के पास tenant में एक device होना चाहिए (on-the-fly registered या किसी legit device से stolen cert + key वाला) और AAD Graph के लिए एक valid access token होना चाहिए।

फिर, यह संभव है कि नई key generate की जाए:

roadtx genhellokey -d <device id> -k tempkey.key

और फिर searchableDeviceKey की जानकारी को PATCH करें:

यह संभव है कि किसी उपयोगकर्ता से device code phishing के माध्यम से access token प्राप्त किया जा सके और पिछले चरणों का दुरुपयोग करके steal his access किया जा सके। अधिक जानकारी के लिए देखें:

Az - Primary Refresh Token (PRT)

संदर्भ

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें