About TrustedInstaller (TI). And because I prefer to understand the details
I must first mention the tiraniddo sites from which I get the information about IT.
https://www.tiranidd...dinstaller.html
-> a superb description of TI and an extraordinary PS module !
https://www.tiranidd...dinstaller.html
-> 2 years later, a trick with a Task from the Schedule service
https://www.powershe...tManager/1.1.33
-> The ready-to-use PS package: 2 files for the PS module and dll/exe that execute the commands
-> you have to download it by clicking on .... and deposit it in the ps module directory
https://github.com/g...-analysis-tools
-> this is the site that contains all the sources in this package. You also have to download it to know their code C#
Links to read to try to write a program :
an educational site and very useful information about "implementing PPID Spoofing"
https://captmeelo.co...serprocess.html
its c/c++ program is well documented
https://github.com/c...eateUserProcess
another C/C+ program+
https://github.com/f...b/main/main.cpp
a very weird C# program
https://github.com/G...teUserProcess-1
a presentation of "Windows Process Creation APIs" by tiraniddo
https://webamooz.com...ffsecmag/94.pdf
the "Process/Thread" chapter of the Windows Internals 5th edition book
https://www.microsof...233328&seqNum=3
Another useful link :
https://processhacke..._8h_source.html
The following link describes several tools to manipulate IT (there are others most certainly but I am not very interested in these tools):
https://www.winhelpo...try-keys-files/
Here I can only summarize the first link. But writing this summary allows me to better understand what IT is.
And I hope that others will have the curiosity to visit the links of "www.tiraniddo.dev".
1 - The first observations
In W10 21H2 (19044-1889), the security properties of "C:\Windows\System32\ntoskrnl.exe"
provide this information :
PS C:\WINDOWS\system32> $acl = get-acl "C:\Windows\System32\ntoskrnl.exe"
PS C:\WINDOWS\system32> $acl.Access
FileSystemRights : ReadAndExecute, Synchronize <<<<<<<<<<<<<<<---------- !!!!!!!!
AccessControlType : Allow
IdentityReference : AUTORITE NT\Système <<<<<<<<<<<<<<<---------- !!!!!!!!
IsInherited : False
InheritanceFlags : None
PropagationFlags : None
...
FileSystemRights : FullControl <<<<<<<<<<<<<<<---------- !!!!!!!!
AccessControlType : Allow
IdentityReference : NT SERVICE\TrustedInstaller <<<<<<<<<<<<<<<---------- !!!!!!!!
IsInherited : False
InheritanceFlags : None
PropagationFlags : None
...
PS C:\WINDOWS\system32>$acl.Owner
-> NT SERVICE\TrustedInstaller
TI is referred to here by its full name : "NT SERVICE\TrustedInstaller"
Note the difference of the first part of the name with the user's name "AUTORITE NT\System" :
"NT SERVICE" vs "AUTORITE NT"
One might think (as I believed for a long time) that TI is a user. Error!
The first link indicates this which I copy here some important lines :
"
However, if you look in the Local Users and Groups application you won’t find a TI user or group. This blog post is about what the TI group really is, and more importantly, with the aid of PowerShell and the NtObjectManager module, how you can be TI to do whatever you wanted to do.
"
TI is therefore not a user!
It is therefore impossible to log in with TI in Winpe!
This is the answer to the question asked in the title of this post.
2 - Now, what is TI?
You can say it's not important. You can, indeed. But I prefer to know what I'm using.
The first link says :
"
We can see in the IdentityReference member that we’ve got the TI group, and it’s prefixed with the domain “NT SERVICE”. Therefore, this is a Windows Service SID. This is a feature added in Vista to allow each running service to have groups which they can use for access checks, without the overhead of adding individual real groups to the local system.
"
A link to "Windows Service SID" :
https://docs.microso...rectedfrom=MSDN
"
The SCM adds the specified service SIDs to the process token, plus the following additional SIDs:
...
This enables developers to control access to the objects a service uses, instead of relying on the use of the LocalSystem account to obtain access.
Use the LookupAccountName and LookupAccountSid functions to convert between a service name and a service SID.
The account name is of the following form:
NT SERVICE\SvcName
"
As I understand it, it is the SCM (services.exe) that creates the SID of the service.
This SID is used to manage the security of resources used by the service through ACLs.
Here are some tests with the SC.EXE command of MS
Caution: do not confuse the "TrustedInstaller" service and the "TrustedInstaller" SID assigned to the service
PS C:\WINDOWS\system32> sc.exe qc TrustedInstaller
[SC] QueryServiceConfig réussite(s)
SERVICE_NAME: TrustedInstaller
TYPE : 10 WIN32_OWN_PROCESS
START_TYPE : 3 DEMAND_START
ERROR_CONTROL : 1 NORMAL
BINARY_PATH_NAME : C:\WINDOWS\servicing\TrustedInstaller.exe
LOAD_ORDER_GROUP : ProfSvc_Group
TAG : 0
DISPLAY_NAME : Programme d’installation pour les modules Windows
DEPENDENCIES :
SERVICE_START_NAME : localSystem >>>>>>>>>>>>>>>>>>> This is the user !
In services.mmc, the properties of the TrustedInstaller service confirm the service user:
"Log in as = Local System Account"
PS C:\WINDOWS\system32> sc.exe QsidType TrustedInstaller
[SC] QueryServiceConfig2 réussite(s)
SERVICE_NAME: TrustedInstaller ----------> the name associated with the SID of the service or the name of the service?
SERVICE_SID_TYPE: UNRESTRICTED --------> ? the "Windows Service SID" link gives the format and characteristics of the groups used by the services.
PS C:\WINDOWS\system32> sc.exe showsid TrustedInstaller
NOM : TrustedInstaller <<<<<<<<<<------ The name associated with the SID of the service. You might think it's a user!!!
SID DE SERVICE : S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 <<<<<<<<<<------- it is the SID string calculated for TI !!!
ÉTAT : actif
Note: The parameter of the ShowSID command is an arbitrary name and thus shows that the returned string is the result of a calculation and not the consultation of an object in the system.
An example :
C:\WINDOWS\system32>sc.exe showsid TestTrustedInstallerTest
NOM : TestTrustedInstallerTest
SID DE SERVICE : S-1-5-80-2786083019-3050900184-3138030285-3684065069-471581235
STATUS: Inactive
Note : read the SC.EXE command help.
What to remember:
the service name is used to define the name of the group (and calculate the SID) used in ACLs to secure a service's resources
This group is not a user group.
"[NT SERVICE\TrustedInstaller] is not a real group, but created synthetically" (see a few lines later)
Who creates this group and when? I guess it's SCM that does this work systematically when starting the service.
3 - Becoming TrustedInstaller : There is no miracle and everything has an explanation
"
You might assume you could just add your current user to the TI group and that’s that? Unfortunately the LSASS APIs such as NetLocalGroupAddMembers takes a group name not a SID, and passing “NT SERVICE\TrustedInstaller” doesn’t work, as it’s not a real group, but created synthetically.
"
3-1 The simple method :
sc config TrustedInstaller binPath= "cmd.exe /C del path\to\file"
To test with Winpe !
Disadvantage: no interaction with the console because the services are active in session 0 and winpe uses session 1 to interact with the user "system".
3-2 "CreateProcess" method:
The first pitfall : "the token we’ve got only has TOKEN_QUERY access."
PS C:\WINDOWS\system32> Set-NtTokenPrivilege SeDEbugPrivilege -------------> do not forget this privilege
PS C:\WINDOWS\system32> $p = Get-NtProcess -Name trustedinstaller.exe
PS C:\WINDOWS\system32> $t = $p.openToken()
PS C:\WINDOWS\system32> $t.groups | ? {$_.Sid.name -match "trustedinstaller"}
Name Attributes
---- ----------
NT SERVICE\TrustedInstaller EnabledByDefault, Enabled, Owner
Is it possible to use this token to create another process in the current user's session?
"
Checking the security descriptor of the token using Process Hacker (we don’t even have READ_CONTROL to read it from PS) explains the reason why we’ve got such limited access.
"
NO because this token $t has ACLs that prohibit it from being duplicated. And it even seems impossible to read these characteristics in this PS console.
Verification proposed by Tiraniddo :
PS C:\WINDOWS\system32> $proc = New-Win32Process cmd.exe -creationFlags NewConsole -token $t
Exception when calling « CreateProcess » with "1" argument(s) : « Access denied »
Au caractère C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\ntobjectmanager\NtObjectManager.psm1:16926 : 5
+ $p = [NtApiDotNet.Win32.Win32Process]::CreateProcess($config)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: ( [], MethodInvocationException
+ FullyQualifiedErrorId : SafeWin32Exception
To check also in Winpe!
3-3 the tiraniddo method
After a complex explanation around the UAC, Tiraniddo points out that one can create a process using the handle of the TrustedInstaller process and not its Token.
PS C:\WINDOWS\system32> $proc = New-Win32Process cmd.exe -creationFlags NewConsole -ParentProcess $p
--> And the CMD console opens!
But tiraniddo does not give much explanation, nor the API used in this case!
Digging through the files, I think I understood that he uses the NtCreateUserProcess API
3-4 impersonation : to be seen later !
4 - my C++ program: I finally managed to compile the piece of code that suits me using the NtCreateUserProcess API.
It launches a CMD.exe with the SID of TI. And it works !
I join files. You need to compile it. If OK and if you need help, i can explain how to use it.
a picture....
ti.png 454.91KB
0 downloads