تعداد بنية AWS السحابية (Enumerating AWS Cloud Infrastructure)

01نظرة عامة على استطلاع السحابة

ليه استطلاع السحابة مختلف

الاستطلاع التقليدي بيعتمد على فحص IPs وفحص الخدمات وإيجاد منافذ مفتوحة. استطلاع السحابة بيضيف أسطح هجوم جديدة تمامًا.

AWS واحدة من أكثر منصات السحابة انتشارًا — وهي التركيز الأساسي لهذا الموديول.

منظوران للتعداد

02استطلاع DNS والدومين

البداية من دومين واحد

• المعلومة الوحيدة المعروفة: الدومين الأساسي فقط (مثلًا BadGlitch.io)
• الخطوة 1 — استعلام سجلات NS: بيكشف مين بيدير DNS الدومين. نمط AWS Route 53: *.awsdns-*.com / .org / .net / .co.uk — ده لوحده بيؤكد استخدام AWS
• الخطوة 2 — WHOIS على دومين الـ Name Server: بيؤكد الملكية لأمازون عبر معلومات المسجّل

البصمة التقنية — أوامر عملية

# استعلام سجلات NS:
nslookup -type=NS badglitch.io
# → ns-XXX.awsdns-XX.com

# تحويل الدومين لـ IP:
nslookup badglitch.io
# → 52.x.x.x (نطاق AWS العام)

# Reverse DNS lookup:
nslookup 52.x.x.x
# → ec2-52-x-x-x.compute-1.amazonaws.com

# WHOIS على الـ IP:
whois 52.x.x.x | grep -i 'amazon\|aws'
# يؤكد: AMAZON-EC2

تعداد الـ Subdomains

• كل Subdomain ممكن يمثّل خدمة أو بيئة مختلفة — بيئات Dev/Staging/Internal غالبًا سيئة الإعداد
• الطرق: DNS brute-force بـ Wordlists، سجلات Certificate Transparency (crt.sh)، محركات البحث (site:domain.com)
• الأدوات: amass، subfinder، dnsx، وضع DNS في gobuster
• كل Subdomain جديد بيعيد تشغيل عملية البصمة من الأول

03استطلاع الدومين الخاص بالخدمات

كيف تُنشئ خدمات AWS روابط متوقَّعة

اكتشاف أي رابط خدمة بيكشف الخدمة السحابية المستخدَمة، وأنماط التسمية بتفضح عادات التنظيم الداخلية — معرفة اسم Bucket واحد بتساعد في تخمين أسماء تانية.

أدوات المتصفح للاستطلاع

• فتح الموقع الهدف وتشغيل DevTools (F12) → تبويب Network → إعادة تحميل الصفحة
• كل طلب مورد ظاهر: JavaScript، CSS، صور، خطوط، استدعاءات API — بما فيها الموارد من دومينات خارجية زي S3 buckets
• ركّز على الطلبات لـ *.s3.amazonaws.com — بتكشف أسماء الـ Buckets، ومسار الرابط غالبًا بيكشف البنية الداخلية للملفات

أخطاء إعداد S3 Bucket

حتى من غير صلاحية سرد: رسائل الخطأ بتؤكد وجود الـ Bucket من عدمه — 403 يعني الـ Bucket موجود لكن الوصول مرفوض، و404 يعني الـ Bucket مش موجود أصلًا. جرّب أنماط زي company-dev، company-backup، company-staging.

أدوات اكتشاف Buckets آلية

• GrayhatWarfare.com — بحث عن S3 Buckets المكشوفة علنًا بالكلمة المفتاحية، عبر عدة مزوّدين سحابيين، بدون مصادقة
• S3Scanner — أداة CLI لتعداد الـ Buckets، بتجرّب تباديل مختلفة من الأسماء وبترجّع حالة عام/خاص/متاح

04الاستطلاع عبر API

طريقتان للتفاعل مع AWS

• Web Console (GUI): واجهة إدارة بالمتصفح، محتاجة اسم مستخدم + كلمة مرور + MFA
• AWS CLI (API برمجي): وصول سطر أوامر لكل خدمات AWS، محتاج Access Key ID + Secret Access Key

aws configure --profile attacker
AWS Access Key ID: AKIA...
AWS Secret Access Key: ...
Default region: us-east-1

aws --profile attacker sts get-caller-identity
# {
#   "Account": "123456789012",
#   "UserId": "AIDAXXXXXXX",
#   "Arn": "arn:aws:iam::123...:user/attacker"
# }

AMIs العامة — كنز استخباراتي

• AMI = Amazon Machine Image، قالب جهاز افتراضي لإطلاق EC2 instances. المؤسسات بتنشئ AMIs مخصّصة ببرامج وإعدادات مثبّتة مسبقًا

aws --profile attacker ec2 describe-images \
  --filters 'Name=name,Values=*badglitch*' --owners self amazon

aws ec2 describe-images --executable-users all \
  --filters 'Name=name,Values=*company*'

# OwnerId: 123456789012  ← Account ID الهدف!
# Name: badglitch-web-prod-2024

# بعد معرفة الـ Account ID:
aws ec2 describe-snapshots --owner-ids 
aws rds describe-db-snapshots --snapshot-type public

Snapshots الـ EBS نسخ احتياطية لأقراص كاملة — Public EBS snapshot يعني أي حد يقدر ينشئ Volume منه ويوصّله. Snapshots الـ RDS نسخ قاعدة بيانات كاملة في لحظة معيّنة — Public RDS snapshot يعني أي حد يقدر يسترجع قاعدة بيانات منه.

05الحصول على Account ID عبر S3

الفكرة الجوهرية

الهدف: اكتشاف Account ID الخاص بـ AWS بتاع الهدف من غير أي وصول مباشر. الحيلة: شروط IAM policy تقدر تتحقّق من Account ID مالك المورد — وAWS بيُقيِّم الشرط ده قبل منح الوصول. استجابة السماح/الرفض بتكشف هل الشرط كان صح أو غلط.

06تعداد مستخدمي وأدوار IAM

كيف يسرّب تحقّق IAM principal البيانات

AWS بيتحقّق من صحة IAM principals قبل حفظ سياسات الموارد. المهاجم بينشئ Resource policy بتمنح وصول لـ ARN مستخدم مُخمَّن — لو الـ Policy اتحفظت بنجاح، المستخدم ده موجود فعلًا في الحساب الهدف؛ لو ظهر خطأ "Invalid principal"، المستخدم مش موجود. ده عمليًا تعداد Brute-force عبر استجابات الـ API — بدون أي محاولات تسجيل دخول، فمفيش Lockouts أبدًا.

أسماء IAM شائعة للتجربة

• عامة عالية القيمة: admin، administrator، root، devops، developer، cloudadmin
• sysadmin، backup، security، auditor، support، helpdesk
• cicd، jenkins، terraform، ansible، packer، github-actions
• billing، finance، readonly، monitor، loganalytics
• أنماط خاصة بالمؤسسة: firstname.lastname، f.lastname، company-admin

تعداد الأدوار (Roles) — أهداف أعلى قيمة

الأدوار غالبًا عندها صلاحيات أعلى من المستخدمين — مصمَّمة للخدمات والتطبيقات والوصول عبر الحسابات، وغالبًا بتشمل صلاحيات بمستوى أدمن. نفس تقنية التحقّق بتنطبق: تخمين ARN الدور في Resource policy، وAWS بيتحقّق هل الدور موجود فعلًا. أسماء أدوار مستهدَفة: Admin، Backup، SecurityAudit، PowerUser، DevOps، CICD، CrossAccount، Lambda-Exec.

07صلاحيات IAM وتحليل السياسات

تقييم بيانات اعتماد مخترَقة

أول أمر لازم تنفّذه مع بيانات اعتماد مخترَقة: aws sts get-caller-identity — بيكشف Account ID، UserID، وARN الكامل. مثال: arn:aws:iam::123456789:user/support/clouddesk-plove — المسار "/support/" بيلمّح لغرض الحساب، وحتى عادات التسمية بتكشف الصلاحيات المحتملة.

كيف تُورَّث الصلاحيات في IAM

1. سياسات مضمَّنة (Inline): مدمجة مباشرة في المستخدم — خاصة بهوية معيّنة
2. سياسات مُدارة مرفقة: سياسات مستقلة مربوطة مباشرة بالمستخدم
3. سياسات المجموعات: المستخدم بيرث كل صلاحيات كل مجموعة هو عضو فيها — وده غالبًا بيتم تجاهله وبيكون واسع جدًا

aws iam list-groups-for-user --user-name clouddesk-plove
# GroupName: support

aws iam list-attached-group-policies --group-name support
# SupportUser (AWS Managed Policy)

aws iam get-policy-version \
  --policy-arn arn:aws:iam::aws:policy/SupportUser --version-id v8
# يعرض كل الأفعال المسموحة!

08تعداد موارد IAM

البداية بملخص الحساب

aws iam get-account-summary بيرجّع أعداد عامة وإعدادات: عدد المستخدمين والمجموعات والأدوار والسياسات، حالة أجهزة MFA (هل Root محمي بـ MFA؟)، قوة سياسة كلمة المرور، وعدد Instance profiles.

سرد كل هويات IAM

aws iam list-users > users.json
aws iam list-groups > groups.json
aws iam list-roles > roles.json
aws iam list-policies --scope Local > policies.json

# الخطوة الأقوى — كل حاجة في استدعاء واحد:
aws iam get-account-authorization-details > full_iam_dump.json

• ابحث عن "admin" جوه اسم المستخدم → غالبًا مميَّز
• مسارات غير معتادة ("/service/"، "/cross-account/")
• حسابات اتعملت حديثًا

09معالجة البيانات بـ JMESPath

ليه JMESPath مهم

AWS CLI بيرجّع البيانات بصيغة JSON — غالبًا ضخمة جدًا، مئات أو آلاف الأوبجكتس في الاستجابة الواحدة. JMESPath لغة استعلام مخصّصة لمستندات JSON، مدمجة في AWS CLI عبر --query لفلترة وإعادة تشكيل البيانات من جهة العميل.

# استخراج كل أسماء المستخدمين:
aws iam get-account-authorization-details \
  --query 'UserDetailList[].UserName'

# إيجاد المستخدمين المرتبطين بـ admin:
aws iam get-account-authorization-details \
  --query 'UserDetailList[?contains(UserName,`admin`)].UserName'
# النتيجة: ["admin", "cloudadmin"]

# المستخدمين مع السياسات المرفقة بيهم:
aws iam get-account-authorization-details \
  --query 'UserDetailList[].[UserName,AttachedManagedPolicies[].PolicyName]'

# معالجة ملفات JSON محفوظة محليًا:
jp -f full_iam_dump.json 'expression'

10التعداد الآلي بـ Pacu

ما هو Pacu؟

• إطار استغلال AWS مفتوح المصدر، طوّرته Rhino Security Labs مخصّص لتقييمات AWS
• منظَّم في موديولات تستهدف خدمات AWS محدَّدة، مبني على جلسات (كل تقييم بيتخزّن منفصل)
• بيستورد بروفايلات AWS CLI الموجودة، وقاعدة بيانات داخلية بتخزّن كل البيانات المُجمَّعة

python3 pacu.py
Pacu (v1.x) - Main Menu

Pacu (No Session) > new_session
assessment1

Pacu (assessment1) > import_keys clouddesk

Pacu (assessment1) > run iam__enum_users_roles_policies_groups
[*] Enumerating IAM users...
[*] 14 users found, 8 roles found...

Pacu (assessment1) > data iam
# يعرض كل بيانات IAM المُجمَّعة!

يدوي مقابل آلي

--تحليل النتائج ومسارات التصعيد

البيانات الخام مجرد بداية — القيمة الحقيقية في التحليل. بعد أي تعداد (يدوي أو آلي)، ركّز على:

• مستخدمين فيهم "admin" في الاسم — غالبًا صلاحيات عالية
• مجموعات مرفق بيها سياسات قوية
• صلاحيات Wildcard (Action: '*'، Resource: '*')
• سياسات بتسمح بـ iam:CreateUser، iam:AttachUserPolicy، iam:AddUserToGroup

مسارات تصعيد شائعة في AWS

• إضافة نفسك لمجموعة أدمن
• إنشاء Access Keys لمستخدم أدمن
• انتحال دور (Role) مميَّز عبر sts:AssumeRole
• استغلال شروط وصول قائمة على التاغات (Tags) مفرطة في السماح

--Cheat Sheet مرجعي

nslookup -type=NS 
nslookup 
nslookup 
whois  | grep -i 'amazon\|aws'
gobuster dns -d  -w wordlist.txt
curl https://.s3.amazonaws.com/

aws configure --profile attacker
aws --profile attacker sts get-caller-identity
aws ec2 describe-images --executable-users all --filters 'Name=name,Values=*company*'
aws ec2 describe-snapshots --owner-ids 
aws iam get-account-summary
aws iam get-account-authorization-details > full_iam_dump.json

--query 'UserDetailList[].UserName'
--query 'UserDetailList[?contains(UserName,`admin`)].UserName'
--query 'UserDetailList[].[UserName,GroupList[].GroupName]'
jp -f full_iam_dump.json 'expression'

python3 pacu.py
new_session assessment1
import_keys 
run iam__enum_users_roles_policies_groups
data iam

الخلاصة العامة للموديول

الموديول ده غطّى تعداد بنية AWS السحابية من اسم دومين واحد بدون أي وصول، مرورًا باستغلال سلوك IAM كـ Oracle، ووصولًا لتعداد وتحليل صلاحيات IAM الكامل يدويًا وآليًا عبر JMESPath وPacu.

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

نهاية نوتس الموديول الثاني والعشرين — Enumerating AWS Cloud Infrastructure