> For the complete documentation index, see [llms.txt](https://0xmedhat.gitbook.io/whoami/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://0xmedhat.gitbook.io/whoami/memory-forensics-notes.md).

# Memory forensics Notes

***

### 1. Volatile Memory

* **Volatile Memory** = الذاكرة المتطايرة (RAM).
* بتخزن بيانات النظام والمستخدم **وقت ما الجهاز شغال** (Processes, Files مفتوحة، Data متشفرة، إلخ).
* أول ما الجهاز يطفي أو يتعمله Restart → **كل البيانات بتروح**.

ليه مهمة؟\
لأنها بتكشفلك **الـ snapshot اللحظي** للجهاز: إيه اللي شغال دلوقتي، إيه الاتصالات، إيه البرامج، حتى الـ keys اللي في الـ RAM.

***

### 2. Memory Hierarchy 

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

1. **CPU Registers** → أسرع حاجة وأصغر سعة (الـ CPU بيستخدمها مباشرة).
2. **CPU Cache** → برضو سريع جدًا وصغير، بيقلل الوقت اللي بياخده البروسيسور عشان يوصل للـ RAM.
3. **RAM** → الذاكرة الرئيسية للتطبيقات والـ OS.
4. **Disk Storage** (HDD/SSD) → بطيء جدًا بس بيخزن بيانات طويلة المدى.

 كمان في مفهوم مهم:\
**Virtual Memory** = الـ OS بيدّي لكل برنامج عنوان افتراضي خاص بيه.

* العناوين دي ممكن تبقى متخزنة في **RAM**.
* لو الـ RAM مليانة → يتحول جزء منها لـ **Swap Space** (على الهارد).
* بالتالي بعض الـ Artifacts ممكن تكون موجودة في الـ RAM أو متسجّلة مؤقتًا في الـ Swap File.

***

### 3. RAM Structure

الـ RAM بتنقسم جزئين أساسيين:

* **Kernel Space**: للـ OS نفسه + الـ Drivers.
* **User Space**: للبرامج والـ Processes بتاعة المستخدم.

جوا الـ User Space نفسه:

* **Stack** → بيخزن حاجات مؤقتة زي function arguments و return addresses.
* **Heap** → بيخزن Dynamic allocations (objects, buffers) اللي البرامج بتنشئها وقت التشغيل.
* **Executable (.text section)** → الكود نفسه اللي الـ CPU بيشغله.
* **Data Sections** → للـ global variables والبيانات المطلوبة للكود.

 أهمية ده في الـ Forensics:

* Encryption keys ساعات بتكون في الـ Heap.
* أوامر Shell ممكن تلاقيها في الـ Stack.

***

### 4. RAM for Forensic Analysts

الـ RAM بتدي صورة لحظية (Snapshot) للنظام:

* إيه الـ processes اللي شغالة.
* إيه الـ executables اللي متحملة.
* إيه الـ network connections اللي مفتوحة.
* مين المستخدمين اللي لوج إن.
* أوامر اتنفذت قريب.
* محتوى متفك تشفيره (مثلاً Keys أو محتوى محمي).
* Fileless malware أو كود متحقن في Process.

 ده كله بيتبخر أول ما الجهاز يطفي → عشان كده لازم **نجمع الـ RAM Dump بدري جدًا** في التحقيق.

***

### 5. ليه مهم للـ Incident Response؟

* لأنه بيكشفلك Attackات مش بتكتب حاجة على الهارد (Fileless Malware).
* بيسمحلك تشوف Credential Theft techniques (زي ميميكاتز) اللي بتحصل كلها في الـ RAM.
* بيخليك تلحق تجمع الأدلة قبل ما تضيع بالـ shutdown.

***

### 1. Memory Dump 

* **Memory Dump = Snapshot للـ RAM** وقت معين.
* بيحتوي على:
  * الـ Processes الشغالة.
  * الـ Sessions المفتوحة.
  * النشاط الشبكي (Network activity).
  * بيانات حساسة (زي الـ credentials).
* المهاجمين  ممكن يستعملوا أدوات زي **Mimikatz** عشان يشفطوا credentials من الـ RAM → عشان كده لازم الـ Analysts يركزوا على الـ dumps.

***

### 2. إزاي بيتعمل Memory Dump؟

#### Windows:

* **Crash Dumps** (موجودة في `%SystemRoot%\MEMORY.DMP`).
* **Hibernation files** (`hiberfil.sys`) → بتخزن snapshot للـ RAM عند الـ Hibernate.
* Tools زي:
  * `WinPmem`
  * `FTK Imager`
  * `RAMMap` (من Sysinternals).

#### Linux/macOS:

* أدوات زي:
  * **LiME (Linux Memory Extractor)**.
  * **dd** مع `/dev/mem` أو `/proc/kcore`.

 الهدف: تعمل acquisition للـ RAM من غير ما تغيّر فيها كتير (forensically sound).

***

### 3. أنواع Memory Dumps

1. **Full Memory Dump**
   * بيشمل كل حاجة في الـ RAM (User + Kernel space).
   * مناسب للتحقيقات الكاملة أو تحليل Malware.
2. **Process Dump**
   * يجيب RAM بتاعت Process معينة بس.
   * مفيد في الـ Reverse Engineering أو تتبع Malware جوا app واحد.
3. **Pagefile/Swap Analysis**
   * الـ OS بينقل شوية RAM مؤقتًا للهارد لما بتتملي.
   * Windows: `pagefile.sys`
   * Linux: swap partition/swapfile.
   * ممكن تلاقي هناك بيانات fragments كانت في الـ RAM.
4. **Hibernation Dump**
   * Windows بيسجّل snapshot للـ RAM جوه `hiberfil.sys` عند Hibernate.
   * ممكن يتفك ويتحلل زي memory dump عادي.

***

### 4. Challenges في الـ Acquisition

المهاجم ممكن يستعمل Anti-Forensics techniques عشان يبوظ الـ dump أو يستخبى:

* **Unlinked/hidden modules**: malware يتشال من process list.
* **DKOM (Direct Kernel Object Manipulation)**: تعديل على kernel structures → يخفي processes/drivers.
* **Code Injection**: حقن كود خبيث جوه process شرعي (زي explorer.exe).
* **Memory Patching**: يغير محتوى الـ RAM أو APIs أثناء التشغيل → يديك بيانات غلط.
* **Hooking APIs/system calls**: يعترض استدعاءات (زي ReadProcessMemory) عشان يزوّر النتايج.
* **Encrypted/Packed payloads**: الـ payload يفضل متشفر أو compressed في الـ RAM ويفك نفسه بس وقت التنفيذ.
* **Trigger-based payloads**: مايتنفذش إلا لما شرط معين يحصل (زي وقت معين أو event) → صعب تكتشفه في snapshot عادي.

***

### 5. Implications للـ Forensic Analyst

* مش كل حاجة بتبان بسهولة → لازم تستعمل:
  * **Memory Carving** (البحث عن بقايا/strings/headers جوه الـ dump).
  * **Kernel-level inspection**.
  * **Behavior-based techniques** (تراقب سلوك بدل ما تعتمد بس على الـ structures).
* Encryption/Obfuscation = بيزودوا التعقيد، لازم تحلّل الـ RAM وقت الـ runtime مش snapshot static بس.

***

أهم الحاجات اللي ممكن تلاقيها في الـ RAM:

1. **Suspicious Processes**: عمليات شغالة مالهاش File فعلي على الهارد.
2. **DLL Injection**: كود خبيث متحقن في برنامج شرعي.
3. **Process Hollowing**: استبدال كود Process شرعي (زي svchost.exe) بكود Malicious.
4. **API Hooking**: اعتراض/تغيير استدعاءات النظام عشان يخبّي نشاط.
5. **Rootkits**: بتخفي نفسها (Files/Processes/Network connections) بالتلاعب بالـ Kernel structures.

 العلامات اللي تكشف ده:

* Memory regions غريبة (مثلاً Writable + Executable في نفس الوقت).
* PE Headers مش متطابقة.
* كود شغال في منطقة المفروض تبقى Data مش Code.

***

### 3. Credential Access (T1003)

* **Mimikatz** وأدوات زيها ممكن تسرّب Credentials من الـ LSASS (Process).
* في الـ RAM تقدر تلاقي:
  * الـ Hashes.
  * الـ Kerberos Tickets.
  * Plaintext creds ساعات.

***

### 4. Command & Control in Memory (T1071)

* Malware حديث بيشتغل Fileless ويكلم الـ C2 مباشرة من RAM.
* بيستخدم بروتوكولات عادية زي HTTP/HTTPS/DNS.
* في الـ RAM ممكن تلاقي:
  * Config مفكوك.
  * IPs أو Domains بتاعة الـ C2.
  * Beacons.

***

### 5. In-Memory Script Execution (T1086 – PowerShell)

* المهاجم يشغّل Script على طول من الـ RAM → مفيش أثر على الهارد.
* مثال: PowerShell, Python, WMI.
* في الـ RAM ممكن تلاقي:
  * محتوى الـ Script كامل.
  * أوامر Encoded (زي Base64).
  * Artifacts في الـ PowerShell process.

***

### 6. Persistence Techniques مرئية في الـ RAM

* **T1053.005 – Scheduled Task**
  * تلاقي `schtasks.exe` أو Strings فيها أسماء Tasks خبيثة.
* **T1543.003 – Malicious Services**
  * Services غريبة تحت `services.exe`، Config مش طبيعي.
* **T1547.001 – Registry Run Keys**
  * Entries في الـ Run Key (`HKCU\Software\Microsoft\Windows\CurrentVersion\Run`) متخزنة أو Cached في الـ RAM.

***

### 7. Lateral Movement Artifacts

* **T1021.002 – SMB / PsExec**
  * تلاقي Services أو أوامر PsExec (`psexecsvc.exe`).
* **T1021.006 – WinRM (wsmprovhost.exe)**
  * تلاقي آثار لفتح Remote Session.
* **T1059.001 – PowerShell Remote**
  * PowerShell process فيه أوامر Obfuscated/Base64.
* **T1047 – WMI**
  * Strings زي `wmic process call create` متخزنة في الـ RAM.

***

## Memory Acquisition 

### 1. العملية مش مجرد Dump

الـ Memory Acquisition مش بتبدأ لما تعمل Dump وبس، لكن قبليها لازم يكون عندك **Incident Response Plan** فيه:

* أي **Technique** هتستخدم؟ (محلي/عن بُعد/Hardware).
* أي **Tool**؟ (مجاني/تجاري).
* التوقيت المناسب.
* الجزء اللي محتاج تركز عليه من الذاكرة.
* إزاي تضمن **سلامة الأدلة** (Integrity).

***

### 2. اختيار الجزء المناسب من الذاكرة

مش دايمًا لازم تعمل Full Dump، وده يتوقف على الـ **IOC/IOA** اللي لقيتها:

* **Process Dump/Core Dump**: لو في Process واحدة بتستهلك CPU/MEMORY بشكل غريب → تعمل Dump للـ Process بس.
* **Full Memory Dump**: لو عندك C2 شغال أو Malware منتشر → تاخد RAM كاملة.
* **Hibernation File (hiberfil.sys)**: لو الجهاز دخل Hibernation بدل ما يطفي → الملف فيه Snapshot للـ RAM.
* **Pagefile/Swapfile**: تخزن بيانات من Processes متوقفة أو متنهية. مفيد جدًا مع Fileless Malware.
* **VM Memory Dump**: Snapshot/Save state من VM، تستخدمها في Sandbox أو Replay.

 الخلاصة: كل نوع Dump له Use Case. (أهمهم: Full Dump / Process Dump).

***

### 3. اختيار الـ File Format

مفيش Format قياسي عالمي → كل Tool له دعم معين:

* **.raw / .mem** → Raw dump، أنسب حاجة للتحليل (أكتر الأدوات بتدعمه).
* **.dmp** → Format بتاع Windows (ممكن يكون Mini, Kernel, أو Full).
* **.vmem, .vmsn, .vmss, .bin, .sav** → VM formats (VMware, Hyper-V).
* **.core** → Process dump في Linux (gcore أو crash dump).
* **.lime** → خاص بـ LiME (Linux Memory Extractor).
* **Expert Witness (.E01)** → EnCase format، قياسي في الـ Forensics.

***

### 4. تقنيات الاستخراج (Acquisition Techniques)

1. **Local Acquisition**:
   * توصل USB وتاخد Dump من الجهاز مباشرة.
   * مناسب للأجهزة اللي تقدر توصلها.
   * عيوب: احتمال الـ Storage يتلوث أو يتحمّل Malware.
2. **Remote Acquisition**:
   * تاخد Dump عن طريق Network.
   * مفيد للسيرفرات أو أجهزة مش متاحة فيزيائيًا.
   * مخاطرة: ممكن يتنقل الـ Malware للـ Collector.
3. **Hardware Acquisition**:
   * باستخدام PCIe Card (زي CaptureGUARD).
   * بيديك Dump من غير ما تدخل على الـ OS.
   * غالي جدًا بس بيحافظ على الـ Integrity.
4. **RAM Freezing**:
   * تبريد الرامات (Cold Boot Attack).
   * يخلي البيانات تثبت شوية عشان تنقلها لجهاز تاني وتعمل Dump.
   * تقني جدًا ونادر الاستخدام في التحقيقات العادية.

***

### 5. الأدوات 

#### مجاني

* **FTK Imager** (Memory + Disk image).
* **Magnet RAM Capture** 
* **DumpIt** 
* **WinPmem / LinuxPmem** 
* **LiME** (Linux Memory Extractor)

####  تجاري

* **EnCase Forensic** 
* **CaptureGUARD (PCIe)** (Hardware).
* **F-Response** (Remote acquisition).
* **Cellebrite UFED** (موبايل + Memory).

***

### 6. التوقيت 

الـ RAM دايمًا بتتغير → Snapshot لحظي. فلازم تختار الوقت الصح:

* **لو Lateral Movement**: راقب الجهاز ولما تلاقي نشاط غريب → اعمل Dump فورًا.
* **لو Fileless Malware**: أي سلوك مش طبيعي → Dump فورًا قبل ما يختفي.
* **لو Evidence Destruction**: لازم تكون سريع، قبل Restart أو Shutdown.

 ممنوع تاخد Dump أثناء:

* Bootup.
* Virus scan.
* Backup.\
  (لأن الـ Memory State بتتغير بسرعة وبيكون مليان Noise).

***

### 7. Integrity

* لازم يكون عندك **Admin Privileges**.
* احسب **Hashes (MD5/SHA256)** للـ Dump للتأكد من سلامة الأدلة.
* استخدم **Write Blocker أو Disposable System** عشان تمنع تلوث البيانات.
* لو Remote Capture → استخدم قنوات مشفرة (VPN, SSH).

\--

### Memory Acquisition on Windows

### Full Memory Capture باستخدام FTK Imager

* **الأداة**: FTK Imager → بتستخدم عشان تعمل **dump كامل للـ RAM**.
* **الخطوات**:
  1. تفتح البرنامج → File → Capture Memory.
  2. تختار مكان تحفظ فيه الملف (في الواقع بيكون external HDD/USB: .
  3. تسمية الملف: (مثلًا Hostname\_Date.mem → `FS-ANALYSIS_07April2025.mem`).
  4. تحدد إذا كنت عايز تضمّن **Pagefile** أو لأ (بيكون ضخم، لكنه أحيانًا مهم لأنه بيحتوي بقايا من العمليات اللي اتقفلت).
  5. تضغط Capture Memory → يبدأ يكتب ملف `.mem`.
* **ليه؟**\
  ده أنسب في حالة إنك شاكك في وجود **Malware running in RAM** أو **C2 connection** زي ما شرحنا في القسم اللي فات.
* **Integrity (النزاهة)**:\
  بعد ما تحفظ الملف → تروح PowerShell كـ Admin وتعمل:

  ```powershell
  Get-FileHash -Path 'C:\Users\Administrator\Documents\Full Memory Capture\FS-ANALYSIS-07April2025.mem' -Algorithm MD5
  ```

  وده بيرجعلك Hash (MD5). الفكرة إنك تكتب الـ Hash ده في تقريرك وتخزن نسخة من الملف. بعدين أي تحليل تعمله على نسخة، وتفضل محتفظ بالأصل.

***

###  ثانيًا: Process Dump باستخدام Procdump

* **الأداة**: Procdump (من Sysinternals Suite).
* **السيناريو**: هنا بنستهدف **lsass.exe** → ده أخطر Process في ويندوز لأنه بيحتوي **credentials, tokens, authentication secrets**. أي هجوم زي Mimikatz أو Pass-the-Hash بيجي من هنا.
* **الخطوات**:
  1. افتح PowerShell كـ Admin →

     ```powershell
     cd C:\TMP\SysinternalsSuite\
     ```
  2. نفذ:

     ```powershell
     .\procdump64.exe -ma lsass.exe C:\TMP -accepteula
     ```

     * `-ma` → full memory of the process.
     * `lsass.exe` → المستهدف.
     * `C:\TMP` → مكان الحفظ.
  3. الملف الناتج هيسمّيه أوتوماتيك:

     ```
     lsass.exe_250408_134544.dmp
     ```
* **Integrity**: تعمل نفس فكرة الـ Hash:

  ```powershell
  Get-FileHash -Path 'C:\TMP\lsass.exe_250408_134544.dmp' -Algorithm MD5
  ```
* **ليه؟**\
  عشان تركز على عملية معينة مش محتاج تعمل full dump للـ RAM كله. ده أسرع وأخف ومفيد جدًا لما تعرف العملية المصابة.

***

### ثالثًا: Crash Dump

* **السيناريو**: ويندوز لو Crash بيقدر يكتب Memory Dump أوتوماتيك. ده مفيد لو Crash سببه **Malware أو Exploit**.
* **الخطوات**:
  1. Run → `sysdm.cpl`
  2. Advanced tab → Startup and Recovery → Settings.
  3. تحت "System failure" تختار نوع الـ dump:
     * **Small memory dump (Minidump)** → معلومات أساسية (أصغر حجم).
     * **Kernel memory dump** → يحفظ الذاكرة المستخدمة في الـ Kernel فقط (مفيد جدًا في analysis).
     * **Complete memory dump** → full RAM (ضخم جدًا).
* **الملف بيتخزن فين؟**\
  عادةً في: `C:\Windows\MEMORY.DMP` أو `C:\Windows\Minidump\`.

***

###  الربط مع Incident Response Plan

بعد كل خطوة انت لازم تجاوب على الـ 4 أسئلة اللي اتكلمنا عليها:

1. **What part of the memory do I need?**
   * Full RAM dump (لما عايز snapshot كامل).
   * Process dump (لما مستهدف عملية زي lsass).
   * Crash dump (لما crash ممكن يكون ناتج عن malware).
2. **Which tool?**
   * FTK Imager → full memory.
   * Procdump → process memory.
   * Windows built-in config → crash dump.
3. **When?**
   * فورًا أثناء النشاط المشبوه (زي lateral movement أو fileless malware).
4. **How to ensure integrity?**
   * MD5/SHA256 hash.
   * حفظ نسخة read-only.

***

### Memory Acquisition on Linux

في لينكس، برضه بنطبق نفس فكرة الـ IR playbook:

1. **ماذا؟** (نوع الـ dump: full, process, crash)
2. **متى؟** (أثناء حادثة – business hours – إلخ)
3. **بأي أداة؟** (LiME, gcore, kdump)
4. **سلامة الملف** (hashing: md5/sha256)

***

###  Full Memory Capture with **LiME**

#### الأداة: LiME (Linux Memory Extractor)

* Kernel Module = لازم يتم تحميله جوه الكيرنل علشان يقدر ياخد نسخة كاملة من الـ RAM.
* مميز جدًا لأنه:
  * يعمل Capture مباشر من الكيرنل.
  * يطلع فورمات متوافق مع **Volatility**.
  * يقدر يطلع بصيغ مختلفة (`lime` , `raw`).

#### الأمر:

```bash
sudo insmod lime-6.8.0-1027-aws.ko "path=/tmp/ubuntu-150000-22042025.lime format=lime"
```

* `insmod` → إدخال module للكيرنل (تشغيل LiME).
* `lime-6.8.0-1027-aws.ko` → الملف اللي هو module متوافق مع نسخة الكيرنل.
* `path=/tmp/ubuntu-150000-22042025.lime` → المكان + اسم الملف.
  * نمط التسمية: HOSTNAME-HHMMSS-DDMMYYYY.lime (عشان يبقى واضح وقت الالتقاط).
* `format=lime` → الصيغة. لازم تتأكد إنها compatible مع أداة التحليل.

#### بعد الانتهاء:

* تحقق من سلامة الملف:

```bash
md5sum /tmp/ubuntu-150000-22042025.lime
```

* شيل الموديول من الكيرنل (علشان مايفضلش محمل):

```bash
sudo rmmod lime
```

⚠ملحوظة: كل مرة هتعمل capture لازم تعمل rmmod قبل insmod من جديد.

***

###  Process Memory Dump with **gcore**

#### الأداة: gcore (جزء من GDB)

* وظيفته: ياخد dump للـ memory الخاصة بـ process واحد.
* مهم جدًا عشان نحلل العمليات الحساسة زي `bash`, `sshd`, `apache`, أو أي malware suspected.

#### الخطوات:

1. دور على الـ PID الخاص بالعملية:

```bash
ps aux | grep bash
```

2. نفذ dump باستخدام gcore:

```bash
sudo gcore -o /tmp/BASH-130000-10042025 6506
```

* `gcore` = توليد core dump.
* `-o /tmp/BASH-130000-10042025` = حدد اسم الملف.
* `6506` = رقم الـ PID.

3. تحقق من سلامة الملف:

```bash
md5sum /tmp/BASH-130000-10042025.6506
```

***

###  Crash Dumps (System & Processes)

#### Kernel Crash Dump (kdump)

* شبيه بالـ Windows Crash Dump.
* يبدأ يشتغل مع Ubuntu ≥ 24.10 بشكل افتراضي.
* هنا (Ubuntu 24.04) لازم نفعّله يدويًا.
* الأداة: `kdump-tools`.

خطوات التفعيل:

```bash
sudo apt install kdump-tools -y
sudo reboot
sudo kdump-config show
```

لو الحالة:

```
current state: ready to kdump
```

يبقى الكيرنل جاهز يولد dump عند حدوث crash.

 Process Crash Dumps

ممكن نفعّل core dumps لما عملية تنهار:

1. للعمليات تحت **systemd**:
   * أنشئ ملف:

     ```bash
     sudo nano /etc/systemd/system.conf.d/core-dumps.conf
     ```
   * أضف:

     ```
     [Manager]
     DefaultLimitCORE=infinity
     ```
   * ثم:

     ```bash
     sudo systemctl daemon-reexec
     ```
2. للعمليات العادية (user processes):

   ```bash
   ulimit -c unlimited
   sudo nano /etc/sysctl.d/60-core-pattern.conf
   ```

   أضف:

   ```
   kernel.core_pattern = /var/crash/core.%e.%p.%t
   fs.suid_dumpable = 1
   ```

   أنشئ مجلد التخزين:

   ```bash
   sudo mkdir -p /var/crash
   sudo chmod 1777 /var/crash
   ```
3. خدمة **apport**:
   * بتيجي افتراضيًا في Ubuntu Desktop.
   * بتولد ملفات `.crash` في `/var/crash` → فيها stack trace + info عن المكتبات + جزء من الـ memory.

***

### Memory Acquisition on Virtual Machines and Cloud Environments

### Memory Acquisition from Hypervisors

الفكرة هنا إنك بدل ما تدخل جوه الـ VM نفسها وتستخدم أدوات زي LiME أو gcore، ممكن تستغل الـ **built-in tools** اللي بيقدمها الـ Hypervisor نفسه (Hyper-V, VMware, VirtualBox, KVM).

1. **Pause / Snapshot للـ VM**\
   → كده السيستم بيعمل freeze لحالة الـ VM بالكامل (RAM + Disk).
2. **سحب ملف الـ Memory State**\
   → الملف ده بيتخزن أوتوماتيك مع الـ snapshot. غالبًا بيبقى بصيغة مختلفة حسب نوع الـ Hypervisor.
3. **حسابه بالـ Hash (MD5 أو SHA256)**\
   → عشان تضمن سلامة الملف قبل ما تحلله.
4. **تأكد من التوافق مع Volatility**\
   → بعض الملفات محتاجة conversion، وبعضها مدعوم مباشرة.

***

####  Microsoft Hyper-V

* بتعمل **Save-VM** أو **Checkpoint-VM**.
* الملف اللي يهمنا: **.vmrs** (Virtual Machine Runtime State) ← بيحتوي على الـ RAM.
* مثال PowerShell:

  ```powershell
  Checkpoint-VM -Name "Ubuntu 22.04 LTS"
  cp "C:\ProgramData\Microsoft\Windows\Hyper-V\Snapshots\xxxx.VMRS" C:\temp\memdump.VMRS
  Get-FileHash -Algorithm MD5 -Path C:\temp\memdump.VMRS
  ```
* التحليل: استخدم **volatility windows.hyperv plugin**.

***

#### VMware vSphere

* خُطوات GUI أو CLI (esxcli).
* تعمل snapshot → هيطلعلك ملف **.vmsn**.
* الملف ده مدعوم **مباشرة في Volatility**، مفيش conversion.

***

####  KVM (Linux Hypervisor)

* الأداة: **virsh**.

```bash
virsh list             # تعرض كل الـ VMs
virsh dump vmname /path/memdump.raw --memory-only
md5sum memdump.raw
```

* الملف: **raw** → متوافق مع Volatility.

***

####  VirtualBox

* الأداة: **VBoxManage.exe** (موجودة في مجلد التنصيب).:

```powershell
VBoxManage.exe list runningvms
VBoxManage.exe debugvm "VM_name" dumpvmcore --filename C:\temp\vm_mem.elf
Get-FileHash -Algorithm MD5 -Path C:\temp\vm_mem.elf
```

* الملف: **.elf** → مدعوم مباشرة في Volatility.

***

### Memory Acquisition from Cloud Platforms

هنا الوضع مختلف شويه 

* Cloud providers (AWS, Azure, GCP) **ما بيدوشك Tool مباشر لسحب RAM**، عشان الأجهزة مشتركة بين أكتر من تينانت (multi-tenant environment).
* بالتالي لازم تستخدم طرق **داخل الـ VM نفسها** (LiME, gcore … إلخ).

#### الطريقتين الرئيسيتين:

1. **من جوه الـ VM نفسها** (زي ما اتعلمت قبل كده في Windows/Linux).
2. **Crash Dump Approach**:
   * تجهز الـ OS إنه يعمل Full Memory Dump عند الـ Crash.
   * تعمل Manual Crash (trigger).
   * الدامب بيتخزن على الـ Disk.
   * بعد كده:
     * Detach الـ Disk.
     * توصل الـ Disk كـ **read-only** على VM تانية للتحليل.
     * (اختياري) تصدّر الـ Disk لـ Tenant مختلف.

***

####  Special Case: Azure

* Microsoft عملت Tool اسمه **AVML (Acquire Volatile Memory for Linux)**.
* مميزاته:
  * Portable (standalone binary).
  * مش محتاج installation أو kernel modules.
  * معمول مخصوص لـ **Linux VMs على Azure**.

***

### **Volatility Overview**

* **Volatility** = Framework مفتوح المصدر لـ **تحليل الذاكرة (Memory Forensics)**.
* Cross-platform → يشتغل على Windows, Linux, MacOS.
* Modular + Extensible → بيتبني على شكل **Plugins**، وكل Plugin ليه وظيفة محددة.

####  الجديد في **Volatility 3** (V3)

* الإصدار الأحدث (Volatility 3) بقى أفضل من V2.
* ليه؟
  *  في V2: كان بيعتمد على **Static Profiles** (يعني محتاج Profile معين لكل OS version).
  *  في V3: استخدم حاجة اسمها **Dynamic Symbol Resolution** → بيقدر يحل الـ Structures الخاصة بالنظام مباشرة من الـ Debug Symbols → معناه إنه:
    * بيدعم أنظمة أحدث.
    * يقدر يتعامل مع تغييرات في الـ Memory Layout.
    * يديك رؤية أعمق عن حالة النظام وقت التشغيل.

***

### **Architectural Overview** 

1. **Memory Layers** 
   * بتمثل هرم Address Spaces.
   * من الـ **Raw memory dump** (الملف الخام) لحد الـ **Virtual Address Translation**.
   * يعني: بتحول الـ Bytes الخام اللي في الـ Dump لعنوان منطقي نفهمه.
2. **Symbol Tables** 
   * جداول بتحتوي على **Debugging Symbols** الخاصة بالـ OS.
   * وظيفتها: ترجمة الـ Data Structures (زي الـ EPROCESS, KTHREAD, dlls … إلخ).
   * بدونها مش هتعرف تفسر الـ Memory بشكل صحيح.
3. **Plugins** 
   * أهم جزء.
   * دي عبارة عن Modules كل واحدة لها وظيفة:
     * إظهار الـ Processes.
     * استخراج الشبكات المفتوحة.
     * تحليل الـ DLLs المحملة.
     * كشف الـ Malware.
   * ودي اللي بنستخدمها طول التحقيق.

***

###  **System Requirements**

* محتاج **Python ≥ 3.6**.
* محتاج مكتبات إضافية:
  * `pefile` → تحليل ملفات PE (Windows executables).
  * `capstone` → Disassembly للـ Instructions.
  * `yara-python` → عشان تستخدم YARA rules وتكتشف Indicators of Compromise.

***

### **Installation**

```bash
git clone https://github.com/volatilityfoundation/volatility3.git
cd volatility3
python3 vol.py -h
```

* ملحوظة: مش محتاج تعمل install كامل (بيشتغل مباشرة من الـ source).
* في TryHackMe room → النسخة موجودة بالفعل تحت:

  ```
  ~/Desktop/volatility3
  ```

***

### **مثال** 

لما تكتب:

```bash
python3 vol.py -h
```

هيظهرلك الـ Usage والـ Options.

* بعض الـ Parameters المهمة:
  * `-f FILE` → تحدد ملف الـ Memory dump.
  * `-p PLUGIN_DIRS` → تضيف Plugins إضافية.
  * `-r RENDERER` → تختار طريقة العرض (text, json).
  * `PLUGIN ...` → هنا بتحط اسم الـ Plugin اللي عايز تشغله.

***

## **Memory Acquisition Methodologies**

قبل ما تعمل أي تحليل لازم **تستخرج (acquire) الذاكرة** بشكل سليم عشان تحافظ على سلامة الدليل.

###  **في Windows:**

1. **DumpIt**
   * Tool بسيط (one-click).
   * بيعمل Dump كامل للـ RAM (32 و 64bit).
   * أوتوماتيك بيعمل **Hash** للـ dump (مهم جدًا في Chain of Custody).
2. **WinPmem**
   * Open-source.
   * Driver-based (يعني بيشتغل على مستوى الـ Kernel).
   * بيحفظ dump بصيغة **RAW** أو **ELF**.
   * بيضيف Metadata → يسهل إثبات إن الدليل صحيح.
3. **Magnet RAM Capture**
   * GUI (واجهة رسومية).
   * بيسمح تعمل Memory Dump مع أقل تدخل ممكن (Low footprint).
   * مناسب للـ Incident Response السريع.
4. **FTK Imager**
   * Tool تجاري معروف جدًا.
   * بيعمل Memory Acquisition وكمان Disk Imaging.
   * يقدر ياخد أجزاء معينة (Logical Artifacts) مع الـ RAM.

***

###  **في Linux و macOS:**

1. **AVML (Linux)**
   * أداة من Microsoft.
   * Lightweight CLI.
   * بتعمل Dump بصيغة **Compressed ELF**.
   * مش محتاجة Kernel Module.
2. **LiME (Linux)**
   * Kernel Module.
   * بيعمل Full Dump سواء لـ File أو عبر Network.
   * بيدعم ARM + x86.
3. **OSXPmem (macOS)**
   * Fork من Pmem مخصوص للـ macOS.
   * بيشتغل على أجهزة Intel-based Macs.
   * بيطلع Raw Memory Image جاهزة لـ Volatility.

***

###  **في Virtual Environments:**

لو الجهاز virtual (VM) مش محتاج tool إضافي، ممكن تاخد ملف الـ Memory Snapshot:

* **VMware** → `.vmem`
* **Hyper-V** → `.bin`
* **Parallels** → `.mem`
* **VirtualBox** → `.sav` (بس جزئي مش كامل dump).

***

##  **Memory Analysis باستخدام Volatility**

بعد ما ناخد الـ dump، بنيجي للمرحلة التانية: **التحليل**.

####  **Case 001**

* في السيناريو: عندك dump اسمه:

  ```
  ~/Desktop/Investigations/Investigation-1.vmem
  ```
* SOC قالك فيه **Banking Trojan** جاي في صورة ملف Adobe.
* كمان في IP مشبوه: `41.168.5.140` → احتمال يكون C2 (Command & Control).

***

### **Volatility Plugins :**

1. **windows.info** / **linux.info**
   * بيجيبلك تفاصيل الـ OS من الـ dump.
   * زي الـ Kernel version, Base Address, Symbol Table.
2. **pslist**
   * يطلعلك قائمة الـ Processes اللي كانت شغالة.
3. **pstree**
   * زي pslist بس بشكل Tree (يوضح الـ Parent/Child relationship).

***

### **مثال تشغيل:**

```bash
python3 vol.py -f ~/Desktop/Investigations/Investigation-1.vmem windows.info
```

* الناتج بيوريك:
  * **Kernel Base** → مكان الـ Kernel في الذاكرة.
  * **DTB** (Directory Table Base) → خاص بالـ Virtual Address Translation.
  * **Symbols** → الـ PDB اللي Volatility استخدمه عشان يفسر الـ structures.

لو ظهرلك Warning زي:

```
No metadata file found alongside VMEM file...
```

ده معناه إن Volatility كان بيفضل لو dump اتاخد معاه ملفات إضافية زي `.vmss` أو `.vmsn` (Snapshots).\
لكن غالبًا يقدر يكمل التحليل حتى بدونها.

***

## **Listing Processes and Connections**

####  1. **Active Process Enumeration – pslist**

*

````
```bash
````

````
python3 vol.py -f Investigation-1.vmem windows.pslist
```
````

* بيجيب كل الـ **Processes** اللي شغالة (زي Task Manager).
* النتيجة تشمل: PID, PPID, Name, Start Time, Exit Time.

> ⚠ ملحوظة: pslist ممكن **ما يبانش فيه التروجان** لو عامل نفسه Hidden (Rootkit).

***

####  2. **Hidden Process Enumeration – pssca**الأمر:

```bash
python3 vol.py -f Investigation-1.vmem windows.psscan
```

* بيعمل **Memory Scanning** للـ `_EPROCESS` structures → يعني حتى لو الـ Process مستخبي هيتكشف.
* مفيد ضد الـ Rootkits.
* لكن: ممكن يجيب **False Positives** (يطلعلك بيانات بروسيس قديمة أو محذوفة).

***

####  3. **Process Hierarchy – pstree**

*

````
```bash
````

````
python3 vol.py -f Investigation-1.vmem windows.pstree
```
````

* بيعرضلك الـ Processes كـ **شجرة** (Parent → Child).
* ده بيساعدك تشوف مين الـ Parent بتاع التروجان.
  * مثال: لو لقيت `winword.exe` مشغل `powershell.exe` أو حاجة مش منطقية → احتمال يكون Attack.

***

####  4. **File, Registry, Thread Handles – handles**

:

```bash
python3 vol.py -f Investigation-1.vmem windows.handles
```

* يوريك الـ **Files / Registry keys / Threads** اللي الـ Process فاتحها.
* مثال: لو لقيت التروجان فاتح مفتاح Registry غريب (Persistence).

***

#### 5. **Network Connections – netstat**

```bash
python3 vol.py -f Investigation-1.vmem windows.netstat
```

* بيحاول يجيبلك الـ **Active Connections**.
* بس في Volatility 3 لسه غير مستقر، خصوصًا مع Windows قديم.

***

 6\. **TCP/UDP Enumeration – netscan** 

* :

  ```bash
  python3 vol.py -f Investigation-1.vmem windows.netscan
  ```
* يجيبلك:
  * **Local Address + Port**
  * **Remote Address + Port**
  * **PID (Process ID)**
  * حالة الاتصال (Established, Closed, Listening).
* ده أهم Plugin عشان نربط بين **الـ Process والـ IP المشبوه** `41.168.5.140`.

***

#### 🔹 7. **DLL Enumeration – dlllist**

* :

  ```bash
  python3 vol.py -f Investigation-1.vmem windows.dlllist
  ```
* يوريك الـ DLLs اللي الـ Process محملها.
* مهم جدًا لو عايز تعرف التروجان بيستخدم **DLL Injection** أو DLL غريبة.

***

***

## **Volatility Hunting and Detection**

###  1. **malfind** 

*

````
```bash
````

````
python3 vol.py -f Investigation-1.vmem windows.malfind
```
````

* بيعمل Scan على الـ **Heap + VAD (Virtual Address Descriptors)** لكل Process.
* بيدور على:
  * **Pages** اللي فيها صلاحيات تنفيذ + كتابة (RWE / RX) → غير طبيعي.
  * **Memory regions** ملهاش ملف على الديسك → يعني ممكن يكون Fileless malware.
* بيعرضلك:
  * **PID + Process name**.
  * **Offset**.
  * جزء من الـ **Hex / ASCII / Disassembly** للمنطقة المشبوهة.

>  الـ Indicators:
>
> * لو لقيت **MZ Header (0x4D 0x5A)** → غالبًا Executable Injected.
> * لو لقيت Shellcode → محتاج تحليل أكتر (reverse engineering).

***

2\. **vadinfo – تحليل الـ Memory Regions**

* :

  ```bash
  python3 vol.py -f Investigation-1.vmem windows.vadinfo
  ```
* بيجيبلك تفاصيل عن الـ **VAD Tree** (اللي هو المسؤول عن إدارة الذاكرة لكل Process).
* مفيد جدًا في:
  * تشوف أي Memory Regions مش طبيعية.
  * تتأكد لو في **Memory Allocation** suspicious (زي Heap كبير متعمله RWE Permissions).

>  ده بيكمل malfind → malfind يقولك فيه Injected Memory، وvadinfo يخليك تحلل Allocations وتشوف سلوك الـ Process أكتر.

***

## **Advanced Memory Forensics Concepts**

###  1. Rootkits و Evasion

* **Rootkit** = Malware متطور بيعيش في الـ **Kernel Mode** (مستوى منخفض جدًا جوه الـ OS).
* بيستخدم طرق زي:
  * **إخفاء الـ Processes** → بيشيل نفسه من الـ Active process list.
  * **إخفاء الـ Drivers / Modules** → بيعمل unlink أو manipulates structures.
  * **التلاعب بالـ System Calls** → يعدل الجدول اللي Windows بيستخدمه ينفذ أوامر النظام.

النتيجة: المستخدم أو حتى الأدوات العادية (زي Task Manager) مش هتشوف أي حاجة غريبة.

***

###  2. Hooking

* **Hooking** = اعتراض وظيفة أساسية في النظام وإعادة توجيهها.
  * مثال: الدالة `NtCreateFile` مسؤولة عن إنشاء الملفات. Rootkit ممكن يغير مكانها بحيث:
    * لو أنت أو برنامج أمني حاول يفتح ملف rootkit → بيتوجّه على دالة وهمية تمنع الوصول.
* **مش دايمًا خبيث**:
  * Antivirus مثلًا ممكن يستخدم Hooking لمراقبة كل الـ File operations.
  * Debuggers برضه بيعملوا كده. شغلك كـ Forensic Analyst إنك تفرق: هل الـ Hook مشروع ولا خبيث؟

***

### 🔹3. SSDT (System Service Descriptor Table)

* Windows بيخزن كل **System Calls → Function addresses** جوه جدول اسمه **SSDT**.
* Rootkit بيغير الـ entries بحيث يشاوروا على **malicious function** بدل الأصلية.
* هنا ييجي دور Volatility:

Detecting SSDT Hooks

```bash
python3 vol.py -f Investigation-1.vmem windows.ssdt
```

* يعرض كل الـ System Calls وعنوانها في الذاكرة.
* لو لقيت **دالة محوّلة لعنوان خارج kernel module الطبيعي** (مثلاً بدل `ntoskrnl.exe` لعنوان في driver غريب) → مؤشر قوي على Hook خبيث.

***

###  4. Kernel Module Enumeration

#### **windows.modules**

```bash
python3 vol.py -f Investigation-1.vmem windows.modules
```

* بيجيب كل الـ Kernel modules (drivers) المحملة.
* بيعرض: **Base Address, Size, File Path**.
* تستخدمه عشان:
  * تراجع الـ Modules وتشوف لو فيه اسم غريب.
  * تشوف File Paths (مثلًا Driver في مكان غير معتاد زي `C:\Temp\evil.sys`).

***

###  5. Hidden Drivers (Driver Scanning)

Rootkit متطور ممكن يعمل **Unlinking** للـ Driver من القوائم الرسمية → كأنها مش موجودة.

* **windows.driverscan**:

```bash
python3 vol.py -f Investigation-1.vmem windows.driverscan
```

* بيعمل Scan خام على الذاكرة ويدور على **DRIVER\_OBJECT structures** مباشرة.
* لو لقي Driver مش موجود في **windows.modules** → احتمال DKOM (Direct Kernel Object Manipulation).

***