{
	"id": "41bb45da-9892-47b4-93ac-96a95c5b9c3d",
	"created_at": "2026-04-06T00:10:12.535943Z",
	"updated_at": "2026-04-10T03:21:03.018155Z",
	"deleted_at": null,
	"sha1_hash": "9565ed9033365abeed3095d4c6f6e49a3298c752",
	"title": "User Account Control: Inside Windows 7 User Account Control",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 78783,
	"plain_text": "User Account Control: Inside Windows 7 User Account Control\r\nBy Archiveddocs\r\nArchived: 2026-04-05 17:32:09 UTC\r\nUser Account Control\r\nInside Windows 7 User Account Control\r\nMark Russinovich\r\nAt a Glance:\r\nStandard user accounts\r\nUser account control\r\nContents\r\nUAC Technologies\r\nElevations and Malware Security\r\nWhat's Different in Windows 7\r\nAuto-Elevation\r\nAuto-Elevation and UAC's Goals\r\nStandard user accounts provide for better security and lower total cost of ownership in both home and corporate\r\nenvironments. When users run with standard user rights instead of administrative rights, the security configuration\r\nof the system, including antivirus and firewall, is protected. This provides users a secure area that can protect their\r\naccount and the rest of the system. For enterprise deployments, the policies set by desktop IT managers cannot be\r\noverridden, and on a shared family computer, different user accounts are protected from changes made by other\r\naccounts.\r\nHowever, Windows has had a long history of users running with administrative rights. As a result, software has\r\noften been developed to run in administrative accounts and take dependencies, often unintentionally, on\r\nadministrative rights. To both enable more software to run with standard user rights and to help developers write\r\napplications that run correctly with standard user rights, Windows Vista introduced User Account Control (UAC).\r\nUAC is a collection of technologies that include file system and registry virtualization, the Protected\r\nAdministrator (PA) account, UAC elevation prompts, and Windows Integrity levels that support these goals. I've\r\ntalked about these in detail in my conference presentations and TechNet MagazineUAC internals article.\r\nWindows 7 carries forward UAC's goals with the underlying technologies relatively unchanged. However, it does\r\nintroduce two new modes that UAC's PA account can operate with and an auto-elevation mechanism for some\r\nbuilt-in Windows components. In this post, I'll cover the motivations behind UAC's technologies, revisit the\r\nrelationship between UAC and security, describe the two new modes, and explain how exactly auto-elevation\r\nhttps://technet.microsoft.com/en-US/magazine/2009.07.uac.aspx\r\nPage 1 of 8\n\nworks. Note that the information in this post reflects the behavior of the Windows 7 release candidate, which is\r\ndifferent in several ways from the beta.\r\nUAC Technologies\r\nThe most basic element and direct benefit of UAC's technology is simply making Windows more standard-user\r\nfriendly. The showcase example is the difference between the privilege requirements of setting the time zone on\r\nWindows XP and Windows Vista. On Windows XP, changing the time zone—actually, even looking at the time\r\nzone with the time/date control panel applet—requires administrative rights.\r\nThat's because Windows XP doesn't differentiate between changing the time, which is a security-sensitive system\r\noperation, from changing the time zone, which merely affects the way that time is displayed. In Windows Vista\r\n(and Windows 7), changing the time zone isn't an administrative operation and the time/date control panel applet\r\nseparates administrative operations from the standard user operations. This change alone enables many enterprises\r\nto configure traveling users with standard user accounts, because users can adjust the time zone to reflect their\r\ncurrent location. Windows 7 goes further, making things like refreshing the system's IP address, using Windows\r\nUpdate to install optional updates and drivers, changing the display DPI, and viewing the current firewall settings\r\naccessible to standard users.\r\nFile system and registry virtualization work behind the scenes to help many applications that inadvertently use\r\nadministrative rights to run correctly without them. The most common unnecessary uses of administrative rights\r\nare the storage of application settings or user data in areas of the registry or file system that are for use by the\r\nsystem. Some legacy applications store their settings in the system-wide portion of the registry\r\n(HKEY_LOCAL_MACHINE\\Software) instead of the per-user portion (HKEY_CURRENT_USER\\Software),\r\nfor example, and registry virtualization diverts attempts to write to the system location to one in\r\nHKEY_CURRENT_USER (HKCU) while preserving application compatibility.\r\nThe PA account was designed to encourage developers to write their applications to require only standard user\r\nrights while enabling as many applications that share state between administrative components and standard user\r\ncomponents to continue working. By default, the first account on a Windows Vista or Windows 7 system, which\r\nwas a full administrator account on previous versions of Windows, is a PA account. Any programs a PA user\r\nexecutes are run with standard-user rights unless the user explicitly elevates the application, which grants the\r\napplication administrative rights. Elevation prompts are triggered by user activities such as installing applications\r\nand changing system settings. These elevation prompts are the most visible UAC technology, manifesting as a\r\nswitch to a screen with an allow/cancel dialog and grayed snapshot of the desktop as the background.\r\nAccounts created subsequent to the installation are standard user accounts by default that provide the ability to\r\nelevate via an \"over the shoulder\" prompt that asks for credentials of an administrative account that will be used to\r\ngrant administrative rights. This facility enables a family member sharing a home computer or a more security-conscious user using a standard user account to run applications with administrative rights, provided they know\r\nthe password to an administrative account, without having to manually switch to a different user logon session.\r\nCommon examples of such applications include installers and parental control configuration.\r\nWhen UAC is enabled, all user accounts—including administrative accounts—run with standard user rights. This\r\nmeans that application developers must consider the fact that their software won't have administrative rights by\r\nhttps://technet.microsoft.com/en-US/magazine/2009.07.uac.aspx\r\nPage 2 of 8\n\ndefault. This should remind them to design their application to work with standard user rights. If the application or\r\nparts of its functionality require administrative rights, it can leverage the elevation mechanism to enable the user\r\nto unlock that functionality. Generally, application developers need to make only minor changes to their\r\napplications to work well with standard user rights. As the E7 blog post on UAC shows, UAC is successfully\r\nchanging the way developers write software.\r\nElevation prompts also provide the benefit that they \"notify\" the user when software wants to make changes to the\r\nsystem, and it gives the user an opportunity to prevent it. For example, if a software package that the user doesn't\r\ntrust or want to allow to modify the system asks for administrative rights, they can decline the prompt.\r\nElevations and Malware Security\r\nThe primary goal of UAC is to enable more users to run with standard user rights. However, one of UAC's\r\ntechnologies looks and smells like a security feature: the consent prompt. Many people believed that the fact that\r\nsoftware has to ask the user to grant it administrative rights means that they can prevent malware from gaining\r\nadministrative rights. Besides the visual implication that a prompt is a gateway to administrative rights for just the\r\noperation it describes, the switch to a different desktop for the elevation dialog and the use of the Windows\r\nIntegrity Mechanism, including User Interface Privilege Isolation (UIPI), seem to reinforce that belief.\r\nAs we've stated since before the launch of Windows Vista, the primary purpose of elevation is not security,\r\nthough, it's convenience: if users had to switch accounts to perform administrative operations, either by logging\r\ninto or Fast User Switching to an administrative account, most users would switch once and not switch back.\r\nThere would be no progress changing the environment that application developers design for. So what are the\r\nsecure desktop and Windows Integrity Mechanism for?\r\nThe main reason for the switch to a different desktop for the prompt is that standard user software cannot \"spoof\"\r\nthe elevation prompt, for example, by drawing on top of the publisher name on the dialog to fool a user into\r\nthinking that Microsoft or another software vendor is generating the prompt instead of them. The alternate desktop\r\nis called a \"secure desktop,\" because it's owned by the system rather than the user, just like the desktop upon\r\nwhich the system displays the Windows logon dialog.\r\nThe use of another desktop also has an important application compatibility purpose: while built-in accessibility\r\nsoftware, like the On Screen Keyboard, works well on a desktop that's running applications owned by different\r\nusers, there is third-party software that does not. That software won't work properly when an elevation dialog,\r\nwhich is owned by the local system account, is displayed on the desktop owned by a user.\r\nThe Windows Integrity Mechanism and UIPI were designed to create a protective barrier around elevated\r\napplications. One of its original goals was to prevent software developers from taking shortcuts and leveraging\r\nalready-elevated applications to accomplish administrative tasks. An application running with standard user rights\r\ncannot send synthetic mouse or keyboard inputs into an elevated application to make it do its bidding or inject\r\ncode into an elevated application to perform administrative operations.\r\nWindows Integrity Mechanism and UIPI were used in Windows Vista for Protected Mode Internet Explorer,\r\nwhich makes it more difficult for malware that infects a running instance of IE to modify user account settings, for\r\nexample, to configure itself to start every time the user logs on. While it was an early design goal of Windows\r\nhttps://technet.microsoft.com/en-US/magazine/2009.07.uac.aspx\r\nPage 3 of 8\n\nVista to use elevations with the secure desktop, Windows Integrity Mechanism, and UIPI to create an\r\nimpermeable barrier—called a security boundary—between software running with standard user rights and\r\nadministrative rights, two reasons prevented that goal from being achieved, and it was subsequently dropped:\r\nusability and application compatibility.\r\nfigb.gif\r\nFigure 1 Showing the executable fi le’s name.\r\nFirst, consider the elevation dialog itself. It displays the name and publisher of the primary executable that will be\r\ngranted administrative rights. Unfortunately, while greater numbers of software publishers are digitally signing\r\ntheir code, there are those that aren't, and there are many older applications that aren't signed. For software that\r\nisn't signed, the elevation dialog simply shows the executable's file name, which makes it possible for malware\r\nalready running in a users account and that's watching for an elevation of an unsigned Setup.exe application\r\ninstaller, for example, to replace the executable with a malicious Setup.exe without the user being able to tell (see\r\nFigure 1).\r\nSecond, the dialog doesn't tell the user what DLLs the executable will load once it starts. If the executable resides\r\nin a directory under the user's control, malware running with the user's standard rights can replace any associated\r\nDLLs in the location that the software will use. Alternatively, malware could use side-by-side functionality to\r\ncause the executable to load malicious versions of application or system DLLs. And unless a user vigilantly clicks\r\nthe details button and carefully looks at the file path listed for the elevating executable, malware can copy the\r\nexecutable to a similarly named location, for example, \\ProgramFiles\\Vendor\\Application.exe (note the missing\r\nspace in what should be \"Program Files\"), where it could control what DLLs the application loads. In Figure 2,\r\nI've copied a component of Microsoft Network Monitor to the user-created C:\\ProgramFiles directory that's\r\ncontrollable by the user and launched it.\r\nfigc.gif\r\nFigure 2 Launched copy of Microsoft Network Monitor component.\r\nFinally, for application compatibility, elevated applications share substantial state with the standard user\r\nenvironment that a malicious application could use to influence the behavior of an elevated application. The\r\nclearest example of this is the user's registry profile, HKEY_CURRENT_USER (HKCU). That is shared because\r\nusers expect settings and extensions they register as a standard user to work in elevated applications. Malware\r\ncould use shell extensions registered in HKCU to load into elevated applications that use any of the shell browsing\r\ndialogs, like File Open and File Save. Other kinds of state are also shared, most notably the Base Named Object\r\nnamespace, where applications create synchronization and shared memory objects. Malware could take advantage\r\nof that sharing to hijack a shared memory object used by an elevated application, for instance, to compromise the\r\napplication and then the system.\r\nAs for the Windows Integrity Mechanism, its effectiveness as a barrier is limited by the elevation issues I've\r\nmentioned, but it also has limitations caused by application compatibility. For one, UIPI doesn't prevent standard\r\nuser applications from drawing on the desktop, something that could be used to trick the user into interacting with\r\nelevated applications in a way that grants malware administrative rights. Windows Integrity Mechanism also\r\nhttps://technet.microsoft.com/en-US/magazine/2009.07.uac.aspx\r\nPage 4 of 8\n\ndoesn't flow across the network. A standard user application running in a PA account will have access to system\r\nresources on a remote system on which that PA account has administrative rights. Addressing these limitations has\r\nmajor application compatibility ramifications. That said, that we are continually looking at ways to improve\r\nsystem security, for instance, improving Protected Mode IE, while at the same time addressing application\r\ncompatibility issues and working closely with software developers.\r\nSo, how much malware protection do you get when you run in a Windows Vista PA account with UAC enabled?\r\nFirst, remember that for any of this to matter, malware has to get onto the system and start executing in the first\r\nplace. Windows has many defense-in-depth features, including Data Execution Prevention (DEP), Address Space\r\nLoad Randomization (ASLR), Protected Mode IE, the IE 8 SmartScreen Filter, and Windows Defender that help\r\nprevent malware from getting on the system and running.\r\nAs for the case where malware somehow does manage to get on a system, because malware authors (like\r\nlegitimate developers) have assumed users run with administrative rights, most malware will not function\r\ncorrectly. That alone could be considered a security benefit. However, malware that's gotten on a system and that's\r\ndesigned to exploit the opportunities might be able to gain administrative rights the first time the user elevates—\r\nbut the malware doesn't even need to wait for a \"real\" elevation because it can precipitate one that would fool even\r\nthe most security conscious users. I've demonstrated publicly how malware can hijack the elevation process in my\r\nUAC Internals and Windows Security Boundaries presentations (the demo is at minute 1:03 in the security\r\nboundaries talk). Remember, though, if malware does start running, it can accomplish most of the things that\r\nmalware wants to do with just standard user rights, including configuring itself to run every time the user logs on,\r\nstealing or deleting all the user's data, or even becoming part of a botnet.\r\nWhat's Different in Windows 7\r\nI mentioned some of the operations in Windows 7 that can now be performed by standard users, but as the E7 blog\r\npost on UAC explains, we also recognized that we could make the Windows experience smoother without\r\nsacrificing UAC's goals. Many users complained about the fact that Windows Vista itself frequently asks for\r\nadministrative rights when they perform common system management operations. It's in our best interest, because\r\nit's in the interest of our customers, to make Windows work well for standard user environments. However,\r\nelevation prompts don't educate or encourage us to do so, but they do force users to click a second time through a\r\ndialog that the vast majority of users don't read. Windows 7, therefore, set out to minimize those prompts from the\r\ndefault Windows experience and enable users that run as administrators to control their prompting experience.\r\nTo do that, we further refactored the system such that someone with standard user rights can execute more tasks,\r\nand we reduced the number of prompts in several multi-prompt scenarios (for example, installing an ActiveX\r\ncontrol in IE). Windows 7 also introduces two new UAC operating modes that are selectable in a new UAC\r\nconfiguration dialog (see Figure 3). You can open the dialog by going to Control Panel, clicking User Accounts,\r\nclicking User Accounts, and then clicking Change User Account Control Settings. (You can also get to it by\r\nclicking on the Change When Notifications Appear link on an elevation prompt or by going through the Action\r\nCenter.)\r\nfigd.gif\r\nFigure 3 Two new UAC operating modes that are selectable in a new UAC configuration dialog.\r\nhttps://technet.microsoft.com/en-US/magazine/2009.07.uac.aspx\r\nPage 5 of 8\n\nThe default setting, shown in Figure 3, is one of the new levels. Unlike Always Notify, which is the selection at\r\nthe top of the slider and is identical to the default mode in Windows Vista, the Windows 7 default prompts the user\r\nonly when a non-Windows executable asks for elevation; the behavior for non-Windows elevations is the same as\r\nit was for Windows Vista.\r\nThe next slider position down is the second new setting and has the same label except with \"(do not dim my\r\ndesktop)\" appended to it. The only difference between that and the default mode is that prompts happen on the\r\nuser's desktop rather than on the secure desktop. The upside of that is that the user can interact with the desktop\r\nwhile a prompt is active, but as I mentioned earlier, the risk is that third-party accessibility software might not\r\nwork correctly on the prompt dialog.\r\nFinally, the bottom slider position turns off UAC technologies altogether, so that all software running in a PA\r\naccount runs with full administrative rights, file system and registry virtualization are disabled, and Protected\r\nMode IE is disabled. While there are no prompts at this setting, the loss of Protected Mode IE is a significant\r\ndisadvantage of this mode.\r\nAuto-Elevation\r\nThe reason that elevation of (most) Windows executables in the two middle settings doesn't result in a prompt is\r\nthat the system \"auto elevates\" Windows executables. First, what does Windows define as a Windows executable\r\nin this context? The answer depends on several factors, but two things must hold: it must be digitally signed by the\r\nWindows publisher, which is the certificate used to sign all code included with Windows (it's not sufficient to be\r\nsigned by Microsoft, so Microsoft software that's not shipped in Windows isn't included); and it must be located in\r\none of a handful of \"secure\" directories. A secure directory is one that standard users can't modify and they include\r\n%SystemRoot%\\System32 (e.g., \\Windows\\System32) and most of its subdirectories, %SystemRoot%\\Ehome, as\r\nwell as a handful of directories under %ProgramFiles% that include Windows Defender and Windows Journal.\r\nAlso, depending on whether the executable is a normal .exe, Mmc.exe, or a COM object, auto-elevation has\r\nadditional rules. Windows executables (as just defined) of the .exe variety auto-elevate if they specify the\r\nautoElevate property in their manifest, which is also where applications indicate to UAC that they want\r\nadministrative rights. Here's the Sysinternals Sigcheck utility dumping the manifest for Task Manager\r\n(Taskmgr.exe) with the command \"sigcheck –m %systemroot%\\system32\\taskmgr.exe\", which shows that Task\r\nManager is opted in for auto-elevation, as shown in Figure 4.\r\nfige.gif\r\nFigure 4 The autoElevate Property\r\nAn easy way to find auto-elevate executables in a directory tree is to use the Sysinternals Strings utility with a\r\ncommand like this:\r\nstrings –s *.exe | findstr /i autoelevate\r\nThere is also a hardcoded list of Windows executables that get the auto-elevate treatment. These Windows\r\nexecutables also ship external to Windows 7 and so must be able to run on down-level systems where the presence\r\nhttps://technet.microsoft.com/en-US/magazine/2009.07.uac.aspx\r\nPage 6 of 8\n\nof the autoexecute property would result in an error. The list includes Migwiz.exe, the migration wizard,\r\nPkgmgr.exe, the package manager, and Spinstall.exe, the Service Pack installer.\r\nThe Microsoft Management Console, Mmc.exe, gets special treatment since it hosts many of the system\r\nmanagement snap-ins, which are implemented as DLLs. Mmc.exe launches with a command line that specifies a\r\n.MSC file that lists the snap-ins MMC is to load. When Windows sees Mmc.exe ask for administrative rights,\r\nwhich it does when launched from a PA account, it validates that Mmc.exe is a Windows executable and then\r\nchecks the .MSC. To be eligible for auto-elevation, the .MSC file must satisfy the Windows executable criteria\r\n(signed by Windows in a secure location) and it must be listed on an internal list of auto-elevate .MSCs. That list\r\nincludes virtually all the .MSC files shipped with Windows.\r\nFinally, COM objects can specify the need for administrative rights with a registry value in their registry key by\r\ncreating a subkey named Elevation with a value named Enabled that is set to 1. Figure 5 shows the registry key\r\nfor the shell's Copy/Move/Rename/Delete/Link Object that Explorer uses when a user performs a file system\r\noperation on a location their account doesn't have permissions for.\r\nfigf.gif\r\nFigure 5 Shell Registry Key\r\nFor a COM object to be auto-elevated, it must also be a Windows executable and it must have been instantiated by\r\na Windows executable. (The instantiating executable doesn't need to be marked for auto-elevation, though.) When\r\nyou use Explorer to create a directory in the %ProgramFiles% directory from a PA account, for instance, the\r\noperation will auto-elevate because the COM object requests elevation, the object's DLL is a Windows executable,\r\nand Explorer is a Windows executable.\r\nAuto-Elevation and UAC's Goals\r\nSo what's behind all the special auto-elevation rules? Choosing what to auto-elevate and what not to was guided\r\nby the question, \"Can an application developer inadvertently or trivially depend on administrative rights by\r\nleveraging auto-elevate?\" Since Cmd.exe can be used to execute batch scripts via command-line arguments and\r\naverage users have no need to run command prompts elevated (most don't even know what a command prompt is),\r\nit was not manifested for auto-elevation. Similarly, Rundll32.exe, the executable that hosts control panel plug-ins,\r\ndoesn't auto-elevate in the final release of Windows 7 because its elevation isn't required for any common\r\nmanagement tasks, and if it auto-elevated, its ability to host arbitrary DLLs via its command-line could cause a\r\ndeveloper to require administrator rights without realizing it.\r\nEnd users have been asking for Windows to provide a way to add arbitrary applications to the auto-elevate list\r\nsince the Windows Vista beta. The commonly cited reason is that some third-party application they frequently use\r\nforces them to constantly click through an elevation prompt as part of their daily routine. Windows 7, just like\r\nWindows Vista, doesn't provide such a capability. We understand the aggravation, and there might be a legitimate\r\nreason that those applications can't run without administrative rights, but the risk is too high that developers will\r\navoid fixing their code to work with standard user rights. Even if the list of what applications get auto-elevated\r\nwas only accessible by administrators, developers might simply change their application setup program, which\r\nhttps://technet.microsoft.com/en-US/magazine/2009.07.uac.aspx\r\nPage 7 of 8\n\nrequires a one-time elevation, to add their application to the list. We've instead chosen to invest in educating and\r\nworking closely with application developers to ensure their programs work correctly as a standard user.\r\nSeveral people have observed that it's possible for third-party software running in a PA account with standard user\r\nrights to take advantage of auto-elevation to gain administrative rights. For example, the software can use the\r\nWriteProcessMemory API to inject code into Explorer and the CreateRemoteThread API to execute that code, a\r\ntechnique called DLL injection. Since the code is executing in Explorer, which is a Windows executable, it can\r\nleverage the COM objects that auto-elevate, like the Copy/Move/Rename/Delete/Link Object, to modify system\r\nregistry keys or directories and give the software administrative rights. While true, these steps require deliberate\r\nintent, aren't trivial, and therefore are not something we believe legitimate developers would opt for versus fixing\r\ntheir software to run with standard user rights. In fact, we recommend against any application developer taking a\r\ndependency on the elevation behavior in the system and that application developers test their software running in\r\nstandard user mode.\r\nThe follow-up observation is that malware could gain administrative rights using the same techniques. Again, this\r\nis true, but as I pointed out earlier, malware can compromise the system via prompted elevations as well. From the\r\nperspective of malware, Windows 7's default mode is no more or less secure than the Always Notify mode (\"Vista\r\nmode\"), and malware that assumes administrative rights will still break when run in Windows 7's default mode.\r\nConclusion\r\nTo summarize, UAC is a set of technologies that has one overall goal: to make it possible for users to run as\r\nstandard users. The combination of changes to Windows that enable standard users to perform more operations\r\nthat previously required administrative rights, file and registry virtualization, and prompts all work together to\r\nrealize this goal. The bottom line is that the default Windows 7 UAC mode makes a PA user’s experience\r\nsmoother by reducing prompts, allows them to control what legitimate software can modify their system, and still\r\naccomplishes UAC’s goals of enabling more software to run without administrative rights and continuing to shift\r\nthe software ecosystem to write software that works with standard user rights.\r\nMark Russinovich is a Technical Fellow at Microsoft in the Platform and Services Division.\r\nSource: https://technet.microsoft.com/en-US/magazine/2009.07.uac.aspx\r\nhttps://technet.microsoft.com/en-US/magazine/2009.07.uac.aspx\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://technet.microsoft.com/en-US/magazine/2009.07.uac.aspx"
	],
	"report_names": [
		"2009.07.uac.aspx"
	],
	"threat_actors": [],
	"ts_created_at": 1775434212,
	"ts_updated_at": 1775791263,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/9565ed9033365abeed3095d4c6f6e49a3298c752.pdf",
		"text": "https://archive.orkl.eu/9565ed9033365abeed3095d4c6f6e49a3298c752.txt",
		"img": "https://archive.orkl.eu/9565ed9033365abeed3095d4c6f6e49a3298c752.jpg"
	}
}