Understanding how the Windows operating system functions and how its core processes' normal behavior is vital and can aid a defender in identifying unusual activity on the Windows endpoint.

Before starting discussing the Windows processes we have to know that Windows has two modes for the running processes:

  • User-mode processes: Windows assign a unique process to any regular application you run. This process provides a program a private virtual address space (This virtual space maps between the reading and writing operations done by a process and the actual physical space). Thus, each program and process has isolated memory space and can't access or modify the virtual space of any other process or of the virtual space of operating system itself. Also, if any process crashes it won't affect other process or the system (safer execution). Finally, a user mode process has limited access to the system resources (CPU, memory, disk) and uses system calls (APIs) to ask the kernel to do things.
  • Kernel-mode processes: Kernel mode doesn't usually run "processes" the same way user mode does. Instead, it runs Kernel threads, drivers, and Core OS components & functions (Process scheduling, Memory management, and I/O operations). All kernel processes share the same virtual address space and have full and unrestricted access to the system's hardware and memory. As a result, a kernel-mode driver isn't isolated from other drivers or the operating system address space. So, if a kernel-mode driver mistakenly writes to the wrong virtual address, it could compromise data that belongs to the operating system or another driver. Also, if a kernel-mode driver crashes, it causes the entire operating system to crash.

How User-mode and Kernel-mode processes work together:

A user app application wants to read a file. It cannot access disk directly. It makes a system call to the kernel. The kernel: Talks to the disk driver, Reads the data, and Returns it safely.

Another thing we need to know about before we start our main topic is the Task manager:

Task Manager is a built-in GUI-based Windows utility that allows users to see what is running on the Windows system. It also provides information on resource usage, such as how much each process utilizes CPU and memory. When a program is not responding, Task Manager is used to end (kill) the process. Task manager can display the following information for each process:

  • Application name.
  • Process type: Apps, Background process, or Windows process.
  • Process Publisher: The name of the author of the program/file.
  • Process Identifier Number (PID): Windows assigns a unique process identifier each time a program starts. If the same program has multiple running processes, each will have its unique process identifier (PID).
  • Process name: The file name of the process.
  • Command line: The full command used to launch the process (Binary).
  • CPU: The amount of CPU (processing power) the process uses.
  • Memory: The amount of physical working memory utilized by the process.

Task Manager is a powerful built-in Windows utility but lacks certain important information when analyzing processes, such as parent process information. That is where other alternatives, such as Process Hacker and Process Explorer, come to the rescue.

Now Let's start our main course:

1- System process:

A PID for any given process is assigned at random, but that is not the case for the System process. The PID for System process is always 4.

The System process:

- Runs entirely in kernel mode. - Hosts system threads. - Executes core OS code (ntoskrnl.exe) and device driver code (.sysfiles). - Managing hardware communication (via drivers). - Handling I/O operations (disk, network, etc.). - Running background kernel tasks. - Supporting OS internals (memory, scheduling, etc.).

The normal behavior for the System process:

- Image Path: N/A or C:\\Windows\\system32\\ntoskrnl.exe (OS Kernel) - Parent Process: None or System Idle Process (0) - Number of Instances: One - User Account: Local System - Start Time: At boot time

The unusual behavior:

- A different parent process than System Idle Process (0). - Multiple instances of System (Should only be one instance). - A different PID than PID 4. - Not running in Session 0

2- Session Manager Subsystem (smss.exe):

Also known as the Windows Session Manager, smss.exe is responsible for creating new sessions. It is the first user-mode process started by the kernel. This process starts the kernel and user modes of the Windows subsystem which include:

win32k.sys: A kernel mode driver that handles the Windows GUI system like mouse/keyboard input, Drawing applications' windows and their management.

csrss.exe: Will be discussed below in detail.

winsrv.dll: A .dll file (Dynamic Link Library) is a file that contains code and functions that other programs can use instead of rewriting them. In other words, a shared library that multiple programs can load and use at runtime. Winsrv.dllis loaded in csrss.exe and implements server-side logic for Console handling and Some system APIs (The brain of the csrss.exe).

Smss.exe starts csrss.exe (Windows subsystem) and wininit.exein Session 0, an isolated Windows session for the operating system, and csrss.exe and winlogon.exe for Session 1, which is the user session. The first child instance (smss.exe in Session 0) creates child instances in new sessions, done by smss.exe copying itself into the new session and self-terminate itself from Session 0. Any other subsystem listed in the Required value in the Windows Registry key HKLM\\System\\CurrentControlSet\\Control\\Session Manager\\Subsystems) is also launched. smss.exe is also responsible for creating environment variables, virtual memory paging files and starts winlogon.exe (Windows Logon Manager).

The normal behavior of smss.exe:

- Image Path: %SystemRoot%\\System32\\smss.exe -Parent Process: System. - Number of Instances: One master instance and child instance per session. The child instance exits after creating the session. - User Account: Local System. - Start Time: Within seconds of boot time for the master instance.

The unusual behavior:

- A different parent process other than System (4). - The image path is different from C:\\Windows\\System32 - More than one running process. (children self-terminate and exit after each new session). - The running User is not the SYSTEM user. - Unexpected registry entries for Subsystem.

3- Client Server Runtime Process (csrss.exe):

A user-mode process that manages parts of the Windows subsystem and handles Console windows (CMD), Process/thread creation and deletion. Pay attention that If you kill this process the Windows crashes (System failure). Although it Runs in user mode, it has very high privileges that's whay it is critical to the system. This process is also responsible for making the Windows API available to other processes, mapping drive letters, and handling the Windows shutdown process.

Note: Recall that csrss.exe and winlogon.exe are called from smss.exe at startup for Session 1.

Normal behavior ofcsrss.exe:

- Image Path:%SystemRoot%\\System32\\csrss.exe - Parent Process: Created by an instance of smss.exe - Number of Instances: Two or more. - User Account: Local System. - Start Time: Within seconds of boot time for the first two instances (for Session 0 and 1). Start times for additional instances occur as new sessions are created, although only Sessions 0 and 1 are often created.

The unusual behavior:

- An actual parent process. (smss.exe calls this process and self-terminates). - Image file path other than C:\\Windows\\System32 - Misspellings to hide rogue processes masquerading as csrss.exe in plain sight like (crss.exe or csrs.exe). - The user is not the SYSTEM user.

4- Windows Initialization Process (wininit.exe):

Runs during the early boot stage of Windows. When the kernel loads. wininit.exe is responsible for starting key system components that Windows needs to function like: Starting the Service Control Manager services.exe, starting the Local Security Authority lsass.exeand LSA Isolated lsaiso.exe. In addition, it initializes background system infrastructure. Without it, Windows cannot properly start.

Note, lsaiso.exe runs only when a feature called Credential Guard and KeyGuard is enabled which is also used to:

  • Protect user credentials (passwords, hashes, Kerberos tickets)
  • Isolate sensitive data from the rest of the system
  • Prevent credential theft attacks (like pass-the-hash)

The normal behavior of winint.exe:

- Image Path: %SystemRoot%\\System32\\wininit.exe - Parent Process: Created by an instance of smss.exe - Number of Instances: One. - User Account: Local System. - Start Time: Within seconds of boot time.

The unusual behavior:

- An actual parent process. (smss.exe calls this process and self-terminates). - Image file path other than C:\Windows\System32. - Misspellings to hide rogue processes. - Multiple running instances. - Not running as SYSTEM

5- Service Control Manager (SCM) or (services.exe):

It acts like a central manager that controls background services (Windows services). It is also responsible for:

  • Starting services when Windows boots.
  • Stopping services during shutdown.
  • Monitoring service status (running, stopped, paused).
  • Handling service dependencies (service A needs service B).
  • Restarting services if they crash (if configured).

It maintains a registry that acts like a database of services and their information. This registry is stored in, HKLM\\System\\CurrentControlSet\\Services and can be queried using a Windows built-in utility sc.exe. This process also loads device drivers marked as auto-start into memory.

When a user logs into a machine successfully, this process is responsible for setting the value of the Last Known Good control set (Last Known Good Configuration) stored in HKLM\\System\\Select\\LastKnownGood, to the value of the CurrentControlSet.

Finally, this process is the parent to several other key processes: svchost.exe, spoolsv.exe, msmpeng.exe, and dllhost.exe, and many more.

The normal behavior of services.exe:

- Image Path: %SystemRoot%\\System32\\services.exe - Parent Process: wininit.exe - Number of Instances: One. - User Account: Local System. - Start Time: Within seconds of boot time

The unusual behavior:

- A parent process other than wininit.exe - Image file path other than C:\\Windows\\System32 - Misspellings to hide rogue processes. - Multiple running instances. - Not running as SYSTEM

6- Service host (svchost.exe):

It is responsible of hosting and managing a group of background Windows services. These services are implemented as .dll files not .exe ones. The DLL to implement is stored in the registry for the service under the Parameters subkey in ServiceDLLfile and the full path is HKLM\\SYSTEM\\CurrentControlSet\\Services\\<SERVICE NAME>\\Parameters. The binary path that is used to legitimately launching the svchost.exe from the bash is C:\\Windows\\System32\\svchost.exe -k <group name> where -k is the identifier to the <group name> is a logical group label that indicates the services that share the same processes.

Note, On machines running more than 3.5 GB of memory, each service will run its own process.

Since svchost.exe will always have multiple running processes on any Windows system, this process has been a target for malicious use. Adversaries create malware to masquerade as this process and try to hide amongst the legitimate svchost.exe processes. They can name the malware svchost.exe or misspell it slightly, such as scvhost.exe. Another tactic is to install/call a malicious service (DLL).

The normal behavior of svchost.exe:

- Image Path: %SystemRoot%\\System32\\svchost.exe - Parent Process: services.exe - Number of Instances: Many - User Account: Varies (SYSTEM, Network Service, Local Service) depending on the svchost.exe instance. In Windows 10, some instances run as the logged-in user. - Start Time: Typically within seconds of boot time. Other instances of svchost.exe can be started after boot.

The Unusual behavior:

- A parent process other than services.exe - Image file path other than C:\\Windows\\System32 - Misspellings to hide rogue processes. - The absence of the -k parameter

7- Local Security Subsystem (lsass.exe):

The Microsoft Windows operating system's process that is responsible for enforcing the security policy on the system. It verifies users logging on to a Windows computer or server, handles password changes, and creates access tokens. It also writes to the Windows Security Log". The created security tokens for SAM (Security Account Manager), AD (Active Directory), and NETLOGON. It uses authentication packages specified in HKLM\\System\\CurrentControlSet\\Control\\Lsa.

Lsass.exe is another process adversaries target. Common tools such as mimikatz are used to dump credentials, or adversaries mimic this process to hide in plain sight (by either naming their malware by this process name or simply misspelling the malware slightly).

The normal behavior of lsass.exe:

- Image Path: %SystemRoot%\\System32\\lsass.exe - Parent Process: wininit.exe - Number of Instances: One. - User Account: Local System. - Start Time: Within seconds of boot time.

The unusual behavior:

- A parent process other than wininit.exe - Image file path other than C:\\Windows\\System32 - Misspellings to hide rogue processes. - Multiple running instances - Not running as SYSTEM

8- Windows logon (winlogon.exe):

It is the process that is responsible for handling user logon and secure authentication events. It is also responsible for handling the Secure Attention Sequence "SAS" (the ALT+CTRL+DELETE key combination users press to enter their username & password).

It launches the userinit.exe** , which is a legitimate Windows system process that runs when a user logs in.

It also does:

  • Initialization of the user session environment.
  • Running logon scripts.
  • Restoring network connections.
  • Starting the user's shell (explorer.exe).
  • Finally it terminates itself.

The normal behavior of winlogon.exe:

- Image Path: %SystemRoot%\\System32\\winlogon.exe - Parent Process: Created by an instance of smss.exe that self terminates, so analysis tools usually do not provide the parent process name. - Number of Instances: One or more - User Account: Local System - Start Time: Within seconds of boot time for the first instance (for Session 1). Additional instances occur as new sessions are created, typically through Remote Desktop or Fast User Switching logons.

The unusual behavior:

- An actual parent process. (smss.exe calls this process and self-terminates). - Image file path other than C:\\Windows\\System32 - Misspellings to hide rogue processes. - Not running as SYSTEM. - Shell value in the registry other than explorer.exe

9- Windows Explorer (explorer.exe):

It is the Windows shell. It is responsible for displaying and managing the user interface. It is the process that gives the user access to their folders and files. It also provides other features, such as the Start Menu and Taskbar.

The winlogon.exe process runs userinit.exe, which launches the Shell value in HKLM\\Software\\Microsoft\\WindowsNT\\CurrentVersion\\Winlogon\\Shell. userinit.exe exits after spawning explorer.exe. Because of this, the parent process is non-existent. There will be many child processes for explorer.exe.

The normal behavior of explorer.exe:

- Image Path: %SystemRoot%\\explorer.exe - Parent Process: Created by userinit.exe and exits. - Number of Instances: One or more per interactively logged-in user. - User Account: Logged-in user(s). - Start Time: First instance when the first interactive user logon session begins.

The unusual behavior:

- An actual parent process. (userinit.exe calls this process and exits). - Image file path other than C:\\Windows - Running as an unknown user. - Subtle misspellings to hide rogue processes in plain sight. - Outbound TCP/IP connections.

Thanks….