Windows Core Processes | Notes on SOC Layer 1 TryHackMe Room

This blog is essentially a compilation of my notes from the ‘Windows Core Processes’ room on TryHackMe.

The readings provided throughout the course were a bit dry and confusing for me. Thus, I’ve drawn the following hierarchy of Windows core system processes.

Windows Core Processes Hierarchy

The System Process (PID 4)

• Only runs in Kernel mode.
• Image Path: C:\Windows\system32\ntoskrnl.exe
• The System process represents the running state of the ntoskrnl.exe in memory.
• User is the SYSTEM. Any other user than SYSTEM, it is sus.
• While process identifier numbers (PIDs) are typically assigned at random, one constant remains: the PID for the SYSTEM process is invariably set to 4.

• Parent process of the System process is System Idle Process (with PID 0).

Session Manager Subsystem Process (smss.exe)

• The parent of the smss.exe process is System process.
• Starts in kernel-mode.

• User is the SYSTEM. This process should not be started by any user other than the SYSTEM.
• Image Path: %SystemRoot%\System32\smss.exe
• It has many child processes.

Responsible for

• nitializing the user session during system startup.
• Setting up environment variables.
• Launching the winlogon.exe process for user logins-Session 1.
• Creating additional sessions (for instance, when using Fast User Switching or Terminal Services).

During the boot-up process, smss.exe is one of the first user-mode processes to start, and it precedes the user login phase. This means the smss.exe process starts before you log on. After it has completed its tasks for system initialization, the primary smss.exe process exits, but when new user sessions are created (as in Terminal Services), a new instance of smss.exe will handle the creation of those sessions.

(In Session 0 — meaning kernel session) smss.exe starts the csrss.exe and wininit.exe processes. The session 0 tells us that it is kernel-level, and we are not actually interacting with it. As users, when we log in to our user account, we are in session 1 or others, not session 0.

smss.exe also spawns the Session 1 process csrss.exe.

Notice how the the Parent process of csrss.exe (both in Session 0 and 1) do not have a parent process (non-existent process).

This is because when the smss.exe process spawns a process, it terminates itself. Hence, there is no process called smss.exe anymore, which cannot refered as a parent process.

Note: Since smss.exe terminates after spawning certain processes, if you check the parent process of, for instance, csrss.exe (which should be spawned by smss.exe), and you see a parent different from "non-existent," then you should know that something went wrong and further investigation is needed.

The Client Server Runtime Process (csrss.exe)

• User is the SYSTEM. Hence, no other user should be starting this process.
• Image path %SystemRoot%\System32\csrss.exe
• Threat creating and deletion.
• Responsible for making Windows API calls.
• There is one Session 0 and Session 1 csrss.exe processes. Hence, one expects to see two of this process. Their PIDs are different.
• “Non-existing parent”, otherwise something is sus. So, if you see an actual process with a PID, it is time to hunt.

Windows Initialization Process (wininit.exe)

• The user is the SYSTEM. Other then SYSTEM user, it is kinda sus.
• Image Path: %SystemRoot%\System32\wininit.exe
• Responsible for launching services, service control manager.
• Remember, in Session 0, smss.exe process spawns two processes: csrss.exe and wininit.exe.
• As spawned by the smss.exe process, “non-existing process” for parent process.
• There should be only one of it. More than one instance is also sus.
• wininit.exe spawns three other processes within Session 0: services.exe, lsass.exe and lsaiso.exe.

TryHackMe Quote: “lsaiso.exe is a process associated with Credential Guard and KeyGuard. You will only see this process if Credential Guard is enabled.”

Service Control Manager (wininit.exe > services.exe)

• Image Path: %SystemRoot%\System32\services.exe
• The parent process is always the wininit.exe
• User is the SYSTEM.
• There is only one instance.
• Responsible for loading, interacting, and starting or ending services.
• Its database can be queried by a OS native program called sc.exe.

• The services.exe processes have multiple child processes.

The Service Host (wininit.exe > services.exe > svchost.exe)

• Responsible for hosting and managing services.
• Multiple occurance.
• Where the DLL processes are stored.

For instance, let us take a closer to the ServiceDLL value for the DcomLaunch service.

Take a closer look as the Binary path in the DcomLaunch properties. The thing that should take your attention is an identifier is the parameter “-k”. It is used for grouping similar servicess.

If you do not see this “-k”, it’s not a legit service process. The absence of the parameter k is an indicator of compromise.

Local Security Authority Subsystem Service (wininit.exe > lsass.exe)

• Responsible for enforcing the security policy on the system.

TryHackMe Definition: 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.

• Image Path: %SystemRoot%\System32\lsass.exe
• Parent process is always the wininit.exe process.
• User is the SYSTEM.
• There should be only one instance.

Okay, now we are moving to the Session 1 processes.

Windows Logon (winlogon.exe)

• Responsible for handling the Secure Attention Sequence (SAS), and loading the user profile.
• Should be in Session 1, user-mode.
• The parent is smss.exe, meaning that “non-existing process” should be displayed.
• More than one instance is normal as new sessions are created with, for instance, RDP connections.
• User is the SYSTEM.

Windows Explorer (explorer.exe)

• Responsible for giving the user access to their folders and files.
• Functionalities to other features such as the Start Menu, Taskbar, etc.
• Non-existing parent process as userinit.exe terminates itself after spawning the explorer.exe process.

User Account: Logged-in user(s). In other words, the user account should be the whomever logged in to the system.

There should not be outbound TCP/IP connections unless you are aware of it.

Hope you enjoyed or got benefit from it.

Best Regards,

Sıla.