https://www.facebook.com/104993532403093/

Cyber Dojo, Cairo (2026)

25/01/2026

ازاي تستخدم التحليل المنهجي (Structured Analysis) في تحقيق الحوادث داخل الـ SOC؟ تعال نحكي سيناريو حقيقي من قلب الشغل 👇

📩 في بداية الشيفت، Analyst استقبل إيميل من يوزر بيقول إنه شاف على جهازه رسالة مرعبة بتقول إن جهازه مصاب بـ "pornographic spyware"، مع شاشة سودا، كود بيجري في CLI، وصوت بيقوله يتصل بـ Microsoft فورًا. الجهاز اتحبس، واليوزر اضطر يعمل Hard Reboot علشان يخرج من الموقف.

🔎 أول خطوة، جمعنا الأدلة:

من إيميل اليوزر، عرفنا إنه:

- الشاشة اتحبست تمامًا.
- ظهر تحذير صوتي بيقوله يتصل فورًا.
- الكود الظاهر في CLI كان شكله غريب وغير مفهوم.
- الرسالة بتدعّي إصابة الجهاز ببرمجيات تجسس إباحية وسرقة بيانات.

ومن Suricata logs:

- اليوزر اتعمله redirect من موقع اسمه freesafesoft[.]com لموقع تاني اسمه secure-serve[.]services فيه صفحة مشبوهة.
- الصفحة دي حملت MP3 files، اللي غالبًا منها جه الصوت اللي سمعه اليوزر.
- الصفحة كانت بتتحمل عبر HTTP، مش HTTPS، يعني فيه احتمالية MitM أو تعديل في الـ Content.

ومن Windows Logs:

- مفيش أي عملية suspicious اتنفذت.
- الWindows Defender ما اكتشفش أي تهديد.
- مفيش PowerShell أو ملفات Temp بتشتغل أو Indicators بتاعة malware ex*****on.

ومن التقرير:

- الجهاز اشتغل طبيعي بعد الReboot بدون أي مشكلة.

🧠 هنا بدأنا نستخدم أسلوب التحليل المقارن ACH - Analysis of Competing Hypotheses، وطرحنا ٦ احتمالات:

1- الRansomware فعلي
2- الMalware غير تشفيري (non-ransomware)
3- صفحة ويب خادعة بتعمل Scareware (Fake AV)
4- الMitM Attack حقن الصفحة
5- رسالة حقيقية من النظام
6- بلاغ مزيف من اليوزر

💡 لما بدأنا نحلل كل دليل مقابل كل فرضية، لقينا إن السيناريو الوحيد اللي بيطابق كل الدلائل بدون تعارض هو إن اليوزر فعلاً اتعرض لـ صفحة ويب بتقلد تحذيرات Microsoft وبتستخدم Redirect + صوت مسجل + CLI مزيف + تصميم بصري مخادع علشان تخوفه وتخليه يتصل برقم دعم وهمي.

السيناريو ده اتدعم بأكتر من نقطة:

- ما فيش أي evidence على إصابة فعلية.
- ما فيش ex*****on غريب.
- الصفحة حملت MP3 بصيغة مباشرة من HTTP.
- حصل redirect واضح لموقع غير موثوق.
- المشكلة اتحلت فورًا بعد Reboot، وده مستحيل يحصل مع ransomware فعلي.

✋ أما باقي الفرضيات زي وجود فيروس حقيقي أو هجوم MitM، فهي أقل تطابقًا مع الأدلة، وبعضها تم استبعاده تمامًا (زي فرضية إن الرسالة كانت حقيقية – لأن Windows مش بيبعت تحذيرات صوتية، ولا بيطلب تتصل خلال ٥ دقايق).

📢 التوصية النهائية:

التحليل يؤكد بنسبة عالية إن الحادثة كانت نتيجة Fake AV Scare Page، ظهرت بسبب redirect من موقع غير موثوق، وتم استغلالها بصريًا وصوتيًا لإيهام المستخدم بوجود تهديد. لا يوجد أي دليل على اختراق فعلي أو Malware. نوصي بزيادة الوعي الأمني للمستخدمين، وتطبيق فلترة HTTP/URL على الشبكة لمنع الوصول للمصادر المشبوهة.

🚀 ابدأ رحلتك كمحلل 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

24/01/2026

النهاردة هنكلمكم عن واحدة من أهم المهارات اللي بتفصل الـ Analyst العادي عن الـ Threat Hunter التقيل: Alert Triage & Prioritization ✴️

💬 إنت أول ما تبدأ شفتك، تفتح TheHive وتلاقي الدنيا مليانة Alerts من Suricata IDS. 8 Alerts كده بيستنّوك، لكن السؤال الحقيقي: فين الكارثة؟ فين اللي فعلاً محتاج تدخل حالاً؟ هنا بقى بييجي دور Kill Chain والتفكير التحليلي.

⚡ أول حاجة بتعملها إنك تربط كل Alert بالمرحلة بتاعته في الKill Chain:

- تحميل EXE؟ ممكن يبقى Installation
- استخدام FTP؟ ده ممكن يبقى Exfiltration أو Installation
- الAlert عن IsDebuggerPresent؟ احتمال يبقى محاولة Malware يعرف لو بيتحلل

📌 يعني مجرد ما تشوف Alert ما تسكتش، لازم تسأل:

- "ده فين في الKill Chain؟"
- "مين المصدر؟"
- "مين الضحية؟"
- "إيه الContext حوالين الـ Traffic؟"

📂 وعلشان كده، اللاب ده استخدم حاجة جامدة جدًا: Moloch (اللي اسمه دلوقتي Arkime). ده Full PCAP Engine بيخليك تشوف كل حاجة بالبايت — من أول Login بـ FTP لحد Payload فيه Social Security Numbers بيتعمله exfil.

🔥 لما لاقينا Alert لـ FTP، وشفنا في Moloch إن الحساب user_1 بيبعت ملف اسمه 04072019_130741text_data.txt، اتأكدنا إن في حد بيجهّز Data علشان يخرجها من الشبكة. والمصيبة الأكبر؟ كان فيه كمان POST Request بـ Python User-Agent بيبعت Credit Card Numbers! يعني Exfiltration confirmed 😱

📍 وبكده، التحليل خادنا من مجرد Alert لـ Full-blown Incident – واستعملنا:

- 🧩الCommunity ID عشان نربط الـ Alerts بـ PCAPs
- 🔍 الMoloch علشان نشوف الPayloads ونستخرج الMD5
- 📌 الTheHive علشان ندمج الـ Alerts المرتبطة ونفتح Case
- ⚠️ لكن مش كل Alert بيكون Malicious!

👀 لقينا Alert على GoogleUpdateSetup.exe نازل من gvt1.com، وده legitimate domain بتاع Google. بعد Whois check وVirusTotal، قررنا نـ “Mark as Read” لإنه False Positive – ودي نقطة مهمة جدًا: الفرق بين suspicious وmalicious بيعتمد على السياق.

🧠 البوست ده مش بس عن أدوات، ده عن "Thinking like an Analyst":

- ما تبصش للAlert كأنه ثابت، بصله كجزء من Story
- اربط الـIndicators ببعض وشوف الصورة الكاملة
- استفيد من الـPCAPs عشان تفهم كل Byte بيعدي

📚 استخدم الـKill Chain كخريطة، والPCAP كدليل، وTheHive كحامل قضية.

💡 في الآخر، الAnalyst الشاطر مش اللي بيقفل Alert، لكن اللي بيحوّل الـNoise لمعلومة واضحة، ومن alert عشوائي لـIncident حقيقي.

ابدأ رحلتك كمحلل 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

12/12/2025

أول حاجة لازم تبقى فاهمها إن “Suspicious Process” مش معناها Malware 100%… هي معناها “فيه ريحة دخان… دور على النار” 🔥🕵️‍♂️
ثاني نقطة إن شغل الـIncident Response الحقيقي مش “لقطة واحدة”… هو correlation بين process + parent + path + command line + network + persistence artifacts 💡

يا ترى إيه اللي يخلي Process يرن جرس الإنذار؟ 🚨

أول علامة هي إن الـprocess جديد على الجهاز أو “مش مألوف” في الـbaseline بتاع البيئة بتاعتك 🧩
ثاني علامة هي إن الاسم شكله random أو pseudo-random زي fRVWQDD أو wXexXHNeSMpQKiiZ… النوع ده بيكون معمول عشان يكسر الـpattern matching ويفلت من الـtriage السريع 🎭
ثالث علامة هي إن برنامج معروف بس شغال من path غريب… يعني svchost.exe بس مش من System32، أو powershell.exe بس طالع من Temp… هنا بتسأل نفسك: “هو نفس الـbinary ولا impersonation؟” 🧠

أقوى سؤال دايمًا: مين الـParent؟ 👨‍👦
أبسط مثال يخلّي analyst يتوتر: lsass.exe يطلع cmd.exe… دي علاقة abnormal جدًا وغالبًا معناها exploitation / injection / token abuse أو سيناريو مش طبيعي في الـWindows normal behavior ⚠️
أصعب من كده كمان: إن العلاقة نفسها تكون “منطقياً غلط” حتى لو الاتنين Legit… زي Office يطلع PowerShell يطلع mshta يطلع rundll32… هنا أنت دخلت فيلم LOLBAS كامل 🎬

أهم حتة الناس بتفوتها: Command Line 🧾
أول ما تشوف Base64 أو -EncodedCommand خصوصًا مع PowerShell… متفترضش فورًا إنه malicious… بس افترض إنه لازم يتفك ويتفهم 🧨
أغلب الـattackers بيحبوا EncodedCommand عشان يهربوا من ترك ملفات .ps1 على الديسك… يعني أقل artifacts على الـdisk، وأكتر شغل “in-memory” 🎯

بعد ما تحدد Process مش مريح… متقفش عنده ✋
لازم تعمل pivoting 🔁
يعني تسأل: هو اتولد إمتى؟ اتنفّذ كام مرة؟ ظهر على كام جهاز؟ مرتبط بـuser مين؟ وبيكلم مين على الشبكة؟

وهنا ييجي دور الـNetwork View 🌐
لما تربط process بـconnections تكتشف الدنيا:
زي إن Notepad يعمل outbound connections على port 80/443… دي مش “غرابة وخلاص”… دي “ليه أصلاً؟” 😅
أو تلاقي long-running HTTPS sessions، أو beaconing pattern (اتصالات صغيرة متكررة بفواصل شبه ثابتة)… ده signature سلوكي لـC2 أكتر من إنه مجرد browsing عادي 📡
ولو فيه lateral movement… فطبيعي تشوف حركة على SMB ports (135-139 و445)… بس الفكرة إنك تربطها بالسياق: مين اللي عملها؟ منين؟ وإمتى؟ 🧭

وبعدين تيجي منطقة الـPersistence 🧱
خد بالك من Services: أي خدمة باسم random، أو description فاضية، أو PathName داخل Temp… دي classic persistence technique 🛠️
خد بالك من Scheduled Tasks: ساعات attacker يسمّيها باسم software مشهور بس غلط إملائي بسيط… علشان عينك تعدّيها 👀
خد بالك من Registry Run keys: لأن الـautostart entries دي “مفتاح رجوع” للمهاجم بعد reboot 🔑

🚀 ابدأ رحلتك كمحلل 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

27/10/2025

إمتى آخر مرة فتحت الـ 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

25/10/2025

النهارده هنتكلم عن واحدة من أخطر الهجمات اللي حصلت الفترة اللي فاتت على SharePoint – الثغرة CVE-2025-53770 أو زي ما ناس كتير بتسميها ToolShell 🛠️💥

🔹 أولًا، إيه اللي حصل؟
هجوم متطور جدًا بيستهدف سيرفرات Microsoft SharePoint on-prem – الثغرة كانت zero-day وبتسمح بتنفيذ أوامر عن بُعد من غير ما الهاكر يقدّم credentials! يعني تخيّل RCE بدون Authentication! Microsoft طلعت Patch يوم 21 يوليو لكن الهجمات بدأت قبل كده بكتير.

🔹 ثانيًا، مين اللي ورا الهجوم؟
التقارير بتحكي عن involvement مباشر من تلات مجموعات APT مرتبطة بالصين 🇨🇳: Budworm (Linen Typhoon)، Sheathminer (Violet Typhoon)، وStorm-2603 (Warlock ransomware operators).

لكن الكارثة الأكبر إن Symantec أثبتت إن في أكتر من مجموعة صينية استخدمت ToolShell، وعلى أربع قارات كمان: أميركا الجنوبية، أفريقيا، الشرق الأوسط، وحتى أميركا نفسها.

🔹 ثالثًا، الهجوم كان ماشي ازاي؟
الهجوم مش بسيط. بيبدأ باستغلال الثغرة عشان ينزلوا Web Shell على SharePoint server، وبعدها تبدأ الـ chain:
- تحميل backdoor مكتوب بلغة Go اسمه Zingdoor
- تشغيل ShadowPad Trojan كـ modular RAT
- استخدام loader مكتوب بـ Rust اسمه KrustyLoader لتحميل Sliver C2 framework
- استخدام أدوات legit زي BitDefender وTrend Micro في DLL sideloading
- Dump للـ credentials باستخدام أدوات زي ProcDump وMinidump وLsassDumper
- وPetitPotam كمان لعشان يـ spoof NTLM requests وتسهيل privilege escalation
- يعني حرفيًا textbook example لاستخدام كل TTP ممكن في MITRE ATT&CK 📚🧠

🔹 رابعًا، ليه الموضوع خطير فعلًا؟
لأنهم استخدموا أدوات open-source زي Revsocks وCertutil وGoGo Scanner عشان يـ evade الـ detection. وكمان 46% من البيئات اللي اتهاجمت اتحل فيها passwords! نسبة مرعبة مقارنة بـ 25% السنة اللي فاتت 😨

🔹 خامسًا، إيه اللي لازم كل SOC يعمله؟
- أول حاجة: Apply the Patch فورًا لو عندك SharePoint on-prem!
- ثاني حاجة: راجع logs بتاعتك من أول يوليو خصوصًا على الـ web servers
- ثالث حاجة: Monitor لـ DLL side-loading وسلوكيات غريبة حوالين Lsass
- رابع حاجة: Use behavior-based detection مش بس signature-based، لأن أغلب الأدوات هنا legit!
- خامس حاجة: راجع السياسات بتاعت privileged account usage – لأن lateral movement كان واضح جدًا هنا

🔹 وأخيرًا، إيه الدروس اللي نتعلمها؟ 📘

- الZero-days مش رفاهية… threat actors بيستغلوها فعليًا، بسرعة وباحترافية
- الـ detection لازم يبقى multi-layered: من EDR لـ NDR لـ UEBA
- مفيش أداة سحرية، لكن correlation هو سلاحك الحقيقي
- لازم يبقى فيه خطة استجابة حقيقية لما تلاقي Web Shell غريب في SharePoint
- الPassword hygiene بقت شيء لازم يبقى مدفوع بـ policy وaudit مستمر مش awareness بس
Reference: https://www.security.com/blog-post/toolshell-china-zingdoor

🚀 ابدأ رحلتك كمحلل 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

19/10/2025

عمرك سألت نفسك السؤال ده؟
❓"هو لو عندي Endpoint Data قوية، أنا كده تمام؟ ولا لازم Network Visibility كمان؟"
أو العكس…
❓"أنا شايف الدنيا كويس على مستوى الـ Network، بس مش قادر أجيب Logs من الـ Endpoints… ده كفاية؟"

🔥 الحقيقة؟ مفيش إجابة سهلة
دايمًا وجود Visibility من أكتر من Source هو الأفضل.
بس خلينا نحفر أكتر شوية ونتكلم بالسيناريوهات:

📌 أول سيناريو:
في Threat Hunting، لاحظت جهاز بيتكلم مع Domain مش معروف… مفيش عليه Intel، بس فجأة بعد الـ Connection الجهاز بدأ يتصرف بغرابة.
لو كل اللي عندك Network Logs بس؟ هتشوف الملف اللي نزل (مثلاً calc.exe)، بس هتحتاج تروح تحلله في Sandbox وتستنى...
⏳ وقت بيتاخد، وده بيدي Attacker مساحة يتحرك قبل ما تمسكه.

لكن
لو عندك Endpoint Visibility؟
💡 هتشوف الـ Process Creation
💡 مين شغّل الملف؟
💡 اشتغل بإيه Permissions؟
💡 كتب إيه في النظام؟
يعني هتوصل لحقيقة اللي حصل بسرعة الصاروخ.

📌 السيناريو التاني المؤلم:
الEDR عندك متسطب وشغال… بس Attacker دخل بـ Phishing Technique جديدة، والـ EDR ما اكتشفهوش!
وبعد ما دخل؟ قام طافي الـ Logging والـ Agent نفسه!
🚨 كده إنت فقدت عينيك على الجهاز ده تمامًا…
وهنا بقى السؤال:
هل تقدر تعتمد على Endpoint؟ لأ، ببساطة عشان الجهاز بقى Compromised وممكن يخدعك.
الحل؟
💡 الNetwork TAP أو NDR بيجمع الـ Traffic من برّا الجهاز.
يعني حتى لو الـ EDR مات…
الـ Network Logs تفضل معاك كدليل تاني.

👀 طيب تختار إيه لو لازم؟
📌 الـ Endpoint Logs دايمًا هتديك تفاصيل أكتر:
الProcess Trees
الCommand-lines
الRegistry Modifications
الFile Drops
الNetwork Connections من المصدر

بس
📌 الـ Network Logs هي Lifeline لما يحصل Bypass أو Tampering على الجهاز نفسه.

📚 الدروس المستفادة لأي SOC:
✅ اعرف إن الـ Attackers مش بيلعبوا بنص فرصة، فـ Visibility ناقصة = Blind Spot
✅ إياك تعتمد على Vendor يقولك "ده كفاية" من غير ما تفهم حدود كل Source
✅ الـ Defense in Depth مش بس Layers… دي كمان Data Sources
✅ لازم تشتغل على Aggregation، Correlation، وتعرف تـ Cross-validate بين الـ Network والـ Endpoint
✅ حدّد الـ Coverage Gaps عندك… واشتغل على تعويضها بالتدريج حسب الـ Budget والـ Risk Profile

🎯 في الآخر؟
مش الهدف تبقى عندك Data كتير…
الهدف إنك تكون شايف كل زاوية ممكن يستخبى فيها Attacker
ولما تحصل حاجة…
تكون أسرع واحد فاهم، مش آخر واحد عرف!

🚀 ابدأ رحلتك كمحلل 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

18/10/2025

ال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

09/10/2025

اخيرا و بعد طول انتظار تم فتح Round جديدة لـ SOC Analyst Bootcamp — والهدف إنك تبقى جاهز لسوق الشغل 100% وتتعامل مع تحديات الـ SOC اليومية بثقة 💼🔥

📚 محتوى الدورة يشمل:
1️⃣ الCybersecurity Foundations: هتكتسب المعرفة الفنية الأساسية عشان تبدأ مسيرتك في الأمن السيبراني. هتفهم إزاي التكنولوجيا بتشتغل عشان تقدر تهاجمها وتدافع عنها بفعالية.
2️⃣ تحضير GSEC - SEC401: دورة تأسيسية تعرّفك على أساسيات أمن المعلومات والحماية السيبرانية.
3️⃣ تحضير GSOC - SEC450: تجهزك للعمل بكفاءة داخل مراكز العمليات الأمنية (SOC)، مع مهارات كشف وتحليل التهديدات والاستجابة السريعة لها.
4️⃣ الSOC Level 1 Labs: تعلّم الأساسيات من خلال تحديات عملية، مراقبة الأمان، والتعامل مع الحوادث باستخدام TryHackMe.
5️⃣ ال SOC Analyst Learning Path من LetsDefend هتتعلّم مهارات تقنية متقدمة في مراقبة الأمان، الاستجابة للحوادث، إدارة الثغرات، والتحضير للحصول على شهادات معترف بها، مع محاكاة واقعية لتطبيق المعرفة.
6️⃣ الCyberDefenders SOC Analyst Tier 1: ابني مهاراتك الأساسية لمراقبة وتنبيه وتصعيد الإنذارات الأمنية: تحديد والاستجابة للحوادث الأمنية البسيطة و أساسيات اكتشاف البرمجيات الخبيثة والتحليل الجنائي على الأجهزة و إتقان الأدوات للتحقيق في الأنشطة المشبوهة وتسريبات البيانات و تعميق معرفتك بالتهديدات الشائعة وتقنيات الاستجابة المتقدمة.
7️⃣ الIBM QRadar Foundations: اتقن استخدام IBM QRadar SIEM للتحقيق في المخالفات، وتنفيذ تقارير مخصصة، واستغلال إمكانيات AQL.

المحاضرين 👥:
معاك خبراء من المجال يعني انت في أيد أمينة 👌

👨‍💻 الدورة تشمل:
- دروس مسجلة مسبقًا يمكنك الوصول لها في أي وقت يناسبك!
- جلسات لايف اونلاين تفاعلية مع المدرب، مرتين أسبوعيًا!
- جلسات One-to-One مع المدرب لحل أي تساؤلات، استفسارات، أو استعداد للانترفيو!
📅 مدة الدورة: 5.5 شهور

⚙️ التطبيق العملي:
🔹 أكتر من 80 معمل عملي يغطي سيناريوهات حقيقية زي الهجمات السيبرانية، تحليل البرمجيات الخبيثة، واكتشاف التهديدات.
🔹 مشروع الامتثال للأمان: تقييم الضوابط الأمنية لشركة وإعداد خطة شاملة لتحسينها (VPN & MFA).
🔹 مشروع SOC Analyst: تحليل وتنظيم 5 تنبيهات حرجة من نظام أمان، والعمل على تمرين Tabletop لتطوير مهاراتك في الاستجابة السريعة.

🎯 جاهز لسوق العمل:
✅ تجهيز كامل لامتحانات GSEC و GSOC بشهادات معترف بها عالميًا.
✅ بناء ملف شخصي قوي مع مشاريع عملية تجذب الشركات.
✅ اترفيوهات فرضية عشان تتأكد إنك جاهز تمامًا.

اضغط هنا لمزيد من التفاصيل عن الSOC Analyst Bootcamp:
https://cyber-dojo.co/bundles/soc-analyst-bootcamp/
⏰ احجز مكانك دلوقتي! كل يوم بيعدي الفرصة بتقل!
📩 للحجز والاستفسار: كلمنا فورًا عبر الواتساب عشان تحجز وتضمن مكانك في الدفعه الجاية 🚀
https://api.whatsapp.com/message/EKDS6MXZOI3IO1

01/10/2025

من مجرد 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

25/09/2025

كل حاجة بتبدأ من الـ log... لكن مش أي log!🎯

الـ log في حد ذاته مجرد شوية بيانات، ساعات بيكون structured، وساعات بيكون unstructured.
المعلومة مش مهمة بس في حد ذاتها، لكن في شكلها... في تنسيقها... في قدرتك تفهمها.
وهنا بيظهر أول تحدي: الـ parsing.

🧩 الـ Parsing هو أول خطوة بتحول الـ chaos لنظام.
- تخيل log بيجيلك كله في سطر واحد، وكأنك بتحاول تفهم مقال كامل مكتوب من غير فواصل أو علامات ترقيم.
- الـ SIEM لازم يفهم كل جزء في الـ log: العنوان، المصدر، الوجهة، البروتوكول... وإلا هيبقى مجرد text بارد بتقراه بعينك بس مش بعقلك.
- من غير parsing سليم، مفيش search قوي، مفيش correlation، ومفيش detection بمعناه الحقيقي.

🔍 لكن حتى بعد ما نفهم كل field، بيظهر سؤال أصعب... كل system بيسمي الحاجة بشكل مختلف؟
- واحد بيقول عليها "SRC"، واحد تاني بيقول "source_ip"، والتالت بيكتبها بالعربي!
- وده معناه إنك لو فضلت تكتب queries حسب كل log format، هتتجنن.

الحل؟ Normalization.
- وهي ببساطة توحيد اللغة. بدل ما كل واحد ينادي المعلومة باسم مختلف، كلهم يتفقوا على اسم واحد.
- بكده، تقدر تعمل query وحدة وتجيب logs من كل sources في نفس اللحظة.

🧠 طيب... بعد ما ظبطنا شكل البيانات... ليه منكتفيش بيها؟
- علشان البيانات الخام، مهما كانت structured، فقيرة من غير context.
وده بيخلينا ندخل على أقوى خطوة: Enrichment.

- في اللحظة اللي بتضيف فيها معلومات إضافية للـ log – زي الدولة اللي جاي منها الترافيك، أو نوع الـ user، أو التصنيف الأمني –
- إنت فعليًا بتبني خريطة استخباراتية جوه الـ SIEM.
- الـ log اللي كان مجرد record بقى دلوقتي asset غني يساعدك تاخد قرار.

📌 بس لسه في خطوة سحرية أخيرة... ودي اللي بتفصل المحترف عن الهاوي: Categorization.
- في عالم مليان logs، محتاج تصنف الحاجات المهمة تحت تاغز واضحة.
- مثلاً، تقدر تلم كل أنواع الـ login مهما كان شكلها أو مصدرها تحت تاغ واحد زي "logon".
- ده بيخلي الـ analyst يقدر يركز على "الحدث"، مش "الشكل".
- وفي لحظات، تقدر تجيب كل login attempts لأي user، من كل الأجهزة، من غير ما تعرف اسم كل log أو شكله.

🌐 النتيجة؟
- دلوقتي عندك log متحول من مجرد سطر عشوائي، لقطعة معلوماتية ذكية:
📌 Parsed
📌 Normalized
📌 Enriched
📌 Categorized

كل ده بيخلي الـ SIEM مش بس search engine للـ logs...
لكنه مخ استخباراتي شغال 24/7 بيجمع، ينظف، يفسر، ويوصللك المعلومة على طبق من ذهب 🧠✨

🔥 الـ detection الحقيقي مش بيبدأ وقت ما الـ alert يضرب، لكن بيبدأ من أول خطوة في بناء الـ pipeline الصح مافيش use case هيشتغل صح، من غير ما تكون الـ data صح.
ومفيش SOC قوي، من غير foundation قوي مبني على parsing, normalization, enrichment, و categorization.

🚀 ابدأ رحلتك كمحلل 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

Cyber Dojo

25/01/2026

24/01/2026

12/12/2025

27/10/2025

25/10/2025

19/10/2025

18/10/2025

09/10/2025

01/10/2025

25/09/2025

Address

Website

Alerts

Shortcuts

Share

Category