Windows Processes Basics

8 minute read
tech
,

This is from Try Hack Me…

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 CPU and memory are utilized by each process. When a program is not responding, Task Manager is used to end (kill) the process.

Use both Process Hacker and Process Explorer instead of Task Manager to obtain information about each of the Windows processes.

Aside from Task Manager, it would be best if you also familiarize yourself with the command-line equivalent of obtaining information about the running processes on a Windows system: tasklist , Get-Process or ps (PowerShell), and wmic.

System

The first Windows process on the list is System. It was mentioned in a previous section that a PID for any given process is assigned at random, but that is not the case for the System process. The PID for System is always 4. What does this process do exactly?

The official definition from Windows Internals 6th Edition:

“The System process (process ID 4) is the home for a special kind of thread that runs only in kernel mode a kernel-mode system thread. System threads have all the attributes and contexts of regular user-mode threads (such as a hardware context, priority, and so on) but are different in that they run only in kernel-mode executing code loaded in system space, whether that is in Ntoskrnl.exe or in any other loaded device driver. In addition, system threads don’t have a user process address space and hence must allocate any dynamic storage from operating system memory heaps, such as a paged or nonpaged pool.”

What is unusual behavior for this process?

  • A parent process (aside from System Idle Process (0))
  • Multiple instances of System. (Should only be 1 instance)
  • A different PID. (Remember that the PID will always be PID 4)
  • Not running in Session 0

Session Manager Subsystem

The next process is smss.exe (Session Manager Subsystem). This process, also known as the Windows Session Manager, is responsible for creating new sessions. This is the first user-mode process started by the kernel.

This process starts the kernel mode and user mode of the Windows subsystem (you can read more about the NT Architecture here). This subsystem includes win32k.sys (kernel mode), winsrv.dll (user mode), and csrss.exe (user mode).

Smss.exe starts csrss.exe (Windows subsystem) and wininit.exe in 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 creates child instances in new sessions. This is done by smss.exe copying itself into the new session and self-terminating. You can read more about this process here.

Session 0 (csrss.exe & wininit.exe)

Session 1 (csrss.exe & winlogon.exe)

Any other subsystem listed in the Required value of HKLM\System\CurrentControlSet\Control\Session Manager\Subsystems is also launched.

SMSS is also responsible for creating environment variables, virtual memory paging files and starts winlogon.exe (the Windows Logon Manager).

What is unusual?

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

Client Server Runtime Process

csrss.exe (Client Server Runtime Process) is the user-mode side of the Windows subsystem. This process is always running and is critical to system operation. If by chance this process is terminated it will result in system failure. This process is responsible for the Win32 console window and process thread creation and deletion. For each instance csrsrv.dll, basesrv.dll, and winsrv.dll are loaded (along with others).

This process is also responsible for making the Windows API available to other processes, mapping drive letters, and handling the Windows shutdown process.  You can read more about this process here.

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

What is unusual?

  • An actual parent process. (smss.exe calls this process and self-terminates)
  • Image file path other than C:\Windows\System32
  • Subtle misspellings to hide rogue process masquerading as csrss.exe in plain sight
  • User is not SYSTEM

Windows Initialization Process

The Windows Initialization Process, wininit.exe, is responsible for launching services.exe (Service Control Manager), lsass.exe (Local Security Authority), and lsaiso.exe within Session 0. This is another critical Windows process that runs in the background, along with its child processes.

Note: lsaiso.exe is a process associated with Credential Guard and Key Guard. You will only see this process if Credential Guard is enabled.

What is unusual?

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

Service Control Manager

The next process is the Service Control Manager (SCM), which is services.exe. Its primary responsibility is to handle system services: loading services, interacting with services, starting/ending services, etc. It maintains a database that can be queried using a Windows built-in utility, ‘sc.exe.’

Information regarding services is stored in the registry, HKLM\System\CurrentControlSet\Services.

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), HKLM\System\Select\LastKnownGood, to that of the CurrentControlSet.

This process is the parent to several other key processes: svchost.exe, spoolsv.exe, msmpeng.exe, dllhost.exe, to name a few. You can read more about this process here.

What is unusual?

  • A parent process other than wininit.exe
  • Image file path other than C:\Windows\System32
  • Subtle misspellings to hide rogue process in plain sight
  • Multiple running instances
  • Not running as SYSTEM

Service Host

The Service Host (Host Process for Windows Services), or svchost.exe, is responsible for hosting and managing Windows services.

The services running in this process are implemented as DLLs. The DLL to implement is stored in the registry for the service under the Parameters subkey in ServiceDLL. The full path is HKLM\SYSTEM\CurrentControlSet\Services\SERVICE NAME\Parameters.

There is a key identifier in the binary path. That identifier is -k . This is how a legitimate svchost.exe process is called.

The -k parameter is for grouping similar services to share the same process. This concept was based on the OS design and implemented to reduce resource consumption. Starting from Windows 10 Version 1703 services grouped into host processes changed. On machines running more than 3.5 GB of memory, each service will run its own process.  You can read more about this process here.

Back to the key identifier (-k) from the binary path. In the above screen the -k value is Dcomlaunch. In the virtual machine used to create this room, there are other services running with the same binary path.

Each will have a different value for ServiceDLL.

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. By doing so the intention is to go under the radar. Another tactic is to install/call a malicious service (DLL).

Extra reading - Hexacorn Blog here

What is unusual?

  • A parent process other than services.exe
  • Image file path other than C:\Windows\System32
  • Subtle misspellings to hide rogue process in plain sight
  • The absence of the -k parameter

Local Security Authority Subsystem Service

“Local Security Authority Subsystem Service (LSASS) is a process in Microsoft Windows operating systems 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.”

It creates security tokens for SAM (Security Account Manager), AD (Active Directory), and NETLOGON. It uses authentication packages specified in HKLM\System\CurrentControlSet\Control\Lsa.

This is another process adversaries target. Common tools such as mimikatz is used to dump credentials or they mimic this process to hide in plain sight. Again, they do this by either naming their malware by this process name or simply misspelling the malware slightly.

Extra reading: How LSASS is maliciously used and additional features that Microsoft has put into place to prevent these attacks. (here)

What is unusual?

  • A parent process other than wininit.exe
  • Image file path other than C:\Windows\System32
  • Subtle misspellings to hide rogue process in plain sight
  • Multiple running instances
  • Not running as SYSTEM

Windows Logon

The Windows Logon, winlogon.exe, is responsible for handling the Secure Attention Sequence (SAS). This is the ALT+CTRL+DELETE key combination users press to enter their username & password.

This process is also responsible for loading the user profile. This is done by loading the user’s NTUSER.DAT into HKCU and via userinit.exe loads the user’s shell. Read more about this process here.

It is also responsible for locking the screen and running the user’s screensaver, among other functions. You can read more about this process here.

Remember from earlier sections, smss.exe launches this process along with a copy of csrss.exe within Session 1.

What is unusual?

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

Windows Explorer

The last process we’ll look at is the Windows Explorer, explorer.exe. This is the process that gives the user access to their folders and files. It also provides functionality to other features such as the Start Menu, Taskbar, etc.

As mentioned previously, the Winlogon process runs userinit.exe, which launches the value in HKLM\Software\Microsoft\Windows NT\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.

What is unusual?

  • 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 process in plain sight
  • Outbound TCP/IP connections

Earlier it was mentioned that if Credential Guard is enabled on the endpoint an additional process will be running, which will be a child process to wininit.exe, and that process is lsaiso.exe. This process works in conjunction with lsass.exe to enhance password protection on the endpoint.

Other processes with Windows 10 is RuntimeBroker.exe and taskhostw.exe (formerly taskhost.exe and taskhostex.exe). Please research these processes and any other processes you might be curious about to understand their purpose and their normal functionality.