Post cover image

September 3, 2026

Core Windows Processes: A SOC L1 Guide to Understanding What Normal Looks Like

Introduction

By Harsh Katiyar

11 min read

Introduction

Understanding how Windows processes normally operate is an important foundation for endpoint investigation.

For a SOC analyst, seeing a process such as svchost.exe, lsass.exe, or explorer.exe is only the beginning. The process name alone does not tell you whether the activity is legitimate.

A stronger approach is to establish a baseline and then compare what you observe against it.

The supplied material builds that baseline by following the Windows process hierarchy from the kernel and early boot stages through session creation, services, authentication, logon, and the user interface. The central investigation principle is:

What process is this?
        ↓
Where is the executable?
        ↓
Who is running it?
        ↓
What started it?
        ↓
What command line was used?
        ↓
What children did it create?
        ↓
Does everything match the expected baseline?

1. Start With Task Manager

Windows includes Task Manager, a native GUI utility for viewing and managing running processes.

It provides visibility into:

  • Running processes
  • CPU usage
  • Memory usage
  • Process IDs
  • Executable names
  • Command lines
  • Process paths, when the relevant columns are enabled

For SOC work, the most useful fields are often more than just CPU and memory.

Important investigation fields include:

FieldWhy it mattersProcess nameIdentifies the executablePIDIdentifies a specific process instancePublisherProvides ownership/contextCommand lineShows how the process was launchedImage pathShows where the executable residesUserShows execution contextParent processProvides process ancestry

The material also highlights an important limitation: Task Manager does not provide the process-tree information needed for deeper parent-child analysis. Tools such as Process Hacker and Process Explorer can provide additional process context.

SOC lesson

Don't stop at:

svchost.exe exists

Instead ask:

Which svchost.exe?
What PID?
What path?
What command line?
Who is its parent?
What service does it represent?

2. The System Process — PID 4

The System process is one of the foundational Windows processes to recognize.

The supplied material identifies a critical fact:

System → PID 4

The System process provides a home for system threads that execute in kernel mode. These threads can execute Windows kernel code and code from loaded device drivers.

This makes System fundamentally different from an ordinary user application.

Normal System baseline

According to the material:

System
├── PID: 4
├── Instances: 1
├── User: Local System
├── Start: Boot time
├── Session: 0
└── Parent: None / System Idle Process (0),
            depending on the investigation tool

The source notes that Process Explorer and Process Hacker can present slightly different information about the System process.

What should concern an analyst?

The material identifies these unusual characteristics:

  • A parent other than the expected relationship
  • Multiple System instances
  • A PID other than 4
  • System running outside Session 0

These should be treated as investigation triggers, not automatic proof of compromise.

SOC principle

This is an excellent example of baseline-based detection:

Known normal
     ↓
Observed process
     ↓
Compare characteristics
     ↓
Identify deviations
     ↓
Investigate

3. smss.exe — Session Manager Subsystem

smss.exe stands for Session Manager Subsystem.

It is one of the earliest user-mode processes started during Windows boot and is responsible for creating and managing Windows sessions.

The material focuses on two sessions:

Session 0
    ├── csrss.exe
    └── wininit.exe
Session 1
    ├── csrss.exe
    └── winlogon.exe

The simplified relationship is:

System (PID 4)
      ↓
   smss.exe
      ├── Session 0
      │     ├── csrss.exe
      │     └── wininit.exe
      │
      └── Session 1
            ├── csrss.exe
            └── winlogon.exe

An important process-tree detail is that child smss.exe instances created for additional sessions can self-terminate after completing their work.

Normal smss.exe baseline

Path:
%SystemRoot%\System32\smss.exe
Parent:
System (PID 4)
User:
Local System
Master instance:
One
Startup:
Very early during boot

The source identifies several characteristics worth investigating:

  • Parent other than System
  • Executable outside the expected System32 location
  • More than one continuously running instance
  • Unexpected user
  • Unexpected subsystem Registry entries

This demonstrates why process count must be interpreted according to the specific process.

4. csrss.exe — Client Server Runtime Process

csrss.exe is the Client Server Runtime Process, a critical user-mode component of the Windows subsystem.

The supplied material associates it with functions including:

  • Win32 console windows
  • Process creation and deletion
  • Thread creation and deletion
  • Windows API functionality
  • Drive-letter mapping
  • Aspects of Windows shutdown

It is a critical process, so terminating it can result in system failure.

Normal baseline

csrss.exe
├── Path: %SystemRoot%\System32\csrss.exe
├── User: Local System
├── Instances: Two or more
└── Initial instances: Start within seconds of boot

One of the most important lessons here is that multiple instances are normal.

This differs from processes such as wininit.exe or services.exe, where the source describes one normal running instance.

The source also explains an unusual parent relationship.

smss.exe creates csrss.exe, but the relevant smss.exe instance subsequently terminates. Therefore, an active parent process may not be present when csrss.exe is examined.

Investigative indicators

The material identifies:

  • An actual/current parent process
  • An incorrect image path
  • A misspelled process name
  • An unexpected user

For example:

C:\Users\Bob\csrss.exe

doesn't match the expected System32 location and should be investigated.

5. wininit.exe — Windows Initialization Process

wininit.exe is responsible for launching important system processes within Session 0.

The process relationship is:

smss.exe
    ↓
wininit.exe
    ├── services.exe
    ├── lsass.exe
    └── lsaiso.exe*

lsaiso.exe is conditional in the supplied material and is associated with Credential Guard and KeyGuard.

Normal baseline

wininit.exe
├── Path: %SystemRoot%\System32\wininit.exe
├── Parent: Created by smss.exe
├── Instances: One
├── User: Local System
└── Start: Within seconds of boot

The source identifies these as investigation indicators:

  • Actual/current parent process
  • Incorrect image path
  • Misspelled filename
  • Multiple running instances
  • Unexpected user

Again, these are anomalies to investigate, rather than automatic proof of malicious activity.

6. services.exe — Service Control Manager

services.exe is also known as the Service Control Manager (SCM).

Its responsibilities include managing Windows services, starting and stopping services, maintaining service information, and loading certain auto-start device drivers.

The expected process relationship is:

wininit.exe
      ↓
services.exe

The material also introduces:

sc.exe

as a command-line utility for communicating with the Service Control Manager and Windows services.

The important Registry location is:

HKLM\System\CurrentControlSet\Services

This is where service configuration information is maintained.

Normal baseline

services.exe
├── Path: %SystemRoot%\System32\services.exe
├── Parent: wininit.exe
├── Instances: One
├── User: Local System
└── Start: Within seconds of boot

Investigation indicators

The source identifies:

  • Parent other than wininit.exe
  • Incorrect image path
  • Misspelled process name
  • Multiple instances
  • Unexpected user

The important SOC lesson is that services.exe itself is not the same thing as an individual Windows service.

Think of it as:

services.exe
     ↓
Service Control Manager
     ↓
Windows services

7. svchost.exe — Service Host

svchost.exe is particularly important for SOC L1 analysts because Windows systems commonly have many instances of it.

Its purpose is to provide a process in which certain Windows services can run. The services hosted by svchost.exe are implemented as DLLs.

The expected relationship is:

wininit.exe
      ↓
services.exe
      ↓
svchost.exe

Why multiple instances are normal

The source explicitly identifies:

svchost.exe
→ Many instances

as normal.

This is a critical distinction.

A SOC analyst should never use:

Multiple processes = malicious

as a general rule.

Instead:

Multiple processes
       ↓
Is this normal for this process?
       ↓
Check the baseline

Normal baseline

svchost.exe
├── Path: %SystemRoot%\System32\svchost.exe
├── Parent: services.exe
├── Instances: Many
├── User: Varies
└── Start: Usually around boot,
           but additional instances can start later

The source notes accounts such as:

SYSTEM
Network Service
Local Service

and explains that some instances can run as the logged-in user depending on the Windows environment.

8. The -k Parameter

One of the most useful details when investigating svchost.exe is its command line.

The material identifies the:

-k

parameter.

For example:

C:\Windows\System32\svchost.exe -k Dcomlaunch

The -k value is associated with service grouping.

Conceptually:

svchost.exe
      ↓
-k <group>
      ↓
Services associated with that group

The source also describes the Registry relationship for a service such as DCOMLaunch:

HKLM\SYSTEM\CurrentControlSet\Services\Dcomlaunch\Parameters

with:

ServiceDLL

being relevant to the DLL implementing the service.

This gives a useful investigation path:

svchost.exe
    ↓
Command line
    ↓
-k group
    ↓
Service
    ↓
ServiceDLL
    ↓
Registry configuration

Indicators worth investigating

The supplied material identifies:

  • Parent other than services.exe
  • Incorrect image path
  • Misspelled filename such as scvhost.exe
  • Missing -k parameter

None of these should be interpreted in isolation as proof of malware.

9. lsass.exe — Local Security Authority Subsystem Service

lsass.exe is the Local Security Authority Subsystem Service.

It is responsible for important Windows security functions, including authentication-related activity, password changes, access tokens, and security logging.

The expected relationship is:

wininit.exe
      ↓
lsass.exe

Normal baseline

lsass.exe
├── Path: %SystemRoot%\System32\lsass.exe
├── Parent: wininit.exe
├── Instances: One
├── User: Local System
└── Start: Within seconds of boot

The material identifies the following investigation indicators:

  • Parent other than wininit.exe
  • Path outside System32
  • Misspelled process name
  • Multiple instances
  • Unexpected user

The source also highlights the security importance of LSASS because adversaries may target it for credential dumping and specifically mentions Mimikatz.

The associated Registry area described in the source is:

HKLM\System\CurrentControlSet\Control\Lsa

For SOC analysis, the important distinction is:

Legitimate LSASS
      ↓
Windows authentication/security
versus
Suspicious activity
      ↓
Process/path/user/context
      ↓
Potential security investigation

10. winlogon.exe — Windows Logon

winlogon.exe is responsible for important Windows logon functionality.

The source identifies the Secure Attention Sequence (SAS):

ALT + CTRL + DELETE

It also describes responsibilities involving:

  • Loading the user profile
  • Loading NTUSER.DAT into HKCU
  • Working with userinit.exe
  • Screen locking
  • Screensavers
  • Other logon-related functionality

The Session 1 relationship is:

smss.exe
   ├── csrss.exe
   └── winlogon.exe

Then:

winlogon.exe
      ↓
userinit.exe
      ↓
explorer.exe

An important process-tree detail is that the smss.exe instance responsible for creating winlogon.exe terminates. Therefore, a currently visible parent process may not exist.

Normal baseline

winlogon.exe
├── Path: %SystemRoot%\System32\winlogon.exe
├── User: Local System
├── Instances: One or more
└── First instance: Shortly after boot

Additional instances can occur with additional sessions, including scenarios such as Remote Desktop and Fast User Switching.

The source also identifies an unexpected shell Registry value as an investigation indicator.

The expected shell value is:

explorer.exe

11. explorer.exe — Windows Explorer

explorer.exe represents the Windows Explorer user interface and provides access to files, folders, the Start Menu, Taskbar, and other Windows UI functionality.

The logon relationship is:

winlogon.exe
      ↓
userinit.exe
      ↓
explorer.exe

The source explains that userinit.exe launches Explorer and then exits.

Therefore:

explorer.exe
Parent: None

can be normal.

This is an important process-tree lesson.

Normal baseline

explorer.exe
├── Path: %SystemRoot%\explorer.exe
├── User: Logged-in user
├── Instances: One or more per interactive user
└── Start: First interactive user logon

Notice the path:

C:\Windows\explorer.exe

rather than:

C:\Windows\System32\explorer.exe

This reinforces another important principle:

Know the expected path for each specific process.

The source also states that Explorer can have many child processes.

For SOC investigation, those children can provide useful context:

explorer.exe
     ↓
Child process
     ↓
Executable
     ↓
Command line
     ↓
File path
     ↓
User

The material specifically identifies outbound TCP/IP connections from Explorer as unusual.

That does not automatically mean compromise, but it gives the analyst a reason to investigate the process and its network activity.

12. Putting the Process Chain Together

After working through these processes, the Windows process hierarchy becomes much easier to visualize.

A simplified chain from the supplied material is:

System (PID 4)
       ↓
    smss.exe
       ├──────────────────────┐
       ↓                      ↓
   Session 0              Session 1
       ↓                      ↓
  csrss.exe             csrss.exe
  wininit.exe           winlogon.exe
       ↓                      ↓
  services.exe           userinit.exe
       ↓                      ↓
  svchost.exe            explorer.exe
       │
       ├── services/processes
       │
       └── other service-related activity
wininit.exe
    ├── lsass.exe
    └── lsaiso.exe*

lsaiso.exe is conditional on Credential Guard according to the source.

This tree is more useful than memorizing individual process names because it gives you context.

13. Process Baselines at a Glance

ProcessExpected pathParent/contextNormal instancesSystemN/A in Process Explorer representationNone / System Idle Process depending on toolOnesmss.exeSystem32\smss.exeSystemOne master + temporary childrencsrss.exeSystem32\csrss.exeCreated by smss.exeTwo or morewininit.exeSystem32\wininit.exeCreated by smss.exeOneservices.exeSystem32\services.exewininit.exeOnesvchost.exeSystem32\svchost.exeservices.exeManylsass.exeSystem32\lsass.exewininit.exeOnewinlogon.exeSystem32\winlogon.exeCreated by smss.exeOne or moreexplorer.exeC:\Windows\explorer.exeCreated by userinit.exeOne or more per interactive user

The exact expected behavior should always be interpreted according to the individual process rather than applying one rule to every executable.

14. A Practical SOC Investigation Method

When you encounter an unfamiliar or suspicious Windows process, work through a consistent sequence.

1. WHAT?

Identify the exact process name.

svchost.exe

Don't rely on approximate visual similarity.

2. WHERE?

Check the image path.

C:\Windows\System32\svchost.exe

A familiar filename in an unexpected directory deserves investigation.

3. WHO?

Identify the associated user.

For some processes, the expected account is:

SYSTEM

For others, such as Explorer, the logged-in user is expected.

4. HOW?

Inspect the command line.

For svchost.exe, for example:

svchost.exe -k <group>

The command line can provide context that the process name cannot.

5. PARENT?

Determine what created the process.

Examples from this material include:

wininit.exe
    ↓
services.exe

and:

services.exe
    ↓
svchost.exe

An unexpected parent can be an important investigation lead.

6. HOW MANY?

Understand the process-specific instance baseline.

For example:

lsass.exe → One
svchost.exe → Many
explorer.exe → One or more per interactive user

There is no universal "multiple instances = bad" rule.

7. WHEN?

Consider startup timing.

Several core Windows processes are expected to start around system boot, while other processes may legitimately appear later.

8. WHAT CHILDREN?

Look at child processes where applicable.

For example:

services.exe
    ↓
svchost.exe

Understanding process ancestry can reveal whether execution makes sense.

9. NETWORK?

For processes where network behavior is relevant, investigate connections and destinations.

The source specifically highlights outbound TCP/IP connections from explorer.exe as unusual.

10. LOGS / EDR?

Finally, correlate process observations with available endpoint telemetry and Windows logs.

The objective is not to label an anomaly immediately.

The objective is to build enough context to determine whether the activity has a legitimate explanation.

15. Common SOC Mistakes

Mistake 1: Trusting the process name

Seeing:

lsass.exe

doesn't prove that the executable is legitimate.

Check:

Name
↓
Path
↓
Parent
↓
User
↓
Command line

Mistake 2: Assuming multiple instances are malicious

This fails immediately for processes such as:

svchost.exe
csrss.exe
winlogon.exe
explorer.exe

where multiple instances can be normal according to the supplied material.

Mistake 3: Treating a missing parent as automatically suspicious

Several processes in this material are created by processes that subsequently terminate.

For example:

userinit.exe
      ↓
explorer.exe
userinit.exe exits

Therefore, Explorer having no current parent can be normal.

Similar considerations apply to processes created by smss.exe.

Mistake 4: Treating every anomaly as proof of malware

A suspicious path, parent, or command line is a signal.

A good SOC analyst investigates the signal and looks for supporting evidence.

Anomaly
   ↓
Validate
   ↓
Correlate
   ↓
Investigate
   ↓
Determine legitimacy

16. Why Native Windows Knowledge Matters

Dedicated tools such as Process Explorer and Process Hacker can provide deeper process visibility.

However, Task Manager and command-line tools remain important because they are native Windows capabilities.

The material specifically introduces:

tasklist
Get-Process
ps
wmic

for process-related information.

This matters during real endpoint investigations because an analyst may not always be able to immediately deploy additional tooling.

Knowing how to work with the operating system's native visibility is therefore an important practical skill.

17. Security Perspective

The common thread across all of these processes is baseline analysis.

A defender should know:

Expected process
     ↓
Expected location
     ↓
Expected parent
     ↓
Expected user
     ↓
Expected number of instances
     ↓
Expected startup behavior

Then compare that baseline with what is actually observed.

For example:

Expected

services.exe
    ↓
svchost.exe
    ↓
C:\Windows\System32\svchost.exe
    ↓
-k <group>

Worth investigating

powershell.exe
    ↓
svchost.exe
    ↓
C:\Users\Bob\svchost.exe
    ↓
No -k

The second chain contains multiple deviations from the expected baseline described in the material.

That doesn't by itself establish exactly what happened — but it gives the SOC analyst a strong reason to investigate.

18. Windows 10 and Additional Core Processes

The supplied conclusion notes that Windows 10 introduced additional processes that analysts should understand.

It specifically mentions:

lsaiso.exe
RuntimeBroker.exe
taskhostw.exe

The material states that lsaiso.exe is associated with Credential Guard and KeyGuard and works with lsass.exe to enhance password protection. It also notes that taskhostw.exe replaced the earlier taskhost.exe and taskhostex.exe naming.

The supplied material does not provide enough detail to establish full behavioral baselines for RuntimeBroker.exe or taskhostw.exe, so they should be treated here as additional processes to study, rather than inventing characteristics that aren't supported by the notes.

19. Key Takeaways

1. Process names are only the starting point

Name ≠ legitimacy

Context matters.

2. Learn process-specific baselines

svchost.exe → Many
lsass.exe → One
services.exe → One

Different processes have different normal behavior.

3. Process ancestry matters

Understanding:

Parent
  ↓
Child

can provide valuable context during endpoint investigations.

4. Paths matter

A legitimate-looking filename outside its expected Windows directory can be an important anomaly.

5. Command lines matter

The command line can reveal how a process was launched and, for svchost.exe, can expose the -k service grouping.

6. Native tools matter

Task Manager, tasklist, and PowerShell's Get-Process can provide useful visibility when dedicated tools aren't available.

7. An anomaly is not automatically compromise

The correct mindset is:

Unexpected
    ↓
Investigate
    ↓
Correlate
    ↓
Determine

not:

Unexpected
    ↓
Malware

Conclusion

Core Windows processes form a connected system rather than a collection of unrelated executables.

Starting with:

System (PID 4)

the process chain moves through:

smss.exe

into Windows session initialization:

wininit.exe

and then into important system functionality:

services.exe
lsass.exe

while service hosting involves:

svchost.exe

User-session activity eventually connects:

winlogon.exe
    ↓
userinit.exe
    ↓
explorer.exe

For SOC L1, the goal isn't to memorize every Windows internal detail.

The more important skill is learning to recognize normal process behavior and investigate deviations.

When you see a Windows process, think:

WHAT?
  ↓
WHERE?
  ↓
WHO?
  ↓
HOW?
  ↓
PARENT?
  ↓
HOW MANY?
  ↓
WHEN?
  ↓
CHILDREN?
  ↓
NETWORK?
  ↓
LOGS / EDR?

That process of reasoning turns a list of Windows executables into useful endpoint-investigation knowledge.

And ultimately, the core defender skill is simple:

Know what normal looks like so you can recognize what doesn't.