List of Hidden / Virtual Windows User Accounts

Question

I’m trying to find a way to get a comprehensive list of user accounts on a Windows 7 system, including hidden ones. The User Accounts dialog (>control userpasswords2) only shows the normal user accounts, and even the Local User and Groups editor only shows normal user accounts and standard hidden/disabled ones like Administrator and Guest. The Select Users or Groups dialog has a Find Now button which which combines users and groups, but alas, it has the same contents as the LUG.

I’m looking for a more comprehensive list that includes “super-hidden” / virtual user accounts like TrustedInstaller (or to be more accurate, NT Service\TrustedInstaller—notice the different “domain”).

I checked HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList, but the SpecialAccounts key does not exist.

I also checked HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList, and while it does have the SystemProfile, LocalService, and NetworkService accounts listed, it does not have others (like TrustedInstaller and its ilk).

TrustedInstaller specifically is a little confusing because it is a user, a service, and an executable file. I am using it as an example because it is “super hidden” in that it does not seem to be listed in any sort of user list. (As an experiment, I tried searching the whole registry for “trustedinstaller” to see if I could find a place where it is listed as a user, but found none.)

To be clear, what I am looking for is a list of all accounts that can be used in a user input-field such as in permissions dialogs or as a runas argument.

Answer 1

From Windows Vista on, services are treated like users. That is, each a SID is assigned to every service. This is not specific to TrustedInstaller service. You can view the SID assigned to any service using the sc showsid command:

USAGE: sc showsid [name]

DESCRIPTION: Displays the service SID string corresponding to an arbitrary name. The name can be that of an existing or non-existent service.

Note that there is no need for the service to exist on the system. Examples:

C:\> sc showsid TrustedInstaller
NAME: TrustedInstaller
SERVICE SID: S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464

or, for the service Windows Management Instrumentation (Winmgmt):

C:\> sc showsid Winmgmt
NAME: Winmgmt
SERVICE SID: S-1-5-80-3750560858-172214265-3889451188-1914796615-4100997547

and, finally, for a fake service:

C:\> sc showsid FakeService
NAME: FakeService
SERVICE SID: S-1-5-80-3664595232-2741676599-416037805-3299632516-2952235698

Note that all SIDs start with S-1-5-80, where 80 is assigned to SECURITY_SERVICE_ID_BASE_RID sub-authority. Moreover, this assignment is deterministic: No RIDs are used, and the SID will be the same across all systems (see the references at the end of this post for more information).

As an example, I will assign the NT Service\Winmgmt service, write permission to some file:

Windows underlines the name Winmgmt, confirming that it's a valid identity:

Now, click OK, and then assign the write permission:

This confirms that any service name can be used as a user identity. Therefore, I wouldn't call them "supper-hidden" accounts :D

For more information, please read the following articles:

• New ACLs Improve Security in Windows Vista
• WS2008: Windows Service Hardening
• SID Components
• Well-known SIDs
• Well-known security identifiers in Windows operating systems

Answer 2

This is because TrustedInstaller is a service and not a "user" object. With Vista, Services are now security principals and can be assigned permissions.

http://technet.microsoft.com/en-us/magazine/2007.06.acl.aspx

Answer 3

1. Go to any file on your hard drive, right-click, and select properties.

2. Go to the security tab and click Edit

   

3. Click Add...

4. Click Advanced...

   

5. Click Object Types... and uncheck Groups, then click OK

   

6. Click Find Now. This will list all regular users and built-in system users ("built in security principles", as Windows calls them).

   

Note that not all accounts that appear on this page can be used in a Run-As command, though they can all be used in a permissions dialog.