Jump to content











Photo

Does Winpe10XPE really boots as TrustedInstaller ?


  • Please log in to reply
8 replies to this topic

#1 noel

noel

    Frequent Member

  • Advanced user
  • 178 posts
  • Location:nantes
  •  
    France

Posted 15 August 2022 - 03:13 PM

Hi,
My goal is to better understand the Winpe generation of the Win10XPE project.
I do not want to polemicize or denigrate.
But I understand English very poorly and a clarification would be useful to me.

 

i read this here : http://reboot.pro/in...showtopic=22646

 

If booting from a Win10XPE, first thing I see in the screen is a Message asking if I want to boot as ADMIN, by the way only way to make TeamViewer run from a PE.
Then if the answer is YES the ADMIN account is created on the fly and the user is ADMIN.
If no answer in 5 seconds or the answer is NO, then the PE boots as Trusted Installer (TI), (even if the name that appears is System), having all privileges of (TI), we avoid all those new artificial (safety) restrictions to edit certain sections of a remote Registry, or to off-line open files or folders that were created by a different user, etc.
So this PE doesn't have the limited access of System, it has the higher access that can be got wich is TI.
 

 

 

Because I want to understand how Win10XPE does this "PE boots as Trusted Installer", I am building a Winp10XPE based on W11 21h1 (version 10.0.22000.194). But it doesn't matter the version.
I start this winpe and I see the dialog box allowing the choice of the session. I don't select "Admin".

Then I went through the "login" process.

The start point is the key : "System\setup\cmdline = Pecmd.exe Main %Windor%\system32\PecmdAdmin.ini"
I see in the PecmdAdmin file.ini the text: :
 

MESS switch to Administrator? @switch to Administrator #YN *1000 $N
FIND $%YESNO%=YES,CALL ADMIN
FIND $%YESNO%=NO,LOAD %windor%\system32\Pecmd.ini

 

 

This lines open the MessageBox and get the choice between "System" or "ADM" session.

 

After that, i made this change : "cmdline = CMD.EXE".
I tryed to analyse or understand the security context.
I haven't seen a single thing different from an ADK-generated Winpe. 

 

The process loading observed with Winbdg or Procmon shows this:
Winlogon reads the "cmdline" key.

In the case of "cmdline=pecmd.exe ...", it is Pecmd.exe that proposes the choice of the session to be opened.
And we find the classic sequence implemented ar Win10XPE (with tsdiscon.exe followed by autologon !).
If cmdline is empty, then winlogon will trigger the display of the logon window ( case of normal windows but i nerver test in a winpe context).

 

After that, I looked in the registry at some keys known and forbidden to the System account like:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkSetup2\BindPaths
And in Winpe10XPE , the "everyone" account has full control on this key.

So, my idea : during the builting phase, in the registry of Winpe, all ACL for "TrustedInstaller" are modify and the ACE "everyone = full control" is added to it.

 

I've looked in a lot of files and I can't see where and when Winpe starts as  "TrustedInstaller".

 

A little note about the account "Administrator" : "PreCreateAdminProfile.bat" does not exist in the generated winpe10xpe but exists in the builder files and contains:

 

:: Add System privileges to Administrator. Start ProfSvc service and Creates Administrator profile with the corresponding registry
:: The administrator has only 16 permissions with CreateProfile, 8 less than the normal system. LSAgetRights adds them
LSAgetRights.exe -c  -u Administrator

 

The "Administrator" account (i speack about the builtin account which is known by its SID "...500") is present in the SAM of WinPe and WinpRE.
So it is not created by WinpeXPE.
This account is renamed  (if needed) by "x:\windows\security\templates\unattend.inf" .
But yes, its profile directory is created by WinpeXPE during the build process.

 

A final note about Rights(permission) and ACLs:
an account has Rights that may not be enabled (a simple PS script can enable them)
an object such as a file, key, etc., has ACLs that define which account can manipulate them.

 

So, can anyone tell me how Winpe (from Win10XPE) can boot as Trusted Installer or can someone explain to me what is different from an ADK-generated winpe?

Noel



#2 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 August 2022 - 11:40 PM

Hi noel, hope you are fine.

 

Does Winpe10XPE really boots as TrustedInstaller?

 

I can't answer how, as there is nothing about this in any of the Scripts, including the hiden, (Level=0), but as you already confirmed it is capable to make things that can't be made by NTAUTORITY: SYSTEM account.

 

And as the next higher level account is Trusted Installer (TI), the logical assumption is it is running as TI.

 

But it doesn't matter if it is really TI, or if SYSTEM account just got the same rights as TI by means of a trick.

The fact is that it is capable to make things that belong to TI rights.

 

Your theory about the ACLs doesn't sound bad.  But it needs to be proven.

 

About your comment:

 

A final note about Rights(permission) and ACLs:
an account has Rights that may not be enabled (a simple PS script can enable them)

 

I will appreciate a lot if you give me more info, as that may be useful in certain scenarios.

 

See you my friend, it is always a pleaseure to talk with you.

 

alacran



#3 noel

noel

    Frequent Member

  • Advanced user
  • 178 posts
  • Location:nantes
  •  
    France

Posted 18 August 2022 - 10:49 AM

Hi Alacran,

Yes, i'm fine, even with too much rain and sun, fires in wood and hot weather. My old bones no longer know if they should be happy or not.

Thank you for this reply and for the other content that i received in my email box.

 

Miracles do not exist in computer science and everything has an explanation.
Too bad I don't know it (about  "boot as TI") for WinpeXPE.

 

When I worked with Wimb to add printer support in their tool, he downloaded all my PS scripts, with the one to add privileges to an account. All my scripts are available on the "enemy" site in the "MicroWinpeBuilder" section. If you can't download them, I'll give you another link.

 

notes about ACL and Right :

-Even if an account (A) has all the rights (the maximum privileges), it will not be able to manipulate the file of an ordinary user account (which is the owner) if an ACL on this file prohibits account (A). This is also true if  A = IT account.
- And It is because the directories hadled by TI (of which TI is the owner) have ACLs that limit the "system" account, that this "system" account cannot modify them.

 

note about the rights of system: https://docs.microso...lsystem-account

i will try to write a PS script to read the rights for TI. (something like whomai.exe /priv)

 

 

See you soon, my friend, and has a good time.



#4 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 19 August 2022 - 12:14 PM

Hi, noel

 

The content you recived by eMail was my original post, that a few hours later seemed to me too long, and with an excess of details, and I decided to fully edit the post, and just express the idea in plain words, to make things easier for you, that have mentioned several times you need to first translate to your lang, as your English is not the best.

 

I went to the forum you mentioned in your last post, I'm (or was) alacran user there too, but haven't gone to that forum since long time ago, I don't know what hapenned but I wasn't able to Sign in, but anyway I found the "MicroWinpeBuilder" section, and read almost all of your interesting topics, but it seemed to me the Power Shell script to enable additional rights to an account is burried into one of your several links, and to be honest, it will be a lot to read to find it.  Don't you have it available in your notes to have it handy when required?

 

 

notes about ACL and Right :

-Even if an account (A) has all the rights (the maximum privileges), it will not be able to manipulate the file of an ordinary user account (which is the owner) if an ACL on this file prohibits account (A). This is also true if  A = IT account.
- And It is because the directories hadled by TI (of which TI is the owner) have ACLs that limit the "system" account, that this "system" account cannot modify them.

 

Yes, no doubt, I deduced it some time ago, I usually delete the System Volume Information folder in all my VHD drives (except if the OS is going to be  installed in Wimboot mode as into that folder is the info of the associated WIM) , take it as a way to avoid wasteing space, because this folder sometimes growsup very easily, and I replace it with a 0 bytes file with same name only redable and hidden, usually I make this booting from Win10XPE, or a VHD, and I run a command as TI.

 

Well, some time ago, after having made a new version of the Win10XPE, and of all my VHDs, I tryed to delete the file, using same procedure but with the premade command I have to delete the file (that worked very fine when made), I tryed several times from WinPE and VHDs, always running the command as TI, and there was no way to delete it,

 

Then my deduction was the WinPE, and the VHDs were builded using a newer diferent version of Win10, also the third party program used to run the command as TI is a new version, then the original TI owner of the file was not the same.  I had to format the partition/drive to get rid of the file.

 

 

I read your link about the SYSTEM rights, I had a general idea, but the article has certain details I didn't knew.  Thanks for the link.

 

alacran



#5 noel

noel

    Frequent Member

  • Advanced user
  • 178 posts
  • Location:nantes
  •  
    France

Posted 19 August 2022 - 08:21 PM

hi Alacran,

I try to upload enablePrivilege.ps1...I hope it can help ....

 

Please, first, read the script and you see the part PS, the part C#.

Refere to MS doc for the API

 

Because nobody needs to use it, and because i'm the only one that use it, i don't write comment in this file. And i modify it when i need, on the fly....

You can modify it for your convenience..

 

In a PS console, load/execute this file : the function "enable-privilege" becomes active.

in this PS console, use it like this for sample to add 3 privileges for the current process (this intance of powershell.exe):

enable-privilege SeTakeOwnershipPrivilege
enable-privilege SeRestorePrivilege
enable-privilege SeBackupPrivilege
# Check that return = true !

The privilege is added to the current process (my choice in this script) but you can easily change the target in the script code

 

Noel

 

PS : About "I don't know what hapenned but I wasn't able to Sign in," : i think the 5 questions used for control (like captcha) have a crazy logic and i signed in but i don't know how and i don't remember the good responses.

Attached Files


  • alacran likes this

#6 noel

noel

    Frequent Member

  • Advanced user
  • 178 posts
  • Location:nantes
  •  
    France

Posted 09 September 2022 - 09:47 PM

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. :D

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 ! :lol:

I join files. You need to compile it. If OK and if you need help, i can explain how to use it.

 

a picture....Attached File  ti.png   454.91KB   0 downloads

Attached Files


  • alacran likes this

#7 noel

noel

    Frequent Member

  • Advanced user
  • 178 posts
  • Location:nantes
  •  
    France

Posted 10 September 2022 - 10:53 AM

hi,

Bad news for me, my code works well in normal w10 and w11 but not in my WINPE  :angry:



#8 noel

noel

    Frequent Member

  • Advanced user
  • 178 posts
  • Location:nantes
  •  
    France

Posted 13 September 2022 - 08:49 PM

Now I know why my program didn't work in Winpe.  :lol: 
I had hardcoded the letter "C:" in the paths of the program to be launched:
RtlInitUnicodeString(&Params, (PWSTR)L""C:WINDOWSSYSTEM32cmd.exe" /k echo Hello world!");
And "C:" is not the right letter for Winpe, of course.

 

But before I found this detail, I had done a Session of Windbg to analyze the PS commands of tiraniddo.
Contrary to what I thought, tiraniddo does not use the NTCreateUserProcess API in this "TI" context.
He simply uses the CreateProcess API.
But what I didn't know is that it is possible to define the "parent handle" in the STARTUPINFOEX stucture
Although the tiraniddo page never refers to this NTCreateUserProcess API, I had imagined that he would use it.
Another blunder on my part. :angry:

So I wrote a second program to check using the CreateProcess API.

My 2 programs work now in windows 10/11 and in Winpe 10/11

There is, however, a difference.
In Both Windows and Winpe, with the parent "TrustedIsntaller.exe", the program using the NTCreateUserProcess API displays a message:
"There are not enough memory resources available to process this command."
But the program works properly. I assume that a parameter of the structures used by this API is not properly initialized.
I stop my research there.

 

What I take away from all this:
1 - Winpe of the ADK starts with the user "System" in session 1.
Note: I prefer to say "winpe starts..." because I don't think it's a real logon like for the "ADM" session in session 2
2 - the user "ADM" exists "naturally" and "natively" in the Sam of WinPe/WinRE. It is not created "on the fly". It can log on (session 2 logically). It is the TsDiscon.exe software that initializes the "ADM" logon mechanism. Then the so-called "autologon" mechanism will do the rest.
3 - In a normal Windows, it is possible to launch a CMD console by inheriting the TrustedInstaller SID.

 

Note: My 2 programs allow it if they are launched from an "ADM" console because you need rights to open the Handle of "TrustedInstaller.exe" (a prioi, the same as to start the service).

 

Now, going back to the very beginning of my philosophical questioning, the sentence that surprised me was:
"So this PE doesn't have the limited access of System, it has the higher access that can be got wich is TI."
I simply misinterpreted that sentence.

Then I wanted to know how the Win10XPE project could achieve this "magic thing".
That's why I looked for how to add this SID.
And I learned that this was possible by launching a process whose parent would be TrustedInstalle.exe.
Writing the programs taught me a lot of things and I don't regret it.

Now, if I had to write in French the sentence quoted above, I would now write:
The "system" account, which is the user of session 1, has from the outset and "by design" the same resource access rights (for ACLs) as the security group (SID) named TrustedInstaller.

 

Note:
The TrustedInstaller SID cannot have privileges because it is not a real user.
The TrustedInstaller SID cannot impact anything other than ACLs. It does not exist outside of ACLs.
To differentiate between Rights and Privileges according to MS terminology, test the following 2 commands:
whoami /priv
whoami /groups

 

The last word:
Why would you want to add the TrustedInstaller SID to Winpe's "System" account?
With my Winpe10 and Winpe11, built with my scripts and without using WinBuilder or a project like winpe10XPE, I see the following:
In session 1, that of the "system" account, I open a CMD console and I launch the command "Whoami /groups"
The display brings up the TrustedInstaller SID  :lol: 
It is true that this is very useful in a windows 10/11 for an "ADM"

 

A lot of philosophy in this post. Knowledge increases when it is shared

Attached Files


  • alacran likes this

#9 noel

noel

    Frequent Member

  • Advanced user
  • 178 posts
  • Location:nantes
  •  
    France

Posted 14 September 2022 - 10:36 AM

hi alacan,

 

I wrote a Ps script to launch a CMD with the TI SID.

As you can see, it's not too complex.

 

And I like to be autonomous, to use my own tools.
So I only offer scripts whose content everyone can read and thus determine the potential risks.

 

have a good day with sun, my friend alacran

Attached Files


  • alacran likes this




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users