Origin text: Blue Team fundamentals Part Two: Windows Processes.
There is a lot of information to be gleaned from Windows processes. The thing with processes is that there are a lot of them, and it can seem massively overwhelming, However with a bit of patience and the aid of a book or three (which I will touch on at the end of this post) you can get really quite far under your own steam.
This obviously requires some form of logging of process trees in a multi host/network scenario, there are a good number of products out there that do this now, especially with buzzword bingo firing on all cylinders, if your endpoint product/agent declares itself ‘next gen’ it should do this. We however, will look at these processes from a single host perspective for the sake of this write-up. The rules and theories will be the same though.
First off we need to arm ourselves with ‘Process Explorer’, which is part of the Windows Sys Internals Suite which can be found at https://technet.microsoft.com/en-gb/sysinternals/bb842062
and when fired up looks a bit like this:
So, lets take a look shall we?
System/Idle
These two are special. Why? Well they are not technically full processes. They are not running a user-mode executable as they are both created by ntoskrnl.exe (NT OS Kernel), which as the name implies means it is running in kernel mode. More information on the difference between user mode and kernel mode can be found here:
Some key features of these two processes are:
- Neither should have a visible parent process
- In the case of the idle process it should be operating one thread per CPU as seen here on my quad core machine.
- The PID value for System is always 4:
- There should only ever be one instance of System:
What can we look for:
- If either process has a visible parent ID.
- If there are more idle threads than CPU’s on the host.
- If the PID for system is not 4.
- If you have multiple instances of System.
Session Manager Subsystem/SMSS.EXE
smss.exe is executed during the startup of the OS and is the first user-mode process to be started by the kernel. It starts both kernel and user modes of the Win32 subsystem. This includes win32k.sys (kernel-mode), winsrv.dll (user-mode), and csrss.exe (user-mode). Any other subsystems listed in the following required registry value are also started:
HKLM\System\CurrentControlSet\Control\Session Manager\SubSystems
Required is the value that lists which subsystems should be loaded at boot time.
Windows lists the file specification of the Windows subsystem and we can see it contains %SystemRoot%\system32\csrss.exe
Specifics of this process:
- It’s Parent will always be System
- It’s user will always be NT AUTHORITY\SYSTEM
- Runs from \systemroot\System32\smss.exe
- all of the above can be seen below:
- There should only ever be one instance SMSS.EXE running. This is actually very important because it is responsible for launching both WINLOGON.EXE, WININIT.EXE and CSRSS.EXE. Now you might be wondering why this is important? Well, after launching these SMSS.EXE exits and a new instance is started, meaning that when viewing either of these processes, they may have Parent PID (Process ID) attached but the process name should be unknown.
- The OS Session is started under Session 0
- The first user Session is started under session 1
What can we look for:
- Parent/User is not SYSTEM
- Seen running from outside of \%systemroot%\system32\
- Either winlogon, wininit or csrss having a parent process (at all).
- Unexpected subsystem registry entries.
Flying off on a tangent:
As we touched on Sessions I think it’s worth have a slightly more in depth look at them. If you launch WinObj.exe from sys internals (as admin) and browse to the /Sessions folder you will see something similar to this:
As we already said 0 is the OS session instance and 1 is the first user.
Taking a look at one of the OS session we can see a shared network drive:
Whilst taking a look at user session under WindowStations we see:
So what does this prove? Well preemptively jumping ahead and looking at explorer.exe and it’s associated handlers we can see:
This shows we can view the namespace instance for a specific process.
anyway…
Windows Logon Process/WINLOGON.EXE
- Does not have a parent process
- Runs as NT AUTHORITY\SYSTEM
- Runs out of \Windows\System32
- Can spawn child processes if alternate login devices are used such as card /biometric readers etc
- Secure Authentication Sequence/SAS (Ctrl+Alt+Delete) is handled by winlogon
- Loads Userinit from registry location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
which:
Specifies the programs that Winlogon runs when a user logs on. By default, Winlogon runs Userinit.exe, which runs logon scripts, reestablishes network connections, and then starts Explorer.exe, the Windows user interface.
https://technet.microsoft.com/en-gb/library/cc939862.aspx
- The registry entry for userinit should be userinit.exe, (The comma is intended). This can be appended with other locations and can be utilised by malware to run things at logon.
- The shell registry entry in the same location should be Explorer.exe (Windows Explorer). This can also be appended with other values allowing the running of malware at logon.
- As with SMSS.EXE, userinit.exe exits after it has run, meaning anything loaded from registry (explorer.exe, dodgy malwares) will not have a parent process. It also means userinit.exe will not be visible to you in Process Explorer.
What can we look for:
- Shell and Userinit registry entries with undesirable values.
- Having a parent process
- Not running as NT AUTHORITY\SYSTEM
- Runs out of a location that isn’t \Windows\System32
Explorer.exe / Windows Explorer
As Winlogon runs userinit which spawns explorer, let’s look at the explorer process next.
- We have already covered the fact that userinit.exe exits after execution meaning no parent process.
- Again as already covered, the registry entry lives under
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell
- The user will be the logged in account (that which was used to logon via the WINLOGON.EXE process).
- It runs out of \%Systemroot%\Explorer.exe
- Explorer spawns child processes
What can we look for:
- Not running out of system root.
- Assuming a genuine naming convention in use, running under context of an unrecognised user.
- Making any TCP/IP connections.
CSRSS.EXE / Client-Server Run
- Runs as NT AUTHORITY\SYSTEM
- Runs out of \%SystemRoot%\system32\csrss.exe
- There is an instance loaded for each session, which loads three DLLs; basesrv.dll, winsrv.dll and csrsrv.dll. These dll’s support the creation and deletion of threads and processes (amongst other stuff).
- It’s a session 0 process
What can we look for:
- Running outside \system32
- Running as non SYSTEM user
WININIT.EXE / Windows Initialisation Process
- Runs as NT AUTHORITY\SYSTEM
- Runs from %SystemRoot%\system32\wininit.exe
- Creates a Window station (Winsta0) and two desktops (Winlogon and Default) for processes to run on in session 0
- Creates Services.exe
- Starts Lsass.exe
- Starts Lsm.exe
- Always a child of SMSS.EXE (We know this won’t have a Parent process due to smss termination after running)
- Creates %windir%\temp
- Runs within session 0
What can we look for:
- Running outside system32
- Running as non SYSTEM user
- Child of an identifiable process.
SERVICES.EXE — Service Control Manager
- Runs as NT AUTHORITY\SYSTEM
- Run from %SystemRoot%\System32\services.exe
- Child to WININIT.EXE
- Spawns Multiple services which can be seen in registry location:
SYSTEM\CurrentControlSet\Services
- Run from %SystemRoot%\system32\services.exe
- Runs as NT AUTHORITY\SYSTEM
- The process should spawn many generic svchost.exe which are responsible for running the services.
What can we look for:
- Running outside \system32
- Running as non SYSTEM user
- Child of a process that is not WININIT.EXE
SVCHOST.EXE / Service Hosting Process
- There will be multiple instances of SVCHOST running as per the following screen grabs:
- Runs from %SystemRoot%\System32\svchost.exe
- Can run as any of the following accounts: NT AUTHORITY\SYSTEM, LOCAL SERVICE, or NETWORK SERVICE
- Always the child process of services.exe
- It will always follow the command line convention of “svchost.exe -k [name]”
- -k [name] values should exist within the following registry location:
Software\Microsoft\Windows NT\CurrentVersion\Svchost
What can we look for:
- Processes not running under NT AUTHORITY\SYSTEM, LOCAL SERVICE, or NETWORK SERVICE
- Processes not using the -k [name] convention
- Parent not services.exe
- Running from outside \system32
LSASS.EXE / Local Security Authority
- Run as NT AUTHORITY\SYSTEM
- Run from %SystemRoot%\System32\lsass.exe
- Spawned by WININIT.EXE
- There should never be more than one LSASS.EXE process.
- It should never spawn any child processes.
- Runs within session 0
What can we look for:
- Not running as SYSTEM.
- Due to the nature of LSASS it is a high value target for malware and frequently spoofed.
- lsass not running out of %SystemRoot%\System32\ is highly likely to be malicious.
- Anything that looks like it has been spawned by lsass is also likely malicious. In most cases this is a malware author using clever font techniques to obfuscate the file; Isass vs lsass for example.
LSM.EXE / Load Session Manager Service
- Runs as NT AUTHORITY\SYSTEM
- Runs from %systemroot%\System32\lsm.exe
- Parent Process should always be wininit.exe
- The Local Session Manager manages (← shocking) the state of terminal server sessions on the local machine. It sends requests to Smss through the ALPC port SmSsWinStationApiPort to start new sessions.
- LSM.EXE should never spawn any child processes
- Runs within session 0
What can we look for:
- LSM spawning any child process
- Running outside system32
- Not running as SYSTEM
- Parent process no wininit.exe