Cyber Dojo

إمتى آخر مرة فتحت الـ Incident Response Playbook عندك؟
عارف، السؤال شكله بسيط… بس ورا الجملة دي في فجوة كبيرة جدًا بين الـ Detection و الـ Response في معظم الـ SOCs 💣

🧠 فكرة الـ Playbook بقت كلمة مطاطة في الـ Cybersecurity
يعني لو سألت مهندس، هيقولك SOAR automation
ولو كلمت مدير أمن معلومات، هيتخيل ملف PDF 180 صفحة اتكلف عليه 200 ألف دولار
ولو سألت Analyst في الـ SOC… ممكن يقصد أي حاجة ما بين الاتنين 🤷‍♂️

💡 بس هل حد فعليًا بيراجع الـ Playbook قبل ما يكتب Detection جديدة؟
يعني الـ Analyst المفروض يعمل إيه لما الـ Alert تضرب؟
يروح فين؟ يسأل مين؟ يعلق فين؟ ياخد Action ولا يستنى Approval؟
دي كلها أسئلة Detection Engineer المفروض يكون جاوبها قبل ما الـ Rule تتـDeploy أصلاً 🎯

📌 هنا بدأت فكرة “Rewriting the Playbook”
مش مجرد ملف compliance يتقفل ويتنسي، لكن approach تاني خالص:
✅ Detection-Driven Incident Response
يعني كل Rule لازم يكون حواليها Response Plan واضحة
والـ Response Plan ترتبط بـ Runbook واضح
والـ Runbook يبقى متقسم حسب كل Customer أو Environment
وكل دا يتحط جوه Wiki أو يتربط جوه التذكرة (Sentinel, Splunk, XSOAR…)

🔷 هنا طلعت فكرة جميلة اسمها: Incident Response Defense Diamond™
وده تقسيم رباعي جميل لأي Playbook فعّال:

١. Compliance Layer: ملفات ضخمة بتريح الـ Auditors، بس ملهاش علاقة بالواقع
٢. High-Level Procedures: إيه السياسات العامة للرد على Phishing أو Ransomware أو ATO
٣. Detection Response Plan: خطوات الـ Analyst في التحقيق والتحليل
٤. Runbooks: خطوات تفصيلية جدًا لأي Tool أو Environment (بما فيهم SOAR Bots أو AI Agents)

💥 بس فين الفرق؟
الفرق إن كل Detection Rule لازم تتولد معاها Response Plan
يعني مش بنبني Rule ونسلمها وخلاص…
إحنا بنبني معها خبرة، توصية، وAction واضح 🔧

زي:
- راجع ASN للـ IP
- شوف الـ User في UBA
- اعمل revoke للـ session (برابط مباشر للـ runbook)

🤖 وده بيدينا شوية حاجات جامدة جدًا:
- الـ Analyst بيعرف يشتغل أسرع
- الـ Runbooks بتتراجع وتتحدث حسب التجربة
- التيم كله بيشارك في التحسين
- كل Task repetitive بتتسجل وبالتالي تـAutomate

🧩 والأهم؟
إن الـ Detection بقى مرتبط فعليًا بالـ Incident Response
وبقى عندك Process واضح للـ Analyst والـ Platform Engineer
مش محتاج تتخانق على Approval ولا تستنى حد يقولك "إعمل إيه"

📣 خلاصة الكلام:
الـ Detection Engineer مش دوره يطلع alert وخلاص
ده حلقة الوصل بين CTI و Incident Response و SOC analysis
هو اللي بيحوّل الـ alert لخطة فعلية، مش مجرد log في SIEM

Reference: https://medium.com/detect-fyi/re-writing-the-playbook-a-detection-driven-approach-to-incident-response-5269e2eb33ca

🚀 ابدأ رحلتك كمحلل SOC محترف واستعد لتكون جزء من الدفاع الأمامي ضد التهديدات الإلكترونية!
اضغط هنا لمزيد من التفاصيل عن الSOC Analyst Bootcamp:
https://cyber-dojo.co/bundles/soc-analyst-bootcamp/
اضغط هنا لمزيد من التفاصيل عن Digital Forensics and Incident Response (DFIR) Bootcamp:
https://cyber-dojo.co/bundles/dfir-bootcamp/
للحجز والاستفسار: كلمنا فورًا عبر الواتساب:
https://api.whatsapp.com/message/EKDS6MXZOI3IO1

الSpoofed Email Injection — ازاي الهاكرز بيضحكوا على الـ Email Gateways؟✉️

في عالم البريد الإلكتروني، دايمًا كنا فاكرين إن أي إيميل جاي من دومين محترم (زي Microsoft أو Bank.com) يبقى أكيد جايلنا من سيرفر رسمي… صح؟
غلط جدًا.

اللي بتوضحه الصورة فوق إن الهجوم مش محتاج اختراق متطور… ده مجرد SMTP abuse كلاسيكي جدًا.

تعال نشرح اللي بيحصل خطوة بخطوة:

🧩 1. الطريقة الشرعية — MUA → MTA → MTA → MUA

في الحالة الطبيعية، الـ MUA (Mail User Agent) زي Outlook أو Thunderbird، بيبعت الرسالة للـ MTA (Mail Transfer Agent) الأول.
الـ MTA ده بيتأكد إن الإيميل جاي من يوزر شرعي… يطلب Username/Password… وميعديش أي رسالة من غير Login.

بعد كده، الرسالة بتسافر عبر الإنترنت لحد ما توصل للـ MTA المستقبل… ومنه للـ MUA بتاع المستلم.
كل ده بيكون في مسار متراقب ومتسجل في الـ headers.

🧨 2. الطريقة الهجومية — Attacker → MTA مباشرة

المهاجم هنا مش محتاج يبعت من MUA أصلاً.
هو بيروح على طول للـ MTA المستلم (Border MTA)… و"يحُقن" رسالة بالإيد فيها
From: [email protected] أو From: [email protected]
ببساطة… بيكتب عنوان "FROM:" مزيف جوه جسم الرسالة (SMTP DATA).

لو الـ receiving MTA مش مفعل فيه SPF أو DKIM أو DMARC أو حتى basic source verification…
هيسمح بدخول الرسالة كأنها جاية من مصدر شرعي تمامًا!

💥 ليه الخطر ده كبير؟

لأن SMTP مبني من أيام ما كان الإنترنت فيه "ثقة متبادلة" بين السيرفرات.
يعني ببساطة، أي سيرفر يقدر يكلم أي سيرفر تاني ويقول له:
"أنا gmail.com… صدقني."
ولو السيرفر التاني مش بيشك أو بيعمل verify — الرسالة تدخل بكل بساطة!

🎓 الدروس المستفادة لأي SOC أو Email Security Team:

✅ لازم تكون SPF و DKIM و DMARC مش بس موجودة… لكن enforced بجد
✅ لازم تعمل تحليل يدوي لأي إيميل غريب — especially الـ headers
✅ لازم الـ border MTA ما يثقش في أي SMTP connection إلا من sources معروفة
✅ لازم يكون في Detection Rules جوه SIEM بتقارن بين الـ header و الـ envelope
✅ لازم تراجع كل الـ “Received” hops… وتشوف أول IP دخل الرسالة منين

💬 مثال واقعي:

إيميل من "[email protected]
" جه لمدير مالي، بيطلب منه يحول مبلغ لحساب خارجي
شكل الرسالة نظيف، Signatures تمام…
بس الـ header بيقول إن الرسالة جاية من VPS في أوكرانيا،
ومفيش أي DKIM signature أصلاً!

🔥 الخلاصة:
مش أي حاجة مكتوب فيها “from: HR Department” تبقى جاية من HR بجد!
والموضوع بسيط جدًا في التنفيذ، ومميت جدًا لو دخل على موظف مش واخد باله!

🚀 ابدأ رحلتك كمحلل SOC محترف واستعد لتكون جزء من الدفاع الأمامي ضد التهديدات الإلكترونية!
اضغط هنا لمزيد من التفاصيل عن الSOC Analyst Bootcamp:
https://cyber-dojo.co/bundles/soc-analyst-bootcamp/
اضغط هنا لمزيد من التفاصيل عن Digital Forensics and Incident Response (DFIR) Bootcamp:
https://cyber-dojo.co/bundles/dfir-bootcamp/
للحجز والاستفسار: كلمنا فورًا عبر الواتساب:
https://api.whatsapp.com/message/EKDS6MXZOI3IO1

من مجرد Click واحدة... حصل أخطر اختراق استمر تقريبًا شهرين! 🐍

📅 القضية دي من تقارير September 2025 اللي اتنشرت في DFIR Labs، وبصراحة، هي كنز تعليمي لأي حد في Detection Engineering، Incident Response، أو حتى Threat Intelligence.

🧵 البداية كانت JavaScript متشبه في “نموذج ضرائب” نزل MSI وشغل Brute Ratel C4 عبر rundll32—وبعدين حصل injection لـLatrodectus جوا explorer.exe وابتدى C2 عبر BackConnect.

⚡ المهاجمين لعبوا بـLatrodectus وBrute Ratel وCobalt Strike وBackConnect ومعاهم .NET backdoor؛ جمعوا credentials من LSASS وVeeam والبراوزر وحتى ملف unattend.xml؛ وبعد 20 يوم عملوا Exfiltration بـRclone على FTP لمدة تقريبًا 10 ساعات؛ وكل ده من غير ما يوصلوا لـRansomware.

🧩 الـInitial Access كان عبر JS obfuscation يجرّك لتحميل MSI؛ الـExecution استخدم DLL via rundll32؛ والـPersistence كان Run Key وScheduled Task؛ والـPrivilege Escalation جه من Secondary Logon وrunas، ومعاه محاولة Zerologon (CVE-2020-1472).

🔎 سلوك الـDiscovery شمل ipconfig وsysteminfo وnltest وdnscmd وAdFind؛ وبعدها Lateral Movement بـPsExec/WMIC وRDP؛ ومع كل خطوة تلاقي beacons بتتبدّل بين Cobalt Strike وBrute Ratel حسب المرحلة.

🌐 الـC2 كان intermittent على مدار ~60 يوم—مرات VNC/BackConnect، ومرات HTTP/HTTPS beacons، ومرات تغيير domains عشان التخفي.

🧳 في اليوم العشرين اتنفذ Rclone (rename باسم نظامي) مع سكربتات start.vbs/run.bat واستبعاد امتدادات علشان نقل نظيف؛ وده خرج ببيانات كثيرة على FTP ثم رجعوا يختفوا ويظهروا.

🎯 نقرة واحدة على JavaScript “شكله آمن” تقدر تفتح لك Kill Chain كاملة—الموضوع مش أداة واحدة، ده Playbook متكامل بيتحرك على هدوء وStages طويلة.

دروس 🧰 إللي يهم الـSOC فعلاً:

1️⃣ امنع تخزين الـAdmin creds في unattend.xml أو سكربتات الـprovisioning—استخدم secrets management واعمل hunting دوري على بقايا الإعدادات.
2️⃣ راقب MSI downloads غير المألوفة + أي rundll32 ينادي DLL من ‎%ProgramData%‎/‎%ALLUSERSPROFILE%‎—دي signature حلوة لـBrute Ratel/Latrodectus.
3️⃣ فعّل Sysmon/EDR telemetry لعمليات CreateRemoteThread وProcess Injection (EID 8) وسلسلة parent-child الغريبة (rundll32 → sihost/spoolsv).
4️⃣ اربط Security 4624/4672 مع Service Control وSecondary Logon علشان تصيّد runas وتبديل السياق لحسابات Privileged.
5️⃣ حط detections لاستخدام AdFind واسع، وPsExec أول مرة من غير ‎-accepteula‎ ثم إعادة المحاولة—سلوك بشري متكرر.
6️⃣ راقب أنماط Cobalt Strike الشائعة (Named Pipes/URI مثل ‎/vodeo/*‎) وبدّل بين Network + Memory detections بدل الاعتماد على واحد.

✅ الهجمة دي بتثبت إن الـTradecraft بقى “متعدد الإطارات”: Initial Access بسيط، ثم C2 هادئ، ثم Privilege & Movement بالقطّارة، ثم Exfiltration محسوب—ولو ما عندكش رؤية end-to-end وإدارة مخارج صارمة، هتكتشف متأخر.

🚀 ابدأ رحلتك كمحلل SOC محترف واستعد لتكون جزء من الدفاع الأمامي ضد التهديدات الإلكترونية!
اضغط هنا لمزيد من التفاصيل عن الSOC Analyst Bootcamp:
https://cyber-dojo.co/bundles/soc-analyst-bootcamp/
اضغط هنا لمزيد من التفاصيل عن Digital Forensics and Incident Response (DFIR) Bootcamp:
https://cyber-dojo.co/bundles/dfir-bootcamp/
للحجز والاستفسار: كلمنا فورًا عبر الواتساب:
https://api.whatsapp.com/message/EKDS6MXZOI3IO1