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

FeatureDescription
Metadata-drivenEvery file and directory is stored as a metadata record in the MFT
JournalingChanges to critical metadata are recorded in the $LogFile before being committed
SecurityFull support for file permissions, ACLs, and encryption (EFS)
ADS (Alternate Data Streams)Allows multiple data streams per file
Compression & EncryptionBuilt-in per-file compression and support for EFS
Hard Links & Reparse PointsAdvanced linking and symbolic path redirection features
Sparse FilesSupport 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 NamePurpose
$MFTThe Master File Table itself
$BitmapTracks which clusters are used/free
$LogFileJournals metadata changes
$SecureSecurity descriptors and ACLs
$VolumeVolume info (version, dirty flag)
$AttrDefList of valid attributes
$ExtendHouses 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:

AttributeDescription
STANDARD_INFORMATIONBasic timestamps and permission flags
FILE_NAMELong and short name entries
DATAThe file’s actual data (can be named streams)
OBJECT_IDUnique identifier for tracking
SECURITY_DESCRIPTORNTFS ACLs
ATTRIBUTE_LISTUsed 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 time
  • Modified: Last content modification
  • MFT Changed: When metadata was last changed
  • Accessed: 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:

  1. $LogFile Recovery
    • Replay undo/redo entries post-crash
  2. CHKDSK
    • Scans metadata for inconsistencies
    • Can fix MFT, indexes, bitmap mismatches
  3. Volume Dirty Bit
    • Flag inside $Volume that triggers auto-CHKDSK

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 link
  • IO_REPARSE_TAG_MOUNT_POINT – Junction
  • IO_REPARSE_TAG_APPEXECLINK – App execution alias

You can create symbolic links using:

mklink file2.txt file1.txt


Common NTFS Attacks and Abuses

Abuse TechniqueDescription
ADS PersistenceHide malicious DLLs or scripts in alternate streams
MFT Record AbuseCreate thousands of MFT entries to trigger slowdowns or detection blind spots
Symbolic Link HijackAbuse reparse points to redirect execution
USN Journal WipeDelete forensic history using low-level tools

Low-Level Tools for NTFS Exploration

ToolPurpose
NTFSInfo (Sysinternals)View cluster sizes, MFT layout
MFTECmd (Eric Zimmerman)Parse MFT and timestamps
FTK ImagerBrowse NTFS structure for forensics
fsutilQuery volume, reparse points, streams
NTFSWalkerInspect MFT and attributes
WinHex / 010 EditorView 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 like bootmgfw.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 and system-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
  • 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

StageComponentModeKey Action
Firmware InitBIOS/UEFIReal ModeHardware init
BootloaderbootmgrProtectedLoads BCD & winload
OS Loaderwinload.exeReal β†’ Prot.Loads kernel & drivers
Kernel Initntoskrnl.exeKernel ModeInitializes OS subsystems
User Initsmss.exeUser ModeSets up sessions, spawns services
Wininit/Logonwininit, winlogonUser ModeStarts SCM, LSA, logon UI
User Shellexplorer.exeUser ModeLoads 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

os a

🧩 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 like disk.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

FeatureUser ModeKernel Mode
Privilege LevelRing 3 (low)Ring 0 (high)
Memory AccessOwn virtual memoryFull system memory
Crash ImpactJust the appWhole system (BSOD)
Direct Hardware Access❌ Noβœ… Yes
Exampleexplorer.exentoskrnl.exe, disk.sys

βš™οΈ System Call Flow (Behind the Scenes)

When you run calc.exe, here’s what happens:

  1. You click a shortcut
  2. Explorer.exe launches calc.exe using CreateProcess
  3. CreateProcess β†’ Win32 API
  4. Win32 API β†’ System Call (like NtCreateProcess)
  5. Kernel validates permissions, allocates memory
  6. 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