Windows Process Genealogy | Notion

Flowchart

Untitled

Processes

System

Does not have an image path because it doesn't host an executable image like other processes (has no executable on disk from which this process is spawned - does not have system.exe or something like that)
Exists solely to host operating system threads for the memory manager, the cache manager and other subsystems, as well as device driver threads that execute entirely in kernel mode

smss.exe

SystemRoot is typically C:\Windows

csrss.exe

Analysis tools do not usually provide the parent process name, because it is created by an instance of smss.exe that exits
User mode process that is responsible for implementing most of the Windows API

wininit.exe

Process table

Process	Tree	Image path	Parent process	No. of instances	User account	Start time	Description
System	1	N/A – Not generated from an executable image	None	One	Local System	At boot time	The System process is responsible for most kernel-mode threads. Modules run under System are primarily drivers (.sys fi les), but also include several important DLLs as well as the kernel executable, ntoskrnl.exe.
smss.exe	2	%SystemRoot%\System32\smss.exe	System	One master instance and another child instance per session. Children exit after creating their session.	Local System	Within seconds of boot time for the master instance	The Session Manager process is responsible for creating new sessions. The first instance creates a child instance for each new session. Once the child instance initializes the new session by starting the Windows subsystem (csrss.exe) and wininit.exe for Session 0 or winlogon.exe for Session 1 and higher, the child instance exits
csrss.exe	3	%SystemRoot%\System32\csrss.exe	Created by an instance of smss.exe that exits, so analysis tools usually do not provide the parent
process name	Two or more	Local System	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 often only Sessions 0 and 1 are created.	The Client/Server Run-Time Subsystem is the user-mode process for the Windows subsystem. Its duties include managing processes and threads, importing many of the DLLs that provide the Windows API, and facilitating the shutdown of the GUI during system shutdown. An instance of csrss.exe will run for each session. Session 0 is for services and Session 1 is for the local console session. Additional sessions are created through the use of Remote Desktop and/or Fast User Switching. Each new session results in a new instance of csrss.exe
wininit.exe	3	%SystemRoot%\System32\wininit.exe	Created by an instance of smss.exe that exits, so tools
usually do not provide the parent process name.	One	Local System	Within seconds of boot time	Wininit.exe starts key background processes within Session 0. It starts Service Control Manager (services.exe), Local Security Authority process (lsass.exe), and lsaiso.exe for systems with Credential Guard enabled. Note that prior to Windows 10, the Local Session Manager process (lsm.exe) was also started by wininit.exe. As of Windows 10, that functionality has moved to a service DLL (lsm.dll) hosted by svchost.exe
services.exe	4	%SystemRoot%\System32\services.exe	wininit.exe	One	Local System	Within seconds of boot time	Implements the Unified Background Process Manager (UBPM), which is responsible for background activities such as services and scheduled tasks. Services.exe also implements the Service Control Manager (SCM), which specifically handles the loading of services and device drivers marked for auto-start. In addition, once a user has successfully logged on interactively, the SCM (services.exe) considers the boot successful and sets the Last Known Good control set (HKLM\SYSTEM\Select\LastKnownGood) to the value of the CurrentControlSet.
svchost.exe	5	%SystemRoot%\system32\svchost.exe	services.exe (most often)	Many (generally at least 10)	Varies depending on svchost instance, though it typically will be Local System, Network Service, or Local Service accounts. Windows 10 also has some instances running as logged-on users	Typically within seconds of boot time. However, services can be started after boot (e.g., at logon), which results in new instances of svchost.exe after boot time.	Generic host process for Windows services. It is used for running service DLLs. Windows will run multiple instances of svchost.exe, each using a unique “-k” parameter for grouping similar services. Typical “-k” parameters include DcomLaunch, RPCSS, LocalServiceNetworkRestricted, LocalServiceNoNetwork,
LocalServiceAndNoImpersonation, netsvcs, NetworkService, and more. Malware authors often take advantage of the ubiquitous nature of svchost.exe and use it either to host a malicious DLL as a service or run a malicious process named svchost.exe or similar spelling. Beginning in Windows 10 version 1703, Microsoft changed the default grouping of similar services if the system has more than 3.5 GB of RAM. In such cases, most services will run under their own instance of svchost.exe. On systems with more than 3.5 GB RAM, expect to see more than 50 instances of svchost.exe
RuntimeBroker.exe	6	%SystemRoot%\System32\RuntimeBroker.exe	svchost.exe	One or more	Typically the logged-on user(s)	Start times vary greatly	RuntimeBroker.exe acts as a proxy between the constrained Universal Windows Platform (UWP) apps (formerly called Metro apps) and the full Windows API. UWP apps have limited capability to interface with hardware and the file system. Broker processes such as RuntimeBroker.exe are therefore used to provide the necessary level of access for UWP apps. Generally, there will be one RuntimeBroker.exe for each UWP app. For example, starting Calculator.exe will cause a corresponding RuntimeBroker.exe process to initiate.
taskhostw.exe	6	%SystemRoot%\System32\taskhostw.exe	svchost.exe	One or more	Multiple taskhostw.exe processes are normal. One or more may be owned by logged-on users and/or by local service accounts.	Start times vary greatly	The generic host process for Windows Tasks. Upon initialization, taskhostw.exe runs a continuous loop listening for trigger events. Example trigger events that can initiate a task include a defined schedule, user logon, system startup, idle CPU time, a Windows log event, workstation lock, or workstation unlock. There are more than 160 tasks preconfigured on a default installation of Windows 10 Enterprise (though many are disabled). All executable files (DLLs & EXEs) used by the default Windows 10 scheduled tasks are signed by Microsoft.
lsaiso.exe	4	%SystemRoot%\System32\lsaiso.exe	wininit.exe	Zero or one	Local System	Within seconds of boot time	When Credential Guard is enabled, the functionality of lsass.exe is split between two processes – itself and lsaiso.exe. Most of the functionality stays within lsass.exe, but the important role of safely storing account credentials moves to lsaiso.exe. It provides safe storage by running in a context that is isolated from other processes through hardware virtualization technology. When remote authentication is required, lsass.exe proxies the requests using an RPC channel with lsaiso.exe in order to authenticate the user to the remote service. Note that if Credential Guard is not enabled, lsaiso.exe should not be running on the system.
lsass.exe	4	%SystemRoot%\System32\lsass.exe	wininit.exe	One	Local System	Within seconds of boot time	The Local Security Authentication Subsystem Service process is responsible for authenticating users by calling an appropriate authentication package specified in HKLM\SYSTEM\CurrentControlSet\Control\Lsa. Typically, this will be Kerberos for domain accounts or MSV1_0 for local accounts. In addition to authenticating users, lsass.exe is also responsible for implementing the local security policy (such as password policies and audit policies) and for writing events to the security event log. Only one instance of this process should occur and it should rarely have child processes (EFS is a known exception)
winlogon.exe	3	%SystemRoot%\System32\winlogon.exe	Created by an instance of smss.exe that exits, so analysis tools usually do not provide the parent process name.	One or more	Local System	Within seconds of boot time for the first instance (for Session 1). Start times for additional instances occur as new sessions are created, typically through Remote Desktop or Fast User Switching logons.	Winlogon handles interactive user logons and logoffs. It launches LogonUI.exe, which uses a credential provider to gather credentials from the user, and then passes the credentials to lsass.exe for validation. Once the user is authenticated, Winlogon loads the user’s NTUSER.DAT into HKCU and starts the user’s shell (usually explorer.exe) via userinit.exe
explorer.exe	5	%SystemRoot%\explorer.exe	Created by an instance of userinit.exe that exits, so analysis tools usually do not provide the parent process name.	One or more per interactively logged-on user	<logged-on user(s)>	First instance starts when the owner’s interactive logon begins	At its core, Explorer provides users access to files. Functionally, though, it is both a file browser via Windows Explorer (though still explorer.exe) and a user interface providing features such as the user’s Desktop, the Start Menu, the Taskbar, the Control Panel, and application launching via file extension associations and shortcut files. Explorer.exe is the default user interface specified in the Registry value HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell, though Windows can alternatively function with another interface such as cmd.exe or powershell.exe. Notice that the legitimate explorer.exe resides in the %SystemRoot% directory rather than %SystemRoot%\System32. Multiple instances per user can occur, such as when the option "Launch folder windows in a separate process" is enabled.

Resources