Comparing Windows and Linux is a bit like comparing a Swiss Army knife to a custom-built
workshop—both get the job done, but their philosophies on organization and transparency are
worlds apart.
a) Comparison of Windows and Linux
i. Event Logging
The primary difference here is structure vs. text.
● Windows: Uses a centralized, binary format managed by the Windows Event Log
service. Logs are categorized into Application, Security, and System. Because they are
binary (.evtx), you need specific tools like Event Viewer or PowerShell to read them.
This makes them harder to tamper with casually but requires specific APIs to parse.
● Linux: Historically relies on plain-text files stored in /var/log. Most modern
distributions use systemd-journald, which captures logs in a binary format
(retrievable via journalctl), but many still forward these to syslog for human-
readable text storage. The "everything is a file" philosophy makes Linux logs very easy
to pipe into other tools like grep or awk.
ii. User Authentication
● Windows: Centered around the Security Accounts Manager (SAM) database for local
accounts and Active Directory (AD) for network environments. It primarily uses
Kerberos and NTLM protocols. Authentication is handled by the Local Security Authority
Subsystem Service (LSASS).
● Linux: Uses a modular system called Pluggable Authentication Modules (PAM). This
allows admins to swap out authentication methods (like biometrics, SSH keys, or LDAP)
without changing the individual applications. Local credentials reside in /etc/passwd
(user info) and /etc/shadow (hashed passwords).
iii. File Access Tracking
● Windows: Uses Access Control Lists (ACLs) within the NTFS file system. Detailed
tracking (auditing) is disabled by default but can be turned on via Group Policy to log
specific events (e.g., "User X deleted File Y") into the Security Event Log.
● Linux: Uses standard Permissions (Read, Write, Execute for Owner, Group, Others).
For granular tracking, Linux uses the Audit Framework (auditd), which monitors
system calls. It can track file access in real-time and log exactly which process or user
accessed a file.
b) Challenges in macOS Forensics
Analyzing a Mac isn't just "Linux with a prettier face." Forensic investigators face several Apple-
specific hurdles:
1. Hardware-Level Encryption (T2 and Apple Silicon)
Modern Macs use the T2 Security Chip or Apple Silicon (M1/M2/M3). These chips handle
encryption at the hardware level. If the computer is powered off and the investigator doesn't
have the user's password or recovery key, the data on the soldered-on SSD is virtually
impossible to decrypt. You cannot simply "pull the hard drive" and put it in another machine.
2. File System Complexity (APFS)
The Apple File System (APFS) uses "snapshots" and "containers."
● Snapshots: A user might delete a file, but a system snapshot might still retain it, which
is great for evidence—if the investigator knows how to find and mount those snapshots.
● Space Sharing: Multiple partitions share the same pool of free space, making traditional
"deleted file recovery" (carving) much more complex than on older systems.
3. Unified Logging System (ULS)
macOS uses a "Unified Logging" system that is notoriously difficult to analyze.
● Most logs are stored in a volatile, compressed binary format (.tracev3).
● They are designed to be high-performance, meaning they roll over quickly. If an
investigator doesn't secure the device fast enough, critical evidence may be overwritten
within hours.
4. System Integrity Protection (SIP)
SIP restricts the "root" user from accessing certain system folders. While this protects users
from malware, it also prevents forensic imaging tools from accessing the entire disk unless SIP
is manually disabled in Recovery Mode—a process that technically alters the state of the
evidence.
5. Artifact Decay & iCloud Integration
With iCloud Desktop and Documents, files may not actually reside on the physical disk; they
might be "evicted" to the cloud to save space. An investigator might find a file metadata entry
but find the actual content is sitting on Apple’s servers, requiring a legal warrant for cloud data
rather than just physical access.
Executive Summary
Deleted files in NTFS and ext4 remain recoverable because the file systems typically remove
pointers (MFT entries or inodes) rather than wiping the actual data blocks. Forensic recovery
involves re-associating these orphaned blocks with metadata. To detect obfuscation,
investigators use file signature analysis (magic bytes) to identify files regardless of their
extension and entropy analysis to detect encrypted or compressed containers hidden within
innocent-looking files.
a) Recovery from File Systems
i. NTFS (New Technology File System)
In NTFS, when a file is deleted, the system performs the following actions:
● MFT Status Change: The Master File Table (MFT) entry for that file is marked as
"unallocated."
● Bitmap Update: The cluster bitmap, which tracks which clusters are in use, is updated
to show the clusters previously occupied by the file as free.
● Recovery Mechanism: Because the MFT entry often remains intact until overwritten by
a new file, forensic tools can read the "unallocated" MFT record to recover the original
filename, timestamps, and the pointers (Data Runs) to the physical clusters on the disk.
ii. ext4 (Fourth Extended Filesystem)
Ext4 handles deletion differently, making recovery more challenging than in NTFS:
● Inode Clearing: When a file is deleted, the inode (the metadata structure) is marked as
free, and the block bitmap is updated.
● Pointer Removal: Crucially, ext4 often zeroes out the extent tree (the pointers to the
data blocks) in the inode during deletion to improve security and performance.
● Recovery Mechanism: If the extent tree is zeroed, automated recovery is difficult.
However, investigators can use File Carving. This technique ignores the file system
metadata entirely and scans the raw disk for known file headers and footers (e.g., JPEG
or PDF signatures) to reconstruct the file from the raw data blocks.
b) Detecting Obfuscation and Renaming
Suspects often rename a sensitive file (e.g., [Link]) to an innocuous extension (e.g.,
system_log.txt) or change its header to bypass basic filters.
1. File Signature Analysis (Magic Bytes)
Forensic software ignores the file extension (which is easily changed) and examines the first
few bytes of the file, known as the "Magic Number" or signature.
● Example: If a file named [Link] actually contains a PDF header (%PDF-), the
forensic tool will flag a Signature Mismatch.
2. Entropy Analysis
Obfuscated, encrypted, or compressed data has high entropy (randomness).
● If a file that is supposed to be plain text or a simple image shows extremely high entropy,
it suggests the file has been encrypted or is a hidden container (like a VeraCrypt volume
or a ZIP file) disguised as a different file type.
3. Metadata and Timestamp Analysis (MAC Times)
Investigators look for anomalies in Modified, Accessed, and Created (MAC) times.
● If a file with a generic name has a creation date that does not align with other system
files, or if the "Modified" time is significantly different from the "Created" time in a
suspicious way, it suggests the file was moved or renamed to blend in with system
directories.
4. Automated String Searching
Tools like grep or specialized forensic suites can search the contents of all files—regardless of
extension—for specific keywords, sensitive data patterns, or suspicious binary strings that
indicate hidden payloads.
When a file is "deleted," most operating systems are lazy—they don't actually scrub the data
immediately. Instead, they just forget where they put it and mark the space as "available for
rent."
a) Recovering Deleted Files
i. NTFS (Windows)
NTFS relies on the Master File Table (MFT). When a file is deleted:
● Flag Update: The system changes the file’s status in the MFT from "allocated" to
"unallocated." The actual data clusters on the disk remain untouched.
● Recovery Method: Forensic tools scan the MFT for entries marked as unallocated.
Since the MFT record often still contains the file's metadata (name, size, and
timestamps) and the pointers to the data clusters, the file can be reconstructed perfectly
as long as those clusters haven't been overwritten by new data.
ii. ext4 (Linux)
The ext4 file system is a bit more aggressive about "letting go," making recovery slightly trickier
than NTFS.
● Inode Clearing: When a file is deleted in ext4, the system clears the extent tree (the
map to the data) in the file's inode. While the inode might still exist, its direct links to the
data blocks are often severed.
● Recovery Method: * Journal Analysis: ext4 is a journaling file system. Investigators
often look at the Journal, which records recent file system changes. If the deletion
happened recently, the pointers to the data blocks might still exist in the journal logs.
○ File Carving: If the metadata is gone, tools like Foremost or Scalpel perform
"carving." They scan the raw data blocks for specific "magic numbers" (headers
and footers), such as FF D8 for a JPEG, to pull files out based on their structure
rather than their name.
b) Detecting File Renaming and Obfuscation
Suspects often try to hide "stolen_data.zip" by renaming it to something boring like
"system_config.dll." Forensic investigators use several techniques to see through this:
1. File Signature (Magic Number) Analysis
The most reliable method is comparing the file extension to its header.
● Every file type has a unique hexadecimal signature in its first few bytes.
● If a file is named [Link] but the hex header reads 89 50 4E 47 (the signature for
a .png), forensic software will flag this as a mismatch, instantly revealing the
obfuscation.
2. Hash Filtering and Known File Filters
Investigators use databases like the National Software Reference Library (NSRL).
● If a file is named [Link] (a standard Windows file) but its MD5 or SHA-1 hash
does not match the known hash for the real [Link], it is immediately identified
as a "non-standard" or "rogue" file that requires manual inspection.
3. Entropy Analysis
If a suspect uses encryption or packing (obfuscation) to hide data inside a file, the file's entropy
(randomness) will be very high.
● Standard text or system files have predictable patterns.
● Encrypted data looks like pure noise. Forensic tools measure the bit-level randomness;
a sudden spike in entropy within a seemingly normal document often indicates hidden,
encrypted payloads.
4. Metadata and Timeline Analysis
Even if a file is renamed, its metadata (MAC times: Modified, Accessed, Created) often tells a
story.
● If a "system file" was supposedly created in 2021 but was modified two minutes before a
suspect's arrest, that temporal inconsistency is a massive red flag.
● The MFT sequence number in Windows can also show if an entry was recently reused
or modified in a way that doesn't align with standard OS behavior.
In digital forensics, "pulling the plug" used to be the gold standard to preserve data. Today,
that's often considered a mistake. Because modern encryption and sophisticated malware
reside primarily in memory, RAM analysis is frequently where the "smoking gun" is found.
a) The Importance of RAM Analysis
RAM is volatile memory, meaning its contents are lost when power is removed. Its importance
stems from the fact that it contains the "living" state of the machine:
● Encryption Keys: Full Disk Encryption (like BitLocker or FileVault) stores keys in RAM
while the system is running. Capturing RAM allows investigators to bypass encryption
that would otherwise be unbreakable.
● Malware in Residence: Modern "fileless" malware exists only in memory and never
touches the hard drive to avoid detection by traditional antivirus. RAM analysis is the
only way to detect these execution patterns.
● User Activity: Unsaved documents, chat messages, passwords typed into web forms,
and recently viewed images often linger in RAM even after the associated application is
closed.
b) Processes, Ports, and System Calls as Evidence
These three elements provide a snapshot of what the computer was doing at the exact moment
of the incident.
i. Running Processes
Investigating the process list helps identify unauthorized software.
● Evidence: A process named [Link] is normal, but if it's running from a temp folder
instead of C:\Windows\System32, or if its parent process is a web browser, it’s likely a
malicious backdoor.
● Technique: Investigators look for "Orphaned Processes" (processes whose parent has
terminated) or "Process Hollowing" (where a legitimate process is hijacked to run
malicious code).
ii. Open Ports and Network Connections
Network evidence in RAM shows who the computer was talking to.
● Evidence: An open port (e.g., Port 4444) connected to an unknown external IP address
suggests an active Command and Control (C2) connection.
● Technique: By mapping a network socket to a specific Process ID (PID), an investigator
can prove exactly which piece of software was exfiltrating data.
iii. System Calls
System calls are the interface between applications and the OS kernel.
● Evidence: If a simple calculator app is making system calls to "WriteProcessMemory" or
"CreateRemoteThread," it is behaving like a virus.
● Technique: Monitoring these calls allows investigators to see what an application did,
such as modifying system files or intercepting keystrokes, even if the application's logs
were deleted.
c) Capturing Volatile Memory Safely
The primary rule of memory forensics is the Order of Volatility: always capture the most
fleeting data first.
Methods
● Software Acquisition: Using a trusted tool from a USB drive to copy the physical RAM
into a "dump" file (typically .raw, .mem, or .img).
● Hardware Acquisition: Using specialized hardware (like a PCI Express card) to bypass
the OS and pull data directly from the bus, though this is rare and expensive.
● Virtual Machine Snapshot: If the target is a VM, simply taking a snapshot or copying
the .vmem file captures the RAM without needing to run tools inside the guest OS.
Tools
Tool Platform Description
FTK Imager Lite Windows A "portable" version that doesn't require installation,
minimizing the "footprint" on the target system.
DumpIt Windows A simple, one-click tool designed for quick memory
acquisition.
AVML / LiME Linux Tools used to acquire memory from Linux systems, often
used in cloud forensics.
Volatility Multi The industry standard for analyzing the memory dump once
Framework it has been captured.
The boot process is the foundation of a system's trust. For an investigator, it’s a race to see who
gained control first: the operating system or the attacker.
a) The Boot Process and Attack Vectors
Modern systems primarily use UEFI (Unified Extensible Firmware Interface), which has
largely replaced the legacy BIOS.
The Stages of Booting:
1. SEC (Security) Phase: The CPU powers on and executes code from the firmware
(ROM). It initializes temporary memory.
2. PEI (Pre-EFI Initialization): Initializes the permanent memory (RAM) and prepares the
system for the driver execution environment.
3. DXE (Driver Execution Environment): Loads device drivers (disk, keyboard, network).
4. BDS (Boot Device Selection): The system looks for a boot loader (like Windows Boot
Manager or GRUB) in the EFI System Partition (ESP).
5. TSL (Transient System Loader): The OS Loader takes over, starts the Kernel, and
transitions to the full Operating System.
Where Attackers Strike:
● Firmware/Rootkits (SEC/PEI Phase): An attacker flashes malicious firmware. This is
the "Holy Grail" of attacks because it persists even if the hard drive is replaced.
● Bootloader Hijacking (BDS Phase): Attackers modify the Boot Configuration Data
(BCD) in Windows or [Link] in Linux to load a malicious "shim" before the kernel.
● Kernel-Mode Rootkits (TSL Phase): Malicious drivers are loaded alongside legitimate
ones, allowing the attacker to intercept system calls at the highest privilege level.
b) Boot Artifacts as Persistence Mechanisms
Persistence is the ability of malware to survive a reboot. Investigators look at specific "bread-
crumbs" left behind:
● The EFI System Partition (ESP): On a compromised system, an investigator might find
unrecognized .efi files. If the boot order has been changed to point to a custom file
instead of [Link], you’ve found the entry point.
● Master Boot Record (MBR) / GPT Headers: On older systems, attackers overwrite the
MBR. In modern systems, they might modify the GUID Partition Table (GPT) to point to
hidden "service partitions" containing malicious code.
● Registry Keys (Windows): The keys HKEY_LOCAL_MACHINE\System\
CurrentControlSet\Control\Session Manager can be manipulated to load
malicious DLLs before a user even logs in.
● Startup Daemons (Linux/macOS): Files in /etc/init.d/,
/etc/systemd/system/, or /Library/LaunchDaemons/ are common hiding spots
for scripts that start automatically at boot.
c) Forensic Approach: From Boot to Shutdown
To analyze a compromised system effectively, follow this structured methodology:
1. Pre-Analysis (The Live State)
● Memory Capture: Before doing anything else, capture the RAM (as discussed
previously). This captures running malware and decrypted keys.
● Volatile Network Data: Record active connections (netstat) to see if the malware is
currently communicating with a C2 server.
2. Boot & Configuration Analysis (The "How it Started")
● Inspect Firmware: Check the UEFI/BIOS settings for unauthorized changes or disabled
"Secure Boot."
● Verify Boot Integrity: Compare the hashes of the bootloader files ([Link] or
grub) against known-good "clean" versions from the OS vendor.
● Examine the BCD/Grub Config: Look for extra boot parameters that might disable
security features (e.g., noexecute=off).
3. Execution Analysis (The "What it Did")
● Autostart Extensibility Points (ASEPs): Use tools like Autoruns to scan all locations
where the OS automatically executes code (Registry, Scheduled Tasks, Services).
● Timeline Analysis: Create a "Super Timeline" using tools like plaso. This aligns file
system changes, log entries, and registry modifications chronologically to see exactly
when the breach occurred.
4. Shutdown & Persistence (The "How it Stays")
● Check Shutdown Scripts: Attackers sometimes place code in "Logoff" or "Shutdown"
scripts to wipe logs or re-infect the system just before it powers down.
● Hibernation/Page Files: Analyze [Link] and [Link]. These files act
as a "dump" of RAM onto the hard drive, often preserving evidence of what was in
memory hours or days ago.