Windows File System Internals (NTFS)
Objective: The NTFS (New Technology File System) is the default file system for modern Windows versions, designed to be secure, scalable, recoverable, and rich in metadata support.
Overview
The NTFS (New Technology File System) is the default file system for modern Windows versions, designed to be secure, scalable, recoverable, and rich in metadata support. Unlike FAT32 or exFAT, NTFS introduces complex data structures, a journaled metadata system, access control lists (ACLs), hard/soft links, and alternate data streams (ADS).

Key NTFS Features
Feature | Description |
---|---|
Metadata-driven | Every file and directory is stored as a metadata record in the MFT |
Journaling | Changes to critical metadata are recorded in the $LogFile before being committed |
Security | Full support for file permissions, ACLs, and encryption (EFS) |
ADS (Alternate Data Streams) | Allows multiple data streams per file |
Compression & Encryption | Built-in per-file compression and support for EFS |
Hard Links & Reparse Points | Advanced linking and symbolic path redirection features |
Sparse Files | Support for efficiently handling large files with empty regions |
The Master File Table (MFT)
At the heart of NTFS is the MFT (Master File Table). Think of it as the central database of the entire file system. Every file, folder, and metadata structure is stored as an MFT record, including internal system files.
MFT Layout
Each record in the MFT is 1024 bytes and contains:
- File metadata (timestamps, size, attributes)
- Pointers to the file’s data blocks (runs)
- Named streams (e.g.,
::$DATA
) - File name entries (long and short names)
Key System Files in the MFT
Entry Name | Purpose |
---|---|
$MFT | The Master File Table itself |
$Bitmap | Tracks which clusters are used/free |
$LogFile | Journals metadata changes |
$Secure | Security descriptors and ACLs |
$Volume | Volume info (version, dirty flag) |
$AttrDef | List of valid attributes |
$Extend | Houses extended features (like quotas, EFS, USN Journal) |
File Record Attributes
Each NTFS file has a set of attributes that describe both the file and its contents. Attributes are stored either resident (inside the MFT entry) or non-resident (stored in separate clusters).
Common Attributes:
Attribute | Description |
---|---|
STANDARD_INFORMATION | Basic timestamps and permission flags |
FILE_NAME | Long and short name entries |
DATA | The file’s actual data (can be named streams) |
OBJECT_ID | Unique identifier for tracking |
SECURITY_DESCRIPTOR | NTFS ACLs |
ATTRIBUTE_LIST | Used if the record can’t fit in one MFT entry |
Resident Data
- Small files (<700 bytes) are stored directly in the MFT.
Non-Resident Data
- Larger files are stored elsewhere on disk and referenced via “data runs”.
File Metadata and Timestamps
NTFS tracks multiple timestamps:
Created
: File creation timeModified
: Last content modificationMFT Changed
: When metadata was last changedAccessed
: Last file access time
These are stored in STANDARD_INFORMATION
and FILE_NAME
attributes. Tools like MFTECmd
or FTK Imager
extract these for forensic timelines.
Alternate Data Streams (ADS)
NTFS supports multiple unnamed or named data streams in a single file. The main stream is usually :$DATA
, but you can add hidden ones.
Example:
echo "secret" > notepad.txt:hidden
type notepad.txt:hidden
Forensics Concern:
- ADS are often used to hide payloads or staging binaries.
dir /R
will list streams in Windows.
Directory Structure & Indexing
NTFS directories are files themselves with INDEX_ROOT
and INDEX_ALLOCATION
attributes.
- Small directories store entries directly inside the MFT (
INDEX_ROOT
) - Large directories spill over to other clusters (
INDEX_ALLOCATION
)
This design allows binary search indexing (B-tree like) instead of linear scanning.
Journaling with $LogFile
NTFS is a journaling file system.
$LogFile
stores redo/undo logs for critical metadata changes.- Ensures metadata integrity after a power failure or crash.
- Does not journal actual file content, only structural data.
This mechanism supports transactional consistency for files.
NTFS Recovery Concepts
NTFS uses a few safety mechanisms:
- $LogFile Recovery
- Replay undo/redo entries post-crash
- CHKDSK
- Scans metadata for inconsistencies
- Can fix MFT, indexes, bitmap mismatches
- Volume Dirty Bit
- Flag inside
$Volume
that triggers auto-CHKDSK
- Flag inside
USN Journal (Change Journal)
Located in: $Extend\$UsnJrnl
- Tracks all file-level changes (created, renamed, modified, deleted)
- Used by tools like antivirus, backup software, and forensic tools
- Each event is indexed by USN ID and timestamp
Enable / Query USN Journal:
fsutil usn queryjournal C:
NTFS Object IDs & Reparse Points
- Object IDs: Unique GUIDs for file tracking
- Reparse Points: Used for symbolic links, junctions, OneDrive placeholders
Types of reparse tags:
IO_REPARSE_TAG_SYMLINK
β Symbolic linkIO_REPARSE_TAG_MOUNT_POINT
β JunctionIO_REPARSE_TAG_APPEXECLINK
β App execution alias
You can create symbolic links using:
mklink file2.txt file1.txt
Common NTFS Attacks and Abuses
Abuse Technique | Description |
---|---|
ADS Persistence | Hide malicious DLLs or scripts in alternate streams |
MFT Record Abuse | Create thousands of MFT entries to trigger slowdowns or detection blind spots |
Symbolic Link Hijack | Abuse reparse points to redirect execution |
USN Journal Wipe | Delete forensic history using low-level tools |
Low-Level Tools for NTFS Exploration
Tool | Purpose |
---|---|
NTFSInfo (Sysinternals) | View cluster sizes, MFT layout |
MFTECmd (Eric Zimmerman) | Parse MFT and timestamps |
FTK Imager | Browse NTFS structure for forensics |
fsutil | Query volume, reparse points, streams |
NTFSWalker | Inspect MFT and attributes |
WinHex / 010 Editor | View raw disk sectors and parse binary templates |
Summary
- NTFS is a highly advanced file system that embeds metadata, journaling, and fine-grained security into every file.
- The MFT is the backbone of the file system, storing every file and folder as a database-like entry.
- ADS, USN, and Reparse Points introduce both powerful features and potential attack surfaces.
- NTFS journaling (
$LogFile
) and recovery structures provide strong integrity guarantees.
Windows Boot Process
Objective: Understand the internal steps that take place when a Windows machine powers on, leading up to the execution of user-level processes like
explorer.exe
.
Introduction
The Windows boot process involves several tightly coordinated stages that transition from firmware-level initialization (BIOS/UEFI) to the full-blown execution of the Windows operating system. Each phase has a critical role in preparing the system environment, loading essential files, initializing the kernel, and finally launching user-space processes.
This knowledge is fundamental when analyzing boot-time malware, rootkits, and persistence mechanisms that abuse early stages.

Boot Sequence Overview
Below is the high-level boot chain:
[BIOS / UEFI]
β
[Boot Manager (bootmgr)]
β
[Windows OS Loader (winload.exe)]
β
[Windows Kernel (ntoskrnl.exe)]
β
[Session Manager Subsystem (smss.exe)]
β
[Wininit.exe / Csrss.exe / Services.exe / Winlogon.exe]
β
[User logon and Explorer.exe startup]
Each stage is explained in detail below.
1. BIOS or UEFI Firmware
BIOS (Legacy)
- The Basic Input/Output System is firmware embedded on the motherboard.
- Initializes CPU, RAM, keyboard, and storage controllers.
- Scans for bootable devices using the boot order.
- Loads the Master Boot Record (MBR) from the first sector of the disk (LBA 0).
- MBR contains:
- Boot code (446 bytes)
- Partition table (64 bytes)
- Boot signature (2 bytes)
UEFI (Modern)
- Unified Extensible Firmware Interface replaces BIOS.
- Stores boot configuration in EFI System Partition (ESP).
- Loads
.efi
binaries likebootmgfw.efi
directly from the FAT32-formatted ESP. - Supports Secure Boot and faster initialization.
Key Outcome: BIOS or UEFI hands off execution to bootmgr
(via MBR or EFI).
2. Boot Manager (bootmgr
)
Location:
- BIOS: Found in the root of system partition (usually
C:\
) - UEFI: Located in
\EFI\Microsoft\Boot\bootmgfw.efi
Responsibilities:
- Reads Boot Configuration Data (BCD) from
\Boot\BCD
- Displays the boot menu (e.g., dual-boot options, recovery)
- Selects which OS to boot (if multiple)
- Loads the next-stage loader:
winload.exe
Boot Configuration Data (BCD):
- A binary registry-like file
- Contains entries for OS boot parameters
- Configurable via
bcdedit
Key Outcome: bootmgr
reads BCD and transfers control to winload.exe
.
3. OS Loader (winload.exe
)
Location:
C:\Windows\System32\winload.exe
Responsibilities:
- Loads essential drivers and kernel images into memory:
ntoskrnl.exe
(Windows kernel)hal.dll
(Hardware Abstraction Layer)- Boot-start drivers (from
HKLM\SYSTEM\CurrentControlSet\Services
)
- Loads system registry hives into memory
- SYSTEM hive is particularly crucial
- Enables DEP, ASLR, Code Integrity (if configured)
Integrity and Security:
- Verifies digital signatures on drivers if Secure Boot is enabled
- If BitLocker is used, winload handles the decryption process
Transition:
- After successful loading, winload calls into
ntoskrnl.exe
- Enters Protected Mode and switches to Kernel Mode
4. Kernel Initialization (ntoskrnl.exe
)
Location:
C:\Windows\System32\ntoskrnl.exe
Responsibilities:
- Initializes kernel subsystems:
- Memory manager
- Process scheduler
- Interrupt dispatcher
- Object manager
- Security reference monitor
- Starts the Hardware Abstraction Layer (
hal.dll
) - Initializes the System Service Descriptor Table (SSDT)
- Mounts the system drive using file system drivers (
ntfs.sys
, etc.)
Driver Loading:
- Executes
boot-start
andsystem-start
drivers (loaded from registry) - Uses
I/O manager
to create device stacks
Key Transition:
- Starts the first user-mode process:
smss.exe
(Session Manager)
5. Session Manager Subsystem (smss.exe
)
Location:
C:\Windows\System32\smss.exe
Role:
- The first user-mode process
- Created by the kernel using
PsCreateSystemProcess
Key Tasks:
- Loads system environment variables from registry
- Launches:
- CSRSS (Client/Server Runtime Subsystem)
- WININIT (Windows Initialization Subsystem)
- Initializes the page file
- Mounts additional volumes and prepares the Winlogon environment
- Creates user sessions (Terminal Services, multi-session support)
Sessions:
- Session 0: Reserved for system services
- Session 1+: Used for interactive logon
Key Outcome: smss.exe
spawns wininit.exe
and csrss.exe
.
6. Windows Initialization (wininit.exe
)
Responsibilities:
- Starts Service Control Manager (
services.exe
)- Loads all services marked as
auto-start
- Loads all services marked as
- Starts Local Security Authority (
lsass.exe
)- Handles authentication and policy enforcement
- Starts Winlogon (
winlogon.exe
)- Manages user logon, Ctrl+Alt+Del
- Loads GINA / Credential Providers
Csrss (Client/Server Runtime):
- Handles console windows, thread management
- Fundamental for GUI and Win32 subsystems
7. User Logon & Shell Startup
Winlogon.exe
- Displays the logon screen
- Invokes credential providers (e.g., password, PIN, smartcard)
- Upon successful authentication, calls
CreateProcessAsUser
for:
Explorer.exe
- Launches the Windows desktop, taskbar, file manager
- Runs under the user’s security token
Summary: Boot Flow Timeline
Stage | Component | Mode | Key Action |
---|---|---|---|
Firmware Init | BIOS/UEFI | Real Mode | Hardware init |
Bootloader | bootmgr | Protected | Loads BCD & winload |
OS Loader | winload.exe | Real β Prot. | Loads kernel & drivers |
Kernel Init | ntoskrnl.exe | Kernel Mode | Initializes OS subsystems |
User Init | smss.exe | User Mode | Sets up sessions, spawns services |
Wininit/Logon | wininit, winlogon | User Mode | Starts SCM, LSA, logon UI |
User Shell | explorer.exe | User Mode | Loads desktop |
Advanced Tips
- Safe Mode: Modifies BCD to restrict drivers (
bcdedit /set {current} safeboot minimal
) - Kernel Debugging: Use
bcdedit /debug on
and attach WinDbg over COM or network - Boot Tracing: Use tools like Process Monitor Boot Logging, xbootmgr, or boot trace logs via Windows Performance Toolkit
- Early Launch Anti-Malware (ELAM): ELAM driver is the first AV component loaded during kernel init
Windows OS Architecture
π‘ Goal: Understand how Windows is built under the hood β from User Mode to Kernel Mode, system layers, and what makes it tick. This is foundational for everything from malware development to EDR evasion.
π§ What is an Operating System?
An OS acts as a middleman between:
- You (the user / programs) and
- Hardware (CPU, RAM, Disk, etc.)
It:
- Manages processes and memory
- Handles file I/O
- Provides APIs to run apps
- Controls devices through drivers

π§© Key Components Breakdown
πΉ User Mode
- Apps like
notepad.exe
,chrome.exe
- Canβt directly talk to hardware or manage memory
- Must ask Kernel Mode via System Calls
- Hosts subsystems (e.g., Win32, POSIX, WOW64)
πΈ Subsystems
- Win32: Main API for GUI apps
- WOW64: Lets 32-bit apps run on 64-bit Windows
- POSIX: Legacy support for Unix-style tools
πΈ Kernel Mode
- Has full access to memory, devices, drivers
- Runs privileged code (Ring 0)
- Includes the Kernel, Executive, Drivers, and HAL
π§± Executive (NTOS)
Think of it as the “brains” of the kernel
Includes:
- Object Manager (handles Windows objects like files, processes)
- Memory Manager (allocates and pages memory)
- Process Manager (creates, manages threads/processes)
- Security Reference Monitor (permission enforcement)
βοΈ Kernel (Core)
- Deals with low-level threading, interrupt handling, synchronization
π¦ Device Drivers
.sys
files likedisk.sys
,kbdclass.sys
- Run in kernel mode and interact directly with hardware
𧬠HAL (Hardware Abstraction Layer)
- Allows Windows to run on different hardware by abstracting CPU/IO differences
- File:
hal.dll
π User Mode vs Kernel Mode
Feature | User Mode | Kernel Mode |
---|---|---|
Privilege Level | Ring 3 (low) | Ring 0 (high) |
Memory Access | Own virtual memory | Full system memory |
Crash Impact | Just the app | Whole system (BSOD) |
Direct Hardware Access | β No | β Yes |
Example | explorer.exe | ntoskrnl.exe , disk.sys |
βοΈ System Call Flow (Behind the Scenes)
When you run calc.exe
, here’s what happens:
- You click a shortcut
- Explorer.exe launches
calc.exe
usingCreateProcess
CreateProcess
β Win32 API- Win32 API β System Call (like
NtCreateProcess
) - Kernel validates permissions, allocates memory
- Kernel returns handle, app runs
β‘οΈ Every “simple” action is backed by 100+ low-level operations.
π§ͺ Hands-On Practice
Want to see the layers in action? Try these:
# On Windows PowerShell
Get-Process | Select-Object Name, Path, Id
# Peek into ntoskrnl usage
Get-WmiObject -Query "Select * from Win32_OperatingSystem"
# View loaded drivers (kernel-mode)
driverquery /v
Use Process Hacker or WinDbg to see threads, handles, and kernel objects live.
π§ Summary
- Windows is a hybrid kernel OS with clear User Mode and Kernel Mode
- User Mode apps can’t touch hardware directly β they rely on System Calls
- Kernel Mode contains the brain (
ntoskrnl.exe
), drivers, and HAL - Everything you do β launching apps, copying files β goes through this architecture