Windows Filesystem: NTFS, Folders, and Registry for Pentesting

Windows Filesystem Architecture: NTFS, System Folders, and the Registry Explained for a Pentester #

The Windows filesystem is not simply a list of folders you have to know by heart: it is a complex architecture based on volumes, NTFS permissions, registry hives, and security mechanisms that determine how the system manages files, configurations, and privileges.

Understanding how Windows is built , how permissions are applied, and who can actually access or modify a resource is critical to recognizing potential attack vectors during a Windows enumeration , penetration test , or privilege escalation.

In this article, we'll analyze the structure of the Windows filesystem , its main components, and the elements that can become attack surfaces. Each section ends with a "For Pentesters" box , linking the theory to the practical checks to be performed during a security assessment.

Before you start: what you need to know #

• Windows Basics: What is a path, the difference between user and administrator
• access to a shell on a Windows machine (RDP, exploit shell, or physical access into a lab)
• Helpful but not essential: NTFS registry and permissions basics

Visual overview of the structure #

Before going into the details of each component, let's take a look at the folder tree that will recur throughout the article:

C:\
├── Windows
│   ├── System32
│   │   ├── config          (hive SAM, SYSTEM, SECURITY)
│   │   ├── drivers          (.sys)
│   │   ├── DriverStore
│   │   ├── inetsrv          (config IIS)
│   │   └── Tasks
│   ├── SysWOW64
│   ├── WinSxS
│   ├── Prefetch
│   ├── Panther              (unattend.xml)
│   ├── SoftwareDistribution
│   └── Logs
│
├── Users
│   ├── <utente>
│   │   ├── Desktop / Documents / Downloads
│   │   └── AppData
│   │       ├── Roaming
│   │       ├── Local
│   │       └── LocalLow
│   └── Public
│
├── Program Files
├── Program Files (x86)
├── ProgramData
├── inetpub                  (solo se IIS è installato)
├── Recovery
├── PerfLogs
├── System Volume Information
└── $Recycle.Bin

How Windows is organized internally #

Before delving into the details of the filesystem, it's worth understanding what it relies on: the filesystem isn't an island; it's just one of the components the operating system works with. At a high level, a Windows boot process traverses these layers, one on top of the other:

Hardware
   ↓
UEFI / BIOS
   ↓
Windows Boot Manager
   ↓
Kernel (ntoskrnl.exe)
   ↓
HAL (Hardware Abstraction Layer)
   ↓
Executive
   ↓
Driver
   ↓
Servizi (Services)
   ↓
Session Manager
   ↓
Winlogon
   ↓
Explorer.exe
   ↓
Applicazioni

The key concept that holds all of this together is the separation between kernel mode and user mode :

• Kernel mode (Ring 0) — where the kernel itself, the HAL and the drivers run.HAL (Hardware Abstraction Layer) is the software layer that acts as a bridge between the operating system and the physical hardware of the machine: thanks to it, Windows can run on different hardware without having to rewrite the kernel each time. In kernel mode, there is direct and unlimited access to the hardware, and a crash here can bring down the entire system (the classic blue screen).
• User mode (Ring 3) — where all the normal applications run (Explorer, Chrome, cmd.exePowerShell): controlled access to resources, always mediated by the kernel. A crash in user mode at most closes that application, it does not bring down the system.

Inside kernel mode, the Executive is not a single program but a set of specialized subsystems — one manages memory, one manages processes, one manages security, one manages I/O — on which the drivers and, indirectly, the entire rest of the system rely.

A user mode application never talks directly to the hardware or the filesystem: it always goes through a chain of layers — the public APIs of kernel32.dll (the library that exposes Windows functions to applications), then the lower level functions of ntdll.dll (often pre-set Nt* o Zw*, which correspond almost directly to kernel operations), finally a system call —that is, a formal request that the program makes to the kernel, crossing the boundary between user mode and kernel mode. This boundary is also a security boundary: it's the point at which the system checks permissions before allowing an operation to proceed.

For the pentest: Understanding this chain explains why many evasion or code injection techniques work at the very level of ntdll.dll (for example bypassing the hooks of an EDR that intercepts calls at the kernel32.dll but not those directed to syscalls). Tools such as LOLBins They exploit these system binaries already loaded into memory to avoid importing obvious tools. It's not essential to write exploits at this level to conduct an effective pentest, but recognizing these names when they appear in a tool or report prevents you from treating them as black boxes.

Filesystem Architecture: NTFS, Volumes, and Links #

Windows organizes data on disk using NTFS (New Technology File System), the default file system used since Windows NT. NTFS isn't just "where files are": it also manages permissions (ACLs, discussed later), native encryption (EFS), and several types of path connections that are worth carefully distinguishing.

Volumes and drive letters. Each disk (or partition) is assigned a letter — C:, D: and so on — which Windows treats as an independent root. C: It is almost always the system volume, but on servers with multiple disks you may find application data, backups or shares on separate volumes, often overlooked during an enumeration that focuses only on C:\. In progress post-exploitation, enumerating all mounted volumes is one of the first steps: backup and share on D:\ o E:\ may contain sensitive data not present on the system volume.

Mount point, junction, reparse point, symbolic link, hard link. These concepts are often confused, but the difference is important:

• Un mount point links an entire volume to an empty folder on another volume, rather than assigning it a letter — useful on servers with many disks
• An junction It is a folder-level symbolic link, but limited to the same computer (it does not cross the network) and historically usable even by non-administrator users
• Un repair point It's the technical mechanism behind junctions and symbolic links: a special attribute that NTFS attaches to a folder or file to signal to the filesystem "when a program gets here, it goes through this filter before proceeding" — and that filter can redirect it elsewhere, decrypt the contents, or do more.
• Un symbolic link (symlink) is conceptually similar to a junction but more flexible: it can point to individual files, work across network paths, and — unlike junctions — its creation typically requires elevated privileges (unless developer mode is active).
• Un hard link it's not a link but a second name for same Disk content: deleting one of the two names does not delete the data as long as there is at least one other hard link pointing to those blocks

For pentesters: Junctions and reparse points have been a local privilege escalation vector on Windows for years, allowing a non-privileged user to cause a more privileged process to write to a path other than the intended one. But a junction only becomes a vector when all of these conditions are met: the user controls the source directory, a more privileged process performs an operation there (read, write, rename, delete), that process follows the reparse point, and the operation can be triggered or included in a race condition. To enumerate existing junctions and reparse points: Useful commands:

Get-ChildItem C:\ -Force -Recurse -Attributes ReparsePoint -ErrorAction SilentlyContinue
cmd /c "dir C:\percorso /al /s"
fsutil reparsepoint query "C:\percorso\link"

What's Under the Hood of NTFS: MFT, ADS, Journal #

NTFS doesn't just organize visible folders and files: it keeps track of everything in internal structures that are worth knowing at least in broad terms.

• Master File Table (MFT) —Think of the MFT as the index of a huge book: it contains a record for every file and folder on the volume, along with all the metadata (location, size, permissions, timestamps). When Windows needs to find a file, it consults the MFT first instead of typing on the disk.
• Alternate Data Stream (ADS) —NTFS allows a file to have additional, hidden data streams beyond its main contents. If you have a file relazione.txt, you can place it next to him relazione.txt:contenuto_nascosto and that second stream does not appear with a dir normal — it is invisible to those who don't know how to look for it
• $UsnJrnl (Update Sequence Number Journal) — the prefix $ indicates that it is an internal NTFS file, not normally visible. It records every modification to the volume's files (creation, renaming, deletion) with a progressive sequence number, but immense retains the contents of the files and the history can be overwritten over time. To be distinguished from $ LogFile, the NTFS metadata transactional log that ensures filesystem consistency in the event of a crash

For pentesting and forensics: ADS have historically been used to hide payloads or data inside seemingly innocuous files. Zone.Identifier It is the most common ADS and legitimate (Windows adds it to files downloaded from the Internet for Mark of the Web) — the mere presence of an ADS does not indicate a payload. To enumerate ADS on files or folders:

cmd /c "dir C:\percorso /r"           # mostra ADS con dimensione
Get-Item "C:\file.exe" -Stream *      # lista tutti gli stream
Get-Content "C:\file.exe" -Stream Zone.Identifier   # legge uno stream specifico

The journal $UsnJrnl It is valuable in forensics for reconstructing created, modified, or deleted files, even when the contents are no longer recoverable. Not to be confused with $LogFile, the NTFS transactional log that ensures filesystem consistency in the event of a crash: its purpose and structure are different.

“Special” files: Where Windows stores system memory #

In addition to normal files and folders, the root of the system disk contains some files with a special role, related to memory management:

• pagefile.sys — the paging file, used by Windows as an extension of RAM when physical memory is not enough; it is located in the root of the system volume
• hiberfil.sys — contains the complete state of the RAM when the system enters hibernation; on systems with Fast Startup enabled (Windows 10/11) it may be a reduced version, not necessarily the full dump
• swapfile.sys — mainly used by UWP/Store apps for memory management
• %SystemRoot%\MEMORY.DMP — a complete RAM dump, generated in the event of a severe system crash (BSOD); smaller minidumps go into %SystemRoot%\Minidump\

For the pentest: These files may contain process memory fragments, including credentials, authentication tokens, or encryption keys that were in RAM at the time they were created. In an offline analysis (for example, with an extracted disk or a forensic image), tools like Volatility can extract secrets from hiberfil.sys or from a MEMORY.DMP exactly as they would from a live memory dump.

Main Folders: What They Contain and Why They Exist #

On a standard Windows installation, the root of the system disk always contains more or less the same folders, each with a specific purpose in the system architecture:

For the pentest: System Volume Information It is normally unreadable even by local administrator (owned by SYSTEM), but it is where the Restore Point created by System Restore and the data of the Volume Shadow Copy Service (VSS) — the automatic snapshots that Windows creates before operations such as updates, which are very useful for reading registry hives that would otherwise be locked, as we will see. Note: The Windows Search database is instead located under C:\ProgramData\Microsoft\Search\Data\, not here.

Inside C:\Windows: The Heart of the Operating System #

C:\Windows It alone contains a huge portion of the entire system's logic. It's worth exploring its main subdirectories one by one.

System32 and SysWOW64. On a 64-bit Windows, System32 contains the tracks to 64 bit of the system, while SysWOW64 contains those to 32 bit, for compatibility. The name is misleading: “System32” makes you think otherwise, but it’s a historical relic from when Windows was still 32-bit — Microsoft kept the old name so as not to break thousands of programs with that handwritten path, moving the 32-bit binaries to a new folder.

For the pentest: If you run a 32-bit script from a 64-bit process, some system calls are automatically redirected from System32 to SysWOW64 (the File System Redirector) — if you're not aware of it, a file you know exists may seem to have disappeared. The same mechanism also exists for the registry (Registry Redirector): a 32-bit process that reads HKLM\Software he actually sees HKLM\Software\WOW6432Node, a parallel copy designed to avoid conflicts with keys written by 64-bit software. If you need to bypass the file redirector and still access System32 from a 32-bit process, Windows also exposes the special path C:\Windows\Sysnative, which exists only virtually and never appears in a folder listing.

WinSxS. The folder C:\Windows\WinSxS (“Windows side-by-side”) is not a simple cache or backup folder: it is the Component Store of Windows, the framework that the system uses to install, update, remove and repair the components of the operating system itself. It contains multiple versions of the same library installed simultaneously, allowing different applications to use the version of a DLL they have been tested with, without conflicts between them (the classic “DLL Hell” problem that WinSxS solves).

For pentesters: WinSxS maintains multiple versions of system components, but the physical presence of an "old" file doesn't automatically mean it's loaded or exploitable—the loader uses manifests to determine which version to activate. That said, when investigating possible DLL hijacking scenarios (an application loads a library from the wrong path), this is where you might find older versions of system libraries; but it's always worth checking whether that version is actually loaded and whether the loading path is controllable.

DriverStore. C:\Windows\System32\DriverStore It is the central repository of driver packages that Windows has seen and installed, separate from the drivers actually active in System32\drivers (See below.) When you install a device, Windows often copies the driver package here first, then activates it.

For pentesting: A list of historically installed drivers (even if no longer in use) can reveal third-party hardware or software that was connected to the machine in the past—useful for reconnaissance, and sometimes a clue to USB devices or peripherals that are no longer physically present but whose traces remain.

Prefetch. C:\Windows\Prefetch Contains files that Windows creates to speed up the startup of frequently used programs by recording which files are loaded during execution.

For pentesting and forensics: Prefetch files reveal which programs were run on the machine, how often, and when they were last run—one of the most reliable sources for reconstructing a system's recent activity, whether in an offensive analysis or a defensive forensic investigation.

SoftwareDistribution. C:\Windows\SoftwareDistribution This is where Windows Update downloads and manages updates before and after installation.

For the pentest: The contents of this folder and its logs provide information on the status of the machine's updates, but they are not the most reliable source for determining whether a specific CVE is exploitable: the folder can be cleaned and does not necessarily reflect the actual installed packages. For a serious assessment, you need the build and UBR (Update Build Revision) from the registry, the packages installed via dism /online /get-packages, and the CBS.log.

panther. Contains the answer files (unattend.xml, Unattended.xml) used to automate Windows installation — network settings, partitioning, and often a local administrator account with a Base64-encoded password, intended for automatic deployment without manual intervention.

For the pentest: A forgotten file here, which happens more often than you might think with "golden" images distributed via centralized deployment tools, is equivalent to giving away a local administrator password. Metasploit has a dedicated module: post/windows/gather/enum_unattend.

Tasks / System32\Tasks. Scheduled tasks exist as XML files, each with the action to perform and the account under which it is launched.

For pentesters: they reveal script paths executed with elevated privileges—often writable by non-privileged users, a classic privilege escalation vector —and the service accounts used for execution. We discuss this in detail in the article on Scheduled Tasks.

Logs, INF, Fonts, servicing, PolicyDefinitions. More peripheral folders but with a specific role: Logs collects setup and maintenance logs (CBS.log, DISM.log, setupact.log — useful for reconstructing machine context, such as usernames or SMB shares involved in past operations); INF contains files that describe how to install drivers and components; Fonts it's self-explanatory; servicing manages component update packages (closely tied to WinSxS); PolicyDefinitions Contains the ADMX files used by Group Policy to define which settings are configurable.

How Windows Loads Code: DLLs, PE Formats, and Where DLL Hijacking Comes From #

A Windows executable (.exe) and a library (.dll) share the same binary format, the PE (Portable Executable): A DOS Header initial (historical residue, kept for compatibility), followed by the true PE Header, and from a series of sections with distinct roles — .text (the executable code), .data (initialized data), .rdata (read-only data, including import/export tables), .reloc (information on how to relocate the code if uploaded to a different address than expected).

The two most relevant tables inside .rdata are:

• Import Table — lists which functions, from which external DLLs, the program will use
• Export Table — lists what functions a DLL makes available for use by other programs

When a program starts, Windows must load into memory all the DLLs listed in its Import Table, using functions such as LoadLibrary e GetProcAddressThe crux of the matter: if a requested DLL does not specify an absolute path (i.e. the full path like C:\Windows\System32\nome.dll), Windows searches for it following a specific order of folders — the DLL Search Order. Typically: first the application folder itself, then the KnownDLLs (a list of system libraries considered “safe” and pre-loaded into memory, which Windows explicitly protects precisely to prevent them from being replaced), then System32, SysWOW64, the Windows folder, the current folder, and finally the folders listed in %PATH%.

For pentesters: DLL hijacking exploits exactly this search order: if you manage to place a malicious DLL with the same name in a folder that Windows checks before the legitimate one (for example, the application folder, if writable), the program will load your DLL instead of the original one, executing your code with that process's privileges. This is the same principle that, as seen above, explains why WinSxS preserves old versions of libraries: an application that depends on an outdated and vulnerable version of a DLL is a prime target for this technique.

The user profile: structure and logic #

Bottom C:\Users\<nome-utente> You'll find the personal profile of every account that's logged in at least once. The default folders are designed with the end user in mind: Desktop, Documents, Downloads, Pictures, Music, Videos, Contacts, Saved Games, Searches — each with a purpose declared by the name, designed to organize personal files in a standard way on every Windows machine.

The most interesting part from a technical point of view is AppData , divided into three folders with a specific purpose:

• roaming — application data designed to follow the user from one machine to another in the same domain (in a corporate environment with roaming profiles configured)
• Local News — data tied to the specific machine, never synchronized elsewhere
• LocalLow — a reduced-permissions version of Local, used by processes running in “sandboxed” mode (for example, some browsers in protected mode)

This separation exists because not all application data makes the same sense everywhere: a program's settings may make sense to follow the user (Roaming), while a local cache tied to specific hardware does not (Local).

For the pentest: AppData hosts many of the credentials saved by third-party applications (FTP/VNC/SSH clients, browsers, password vaults), often protected by DPAPI —the Windows mechanism that encrypts data and ties it to the user account. But it's not the only place: other secrets lie in the registry, Credential Manager, scattered configuration files, and SSH keys. This is a good starting point, but not an exhaustive list.

The Registry: How Disk Hives Become HKLM, HKCU, and the Others #

The Windows registry is not a single file: it is a collection of hive, binary files on disk that the system loads and presents as a single hierarchical tree structure. The main roots you see in regedit:

• HKEY_LOCAL_MACHINE (HKLM) — machine-wide settings, valid for all users; built by merging hives like SYSTEM, SOFTWARE, SAM, SECURITY, all physically present under C:\Windows\System32\config
• HKEY_CURRENT_USER (HKCU) — settings of the currently logged in user; it is actually a dynamic link to the hive NTUSER.DAT inside that user's profile
• HKEY_USERS (HKU) — contains the hives of all users with a loaded profile, not just the current one; HKCU is actually a pointer to one of the subkeys in here
• HKEY_CLASSES_ROOT (HKCR) — associations between file extensions and programs, COM objects; combines data from HKLM and HKCU
• HKEY_CURRENT_CONFIG (HKCC) — information about the active hardware profile, less relevant in modern systems with only one hardware profile

Understanding this relationship between hives-on-disk and roots-in-registry is useful because it explains why, for example, changing NTUSER.DAT of an offline user (manually mounting him) is equivalent to changing his HKCU when he logs in.

A small table to fix the correspondence between logical hive and physical file on disk:

All (except NTUSER.DAT, which is in the user profile) live under C:\Windows\System32\config.

For the pentest: in HKLM\SYSTEM\CurrentControlSet\Services, each service has a subkey with the value ImagePath, which indicates the executable launched by the service — if the path is not quoted and contains spaces, or if it points to a file writable by a non-privileged user, you have a classic escalation vector. The keys Run/RunOnce under HKLM\Software\Microsoft\Windows\CurrentVersion (and the equivalent in HKCU) indicate what starts automatically at login. And inside System32\config hives live SAM, SYSTEM e SECURITY —locked while Windows is running, removable with reg save or from a Volume Shadow Copy, and can be analyzed with tools such as Impacket reg.py or with SeBackupPrivilege if available.

PowerShell commands to explore the architecture seen so far #

Get-Volume                  # elenca i volumi montati, con filesystem e spazio libero
Get-ChildItem Env:           # mostra tutte le variabili d'ambiente disponibili
Get-Acl C:\percorso\file     # mostra owner e ACL di un file o cartella
fsutil fsinfo drives         # elenca le lettere di unità disponibili
mountvol                     # mostra i mount point e i volumi montati come cartella

These are read-only commands, useful for quickly orienting oneself on the real architecture of a newly accessed machine, before even looking for specific attack vectors.

Environment Variables: The Shortcuts Windows Offers to Each Process #

Windows exposes several paths via environment variables, which are intended to make scripts portable between different machines without writing absolute paths:

For the pentest: These variables come up again and again in enumeration scripts and public exploits, precisely because they make a command work regardless of where Windows is installed (not always C:\) or by whoever performs it — it is worth getting used to reading them on the fly instead of always having to expand them mentally.

Permissions: ACLs, Ownership, and Why “Administrator” Isn't Always Enough #

Every file and folder on NTFS has an ACL (Access Control List) that defines who can do what, and an owner who by default always has control over that file's permissions, regardless of what the ACL itself says.

The most relevant accounts/groups to know about:

• SYSTEM — the account under which most kernel processes and core services run; it effectively has complete control over the machine
• TrustedInstaller — a special account, introduced to protect the most critical system files, which owns many files inside System32 and other protected folders — even the Administrator account cannot modify them without first explicitly taking ownership (takeown) and grant yourself permissions, because the ACL of those files does not give write access to Administrator by design
• Administrator — broad, but not unlimited privileges on files owned by TrustedInstaller
• Users — minimal permissions, typically read and execute on system folders
• Everyone — includes all authenticated users; in modern default configurations does not include anonymous users (this depends on the “Network access: Let Everyone permissions apply to anonymous users” policy, which is disabled by default)

An important point about ownership: owning a file does not automatically mean having "complete control" over its contents. The owner implicitly gains WRITE_DAC, that is, the right to modify the DACL (the file's permissions list) — which indirectly allows you to grant yourself any permission, but it's an extra step, not automatic.

Where Permission Control Really Comes From: The Access Token #

A detail that explains why an ACL control works: when a user logs in, Windows assigns him an Access Token , an object that carries with it his identity and his rights for the entire session:

Utente → Logon → Access Token → SID → Privilegi → confronto con l'ACL dell'oggetto

The token contains the SID (Security Identifier, the unique identifier of the user and the groups to which it belongs) and the list of assigned privileges (such as SeDebugPrivilege or SeImpersonatePrivilege ). Whenever that process attempts to access a file, registry key, or any other resource, Windows compares the token with the resource's ACL and decides whether to grant access.

This is possible because, internally, Windows doesn't treat files, registry keys, processes, and mutexes as different things: they're all Objects , managed by a component called Object Manager , each with its own Security Descriptor (which contains the ACL) and accessible via a Handle —a numeric reference the process receives when Windows grants it access to that object, valid only for that session. This is why the same concept of permissions (owner, ACL, access control) applies identically to a file on disk and, for example, to a running process.

For the pentest: icacls (o Get-Acl) is one of the first commands to run on suspicious files and services, but be careful: the relevant permissions are on four distinct levels which must be checked separately:

1. **ACL del file** — posso sovrascrivere o modificare l'eseguibile?
2. **ACL della directory padre** — posso creare, rinominare o cancellare file nella stessa cartella?
3. **ACL del servizio** — posso cambiare `ImagePath` o l'account? (`sc.exe sdshow <servizio>`)
4. **ACL della share SMB** — se il percorso è su una condivisione, i permessi NTFS e quelli della share si sommano (vince il più restrittivo tra i due)

For PATH hijacking, it is worth checking which directories of the %PATH% they are writable:

$env:PATH -split ';' | Where-Object { $_ } | ForEach-Object {
    $acl = (Get-Acl $_ -ErrorAction SilentlyContinue).Access
    if ($acl -match "Write|Modify|FullControl") { $_ }
}

A directory that is writable before the PATH of a DLL or executable searched for without an absolute path is a hijacking vector. Exploitation details are in the Windows Privilege Escalation guide and in SharpUp . ACL abuse on AD objects has its own dedicated guide on acl-abuse.

Services and Drivers: From Registry to Kernel #

Windows services are defined in the registry (the key Services seen above) but actually executed in two ways: as a dedicated process, or hosted inside svchost.exeThe latter is a host process shared by many Windows services: instead of having a separate executable for each individual service (with the resulting cost in terms of memory and resources), Windows groups multiple related services into a single instance of svchost.exe, reducing the total number of running processes. On a modern Windows you will often see dozens of instances of svchost.exe in Task Manager, each with one or more services inside it.

An often simplified aspect: a unquoted service path (executable path with spaces and no quotes in the registry) cannot be exploited automatically. For it to become a real vector, the following are required at the same time: the service must run with elevated privileges, the path must contain spaces and no quotes, and you must have write access to one of the candidate routes that Windows would try before the legitimate binary, and you need to be able to start the service or wait for it to restart. In addition to the NTFS permissions on the binary, it's also worth checking the permissions on the service object itself with sc.exe sdshow <nome_servizio>: SERVICE_CHANGE_CONFIG allows you to change the executable path regardless of NTFS permissions.

I driver are a special case of service: files with the extension .sys, typically under C:\Windows\System32\drivers, loaded directly into the kernel instead of as a user process. It is worth distinguishing between two distinct scenarios: exploiting a driver already loaded with a vulnerability accessible by a standard user (via a device object or an IOCTL interface exposed without proper privilege checks) — which is one of the most serious escalation vectors because the code runs in kernel mode; or loading a new vulnerable driver (BYOVD, Bring Your Own Vulnerable Driver), which however already requires specific privileges to install the driver and presupposes a significantly different attack context.

System Boot: BCD, bootmgr, EFI #

Before the Windows kernel even loads, a chain of boot components comes into play: the firmware. EFI (or the old BIOS/MBR on older systems) locates the Bootmgr, which reads the BCD (Boot Configuration Data, the modern equivalent of the old boot.ini) to find out which operating system to boot and with which options. From there, winload.efi (o winload.exe on legacy BIOS systems) is the component that actually loads the Windows kernel and essential boot drivers into memory, before finally handing control over to it.

The complete timeline, from startup to desktop, passes through a very specific sequence of processes:

Accensione PC → UEFI → EFI Partition → bootmgfw.efi → BCD → winload.efi
   → ntoskrnl.exe (kernel) → HAL → smss.exe → csrss.exe → wininit.exe
   → services.exe → lsass.exe → winlogon.exe → explorer.exe

Each process in this chain has a specific role, and several of these continually come up in a pentest or post-exploitation analysis:

For pentesting: If I had to remember just one process from this table, it would be lsass.exe —it's the heart of nearly every credential dumping technique , which is why modern Windows protects it with mechanisms like Credential Guard and Protected Process Light. A tool that directly leverages credential dumping is Mimikatz . For physical pentesting: These boot components are rarely targeted in remote pentesting, but become relevant with physical access (password bypass via alternate media, BCD modification to enable Safe Mode). The main limitation in these scenarios is BitLocker : if the system volume is encrypted, offline access to the disk is blocked without the recovery key, making many of these techniques inapplicable without that key.

How Windows Thinks When You Open a File: The Entire Chapter in One Flow #

Putting together almost all the concepts we've seen so far, here's what actually happens when an application opens a file — from user code all the way to the physical disk:

Applicazione
   ↓ (chiamata a un'API pubblica)
kernel32.dll
   ↓ (funzione di basso livello)
ntdll.dll → NtCreateFile
   ↓ (system call)
Kernel: I/O Manager
   ↓ (verifica ACL sul token dell'utente, poi inoltra)
Filesystem Driver (NTFS)
   ↓
Disco fisico

Each step of this chain is one of the concepts explained in this article: the kernel/user mode separation, the syscalls through ntdll.dll, the Object Manager that verifies the token against the resource's ACL, and finally NTFS that translates the request into physical blocks on the disk. This isn't a textbook detail: it's the sequence that makes it understandable. because A denied permission, a security hook, or a locked file behave the way you observe them during a pentest.

Same structure, different authentication: the file system in an Active Directory domain #

One last useful point if you frequently work in corporate environments: when a Windows machine is part of an Active Directory domain , the local filesystem structure we've seen in this article remains identical —same Program Files, same System32, same registry. What changes is everything around it: authentication is done through the domain instead of local accounts, Group Policy can enforce specific configurations (including those distributed via SYSVOL and NETLOGON), profiles can be roaming rather than tied to a single machine, and services like DNS, Kerberos , and LDAP become an integral part of how the machine behaves on the network. The disk map doesn't change; what changes is who decides what you can do with it.

Path namespaces: \\?\, \\.\, Volume GUID and UNC #

An often ignored but relevant aspect both for understanding the tools and for understanding certain bypasses: Windows supports multiple syntaxes for expressing a path, not only C:\cartella\file.

• Normal route C:\Windows\System32\cmd.exe: the usual, subject to canonicalization and 260 character limits
• UNC \\server\condivisione\file: to access network resources; also works locally (\\127.0.0.1\c$\file). This syntax is the basis of how it works. SMB for file sharing and on which various techniques are based lateral movement
• \\?\ (extended-length path) — bypass canonicalization and MAX_PATH limit: \\?\C:\percorso\molto\lungo\...; many security tools and some virus scanners do not handle this syntax correctly.
• \\.\ (device namespace) — direct access to kernel device objects: \\.\PhysicalDrive0, \\.\pipe\nome for named pipes, \\.\C: for the raw volume
• Volume GUID \\?\Volume{GUID}\file: uniquely identifies a volume regardless of the assigned letter; useful in scripts when the letter can change

For the pentest: the syntax \\?\ It has historically been used to bypass path controls (path traversal, AVs that cannot normalize it, pattern-based whitelists), and device namespaces allow access to IPC channels and raw disks that are not normally reachable via normal file paths.

Operating controls: orienting yourself on a machine you have just reached #

Once you have a shell, these commands cover the initial checks without installing anything. If you want to automate this process, WinPEAS and Seatbelt cover these and many other checks with a single executable:

whoami /all                                    # utente, gruppi e TUTTI i privilegi del token
dir /r C:\Users\<utente>                        # elenca anche gli Alternate Data Stream nascosti
Get-Item -Path C:\file.txt -Stream *           # ADS su un file specifico (PowerShell)
fsutil reparsepoint query C:\percorso          # verifica se una cartella è un reparse point/junction
icacls C:\percorso\file.exe                    # permessi NTFS su file e cartelle
sc.exe qc <nome_servizio>                      # configurazione servizio: percorso eseguibile, account
sc.exe sdshow <nome_servizio>                  # Security Descriptor del servizio (chi può fare cosa)
schtasks /query /fo LIST /v                    # task pianificate con tutti i dettagli
vssadmin list shadows                          # Volume Shadow Copy disponibili
dism /online /get-packages                     # patch effettivamente installate (più affidabile di SoftwareDistribution)

Forensic and Enumeration Artifacts: Quick Table #

In addition to the root folders, these paths often appear in enumeration and post-exploitation:

The System Resource Usage Monitor ( SRUM ) is particularly useful in forensic scenarios: it records which processes used how much network and CPU space, and can reveal executed tools that leave no other trace.

Detection & Blue Team #

• Event 4656/4663 (Security log) — opening handles and accessing objects (files, registry): these report reading of SAM/SECURITY hives; they require both an enabled audit policy and a SACL on the object, otherwise they are not generated
• Event 4670 — change permissions on an object: useful for monitoring who takes ownership of system files with takeown
• Sysmon Event 6 — Loading a driver: essential for detecting abnormally loaded drivers or BYOVD (Bring Your Own Vulnerable Driver) scenarios
• Sysmon Event 11 — file creation; Event 12-14 — create/modify/delete registry keys; Event 15 — creation of Alternate Data Stream: the latter is specific to detect ADS used to hide payloads
• Monitor the creation of junctions or reparse points in sensitive paths by non-system processes
• Check periodically with icacls permissions on binaries run by privileged services: a SYSTEM service with an executable writable by Users is an immediate risk
• Remove answer files (Panther\Unattend.xml) after deployment
• Periodically audit Run/RunOnce keys and the Tasks folder for unauthorized persistence

FAQ #

What's the difference between a junction and a symbolic link? Both redirect one path to another, but a junction only works on the same computer and can historically be created even by non-administrator users. A symbolic link is more flexible (it also works on network paths) but generally requires higher privileges to create.

Why can't Administrator sometimes modify a system file? This is because some critical files are owned by the TrustedInstaller account, not Administrator. You must first explicitly take ownership of the file before you can modify it.

Does System32 contain 32-bit or 64-bit binaries? 64-bit, despite the name. The 32-bit binaries are in SysWOW64—one of the more counterintuitive features of Windows.

What is WinSxS used for in practice? It allows multiple versions of the same library to coexist on the system, preventing updating one DLL from breaking another application that depends on an older version.

Is HKCU separate from HKLM? Yes: they are distinct logical roots. HKCU is dynamically mapped to the current user's subkey within HKEY_USERS—that is, HKU\<SID_utente> — which in turn is built by the system by loading the file NTUSER.DAT of the profile. So HKCU is not “NTUSER.DAT”, but reflects its contents through this mapping.

Where can I find the list of tasks that start automatically at startup? In the Run and RunOnce registry keys (both in HKLM and HKCU) and in the Scheduled Tasks folder under System32\Tasks.

What is the difference between kernel mode and user mode? Kernel mode (Ring 0) has direct and unrestricted access to the hardware—it runs the kernel, HAL, and drivers; user mode (Ring 3) is where normal applications run, with access still mediated by the kernel via system calls.

Why is lsass.exe so important in a pentest? Because it handles authentication and stores active session hashes and credentials in memory. A memory dump (using tools like Mimikatz) is the classic way to extract credentials without directly touching registry hives.

What is DLL hijacking, in short? It exploits the order in which Windows searches for DLLs required by a program: if you manage to place a malicious DLL with the same name in a controlled folder before the legitimate one, the program loads and executes your code in its place.

What is Windows Object Manager? It's the component that treats files, registry keys, processes, and other items as a single category of "objects," each with a Security Descriptor (which contains the ACL) and accessible via a Handle—which is why the same permissions model applies to both files and, for example, processes.

To learn more #

On Hackita, the natural insights starting from this article:

• Windows Privilege Escalation — how to transform architectural understanding into concrete vectors of escalation
• WinPEAS — the tool that automates enumeration on almost everything we've seen
• seat belt — more surgical enumeration, useful when WinPEAS is too noisy
• Credential Dumping — what to do once you've located the SAM/SECURITY or lsass hives
• DPAPI — the mechanism that protects most of the secrets inside AppData

External resources:

• PayloadsAllTheThings — Windows Privilege Escalation — the most complete collection of techniques, vectors and commands on Windows privesc
• Shard Security — Windows File System & Registry — good compact guide oriented to practical pentesting
• Pentest Everything — Windows Privilege Escalation Checklist — operational checklist to follow after understanding the structure

This article is for educational purposes only. Techniques tested on authorized environments such as HackTheBox, VulnLab, and personal labs.