Life of a Windows Process

In a previous post, I covered a bit about how Windows Processes are initialized. But how does process creation work in Windows? Let's explore a bit further into Windows processes.

Paths to Process Creation

The Windows API provides several paths to process creation. Perhaps the most straightforward of these is the CreateProcess call, which creates a process that inherits the process token of the parent process. But there are also several other calls to create processes. For example, if a user desires to spawn a process with the token of a different user, the Windows API provides us with the CreateProcessAsUser function.

We also have additional process creation functions like CreateProcessWithTokenW and CreateProcessWithLogonW. These reside within a DLL which I've not mentioned yet - advapi32.dll. These API calls enable process creation using specific tokens, such as tokens associated with other users.

So, to recap: in the Windows user mode space, we have dynamic libraries such as NtDll.Dll, Kernel32.dll, Advapi32.dll, and SecLogon.Dll.

Kernel32.dll contains calls to CreateProcess, CreateProcessAsUser, and CreateProcessInternal. While Advapi32.dll contains CreateProcessWithLogonW and CreateProcessWithTokenW.

And calls to Advapi32.dll talk to SecLogon.dll. SecLogon.dll lives in a SvcHost.exe instance. And within SecLogon.dll lives the SlrCreateProcessWithLogon function. So, when process creation happens, SecLogon.dll talks to Kernel32.dll, calling CreateProcessAsUser, which in turn talks to NtDll.dll and context switches from user mode to kernel mode, finally calling NtCreateUserProcess within the context of the Windows Kernel.

According to the Windows Security encyclopedia and various documentation on the internet, SecLogon.dll works something like like this:

The Secondary Logon (seclogon) service enables processes to be started under alternate credentials. This allows a user to create processes in the context of different security principals. A common use of this service is by administrators who may log on as restricted users but must have administrative privileges to run a specific application. They can use a secondary logon to temporarily run such applications. If the service is disabled, this type of logon access is unavailable and calls to the CreateProcessWithLogonW API fail. This service starts when a program or application is started by using the Run as different user option in the extended context menu (which can be opened by holding down the shift key when you right-click an item). This service is installed by default and its startup type is Manual. When the Secondary Logon service is started in its default configuration, it logs on by using the Local System account. This service is not dependent on any other system service, nor is any service dependent on it.