An increase in access rights is required. Elevating privileges in Windows. We'll go a different way

Elevating privileges is perhaps one of the key points on which the scenario for further pentesting or attack depends. Very often, everything ends at this stage if it is not possible to “expand your powers.” Therefore, today we will talk a little about ways that allow a user to increase their privileges not only to administrator, but also to system.

Introduction

Privilege escalation is slightly different in Windows and Linux. Although both operating systems carry the usual number of vulnerabilities, researchers note that a fully patched Windows server is much more common than a Linux server that has been updated to the latest state. In addition, the release time for Windows patches is often shorter, which makes increasing privileges on Windows a rather interesting and ambitious task. It is to her that we will dedicate our story.

Options

So what opportunities do we have to rise up in the Windows world? First of all, recently enough vulnerabilities related to font parsing have been found in the OS kernel, which makes the process of escalating privileges quite simple if you have a suitable exploit on hand. If you use Metasploit, then just one command is enough to get a system shell. However, all this is likely to work successfully only if the system is not completely patched. If all updates are installed on the machine, then, unlike Linux, it will not be possible to find SUID binaries, and environment variables are usually not passed to services or processes with higher privileges. What is left for us as a result?

From the admin to the system, or what everyone knows

Typically, when you think of escalating privileges, the method that immediately comes to mind is using the task scheduler. In Windows, you can add a task using two utilities: at and schtasks. The second will run the task on behalf of the user who added the task, while the first will run on behalf of the system. A standard trick that you've probably heard of that allows you to run the console with system rights:

At 13:01 /interactive cmd

The second thing that comes to mind is adding a service that will launch the required file / execute the command:

@echo off @break off title root Cls echo Creating service. sc create evil binpath= "cmd.exe /K start" type= own type= interact > nul 2>&1 echo Starting service. sc start evil > nul 2>&1 echo Standing by... ping 127.0.0.1 -n 4 > nul 2>&1 echo Removing service. echo. sc delete evil > nul 2>&1

The third method is to replace the system utility C:\windows\system32\sethc.exe with, for example, cmd. If you log out after this and press the Shift key several times, a console with system rights will appear.

As for automated methods, Metasploit and its getsystem immediately come to mind. An alternative option is PsExec from Sysinternals (psexec -i -s -d cmd.exe).

We'll go a different way

All of these methods have a common drawback: administrator privileges are required. This means that we are escalating privileges from a privileged account. In most cases, when you have received admin rights, you have a bunch of options on how to rise even higher. So it's not a very difficult task. Today we will talk about methods for escalating privileges that do not use any 0day vulnerabilities, assuming that we have a normal system and an account of an ordinary unprivileged user.

Hunt for credentials

One of the reliable and stable ways to increase privileges and gain a foothold in the system is to obtain the passwords of administrators or users with higher privileges. And now it’s time to remember about automated software installation. If you manage a domain that includes a large fleet of machines, you definitely don't want to go and install software on each of them manually. And it will take so much time that there will not be enough for any other tasks. Therefore, Unattended installations are used, which generate files containing admin passwords in their purest form. Which is simply a treasure for both pentesters and attackers.

Unattended Installations

In the case of an automated installation, the file Unattended.xml, which is quite interesting for us, remains on the client, which is usually located either in %WINDIR%\Panther\Unattend\ or in %WINDIR%\Panther\ and can store the administrator password in clear text. On the other hand, to get this file from the server, you don't even need any authentication. You only need to find the “Windows Deployment Services” server. To do this, you can use the script auxiliary/scanner/dcerpc/windows_deployment _services from Metasploit. Although Windows Deployment Services is not the only way to perform automated installations, the Unattended.xml file is considered a standard, so its discovery can be considered a success.

GPP

Group Policy Preference XML files quite often contain a set of encrypted credentials that can be used to add new users, create shares, and so on. Fortunately, the encryption method is documented, so you can easily obtain passwords in their pure form. Moreover, the Metasploit team has already done everything for you - just use the /post/windows/gather/credentials/gpp.rb module. If you are interested in details, then all the necessary information is available at this link.

User rights

Very often, escalation of privileges is a consequence of incorrectly configured user rights. For example, when a domain user is a local administrator (or Power User) on the host. Or when domain users (or members of domain groups) are local administrators on all hosts. In this case, you won’t really have to do anything. But such options don’t come up very often.

AlwaysInstallElevated

Sometimes administrators allow regular users to install programs themselves, usually through the following registry keys:

HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated

HKCU\SOFTWARE\Policies\Microsoft\Window s\Installer\AlwaysInstallElevated

They tell the system that any MSI file must be installed with elevated privileges (NT AUTHORITY\SYSTEM). Accordingly, by using a specially created file, you can again perform actions on behalf of the system and upgrade your privileges.

Metasploit includes a special module exploit/windows/local/always_install_elevated, which creates an MSI file with a special executable file embedded in it, which is extracted and executed by the installer with system privileges. Once executed, the MSI file aborts the installation (by calling a specially crafted invalid VBS) to prevent the action from being logged on the system. In addition, if you start the installation with the /quiet switch, the user will not even see an error.

Missing autostart

It often happens that the system keeps a record of a file that needs to be launched automatically, even after the file itself has already sunk into oblivion. Maybe some service was removed incorrectly - there is no executable file, but the registry entry remains, and every time you start the system unsuccessfully tries to start it, filling the event log with messages about failures. This situation can also be used to expand your powers. The first step is to find all such orphaned records. For example, using the autorunsc utility from Sysinternals.

Autorunsc.exe -a | findstr /n /R "File\ not\ found"

After which, as you guessed, all that remains is to somehow slip your candidate in place of the missing file.

The magic of quotes

Yes, yes, quotes can not only play a cruel joke in SQL queries, allowing for injection, but also help raise privileges. The problem is quite old and has been known since NT times. The point is that the paths to the executable files of some services are not surrounded by quotes (for example, ImagePath=C:\Program Files\Common Files\Network Associates\McShield\McShield.exe), and there are space characters in the path. In this case, if the attacker creates a file that will add new administrators to the system or perform some other actions, and calls it C:\Program Files\common.exe , then when the service is next started, it will be common.exe that will be launched, and the remaining part of the path will be taken as argument(s). It is clear that an unprivileged user will not be able to put anything in Program Files, but the executable file of the service may be located in another directory, that is, the user will have the opportunity to slip in his own file.

In order to use this technique, you need to find a vulnerable service (which will not use quotes in the path to its binary). This is done as follows:

Wmic service get name,displayname,pathname, startmode |findstr /i "auto" |findstr /i /v "c: \windows\\" |findstr /i /v """

True, on XP this will require administrator privileges, so it is better to use the following method there: get a list of services - sc query , then look at information for each service - sc qc servicename .

All according to plan

Another mechanism that can help raise rights and is usually forgotten about is the task scheduler. The schtasks utility allows you to assign tasks to specific events. The most interesting for us are ONIDLE, ONLOGON and ONSTART. As the names suggest, ONIDLE will be executed every time the computer is idle, ONLOGON and ONSTART - when the user logs in and when the system starts, respectively. Thus, a separate task can be assigned to each of the events. For example, when the system starts, copy a malicious binary/keylogger/… somewhere and run it. When users log in, run a credit card dumper. In short, everything is limited only by your imagination and the task at hand.

Tricks with permissions

File permissions are usually the first defense that prevents us from escalating our privileges. It would be tempting to simply overwrite some system file (for example, the same sethc.exe mentioned at the very beginning of the article) and immediately gain system privileges. But all these are just dreams; in fact, we only have permission to read it, which gives us absolutely nothing. However, you should not hang your nose, because with permits, not everything is so smooth either - here, as elsewhere, there are pitfalls, the knowledge of which allows you to make the impossible possible.

One of the system directories protected by this mechanism is especially interesting from the point of view of privilege escalation - Program Files. Unprivileged users are denied access there. However, it sometimes happens that during the installation process, installers incorrectly set file permissions, resulting in all users being given full access to executable files. What follows from this - you already guessed.

Another limitation is that an ordinary mortal is not allowed to write to the root of the system disk. However, for example, on XP, when creating a new directory at the root of the disk, the BUILTIN\Users group receives FILE_APPEND_DATA and FILE_WRITE_DATA permissions (even if the owner of the folder is an administrator):

BUILTIN\Users:(OI)(CI)R BUILTIN\Users:(CI)(special access:) FILE_APPEND_DATA BUILTIN\Users:(CI)(special access:) FILE_WRITE_DATA

On the “seven” almost the same thing happens, only the AUTHENTICATED USERS group receives permission. How can this behavior become a problem? It’s just that some applications install themselves outside of protected directories, which makes it easy to replace their executable files. For example, such an incident happened with the Metasploit Framework in the case of its multi-user installation. This bug was fixed in version 3.5.2, and the utility moved to Program Files.

How to search for such directories/files

Finding a directory with incorrect permissions is already half the battle. However, you must first find it. To do this, you can use the following two tools: AccessChk and Cacls/ICacls. To find “weak” directories using AccessChk, you will need these commands:

Accesschk.exe -uwdqs users c:\ accesschk.exe -uwdqs “Authenticated Users” c:\

To search for files with “weak” permissions, use the following:

Accesschk.exe -uwqs users c:\*.* accesschk.exe -uwqs “Authenticated Users” c:\*.*

The same can be done using Cacls/ICacls:

Cacls "c:\Program Files" /T | findstr Users

Tricks with services

Another option for moving up in the system is to take advantage of misconfigurations and service errors. As practice shows, not only files and folders, but also services running in the system can have incorrect permissions. To detect these, you can use the AccessChk utility from the well-known Mark Russinovich:

Accesschk.exe –uwcqv *

It will be most encouraging to see SERVICE_ALL_ACCESS permission for authenticated users or power users. But the following can also be considered great success:

• SERVICE_CHANGE_CONFIG - we can change the service executable file;
• WRITE_DAC - permissions can be changed, which results in the SERVICE_CHANGE_CONFIG permission being obtained;
• WRITE_OWNER - you can become the owner and change permissions;
• GENERIC_WRITE - inherits permissions SERVICE_CHANGE_CONFIG ;
• GENERIC_ALL - inherits SERVICE_CHANGE_CONFIG permissions.

If you find that one (or more) of these permissions are set to unprivileged users, your chances of escalating your privileges increase dramatically.

How to increase?

Let's say you've found a suitable service, it's time to work on it. The console utility sc will help with this. First, we get complete information about the service we are interested in, let’s say it’s upnphost:

Sc qc upnphost

Let's configure it using the same utility:

Sc config vulnsrv binpath= "net user john hello /add && net localgroup Administrators john /add" type= interact sc config upnphost obj= “.\LocalSystem” password=“”

As you can see, the next time the service starts, instead of its executable file, the command net user john hello /add && net localgroup Administrators john /add will be executed, adding a new user john with the password hello to the system. All that remains is to manually restart the service:

Net stop upnphost net start upnphost

That's all the magic.

What's the result?

Once upon a time, I read a magazine article that outlined basic techniques for escalating privileges in Windows. I didn’t attach much importance to it then, but the theory stuck in my head and once helped me out a lot. So, I hope you will find something new for yourself in this article that will one day help you overcome another barrier.

Today we will talk about Windows privilege escalation. You will learn how an attacker can escalate privileges and how to protect yourself from this.

All information is for informational purposes only. Neither the editors of the site nor the author of the article are responsible for its improper use.

Elevating privileges with BeRoot

Most methods of raising privileges are associated with errors in the configuration of the installed software, be it the path to the executable file of the service, not surrounded by quotes and containing a space (this situation is handled quite interestingly by Windows), or incorrectly set rights to the directory with the application.

Man is a lazy creature and does not want to check all this manually every time. Therefore, sooner or later a tool had to appear that would automate this routine.

Secondary Logon Handle

Another interesting trick involves using the Secondary Login service. This service allows you to run programs, Microsoft Management consoles, and control panel elements as an administrator, even if the current user only belongs to the Users or Power Users group. The point is that this service does not clear handles when creating new processes.

What is important for us is that almost all versions of Windows (x32 and x64) are susceptible to this vulnerability: from Vista to Windows 2012 Server. But there are also limitations: to successfully escalate privileges, the system must have PowerShell 2.0 or higher installed, as well as two or more CPU cores. Metasploit Framework has a special module exploit/windows/local/ms16_032_secondary_logon_handle_privesc.

Its use implies that we already have a meterpreter session, which we must specify in the parameters: set SESSION 1. Well, in case of successful exploitation, we will have another session with elevated privileges.

Conclusion

No matter how hard I try to fit all possible options for increasing privileges into one article, this is unlikely to work, or the article will grow to gigantic proportions and will become uninteresting to you. So it's time to call it a day. We will talk about protection in a separate article.

Many programs require elevation of rights at startup (a shield icon next to the icon), but in fact they do not require administrator rights for their normal operation (for example, you manually granted the necessary rights to users for the program directory in ProgramFiles and the registry branches that are used by the program). Accordingly, when running such a program as a simple user, if User Account Control is enabled on the computer, a UAC prompt will appear and the user will be required to enter the administrator password. To bypass this mechanism, many simply disable UAC or grant the user administrator rights on the computer by adding him to the local administrators group. Naturally, both of these methods are unsafe.

Why a regular application might need administrator rights

The program may need administrator rights to modify certain files (logs, configurations, etc.) in its own folder in C:\Program Files (x86)\SomeApp). By default, users do not have rights to edit this directory; therefore, for normal operation of such a program, administrator rights are required. To solve this problem, you need to manually assign change/write rights to the user (or Users group) to the program folder as an administrator at the NTFS level.

Note. In fact, the practice of storing changing application data in its own directory under C:\Program Files is incorrect. It is more correct to store application data in the user profile. But this is a question of laziness and incompetence of developers.

Running a program that requires administrator rights from a standard user

We have previously described how you can use the RunAsInvoker parameter. However, this method is not flexible enough. You can also use it with saving the admin password /SAVECRED (also unsafe). Let's consider a simpler way to force any program to launch without administrator rights (and without entering the admin password) with UAC enabled (4.3 or level 2).

For example, let's take the registry editing utility - regedit.exe(it is located in the C:\windows\system32 directory). When you run regedit.exe, a UAC window appears and, unless you confirm the privilege elevation, the Registry Editor does not start.

Let's create a file on the desktop run-as-non-admin.bat with the following text:

cmd /min /C "set __COMPAT_LAYER=RUNASINVOKER && start "" %1"

Now to force the application to run without administrator rights and suppress the UAC prompt, simply drag the desired exe file onto this bat file on the desktop.

After this, the Registry Editor should start without the UAC prompt appearing. Open the process manager and add a column Elevated(With a higher permission level), you will see that the system has a regedit.exe process with a non-elevated status (running with user rights).

Try editing any parameter in the HKLM branch. As you can see, access to edit the registry in this branch is denied (this user does not have rights to write to the system registry branches). But you can add and edit keys in the user's own registry branch - HKCU.

In the same way, you can launch a specific application through a bat file, just specify the path to the executable file.

run-app-as-non-admin.bat

Set ApplicationPath="C:\Program Files\MyApp\testapp.exe"
cmd /min /C "set __COMPAT_LAYER=RUNASINVOKER && start "" %ApplicationPath%"

You can also add a context menu, which adds the ability for all applications to launch without elevation. To do this, create the following reg file and import it into the registry.

Windows Registry Editor Version 5.00

@="cmd /min /C \"set __COMPAT_LAYER=RUNASINVOKER && start \"\" \"%1\"\""

After this, to launch any application without administrator rights, just select the “” item in the context menu.

__COMPAT_LAYER environment variable and RunAsInvoker parameter

The __COMPAT_LAYER environment variable allows you to set different compatibility levels for applications (tab Compatibility in the properties of the exe file). Using this variable, you can specify the compatibility settings with which the program should run. For example, to run the application in Windows 7 compatibility mode and 640x480 resolution, set:

set __COMPAT_LAYER=Win7RTM 640x480

Among the options of the __COMPAT_LAYER variable that are interesting to us, we highlight the following parameters:

• RunAsInvoker- launching an application with the privileges of the parent process without a UAC request.
• RunAsHighest- launching the application with maximum rights available to the user (the UAC request appears if the user has administrator rights).
• RunAsAdmin- launch the application with administrator rights (the AUC prompt always appears).

Those. The RunAsInvoker parameter does not provide administrator rights, but only blocks the appearance of the UAC window.

Hmm, the difference between one and the other is only in how the compatibility parameters are set, in the first case - manually, in the second - the same thing, only through the wizard. But thanks anyway for the detailed answer))

Thanks, I know))))))))))))))))))

Ok, I'm an admin (maybe a little illiterate, but I hope to catch up...) How can I be allowed to run this application (and only this)? At the same time, so as not to constantly run to his machine (to enter the local admin password, which he should not know) when he needs to launch this application.

I am very grateful to you for reminding me of part of the lecture on the subject “Operating Systems”. Let me give you another, now classic, example:

Sometimes a user needs to change their login password. The user himself does not have rights to access the password database. However, the program he uses to change the password runs with elevated rights. Which allows him to eventually change his password.

So, my case is similar. How do I "tell" the system that a program should run with elevated rights? In this case, it will be launched by a user from the “user”/“power user” group.

This can actually be done by running the program as a "scheduled task" as a different user. Everything would be fine - it even starts, but the graphical interface (program windows) is not displayed on the user's desktop...

Conceptual contradiction??? I gave an example above - the task is quite standard for any OS. I just don’t want to solve it with third-party tools (not included in Windows Vista). I've already disabled UAC - in any case, the application works correctly only with admin rights, that's how it is - specific.... It doesn't seem possible to include this user in the local "Administrators" group for security reasons.

Regarding the script - for runas there is a flag that allows you to remember the password, but in this case the user will be able to run any program with admin rights.

This means that I don’t want to launch software whose source code no one has seen, nothing is known about the supplier, and whose website is “in the hands of the people.” What about users - eh, if that was enough, then this discussion would not have appeared on the forum..... =(

I would like to believe that not everything is so bad.

Part of the article described in detail the principle of operation of User Account Control. In this part we will talk about setting up UAC in the case when your computer operates standalone, that is, it is not part of an Active Directory domain. To configure User Account Control, use the Local Security Policy feature, which can be found in the Local Group Policy Object Editor.

There are 10 Group Policy settings that are responsible for configuring User Account Control. In order to change policy settings, you need to open the snap-in "Local Group Policy Editor" node Computer Configuration\Windows Configuration\Security Settings\Local Policies\Security Settings. This article will also show you how to configure each policy setting using the system registry. The following table shows the default values ​​for each policy setting.

Default User Account Control group policy settings:

Group Policy settings that relate to User Account Control (UAC) are discussed in detail below:

All administrators work in administrator approval mode

This policy setting determines the characteristics of all User Account Control policies for the computer. This setting determines whether administrator accounts will run in “administrator approved mode,” that is, whether dialogs will be displayed asking for elevation of privileges. Disabling this setting, roughly speaking, completely disables the User Account Control functionality. If you change this policy setting, you must restart the computer. The default value is enabled.

Possible parameter values:

• Included. Administrator approval mode is enabled to allow the built-in administrator account and all other users who are members of the group "Administrators", work in administrator approval mode.
• Disabled. Administrator approval mode and all associated User Account Control policy settings will be disabled.

;Disable "EnableLUA"=dword:00000000

Detect application installation and prompt for elevation

This setting defines the application installation detection characteristics for a computer by checking whether the programs used to deploy applications are signed or not. By default, if a user is a member of a workgroup, it is enabled.

Possible parameter values:

• Enabled (default for home). If the application installer detects the need for elevated privileges, the user is prompted to enter the user name and password for the administrator account. If the user enters correct credentials, the operation continues with appropriate rights. The type of request depends on which group the user belongs to.
• Disabled (organization default). When you select this setting, application installer detection does not prompt you for elevation. Typically, this setting is used in organizations whose computers and users are part of a domain and use delegated installation technologies (Group Policy Software Install - GPSI) to deploy applications. Accordingly, there is no need to detect the installer.

Current policy settings using the registry:

;Disable "EnableInstallerDetection"=dword:00000000

Switch to the secure desktop when prompted for elevation

This policy setting determines whether elevation prompts are displayed on the user's interactive desktop or on the secure desktop when a UAC prompt is initiated. The default value is enabled. If you change this policy setting, you must restart the computer.

Possible parameter values:

• Included. All elevation requests are displayed on the secure desktop, regardless of the prompt behavior policy settings for administrators and standard users.
• Disabled. All requests for elevation of rights are displayed on the user's interactive desktop.

Current policy settings using the registry:

;Disable "PromptOnSecureDesktop"=dword:00000000

Behavior of elevation prompt for administrators in admin approval mode

The current setting allows you to determine the actions of a user who is a member of the group "Administrators" when performing an operation that requires elevation of rights. The default value is set "Request Consent for Third Party Binaries (Non-Windows)".

Possible parameter values:

• Promotion without request. Allows privileged accounts to perform an operation that requires elevation without requiring consent or entering credentials. It is advisable to use this option only in environments with maximum user restrictions. When you select this setting, the user's permissions will be identical to the built-in administrator account.
• . For any operation that requires elevation, the secure desktop will prompt you to enter the root user name and password. If correct credentials are entered, the operation will continue with the maximum available user rights.
• Request Consent on Secure Desktop. For any operation that requires elevation, the secure desktop will prompt you to select: "Allow" or "Prohibit". When selecting the option "Allow", the operation will continue with the maximum available user rights.
• Request for credentials. For any operation that requires elevation, you will be prompted to enter the user name and password for the administrator account. If you enter the correct credentials, the operation will continue with elevated privileges.
• Request for consent. When selecting this option, for any operation that requires elevation of rights, the user will be prompted to select a button: "Allow" or "Prohibit". When you press the button "Allow"
• Request Consent for Third Party Binaries (Non-Windows). When you select this option, a selection prompt will be displayed on the secure desktop: "Allow" or "Prohibit", in the case where the operation for a third-party (non-Microsoft) application requires elevation of rights. At the click of a button "Allow", the operation will continue with the user's maximum available privileges.

Current policy settings using the registry:

;Promotion without prompt "ConsentPromptBehaviorAdmin"=dword:00000000 ;Prompt for credentials on secure desktop; "ConsentPromptBehaviorAdmin"=dword:00000001 ;Prompt for consent on secure desktop; "ConsentPromptBehaviorAdmin"=dword:00000002 ;Prompt for credentials; "ConsentPromp tBehaviorAdmin" =dword:00000003 ;Consent request;"ConsentPromptBehaviorAdmin"=dword:00000004 ;Consent request for non-Windows binary data ;"ConsentPromptBehaviorAdmin"=dword:00000005

Elevation prompt behavior for standard users

This policy setting determines the actions taken when a standard user interacts with applications that require elevated privileges. Default value - "Prompt for credentials on secure desktop".

Possible parameter values:

• Request for credentials. Using this option, the standard user is prompted to select an administrator account and enter a password to perform subsequent actions. The operation will only continue if the credentials are entered correctly.
• Automatically deny elevation requests. If you select this option, a standard user will be shown an access denied error message when performing an operation that requires elevated privileges. Organizations whose desktop computers are used by regular users can select this policy setting to reduce the number of support calls.
• Prompt for credentials on secure desktop. By selecting this option, the standard user is prompted to select an administrator account and enter a password to perform subsequent actions only on the secure desktop. The operation will only continue if the credentials are entered correctly.

Current policy settings using the registry:

;Automatically reject elevation requests "ConsentPromptBehaviorUser"=dword:00000000 ;Prompt for credentials on secure desktop "ConsentPromptBehaviorUser"=dword:00000001 ; Prompt for credentials "ConsentPromptBehaviorUser"=dword:00000003

Elevate rights for UIAccess applications only when installed in secure locations

The current policy setting allows you to control the location permission of applications that request execution at the integrity level defined by the User Interface of Access (UIAccess) attribute in a secure file system location. By default, this setting is enabled and for accessible apps, the UIAccess attribute in the manifest is set to True to control the privilege escalation request window. If applications are set to false, that is, if the attribute is omitted or there is no manifest for the assembly, the application will not be able to access the protected user interface. Only the following folders are considered safe:

…\Program Files\, including subfolders

…\Windows\system32\

...\Program Files (x86)\, including subfolders for 64-bit versions of Windows

Possible parameter values:

• Included. The application will only run with the UIAccess integrity level if it is located in a secure folder on the file system.
• Disabled. The application will run with the UIAccess integrity level even if it is not in a secure file system folder.

Current policy settings using the registry:

;Disable "EnableSecureUIAPaths"=dword:00000000

Elevation of privileges only for signed and verified executables

This User Account Control Group Policy setting allows you to determine whether to authenticate signatures of interactive Public Key Infrastructure (PKI) applications that require elevation of privileges. The purpose of PKI is to determine the policy for issuing digital certificates, issuing and revoking them, and storing information necessary for subsequent verification of the correctness of certificates. Applications that support PKI include: secure email, payment protocols, electronic checks, electronic information interchange, data security over IP networks, electronic forms, and electronically signed documents. If this check is enabled, programs initiate verification of the certificate path. The default value of this setting is Disabled.

Possible parameter values:

• Included. A path check for PKI certificates is forced before the file is executed. This setting is mainly used in organizations with a domain, if the administrator has placed PKI certificates in the trusted publishers store.
• Disabled. When this option is set, User Account Control does not initiate a PKI certificate verification chain check before allowing execution of a given executable file.

Current policy settings using the registry:

;Disable "ValidateAdminCodeSignatures"=dword:00000000

If writing to a file or registry fails, virtualize to the user's location

This setting controls whether application write failures are redirected to specific locations in the registry and file system. When this setting is enabled, for legacy applications that attempt to read or write information using protected areas of the system, User Account Control virtualizes the registry and file system. Thanks to this setting, UAC allows you to reduce the danger of legacy applications that run as an administrator and write data to the %ProgramFiles%, %Windir% folder during execution; %Windir%\system32 or to the system registry key HKLM\Software\. The default value is enabled.

Possible parameter values:

• Included. Application write failures are redirected at runtime to user-defined locations in the file system and registry.
• Disabled. Applications that write data to secure locations will fail and will not execute.

Current policy settings using the registry:

;Disable "EnableVirtualization"=dword:00000000

Allow UIAccess applications to request elevation without using the secure desktop

This new policy setting, introduced in Windows 7 and Windows Server 2008 R2 operating systems, controls whether UIAccess applications can automatically disable the secure desktop for elevation requests used by a standard user. The default value is disabled.

Possible parameter values:

• Included. When you select this setting, UIAccess programs, including Windows Remote Assistance, automatically disable Secure Desktop for elevation requests. If the "User Account Control: Switch to secure desktop when prompted for elevation" policy setting is enabled, the prompt appears on the user's interactive desktop rather than on the secure desktop.
• Disabled. When this option is selected, the secure desktop can only be disabled by the user of the interactive desktop or by disabling the "User Account Control: Switch to secure desktop when prompted for elevation" policy setting.

Current policy settings using the registry:

;Disable "EnableUIADesktopToggle"=dword:00000000

Administrator approval mode for the built-in administrator account

This setting determines whether User Account Control applies administrator approval mode to the built-in account "Administrator". This default built-in account allows the user to log on in Windows XP compatibility mode, allowing them to run any application with full administrator rights. By default, this policy setting is disabled.

Possible parameter values:

• Included. When you select this option, the built-in administrator account will use administrator approval mode. In this case, any operation that requires elevation of rights will be accompanied by a request to confirm the operation.
• Disabled. The built-in administrator account runs all applications with full administrator rights.

Current policy settings using the registry:

;Disable "FilterAdministratorToken"=dword:00000000

Conclusion

This article explains all the possible User Account Control settings. All ten security policy settings are considered, which are responsible for all possible actions related to UAC. In addition to setting up User Account Control using Group Policy, the equivalent registry tweaks are also discussed.