Latin1 was the early default character set for encoding documents delivered via HTTP for MIME types beginning with /text . Today, only around only 1.1% of websites on the internet use the encoding, along with some older appplications. However, it is still the most popular single-byte character encoding scheme in use today. A funny thing about Latin1 encoding is that it maps every byte from 0 to 255 to a valid character. This means that literally any sequence of bytes can be interpreted as a valid string. The main drawback is that it only supports characters from Western European languages. The same is not true for UTF8. Unlike Latin1, UTF8 supports a vastly broader range of characters from different languages and scripts. But as a consequence, not every byte sequence is valid. This fact is due to UTF8's added complexity, using multi-byte sequences for characters beyond the general ASCII range. This is also why you can't just throw any sequence of bytes at it and e...
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.
Comments
Post a Comment