Here is a detailed comparison and discussion based on your requests.

a) Comparison of Microsoft Windows and Linux

Feature Microsoft Windows Linux

i. Event Logging Centralized Event Viewer Plain-text logs (mostly) and

(Windows Event Log – binary logs (e.g., journald).
.evtx). Traditional logs are in
Logs are binary and /var/log/ (e.g., syslog,

categorized into: [Link], [Link]).

- Application, Security, Setup, - systemd-journald stores

System, Forwarded Events. binary journal files
- Event IDs (e.g., 4624 for (/var/log/journal/).
successful logon) provide - Logs can be viewed via
specific meanings. journalctl, dmesg, last,

- Uses ETW (Event Tracing lastb.

for Windows) for detailed - Highly configurable (e.g.,

tracing. rsyslog, logrotate).

- Logs are stored by default

in C:\Windows\System32\
winevt\Logs.
ii. User Authentication Active Directory (AD) for Pluggable Authentication
domain networks; Local SAM Modules (PAM) – modular
(Security Account Manager) and flexible.
for standalone machines. - Local passwords stored in
- Passwords stored as NTLM /etc/shadow (SHA-512

hashes in SAM file (locked by hashes by default).

OS). - Supports LDAP, Kerberos
- Supports Kerberos (via SSSD), fingerprint, smart
(domain), smart cards, cards via PAM modules.
Windows Hello, biometrics. - No single directory
- Logon types (2=interactive, equivalent to AD by default
3=network, 10=remote (Samba or FreeIPA can add
interactive) are recorded in AD-like features).
Security logs. - su, sudo, login are
common auth tools.

iii. File Access Tracking SACL (System Access inotify (real-time monitoring)
Control List) with Audit and auditd (kernel-level
Policies ([Link]). auditing).
- Must enable "Audit Object - auditd can track specific
Access" in Group Policy. files, directories, syscalls
- Generates Event ID 4663 (open, unlink, chmod).
(access attempt) and 4660 - Rules defined via auditctl
(deletion) in Security log. or /etc/audit/[Link].
- Tracks - Logs to
read/write/execute/delete /var/log/audit/[Link]

per user and process. with detailed UID, PID,

- Limited to NTFS volumes. comm, success/failure.
 - Works across any
filesystem type.

b) Challenges a Forensic Investigator May Face When Analyzing

macOS Systems

macOS (formerly OS X) presents unique challenges due to its hybrid UNIX foundation
(Darwin) and Apple’s proprietary security and filesystem features.

1. APFS (Apple File System) Complexity

● Encryption by default – Many Macs have FileVault 2 full-disk encryption. Without

the user’s password or recovery key, logical acquisition yields encrypted data.
● Copy-on-Write (CoW) and snapshots – Traditional file carving tools may struggle
with fragmented metadata. Snapshots
(/Volumes/[Link]/) can contain older
deleted data but require special handling.
● Clones and sparse files – APFS clones (used for instant duplication) share
blocks; forensic tools must dereference clones correctly to avoid missing data.

2. Unified Log (since macOS 10.12/macOS Sierra)

● Replaces traditional [Link] and Apple System Log (ASL).

● Logs are stored in a binary compressed format in /var/db/diagnostics/ and
/private/var/log/.
● Requires log command or specialized parsers (e.g., log show) – not human-
readable in raw form.
● Logs are volatile; system limits retention (often hours/days). Timely acquisition
is critical.

3. T2 Chip / Apple Silicon (M1/M2/M3)

● Hardware-based security – Includes Secure Enclave, SSD controller, and boot

ROM.
● SSD is soldered and encrypted with a hardware-bound key – even removing the
NAND chips is useless without the paired T2/SoC.
● Full system volume integrity – macOS boot security prevents booting from
unauthorized external media unless explicitly allowed (Startup Security Utility).
● Live acquisition may be required, but disabling SIP (System Integrity Protection)
is often restricted.
4. Proprietary File Metadata & Databases

● Spotlight (.Spotlight-V100) and Quarantine database

(~/Library/Preferences/[Link].QuarantineEventsV2)
store file execution history, download sources (URLs), and timestamps – but
formats are not open.
● KnowledgeC (/private/var/db/CoreDuet/) – activity and usage data (app
usage, notifications, screen on/off). Requires proprietary or reverse-engineered
parsers.
● Powerlog (.powerlog PLSQLite) – aggregated usage data, but time-consuming
to parse.

5. FileVault 2 & Keychain

● Keychain (~/Library/Keychains/) stores passwords, certificates, and tokens

encrypted with the user’s login password.
● Without the password, offline cracking is difficult (PBKDF2 with high iterations).
● FileVault recovery key or institutional recovery key must be obtained during
acquisition.

6. System Integrity Protection (SIP)

● Protects /System, /usr (except /usr/local), /bin, /sbin, and built-in apps.
● Even root cannot modify these paths. This prevents forensic tools from writing
kernel extensions or loading custom acquisition modules into protected
directories.
● Requires rebooting into Recovery mode and disabling SIP (via csrutil disable)
– which changes the system state and may be contested in court.

7. Limited Open-Source Tooling

● Most commercial forensics suites (e.g., Magnet AXIOM, Cellebrite) support

macOS, but open-source tools (Sleuth Kit, Autopsy) lag in APFS and Unified Log
support.
● Custom parsers needed for databases like Contacts, Calendar, SMS ([Link]),
which are SQLite but with schema changes across macOS versions.

8. User Data Protection (UDP) / Sandboxing

● Applications are sandboxed; each app’s data resides in ~/Library/Containers/

with restrictive permissions.
● Accessing another user’s or another app’s data requires disabling SIP or using
the tccutil database (Privacy preferences) – even as root.
● Full Disk Access must be granted to forensic tools via System Preferences >
Security & Privacy.
9. Non-Standard Partition Layout

● APFS containers host multiple volumes: Macintosh HD (System), Macintosh HD -

Data (user data), Preboot, Recovery, VM.
● Deleted files may appear in different volumes or snapshots. Understanding the
volume group relationship is essential.

10. Power Management & Hibernation

● macOS writes sleepimage (/var/vm/sleepimage) containing memory state. This

can hold decryption keys or active process data, but parsing hibernate
(compressed) format is complex.
● If the machine is hibernated (hibernatemode 25), RAM is lost unless the image
is recovered – and FileVault may lock the system on wake.

Summary Table of macOS Challenges

Challenge Forensic Implication

APFS encryption (FileVault 2) Need password or recovery key for full disk
access

Unified Log (binary, volatile) Must acquire quickly and use log
command; short retention

T2 / Apple Silicon Hardware binding prevents chip-off; need

live acquisition

SIP Blocks modification of system files; may

require reboot to disable

Proprietary databases Requires specialized or commercial

parsers

Sandboxing & TCC Even root cannot read app data without
 privacy authorization

Open-source tool gap Limited support for APFS, Unified Log,

KnowledgeC

Best Practices for macOS Forensics

● Image with hardware write-blocker (e.g., Tableau T8) over Thunderbolt or USB-C.
● Capture live memory before shutdown (if FileVault unlocked).
● Disable auto-lock and keep system powered on until logical acquisition
completes.
● Extract Keychain, Unified Log, KnowledgeC, Quarantine database, and
sleepimage.
● Document SIP and FileVault status before any change to the system

Here is a detailed explanation of deleted file recovery on NTFS and ext4, followed by
forensic techniques to detect renaming and obfuscation.

a) How Deleted Files Can Still Be Recovered

i. NTFS (Windows)

When a file is deleted on NTFS, the operating system does not wipe the file content.
Instead, it performs specific metadata changes:

1. Master File Table (MFT) entry is modified:

○ The file’s record in the MFT is marked as not in use (flag changed).
 ○ The filename is either removed or, in Windows 10/11 and Server 2016+,
the first character of the filename in the $FILE_NAME attribute is changed
to 0xE5 (a special "deleted" marker).
○ The timestamps (creation, modification, access) are preserved in the MFT
entry.
2. $BITMAP metadata file is updated:
○ Clusters (disk space) occupied by the file are marked as free (available for
new data).
3. Actual file content remains untouched until:
○ A new file or data overwrites those clusters.
○ The MFT entry is reused for a new file.

Recovery potential:

● Small files (≤ 900 bytes for a typical MFT record) – stored

entirely inside the MFT entry ("resident data"). Very high
recovery chance.
● Large files (non-resident) – data resides in clusters outside MFT. Recoverable
until clusters are overwritten.
● Deleted directory – MFT entries of all files inside may still exist; filenames may
be recoverable via $INDEX_ROOT and $INDEX_ALLOCATION attributes.

Forensic recovery tools:

● ntfsundelete (Linux), TestDisk, FTK Imager, Autopsy, Recuva (forensically

sound imaging first).

ii. ext4 (Linux)

ext4 handles deletion differently, primarily by removing inode references:

1. Inode is unlinked:
○ The link count in the inode is decremented. When it reaches 0, the inode is
marked as free in the inode table bitmap.
○ The filename entry is removed from its parent directory block.
○ The directory entry's inode field is set to 0 (but the entry length field
remains).
2. Block pointers are preserved:
○ Direct, indirect, double-indirect, triple-indirect block pointers inside the
inode remain unchanged until the inode is reallocated.
3. Block bitmap is updated:
○ Blocks belonging to the file are marked as free in the block bitmap.
 4. Journal may retain data (if filesystem is journaled and deletion occurred
recently):
○ ext3/ext4 journals can contain copies of metadata and sometimes data
blocks (data=ordered or data=journal modes).

Recovery challenges:

● Extents (default in ext4) – deleted file’s extent tree is still in the inode until
overwritten.
● Zeroing of inode fields – Some ext4 implementations (depending on kernel
version and mount options) may zero out block pointers upon deletion, reducing
recovery chance.
● Directory entries – The removed filename is not overwritten immediately; the
directory block retains the deleted entry with a zeroed inode number.

Recovery tools:

● extundelete, testdisk, ext4magic, scalpel (carving), The Sleuth Kit (ils, icat).

Comparison table:

Feature NTFS ext4

Metadata retained MFT entry, timestamps, file Inode (unless zeroed),

size timestamps

Filename retained Yes (with 0xE5 marker) Removed from dir entry but
structure persists

Small file recovery High (resident in MFT) Moderate (inode may still
have data blocks)

Overwrite risk Clusters marked free Blocks marked free

Journal aiding recovery No (NTFS journal is Yes (ext3/ext4 journal may

transactional, not data- contain metadata/data)
focused)
b) Forensic Techniques to Detect File Renaming and
Obfuscation

Suspects may rename files (e.g., [Link] → [Link]), change extensions

([Link] → [Link]), or use deceptive names (e.g., [Link] →
[Link]). Here are forensic methods to detect such activity.

1. Analyze File Signatures (Magic Numbers)

Every file format has a unique header (magic number). Compare actual file type (based
on signature) against reported extension.

● Example: A file named [Link] that starts with MZ (PE executable header) is
actually an .exe.
● Tools: file (Linux/macOS), Binwalk, FTK (File Signature Analysis), Autopsy
(extension mismatch detector).

2. Examine MFT / Inode Timestamps (Time Stomping Detection)

Renaming a file modifies specific timestamps:

● NTFS:
○ Rename changes $FILE_NAME timestamps (specifically the "last modified"
of the directory entry).
○ Compare $STANDARD_INFORMATION (SI) vs $FILE_NAME (FN)
timestamps – mismatches may indicate manipulation.
● ext4:
○ Rename updates the ctime (change time) of the file and parent directory.
○ A file with old mtime but recent ctime without content change suggests a
rename or permission change.
● Tool: mactime (Sleuth Kit), timeline analysis in any forensics suite.

3. Detect Double Extensions & Hidden Characters

● Double extension: [Link] – Windows hides known extensions by

default, so user sees [Link].
○ Detection: List files in raw directory structure; parse MFT $FILE_NAME
attributes (which store full name, not displayed).
 ● Right-to-left override (RLO) spoofing: Filename [Link] with Unicode RLO
becomes [Link] (visually confusing).
○ Detection: Scan filenames for Unicode control characters (U+202E). Tools
like strings with Unicode awareness or custom scripts.

4. Check Alternate Data Streams (ADS) – NTFS Only

Suspects can hide data in ADS: echo "secret" > [Link]:[Link]

● Detection:
○ dir /R (Windows command line)
○ Get-Item -Stream * (PowerShell)
○ [Link] (LADS – List Alternate Data Streams)
○ FTK Imager shows ADS as child nodes.

5. Directory Structure & Link Analysis

● Hard links / symbolic links: A file with multiple names (e.g., [Link] and
[Link] pointing to same inode in Linux).
○ Detection (Linux): ls -li (show inode numbers) – identical inode
numbers = same file.
○ Detection (Windows): fsutil hardlink list <filename> or analyze
MFT – multiple $FILE_NAME entries pointing to same MFT record.
● Obfuscation via nested folders: C:\Users\Public\...\...\temp\... – analyze
path depth and unusual folder names (e.g., ..., , Unicode).

6. File System Journal / Log Analysis

● NTFS USN Journal ($UsnJrnl) – records every file change, including renames
(Reason: USN_REASON_RENAME_OLD_NAME and USN_REASON_RENAME_NEW_NAME).
○ Tool: MFTExplorer, USN Journal Parser (custom or commercial).
● ext4 Journal – may contain directory block changes before/after rename.
○ Tool: ext4magic – can replay journal to see rename operations.

7. Carve for Filename Artifacts in Unallocated Space

● Deleted directory entries may reveal original filenames that were changed.
● Process:
○ Image the drive.
 ○ Carve unallocated space for strings resembling file paths, extensions, or
known file headers.
○ Use scalpel, bulk_extractor, or strings with pattern matching (\.[a-
z0-9]{3,4}$).

8. LNK / Jump List Analysis (Windows)

● If a renamed file was ever opened, Windows may leave a shortcut (LNK) in
%UserProfile%\Recent\ or Jump List in %AppData%\Microsoft\Windows\
Recent\.
● LNK files store original path, volume serial, file size, timestamps – compare with
current file system to detect renaming.
● Tool: LNK Parser (Eric Zimmerman’s LECmd), JumpList Explorer.

9. Compare File Hashing Against Known Databases

● Compute hash (MD5, SHA-1, SHA-256) of a suspiciously named file.

● Compare against:
○ VirusTotal – known malware hashes regardless of filename.
○ NSRL (National Software Reference Library) – known legitimate software.
○ Custom case hashes – if same hash appears with different names in
different locations, suggests duplication/obfuscation.

10. Keyword Search & Indexing

● Index the entire disk for specific keywords that would appear in hidden file
content (e.g., password, confidential, malware).
● Search file paths for deceptive terms (*.jpg that contains PK – ZIP header).
● Tools: grep (Linux), Agent Ransack, dtSearch, Autopsy keyword search.

Summary Table of Techniques

Technique Detects Best for

Magic number vs extension Mismatched file type All OS

Timestamp analysis (SI/FN, Time stomping, renames NTFS, ext4

ctime)

Unicode RLO / double Visual spoofing Windows, Linux

extensions

Alternate Data Streams Hidden ADS content NTFS only

Inode / MFT link analysis Hard links, same file multiple Both
names

USN Journal / ext4 journal Historical rename events Both

LNK / Jump List Past access of renamed files Windows

File carving (unallocated) Original deleted filenames Both

Hash comparison Same content, different names All OS

Keyword search Content hidden by renaming All OS

Best practice: Combine multiple techniques – for example, identify a file named
[Link] via USN Journal that used to be [Link], confirm via hash match,
and validate via MFT timestamps showing rename at suspicious time.

RAM analysis is a cornerstone of modern digital forensics, often revealing the "smoking
gun" that would otherwise be lost when a computer is powered off. Below is a
breakdown of its importance, the value of specific types of evidence, and the methods
used to safely capture it.

a) The Importance of RAM Analysis in Digital Forensics

Random Access Memory (RAM) is the computer's temporary, high-speed workspace,

holding data for actively running programs and the operating system. Its volatile nature
means that all data is lost the moment power is cut, making it a critical resource for
investigators.

The primary importance of RAM analysis lies in its ability to provide a real-time
snapshot of system activity that is often not recorded on the hard drive. Key evidence
found exclusively in memory includes:

● Decryption Keys and Passwords: Many modern systems and encrypted

containers store their decryption keys in memory while they are mounted or in
use. Capturing RAM can allow an investigator to unlock encrypted drives or files
that would otherwise be inaccessible.
● Network Connections: RAM contains a record of active and recent network
connections, including IP addresses and ports, which can link a system to a
command-and-control (C2) server.
● Malware Analysis: "Memory-resident" malware or fileless malware loads directly
into RAM and leaves no traces on the hard disk. Analyzing the memory dump is
the only way to detect and analyze such malicious code.
● User Activity: Evidence of recently executed commands (including bash history
loaded into memory), processes, and even artifacts from private browsing
sessions can be recovered from RAM.
● System State: Information about running processes, logged-in users, open files,
and loaded kernel modules provides a detailed picture of the system's state at a
specific moment in time.

In essence, ignoring RAM is like investigating a crime scene only after it has been
thoroughly cleaned; you lose the immediate, volatile context of what was actually
happening.

b) Running Processes, Open Ports, and System Calls as Evidence

These three artifacts are among the most valuable pieces of data extracted from a
memory image, as they directly describe the system's active behavior.

Artifact Description & Forensic Value

Running Processes Description: A list of all programs currently
being executed by the operating system,
including their Process ID (PID), parent
process ID (PPID), and path on disk.

Evidentiary Value: This is the primary method

for detecting malware. An investigator can
look for:
- Suspicious Process Names: Processes with
random names, misspellings of legitimate
system files (e.g., [Link]), or names
masquerading as system processes
([Link]).
- Anomalous Parent-Child Relationships: A
Microsoft Word document spawning a
command shell ([Link]) is a classic
indicator of a malicious macro attack.
- Hidden Processes: Sophisticated rootkits can
hide processes from standard system tools
like Task Manager, but a forensic memory
dump and tools like Volatility can often reveal
them using techniques like psscan.
Open Ports & Network Connections Description: A record of the system's active
network communication, showing local and
remote IP addresses and port numbers
associated with a specific process.

Evidentiary Value: This can prove a system is

compromised and communicating externally:
- C2 Communication: An open connection to a
known malicious IP address on a non-
standard port is strong evidence of a backdoor
or Trojan.
- Listening Ports: A process listening on a port
(e.g., port 4444) can indicate that a remote
access tool (RAT) or backdoor is waiting for
commands from an attacker.
- Data Exfiltration: Outbound connections to
unusual ports or high volumes of traffic
associated with a specific process can
indicate data theft.

System Calls Description: System calls are the primary

interface through which a user-mode process
requests a service from the operating system
kernel (e.g., reading a file, creating a process,
or opening a network socket).

Evidentiary Value: Analyzing the sequence or

hooking of system calls is a more advanced
forensic technique for detecting stealthy
 malware:
- Detecting Rootkits: Many rootkits operate by
"hooking" system calls. For example, a rootkit
might hook the system call that enumerates
processes (NtQuerySystemInformation) to
filter out its own process from the results,
effectively hiding itself. Memory analysis can
identify such hooks by comparing the live
system call table with known good values.
- Revealing Malicious Actions: By analyzing the
system call history (if captured), an
investigator can reconstruct a program's exact
actions, such as every file it attempted to open
or modify, even if those actions were designed
to be stealthy.

c) Tools and Methods to Capture Volatile Memory Safely

Capturing memory safely is a challenge because running any tool on a live system alters
the memory state to some degree, a phenomenon known as "tool-induced" footprint or
"page smear". The goal is to minimize this impact.

Key Methods and Principles

1. Minimize Footprint: Run the smallest, most static-linked executable possible.

This reduces the number of new pages allocated in memory that could overwrite
evidence.
2. Run from External Media: The acquisition tool should be executed from a trusted,
write-protected USB drive or network location, not from the suspect's hard drive.
3. Prioritize Volatility: The order of collection is critical. Data that changes most
rapidly should be collected first: system time, then running processes, then
network connections, and finally physical memory.
4. Maintain Integrity: Immediately compute a cryptographic hash (e.g., SHA-256) of
the captured memory image to ensure it has not been altered after acquisition.
Common Tools

Tool Platform Type Key Features / Notes

AVML Linux Open-Source A modern, userland tool

written in Rust. It is a
static binary, requires no
kernel module, and has a
very small memory
footprint. Preferred for
modern Linux systems.

LiME Linux Open-Source A classic tool that

operates as a Loadable
Kernel Module (LKM). It is
very powerful but must be
compiled for the specific
target kernel, which can
be a limitation.

WinPmem Windows Open-Source The default memory

acquisition driver for
Windows, integrated with
the Volatility framework.
Known for its reliability.

FTK Imager Windows Free / A very popular, easy-to-

Commercial use GUI tool from
AccessData. It can
acquire memory from a
 live system and create a
pagefile capture
alongside the physical
memory.

Magnet RAM Windows Free A simple, free tool from

Capture Magnet Forensics
designed specifically for
capturing RAM with a
minimal footprint.

PCILeech / Cross- Hardware/ An advanced technique

Hardware Platform Software that uses Direct Memory
Access (DMA) over a
PCIe interface (e.g., from
a dedicated hardware
device or laptop via a
Thunderbolt/FireWire
port). Its primary
advantage is that it does
not require running any
software on the target
system, making it
completely stealthy and
leaving no forensic
footprint.

Safe Acquisition Workflow Example (for a Linux system)

1. Preparation: A forensic USB drive containing a static binary of avml is plugged

into the target machine.
 2. Execute: The investigator runs the command from the USB drive: sudo
/mnt/usb/avml /mnt/usb/case001/[Link].
3. Capture: AVML copies the contents of physical memory from sources like
/proc/kcore to the designated file on the USB drive.
4. Hash: Immediately after the capture completes, the investigator runs
sha256sum /mnt/usb/case001/[Link] and records the output in their case
notes.
5. Analyze: The memory image is transferred to a dedicated forensic workstation
for analysis using a framework like Volatility 3 or MemProcFS.

I hope this comprehensive overview is helpful for your studies. If you'd like to explore
any of these topics in more detail, such as how to use a specific tool like Volatility, feel
free to ask

This is an excellent question that ties together system internals, attacker techniques,
and forensic methodology. Below is a comprehensive answer.

a) Complete Boot Process & Attacker Insertion Points

The boot process differs between BIOS/Legacy and UEFI systems. Below is the UEFI-
based boot process (modern Windows/Linux), with insertion points identified.

UEFI Boot Process Steps

Step Component Description Attacker Insertion

Point

1 UEFI Firmware (SPI Firmware initializes UEFI firmware rootkit

flash ROM) CPU, memory, – Malware flashed
chipset. Loads UEFI into SPI ROM survives
drivers for hardware. OS reinstall. Rare but
sophisticated (e.g.,
LoJax, ESPecter).

2 Secure Boot Verifies bootloader Secure Boot bypass –

 (optional) signature against Attacker adds own
db/dbx key to db (if write
(allowed/forbidden access), or exploits
signatures database). signed vulnerable
bootloader (e.g.,
"Golden Key" attack).

3 UEFI Boot Manager Reads BootOrder Bootkit – Replace

NVRAM variable. legitimate .efi
Loads \EFI\{OS}\ bootloader with
[Link] (e.g., malicious one. Modify
[Link] for BootOrder to load

Windows, attacker-controlled
[Link] for .efi first.

Linux).

4 Bootloader Loads kernel into Bootloader backdoor

(Windows: memory, prepares – Malicious GRUB

[Link] → kernel parameters, module or patched

[Link], Linux: passes control. [Link] that

GRUB2) loads unsigned

drivers or injects into
kernel.

5 Kernel Initialization Kernel initializes Kernel rootkit –

([Link] / subsystems, loads Malicious driver
vmlinuz) boot-start drivers. loaded via
DriverLoad order;

DKOM (Direct Kernel

 Object Manipulation).

6 Init / Session Launches user-mode Persistent malware –

Manager (Windows: boot processes. Replace [Link] or
[Link], Linux: add malicious
init/systemd) systemd service.

7 Login / Shell User logs in, shell User-level persistence

starts. – Registry run keys,
.bashrc, launch

agents.

Legacy BIOS (Less Common Now) – Brief Notes

● BIOS → MBR (sector 0) → VBR (active partition) → bootloader

(bootmgr / GRUB stage1) → kernel.
● Insertion points: MBR rootkits (e.g., Petya, Mebroot), VBR malware, bootloader
patches.

b) Boot Artifacts Revealing Persistence Mechanisms

Persistence mechanisms ensure malware survives reboots. Boot artifacts are among
the most reliable indicators because they are loaded early and often overlooked.

Windows Boot Artifacts

Artifact Location What It Reveals Malicious

Indicator

Boot Execute HKLM\SYSTEM\ Programs run Entries pointing to

 CurrentControlSe before Windows malware instead of
t\Control\ services start (e.g., legitimate
Session Manager\ autocheck). [Link].

BootExecute

BootVerification HKLM\SYSTEM\ Programs verified Malicious DLL

CurrentControlSe during boot. paths.
t\Control\

BootVerification

Boot Drivers HKLM\SYSTEM\ All kernel and Start=0 with

CurrentControlSe boot-start drivers. unknown
t\Services\ Look at Start ImagePath;

value (0=Boot, mismatch between

1=System, 2=Auto, ImagePath and file

3=Manual). signature.

Early Launch Anti- HKLM\SYSTEM\ Drivers loaded Malicious driver

Malware (ELAM) CurrentControlSe before ELAM. registered as
t\Control\ critical boot driver.
EarlyLaunch

BCD (Boot \EFI\Microsoft\ Boot loader debug enabled,

Configuration Data) Boot\BCD (or C:\ settings, including bootlog disabled

boot\BCD) nx, debug, bootlog, suspiciously, or

safeboot. modified boot
parameters for
test-signing.

Secure Boot State NVRAM + HKLM\ Indicates if Secure Secure Boot

 System\ Boot is active and disabled without
CurrentControlSe keys. administrative
t\Control\ reason; unknown
SecureBoot keys in db.

Windows Boot Log C:\Windows\ Lists drivers Unknown or

[Link] (if loaded during unsigned drivers;
enabled) boot. driver loading order
anomalies.

Linux Boot Artifacts

Artifact Location What It Reveals Malicious

Indicator

GRUB2 /boot/grub/ Kernel command initrd replaced

Configuration [Link], line, initrd images. with malicious

/etc/default/grub image; [Link] or
single

(debug/single-user
mode) added for
unauthorized
access.

Initramfs/Initrd /boot/[Link]- Temporary root Modified initramfs

* filesystem loaded containing backdoor
before real root. scripts or altered
/init.
Systemd Boot /etc/systemd/ Services loaded at multi-

Services system/*.wants/, boot. [Link]

/usr/lib/systemd/ contains malicious

system/ .service file

pointing to non-
standard binary.

Kernel Modules /etc/modules- Modules loaded at Unknown .ko file

load.d/*.conf, boot. loading before
/lib/modules/ network (for C2).

Boot Logs /var/log/ Boot messages, Error messages

[Link], driver loads. indicating tampered
journalctl -b 0 kernel or driver load
failures.

EFI Boot Entries /sys/firmware/ NVRAM boot Unexpected

efi/efivars/ (or variables. BootXXXX entries

efibootmgr with EFI\

command) Malicious\

[Link].

Persistence Indicators from Boot Analysis

1. Time Stomping Detection: Compare $STANDARD_INFORMATION vs $FILE_NAME

timestamps on boot files (bootmgr, [Link], [Link]). Mismatches
suggest replacement or tampering.
2. Digital Signature Verification: Bootloaders and kernel files must be signed by
Microsoft or hardware vendor. Unsigned or invalid signatures = compromise.
3. Hash Analysis: Compute hashes of all boot-critical files and compare against
known good baselines (from clean installation media).
 4. Unexpected Load Order: Malicious boot drivers often load before security
software (Start=0). Look for unusual driver dependencies.

c) Forensic Investigation Approach: Boot to Shut Down

A systematic methodology ensures no phase of the system's operation is overlooked.

Phase 1: Preparation & Triage (Before Touching the System)

Step Action

1.1 Preserve volatile evidence first – Capture RAM (as

described in previous answer).

1.2 Document system state – Uptime, logged-in users, open

files, network connections (netstat -an), running
processes.

1.3 Photograph screen and connections – Physical layout,

connected devices.

1.4 Isolate from network – Unplug Ethernet, but note: some

malware may trigger upon disconnection.

Phase 2: Boot-Time Acquisition (Forensic Boot)

Step Action Purpose

2.1 Boot from forensic media – Use Avoid altering suspect disk.
a write-blocked forensic boot
 CD/USB (e.g., CAINE, Paladin, or
custom Linux with losetup
read-only).

2.2 Verify Secure Boot state – If Detect tampering with boot

enabled, note keys. If disabled, integrity.
document why.

2.3 Acquire full disk image – Use Bit-for-bit copy.

dcfldd, dd with

conv=noerror,sync, or

commercial imager (FTK

Imager, Guymager).

2.4 Capture NVRAM/EFI variables – Detect bootkit persistence.

efibootmgr -v (Linux) or

extract from \EFI\Microsoft\

Boot\BCD and registry SYSTEM

hive.

Phase 3: Post-Acquisition Analysis (Offline)

3.1 Boot Component Analysis

Target Method

EFI System Partition (ESP) Mount image, examine \EFI\ folder. Verify
hashes of .efi files against known good.
Check for unexpected directories (e.g., \EFI\
 Windows is normal; \EFI\Hacker is not).

Bootloader files [Link], [Link], [Link] –

validate digital signatures using sigcheck

(Windows) or pesign (Linux).

BCD / GRUB config Parse BCD with bcdedit (offline via registry
hive). Check for DEBUG on, TESTSIGNING on,
or unusual PATH values.

Boot drivers Enumerate Start=0 services from registry

SYSTEM hive. Extract driver files, check

signatures, submit unknown hashes to

VirusTotal.

Initramfs Extract using unmkinitramfs or

lsinitramfs. Examine /init script,

/scripts/ for backdoors.

3.2 Timeline Analysis (Boot to Shutdown)

Step Tool Goal

Create super timeline log2timeline (Plaso), Correlate file system, registry,

sleuthkit event logs, and memory
artifacts.

Identify boot time $MFT timestamps of C:\ Anchor timeline.

Windows\[Link]

(Windows) or
 /var/log/[Link] creation

(Linux).

Map critical events Manual or timeline filtering Look for:

- Files modified within
seconds of boot (persistence
installation).
- Unexpected processes
starting early in boot
sequence.
- Network connections
immediately after boot (C2
beaconing).

3.3 Memory Analysis (Correlating with Boot Artifacts)

Question to Answer Volatility 3 Plugin (Windows) Linux Equivalent

What processes were [Link], [Link]

running? [Link]

Any hidden processes? [Link] (carves from linux.check_syscall

pool)

What kernel modules [Link] [Link]

loaded?

Any rootkit hooks? [Link], [Link] linux.check_syscall

Network connections? [Link] [Link]

Key correlation: Compare [Link] output with boot driver list from
registry. Any module in memory not in registry → potential manually
loaded rootkit.

3.4 Log Analysis (Boot Events)

Log What to Look For

Windows Event Log (Security, System) Event ID 12 (registry boot-start driver load),
4657 (registry modification to boot
settings), 7045 (service installation).

Linux auditd (/var/log/audit/[Link]) SYSCALL events for init_module,

finit_module (kernel module loading).

PowerShell log (Windows) Event ID 4104 – scripts executed at boot

via Group Policy or startup scripts.

Phase 4: Shutdown & Hibernation Artifacts

Artifact Location Forensic Value

Hibernation file C:\[Link] (Windows) Contains compressed

memory state at shutdown.
May include evidence of
malware that unloaded itself
before shutdown.

Shutdown Event Logs C:\Windows\System32\ User who initiated shutdown,

winevt\Logs\[Link] unexpected shutdowns
(Event IDs 1074, 6006, 6008) (crashes may indicate
 malware instability).

Linux lastlog /var/log/lastlog Last login time before

shutdown – can indicate if
shutdown was from console
or remote.

Swap / Pagefile C:\[Link] (Windows), Contains memory pages

/swapfile (Linux) written to disk. Can recover
processes not captured in
RAM dump.

Phase 5: Reporting

Component Content

Boot chain integrity assessment List each component from firmware to

login, with hash and signature status.

Persistence mechanisms found Specify registry keys, services, bootloaders,

initrd modifications.

Timeline of compromise Boot time → persistence

installation → C2 communication →

shutdown.

Recovered artifacts Malicious drivers, bootkits, injected code.

Chain of custody Document every tool and step.

Summary Diagram (Conceptual)

text

[UEFI Firmware] → [Secure Boot] → [Boot Manager] → [Bootloader] → [Kernel] → [Init]

→ [Login]
↑ ↑ ↑ ↑ ↑ ↑
↑
Flashing Key DB BootOrder .efi file Driver
Service Run Key

malicious tampering modification replacement load

addition addition

Best practice for investigators: Always capture RAM before powering off. Always verify
digital signatures of boot-critical files. Always compare against known good baselines
from a clean reference system of the same OS version