Auditing permissions of an admin account protected with UAC

Background UAC info from http://technet.microsoft.com/en-us/library/cc772207(v=ws.10).aspx:

So how can we audit the permissions of the filtered access token of an admin account protected with UAC? (i.e. how can we audit the permissions of what an admin account protected with UAC can do when it's not elevated?)

Here is a method that I figured out:

As an example, let's suppose we want to audit what a UAC-protected admin account named BrianAdmin can write to in C:\Windows when it's not elevated.

1. You might want to create a system backup in case this method causes any problems.
2. Log into a different admin account than BrianAdmin. Create one if necessary.
3. Go into the Control Panel User Accounts applet. Demote account BrianAdmin to a standard user account.
4. In an elevated command prompt, go to the folder where AccessChk is located.
5. Type accesschk -w -s "BrianAdmin" "c:\windows" . Note the results.
6. Go into the Control Panel User Accounts applet. Change account BrianAdmin back to an administrator account.

Does anyone know of an alternate method to do this? Has anyone seen (or can find) a similar discussion anywhere else?

 

I'm not sure if it's relevant to your post, but it looks like you want to - in a nutshell - allow BrianAdmin "write" permissions to C:\Windows? All I've ever done in Win7 is used the security tab to set permissions from my admin account, usually under "special permissions" whenever I want to either restrict permissions or relax permissions to a path for a selected user account.

 

No, I was trying to audit where in C:\Windows BrianAdmin (a UAC-protected admin account) can write to when not elevated, for the same reason that one might audit a non-admin account - in combination with usage of AppLocker (or Software Restriction Policies, or whatever), to try to guarantee that wherever a standard user account (or in this case, a UAC-protected admin account) can write to, it can't execute from, and wherever a standard user account (or in this case, a UAC-protected admin account) can execute from, it can't write to. I actually use a standard account for my everyday account, so I have less of a need for auditing my UAC-protected admin account, but I thought those of you who use a UAC-protected admin account as your everyday account might appreciate it.

One can periodically (especially after installation of software) audit write permissions of key areas with a batch file like this (run it from an elevated command prompt for most thorough results):

echo C:\Program Files (x86) > "ReportFileAndPathToWriteTo"
"C:\Program Files (x86)\Sysinternals Suite\accesschk.exe" -w -s "AccountToAudit" "C:\Program Files (x86)" >> "ReportFileAndPathToWriteTo"
echo C:\Program Files >> "ReportFileAndPathToWriteTo"
"C:\Program Files (x86)\Sysinternals Suite\accesschk.exe" -w -s "AccountToAudit" "C:\Program Files" >> "ReportFileAndPathToWriteTo"
echo C:\Windows >> "ReportFileAndPathToWriteTo"
"C:\Program Files (x86)\Sysinternals Suite\accesschk.exe" -w -s "AccountToAudit" "C:\Windows" >> "ReportFileAndPathToWriteTo"

My AppLocker ruleset is still quite similar to https://www.wilderssecurity.com/showpost.php?p=1679077&postcount=7.

 

Oh okay. I thought that could still be controlled by permissions even for a protected admin account?? Like you, I also run normally form a standard account, although for several months I've been running primarily Linux so I confess to getting rusty on Windows

 

You can do so. If you want to set permissions for a specific UAC-protected admin account, whether it's elevated or not, specify that specific UAC-protected admin account when setting permissions. If you want to set permissions for only when elevated, then specify the Administrators group when setting permissions. (Kinda tricky, no?)

The first post here is about how to audit the write permissions for a UAC-protected admin account, not how to set them.

 

Got it, thanks! Yes it does seem tricky

 

You're welcome .

A few days ago I discovered, quite by accident, that a few permissions were weak in my UAC-protected admin account. Afterwards, I checked the permissions for the files in question, and they were fine. Turned out that my UAC-protected admin account was set as the owner for those files (doh!) - changed owner to Administrators group to fix it.

 

I guess that's Windows doing its thing in the background, determined by what's built-in to Windows but not necessarily the right thing.?

 

Frankly it could have been - and probably was - my fault. The files in question are some DLLs used by LastPass, a Firefox extension. I have AppLocker path rules to allow them to run. I also have them specified in my accesschk batch file to check for permissions weaknesses for my standard user account. I had thought the permissions that I custom-made for those LastPass DLL files would have also protected them from writing in my UAC-protected admin when it's not elevated. To my surprise though, I was able to modify (delete in my case) those LastPass DLL files in my UAC-protected admin account with my file browser (Q-Dir) when it wasn't elevated. These permissions weaknesses would have been caught by accesschk if I had done auditing for my UAC-protected admin account using the technique in the first post. (I don't use Firefox often in my UAC-protected admin account, but I do once in awhile.)

I haven't audited my UAC-protected admin account yet, but I will today. I'll post my results here if I remember.

 

I've done it now on one computer - very interesting results! I found two additional folders within C:\Windows where my UAC-protected admin account can write to that I didn't know about before. My AppLocker ruleset mentioned in post #3 will have to be updated based upon these results.

If anybody audits your own UAC-protected admin account, can you please tell me (either here or via PM) which folders in \windows beyond these 15 folders have write permissions on your system (using the technique in post #1):

c:\windows\debug\WIA\*
c:\windows\PCHEALTH\ERRORREP\*
c:\windows\Registration\CRMLog\*
c:\windows\System32\catroot2\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\*
c:\windows\System32\com\dmp\*
c:\windows\System32\FxsTmp\*
c:\windows\System32\spool\PRINTERS\*
c:\windows\System32\spool\drivers\color\*
c:\windows\System32\Tasks\*
c:\windows\SysWOW64\com\dmp\*
c:\windows\SysWOW64\FxsTmp\*
c:\windows\SysWOW64\Tasks\*
c:\windows\Tasks\*
c:\windows\Temp\*
c:\windows\tracing\*

I have had c:\windows\PCHEALTH\ERRORREP\* in my AppLocker ruleset for awhile, although it wasn't in my ruleset at the time I posted https://www.wilderssecurity.com/showpost.php?p=1679077&postcount=7.

 

Results of my Win7 x64 setup...

 

Thanks! I didn't see any folders in your list that aren't in the list from post #10.

The other computer I just audited also had two folders that aren't in the list from post #10.

 

You're welcome and thanks for that tip

Sorry it took me so long to clue in to what you were doing. For some reason I thought at first auditing permissions and setting permissions went hand in hand

 

As a result of auditing write permissions of \windows, \program files, \program files (x86), and a few files that are specific to my situation (i.e. LastPass DLLs), I may take these actions:
1. Modify AppLocker ruleset of folder exceptions for allowed execution within \windows folder.
2. Change some file/folder permissions or file/folder owner.
3. If files with permission problems are unnecessary, delete them.
4. Uninstall programs that I can't find a way to run safely.

You're welcome .

 

An alternative to creating a new admin account (if needed) is to temporarily enable the hidden Administrator account.