Windows Architecture and the Registry

Most office computers in the world run Windows, and most company networks are managed with Windows-based infrastructure. A security professional who only knows Linux is blind to a large part of real environments. In this lesson you get to know how Windows is organised under the surface, and you meet the registry, a configuration database that administrators, malware and investigators all care about.

Chapter 4 made you comfortable with Linux. Many ideas will carry over: users, permissions, services, processes and logs exist on Windows too, with different names and tools. We start by mapping the Windows landscape, and we will go on to the directory services that tie company networks together.

Setting up a Windows machine in your lab

For the exercises of this chapter, add a Windows virtual machine to your lab. Use an official evaluation edition provided by the vendor for testing, or a licence that you own, and respect its terms. Do not download "cracked" or modified images from unofficial sources: besides being illegal, they are a classic way to get a lab infected from the start. Attach the VM to your isolated labnet network, give it a static address such as 10.10.10.30/24, and take a snapshot after installation. Connect to the Internet only temporarily for updates.

If your computer cannot run a Windows VM, you can still follow the lessons by reading and by working on your own Windows machine for read-only commands, being careful not to change anything you do not understand.

The big picture: user mode and kernel mode

Windows, like Linux, separates the system into two worlds. The kernel mode contains the core of the operating system and the drivers: it has direct access to the hardware and to all the memory. The user mode contains your applications and most services: they have limited access and must ask the kernel for anything sensitive, through system calls. This separation protects the system from faulty or malicious programs. A bug or a malicious driver in kernel mode is much more serious than the same problem in an ordinary application, which is why modern Windows insists on signed drivers.

Processes, services and users

As on Linux, a program that runs is a process, started under the identity of a user. You can see processes in the Task Manager, or from a command prompt with tasklist. Several system processes are always present and worth recognising, because malware likes to imitate their names:

• System: the kernel's own activity.
• smss.exe and csrss.exe: session and subsystem management.
• wininit.exe and services.exe: start up and run services.
• lsass.exe: the Local Security Authority Subsystem, which handles logins and holds authentication material in memory. Its sensitivity makes it a frequent target for attackers, and a key element of defence.
• svchost.exe: a host process that runs many system services, so you will see many instances.
• explorer.exe: your desktop and file explorer.

An executable with a legitimate-looking name but running from an unusual folder (for example a user's temporary folder) is a typical sign of trouble. Knowing where the genuine ones live (the system folder) helps with detection.

Services are managed by the Service Control Manager. You can see them with services.msc or from the command line with sc query. Like Linux daemons, they can start at boot, run under a specific account (often a restricted built-in account such as Local Service or Network Service) and listen on network ports.

The file system and permissions

Windows uses drive letters (C:\) and the NTFS file system. Important locations to know:

Location	Content
C:\Windows	The operating system
C:\Windows\System32	Core system programs and libraries; also configuration and logs in subfolders
C:\Program Files	Installed applications
C:\Users	User profiles (documents, desktop, application data)
C:\ProgramData	Application data shared across users

Permissions on NTFS work with access control lists (ACL): each file or folder has a list of entries saying "this user or group may read / modify / have full control". It is more granular than the three-triplet Unix model, but the philosophy is identical: least privilege. You can view them with the Security tab of a file's properties or with the icacls command.

Windows also has User Account Control (UAC): even an administrator runs most things with reduced rights, and a prompt asks for confirmation before an action that needs elevation. It is the Windows cousin of the sudo philosophy. Accounts are identified internally by a SID (security identifier), a unique number that stays the same even if the account name changes.

The registry

The registry is a hierarchical database in which Windows and many applications store their settings: hardware configuration, user preferences, services, installed software, start-up programs. Think of it as a giant tree of folders (called keys) containing named values, each with a type (text, number, binary data).

You can browse it with the Registry Editor (regedit). The top of the tree has several root keys (hives). The ones you must know:

• HKEY_LOCAL_MACHINE (HKLM): settings that apply to the whole computer: hardware, installed software, system services.
• HKEY_CURRENT_USER (HKCU): settings of the user who is logged in.
• HKEY_USERS (HKU): the settings of all loaded user profiles. HKCU is a shortcut to the current user's part.
• HKEY_CLASSES_ROOT (HKCR): file associations and related information.
• HKEY_CURRENT_CONFIG (HKCC): information about the current hardware profile.

Behind the scenes, the data is stored in files (hive files) on disk, and loaded at start-up and login.

Why the registry matters for security

Because the registry controls how the system behaves and what starts automatically, it is at the centre of three activities:

• Hardening and configuration: many security settings, including those pushed by group policies (next lesson), end up as registry values.
• Persistence by attackers: malware that wants to survive a reboot often adds an entry in a start-up location, such as the "Run" keys. These live under paths such as HKCU\Software\Microsoft\Windows\CurrentVersion\Run and the matching HKLM key. Anything listed there starts automatically when a user logs in.
• Forensics: the registry holds traces of past activity: recently opened files, connected USB devices, installed programs, network history. Investigators read it to rebuild what happened.

Persistence is the attacker's problem of "how do I stay once the computer reboots?", and so it is also the defender's checklist of "where should I look?". In course 4 we revisit persistence from the defensive point of view.

Reading the registry from the command line

You can query the registry with reg query. This command only reads:

reg query HKCU\Software\Microsoft\Windows\CurrentVersion\Run
reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Run

Each line of the output shows a value name, its type (for example REG_SZ for a text value) and its data, often the path of a program. For a clean new VM, the list is short. On a real computer, it shows the programs that start with your session: security tools, cloud storage clients, update helpers. It is a good routine to know what is expected there.

Your turn: inspect your Windows VM

On your Windows lab VM (or read-only on your own Windows computer), do the following and record the results in your notebook. List the running processes with tasklist and identify lsass.exe and at least two svchost.exe instances. List the services that are running with sc query type= service state= running (note the spaces after the equal signs). Query the two "Run" keys shown above. Finally, display the SID of your account with whoami /user.

See a solution

You should find lsass.exe once, and several instances of svchost.exe, each hosting a group of services. The service list shows services such as the Windows Update service or the firewall service, with their state. On a fresh VM, the Run keys are likely empty or contain only a few entries (for example for a security tool or a system helper); an empty answer is displayed as an error such as "unable to find the specified registry key or value" if the key does not exist, which is perfectly normal. whoami /user prints your account name and its SID, which starts with S-1-5-21- for a local or domain account, followed by numbers that identify the machine or domain and, at the end, the relative identifier of the account.