# Exploring Windows Internals: A Guide for Security Engineering Windows, as you might already know, is quite prevalent. With the low-level programming already gained in C/C++ and reverse engineering intro I have learned about so far, I had to also look into how Windows works from a security perspective. When spinning up environments like FLARE VM for dynamic malware analysis, or writing low-level C code that interacts with `#include ` (`windows.h` is a header file in the C and C++ programming languages that lets your computer program use features from the Microsoft Windows operating system, more specifically, the **Windows API**), understanding the underlying operating system architecture is critical. Operating systems orchestrate complex interactions between hardware and software, and Windows relies on a highly specific structure to manage memory, execution, and security. ## Demystifying Windows Architecture ![](https://cdn.hashnode.com/uploads/covers/69ad46a686766ac3a61e712e/764ed4e8-3188-40e3-9529-8c44616fc141.png align="center") Windows relies on a separated architecture to maintain system stability and security, operating primarily in user mode and kernel mode. 1. **User mode** is designated for standard software and applications that a user interacts with daily, such as web browsers. 2. **Kernel mode** is reserved for critical, low-level tasks including hardware interaction and memory management. Code executing in user mode is intentionally restricted from interfering with kernel mode to prevent malicious or misconfigured applications from crashing the entire operating system or altering it. ### Applications These are the software and programs that a user runs. ### Windows application programming interface (WinAPI) This is what applications rely on in order to function. ### Drivers These control various devices on the system and provide an abstraction layer between the devices and the programs that wish to interact with them. There are two kinds of drivers. 1. **Hardware device drivers** * take input/output (IO) requests and convert them to hardware IO requests, such as for the mouse and keyboard. 2. **Non-hardware device drivers** * controls system components such as network interfaces and the filesystem. Some drivers operate in user mode and some in kernel mode. ### Windows Kernel The Windows kernel is contained in an executable file called `ntoskrnl.exe` which is split into 2 parts: 1. **Kernel**: responsible for fundamental functionality like: - task synchronization and scheduling - it also provides low-level hardware support, which is essential for the system to run efficiently. 2. **Executive Layer**: contains critical system services such as the **Memory Manager**, which implements virtual memory functionalities and the **Process Manager**, which handles the creation and termination of processes and threads. ### Hardware abstraction layer This provides an interface that **device drivers** can use to communicate with the underlying system hardware. It enables the kernel and higher-level applications to operate independently of the system hardware. ## Objects and Handles ### Windows Objects Windows objects are internal data structures used by the operating system to represent system resources, typically stored in kernel memory. They are instances of a certain type of resource, such as a file, another process or thread, a security token (for user access rights), or even a section of memory. The Windows kernel has a core component called the **Object Manager** which is responsible for: * tracking all Windows objects * sharing them among processes * protecting them from unauthorized access. Since most applications on Windows run in user space, a process uses a unique identifier known as a **handle** to access an object. Each process may have multiple handles for various objects. Handles are managed in a process’s **handle table**, which contains pointers to the objects in kernel memory, as illustrated in the figure below: ![](https://cdn.hashnode.com/uploads/covers/69ad46a686766ac3a61e712e/9556f54b-2524-4d1a-b8db-21f17e95c6be.png align="center") ### Main Categories of Windows Objects The Windows operating system divides system objects into three core categories: * **USER Objects:** Manage user-interface elements and window components like menus, hooks, and windows themselves. * **GDI (Graphics Device Interface) Objects:** Support graphical displays and rendering elements like fonts and regions. * **Kernel Objects:** Manage core system operations, memory management, process execution, and interprocess communication (IPC) via the [Windows Object Manager](https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/managing-kernel-objects). Examples include processes, threads, file objects, and mutexes. ### Mutex (Mutual Exclusion) Mutual exclusions, or mutexes, are a method of controlling access to objects to prevent potential issues like Process A and Process B both attempting to access and modify a file at exactly the same time, which is known as a **race condition.** Depending on how Windows uses this specific file, this situation could potentially cause data inconsistencies, or worse, crash a process or the OS. To avoid unwanted events such as a race condition, Process A may create a mutex object for that file, locking the file for its own use and preventing Process B from being able to access or write to the file until it is unlocked. The program’s interaction with these objects, and with the OS itself, is managed by the **Windows API**. ## Stacks and Heaps **Stack**: where the thread stores temporary data such as **variables, pointers, and other objects** that will inevitably be destroyed once the thread completes execution and is terminated. A process can have multiple active threads, each of which has its own memory stack. * stack = volatile * largely managed by OS **Heap**: is a variably sized region of memory that a program dynamically allocates at runtime and is managed by the program itself. * from a C perspective, `malloc`, `calloc`, `realloc` are used. * Heaps are often used to store objects and data structures that are too large for the stack. * Heaps are also used to store global variables and data that persist and can be used by multiple functions in the same program. ## Dynamic Link Libraries (DLLs) These are a collection of resources that developers can **import into their program** to make use of existing code from Microsoft or third-party developers. While Windows programs can import these libraries, DLL files themselves export functions to the program that imported them e.g *if a developer wishes to access a hard disk on the Windows system, they can import the* `kernel32.dll` *library, which exports (provides) the* `GetLogicalDrives` *function they need.* ### Some DLLs used often in Windows programs * `kernel32.dll`: ​This is one of the primary DLLs required for Windows programs to run, and it **contains many of the fundamental user-mode functions.** `kernel32.dll` exposes the standard, developer-friendly Win32 APIs (like `CreateFile` or `VirtualAlloc`). * `user32.dll`: ​This DLL provides the graphical user interface (GUI) functions required for Windows programs. * `Winhttp.dll`: ​ Also known as the “Windows HTTP Interface,” this DLL provides internet connection functionalities to Windows programs. * `ntdll.dll`: ​​This critical DLL **contains functions for synchronization, threading, and other system tasks; it also communicates with the kernel.** `ntdll.dll` sits underneath `kernel32.dll`. It acts as the final gatekeeper in user space, taking requests from `kernel32.dll` and using `SYSCALL` instructions to switch execution safely into Kernel Mode. **NB**: *If you’re analyzing code with functions exported from kernel32.dll (as many functions are), you might notice that when a process executes a* `kernel32.dll` *function, there’s an immediate jump to another DLL,* `kernelbase.dll`*.* * Introduced in Windows 7, `kernelbase.dll` allows for backward compatibility between older and newer Windows versions. Most kernel32.dll function calls simply jump to `kernelbase.dll`, which contains the function’s actual code. For example, the function `WriteFile` (exported from `kernel32.dll`), once invoked, will immediately jump to `kernelbase.dll`, where its code actually resides. ### How DLL Files Work * **Shared code:** Programs use the code inside a DLL only when they need it. * **No direct opening:** You cannot click and run a DLL file like a normal app (`.exe`). * **Easy updates:** Fixing or updating a code block inside a single DLL updates it for every program that uses it. ## Windows API (WinAPI) This is a shared library of code that is exposed to user-mode applications. When a Windows program runs, WinAPI invokes Windows functions that enable the program to operate as designed within the Windows OS. It covers nearly all the functionality that a developer could want to implement in their code: everything from user interface and networking capabilities to input devices (mouse, keyboard, and so on) to memory management e.g if a developer wants to create a new window for their application, they might call the ***CreateWindowEx*** function. If a program needs access to a hard disk, it might call ***GetLogicalDrives*** to retrieve a list of the available hard disks. There exists a lower-level API called the **Windows Native API**/**Native API**. WinAPI is well documented and designed to be used by developers. However, the Native API is largely undocumented but some of the documentation can be found at: [ninternals project](http://xn--undocumented-wy9f.xn--ntinternals-5d3f.net) and [Geoff Chappell’s research](https://xn--www-7m0a.xn--geoffchappell-nk6g.xn--com-7m0a/studies%E2%80%8B/windows%E2%80%8B/win32%E2%80%8B/ntdll%E2%80%8B/api%E2%80%8B/native%E2%80%8B.htm). The highest-level functionality in kernel mode is also the lowest-level functionality in user mode. This functionality is sometimes called the **native API**. Its functions are described as native system services in Microsoft’s documentation for device driver programming and are sometimes referred to just as system calls. Native API is designed to be internal to the OS, but programs can call Native API functions directly if they so choose. In turn, Native API functions call into even lower-level kernel API code residing in `ntoskrnl.exe`***.*** A call into the kernel is known as a ***syscall*** *or* ***sysenter***. Both have the same objective: allowing user applications access to kernel services. ### Interaction between WinAPI and the Native API. ![](https://cdn.hashnode.com/uploads/covers/69ad46a686766ac3a61e712e/79721e26-51a8-4a3c-9768-638b8f88cd5d.png align="center") 1. a program calls the WinAPI function `VirtualAlloc`, which in turn calls WinAPI’s `VirtualAllocEx` function (not shown in this diagram). [VirtualAlloc](https://memoryapi.h/) allocates memory only within the address space of the current (calling) process, while [VirtualAllocEx](https://www.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualallocex) can allocate memory inside the address space of **any specified process**. * Key Differences: * **Target Process:** * `VirtualAlloc`: Always operates on the calling process itself. It does not take a process handle parameter. * `VirtualAllocEx`: Requires a `hProcess` handle as its first argument, allowing you to target an external or remote process. * **Parameters:** * `VirtualAlloc` takes 4 parameters: `lpAddress`, `dwSize`, `flAllocationType`, and `flProtect`. * `VirtualAllocEx` takes 5 parameters, adding `hProcess` at the very beginning. * **Common Use Cases:** * `VirtualAlloc` is used for internal memory management, large local buffers, or custom allocators within your own application. * `VirtualAllocEx` is frequently used in advanced programming patterns like inter-process communication or **process injection** (allocating memory in another running application to inject code or data). 2\. This is followed by a call to the Native API’s `NtAllocateVirtualMemory` function. 3\. Finally, the program invokes the `NtAllocateVirtualMemory` function inside **ntoskrnl.exe.** **NB**: *This complex chain of API calls is very common in Windows and allows for code to be deve­loped without the developer needing to understand all of the internals of Windows and the lower-level APIs.* ### WinAPI Function Suffixes 1. **Ex**: Microsoft’s way of designating a newer, extended (with more features) version of an older function. For example, the `CreateWindowExA` function is the newer, extended version of the `CreateWindowA` function. 2. **A**: indicates that the function uses ANSI format inputs and outputs 3. **W**: Functions use Unicode inputs and outputs. **NB**: usage of ANSI versus Unicode doesn’t matter that often ### Windows Native API function Prefixes 1. **Nt**: e.g `NtCreateProcess` 2. **Zw**: Zw functions are most often used by drivers and other lower-level system software but are largely interchangeable with Nt functions. * Example: `ZwNotifyChangeKey` ## Processes, Threads, and Memory Management Understanding how Windows allocates resources is foundational for both software engineering and digital forensics. The operating system represents user-mode processes in kernel space using opaque data structures known as **Executive Process (EPROCESS) structures.** Each user-mode process in Windows is linked to an EPROCESS structure running in kernel mode. * I found out that **direct kernel object manipulation (DKOM)** is associated with EPROCESS structures but I did not go deep into it. ### **Main Components Inside EPROCESS** * **KPROCESS (PCB):** Embedded at the beginning of the structure, the kernel process block handles low-level CPU scheduling, threads, priorities, and quantum times. * **PEB Pointer:** It points to the **Process Environment Block**, a user-space structure containing vital information about the process such as command-line arguments and loaded DLLs. * **Object Table:** Points to the handle table, which tracks open handles (files, registry keys, synchronization objects) used by the process. * **Token:** Holds security and access token information defining user privileges. EPROCESS structures consist of a doubly linked list; that is, they form a chain in which each structure links to the previous and subsequent structures. Instances connect through a doubly linked list (`ActiveProcessLinks`) to track every running process on the system. * EPROCESS structure members called **forward links (flinks)** are pointers to the next EPROCESS structure in the chain, while **backward links (blinks)** point to the previous one. ![](https://cdn.hashnode.com/uploads/covers/69ad46a686766ac3a61e712e/a06cdd37-32f0-4923-9fb0-5e3a8d8ff980.png align="center") User-space information for a process, such as loaded dynamic link libraries (DLLs), is stored within a single Process Environment Block (PEB). Basically, A PEB memory structure contains information about a running process that the kernel needs to communicate with that process and information for interprocess communication (IPC). The offset of each structure member in a PEB is shown for both x86 and x64 architectures: | Offset (x86) | Offset (x64) | Data | | --- | --- | --- | | 0x002 | 0x002 | Stores the `BeingDebugged` value, which indicates | | whether the process is running under the context of a debugger. | | | | 0x008 | 0x10 | Stores the base address of the process executable in | | memory. | | | | 0x00C | 0x18 | Stores information on the modules and libraries the process has loaded. | | 0x018 | 0x30 | Stores information about the process’s memory heap | | 0x064 | 0xB8 | Stores the `NumberOfProcessors` value, which indicates the number of processors the system has. | While a process has only one PEB, it can contain multiple Thread Environment Blocks (TEBs) which store critical information for each running thread. Threads utilize a volatile memory stack to temporarily store variables and pointers, which the OS destroys once the thread terminates. **Table: TEB Structure Offsets and Data** Windows uses `FS` & `GS` registers as shortcuts to find the current thread's information instantly, without needing to perform a slow system call or query the kernel: * `FS` **(Segment Register):** Used in **32-bit (x86) Windows**. It points directly to the base of the current thread's **TEB** (Thread Environment Block). * `GS` **(Segment Register):** Used in **64-bit (x64) Windows**. It serves the exact same purpose, pointing directly to the base of the current thread's **TEB**. | Offset (x86) | Offset (x64) | Data | | --- | --- | --- | | FS:\[0x00\] | GS:\[0X00\] | Stores the current **structured exception handler** (SEH) frame. | | FS:\[0x04\] | GS:\[0x08\] | Points to the base of the thread’s stack | | FS:\[0x18\] | GS:\[0x30\] | Points to the TEB itself. (contains a variable whose value is the memory address of the TEB itself.) | | FS:\[0x20\] | GS:\[0x40\] | Stores the process ID (PID) of the thread’s owning | | process. | | | | FS:\[0x24\] | GS:\[0x48\] | Stores the thread ID (TID) of the current thread | | FS:\[0x30\] | GS:\[0x60\] | Points to the PEB of the thread’s owning process | | FS:\[0xE10\] | GS:\[0x1480\] | Points to thread-local storage (TLS) information | * **Thread-local storage (TLS)** is used to store variables and other information across different threads. It can be abused to stealthily execute malicious code. ## Virtual Memory Each process running in Windows has a **number of virtual memory regions** assigned to it that are **mapped to physical memory (or RAM).** * Physical memory shared by all processes running on your system poses a problem in that any process can interfere with any other process on the system (either inadvertently, such as in the case of a crash, or purposefully), with unwanted side effects. Virtual memory is a sort of barrier between physical memory and process memory address space. * When a process is started, it’s assigned an allotment of virtual memory that is mapped to physical memory via the **page table.** A page table keeps track of where different segments of virtual memory are physically located in RAM. ![](https://cdn.hashnode.com/uploads/covers/69ad46a686766ac3a61e712e/62474912-b497-441a-919b-522363e45223.png align="center") * Each block containing an ellipsis (. . .) represents a memory address range, or region. * Each region of memory is mapped to the page table. When the system has less RAM than what is required by all its running processes, virtual memory can be ***paged out***, meaning it will be temporarily stored on the hard disk when unused. * If a process requires access to that virtual memory region again, the memory can be read from disk and remapped to physical memory. A tool like [System Informer](https://systeminformer.io/) (fka Process Hacker) can be used to view the virtual memory of a process. Here is an example with CalculatorApp.exe 1. I opened the calculator app then opened System Informer 2. I switched to the memory tab after locating the `CalculatorApp.exe` process ![](https://cdn.hashnode.com/uploads/covers/69ad46a686766ac3a61e712e/763d3024-42a6-4c30-94bc-8f97829cd524.png align="center") ![](https://cdn.hashnode.com/uploads/covers/69ad46a686766ac3a61e712e/4c78599f-42c6-4a5a-bd07-25fe10281e12.png align="center") 3. **Base address** column contains the base memory address of each virtual memory region assigned to Calculator.exe. 4. **Type column** contains the memory type for each region. Each virtual memory region is typically assigned one of three common memory types: * **Image (IMG) memory** usually contains executable files or libraries that have been mapped into memory via the standard Windows loader mechanism. * **Mapped (MAP) memory** often contains either files that have been mapped into memory from the disk or other data used by the application running inside the process. * **Private (PRV) memory** is typically allocated via `VirtualAlloc` and similar memory allocation functions. 5. **Size column** gives the allocation size of each region 6. **Protection column** lists the protection status of the region. each memory region can be either committed or reserved. * **Committed regions** are being actively used and have been mapped to physical memory. * **Reserved regions** are reserved for the process but aren’t in active use and haven’t yet been mapped to RAM. ## Portable Executable (PE) File Format Windows executables utilize the Portable Executable (PE) file format, which contains headers and sections necessary for the Windows PE loader to run the code. * x64 has its own version of the PE format called **PE32+**. It differs slightly from its x86 equivalent. ### Structures of the PE format 1. **Headers and Sections** PE file format contains several headers which are metadata or other information at the top of a file, telling the OS and other software what to do with its contents. * **DOS header** contains information required by MS-DOS and very early versions of Windows, and it mostly exists for legacy reasons. * **PE header** contains information used by the Windows PE loader, such as the CPU architecture the executable was compiled to run on and metadata like the file’s compilation timestamp. * The PE header also includes **the optional header**, which indicates important information such as: * the PE’s **base memory address** (the memory address at which the PE will be mapped into memory) * the size of the code inside the executable * the target OS that the executable will run on. NB: The “optional” header is in fact no longer optional in modern Windows systems. * **Section Header**: contains metadata related to each of the file’s sections (where the actual file contents are stored), such as the section’s size, address, and other characteristics. * most PE files contain at least a few of the following sections: * `.text`: The file’s main executable code * `.rdata`: Read-only data, such as static variables and constants * `.bss`: Uninitialized data, such as variables that haven’t been assigned a value yet * `.data`: Variables not embedded in the .rdata and .bss sections, such as global variables * `.rsrc`: Assets that will be loaded by the executable at runtime, such as images, fonts, and other supporting files * `.idata`: The imports address table (see the next section) * `.edata`: The exports address table (see the next section) **NB**: In practice, however, both the `.edata` and `.idata` sections are often contained in the `.rdata` section. **2\. Imports and Exports** `.idata` and `.edata` sections are two of the most important components of a PE file. `.idata` section contains information about the functions that the PE file will import at runtime. Once the PE file is executed, the program will load the libraries and functions referenced here into memory and build its `import address table (IAT)`, which maps the **imported Windows API functions** to their addresses in memory. `.edata` section contains information about the functions that the PE file exports to other programs, which they can then import and load into memory for their own use. It’s common for DLL executable files, for example, to contain a list of exported functions. As with imports, exports have their own table called the `export address table`. In short, the `.idata` **/** `.rdata` **Section** is the specific folder or "table of contents" inside your executable file (the PE file) where the list of required DLLs and functions is stored. Let's now see how all these items come full circle: ### Windows PE Loading Process When a program is launched, for example, your favourite browser: 1. An executable(programs `.exe` file) is launched 2. Windows creates a new EPROCESS data structure for the program launched and assigns a new Process ID 3. Windows initializes the virtual memory required for the process, creates the PEB structure, and loads 2 libraries that nearly all Windows processes require: `ntdll.dll` and `kernel32.dll`. * When Windows **"loads"** `ntdll.dll` and `kernel32.dll` into a newly created process, it means the OS Memory Manager maps the shared physical memory pages containing `ntdll.dll` and `kernel32.dll` directly into the process's **virtual address space** from your hard drive into the registering them so the application can use their functions. * The binary code, export tables, and resources of these DLLs are made readable and executable within the boundaries of that specific process. * The address where they are placed is tracked by the process as their **Base Address**. * Windows needs a way to keep track of what libraries a program has access to. The operating system updates the process's **PEB (Process Environment Block)**—specifically a sub-structure called `PEB_LDR_DATA`. * The Windows loader adds entries for `ntdll.dll` and `kernel32.dll` into three internal linked lists that track modules in their **load order, memory order, and initialization order**. * This registration tells the program exactly *where* in memory these libraries live so it can find their functions later. 4. Windows then prepares to load Firefox’s PE file by initializing the PE loader. 5. The PE loader parses the DOS, PE, and optional headers of the PE file to gather all information required to successfully execute the file. 6. The PE loader parses the section header to prepare for mapping these sections into memory. The PE loader maps each section into virtual memory within the new process. 7. The PE loader loads all libraries referenced in the imports (usually .idata or .rdata) section and resolves all addresses for the functions required. The loader finds those files on the disk and maps them into the process's memory space (just like it did for `ntdll.dll`). * All addresses are then stored in the IAT inside the process. The loader looks up the memory addresses of the specific functions the program asked for (like `MessageBoxA` inside `USER32.dll`) and writes those exact memory addresses into the **IAT**. * Those imports are the DLLs (Dynamic Link Libraries), along with the specific functions the program needs to use from them. 8. A new thread is created inside the current process, and the loader executes the first bytes of code in the executable (usually in the .text section). ###### **Diagram of a PE file being loaded and mapped into virtual memory:** ![](https://cdn.hashnode.com/uploads/covers/69ad46a686766ac3a61e712e/0862680a-f4cd-4732-aba8-f5c36d5775d8.png align="center") * Each section in the PE file is individually mapped into memory, but it appears expanded in virtual memory as there are often regions of memory between each section. ## Windows Registry This is a hierarchical database used by Windows and many installed applications to store configuration information. It stores low-level settings for the Windows operating system and applications that choose to use it. It is divided into **computer-specific** and **user-specific data** and contains settings related to: 1. user profiles 2. software 3. hardware 4. services 5. security policies 6. the operating system itself. * A Windows host may use the Registry to determine **which applications run when a user logs in, how a service starts, or whether a security feature is enabled**. System administrators often use the Registry while configuring systems, deploying software, and troubleshooting problems. ### Registry structure | Component | Description | | --- | --- | | `Hives` | top-level section of the Registry that contains various types of settings, such as **system-wide configuration or settings for the current user.** | | `Keys` | \- A container within a hive, similar to a folder. A key can contain additional keys and values. | | `Subkeys` | A key located beneath another key. Subkeys are used to organize related settings into a hierarchy. | | `values` | An individual setting stored within a key. Each value has a name, a data type, and its associated data. | e.g given the following registry path: `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion` * `HKEY_LOCAL_MACHINE` is the hive. * `SOFTWARE` is a key within the hive. * `Microsoft`, `Windows`, and `CurrentVersion` are subkeys beneath it. * Selecting `CurrentVersion` in Registry Editor displays the values stored within that key. Registry hives are stored on the hard disk as files. When Windows boots up, these files are loaded into memory, and the registry is built. Any changes to the registry after the system boots up are stored in memory and not directly on disk. This is why some malware is able to store malicious code and configurations in the registry without necessarily touching the disk. Each registry value includes three primary components: | Component | Description | | --- | --- | | **Name** | Identifies the setting. | | **Type** | Determines the kind of data the value can store. | | **Data** | Holds the configuration information. | * Registry values can store several types of data. Below are some common examples: | **Value** | **Type** | | --- | --- | | REG\_BINARY | Binary data in any form. | | REG\_DWORD | A 32-bit number. | | REG\_DWORD\_LITTLE\_ENDIAN | A 32-bit number in little-endian format. Windows is designed to run on little-endian computer architectures. Therefore, this value is defined as REG\_DWORD in the Windows header files. | | REG\_DWORD\_BIG\_ENDIAN | A 32-bit number in big-endian format. Some UNIX systems support big-endian architectures. | | REG\_EXPAND\_SZ | A null-terminated string that contains unexpanded references to environment variables (for example, "%PATH%"). It will be a Unicode or ANSI string depending on whether you use the Unicode or ANSI functions. To expand the environment variable references, use the [**ExpandEnvironmentStrings**](https://docs.microsoft.com/en-us/windows/win32/api/processenv/nf-processenv-expandenvironmentstringsa) function. | | REG\_LINK | A null-terminated Unicode string containing the target path of a symbolic link created by calling the [**RegCreateKeyEx**](https://docs.microsoft.com/en-us/windows/desktop/api/Winreg/nf-winreg-regcreatekeyexa) function with REG\_OPTION\_CREATE\_LINK. | | REG\_MULTI\_SZ | A sequence of null-terminated strings, terminated by an empty string (\\0). The following is an example: *String1*\\0\_String2\_\\0\_String3\_\\0\_LastString\_\\0\\0 The first \\0 terminates the first string, the second to the last \\0 terminates the last string, and the final \\0 terminates the sequence. Note that the final terminator must be factored into the length of the string. | | REG\_NONE | No defined value type. | | REG\_QWORD | A 64-bit number. | | REG\_QWORD\_LITTLE\_ENDIAN | A 64-bit number in little-endian format. Windows is designed to run on little-endian computer architectures. Therefore, this value is defined as REG\_QWORD in the Windows header files. | | REG\_SZ | A null-terminated string. This will be either a Unicode or an ANSI string, depending on whether you use the Unicode or ANSI functions. | Each folder under `Computer` is a key. The root keys all start with `HKEY`. some of the primary Registry hives found in every Windows operating system are: | Hive | Abbreviation | Purpose | | --- | --- | --- | | `HKEY_CURRENT_USER` | `HKCU` | Stores settings for the currently logged-on user. | | `HKEY_LOCAL_MACHINE` | `HKLM` | Stores system-wide hardware, software, and operating system settings. Contains six subkeys like `SAM`, `SECURITY`, `SYSTEM`, `SOFTWARE`, `HARDWARE`, and `BCD`, loaded into memory at boot time (except `HARDWARE` which is dynamically loaded). | | `HKEY_CLASSES_ROOT` | `HKCR` | Stores file associations and application registration information. | | `HKEY_USERS` | `HKU` | Contains user profiles currently loaded on the system. | | `HKEY_CURRENT_CONFIG` | `HKCC` | Contains information about the current hardware configuration. | The most commonly used are HKCU & HKLM * The entire system registry is stored in several files on the operating system. You can find these under `C:\Windows\System32\Config\`. * The user-specific registry hive (HKCU) is stored in the user folder (i.e., `C:\Users\\Ntuser.dat`) ```plaintext PS C:\htb> gci -Hidden Directory: C:\Users\bob Mode LastWriteTime Length Name ---- ------------- ------ ---- d--h-- 6/25/2020 5:12 PM AppData d--hsl 6/25/2020 5:12 PM Application Data d--hsl 6/25/2020 5:12 PM Cookies d--hsl 6/25/2020 5:12 PM Local Settings d--h-- 6/25/2020 5:12 PM MicrosoftEdgeBackups d--hsl 6/25/2020 5:12 PM My Documents d--hsl 6/25/2020 5:12 PM NetHood d--hsl 6/25/2020 5:12 PM PrintHood d--hsl 6/25/2020 5:12 PM Recent d--hsl 6/25/2020 5:12 PM SendTo d--hsl 6/25/2020 5:12 PM Start Menu d--hsl 6/25/2020 5:12 PM Templates -a-h-- 8/13/2020 6:01 PM 2883584 NTUSER.DAT -a-hs- 6/25/2020 5:12 PM 524288 ntuser.dat.LOG1 -a-hs- 6/25/2020 5:12 PM 1011712 ntuser.dat.LOG2 -a-hs- 8/17/2020 5:46 PM 1048576 NTUSER.DAT{53b39e87-18c4-11ea-a811-000d3aa4692b}.TxR.0.regtrans-ms -a-hs- 8/17/2020 12:13 PM 1048576 NTUSER.DAT{53b39e87-18c4-11ea-a811-000d3aa4692b}.TxR.1.regtrans-ms -a-hs- 8/17/2020 12:13 PM 1048576 NTUSER.DAT{53b39e87-18c4-11ea-a811-000d3aa4692b}.TxR.2.regtrans-ms -a-hs- 8/17/2020 5:46 PM 65536 NTUSER.DAT{53b39e87-18c4-11ea-a811-000d3aa4692b}.TxR.blf -a-hs- 6/25/2020 5:15 PM 65536 NTUSER.DAT{53b39e88-18c4-11ea-a811-000d3aa4692b}.TM.blf -a-hs- 6/25/2020 5:12 PM 524288 NTUSER.DAT{53b39e88-18c4-11ea-a811-000d3aa4692b}.TMContainer000000000 00000000001.regtrans-ms -a-hs- 6/25/2020 5:12 PM 524288 NTUSER.DAT{53b39e88-18c4-11ea-a811-000d3aa4692b}.TMContainer000000000 00000000002.regtrans-ms ---hs- 6/25/2020 5:12 PM 20 ntuser.ini ``` * Changes made under `HKCU` typically affect the current user only, while changes made under `HKLM` usually affect the entire computer and require administrative privileges to edit. ### Run and RunOnce Registry Keys These are also so-called registry hives, which contain a logical group of keys, subkeys, and values to support software and files loaded into memory when the operating system is started or a user logs in & are **useful for maintaining access to the system**. (https://docs.microsoft.com/en-us/windows/win32/setupapi/run-and-runonce-registry-keys). The Windows registry includes the following four keys, 2 each in HKCU and HKLM: ```plaintext HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce ``` ![](https://cdn.hashnode.com/uploads/covers/69ad46a686766ac3a61e712e/8d174a28-2079-4ce4-9bf0-cd8f0a5cdf6a.png align="center") ### Regedit Regedit allows you to inspect and modify each registry key and value on the system, which is useful for understanding how the registry works. Regedit can also be useful for investigating how malware may have altered this data. ## Security, Permissions, and Core Services ### Services Services allow for the **creation and management of long-running processes.** Windows services can be started automatically at system boot without user intervention. These services can **continue to run in the background** even after the user logs out of their account on the system. Applications can also be created to install as a service, such as a network monitoring application installed on a server. Functions of services in windows: 1. networking functions 2. performing system diagnostics 3. managing user credentials 4. controlling Windows updates 5. etc Windows services can be managed via: **Service Control Manager (SCM) system**, accessible via the `services.msc` MMC add-in. This add-in provides a GUI interface for interacting with and managing services and displays information about each installed service. This information includes: 1. the service Name 2. Description, Status 3. Startup Type 4. user that the service runs under. * It is also possible to query and manage services via the command line using `sc.exe` **using** [**PowerShell**](https://docs.microsoft.com/en-us/powershell/scripting/overview?view=powershell-7) **cmdlets such as** `Get-Service`**.** ```plaintext PS C:\htb> Get-Service | ? {$_.Status -eq "Running"} | select -First 2 |fl Name : AdobeARMservice DisplayName : Adobe Acrobat Update Service Status : Running DependentServices : {} ServicesDependedOn : {} CanPauseAndContinue : False CanShutdown : False CanStop : True ServiceType : Win32OwnProcess Name : Appinfo DisplayName : Application Information Status : Running DependentServices : {} ServicesDependedOn : {RpcSs, ProfSvc} CanPauseAndContinue : False CanShutdown : False CanStop : True ServiceType : Win32OwnProcess, Win32ShareProcess ``` * Service statuses can appear as *Running, Stopped, or Paused*, and they can be set to start *manually, automatically, or on a delay at system boot*. * Services can also be shown in the state of Starting or Stopping if some action has triggered them to either start or stop. There are 3 categories of services: 1. Local Services 2. Network Services 3. System Services Services can usually only be **created, modified, and deleted by users with administrative privileges.** However, **misconfigurations around service permissions** are a common privilege escalation vector on Windows systems. There are [critical system services](https://docs.microsoft.com/en-us/windows/win32/rstmgr/critical-system-services) which services cannot be stopped and restarted without a system restart e.g | Service | Description | | --- | --- | | smss.exe | Session Manager SubSystem. Responsible for handling sessions on the system. | | csrss.exe | Client Server Runtime Process. The user-mode portion of the Windows subsystem. | | wininit.exe | Starts the Wininit file .ini file that lists all of the changes to be made to Windows when the computer is restarted after installing a program. | | logonui.exe | Used for facilitating user login into a PC | | lsass.exe | The Local Security Authentication Server verifies the validity of user logons to a PC or server. It generates the process responsible for authenticating users for the Winlogon service. | | services.exe | Manages the operation of starting and stopping services. | | winlogon.exe | Responsible for handling the secure attention sequence, loading a user profile on logon, and locking the computer when a screensaver is running. | | System | A background system process that runs the Windows kernel. | | svchost.exe with RPCSS | Manages system services that run from dynamic-link libraries (files with the extension .dll) such as "Automatic Updates," "Windows Firewall," and "Plug and Play." Uses the Remote Procedure Call (RPC) Service (RPCSS). | | svchost.exe with Dcom/PnP | Manages system services that run from dynamic-link libraries (files with the extension .dll) such as "Automatic Updates," "Windows Firewall," and "Plug and Play." Uses the Distributed Component Object Model (DCOM) and Plug and Play (PnP) services | ### Local Security Authority Subsystem Service (LSASS) `lsass.exe` is the process that is **responsible for enforcing the security policy on Windows systems**. When a user attempts to log on to the system, this process **verifies their log on attempt** and **creates access tokens based on the user's permission levels.** LSASS is also responsible for user account password changes. All events associated with this process (logon/logoff attempts, etc.) are logged within the **Windows Security Log**. LSASS is an **extremely high-value target** as several tools exist to extract both **cleartext and hashed credentials** stored in memory by this process. One of those tools is ***Mimikatz.*** ### Sysinternals Tools These are a set of **portable Windows applications** that can be **used to administer Windows systems** (for the most part without requiring installation) The tools can be either downloaded from the Microsoft website or loaded directly from an internet-accessible file share by typing `\\live.sysinternals.com\tools` into a Windows Explorer window. For example, we can run **procdump.exe** directly from this share without downloading it directly to disk. ```plaintext C:\htb> \\live.sysinternals.com\tools\procdump.exe -accepteula ProcDump v9.0 - Sysinternals process dump utility Copyright (C) 2009-2017 Mark Russinovich and Andrew Richards Sysinternals - www.sysinternals.com Monitors a process and writes a dump file when the process exceeds the specified criteria or has an exception. Capture Usage: procdump.exe [-mm] [-ma] [-mp] [-mc Mask] [-md Callback_DLL] [-mk] [-n Count] [-s Seconds] [-c|-cl CPU_Usage [-u]] [-m|-ml Commit_Usage] [-p|-pl Counter_Threshold] [-h] [-e [1 [-g] [-b]]] [-l] [-t] [-f Include_Filter, ...] [-fx Exclude_Filter, ...] [-o] [-r [1..5] [-a]] [-wer] [-64] { {{[-w] Process_Name | Service_Name | PID} [Dump_File | Dump_Folder]} | {-x Dump_Folder Image_File [Argument, ...]} } ``` The suite includes tools such as: 1. `Process Explorer`, an enhanced version of `Task Manager`. It can show which **handles and DLL processes are loaded when a program runs.** It also shows a list of currently running processes, and from there, we can see **what handles the process has selected in one view or the DLLs and memory-swapped files that have been loaded in another view**. We can also search within the tool **to show which processes tie back to a specific handle or DLL.** The tool can also be used **to analyze parent-child process relationships** to see what child processes are spawned by an application and help troubleshoot any issues such as orphaned processed that can be left behind when a process is terminated. 2. `Process Monitor`, which can be used to monitor file system, registry, and network activity related to any process running on the system. 3. `TCPView`, which is used to monitor internet activity 4. `PSExec`, which can be used to manage/connect to systems via the SMB protocol remotely. * *These tools can be useful for penetration testers to, for example, discover interesting processes and possible privilege escalation paths as well as for lateral movement.* ### Permissions Windows enforces strict access controls to dictate how users and programs interact with the system. Every security principal on the system is assigned a unique Security Identifier (SID) which dictates authorized actions. The NTFS file system manages access to files and folders through Access Control Lists (ACLs) built from individual Access Control Entries (ACEs). Every named object in Windows is a [securable object](https://docs.microsoft.com/en-us/windows/win32/secauthz/securable-objects), and even some unnamed objects are securable. If it's securable in a Windows OS, it will have a [security descriptor](https://docs.microsoft.com/en-us/windows/win32/secauthz/security-descriptors). Security descriptors identify the: * **object’s owner** * **a primary group containing a** `Discretionary Access Control List` **(**`DACL`**) and a** `System Access Control List` **(**`SACL`**).** DACL is used for controlling access to an object, and a SACL is used to account for and log access attempts. The amalgamation of characters crunched together and delimited by opened and closed parentheses is in a format known as the `Security Descriptor Definition Language` (`SDDL`). * we are essentially viewing access control entries in an access control list. ```plaintext D:(A;;CCLCSWRPLORC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY) ``` `D: (A;;CCLCSWRPLORC;;;AU)`: 1. D: - the proceeding characters are DACL permissions 2. AU: - defines the security principal Authenticated Users 3. A;; - access is allowed 4. CC - SERVICE\_QUERY\_CONFIG is the full name, and it is a query to the service control manager (SCM) for the service configuration 5. LC - SERVICE\_QUERY\_STATUS is the full name, and it is a query to the service control manager (SCM) for the current status of the service 6. SW - SERVICE\_ENUMERATE\_DEPENDENTS is the full name, and it will enumerate a list of dependent services 7. RP - SERVICE\_START is the full name, and it will start the service 8. LO - SERVICE\_INTERROGATE is the full name, and it will query the service for its current status 9. RC - READ\_CONTROL is the full name, and it will query the security descriptor of the service * Each set of 2 characters in between the semi-colons represents actions allowed to be performed by a specific user or group: `;;CCLCSWRPLORC;;;` * After the last set of semi-colons, the characters specify the security principal (User and/or Group) that is permitted to perform those actions: `;;;AU` * The character immediately after the opening parentheses and before the first set of semi-colons defines whether the actions are Allowed or Denied: `A;;` * This entire security descriptor associated with the `Windows Update` (`wuauserv`) service has three sets of access control entries because there are three different security principals. Each security principal has specific permissions applied. * The Windows Management Instrumentation (WMI) subsystem allows administrators to monitor systems and execute code across networks using classes and methods. The command `Get-WmiObject cmdlet` is used to find information about the operating system. This cmdlet can be used to get instances of WMI classes or information about available WMI classes. ```plaintext Get-WmiObject -Class win32_OperatingSystem | select Version,BuildNumber ``` * obtain information such as version and build number of our system using the `win32_OperatingSystem` class Some other useful classes that can be used with `Get-WmiObject` are: 1. `Win32_Process` to get a process listing 2. `Win32_Service` to get a listing of services 3. `Win32_Bios` to get [Basic Input/Output System](https://en.wikipedia.org/wiki/BIOS) (`BIOS`) information. 4. `Win32_UserAccount` to get user account info e.g SID: `Get-WmiObject -Class Win32_UserAccount -Filter "Name='bob.smith'" | Select-Object Name, SID` `Get-WmiObject` can be used to start and stop services on local and remote computers, and more. ### Windows Security The security model is designed to minimize the risk of unauthorized access, making it more challenging for attackers or malicious software to exploit the system. **Security Identifier (SID)** SIDs are string values with different lengths, which are stored in the security database. These SIDs are added to the **user's access token** to identify all actions that the user is authorized to take. Each of the security principals on the system has a unique security identifier (SID). The system automatically generates SIDs. This means that even if, for example, we have two identical users on the system, Windows can distinguish the two and their rights based on their SIDs. These SIDs are added to the user's access token to identify all actions that the user is authorized to take. #### SID Components 1. Identifier Authority 2. Relative ID (RID). 3. Domain SID (*optional: found in Active Directory*) ![](https://cdn.hashnode.com/uploads/covers/69ad46a686766ac3a61e712e/d55a1595-66a4-45bf-ac1d-8135930fbcf4.png align="center") The SID is broken down into this pattern: ```plaintext (SID)-(revision level)-(identifier-authority)-(subauthority1)-(subauthority2)-(etc) ``` | **Number** | **Meaning** | **Description** | | --- | --- | --- | | S | SID | Identifies the string as a SID. | | 1 | Revision Level | To date, this has never changed and has always been `1`. | | 5 | Identifier-authority | A 48-bit string that identifies the authority (the computer or network) that created the SID. | | 21 | Subauthority1 | This is a variable number that identifies the user's relation or group described by the SID to the authority that created it. It tells us in what order this authority created the user's account. | | 3045493438-943182246-405288309 | Subauthority2 | Tells us which computer (or domain) created the number | | 1001 | Subauthority3 | The RID that distinguishes one account from another. Tells us whether this user is a normal user, a guest, an administrator, or part of some other group | **Security Accounts Manager (SAM) and Access Control Entries (ACE)** * SAM grants rights to a network to execute specific processes. * The access rights themselves are managed by **Access Control Entries (ACE)** in **Access Control Lists (ACL).** * The ACLs contain ACEs that define which **users, groups, or processes** have access to a file or to execute a process, for example. * The permissions to access a securable object are given by the security descriptor, classified into two types of ACLs: the `Discretionary Access Control List (DACL)` or `System Access Control List (SACL)`. * Every thread and process started or initiated by a user goes through an authorization process. * An integral part of this process is **access tokens,** validated by the Local Security Authority (LSA). * In addition to the SID, these access tokens contain other security-relevant information. Understanding these functionalities is an essential part of learning how to use and work around these security mechanisms during the privilege escalation phase. **User Account Control (UAC)** [User Account Control (UAC)](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works) is a security feature in Windows to prevent malware from running or manipulating processes that could damage the computer or its contents * There is the **Admin Approval Mode** in UAC, which is designed to prevent unwanted software from being installed without the administrator's knowledge or to prevent system-wide changes from being made. * shows a consent prompt which interrupts the execution of scripts or binaries that malware or attackers try to execute until the user enters the password or confirms execution. ![](https://cdn.hashnode.com/uploads/covers/69ad46a686766ac3a61e712e/30c352df-05c9-4daf-aa3f-04eaec74a090.png align="center") **Application Whitelisting** An application whitelist is a **list** of approved software applications or executables **allowed to be present and run on a system.** The goal is to protect the environment from harmful malware and unapproved software that does not align with the specific business needs of an organization. Whitelisting is based on a "**zero trust**" principle in which all software/applications are deemed "bad" except for those specifically allowed. Implementing an enforced whitelist can be a challenge, especially in a large network. An organization should implement a whitelist in audit mode initially to make sure that all necessary applications are whitelisted and **not blocked by an error of omission**, which can cause more problems than it fixes. Blacklisting, in contrast, specifies a list of harmful or disallowed software/applications to block, and all others are allowed to run/be installed. Maintaining a whitelist generally has less overhead as a system administrator will only need to specify what is allowed and not constantly update a "blacklist" with new malicious applications. Whitelisting is recommended by organizations such as [**NIST**](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-167.pdf), especially in high-security environments. **AppLocker** [AppLocker](https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview) is Microsoft's application whitelisting solution and was first introduced in Windows 7. AppLocker gives system administrators control over which applications and files users can run. It gives granular control over executables, scripts, Windows installer files, DLLs, packaged apps, and packed app installers. It allows for creating rules based on: * **file attributes** such as: * the publisher's name (which can be derived from the digital signature) * product name * file name * version. * **file paths and hashes**. Rules can be applied to either security groups or individual users, based on the business need. AppLocker can be deployed in audit mode first to test the impact before enforcing all of the rules. **Local Group Policy** Group Policy allows administrators to **set, configure, and adjust** **a variety of settings.** Group Policy can be configured locally, in both domain environments and non-domain environments. In a domain environment, group policies are pushed down from a Domain Controller onto all domain-joined machines that Group Policy objects (GPOs) are linked to. These settings can also be defined on individual machines using **Local Group Policy** which can be used to: * tweak certain graphical and network settings that are otherwise not accessible via the Control Panel. * lock down an individual computer policy with stringent security settings, such as only allowing certain programs to be installed/run or enforcing strict user account password requirements. To Open: type `gpedit.msc` * The editor is split into two categories under Local Computer Policy - Computer Configuration and User Configuration. * For example, we can open the Local Computer Policy to enable Credential Guard by enabling the setting `Turn On Virtualization Based Security`. Credential Guard is a feature in Windows 10 that protects against credential theft attacks by isolating the operating system's LSA process. * We can also enable fine-tuned account auditing and configure AppLocker from the Local Group Policy Editor. \*\*NB:\*\**It is worth exploring Local Group Policy and learning about the wide variety of ways it can be used to lock down a Windows system.* **Windows Defender Antivirus** Windows Defender Antivirus (Defender), formerly known as Windows Defender, is built-in antivirus that ships for free with Windows operating systems. It comes with several features such as: 1. **real-time protection**: which protects the device from known threats in real-time and cloud-delivered protection, which works in conjunction with automatic sample submission to upload suspicious files for analysis. When files are submitted to the cloud protection service, they are "locked" to prevent any potentially malicious behavior until the analysis is complete. * Real-time protection settings can be tweaked to add files, folders, and memory areas to controlled folder access to prevent unauthorized changes. (*Controlled folder access is Defender's built-in Ransomware protection.*) * We can also add files or folders to an **exclusion list**, so they are not scanned. e.g excluding a folder of tools used for penetration testing from scanning as they will be flagged malicious and quarantined or removed from the system. 2. **Tamper Protection**, which prevents security settings from being changed through the Registry, PowerShell cmdlets, or group policy. * managed from the **Security Cente**r, from which a variety of additional security features and settings can be enabled and managed. * use the PowerShell cmdlet `Get-MpComputerStatus` to check which protection settings are enabled. ```plaintext PS C:\htb> Get-MpComputerStatus | findstr "True" AMServiceEnabled : True AntispywareEnabled : True AntivirusEnabled : True BehaviorMonitorEnabled : True IoavProtectionEnabled : True IsTamperProtected : True NISEnabled : True OnAccessProtectionEnabled : True RealTimeProtectionEnabled : True ``` #### Advantages * Windows Defender does very well in **monthly detection rate tests compared to other solutions, even paid ones**. * Since it comes preinstalled as part of the operating system, it does not introduce "bloat" to the system, such as other programs that add browser extensions and trackers. * Other products are known to slow down the system due to the way they hook into the operating system. Windows Defender will pick up payloads from common open-source frameworks such as Metasploit or unaltered versions of tools such as Mimikatz. ## Conclusion Understanding Windows internals is an absolute necessity for anyone stepping into security engineering, malware analysis, or low-level development. From the strict separation of user and kernel modes that protects core operating system functions, to the intricate ways the PE loader maps executables and DLLs into virtual memory, every component plays a critical role in the system's broader security posture. Threat actors constantly look for ways to abuse legitimate mechanisms, whether it is by targeting the Local Security Authority Subsystem Service (LSASS) for credential theft, hijacking service permissions for privilege escalation, or storing malicious configurations directly within the Windows Registry without touching the disk. By familiarizing ourselves with the Windows API, memory management structures like the PEB and TEB, and built-in defenses such as User Account Control (UAC) and AppLocker, we shift from merely observing malicious behavior to truly understanding how and why it executes. Armed with this foundational knowledge, one is far better equipped to analyze, defend against, and mitigate modern cyber threats during your next dynamic analysis session.