> ## 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. # تحليل ذاكرة الجهاز Memory Forensics مع Volatility 3 - URL: https://arabroot.io/articles/تحليل-ذاكرة-الجهاز-memory-forensics-مع-volatility-3/ - Published: 2026-10-25T20:02:52.000Z - Updated: 2026-10-26T05:51:23.000Z - Description: حللنا نسختي ذاكرة رسميتين من سيرفر Debian وجهاز Windows 10، فاستخرجنا البرامج والاتصالات وأوامر Bash، ورأينا أين تخطئ malfind. - Author: فريق عرب رووت - Tags: الأدلة التقنية, الأمن السيبراني, لينكس والسيرفرات, Volatility المخترق الذي يعرف عمله يحاول ألا يترك شيئاً على القرص، فيشغل برنامجه من الذاكرة، ويمسح سجل الأوامر، ويحذف الملف بعد تشغيله. ولكن ما دام البرنامج يعمل فهو موجود في ذاكرة الجهاز RAM، ومعه اتصالاته والأوامر التي كتبها في الـ Shell. وفي دليل [أدوات التحقيق الرقمي مفتوحة المصدر](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/) ثبتنا Volatility 3 وعرضنا أشهر إضافاته، ووعدنا بمقال نحلل فيه نسخة ذاكرة حقيقية خطوة خطوة، وهذا هو المقال. وسوف نعمل على عينتين عامتين ينشرهما فريق Volatility نفسه في مستودع بيانات الاختبار، الأولى من سيرفر Debian والثانية من جهاز Windows 10 على Azure، فتستطيع أن تنزلهما وتعيد كل أمر في المقال وتحصل على المخرج نفسه. 📚 المواضيع في السلسلة: (1) التحقيق الرقمي والاستجابة للحوادث DFIR للمبتدئين. (2) أدوات التحقيق الرقمي مفتوحة المصدر. (3) البحث عن آثار الاختراق في كل السيرفرات مع Velociraptor. (4) تحليل ذاكرة الجهاز Memory Forensics مع Volatility 3 (الموضوع الحالي). (5) الخط الزمني للحادث Timeline مع Plaso وTimesketch. (6) فحص سيرفر Linux مخترق دون أن تفسد الأدلة. [![](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/) وسوف نتناول في هذا المقال ما يلي: - من أين تأتي العينتان وكيف تتحقق من أنهما لم تتغيرا. - كيف يقرأ Volatility ملف الذاكرة، ولماذا يحتاج جدول رموز Symbols، وأين يتعثر أغلب المبتدئين. - تحليل ذاكرة Linux: البرامج، والاتصالات، وسجل Bash من الذاكرة، والبحث عن Rootkit في النواة. - تحليل ذاكرة Windows: الشجرة والاتصالات وسطر الأوامر، وmalfind ونتائجها الخاطئة. - الوقت والذاكرة التي احتاجتها كل إضافة، وما الذي يناسب جهاز التحليل. ## العينتان ومن أين جاءتا أكثر ما يتعب من يتعلم تحليل الذاكرة هو العثور على عينة يعرف مصدرها، فأغلب الملفات المتداولة في المقالات القديمة مرفوعة على مواقع مشاركة ملفات لا تعرف من رفعها، وبعضها من مسابقات CTF فيها قصص مصنوعة. والمصدر الذي اخترناه هو مستودع [volatility3-test-data](https://github.com/volatilityfoundation/volatility3-test-data?ref=arabroot.io) من مؤسسة Volatility، وفيه العينات التي يختبر بها الفريق كل تعديل على الكود قبل دمجه، ومعها ملفات الهاش وحزم الرموز. واخترنا منه ملفين: | الملف | النظام | الحجم بعد فك الضغط | وقت أخذ النسخة | | -------------------------- | ---------------------------------- | ------------------ | -------------- | | linux-sample-1.bin | Debian 7، النواة 3.2.0-4-amd64 | 512 MiB | 24 يونيو 2014 | | win-10\_19041-2025\_03.dmp | Windows 10 الإصدار 19041 على Azure | 1.95 GiB | 6 مارس 2025 | ولاحظ أن المستودع لا يقول ما الذي حدث على هذين الجهازين قبل أخذ النسخة، فهما ليسا قضية لها حل معروف، وهذا أقرب لعملك الحقيقي، فأنت تفتح الملف ولا تعرف ماذا سوف تجد. والسيرفر Debian 7 قديم بالطبع، ولكن الخطوات نفسها هي التي سوف تنفذها على نواة حديثة، والفرق الوحيد في ملف الرموز كما سيأتي. نزلنا الملفات من صفحة [الإصدار v0.0.1](https://github.com/volatilityfoundation/volatility3-test-data/releases/tag/v0.0.1?ref=arabroot.io) وقارنا الهاش بالملف `SHA256SUMS` في المستودع قبل أي شيء آخر: ```bash B=https://github.com/volatilityfoundation/volatility3-test-data/releases/download/v0.0.1 for f in linux-sample-1.bin.gz linux.zip win-10_19041-2025_03.dmp.gz symbols_win-10_19041-2025_03.zip; do curl -sLO "$B/$f" done curl -sL https://raw.githubusercontent.com/volatilityfoundation/volatility3-test-data/main/images/SHA256SUMS curl -sL https://raw.githubusercontent.com/volatilityfoundation/volatility3-test-data/main/symbols/SHA256SUMS sha256sum *.gz *.zip ``` ```text 910f272e5eeecdbf229e648d7b136a6722a11a5000f3995647364339417dfddd linux-sample-1.bin.gz 58bb7da2ed1e491ce922d04a59881d201e233b5605c9fd5a7f0c08ee528253c6 linux.zip abd6500fba6a59c9a7c21f2c4b8a4d7edc2da417ec3161311a19a0e0beffd94e symbols_win-10_19041-2025_03.zip b377ecd13bf40c90f59a8c41ffc8bc81166462627a7800ec82a67a73520c7f9d win-10_19041-2025_03.dmp.gz ``` تطابقت القيم الأربع مع ما في المستودع، ثم فككنا الضغط وحسبنا الهاش للملفين بعد فك الضغط، وهذه القيم هي التي تكتبها في ملاحظات القضية، لأنها هاش الدليل الذي سوف تعمل عليه فعلاً: ```bash gunzip linux-sample-1.bin.gz win-10_19041-2025_03.dmp.gz sha256sum linux-sample-1.bin win-10_19041-2025_03.dmp ``` ```text 8ce57b7c7b423173ce970fe8f51e7016c04ef1b4a5f73d5c5f1001d5c18780bc linux-sample-1.bin ef92b50aa2ba2f830e3f816eb55ed8d15b0658fdfff0ab7af8adb68f2c8da460 win-10_19041-2025_03.dmp ``` ## بيئة التحليل شغلنا Volatility في Container من `python:3.12-slim`، وربطنا مجلد العينات للقراءة فقط `:ro`، والسبب أن الأداة لا يجب أن تكتب على الدليل أبداً، ولو أخطأت في أمر فالنظام نفسه يمنعها. وجعلنا للرموز مجلداً مستقلاً وللمخرج مجلداً ثالثاً: ```bash docker run -d --name scf-vol \ -v "$PWD/data":/evidence:ro -v "$PWD/symbols":/symbols:ro -v "$PWD/out":/out \ python:3.12-slim sleep infinity docker exec scf-vol pip install volatility3==2.28.2 docker exec scf-vol vol -h | head -1 ``` ```text Volatility 3 Framework 2.28.2 ``` الإصدار 2.28.2 هو آخر إصدار من [Volatility 3](https://github.com/volatilityfoundation/volatility3/releases/tag/v2.28.2?ref=arabroot.io) وصدر في 17 سبتمبر 2026، وآخر تعديل على الكود كان في 12 أكتوبر 2026\. والرخصة هي [Volatility Software License](https://www.volatilityfoundation.org/license/vsl-v1.0?ref=arabroot.io) وليست رخصة مفتوحة المصدر معتمدة، فالكود منشور ويمكنك استخدامه في عملك وفي قضاياك، ولكن اقرأ شروطها إذا كنت سوف تدمجه في منتج تبيعه. ## كيف يقرأ Volatility ملف الذاكرة؟ ملف الذاكرة بايتات بلا أسماء ملفات ولا جداول، فالنواة Kernel تحفظ قائمة البرامج في هياكل Structures مرتبطة ببعضها بمؤشرات، ومكان كل حقل في كل هيكل يختلف من نسخة نواة إلى أخرى. ولذلك يحتاج Volatility شيئين: الطبقات Layers التي تحول العناوين الافتراضية إلى أماكن في الملف، وجدول الرموز Symbol Table الذي يقول له أين يبدأ كل هيكل وما حجم كل حقل فيه. والصورة التالية تبين ذلك: ![ملف الذاكرة يمر بثلاث طبقات ثم يجتمع مع جدول الرموز في الإضافات التي تخرج جدول نتائج](https://arabroot.io/content/images/2026/10/volatility-lab-01-layers.webp) الطبقات تقرأ البايتات، والرموز تعطيها المعنى، والإضافات تمشي في الهياكل والرموز تأتي بصيغة ISF، وهي ملف JSON، ومصدرها يختلف بين النظامين: - **Windows:** تنشر Microsoft ملفات PDB لكل نسخة نواة على [سيرفر الرموز العام](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/microsoft-public-symbols?ref=arabroot.io)، وVolatility ينزل الملف المناسب ويحوله وحده، بشرط أن يصل جهاز التحليل إلى الإنترنت. - **Linux:** لا يوجد سيرفر مثل هذا، وعليك أن تبني ملف الرموز بنفسك بأداة [dwarf2json](https://github.com/volatilityfoundation/dwarf2json?ref=arabroot.io) من ملف `vmlinux` فيه معلومات التصحيح Debug Symbols للنواة نفسها بالضبط، أي الإصدار نفسه ورقم البناء نفسه. والتفصيل في صفحة [جداول الرموز](https://volatility3.readthedocs.io/en/latest/symbol-tables.html?ref=arabroot.io) في التوثيق. وفي هذه العينات وفر الفريق حزم الرموز جاهزة، فوضعناها في المجلد `/symbols` بالترتيب الذي يتوقعه Volatility، أي `linux/` لملفات Linux و`windows/ntkrnlmp.pdb//` لملف Windows. ## تحليل ذاكرة سيرفر Linux ### أي نواة هذه؟ أول سؤال على ملف Linux هو نسخة النواة، لأنك لن تستطيع أن تفعل شيئاً قبل أن تجد لها ملف رموز. والإضافة `banners.Banners` تبحث في الملف عن النص الذي تطبعه النواة عند الإقلاع: ```bash vol -q -f /evidence/linux-sample-1.bin banners.Banners ``` ```text Offset Banner 0x1400070 Linux version 3.2.0-4-amd64 (debian-kernel@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.57-3+deb7u2 ``` النواة 3.2.0-4-amd64 بالبناء 3.2.57-3+deb7u2، وفي حزمة الرموز ملف بهذا الاسم بالضبط `Debian_3.2.57-3+deb7u2_3.2.0-4-amd64_x64.json.xz`. وقد استغرق البحث 54 ثانية على ملف حجمه 512 MiB، لأنه يقرأ الملف كاملاً. ### ماذا يحدث بدون ملف الرموز؟ قبل أن نعطيه الرموز، جربنا أن نطلب قائمة البرامج مباشرة، وهذا ما سوف تراه أنت غالباً في أول محاولة على سيرفر حقيقي: ```bash vol -q -f /evidence/linux-sample-1.bin linux.pslist.PsList ``` ```text Unsatisfied requirement plugins.PsList.kernel.layer_name: Unsatisfied requirement plugins.PsList.kernel.symbol_table_name: A translation layer requirement was not fulfilled. Please verify that: A file was provided to create this layer (by -f, --single-location or by config) The file exists and is readable The file is a valid memory image and was acquired cleanly A symbol table requirement was not fulfilled. Please verify that: The associated translation layer requirement was fulfilled You have the correct symbol file for the requirement The symbol file is under the correct directory or zip file The symbol file is named appropriately or contains the correct banner ``` الرسالة تذكر الطبقة والرموز معاً، وقد تظن أن الملف تالف، ولكن السبب الحقيقي هنا هو الرموز وحدها، فالطبقة الافتراضية للنواة لا يمكن بناؤها في Linux قبل معرفة الرموز. والحل الأنسب ألا تنتظر الحادثة لتبحث عن الرموز، وإنما أن تبني ملف الرموز لكل نسخة نواة في سيرفراتك مسبقاً وتحفظه مع حقيبة الاستجابة، والسبب أن السيرفر بعد الحادثة قد يكون محدثاً أو معاد البناء، فلا تجد حزمة التصحيح للنسخة القديمة بسهولة. ### البرامج العاملة وشجرتها أعدنا الأمر مع الخيار `-s /symbols`: ```bash vol -q -s /symbols -f /evidence/linux-sample-1.bin linux.pslist.PsList ``` فظهرت 133 عملية في 37 ثانية، وهذه آخر الأسطر بعد حذف بعض الأعمدة: ```text PID PPID COMM UID CREATION TIME 3976 3968 bash 1000 2014-06-24 10:36:40.116245 UTC 8099 2 flush-8:0 0 2014-06-24 12:02:44.857271 UTC 8105 2 kworker/0:1 0 2014-06-24 12:10:16.003074 UTC 8471 2575 sleep 0 2014-06-24 12:52:39.968178 UTC 8492 2 kworker/0:2 0 2014-06-24 12:55:34.003716 UTC 8497 3373 sshd 0 2014-06-24 12:58:52.986083 UTC 8502 8497 sshd 1001 2014-06-24 12:58:55.472387 UTC 8503 8502 bash 1001 2014-06-24 12:58:55.474586 UTC 8599 3976 sudo 0 2014-06-24 13:00:21.592988 UTC 8600 8599 bash 0 2014-06-24 13:00:21.598157 UTC 8601 2 kworker/0:0 0 2014-06-24 13:00:36.003136 UTC ``` الترتيب حسب وقت الإنشاء يعطيك قصة الجلسة الأخيرة: دخول عبر SSH في 12:58:52 لمستخدم رقمه 1001، ثم Shell بصلاحية root من الطرفية الرسومية في 13:00:21\. ولمعرفة من هو المستخدم 1001 وما الذي شغله، نستخدم `linux.psaux.PsAux` الذي يعرض سطر الأوامر كاملاً، و`linux.pstree.PsTree` الذي يرتب البرامج حسب الأب: ```text PID PPID COMM ARGS 8497 3373 sshd sshd: mark [priv] 8502 8497 sshd sshd: mark@pts/1 8503 8502 bash -bash 8599 3976 sudo sudo bash 8600 8599 bash bash * 0x88001d375840 3373 3373 1 sshd ** 0x88001d06c800 8497 8497 3373 sshd *** 0x88001d3a7180 8502 8502 8497 sshd **** 0x88001ac9c740 8503 8503 8502 bash ``` المستخدم اسمه mark، دخل على الطرفية الثانية pts/1\. ولاحظ أن سطر الأوامر لبرامج sshd يظهر فيه اسم المستخدم لأن sshd يغير اسمه بنفسه ليسهل عليك متابعته، وهذا من عادات البرامج التي يجب أن تعرفها، لأن المخترق يستطيع أن يفعل الشيء نفسه فيغير سطر أوامر برنامجه ليبدو مثل `[kworker/0:1]`. ### الاتصالات الإضافة `linux.sockstat.Sockstat` تعرض كل Socket مفتوح لكل برنامج، وهي 1021 سطراً في هذا الملف أغلبها Unix Sockets بين برامج الجهاز نفسه، فاخترنا منها اتصالات الشبكة القائمة: ```bash vol -q -s /symbols -f /evidence/linux-sample-1.bin linux.sockstat.Sockstat > sockstat.txt awk -F'\t' '$7 ~ /AF_INET/ && $14=="ESTABLISHED"' sockstat.txt | cut -f2,3,9-14 ``` ```text sshd 8497 TCP 192.168.201.161 22 192.168.201.1 59982 ESTABLISHED sshd 8502 TCP 192.168.201.161 22 192.168.201.1 59982 ESTABLISHED ``` اتصال واحد فقط، وهو جلسة mark من العنوان 192.168.201.1، وهذا العنوان في الغالب جهاز المضيف لأن السيرفر نفسه 192.168.201.161 على الشبكة نفسها وكرت الشبكة من VMware كما يظهر من بداية عنوان MAC في `linux.ip.Addr`: ```text NetNS Index Interface MAC Promiscuous IP Prefix Scope Type State - 2 eth0 00:0c:29:8f:ed:ca False 192.168.201.161 24 global UP ``` ولاحظ العمود Promiscuous، فلو كانت قيمته True لكان كرت الشبكة يلتقط كل ما يمر عليه، وهذا ما يفعله برنامج تنصت Sniffer، فهو سؤال يستحق أن تنظر إليه في كل سيرفر. ### سجل Bash من الذاكرة هذه الإضافة من أهم ما يقدمه تحليل الذاكرة لسيرفرات Linux، فهي تقرأ سجل الأوامر من ذاكرة كل عملية Bash مباشرة، وليس من الملف `.bash_history`، فإذا مسح المخترق الملف أو منع الكتابة فيه بقيت أوامره في الذاكرة ما دامت الجلسة مفتوحة: ```bash vol -q -s /symbols -f /evidence/linux-sample-1.bin linux.bash.Bash ``` ```text PID Process CommandTime Command 3976 bash 2014-06-24 10:36:40.000000 UTC su 3976 bash 2014-06-24 10:36:40.000000 UTC sudo bash 3976 bash 2014-06-24 10:36:42.000000 UTC sudo bash 3976 bash 2014-06-24 10:37:19.000000 UTC su 3976 bash 2014-06-24 12:44:41.000000 UTC svn co http://lime-forensics.googlecode.com/svn/trunk lime 3976 bash 2014-06-24 12:45:09.000000 UTC ls 3976 bash 2014-06-24 12:45:09.000000 UTC cd lime 3976 bash 2014-06-24 12:45:10.000000 UTC cd src 3976 bash 2014-06-24 12:45:11.000000 UTC clear 3976 bash 2014-06-24 12:45:11.000000 UTC ls 3976 bash 2014-06-24 12:45:13.000000 UTC make 3976 bash 2014-06-24 12:45:17.000000 UTC clear 3976 bash 2014-06-24 12:48:14.000000 UTC ls 3976 bash 2014-06-24 12:48:22.000000 UTC history 3976 bash 2014-06-24 12:48:40.000000 UTC sudo bash 3976 bash 2014-06-24 12:49:00.000000 UTC su 3976 bash 2014-06-24 12:55:17.000000 UTC sudo bash 3976 bash 2014-06-24 12:57:37.000000 UTC ifconfig 3976 bash 2014-06-24 12:57:53.000000 UTC /sbin/ifconfig 3976 bash 2014-06-24 13:00:22.000000 UTC sudo bash 8503 bash 2014-06-24 12:59:50.000000 UTC sudo 8503 bash 2014-06-24 12:59:52.000000 UTC sudo bash 8503 bash 2014-06-24 13:00:02.000000 UTC su 8503 bash 2014-06-24 13:00:12.000000 UTC cat /etc/passwd 8503 bash 2014-06-24 13:00:17.000000 UTC cat /etc/group 8600 bash 2014-06-24 13:00:22.000000 UTC halt 8600 bash 2014-06-24 13:00:22.000000 UTC exit ``` في المخرج أعلاه لاحظ التالي: - الجلسة 3976 نزلت أداة LiME لأخذ نسخة الذاكرة وبنتها بالأمر `make` على الجهاز نفسه، وهذا يفسر وجود العينة. ولكن هذا ما لا يجب أن تفعله في حادثة حقيقية، والسبب أن التنزيل والبناء يكتبان ملفات على قرص الجهاز المشكوك فيه وقد يكتبان فوق ملفات محذوفة تحتاجها، فابن الأداة مسبقاً على جهاز مماثل وشغلها من قرص خارجي، كما ذكرنا في دليل [التحقيق الرقمي للمبتدئين](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/). - الأوامر الأربعة الأولى في الجلسة 3976 تحمل الوقت 10:36:40 و10:36:42 و10:37:19، وهو قريب جداً من وقت بدء الجلسة نفسها، والسبب أن Bash يقرأ الأوامر القديمة من ملف السجل عند بدء الجلسة ويعطيها ذلك الوقت، فلا تبن استنتاجاً على وقت أمر قبل أن تميز بين ما قرئ من الملف وما كتب في الجلسة. - المستخدم mark الذي دخل عبر SSH جرب `sudo` و`su` ثم قرأ `/etc/passwd` و`/etc/group`. ولا يوجد في شجرة البرامج أي Shell بصلاحية root تحت جلسته، فالظاهر أن محاولاته لم تعطه صلاحيات، ولكن الذاكرة وحدها لا تجيب هل نجحت `su` ثم خرج، والجواب في سجل الدخول على القرص `/var/log/auth.log`، وهذا مثال لماذا تحتاج الذاكرة والقرص معاً. - الجلسة 8600 بصلاحية root كتبت `halt` لإيقاف الجهاز، وهو آخر ما حدث قبل أخذ النسخة. ### هل في النواة Rootkit؟ البرنامج الذي يخفي نفسه بشكل جاد لا يكتفي بتغيير اسمه، وإنما يحمل وحدة نواة Kernel Module تعدل جدول دوال النظام System Call Table حتى لا يراه `ps` ولا `ls`، وهذا ما يسمى Rootkit. وفي Volatility ثلاث إضافات لهذا السؤال، فشغلناها: ```bash vol -q -s /symbols -f /evidence/linux-sample-1.bin linux.malware.hidden_modules.Hidden_modules vol -q -s /symbols -f /evidence/linux-sample-1.bin linux.malware.check_syscall.Check_syscall > syscall.txt awk -F'\t' 'NR>4 && $5=="UNKNOWN"' syscall.txt | wc -l vol -q -s /symbols -f /evidence/linux-sample-1.bin linux.lsmod.Lsmod ``` - `hidden_modules` لم يجد أي وحدة مخفية من قائمة الوحدات. - `check_syscall` عرض 661 مدخلاً في جداول دوال النظام، وكل مدخل يشير إلى دالة معروفة في النواة مثل `sys_read`، ولا يوجد أي مدخل يشير إلى عنوان غير معروف UNKNOWN، وهذا ما تبحث عنه، لأن الدالة التي يضعها الـ Rootkit تكون خارج النواة الأصلية. - `lsmod` عرض 79 وحدة كلها من وحدات Debian المعروفة، ولا توجد بينها وحدة LiME، أي أنها أزيلت بعد أخذ النسخة أو أن النسخة أخذت بطريقة أخرى، والمستودع لا يذكر ذلك. وشغلنا أيضاً `linux.malware.malfind.Malfind` الذي يبحث عن مناطق ذاكرة قابلة للكتابة والتنفيذ معاً في كل برنامج، فلم يجد شيئاً، وقد استغرق وحده 149 ثانية، أي أطول من كل الإضافات الأخرى مجتمعة. ## تحليل ذاكرة Windows 10 ### معلومات النظام والرموز في Windows لا تحتاج أن تعرف النسخة مسبقاً، فالإضافة `windows.info` تبحث عن توقيع ملف PDB الخاص بالنواة داخل الذاكرة، ثم تبحث عن ملف الرموز المناسب. وشغلناها أولاً بالخيار `--offline` ومعها مجلد الرموز الجاهز: ```bash vol -q --offline -s /symbols -f /evidence/win-10_19041-2025_03.dmp windows.info.Info ``` ```text Variable Value Kernel Base 0xf8043601f000 DTB 0x6d4000 Symbols file:///symbols/windows/ntkrnlmp.pdb/167FE94B5641C005AC3036212A01F8DC-1.json Is64Bit True IsPAE False layer_name 0 WindowsIntel32e memory_layer 1 WindowsCrashDump64Layer base_layer 2 FileLayer NTBuildLab 19041.1.amd64fre.vb_release.1912 Major/Minor 15.19041 KeNumberProcessors 1 SystemTime 2025-03-06 17:59:20+00:00 NtSystemRoot C:\Windows NtProductType NtProductWinNt ``` الملف من نوع Crash Dump، وهو الشكل الذي يكتبه Windows نفسه عند الانهيار وتكتبه بعض أدوات النسخ، وVolatility تعرف ذلك وحدها فتضع الطبقة `WindowsCrashDump64Layer`. والوقت `SystemTime` هو وقت أخذ النسخة، وهذا الرقم أول ما تكتبه في التقرير. ثم جربنا ما يحدث بدون مجلد الرموز. مع `--offline` ظهرت رسالة الرموز نفسها التي رأيناها في Linux، وبدون `--offline` نزل Volatility الملف وحده من سيرفر Microsoft: ```text Downloading http://msdl.microsoft.com/download/symbols/ntkrnlmp.pdb/167FE94B5641C005AC3036212A01F8DC1/ntkrnlmp.pdb ``` ثم حوله وحفظ الناتج في مجلد الرموز داخل مكتبة Python نفسها بحجم 578 KiB مضغوطاً، واستغرق التشغيل الأول كله نحو خمس دقائق، بينما استغرق `windows.pslist` تسع ثوان عندما كان ملف الرموز موجوداً. وهذا مهم إذا كان جهاز التحليل معزولاً عن الإنترنت كما يجب أن يكون في القضايا الحساسة، فعليك أن تجهز ملفات الرموز لنسخ Windows عندك مسبقاً، أو أن تسمح لجهاز التحليل بالوصول إلى `msdl.microsoft.com` فقط. ### شجرة البرامج وسطر الأوامر أظهرت `windows.pslist` 120 عملية، والشجرة `windows.pstree` هي التي تعطيك المعنى، فهذه البرامج التي شغلها المستخدم من واجهة Windows: ```text *** 784 4912 cmd.exe 0x840f6fc19080 2025-03-06 17:51:44.000000 UTC N/A \Device\HarddiskVolume4\Windows\System32\cmd.exe **** 3896 784 conhost.exe 0x840f6fc35080 2025-03-06 17:51:49.000000 UTC N/A \Device\HarddiskVolume4\Windows\System32\conhost.exe *** 2968 4912 notepad.exe 0x840f70106080 2025-03-06 17:52:33.000000 UTC N/A \Device\HarddiskVolume4\Windows\System32\notepad.exe ``` الأب 4912 هو `explorer.exe`، أي أن المستخدم فتحهما بنفسه، والمسار هو مسار النظام الصحيح. وفي التحقيق الحقيقي تسأل نفسك عن كل برنامج: هل الأب منطقي؟ فـ `cmd.exe` تحت `explorer.exe` طبيعي، أما تحت `w3wp.exe` وهو خادم IIS، أو تحت `winword.exe`، فهذا من أوضح علامات الاختراق. ثم `windows.cmdline` لسطر الأوامر: ```text 912 sshd.exe "C:\Program Files\OpenSSH\sshd.exe" 784 cmd.exe "C:\Windows\system32\cmd.exe" 2968 notepad.exe "C:\Windows\system32\notepad.exe" 7352 MpCmdRun.exe "C:\Program Files\Windows Defender\MpCmdRun.exe" SignatureUpdate -ScheduleJob -RestrictPrivileges -Reinvoke 5044 MpCmdRun.exe "C:\Program Files\Windows Defender\MpCmdRun.exe" SignaturesUpdateService -ScheduleJob -UnmanagedUpdate ``` لا يوجد شيء مشفر بـ Base64 بعد `powershell -enc`، ولا برنامج من `AppData\Local\Temp`، وهما أكثر ما تجده في حوادث Windows. وسألنا `windows.cmdscan` عن الأوامر المكتوبة في نافذة `cmd.exe` فأجاب بأنه لم يجد سجل أوامر في الـ conhost التابع لها، أي أن المستخدم فتح النافذة ولم يكتب فيها شيئاً قبل أخذ النسخة، أو أن السجل لم يعد في الذاكرة. ### الاتصالات ```bash vol -q --offline -s /symbols -f /evidence/win-10_19041-2025_03.dmp windows.netscan.NetScan > netscan.txt grep ESTABLISHED netscan.txt | cut -f2-10 ``` ```text TCPv4 10.0.0.4 49710 168.63.129.16 32526 ESTABLISHED 1908 WaAppAgent.exe 2025-03-06 17:50:18.000000 UTC TCPv4 10.0.0.4 49709 20.7.2.167 443 ESTABLISHED 1008 svchost.exe 2025-03-06 17:50:17.000000 UTC TCPv4 10.0.0.4 3389 10.1.130.4 41982 ESTABLISHED 1016 svchost.exe 2025-03-06 17:49:21.000000 UTC TCPv4 10.0.0.4 49679 168.63.129.16 32526 ESTABLISHED 1944 WindowsAzureGu 2025-03-06 17:49:50.000000 UTC TCPv4 10.0.0.4 49688 168.63.129.16 80 ESTABLISHED 1944 WindowsAzureGu 2025-03-06 17:50:02.000000 UTC TCPv4 10.0.0.4 49922 150.171.29.10 443 ESTABLISHED 5644 SearchApp.exe 2025-03-06 17:56:49.000000 UTC TCPv4 10.0.0.4 49749 20.7.2.167 443 ESTABLISHED 1008 svchost.exe 2025-03-06 17:51:21.000000 UTC ``` هنا تحتاج أن تعرف بيئتك حتى تفرق بين الطبيعي والغريب. فالعنوان 168.63.129.16 الذي يتصل به وكيل Azure هو [العنوان الثابت الذي توثقه Microsoft](https://learn.microsoft.com/en-us/azure/virtual-network/what-is-ip-address-168-63-129-16?ref=arabroot.io) لخدمات المنصة في كل جهاز افتراضي على Azure، والمنفذ 3389 هو جلسة سطح المكتب البعيد RDP من 10.1.130.4 داخل الشبكة الخاصة، وهي جلسة المستخدم الذي فتح cmd.exe وnotepad.exe. ولو رأيت المنفذ 3389 متصلاً بعنوان عام من الإنترنت لكان هذا أول ما تسأل عنه. ### malfind ونتائجها الخاطئة الإضافة `windows.malware.malfind` تبحث عن مناطق في ذاكرة البرامج صلاحيتها `PAGE_EXECUTE_READWRITE` وليست مرتبطة بملف على القرص، وهذا شكل الكود المحقون Injected Code الذي يكتبه المخترق في ذاكرة برنامج سليم. وعلى هذا الجهاز السليم أعطتنا ست نتائج: ```text PID Process Start VPN End VPN Tag Protection CommitCharge PrivateMemory 1944 WindowsAzureGu 0x1f6127d0000 0x1f6127dffff VadS PAGE_EXECUTE_READWRITE 2 1 1956 MsMpEng.exe 0x29ed9570000 0x29ed967cfff VadS PAGE_EXECUTE_READWRITE 269 1 1956 MsMpEng.exe 0x29ee1190000 0x29ee128ffff VadS PAGE_EXECUTE_READWRITE 256 1 1956 MsMpEng.exe 0x29ee6600000 0x29ee67fffff VadS PAGE_EXECUTE_READWRITE 512 1 1956 MsMpEng.exe 0x29ee6f50000 0x29ee705cfff VadS PAGE_EXECUTE_READWRITE 269 1 1956 MsMpEng.exe 0x29ee7610000 0x29ee771cfff VadS PAGE_EXECUTE_READWRITE 269 1 ``` خمس منها في `MsMpEng.exe`، وهو محرك Microsoft Defender نفسه، وواحدة في وكيل Azure. وهذه نتائج خاطئة False Positives معروفة، والسبب أن البرامج التي تولد الكود أثناء التشغيل JIT، مثل محرك مكافحة الفيروسات الذي يحاكي البرامج التي يفحصها وتطبيقات .NET مثل وكيل Azure، تحتاج ذاكرة قابلة للكتابة والتنفيذ معاً بشكل مشروع. وإذا نظرت إلى البايتات في المخرج الكامل تجد في مناطق MsMpEng تعليمات حفظ السجلات المعتادة في بداية الدوال `push rsi; push rdi; push rbx…` ومناطق مملوءة بالقيمة `cc`، وليس شكل ملف PE ولا Shellcode معروف. ولذلك لا تقم بإرسال نتيجة malfind في تقرير قبل أن تسأل: ما هذا البرنامج؟ وهل يولد كوداً أثناء التشغيل؟ وماذا في البايتات؟ ثم احفظ المنطقة بالخيار `--dump` وافحصها بقواعد YARA أو بأداة تحليل قبل أن تحكم. وأخيراً شغلنا `windows.malware.psxview` الذي يقارن قائمة البرامج من أربعة مصادر مختلفة داخل النواة، والفكرة أن البرنامج الذي يخفي نفسه من قائمة واحدة يظهر في غيرها. وكانت الفروق كلها لبرامج انتهت قبل أخذ النسخة، مثل `userinit.exe` و`MpCmdRun.exe` الذي ظهر في المسح psscan وحده ومعه وقت انتهائه، أو لبرامج النظام مثل `System` و`csrss.exe` التي لا تظهر في عمود csrss بطبيعتها. ## ترتيب الأسئلة الصورة التالية تجمع الأسئلة الخمسة التي سألناها بالترتيب، وما أجابت به كل عينة: ![جدول من خمس خطوات لفحص ملف الذاكرة مع ما ظهر في عينة Linux وعينة Windows في كل خطوة](https://arabroot.io/content/images/2026/10/volatility-lab-02-triage.webp) من السؤال الواسع إلى الضيق: البرامج، ثم الاتصالات، ثم الأوامر، ثم الكود المحقون، ثم النواة ولاحظ أن الترتيب يبدأ بالأسرع والأوضح، فقائمة البرامج تأخذ ثوان، وmalfind وpsxview يأخذان دقائق، والسبب أنك في حادثة حقيقية تريد أن تعرف بسرعة إلى أين تنظر قبل أن تشغل الإضافات الثقيلة. وإذا أردت أن تجمع المخرج في أداة أخرى فاستخدم الخيار `-r json` أو `-r csv` بدلاً من الجدول النصي، ومنه تستطيع أن تضعه في الخط الزمني للحادث كما سوف نرى في المقال القادم. ## الوقت والذاكرة على جهاز التحليل قسنا وقت كل إضافة في المختبر على ملف من الملفين، والأرقام تتغير حسب سرعة القرص والمعالج، ولكنها تعطيك الفكرة: | الإضافة | Linux (512 MiB) | Windows (1.95 GiB) | | ------------------ | --------------- | ------------------ | | banners / info | 54 ثانية | 53 ثانية | | pslist | 37 ثانية | 9 ثوان | | bash / cmdline | 8 ثوان | 21 ثانية | | sockstat / netscan | 38 ثانية | 144 ثانية | | malfind | 149 ثانية | 396 ثانية | | psxview | غير متوفرة | 464 ثانية | وعند إعادة تشغيل netscan وsockstat مع قياس الذاكرة، وصل أقصى استخدام للذاكرة إلى 247 MiB لـ netscan و351 MiB لـ sockstat، واستغرقا هذه المرة 317 و381 ثانية لأن الجهاز كان مشغولاً بأعمال أخرى. أي أن جهاز التحليل لا يحتاج ذاكرة كبيرة بالنسبة لحجم الملف، والذي يحدد الوقت هو قراءة القرص، فضع ملف الذاكرة على قرص SSD سريع، وحجز مساحة تكفي ضعف حجم الملف لما سوف تحفظه بالخيار `--dump`. أما البديل التجاري فمثاله Volcano من Volexity، وهي أداة تحليل ذاكرة بواجهة رسومية وتعاون بين المحللين، ولا تنشر سعرها، فالصفحة الرسمية تطلب [طلب عرض Demo](https://www.volexity.com/products-overview/volcano/?ref=arabroot.io) عند تاريخ كتابة المقال في 25 أكتوبر 2026. ## قبل أن تحتاجه في حادثة - **جهز الرموز:** لكل نسخة نواة Linux على سيرفراتك ابن ملف الرموز بـ dwarf2json الآن، واحفظه مع اسم النسخة، والسبب أنك لن تحلل أي شيء بدونه. وتابع [دليل البدء لـ Linux](https://volatility3.readthedocs.io/en/latest/getting-started-linux-tutorial.html?ref=arabroot.io) في التوثيق. - **جهز أداة النسخ:** [AVML](https://github.com/microsoft/avml?ref=arabroot.io) من Microsoft ملف تنفيذي واحد لا يحتاج بناء وحدة نواة، و[LiME](https://github.com/504ensicsLabs/LiME?ref=arabroot.io) يحتاج بناءها لكل نسخة نواة، فابنها مسبقاً على جهاز مماثل وليس على السيرفر المشكوك فيه. - **اكتب في القضية:** هاش ملف الذاكرة، ونسخة Volatility، وملف الرموز المستخدم، والأمر الكامل لكل إضافة، حتى يستطيع غيرك إعادة النتيجة. - **لا تحكم بإضافة واحدة:** كما رأينا في malfind، وكما رأينا في سجل Bash الذي يعطي الأوامر القديمة وقت بدء الجلسة. ## الخلاصة وصلنا لنهاية الموضوع، وأهم ما ظهر في المختبر: - العينات الرسمية في مستودع volatility3-test-data هي أسهل طريقة للتعلم بملفات معروفة المصدر، ومعها الهاش وحزم الرموز. - تحليل ذاكرة Linux يتوقف تماماً بدون ملف رموز للنواة نفسها، وWindows ينزل رموزه من Microsoft وحده إذا سمحت له بالإنترنت، فجهز الرموز قبل الحادثة. - سجل Bash في الذاكرة أظهر 27 أمراً من ثلاث جلسات، منها محاولات `sudo` و`su` لمستخدم دخل عبر SSH، وهذا ما لا تجده إذا مسح أحد ملف السجل. - malfind أعطى ست نتائج على جهاز Windows سليم، كلها في Defender ووكيل Azure، فكل نتيجة منها سؤال وليست حكماً. - الذاكرة تجيب عن «ما الذي كان يعمل الآن»، والقرص والسجلات تجيب عن «ما الذي حدث قبل ذلك»، والتحقيق يحتاج الاثنين. في المقال القادم بإذن الله سوف نجمع السجلات وأوقات الملفات ونتائج الذاكرة في خط زمني واحد مع Plaso وTimesketch. [![](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/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 - نزل العينة `win-xp-laptop-2005-06-25.img.gz` من المستودع نفسه، وشغل عليها `windows.pstree` و`windows.netscan`، وقارن ما تراه بجهاز Windows 10 في المقال. - شغل `linux.bash.Bash` على العينة مع الخيار `-r json`، واكتب سكربتاً صغيراً يفصل الأوامر التي تحمل وقت بدء الجلسة عن الأوامر المكتوبة بعدها. ## سجل التحديثات - أكتوبر 2026: كتابة الدليل وتحليل عينتي Linux وWindows 10 من مستودع volatility3-test-data يوم 25 أكتوبر 2026 على Volatility 3 الإصدار 2.28.2.