> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # محاكاة الهجمات لاختبار دفاعك: Atomic Red Team في مختبر معزول - URL: https://arabroot.io/articles/محاكاة-الهجمات-لاختبار-الكشف-atomic-red-team-في-مختبر-معزول/ - Published: 2026-10-28T13:58:43.000Z - Updated: 2026-10-28T14:59:17.000Z - Description: شغلنا أساليب مختارة من Atomic Red Team في حاوية معزولة، وتحققنا أي قاعدة كشف أطلقت، فظهرت فجوة ونجا السجل المركزي من محاولة المسح. - Author: فريق عرب رووت - Tags: الأدلة التقنية, الأمن السيبراني, Docker والحاويات, لينكس والسيرفرات, Atomic Red Team كتبت قواعد كشف جيدة في مقال [قواعد الكشف](https://arabroot.io/articles/%D9%82%D9%88%D8%A7%D8%B9%D8%AF-%D8%A7%D9%84%D9%83%D8%B4%D9%81-detection-rules-%D8%A8%D9%84%D8%BA%D8%A9-sigma-%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%84%D9%88%D9%83-%D8%A7%D9%84%D9%89-%D8%AA%D9%86%D8%A8%D9%8A%D9%87/)، وجمعت السجلات كما في [مقال السجلات](https://arabroot.io/articles/%D8%A7%D9%84%D8%B3%D8%AC%D9%84%D8%A7%D8%AA-%D8%A7%D9%84%D8%A7%D9%85%D9%86%D9%8A%D8%A9-logs-%D9%85%D8%A7%D8%B0%D8%A7-%D8%AA%D8%AC%D9%85%D8%B9-%D9%88%D9%85%D9%86-%D8%A7%D9%8A%D9%86-%D9%82%D8%A8%D9%84-soc/)، وبنيت مركز عمليات صغيراً. لوحة التحكم هادئة منذ أسابيع. والسؤال الذي يقف عنده كل فريق: هل الهدوء لأن شبكتك آمنة، أم لأن قواعدك عمياء عن الهجوم الذي يحدث الآن؟ ولا تستطيع أن تفرق بين الحالتين بالنظر إلى لوحة هادئة، فكلتاهما تبدو هكذا. الطريقة الوحيدة أن تنفذ سلوك المهاجم بنفسك، في بيئة مصرح بها معزولة، وترى هل تطلق قواعدك، ومتى، وأيها يفوت. وهذا ما يسمى التحقق من الكشف Detection Validation، أو محاكاة الخصم Adversary Emulation: لا تختبر هل تستطيع اختراق شيء، وإنما هل يراك دفاعك عندما يفعل غيرك. وأداة ذلك مكتبة [Atomic Red Team](https://www.atomicredteam.io/?ref=arabroot.io)، وهي تعريفات اختبار رسمية مفتوحة، كل اختبار أمر أو أمران مربوطان بأسلوب في [إطار MITRE ATT&CK](https://arabroot.io/articles/mitre-attack-%D9%83%D9%8A%D9%81-%D9%8A%D9%81%D9%83%D8%B1-%D8%A7%D9%84%D9%85%D9%87%D8%A7%D8%AC%D9%85-%D8%AE%D8%B7%D9%88%D8%A9-%D8%A8%D8%AE%D8%B7%D9%88%D8%A9/). وفي هذا المقال نشغل مجموعة مختارة منها ضد Container معزول، ونقيس أي أساليبها رأته قواعدنا، ونكشف فجوة في تغطيتنا، ونرى كيف ينجو السجل المركزي من محاولة المهاجم مسح أثره. 🛑 كل ما في هذا المقال يجري داخل Container معزول بلا شبكة، يحذف بعد الاختبار، ولا يمس شيئاً خارجها. ولا نكتب أي كود استغلال، فالأوامر التي نشغلها تعريفات اختبار رسمية منشورة وبسيطة (إنشاء حساب، كتابة ملف، مسح سجل)، الغرض منها قياس الكشف لا الاختراق. نفذ المحاكاة على مختبرك أنت فقط، بإذن مكتوب ونطاق واضح، ولا توجهها إلى أي نظام لا تملكه. [![](https://arabroot.io/content/images/2026/10/detection-rules-cover-cover.webp)دليلقواعد الكشف Detection Rules بلغة Sigma: من السلوك إلى تنبيهولدنا حركة اعتداء حقيقية الشكل، وحولنا قواعد SigmaHQ وقواعد كتبناها إلى SQL بمكتبة pySigma، فرأينا ما أصابت وما فاتها قاعدة بفلتر 404.](https://arabroot.io/articles/%D9%82%D9%88%D8%A7%D8%B9%D8%AF-%D8%A7%D9%84%D9%83%D8%B4%D9%81-detection-rules-%D8%A8%D9%84%D8%BA%D8%A9-sigma-%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%84%D9%88%D9%83-%D8%A7%D9%84%D9%89-%D8%AA%D9%86%D8%A8%D9%8A%D9%87/)[![](https://arabroot.io/content/images/2026/10/security-logging-cover-cover.webp)دليلالسجلات الأمنية Logs: ماذا تجمع ومن أين قبل أن تبني SOCجمعنا سجلات nginx وتطبيق صغير وSSH بأداة Vector، فرأينا كيف يقلب وقت بلا منطقة زمنية ترتيب الحادثة، وكيف ينجو السجل المركزي من المسح.](https://arabroot.io/articles/%D8%A7%D9%84%D8%B3%D8%AC%D9%84%D8%A7%D8%AA-%D8%A7%D9%84%D8%A7%D9%85%D9%86%D9%8A%D8%A9-logs-%D9%85%D8%A7%D8%B0%D8%A7-%D8%AA%D8%AC%D9%85%D8%B9-%D9%88%D9%85%D9%86-%D8%A7%D9%8A%D9%86-%D9%82%D8%A8%D9%84-soc/)[![](https://arabroot.io/content/images/2026/10/mitre-attack-cover-cover.webp)دليلMITRE ATT&CK: كيف يفكر المهاجم خطوة بخطوةلغة موحدة لسلوك المهاجمين مبنية على حوادث موثقة، نقرأ بها هجوم فدية حقيقياً مرحلة بمرحلة ونربط كل خطوة بالدفاع المقابل.](https://arabroot.io/articles/mitre-attack-%D9%83%D9%8A%D9%81-%D9%8A%D9%81%D9%83%D8%B1-%D8%A7%D9%84%D9%85%D9%87%D8%A7%D8%AC%D9%85-%D8%AE%D8%B7%D9%88%D8%A9-%D8%A8%D8%AE%D8%B7%D9%88%D8%A9/) وسوف نناقش في هذا المقال ما يلي: - ما الفرق بين اختبار الاختراق ومحاكاة الهجوم والتحقق من الكشف، ولماذا لوحة هادئة لا تعني أمناً. - من أين جاءت فكرة محاكاة الخصم، ولماذا تحولت من «هل أنا منيع؟» إلى «ماذا أرى؟». - دائرة الفريق البنفسجي Purple Team: نفذ، تحقق، سجل الفجوة، اكتب القاعدة. - ما Atomic Red Team، ولماذا لا تشغل اختباراتها عمياء أبداً. - ماذا يفعل كل أسلوب في عقل المهاجم، ولماذا يهم المدافع. - تجربة عملية: نشغل أساليب مختارة في Container معزول، ونقيس أي قاعدة أطلقت. - الفجوة التي كشفتها: أسلوب نفذ بلا قاعدة، وأسلوب تملص مسح الأثر المحلي ونجا منه المركزي. - الإذن والنطاق، وAtomic Red Team وCaldera، وكيف تبني برنامج محاكاة. ## اختبار اختراق أم محاكاة أم تحقق من كشف؟ ثلاثة مصطلحات تتداخل، ولكل منها غرض مختلف، ومن يخلط بينها يشتري الخطأ. فاختبار الاختراق Penetration Test، كما في [مقال اختبار الاختراق](https://arabroot.io/articles/%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%AE%D8%AA%D8%B1%D8%A7%D9%82-%D8%A7%D9%84%D9%85%D8%B5%D8%B1%D8%AD-%D8%A8%D9%87-%D8%A7%D9%84%D9%85%D9%86%D9%87%D8%AC%D9%8A%D8%A9-%D9%88%D8%A7%D9%84%D8%A7%D8%B0%D9%86-%D9%88%D8%A7%D9%84%D8%AA%D9%82%D8%B1%D9%8A%D8%B1/)، يسأل: هل يمكن اختراقي، وكيف؟ ويبحث عن الثغرات والطرق، وغايته قائمة بما يجب إصلاحه. ومحاكاة الخصم Adversary Emulation تسأل سؤالاً آخر: إذا نفذ مهاجم أساليب معروفة، فماذا يحدث في دفاعي؟ وهي لا تبحث عن ثغرة جديدة، وإنما تنفذ أساليب موثقة لتقيس الاستجابة. والتحقق من الكشف Detection Validation أضيق وأدق: هل تطلق قواعدي عندما ينفذ هذا الأسلوب بالضبط؟ والفرق العملي أن اختبار الاختراق يقيس قدرة المهاجم، والتحقق من الكشف يقيس قدرتك أنت على الرؤية. فقد تكون محصناً ضد الاختراق ومع ذلك أعمى عن محاولة تحدث، والعكس. ولوحة التحكم الهادئة تقيس شيئاً واحداً: أن قواعدك لم تطلق. وهذا قد يعني أن لا هجوم، أو أن قواعدك لا ترى الهجوم. والمحاكاة هي ما يفرق بينهما: تنفذ الأسلوب، فإن أطلقت القاعدة فأنت ترى، وإن لم تطلق فعندك فجوة كنت ستكتشفها يوماً بالطريقة الصعبة. وهذا بالضبط ما أوصى به تقرير الفريق الأحمر في CISA الذي ذكرناه في [مقال المركز](https://arabroot.io/articles/%D9%85%D8%B1%D9%83%D8%B2-%D8%A7%D9%84%D8%B9%D9%85%D9%84%D9%8A%D8%A7%D8%AA-%D8%A7%D9%84%D8%A7%D9%85%D9%86%D9%8A%D8%A9-soc-%D9%83%D9%8A%D9%81-%D9%8A%D8%B9%D9%85%D9%84-%D9%88%D9%85%D9%86-%D9%8A%D8%B9%D9%85%D9%84-%D9%81%D9%8A%D9%87/): اختبر مركز عملياتك بانتظام لتتأكد أنه يرى. ففي ذلك التقرير لم تكتشف جهة ناضجة نشاط الفريق الأحمر طوال التقييم، رغم أن لديها أدوات مراقبة، والسبب أن وجود الأداة لا يعني أنها ترى، والطريقة الوحيدة للتأكد أن تنفذ الأسلوب وتتحقق. فالمحاكاة ليست ترفاً للجهات الكبيرة، وإنما هي الفرق بين فريق يظن أنه يرى وفريق يعرف أنه يرى، وهذا الفرق قد يظهر في أسوأ لحظة: يوم الحادثة الحقيقية. ## من أين جاءت فكرة محاكاة الخصم؟ فكرة أن تهاجم نفسك لتختبر دفاعك قديمة في الأمن، فالفرق الحمراء Red Teams في الجيوش تلعب دور العدو لتكشف ثغرات الخطط. ونقلت هذه الفكرة إلى الأمن السيبراني في صورة اختبار الاختراق، ثم تطورت حين لاحظ المدافعون مشكلة: اختبار الاختراق يكشف كيف يدخل المهاجم، ولكنه لا يقيس جيداً هل يراه المدافع وهو بالداخل. فمختبر الاختراق هدفه الوصول إلى الهدف بأي طريق، وقد يصل بطريقة واحدة ذكية، فتخرج بتقرير يقول «أمكن الوصول»، دون أن تعرف أي أساليبك المتعددة يكشفها دفاعك. ومن هنا جاءت محاكاة الخصم المبنية على إطار [MITRE ATT&CK](https://arabroot.io/articles/mitre-attack-%D9%83%D9%8A%D9%81-%D9%8A%D9%81%D9%83%D8%B1-%D8%A7%D9%84%D9%85%D9%87%D8%A7%D8%AC%D9%85-%D8%AE%D8%B7%D9%88%D8%A9-%D8%A8%D8%AE%D8%B7%D9%88%D8%A9/) الذي نشر في 2015: بدل أن تسأل «هل يمكن اختراقي؟» تسأل «لكل أسلوب معروف يستخدمه المهاجمون، هل أراه؟». وATT&CK قدم القائمة المشتركة للأساليب، وAtomic Red Team قدم طريقة تنفيذها، فصار بإمكان أي فريق أن يختبر تغطيته أسلوباً أسلوباً، ويبني مصفوفة تقول بالضبط ما يرى وما يفوته. وهذا تحول من قياس «هل أنا منيع؟» إلى قياس «ماذا أرى؟»، وهو سؤال أدق وأنفع للمدافع، لأن المنعة الكاملة وهم، أما الرؤية فيمكن قياسها وتحسينها. ولهذا التحول أثر عملي على كيف تفكر في دفاعك. فمن يطارد المنعة الكاملة ينفق على جدران أعلى وأعلى، ويظن أنه كلما أنفق أكثر صار أكثر أماناً، حتى يخترق فيكتشف أنه لم يكن يرى شيئاً داخل جدرانه. ومن يطارد الرؤية يقبل أن المهاجم قد يدخل، ويركز على أن يراه وهو بالداخل بسرعة كافية ليحتويه قبل أن يصل إلى ما يهم. وهذا هو منطق الكشف والاستجابة الحديث: ليس «امنعهم كلهم» المستحيل، وإنما «راهم بسرعة واطردهم قبل الضرر». والمحاكاة هي ما يقيس هذه الرؤية بالأرقام: كم أسلوباً نرى، وبعد كم، وأيها يفوتنا، فتحول هدفاً مجرداً إلى مقياس يتحسن. ولعل أوضح صورة للفرق أن تتخيل ثلاثة فرق تدخل شركتك في ثلاثة أسابيع. الأول، مختبر الاختراق، يقضي أسبوعه يبحث عن طريق للدخول، فإذا وجده كتب في تقريره «دخلت من هذه الثغرة»، وغادر. والثاني، محاكي الخصم، لا يبحث عن ثغرة جديدة، وإنما ينفذ عشرين أسلوباً معروفاً داخل الشبكة، ويسجل أيها أثار تنبيهاً وأيها مر بهدوء. والثالث، محقق التحقق من الكشف، يأخذ قاعدة بعينها ويسأل: هل تطلق على ما كتبت لأجله؟ والثلاثة مفيدون، ولكنهم يجيبون أسئلة مختلفة، ومن يطلب اختبار اختراق وهو يريد أن يعرف هل يرى مركزه الهجوم اشترى الإجابة الخطأ: سيحصل على قائمة ثغرات، لا على خريطة لما يراه وما يفوته. ## دائرة الفريق البنفسجي عندما يجلس من ينفذ الأسلوب (الفريق الأحمر) ومن يتحقق من الكشف (الفريق الأزرق) على طاولة واحدة لتحسين القواعد، يسمى ذلك الفريق البنفسجي Purple Team، وهو أسرع طريق لتحسين التغطية. والصورة التالية تبين دائرته: ![أربع خطوات: نفذ أسلوباً معروفاً بتشغيل تعريف اختبار رسمي من Atomic Red Team لأسلوب ATT&CK في Container معزول، ثم هل أطلقت القاعدة تحقق إن كانت قاعدة الكشف رأت السلوك نعم أم لا، ثم سجل الفجوة أسلوب نفذ ولم تطلق له قاعدة فائت في تغطيتك، ثم اكتب القاعدة واختبرها أضف قاعدة للفجوة وأعد الاختبار حتى تطلق](https://arabroot.io/content/images/2026/10/attack-simulation-01-purple.webp) ليس اختراقاً، وإنما قياس للكشف: الأحمر ينفذ، والأزرق يتحقق، والاثنان فريق واحد والدائرة بسيطة ولكنها تغير كل شيء: بدل أن تنتظر الهجوم لتكتشف أن قاعدتك لا تعمل، تنفذ الأسلوب بنفسك في بيئة آمنة، وتكتشف الفجوة وأنت هادئ، وتسدها. وكل دورة ترفع تغطيتك خطوة، وتحولها من ظن «قواعدنا جيدة» إلى معرفة «قواعدنا رأت هذه الأساليب الخمسة وفاتها السادس». وهذا هو الفرق بين تغطية مقاسة وتغطية على الورق. ## ما Atomic Red Team، ولماذا لا تشغلها عمياء؟ مكتبة [Atomic Red Team](https://github.com/redcanaryco/atomic-red-team?ref=arabroot.io) من شركة Red Canary، مفتوحة برخصة MIT، وهي مجموعة اختبارات صغيرة مركزة، كل اختبار مربوط بأسلوب في ATT&CK، ومكتوب بصيغة YAML فيها اسم الاختبار، والمنصات المدعومة، والأمر الذي ينفذه، وأمر التنظيف الذي يعيد الحال. وقيمتها أنها لغة مشتركة: عندما تقول «اختبرت T1136.001» يعرف أي محلل في العالم ما نفذته بالضبط، لأن التعريف منشور وموحد. وهذه اللغة المشتركة تحل مشكلة كانت تربك فرق الأمن: كيف تتفق على ما اختبرت؟ فلو قال فريق «اختبرنا إنشاء حساب» لكان الوصف غامضاً، أي طريقة؟ وبأي صلاحية؟ وعلى أي نظام؟ أما حين يقول «اختبرنا T1136.001 الاختبار الأول على Linux» فالوصف دقيق لا لبس فيه، يستطيع أي فريق أن يعيده بالضبط ويقارن نتيجته. وهذا ما يجعل المكتبة أساساً لبرنامج قياس: تبني مصفوفة من معرفات الاختبارات، لكل واحد نتيجة مؤرخة، فتعرف بالضبط ما اختبرت ومتى وما كانت النتيجة، وتقارن تقدمك عبر الأشهر. فالمكتبة ليست مجرد أوامر، وإنما نظام ترقيم مشترك لأساليب المهاجمين، وهذا وحده نصف قيمتها. ولكن هذه المكتبة سلاح ذو حدين، والحد الخطير أنها تحتوي اختبارات مدمرة. فمن يشغلها كلها آلياً دون قراءة قد يمسح نظامه، والصورة التالية تبين القاعدة الذهبية: ![لوحتان: ما شغلناه آمن وقابل للتراجع T1136.001 إنشاء حساب خدمة وT1053.003 كتابة نص غير ضار في cron.d وT1070.003 مسح سجل الأوامر وT1070.004 حذف ملف خدعة أنشأناه وكل أمر له تراجع ولا يمس شيئاً خارج ال Container، وما لم نشغله أبداً T1070.004 الاختبار السابع rm -rf مع no-preserve-root لأن المكتبة تحتوي اختبارات مدمرة فمن يشغلها عمياء يمسح نظامه فاقرأ التعريف قبل أن تنفذ](https://arabroot.io/content/images/2026/10/attack-simulation-02-safe.webp) مكتبة الاختبارات فيها ما يمسح النظام، فالاختيار اليدوي والقراءة قبل التنفيذ شرط لا خيار فمثلاً يحمل أسلوب حذف الملفات T1070.004 اختباراً سابعاً اسمه «Delete Filesystem - Linux» أمره `rm -rf / --no-preserve-root`، أي محو نظام الملفات كاملاً. هذا اختبار حقيقي في المكتبة، غرضه قياس الكشف عن محو البيانات، ولكن تشغيله على نظام تهتم به كارثة. ولهذا القاعدتان الذهبيتان: اقرأ تعريف كل اختبار قبل أن تنفذه، واختر بالرقم الاختبارات الآمنة القابلة للتراجع، وشغل كل شيء في Container معزول تحذف بعد الاختبار. ونحن في هذا المقال اخترنا أربعة اختبارات بسيطة لها تراجع، ولم نشغل أي اختبار مدمر. ### تشريح تعريف اختبار Atomic كل اختبار في المكتبة ملف YAML منظم، يحتوي اسم الاختبار، ووصفه، والمنصات المدعومة (Linux أو Windows أو macOS)، والمتغيرات التي تستطيع تغييرها مثل اسم المستخدم، ثم المنفذ Executor الذي يحمل الأمر وأمر التنظيف. فاختبار إنشاء الحساب T1136.001 أمره `useradd` بخيارات تنشئ حساب خدمة، وأمر تنظيفه `userdel` يحذفه، وهذا ما يجعله آمناً للتجربة: له تراجع واضح. وحقل المنصات مهم، فبعض الاختبارات تعمل على Windows فقط، ولا معنى لتشغيلها على Linux. وقراءة هذا التعريف قبل التنفيذ ليست إجراء احتياط زائد، وإنما ضرورة. فبعض الاختبارات تحتاج صلاحية مدير، وبعضها يترك أثراً يحتاج تنظيفاً يدوياً، وبعضها، كما رأينا، مدمر. والفرق بين من يقرأ ومن لا يقرأ هو الفرق بين محاكاة محكومة وحادثة تصنعها بيدك. ولهذا ننصح بأن تبدأ دائماً بقراءة ملف الأسلوب على موقع المكتبة، وتختار الاختبار بالرقم، وتنفذه وحده، وتتأكد أنك فهمت أمره وأمر تنظيفه قبل أن تشغله. وتأتي مع المكتبة أداة تشغيل اسمها Invoke-Atomic تؤتمت تنفيذ الاختبارات وتنظيفها، وهي مريحة في بيئة اختبار منظمة، ولكننا لم نستخدمها هنا عمداً، لأن تنفيذ أمر الاختبار يدوياً يجعلك تقرأ كل أمر قبل أن تشغله، وهذا بالضبط ما نريد أن نزرعه عادة. فالأداة التي تشغل كل شيء بأمر واحد مريحة للخبير الذي يعرف ما يفعل، وخطيرة للمبتدئ الذي يثق بها دون قراءة. ونحن في هذا المقال نشغل الأوامر مباشرة في سكربت نكتبه، فنرى كل أمر قبل تنفيذه، ونختار بأنفسنا ما ننفذ وما نترك. وحين تنضج وتبني بيئة اختبار منظمة، تستطيع أن تنتقل إلى أداة التشغيل، بعد أن تكون قد تعودت قراءة ما تنفذ. ## ماذا يفعل كل أسلوب، ولماذا يهم المدافع؟ قبل أن ننفذ، يجب أن نفهم ما يمثله كل أسلوب في عقل المهاجم، لأن القاعدة الجيدة تكتب لتكشف النية لا الأمر الحرفي. والأساليب الأربعة التي اخترناها ليست عشوائية، وإنما تمثل مراحل مختلفة مما يفعله المهاجم بعد أن يدخل: - **إنشاء حساب T1136.001:** بعد أن يدخل المهاجم، يريد طريقاً للعودة لا يعتمد على الثغرة التي دخل منها، فينشئ حساباً جديداً يبدو عادياً، مثل حساب خدمة باسم لا يثير الشك. وهذا سلوك ثبات Persistence: البقاء في النظام بعد إغلاق باب الدخول الأول. والمدافع يكشفه بمراقبة إنشاء الحسابات، فالحساب الجديد الذي لم ينشئه أحد من الفريق حدث يستحق سؤالاً. - **الاستمرارية عبر cron T1053.003:** طريقة ثبات أخرى: المهاجم يضيف مهمة مجدولة تشغل كوده كل فترة، فحتى لو حذفت عمليته يعيدها الجدول. ويكشفها المدافع بمراقبة مجلدات cron، فأي ملف جديد فيها لم يضعه فريقك مشبوه. - **مسح سجل الأوامر T1070.003:** سلوك تملص Defense Evasion: المهاجم يمسح ما يكشف أفعاله على الجهاز، فسجل الأوامر يبين ما كتب، ومسحه يخفي أثره عمن يبحث على الجهاز نفسه. وهذا الأسلوب بالذات يختبر دفاعك المركزي: إن كان سجلك على الجهاز فقط ضاع، وإن خرج إلى مجمع نجا. - **حذف ملف T1070.004:** تملص أيضاً: المهاجم يحذف أدواته أو السجلات أو الأدلة بعد أن ينتهي. واخترنا منه الاختبار الآمن، حذف ملف خدعة أنشأناه نحن، لا الاختبار المدمر. ولاحظ أننا نصف السلوك بالكلمات، لا بكود استغلال: ماذا يريد المهاجم، وأي مرحلة من مراحله، وكيف يكشفه المدافع. فالغرض أن تفهم لماذا تكتب القاعدة، فالقاعدة التي تكتب دون فهم النية تكشف الأمر الحرفي وتفوت كل صورة أخرى منه. والأساليب الأربعة تغطي مرحلتين من أخطر مراحل ما بعد الاختراق: الثبات والتملص، وهما ما يفرق بين مهاجم يطرد في دقائق ومهاجم يبقى شهوراً. ولماذا اخترنا الثبات والتملص بالذات؟ لأنهما المرحلتان اللتان يقضي فيهما المهاجم أطول وقت، وفيهما أكبر فرصة للمدافع. فالوصول الأولي، أي لحظة الدخول، سريع وقد لا يترك أثراً، أما بعده فالمهاجم يحتاج أن يثبت أقدامه، ويستكشف، ويتحرك، ويخفي أثره، وكل خطوة من هذه فرصة لتراه إن كانت لك قاعدة. ولهذا يقول خبراء الكشف إن المعركة ليست عند الباب، وإنما بعده: من يرى المهاجم وهو ينشئ حسابه أو يضيف مهمته المجدولة يوقفه قبل أن يصل إلى بياناته، ومن يعمى عن ذلك يكتشفه بعد شهور حين يرى بياناته تباع. واختبار هذه المرحلة بالذات يقيس أهم ما في دفاعك: قدرتك على رؤية المهاجم بعد أن يدخل، لا منعه من الدخول فقط. ## تجربة عملية: نفذ، ثم اسأل هل رأته القواعد الآن نبني الاختبار على جهازك. نشغل أربعة أساليب مختارة في Container Debian معزولة بلا شبكة، ونشحن كل أمر إلى سجل مركزي قبل تنفيذه، ثم نشغل قواعد كشف تسأل عن كل أسلوب: هل رأيته؟ والصورة التالية تبين الطريق: ![أربع لوحات: تعريف الاختبار من مكتبة Atomic Red Team الرسمية بصيغة YAML، ثم Container Debian معزول بلا شبكة ننفذ التعريف ونشحن كل أمر إلى سجل مركزي قبل تنفيذه، ثم السجل المركزي نسخة من الأوامر خرجت قبل أن يمسح المهاجم أثره المحلي، ثم قواعد الكشف لكل أسلوب قاعدة هل رأته وأي أسلوب بلا قاعدة فجوة](https://arabroot.io/content/images/2026/10/attack-simulation-03-pipeline.webp) نولد السلوك بتعريف رسمي، ونقيس هل تراه قواعدنا، لا هل نستطيع اختراق شيء ### الأساليب الأربعة في Container معزول السكربت التالي ينفذ الأساليب المختارة. ولاحظ أنه قبل كل أمر يشحنه إلى سجل مركزي، وهذا يحاكي تدقيق الأوامر Command Auditing الذي يرسل كل أمر إلى مجمع، كما في [مقال السجلات](https://arabroot.io/articles/%D8%A7%D9%84%D8%B3%D8%AC%D9%84%D8%A7%D8%AA-%D8%A7%D9%84%D8%A7%D9%85%D9%86%D9%8A%D8%A9-logs-%D9%85%D8%A7%D8%B0%D8%A7-%D8%AA%D8%AC%D9%85%D8%B9-%D9%88%D9%85%D9%86-%D8%A7%D9%8A%D9%86-%D9%82%D8%A8%D9%84-soc/). وأضفنا عمداً أسلوباً خامساً، استطلاع النظام T1082، لم نكتب له قاعدة، لنرى هل تكشف المحاكاة الفجوة: ```bash #!/bin/bash # Runs a SELECTED, benign subset of official Atomic Red Team tests inside this disposable container. # Before each test it ships the command to a central log (simulating shell-command auditing), so the # record survives even if the test then clears the LOCAL history. Nothing here targets anything outside # this container. The destructive tests in these atomics (e.g. T1070.004 #7, rm -rf /) are NOT run. CENTRAL=/lab/out/central.ndjson host=$(hostname) ship() { printf '{"@timestamp":"%s","host":"%s","user":"%s","event":{"action":"process","technique":"%s"},"process":{"command_line":"%s"}}\n' \ "$(date -u +%Y-%m-%dT%H:%M:%S.%3NZ)" "$host" "$(whoami)" "$1" "$2" >> "$CENTRAL"; } mkdir -p /etc/cron.d echo "[*] baseline"; cp /etc/passwd /lab/out/passwd.before; ls /etc/cron.d > /lab/out/crond.before # T1136.001 #0 - Create a user account on a Linux system (benign: service account, no password) ship "T1136.001" "useradd -M -N -r -s /bin/bash -c evil_account svc_backup" useradd -M -N -r -s /bin/bash -c evil_account svc_backup # T1053.003 #2 - Cron: add script to /etc/cron.d (benign payload: a harmless echo) ship "T1053.003" "echo '* * * * * root echo lab' > /etc/cron.d/art_cron" echo '* * * * * root echo lab' > /etc/cron.d/art_cron # a few real commands land in the shell history first echo "id" >> ~/.bash_history; echo "uname -a" >> ~/.bash_history; echo "cat /etc/shadow" >> ~/.bash_history # T1070.003 #1 - Clear Bash history (echo): the defense-evasion step that erases the LOCAL trail ship "T1070.003" "echo -n > ~/.bash_history (clear bash history)" echo "" > ~/.bash_history # T1070.004 #0 - Delete a single file (benign: a decoy file we created) touch /lab/out/decoy.txt ship "T1070.004" "rm -f /lab/out/decoy.txt" rm -f /lab/out/decoy.txt # T1082 - System Information Discovery (no detection rule written for it on purpose: a coverage gap) ship "T1082" "uname -a; cat /etc/os-release" uname -a > /dev/null; cat /etc/os-release > /dev/null echo "[*] local bash_history now has $(wc -l < ~/.bash_history) lines (attacker cleared it)" cp /etc/passwd /lab/out/passwd.after; ls /etc/cron.d > /lab/out/crond.after echo "[*] done" ``` نشغله في Container بلا شبكة `--network none`، فما يحدث فيها لا يخرج منها: ```bash docker run --rm --name scu-ats --network none -v "$(pwd -W):/lab" \ debian:trixie-slim bash -c 'bash /lab/run_atomics.sh; wc -l < ~/.bash_history | tr -d " " > /lab/out/histlines.txt' ``` ```text [*] baseline [*] local bash_history now has 1 lines (attacker cleared it) [*] done ``` والسجل المركزي بعد التشغيل فيه خمسة أسطر، سطر لكل أسلوب، شحن قبل أن ينفذ، وهذه عينة منه: ```json {"@timestamp":"2026-10-28T13:54:09.196Z","host":"5fcb8c4e371a","user":"root","event":{"action":"process","technique":"T1136.001"},"process":{"command_line":"useradd -M -N -r -s /bin/bash -c evil_account svc_backup"}} {"@timestamp":"2026-10-28T13:54:09.498Z","host":"5fcb8c4e371a","user":"root","event":{"action":"process","technique":"T1053.003"},"process":{"command_line":"echo '* * * * * root echo lab' > /etc/cron.d/art_cron"}} {"@timestamp":"2026-10-28T13:54:09.587Z","host":"5fcb8c4e371a","user":"root","event":{"action":"process","technique":"T1070.003"},"process":{"command_line":"echo -n > ~/.bash_history (clear bash history)"}} ``` في العينة أعلاه لاحظ أن كل سطر حدث منظم بأسماء حقول موحدة، كما تعلمنا في مقال السجلات: وقت بصيغة UTC، واسم الجهاز، والمستخدم، ومعرف الأسلوب في ATT&CK، والأمر نفسه. وهذا التنظيم مقصود، فالسجل الذي يصل إلى القواعد بأسماء حقول ثابتة تكتب عليه قاعدة واحدة تعمل على كل الأسطر، بينما السجل الحر الذي كل سطر فيه بصيغة مختلفة يحتاج تحليلاً لكل صيغة. ولاحظ أيضاً أن الأمر الذي ننفذه مكتوب في السجل كما هو، فلو كان أمراً خبيثاً حقيقياً لكان في السجل دليلاً كاملاً على ما فعل المهاجم، وهذا ما يجعل تدقيق الأوامر من أقوى مصادر البيانات للمدافع، وأكثرها حساسية أيضاً، لأنه قد يلتقط كلمات مرور كتبت في سطر الأوامر، فاحرص ألا تسجل ما لا تحتاجه كما نبهنا في مقال السجلات. وفي السكربت أعلاه لاحظ ثلاثة قرارات تصميم مهمة. الأول أن كل أمر يشحن إلى السجل المركزي قبل تنفيذه لا بعده، والسبب أن الأسلوب الذي يمسح الأثر ينفذ ضمن القائمة، فلو شحنا بعد التنفيذ لربما مسح نفسه قبل أن يصل. والثاني أننا نسجل قبل كل أمر معرف الأسلوب الذي ينتمي إليه، فحين تصل الأحداث إلى القواعد تعرف كل حدث أي أسلوب يمثل، وهذا ما يجعل الحكم ممكناً أسلوباً أسلوباً. والثالث، الأهم، أن ال Container بلا شبكة `--network none`، فحتى لو احتوى أسلوب ما على أمر يتصل بالخارج، لا يجد شبكة يتصل منها، وهذا حاجز تقني فوق انضباطنا الذاتي: المختبر معزول بالتصميم لا بالثقة. ### كيف تقرر القواعد؟ قواعد الكشف في السكربت بسيطة عمداً، لأن الغرض أن نرى المنطق لا أن نبني محرك SIEM. فكل قاعدة دالة صغيرة تجيب بنعم أو لا: قاعدة الحساب الجديد تقارن `/etc/passwd` قبل وبعد، فإن ظهر مستخدم جديد أطلقت، وهذا أسلوب مراقبة سلامة الملفات File Integrity Monitoring الذي جربناه في [مقال Wazuh](https://arabroot.io/articles/%D9%85%D8%B1%D8%A7%D9%82%D8%A8%D8%A9-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA-%D9%85%D8%B9-wazuh-%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D8%AC%D9%84-%D8%A7%D9%84%D9%89-%D8%AD%D8%B8%D8%B1-%D8%A7%D9%84%D9%85%D9%87%D8%A7%D8%AC%D9%85/). وقاعدة cron تقارن محتوى مجلد `/etc/cron.d` قبل وبعد. وقاعدة مسح السجل تبحث في السجل المركزي عن أمر المسح، لأنها الطريقة الوحيدة لرؤيته بعد أن مسح المحلي. وقاعدة حذف الملف تبحث عن أمر `rm` في السجل المركزي. ولاحظ تصميماً مهماً: بعض القواعد تقرأ حالة النظام (مثل ملف passwd)، وبعضها يقرأ السجل المركزي (مثل مسح السجل). والسبب أن بعض الأفعال تترك أثراً باقياً في النظام تراه متى شئت، وبعضها لا يترك إلا سجلاً، فإن لم تجمعه ضاع. وهذا يعلمك أين تحتاج مراقبة الحالة وأين تحتاج مراقبة السجل: الحساب الجديد تراه في passwd متى نظرت، أما أمر مسح نفذ ثم انتهى فلا يبقى منه إلا ما سجلته لحظة حدوثه. وهذا الدرس وحده يستحق المحاكاة: أن تعرف أي أساليبك تكشفها الحالة وأيها تكشفها السجلات فقط. وهذا التمييز بين مراقبة الحالة ومراقبة السجل من أعمق دروس المحاكاة، لأنه يحدد أين دفاعك هش. فالأساليب التي تترك أثراً باقياً، مثل حساب جديد أو ملف cron، تكشفها متى شئت لأنها تبقى في النظام، فحتى لو تأخرت عنها رأيتها لاحقاً. أما الأساليب التي لا تترك إلا سجلاً، مثل أمر ينفذ ثم ينتهي، أو اتصال شبكي يمر، فلا تكشفها إلا إذا كنت تجمع السجل لحظة حدوثه، فإن لم تكن تجمعه فاتك إلى الأبد ولا سبيل لاستعادته. ولهذا يقول خبراء الكشف إن أخطر فجواتك ليست في الأساليب التي لا قاعدة لها، وإنما في الأساليب التي لا مصدر بيانات لها أصلاً: قاعدة بلا سجل يغذيها قاعدة ميتة، والمحاكاة تكشف الاثنين، فتسألك أولاً هل تجمع السجل، ثم هل تكتب القاعدة. ### الحكم: أي أسلوب رأته القواعد؟ الآن نشغل قواعد الكشف. لكل أسلوب قاعدة تبحث في السجل المركزي وفي حالة النظام: هل ظهر مستخدم جديد؟ هل ظهر ملف cron جديد؟ هل في السجل أمر مسح؟ والسكربت يعد كم قاعدة أطلقت، ويكشف أي أسلوب نفذ بلا قاعدة: ```python """Detection validation: for each attacker technique the atomics ran, does a detection rule fire? Rules read the central command log that was shipped BEFORE the local trail was cleared, plus the host state (passwd and cron.d before/after). Firing proves the rule works; a technique with no rule that fires is a coverage gap (a false negative) the validation surfaces.""" import json, sys, os central = [json.loads(l) for l in open(sys.argv[1], encoding="utf-8") if l.strip()] cmds = [(e["event"]["technique"], e["process"]["command_line"]) for e in central] before = set(open(sys.argv[2]).read().splitlines()) after = set(open(sys.argv[3]).read().splitlines()) crond_new = set(open(sys.argv[5]).read().split()) - set(open(sys.argv[4]).read().split()) new_users = [l.split(":")[0] for l in after - before] # detection rules: (technique, name, predicate over the shipped commands / host state) rules = [ ("T1136.001", "حساب مستخدم جديد", lambda: bool(new_users) or any("useradd" in c for _, c in cmds)), ("T1053.003", "استمرارية عبر cron", lambda: bool(crond_new) or any("/etc/cron.d" in c for _, c in cmds)), ("T1070.003", "مسح سجل الأوامر", lambda: any(t == "T1070.003" for t, _ in cmds)), # only the central copy can see this ("T1070.004", "حذف ملف", lambda: any("rm -f" in c or "rm -rf" in c for _, c in cmds)), ] ran = {t for t, _ in cmds} print(f"techniques run: {len(ran)} rules defined: {len(rules)}\n") print(f"{'technique':12} {'rule':22} {'fired?':8} evidence") fired = 0 for tech, name, pred in rules: ok = pred() fired += ok ev = {"T1136.001": f"new user: {new_users}", "T1053.003": f"new cron file: {sorted(crond_new)}", "T1070.003": "central log has the clear command; local history is empty", "T1070.004": "rm command in central log"}[tech] print(f" {tech:12} {name:22} {'نعم ✓' if ok else 'لا ✗':8} {ev}") no_rule = ran - {t for t, _, _ in rules} print(f"\nrules that fired: {fired}/{len(rules)}") print("techniques run with NO detection rule (coverage gap / false negative):", ", ".join(sorted(no_rule)) or "none") print(f"\nlocal ~/.bash_history lines after the clear: {int(open(sys.argv[6]).read().strip())}; " f"central log entries: {len(central)} <-- the shipped copy survived the clear") ``` ```bash docker run --rm -v "$(pwd -W):/w" -w /w python:3.13.17-slim \ python detect.py out/central.ndjson out/passwd.before out/passwd.after out/crond.before out/crond.after out/histlines.txt ``` والمخرج سوف يكون كما يلي: ```text techniques run: 5 rules defined: 4 technique rule fired? evidence T1136.001 حساب مستخدم جديد نعم ✓ new user: ['svc_backup'] T1053.003 استمرارية عبر cron نعم ✓ new cron file: ['art_cron'] T1070.003 مسح سجل الأوامر نعم ✓ central log has the clear command; local history is empty T1070.004 حذف ملف نعم ✓ rm command in central log rules that fired: 4/4 techniques run with NO detection rule (coverage gap / false negative): T1082 local ~/.bash_history lines after the clear: 1; central log entries: 5 <-- the shipped copy survived the clear ``` ![جدول: الأسلوب T1136.001 حساب مستخدم جديد أطلقت نعم بدليل مستخدم جديد svc_backup، وT1053.003 استمرارية عبر cron أطلقت نعم بدليل ملف cron جديد art_cron، وT1070.003 مسح سجل الأوامر أطلقت نعم لأن السجل المركزي رآه والمحلي فارغ، وT1070.004 حذف ملف أطلقت نعم بأمر rm في السجل المركزي، وT1082 لا توجد قاعدة فجوة لأن استطلاع النظام نفذ ولم تره أي قاعدة](https://arabroot.io/content/images/2026/10/attack-simulation-04-results.webp) أربع قواعد أطلقت على ما نفذ، وأسلوب خامس نفذ بلا قاعدة: فجوة تكشفها المحاكاة لا الحظ في المخرج أعلاه لاحظ التالي: - **أربع قواعد من أربع أطلقت:** الحساب الجديد، والاستمرارية عبر cron، ومسح السجل، وحذف الملف، كلها رأتها قواعدنا. وهذا يثبت أن القواعد تعمل على هذه الأساليب، لا يفترضه. - **الفجوة:** استطلاع النظام T1082 نفذ ولم تطلق له أي قاعدة، لأننا لم نكتب له واحدة. وهذا فائت False Negative، وهو أخطر حكم كما شرحنا في [يوم محلل SOC](https://arabroot.io/articles/%D9%8A%D9%88%D9%85-%D9%85%D8%AD%D9%84%D9%84-soc-%D9%81%D8%B1%D8%B2-%D8%A7%D9%84%D8%AA%D9%86%D8%A8%D9%8A%D9%87%D8%A7%D8%AA-%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D9%86%D8%A8%D9%8A%D9%87-%D8%A7%D9%84%D9%89-%D8%A7%D9%84%D9%82%D8%B1%D8%A7%D8%B1/)، لأنه لا يظهر في أي طابور، ولا تعرفه إلا بالبحث أو بالمحاكاة. والمحاكاة كشفته في دقائق. - **الدليل مكتوب:** كل قاعدة أطلقت تقول لماذا، مثل «مستخدم جديد svc\_backup»، فالحكم ليس نعم مجردة، وإنما نعم بدليل يستطيع المحلل أن يتحقق منه. ولاحظ ما لم يظهر في الحكم: كم استغرق الكشف. ففي هذا المختبر الصغير كل شيء لحظي، أما في بيئة حقيقية فالسؤال الثاني بعد «هل رأته القاعدة؟» هو «بعد كم؟». فقاعدة تطلق بعد ساعة من الحدث مفيدة أقل بكثير من قاعدة تطلق في دقيقة، لأن المهاجم في الساعة التي لم ترها فيها تحرك وتوسع. لذلك في المحاكاة الحقيقية تقيس لكل أسلوب زمنين: هل أطلقت القاعدة، وبعد كم من تنفيذ الأسلوب. والفجوة قد لا تكون في عدم الإطلاق، وإنما في بطئه، وهذا ما يربط المحاكاة بمقاييس المركز التي ذكرناها في مقال المركز، مثل زمن الكشف. والمحاكاة هي ما يحول هذه المقاييس من أرقام تاريخية تجمع من الحوادث إلى أرقام تقيسها متى شئت بتنفيذ أسلوب. ### التملص: المهاجم يمسح، والمركزي يبقى أهم أسلوب في الاختبار كان مسح سجل الأوامر T1070.003، وهو أسلوب تملص Defense Evasion: المهاجم يمسح سجل الأوامر المحلي ليخفي ما فعل. وبعد تشغيله صار سجل الأوامر المحلي سطراً واحداً، أي أن من يبحث على الجهاز نفسه لا يرى شيئاً. ولكن السجل المركزي بقي فيه الأوامر الخمسة، لأنها شحنت قبل المسح، والصورة التالية تبين ذلك: ![ثلاث لوحات: على الجهاز المصاب سطر واحد في سجل الأوامر المحلي بعد أن مسحه أسلوب التملص T1070.003 فمن يبحث على الجهاز وحده لا يرى شيئاً، وعند المجمع المركزي خمسة أوامر شحنت قبل المسح فبقيت وأسلوب التملص نفسه ظهر في السجل المركزي، والدرس أن الكشف ينجح لأن السجل خرج من الجهاز لحظة كتابته](https://arabroot.io/content/images/2026/10/attack-simulation-05-evasion.webp) المحاكاة تثبت أن السجل المركزي ينجو من المسح، لا تفترضه وهذا يربط المحاكاة بمقال السجلات ربطاً مباشراً: هناك شرحنا أن المهاجم يمسح السجل المحلي ولا يصل إلى ما خرج إلى المجمع قبله، وهنا نفذنا الأسلوب فعلاً وأثبتنا أن القاعدة ما زالت تطلق لأن السجل خرج في وقته. فالمحاكاة لا تختبر القاعدة وحدها، وإنما تختبر السلسلة كلها: هل جمعت السجل؟ هل نجا من المسح؟ هل رأته القاعدة؟ وكل حلقة قد تتعطل، والمحاكاة تكشف أيها. ### حذف المختبر ال Container حذف نفسه بالخيار `--rm` فور انتهاء الاختبار، ولم تنشئ شبكة ولا تركت أثراً خارج مجلد المختبر. فلا يبقى إلا أن تحذف مجلد المخرجات إن أردت: ```bash rm -rf out ``` ولاحظ قيمة العزل التامة: لم نحتج أن نثق بأن الأوامر آمنة، لأن ال Container يمنعها من إيذاء أي شيء خارجها، فلا شبكة تصل منها، ولا ملفات للنظام المضيف تمسها، وتختفي بالكامل عند انتهائها. وهذا هو الشكل الصحيح لأي عمل هجومي تجريبي: اجعل البيئة تمنع الضرر بالتصميم، لا أن تعتمد على حذرك وحدك، فالحذر يخطئ والتصميم لا. وال Container المعزول أرخص بيئة تحقق هذا، فهي تنشأ في ثانية وتحذف في ثانية، ولا تترك أثراً، وتستطيع أن تكررها مئة مرة لتجرب مئة أسلوب دون أن تراكم خطراً. ## الإذن والنطاق: ماذا تقول الضوابط؟ المحاكاة عمل هجومي، ولو كان على مختبرك، فتخضع لنفس مبدأ اختبار الاختراق: لا تبدأ دون إذن مكتوب ونطاق واضح، كما فصلنا في [مقال اختبار الاختراق](https://arabroot.io/articles/%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%AE%D8%AA%D8%B1%D8%A7%D9%82-%D8%A7%D9%84%D9%85%D8%B5%D8%B1%D8%AD-%D8%A8%D9%87-%D8%A7%D9%84%D9%85%D9%86%D9%87%D8%AC%D9%8A%D8%A9-%D9%88%D8%A7%D9%84%D8%A7%D8%B0%D9%86-%D9%88%D8%A7%D9%84%D8%AA%D9%82%D8%B1%D9%8A%D8%B1/). وقد تظن أن مختبرك لا يحتاج إذناً، ولكن العادة التي تبنيها مهمة: أن يكون لكل عمل هجومي إذن ونطاق، حتى لا يتسرب يوماً إلى نظام حقيقي بالخطأ. والضابط 2-11 في [وثيقة ECC-2:2024](https://cdn.nca.gov.sa/api/files/public/upload/86e09090-44e4-481f-bc28-355673607654%5FECC--2024-EN.pdf?ref=arabroot.io) يطلب اختبار الاختراق عبر محاكاة أساليب وتقنيات الهجوم الحقيقية لاكتشاف نقاط الضعف، ويطلب أن يجرى دورياً. ومحاكاة الخصم جزء من هذا: فهي محاكاة أساليب حقيقية، وإن كان غرضها قياس الكشف لا اكتشاف الثغرات. ولاحظ أن الضابط يطلب أن يشمل اختبار الاختراق الخدمات المقدمة عبر الإنترنت وأن يجرى دورياً، أي أنه يرى الاختبار عملاً منتظماً لا حدثاً يجرى مرة ويوثق. ومحاكاة الكشف تكمل هذه الصورة: فالاختبار الدوري على الأنظمة المكشوفة يقيس هل يمكن اختراقها، والمحاكاة الدورية على مركز عملياتك تقيس هل تراها وهي تهاجم. والاثنان معاً يعطيان الصورة الكاملة التي يريدها المدقق: نعرف ثغراتنا، ونعرف ماذا نرى. وفي كل عمل هجومي، سواء كان اختبار اختراق أو محاكاة، يبقى الإذن والنطاق أول خطوة، لأن ما يميز العمل المصرح به عن الجريمة ليس الأداة، وإنما الإذن المكتوب والحدود المتفق عليها. والفرق بين المحاكاة في مختبرك والاختبار على الإنتاج مهم: ما تفعله هنا، على Container معزول تنشئها وتحذفها، لا يحتاج أكثر من انضباطك الذاتي؛ أما توجيه أي أسلوب إلى نظام إنتاج، أو إلى نظام مورد، أو إلى أي شيء لا تملكه، فيحتاج إذناً مكتوباً صريحاً، ونطاقاً يحدد ما يختبر وما لا يختبر، وتوقيتاً، وجهة اتصال إن حدث خطأ. وهذا ليس شكلاً قانونياً فقط، وإنما حماية لك: محاكاة ذهبت إلى نظام خارج النطاق قد تسبب ضرراً حقيقياً أو تفسر اختراقاً. ## Atomic Red Team وCaldera: متى كل منهما؟ Atomic Red Team ليست الأداة الوحيدة، وأشهر بديل أثقل منها هو منصة [MITRE Caldera](https://github.com/mitre/caldera?ref=arabroot.io)، والصورة التالية تقارن بينهما: ![لوحتان: Atomic Red Team مكتبة اختبارات بسيطة ومركزة كل اختبار أمر أو أمران مربوطان بأسلوب ATT&CK برخصة MIT تشغل اختباراً بعينه بسيط يدوي، وMITRE Caldera منصة محاكاة خصم كاملة بوكيل على الأجهزة وخطط هجوم متسلسلة وأتمتة أثقل وأقرب لسيناريو كامل تحتاج إعداداً](https://arabroot.io/content/images/2026/10/attack-simulation-06-tools.webp) ابدأ بالبسيط: اختبار واحد لأسلوب واحد في Container معزول، أوضح وأقل خطراً - **Atomic Red Team:** مكتبة اختبارات بسيطة، تشغل اختباراً بعينه يدوياً، وتقرأ تعريفه قبل. مناسبة للتحقق من قاعدة بعينها، وللبدء، لأنها بسيطة وواضحة وأقل خطراً. - **MITRE Caldera:** منصة محاكاة خصم كاملة، تضع وكيلاً Agent على الأجهزة، وتشغل خطط هجوم متسلسلة مؤتمتة تحاكي حملة كاملة من البداية إلى الهدف. أقوى وأقرب للواقع، وأثقل إعداداً وأخطر، لأنها تؤتمت سلسلة أفعال لا فعلاً واحداً. والنصيحة للشركات الصغيرة: ابدأ بـ Atomic Red Team، فاختبار واحد لأسلوب واحد في Container معزول يعلمك التحقق من الكشف بأقل خطر، ويكشف أكبر الفجوات. وCaldera تأتي حين تنضج، وتريد محاكاة حملة كاملة لتختبر هل يربط فريقك الأفعال المتفرقة في قصة واحدة، وتشغلها بإذن ونطاق واضحين كما أي عمل هجومي. وفي الحالتين، المبدأ واحد: المحاكاة تقيس الكشف، لا تخترق، وتبقى داخل مختبرك بإذن. ## مصفوفة التغطية: من الاختبار إلى الخريطة الاختبار الواحد يجيب سؤالاً صغيراً، والقيمة الحقيقية حين تجمع الأجوبة في خريطة. فإطار ATT&CK ليس قائمة أساليب فحسب، وإنما مصفوفة تنظمها بحسب هدف المهاجم: الوصول الأولي، والتنفيذ، والثبات، ورفع الصلاحية، والتملص، وهكذا. وعندما تلون هذه المصفوفة بما اختبرته، تظهر صورة لا يعطيها أي تقرير اختبار اختراق: أي مراحل المهاجم تراها جيداً، وأيها عمياء عنها. وقد تكتشف أنك تكشف الوصول الأولي والتنفيذ ممتازاً، وتعمى تماماً عن التملص، أي أنك ترى المهاجم يدخل ولا تراه يخفي أثره، وهذه معلومة تغير أولوياتك. ولتبني هذه الخريطة، لا تحتاج أن تختبر كل أسلوب في المصفوفة، فهي مئات، وأغلبها لا يخصك. وإنما تبدأ من الأساليب التي يستخدمها المهاجمون ضد قطاعك فعلاً، والتي تنشرها تقارير التهديد ومعلومات التهديدات كما في مقال MISP وOpenCTI. فإذا كان قطاعك يتعرض لهجمات فدية، فأساليب الثبات والتشفير والتملص أولى بالاختبار من أساليب نادرة لن تراها. والهدف أن تختبر ما يرجح أن يصيبك، لا كل ما هو ممكن، فالتغطية الكاملة وهم، والتغطية الذكية هي ما يميز فريقاً ناضجاً. وهكذا تتحول المحاكاة من تمرين تقني إلى قرار أولويات: ما الذي نستثمر في كشفه أولاً، لأنه الأرجح أن يصيبنا. ## كيف تبني برنامج محاكاة؟ الاختبار الواحد مفيد، والبرنامج المنتظم أهم. فابدأ من تغطيتك: أي أساليب ATT&CK تهم بيئتك، أي ما يستخدمه المهاجمون ضد شركات مثلك، ورتبها. ثم اختبر كل شهر مجموعة منها، وسجل لكل أسلوب: هل أطلقت القاعدة؟ وبعد كم؟ وإن لم تطلق، اكتب القاعدة، واختبرها، وأعد المحاكاة حتى تطلق. وهكذا تبني مصفوفة تغطية تنمو: أساليب رأيتها واختبرتها، وأساليب تعمل عليها، وأساليب لم تصل إليها بعد. وهذا ما يحول سؤال المدير «هل نحن محميون؟» من إجابة غامضة إلى رقم: «نكشف هذه الأساليب الثلاثين المختبرة، ونعمل على عشرة، ولم نصل إلى بقية المصفوفة». وأفضل شكل للبرنامج هو الفريق البنفسجي المنتظم: جلسة قصيرة كل فترة يجلس فيها من ينفذ ومن يكشف معاً، ينفذون أسلوباً، ويراقبون القاعدة، ويحسنونها على الطاولة. فبدل أن ينفذ الأحمر تقريراً يرميه للأزرق بعد شهر، يتعلم الاثنان معاً في ساعة، وهذا أسرع ما يرفع التغطية. وهذا امتداد طبيعي لما بنيناه: السجلات تجمع، والقواعد تكتب، والمحاكاة تثبت أنها تعمل، والدائرة تدور. ولا تنس أن تختبر ما كان يعمل أيضاً، فالقاعدة التي كانت تطلق الشهر الماضي قد تتوقف بعد تحديث غير اسم حقل أو أسقط مصدر سجل، والمحاكاة المنتظمة تكشف هذا التراجع الصامت قبل أن يكشفه المهاجم. وفي شركة صغيرة لا فريق أحمر فيها ولا أزرق منفصلين، لا يمنعك ذلك من البرنامج، فالشخص نفسه يستطيع أن يلبس القبعتين في أوقات مختلفة: يوماً ينفذ أسلوباً، ويوماً يتحقق هل رأته قواعده، ويكتب الفجوة ويسدها. والمهم ليس أن يكون لديك فريقان، وإنما أن تكون الدورة موجودة: تنفيذ، فتحقق، فسد فجوة. وحتى اختبار واحد في الشهر، على أسلوب واحد، أفضل بكثير من لا شيء، لأنه يبني العادة ويكشف فجوة كل مرة. والبرنامج ينمو مع الوقت: يبدأ بأسلوب في الشهر، ثم بخمسة، ثم بمصفوفة كاملة تراجعها كل ربع سنة، وكل درجة ترفع ثقتك بما ترى من ظن إلى قياس. ## ما لا تقوله المحاكاة المحاكاة أداة قوية، ولكن لها حدود يجب أن تعرفها حتى لا تثق بها أكثر مما تستحق. فأولاً، هي تقيس الكشف عن الأساليب التي اخترت أن تختبرها، لا عن غيرها، فنجاحك في عشرة أساليب لا يقول شيئاً عن الحادي عشر الذي لم تجربه. وثانياً، تشغيل الأسلوب في Container نظيف يختلف عن تنفيذه في بيئة إنتاج محملة بآلاف الأحداث، فقاعدة أطلقت في مختبر هادئ قد تضيع وسط ضجيج الإنتاج، أو تطلق مئة إنذار خاطئ لم تظهر في المختبر. وثالثاً، المهاجم الحقيقي يتكيف ويغير أسلوبه ليتجنب ما يعرف أنك تكشفه، بينما تعريف الاختبار ثابت، فأنت تختبر نسخة واحدة من الأسلوب لا كل صوره. ولهذا فالمحاكاة تثبت الوجود لا الغياب: إذا أطلقت القاعدة فأنت تكشف هذه الصورة من هذا الأسلوب، وهذه معلومة موجبة قوية؛ أما إذا لم تطلق فأنت تعرف أن عندك فجوة، وهذه أيضاً معلومة مفيدة. ولكن نجاح كل اختباراتك لا يعني أنك محصن، وإنما يعني أنك تكشف ما اختبرت. والفريق الناضج يعرف هذا، فيوسع مصفوفته باستمرار، ويختبر صوراً متعددة من كل أسلوب، ويعيد الاختبار في بيئة أقرب للإنتاج حين يستطيع، ولا يقرأ لوحة خضراء على أنها «نحن آمنون»، وإنما «نحن نرى هذه الأساليب، ونعمل على البقية». ## أخطاء شائعة - **اعتبار الهدوء أمناً:** لوحة هادئة قد تعني قواعد عمياء لا شبكة آمنة، والمحاكاة تفرق بينهما. - **تشغيل الاختبارات عمياء:** المكتبة فيها اختبارات مدمرة مثل محو نظام الملفات، فاقرأ قبل أن تنفذ. - **المحاكاة خارج المختبر:** لا توجه أي اختبار إلى نظام إنتاج أو نظام لا تملكه، وابق في Container معزول. - **اختبار بلا قياس:** تشغل الأسلوب ولا تسجل هل أطلقت القاعدة، فتضيع الفائدة كلها. - **تجاهل الفجوات:** أسلوب نفذ بلا قاعدة فائت، واكتشافه نصف الفائدة، فاكتب له قاعدة. - **اختبار القاعدة دون السلسلة:** القاعدة قد تكون صحيحة والسجل لم يجمع أو مسح، فاختبر السلسلة كاملة. - **الاكتفاء بمرة واحدة:** التغطية تتغير مع كل قاعدة جديدة وكل نظام جديد، فالمحاكاة برنامج لا حدث. - **القفز إلى Caldera مبكراً:** محاكاة حملة مؤتمتة قبل أن تتقن اختبار أسلوب واحد تضيف تعقيداً وخطراً. ## قائمة تحقق | السؤال | كيف تتحقق | | ---------------------------------------- | ------------------------------------------ | | هل الاختبار في Container معزول بلا شبكة؟ | \--network none وحذف بعد الاختبار | | هل قرأت تعريف كل اختبار قبل تشغيله؟ | تجنب الاختبارات المدمرة مثل محو الملفات | | هل لكل أسلوب حكم: أطلقت القاعدة أم لا؟ | سكربت أو جدول يسجل لكل أسلوب | | هل سجلت الأساليب التي نفذت بلا قاعدة؟ | قائمة الفجوات، كل واحدة قاعدة تكتب | | هل اختبرت السلسلة لا القاعدة وحدها؟ | هل جمع السجل، ونجا من المسح، ورأته القاعدة | | هل تربط الأساليب بمصفوفة ATT&CK؟ | تغطية مقاسة: ما اختبرت، وما بقي | | هل المحاكاة منتظمة لا مرة واحدة؟ | جلسة فريق بنفسجي دورية | | هل كل ذلك بإذن ونطاق مكتوبين؟ | كما أي عمل هجومي، حتى في مختبرك | ## الخلاصة - لوحة التحكم الهادئة لا تعني أمناً، فقد تعني قواعد عمياء، والمحاكاة وحدها تفرق بينهما. - التحقق من الكشف يقيس قدرتك على الرؤية، لا قدرة المهاجم على الاختراق، وهما شيئان مختلفان. - Atomic Red Team مكتبة اختبارات رسمية مربوطة بـ ATT&CK، ولا تشغل عمياء لأن فيها اختبارات مدمرة. - في التجربة أطلقت أربع قواعد من أربع على ما نفذ، وكشفت المحاكاة فجوة: استطلاع نظام بلا قاعدة. - أسلوب التملص مسح السجل المحلي، ونجا منه السجل المركزي، فأثبتت المحاكاة أن السلسلة تعمل. - ابدأ بـ Atomic Red Team في Container معزول، وCaldera حين تريد محاكاة حملة كاملة بإذن ونطاق. - المحاكاة برنامج لا حدث: فريق بنفسجي منتظم يبني مصفوفة تغطية تنمو كل دورة. وأقرب المقالات إلى هذا الموضوع في المسار: [![](https://arabroot.io/content/images/2026/10/detection-rules-cover-cover.webp)دليلقواعد الكشف Detection Rules بلغة Sigma: من السلوك إلى تنبيهولدنا حركة اعتداء حقيقية الشكل، وحولنا قواعد SigmaHQ وقواعد كتبناها إلى SQL بمكتبة pySigma، فرأينا ما أصابت وما فاتها قاعدة بفلتر 404.](https://arabroot.io/articles/%D9%82%D9%88%D8%A7%D8%B9%D8%AF-%D8%A7%D9%84%D9%83%D8%B4%D9%81-detection-rules-%D8%A8%D9%84%D8%BA%D8%A9-sigma-%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%84%D9%88%D9%83-%D8%A7%D9%84%D9%89-%D8%AA%D9%86%D8%A8%D9%8A%D9%87/)[![](https://arabroot.io/content/images/2026/10/security-logging-cover-cover.webp)دليلالسجلات الأمنية Logs: ماذا تجمع ومن أين قبل أن تبني SOCجمعنا سجلات nginx وتطبيق صغير وSSH بأداة Vector، فرأينا كيف يقلب وقت بلا منطقة زمنية ترتيب الحادثة، وكيف ينجو السجل المركزي من المسح.](https://arabroot.io/articles/%D8%A7%D9%84%D8%B3%D8%AC%D9%84%D8%A7%D8%AA-%D8%A7%D9%84%D8%A7%D9%85%D9%86%D9%8A%D8%A9-logs-%D9%85%D8%A7%D8%B0%D8%A7-%D8%AA%D8%AC%D9%85%D8%B9-%D9%88%D9%85%D9%86-%D8%A7%D9%8A%D9%86-%D9%82%D8%A8%D9%84-soc/)[![](https://arabroot.io/content/images/2026/10/soc-triage-cover-cover.webp)دليليوم محلل SOC: فرز التنبيهات Alert Triage من التنبيه إلى القرارستة عشر تنبيهاً حقيقياً من Wazuh وSuricata نفرزها واحداً واحداً بالإثراء من Zeek حتى القرار والتصعيد.](https://arabroot.io/articles/%D9%8A%D9%88%D9%85-%D9%85%D8%AD%D9%84%D9%84-soc-%D9%81%D8%B1%D8%B2-%D8%A7%D9%84%D8%AA%D9%86%D8%A8%D9%8A%D9%87%D8%A7%D8%AA-%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D9%86%D8%A8%D9%8A%D9%87-%D8%A7%D9%84%D9%89-%D8%A7%D9%84%D9%82%D8%B1%D8%A7%D8%B1/)[![](https://arabroot.io/content/images/2026/10/mitre-attack-cover-cover.webp)دليلMITRE ATT&CK: كيف يفكر المهاجم خطوة بخطوةلغة موحدة لسلوك المهاجمين مبنية على حوادث موثقة، نقرأ بها هجوم فدية حقيقياً مرحلة بمرحلة ونربط كل خطوة بالدفاع المقابل.](https://arabroot.io/articles/mitre-attack-%D9%83%D9%8A%D9%81-%D9%8A%D9%81%D9%83%D8%B1-%D8%A7%D9%84%D9%85%D9%87%D8%A7%D8%AC%D9%85-%D8%AE%D8%B7%D9%88%D8%A9-%D8%A8%D8%AE%D8%B7%D9%88%D8%A9/)[![](https://arabroot.io/content/images/2026/10/pentest-methodology-cover-cover.webp)دليلاختبار الاختراق المصرح به: المنهجية والإذن والتقريريواجه مسؤول نظم طلب المستشفى باختبار اختراق سنوي، فنرافقه وهو يفهم الإذن والنطاق وقواعد الاشتباك وبنية التقرير قبل أن يبدأ.](https://arabroot.io/articles/%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%AE%D8%AA%D8%B1%D8%A7%D9%82-%D8%A7%D9%84%D9%85%D8%B5%D8%B1%D8%AD-%D8%A8%D9%87-%D8%A7%D9%84%D9%85%D9%86%D9%87%D8%AC%D9%8A%D8%A9-%D9%88%D8%A7%D9%84%D8%A7%D8%B0%D9%86-%D9%88%D8%A7%D9%84%D8%AA%D9%82%D8%B1%D9%8A%D8%B1/)[![](https://arabroot.io/content/images/2026/10/kali-red-team-cover-cover.webp)دليلKali Linux في Docker وأدوات الفريق الأحمر الأساسيةنرافق مسؤول نظم وهو يبني محطة Kali في Docker ويوجه أدواتها إلى مختبر يملكه، فيكشف gobuster مجلدات مخفية وتجد hydra كلمة مرور ضعيفة.](https://arabroot.io/articles/kali-linux-%D9%81%D9%8A-docker-%D9%88%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D8%A7%D9%84%D9%81%D8%B1%D9%8A%D9%82-%D8%A7%D9%84%D8%A7%D8%AD%D9%85%D8%B1/) ## سجل التحديثات - أكتوبر 2026: كتابة المقال، وتشغيل أساليب مختارة من Atomic Red Team يوم 28 أكتوبر 2026 في Container debian:trixie-slim معزولة بلا شبكة، والتحقق من الكشف بسكربت على Python 3.13.17.