{
	"id": "8560d3ae-b570-4e56-bb6b-5fe49885af11",
	"created_at": "2026-04-06T00:13:48.500909Z",
	"updated_at": "2026-04-10T03:31:17.746409Z",
	"deleted_at": null,
	"sha1_hash": "d450f878fa7e9d72fb598857abddbb92122e7aad",
	"title": "Windows 7 UAC whitelist: Code-injection Issue (and more)",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 550616,
	"plain_text": "Windows 7 UAC whitelist: Code-injection Issue (and more)\r\nArchived: 2026-04-05 20:17:34 UTC\r\nWindows 7 UAC whitelist:\r\n- Code-injection Issue\r\n- Anti-Competitive API\r\n- Security Theatre\r\n(Still needs an edit/re-write/chainsaw but I can't be bothered. I have wasted enough time on this already.)\r\nAs I was typing more words into this page, this appeared in my text editor at the 10,000th word! :-)\r\nQuick Windows 7 RTM update:\r\nEverything below still applies to the final retail release of Windows 7 (and all updates as of 14/Sep/2011).\r\nQuick Windows 8 update:\r\nEverything below still applies to the Windows 8 Developer Preview released on 13/Sep/2011. It is early days, of\r\ncourse, but from a quick look it does not seem that anything UAC-related has changed at all in Win8.\r\nContents:\r\nWin 7 UAC Code-Injection: Program \u0026 source-code\r\nWin 7 UAC Code-Injection: Video demonstrations\r\nSome Quotes\r\nWin 7 UAC Code-Injection: Summary\r\nWin 7 UAC Code-Injection: The good news\r\nWin 7 UAC Code-Injection: How it works\r\nUAC in Vista and Windows 7: Mistakes then and now (Better ways MS could've responded to complaints\r\nabout Vista.)\r\nhttp://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nPage 1 of 23\n\nUAC Comparison: Two file-managers\r\nIf a whitelist makes sense then it must be user-configurable\r\nPrevious Windows 7 UAC issues\r\nTo those saying, \"but it requires code to get on the box\"\r\nTo those saying, \"but UAC isn't a security boundary\"\r\nTo those saying, \"but it's only a beta\"\r\nQuick response to a couple of newer things\r\nProgram, Source Code and Step-by-Step Guide\r\nWhile Windows 7 was still in beta Microsoft said this was a non-issue, and ignored my offers to give them full\r\ndetails for several months. so there can't be an issue with making everything public now.\r\nMarch 2020: Binaries removed as I got sick of the page being marked as malware, even by Google (FFS) who\r\nthemselves publish thousands of similar disclosures. There's no way to contact a human being at Google. The old\r\nbinaries still worked completely on Windows 10 in the year 2020 and the issue is never going to be addressed by\r\nMicrosoft, but apparently providing proof of it is bad in some way. Whatever. The source code remains up but you\r\ncan find the binaries yourselves. If you end up getting ACTUAL malware because you couldn't get the binaries\r\nfrom a safe, official source, blame Google.\r\nWin7ElevateV2.zip (32-bit and 64-bit binaries; use the version for your OS.\r\nWin7ElevateV2_Source.zip (C++ source code, and detailed guide to how it works.)\r\nSource in HTML format (for browsing online)\r\nStep-by-step guide (description of what the code does)\r\nThis works against the RTM (retail) and RC1 versions of Windows 7. It probably won't work with the old beta\r\nbuild 7000 due to changes in which apps can auto-elevate.\r\nMicrosoft could block the binaries via Windows Defender (update: they now do via MSE), or plug the\r\nCRYPTBASE.DLL hole, but unless they fix the underlying code-injection / COM-elevation problem the file copy\r\nstuff will still work. Fixing only the CRYPTBASE.DLL part, or blocking a particular EXE or DLL, just means\r\nsomeone has to find a slightly different way to take advantage of the file copy part. Finding the\r\nCRYPTBASE.DLL method took about 10 minutes so I'd be surprised if finding an alternative took long.\r\nEven if the hole is fixed, UAC in Windows 7 will remain unfair on third-party code and inflexible for users who\r\nwish to use third-party admin tools.\r\nMicrosoft Security Essentials detects proof-of-concept as \"hacktool\"\r\nAs originally reported by Maurice at AeroXperience, the free Microsoft Security Essentials anti-virus tool now\r\ndetects the Win7ElevateV2 binaries as HackTool:Win32/Welevate.A and HackTool:Win64/Welevate.A.\r\nApparently recompiling the binaries in VS2010 means they are no longer detected. So as well as being named\r\nafter the proof-of-conept executables the detection seems to be looking for those executables specifically, rather\r\nthan detecting a general pattern within them. That seems pointless when, aside from demonstrating what a\r\nprogram could do, the proof-of-concept executables don't do or allow the user to do anything that couldn't be done\r\nhttp://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nPage 2 of 23\n\nusing Windows Explorer. The point of them is to demonstrate that anything Windows Explorer is allowed to do\r\ncan be hijacked by any other program.\r\nAnother program using the same technique would not be detected by MSE's current anti-virus signatures.\r\nIf this whole thing is a non-issue then why block the proof-of-concept binaries? On the other hand, if bypassing\r\nUAC does makes something dangerous then shouldn't Explorer.exe be detected and blocked as well? :-)\r\nWin 7 UAC Code-Injection: Video demonstrations\r\nI'll cut to the chase for the TLDR crowd.\r\nVideo demonstration of Win 7 beta UAC flaws and design:\r\n Mirror 1; Mirror 2\r\nA more dramatic example of a machine being hosed:\r\n Mirror 1; Mirror 2\r\nhttp://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nPage 3 of 23\n\nDepending on which side of the \"trust all code on the box\" fence you are on, watching the two videos above\r\nshould show you either how serious this problem is or how pointless it is to force UAC prompts on third-party\r\napps.\r\nLong Zheng's video demonstration using Win 7 RC1 build 7100:\r\nThe original, less interesting version which just copied a file:\r\n Mirror 1; Mirror 2\r\n(Thanks to Kelbv and Jon for hosting the videos.)\r\nSome quotes\r\n(Bold emphasis is mine.)\r\nUser Account Control (UAC) is a core security feature in the next release of Windows Vista and Windows Server\r\ncode name Longhorn.\r\nhttp://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nPage 4 of 23\n\n--Microsoft's UAC blog\r\nThe other fact is that User Account Control (UAC) is one of the most important ways that we hope to protect\r\npeople in Windows Vista. [...] Once the OS is released, if you absolutely can’t stand a security feature that is\r\ndesigned to protect you, by all means, turn it off\r\n --Jesper's Blog (Senior Security Strategist in the Security Technology Unit at Microsoft.)\r\nHere’s my million dollar question: If UAC wasn’t designed to ultimately protect us from anything, why does its\r\nicon resemble a damn shield?\r\n --Rafael's Within Windows\r\nStandard user accounts are a distraction and an excuse as far as Windows 7 UAC goes. You might as well say\r\n\"People should use Linux to be more secure\" as it's about as relevant and likely to happen. If Windows 8 (or\r\nwhatever) actually makes standard user the default, and improves the user experience to one that people might\r\nactually put up with, then the argument will hold water.\r\n --Me :-)\r\nWin 7 UAC Code-Injection: Summary\r\nOn 5th February 2009 I wrote a proof-of-concept program to demonstrate a flaw in Windows 7's UAC under\r\ndefault UAC/account settings. This simply copied a file to Program Files without the user's consent. In other\r\nwords, it performed a file copy to a protected location from an unelevated process, bypassing UAC.\r\n\"So what? All it does is copy a file?\"\r\nOn 9th February 2009 I extended the proof-of-concept program into to something which, without requiring\r\nelevation itself, can run and elevate any command or program without triggering a UAC prompt.\r\nAll of this is done without using the SendKeys or RunDll32 holes which were found earlier in February. It is done\r\nusing a method which can attack almost any Windows executable and which is inherent to the changes Microsoft\r\nhave made to UAC in Windows 7.\r\nThe proof-of-concept works on unmodified installs of Windows 7, including the October retail release, both 32-bit\r\nand 64-bit versions, at default settings.\r\nSetting UAC to its highest level, or using a non-admin account, will prevent the proof-of-concept from working\r\nby forcing it to display a UAC prompt. However, neither of those are the default settings of a Windows 7 install.\r\nAs well as discussing the proof-of-concept code I argue that:\r\nMicrosoft should either admit that local process elevation is a problem and make Windows more secure by\r\ndefault or admit that the Windows 7 default UAC settings are security theater (as they offer no protection)\r\nand anti-competitive (as they are inflicted on third-party code despite local elevation supposedly being a\r\nnon-issue).\r\nIf there is to be a UAC whitelist, or the equivalent of one, then it should be up to the user which Microsoft\r\nand third-party software is on it. Users should not be forced to expose themselves to risks from software\r\nthey do not use. Conversely, if reducing UAC prompts in frequently-used software is needed to stop people\r\nhttp://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nPage 5 of 23\n\ndisabling UAC entirely then that applies to third-party software as much as to bundled software (especially\r\nonce a machine is past the \"setup\" phase).\r\nThe \"elevate without prompting\" UAC option should be available in the main UAC control panel, in\r\nparticular so that Home Premium users can access it. (This allows you to turn off UAC prompts without\r\nturning off the undeniably good parts of UAC such as Protected-Mode IE.)\r\nUAC itself was a good API and a good design that was given a bad name because of the way it was used\r\nby Microsoft's application-level code (such as Explorer and Control Panel). Accordingly, the user\r\nexperience of having UAC enabled could have been vastly improved by changing the application-level\r\ncode without opening a huge hole in UAC.\r\nMicrosoft created these problems themselves and, rather than fixing them properly, have taken the easy\r\nway out, unnecessarily making UAC less secure in the process. At the same time Microsoft expect third-party vendors to do a better job than they bothered to do using the API which they themselves designed.\r\nIf UAC is inherently \"undefendable\" then that applies equally to UAC when used for elevation from a\r\nstandard user account.\r\nIf the only goal of UAC is to coerce third-party programmers into working better under standard user\r\naccounts then there are far, far better ways to achieve that.\r\nMicrosoft need to get their message straight about what UAC is and isn't supposed to do. They need to stop\r\nsaying that UAC is a security feature only to say it isn't, depending on what suits them at the time.\r\nAnd, for the record, I like Windows and much of what Microsoft do, in general. I even like UAC (the API, not the\r\nway it has been used). I wrote this page because I care about the platform not because I get a kick out of attacking\r\nsomething Microsoft have done. I call things as I see them. I attack and criticise some of what Microsoft do and I\r\nsupport and defend Microsoft other things that they do.\r\nWin 7 UAC Code-Injection: The good news\r\nAll of this only affects the default account type and UAC level of Windows 7 (builds 7000 \u0026 7022, but probably\r\nalso the retail given Microsoft's stance so far). If you go against the defaults and run as a non-admin user or turn\r\nUAC up to the Always Prompt level, so it behaves like it did in Vista, then it is no longer possible for code-injection from unelevated processes to bypass UAC prompts. So the advice remains as before:\r\nIf you are using Windows 7 and want to be protected against silent elevation then turn UAC up to the\r\nhighest level.\r\nHowever, I would add to that advice:\r\nIf, on the other hand, you don't care about silent elevation then you should turn down UAC to Elevate\r\nWithout Prompting -- so that UAC is still enabled but it never prompts you -- because the default level\r\nisn't buying you much except a few pointless prompts which can be bypassed by any program which\r\nwants to.\r\nThe Elevate Without Prompting mode, which was available on Vista as well, can be set via the Local\r\nSecurity Policy control panel (screenshot) but isn't one of the options in the simplified UAC control\r\npanel.\r\nhttp://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nPage 6 of 23\n\nYou either care about silent elevation or you don't. Pick one.\r\nWin 7 UAC Code-Injection: How it works\r\nIn the quest to reduce the number of UAC prompts, for their code only, Microsoft have granted (at least) three\r\ngroups of components special privileges:\r\n1. Processes which anything else can run elevated without a UAC prompt.\r\nThis is the list of about 70 processes published on Rafael's Within Windows blog. (Update: New list for\r\nRC1 build 7100.) If you run a process on this list and it requires elevation then it -- the whole process --\r\nwill be given elevation without showing you a UAC prompt.\r\nDiscovery of this list is what lead to the earlier RunDll32.exe exploit where you could ask RunDll32.exe to\r\nrun your code from within a DLL and it would do so with full elevation and no UAC prompt. Microsoft\r\nhave since removed RunDll32.exe from the list but there are still plenty of other processes on the list,\r\nseveral of which can be exploited if you can copy files to the Windows folder.\r\n2. Processes which can create certain elevated COM objects without a UAC prompt.\r\nPrograms on this second list are able, without being elevated themselves, to create certain elevated COM\r\nobjects without triggering a UAC prompt. Once such an object has been created the processes can then tell\r\nit to perform actions which require administrator rights, such as copying files to System32 or Program\r\nFiles.\r\nThis appears to be a superset of the first list. In fact, it seems to include all executables which come with\r\nWindows 7 and have a Microsoft authenticode certificate.\r\nUnbelievably, as of build 7000 (and confirmed in RC1 build 7100), the list includes not only programs like\r\nExplorer.exe which use this feature (or potential security hole, if you like) but also programs such as\r\nCalc.exe, Notepad.exe and MSPaint.exe. Microsoft appear to have done nothing to minimize the attack\r\nsurface and have arbitrarily granted almost all of their executables with this special privilege whether they\r\nactually use it or not. You can see evidence of this yourself by opening MSPaint, using the File Open\r\ndialog as a mini-file manager, and making changes within Program Files (e.g. create a folder or rename\r\nsomething); it'll let you do that without the UAC prompt that non-MS apps should trigger. I doubt that is\r\nintentional and it shows how little thought has gone into the UAC whitelist hacks MS have added to make\r\ntheir own apps seem better.\r\n3. COM objects which can be created with elevation, by the things in list 2, without a UAC prompt.\r\nFull enumeration of this list has not yet been done. The list is known to include IFileOperation and may\r\nsimply be all Microsoft-signed COM objects that allow elevation at all.\r\nIt does not look like third-party COM objects can be elevated without triggering a UAC prompt, even by\r\nMicrosoft processes, so the process and object must be on lists 2 and 3 respectively to bypass the UAC\r\nprompt. Given the number of processes which can be attacked and the fact that there are Microsoft COM\r\nobjects to do many admin tasks, that isn't much of a consolation.\r\nhttp://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nPage 7 of 23\n\nMy proof-of-concept program is a standalone executable that is run as a normal unelevated process. I made from\r\nscratch in about a day and a half. Keep in mind that, while I am an experienced Windows developer, I am not a\r\n\"security researcher\" or \"hacker\" and this isn't the kind of thing I write every day.\r\nThe proof-of-concept works by directly copying (or injecting) part of its own code into the memory of another\r\nrunning processes and then telling that target process to run the code. This is done using standard, non-privileged\r\nAPIs such as WriteProcessMemory and CreateRemoteThread.\r\nIf the target process is on list 2 (above) then our process gains the ability to create and control elevated COM\r\nobjects from list 3 (above) without triggering a UAC prompt or giving any indication to the user (under default\r\nWindows 7 beta settings).\r\nTypically, Explorer.exe is targeted because it is always running to provide the Windows taskbar and desktop.\r\nHowever, innocuous programs such as Calc.exe and Notepad.exe can also be targeted, launching them first if\r\nrequired. Like the proof-of-concept program, the targeted process is unelevated (and must be for direct code-injection to work).\r\nThe target process can have ASLR on or off and can be 32-bit or 64-bit; neither matters. (However, ASLR should\r\nmean that it would be difficult to launch a code-injection attack directly and reliably from a remote-code-execution exploit. Such an exploit would probably have to write-out and launch a separate EXE.)\r\nThe underlying problem is that the silent elevation feature, enabled by default in Windows 7 beta, does not check\r\nwhere the code requesting elevation comes from. It checks which process it is running within but not the particular\r\ncode came from. So, for example, if you inject code into Explorer, or get Explorer to load your DLL, then you can\r\ncreate elevated COM objects without the user's knowledge or consent.\r\nThere are many ways to get your code into another process that's running at the same security level. That usually\r\nisn't a problem because there's usually nothing you can do in that other process that you can't already do in your\r\nown. The silent elevation feature changes that.\r\nGetting your code into another process can be done in various ways. You can use buffer-overflow exploits\r\n(although ASLR helps greatly to mitigate those) or you can install yourself as a plugin DLL which the targeted\r\nprogram loads, like an Explorer shell extension. My proof-of-concept program uses a well-known technique\r\ncalled code injection. Code injection has the advantage that you don't have to trick the target program into loading\r\nyour code; you simply push it into the other process and tell it to run it. This isn't a hack, either; everything is done\r\nusing documented, supported APIs. (Legitimate uses of the APIs include debugging and inter-process\r\ncommunication. The APIs do not require elevation to use.)\r\n(Note: The Wikipedia article on code injection is, at the time of writing, about a related but different type of code\r\ninjection. Unlike what's described there, the code-injection technique I am using does not depend on feeding the\r\ntarget program a specially-crafted input that confuses it. Instead, I am calling Windows APIs which allow one\r\nprocess to copy code and data into another and then make that target process execute the code. The technique is\r\noften called DLL injection in the Windows world, but that name isn't accurate here because I am not injecting a\r\nDLL. I am copying, or injecting, the code directly from my in-memory exe to the target process. Update: A second\r\nhttp://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nPage 8 of 23\n\ntechnique which does use a DLL is used as well now, but the main technique discussed here still doesn't invole\r\nDLLs. See the source archive for details.)\r\nUpdate: Now that the Program and Source Code have been released you can download it or, read it online, to see\r\nexactly what it does. I have also written a separate step-by-step guide which goes into more detail about exactly\r\nwhat the source does, including the CRYPTBASE.DLL issue which had not been discussed before the source\r\nrelease (June 2009).\r\nUAC in Vista and Windows 7: Mistakes then and now\r\nConsider this combination:\r\n1. UAC in Vista was criticised mainly because of the excessive frequency of prompts.\r\nMicrosoft want to reduce the number of prompts. Nobody is against them doing that. The problem is how\r\nthey are doing it.\r\n2. The excessive prompts were due to the way UAC was used at the application level, not the design of\r\nUAC itself.\r\nIn general, UAC was a well-designed, flexible and secure elevation API. However, converting old code to\r\nuse UAC and provide a good user experience requires refactoring. Microsoft failed to do this in Vista and\r\nin particular with Windows Explorer, the Control Panels and Properties dialogs. Rather than refactor they\r\nretrofitted existing code and this resulted in excessive UAC prompts. (See \"UAC Comparison\" below.)\r\n3. UAC in Vista provided a good security layer between admin and non-admin code and user\r\ninterfaces.\r\nUAC was not a security boundary in the strict technical sense but it did do a good job of making it very\r\ndifficult to cross from one side to the other without user consent. That is worth keeping.\r\n4. With Windows 7, Instead of modifying their application-level software to use UAC better, Microsoft\r\nhave taken the easy way out and modified UAC to allow their software -- and only their software, or\r\nso they intended -- to elevate for free, without prompting.\r\nIn other words, Microsoft are still avoiding the refactoring work which their code has desperately needed\r\nsince the early versions of Vista.\r\n5. In doing so Microsoft have created several obvious, easy-to-exploit and inherent flaws.\r\nHad they created secure silently-elevating processes then, perhaps, they could have argued that their code\r\ndeserved special trust; they could have argued that it was too dangerous to allow silent elevation for any\r\nthird-party code. They failed spectacularly to so and thus cannot be allowed to argue either point. Beta or\r\nnot, you design security in from day one, not at the last minute. Even if they patch over some of the\r\nsecurity issues the fact is that the system is inherently flawed and more holes will be found in time. The\r\nbest they can do, without drastic changes, is obfuscate things.\r\nhttp://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nPage 9 of 23\n\nAnother thing: The design of UAC in Vista shows that Microsoft had already predicted the very problems\r\nthey are now opening up in Windows 7. Things which Vista's UAC went out of its way to prevent are now\r\nnot only allowed but used routinely.\r\n6. The real aim of UAC, we are told, is to coerce developers into refactoring their software.\r\nWhile trying to dismiss the holes they've opened up, some from Microsoft appear to be saying that UAC\r\nisn't supposed to be a security feature for admins at all. Instead, it seems, its aim is to coerce third-party\r\ndevelopers into making their software to work better with limited user accounts and over-the-shoulder\r\nelevation, not requiring admin rights all the time (for that increases the attack surface), and elevating only\r\nwhen required without nagging the user too much...\r\n7. The eventual goal of UAC is to have everyone running as standard users, not admins, and yet:\r\nNothing has improved for non-admins.\r\nThe imbalance between admin and non-admin has grown.\r\nIf people complained about UAC as admin on Vista they'll complain even more about running\r\nas non-admin.\r\nIn the rush to respond to complaints about running as administrator it seems the situation for standard users\r\n-- the stated end-game for UAC -- was completely overlooked. Standard users still get just as many UAC\r\nprompts as before. Crucially, since non-admins (understandably) have to type an admin password for every\r\nprompt, running as standard user is more annoying than running as admin was on Vista. Since Microsoft\r\nknow that running as admin on Vista was too annoying for many people they can't seriously think that\r\npeople are going to switch to an even more annoying standard user account in Windows 7. If they wanted\r\npeople to switch then they should have been working to improve the user experience of that mode (or all\r\nmodes), not add silent elevation for admins and make it even more convenient for people to use the admin\r\nmode they want them to move away from.\r\nLeaving UAC as it was and refactoring the Windows applications \u0026 applets to use UAC better would have\r\nmade Windows better for all types of user and would have encouraged people to move to non-admin\r\naccounts, all without creating such large security issues.\r\nNow, wait a minute...\r\nUAC exists to make developers change their code. Microsoft retrofitted UAC to their code but it annoyed too\r\nmany people. Microsoft needed to refactor their own code but decided it was too hard (or failed to imagine how it\r\ncould be done). So they left their code the same, and instead changed UAC to exempt themselves from having to\r\ndo the job properly. Yet they still expect everyone else to do the hard work they failed to do, using the system they\r\nthemselves designed. On top of this, in the quest to make their own apps less annoying with as little effort as\r\npossible, they have made the whole OS less secure under default settings and made the admin/non-admin choice\r\neven more weighted towards the admin option. And they have done nothing to improve the user experience of\r\nthird-party apps under UAC for any type of user. Nor that of unbundled Microsoft apps such as the popular\r\nSysInternal tools which require elevation. Under default settings they are forcing UAC prompts on third-party\r\ncode purely to maintain the illusion of security while giving their own poorly designed apps a free pass and\r\ndismissing new local code elevation issues.\r\nhttp://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nPage 10 of 23\n\nSecurity has being reduced, the quest towards non-admin accounts has been harmed and third-party applications\r\nare being punished all for Microsoft's failure to properly design around their own API.\r\nWe should not accept this.\r\nMicrosoft: Eat your own dog food before feeding it to us!\r\n(This section wouldn't be complete without a quick mention of the UAC Secure Desktop feature: Great idea but\r\nwhat went wrong with the implementation? It seems somewhat dependent on the videocard brand/driver and\r\nsystem load but, whoever is responsible, it simply isn't acceptable for the whole desktop to go unresponsive and\r\nturn completely black -- worse if you have multiple monitors -- for up to 10 seconds while Windows does who-knows-what before the dimmed desktop -- still annoying with large/multiple monitors -- and UAC prompt actually\r\nappear and allow you to continue (perhaps after another 10 seconds of black screen(s)). I really cannot believe that\r\nmodern hardware has to take that long to switch from one picture and mouse/keyboard input queue to another. If\r\nthat switch was implemented better then UAC would have been half as painful. That's one thing I do blame UAC\r\nitself for, or maybe a particular popular video card vendor if it's their fault, rather than the applications that use\r\nUAC.)\r\nUAC Comparison: Two file-managers\r\nI make the claim that UAC itself is okay and the problem has largely been how it has been used at the application\r\nlevel, particularly in Windows Explorer and the Control Panels. Since Vista's release UAC has always allowed\r\napplications to cache their elevated objects for as long as they need to. If the same program shows you two\r\nprompts it's because it was designed that way, not because UAC forced it to.\r\nHere is some evidence to back that up.\r\nThe two videos below were made back in 2007 just over two months after Vista's released. They compare two file\r\nmanagers on Vista: Windows Explorer and Directory Opus. Note how much better the user experience is when\r\nusing Opus compared to Explorer. Then note how much longer Microsoft had to redesign their file manager for\r\ntheir API and wonder how they did such a bad job. Then wonder why they decided to improve nothing about the\r\nway UAC was used in Windows 7 and instead botched the default UAC mode to cover up their annoying prompts\r\nwhile still expecting everyone else to do a better job, now on an unlevel field.\r\n(Vista SP1 was released since these videos were made and improved Explorer's handling of new folder creation.\r\nPerhaps someone saw my video? I don't know. So maybe this isn't a fair comparison today but note that only the\r\nnew folder case was improved and the excessive prompting in Explorer continues to this day for other actions,\r\neven in Windows 7 (build 7000) if you disable silent elevation. Even if Vista SP1 had fixed the other cases, which\r\nit didn't, by then the bad taste had already been left in people's mouths.)\r\nhttp://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nPage 11 of 23\n\n2007 video: See how Opus behaved compared to Explorer's gratuitous UAC prompting.\r\nOpus, again back in 2007, also included an Administrator Mode option where you could click a button, consent\r\nto just one UAC prompt and then perform as many admin actions as you wanted to until a time limit (which you\r\nspecified) ran out. A lot of people criticised UAC for not having a mode like this, like other platform's have, but\r\nthere was nothing about UAC itself preventing such a thing from being implemented:\r\n2007 video: Administrator Mode in Opus.\r\nNote that Delete Confirmation was turned off for this video. The Delete Confirmation setting is\r\nindependent of admin mode.\r\nIt's worth pointing out that Administrator Mode in Directory Opus does open as security hole. If you choose to use\r\nit and consent to the UAC prompt then you are sacrificing some security for some convenience while the mode is\r\nactive. You will have a non-admin window from which you can trigger actions on an elevated COM object and\r\nthat window is vulnerable to other non-admin applications sending it mouse and keyboard events. Also, if you run\r\nOpus buttons which you've configured to launch third-party apps (usually command-line driven batch-processing\r\ntools that are run on the selected files) then they will be run with admin access. The assumption is that if you\r\nswitch into admin mode to run such a command then it's intended to modify the files and thus the command needs\r\nwrite access to them.\r\nhttp://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nPage 12 of 23\n\nThis is different to what Microsoft have done with their applications on Windows 7: On Windows 7 (build 7000\r\nwith default settings), Explorer (among other things) is always running in this insecure mode. There's no UAC\r\nprompt when you enter it (because you're always in it). You can't turn it on and of as and when you wish to\r\nperform a bulk of admin actions and sacrifice security for convenience, except by changing the system-wide UAC\r\nlevel (which is hardly convenient, either). In Opus you have to opt-in to use Administrator Mode by clicking a\r\ntoolbar button (which isn't shown in the UI by default) and then consenting to the one-off UAC prompt. That UAC\r\nprompt in turn prevents other programs triggering the mode by themselves, though they could obviously wait for\r\nit to happen.\r\nI'm not saying this Administrator Mode is right for all programs or even right for all Opus users. I rarely use it\r\nmyself as I don't find the normal UAC prompts annoying, outside of exceptional circumstances. I'm just showing\r\nit as a demonstration that UAC is a flexible API and there are more ways to use it than many people realise.\r\nIf a whitelist makes sense then it must be user-configurable\r\n(I talk about the concept of a whitelist here. As currently implemented, special elevation privileges are granted via\r\nmanifest attributes and code signing, rather than a literal list, but conceptually the two are the same.)\r\nLet's play a game of what if... I don't believe there would be a need for a whitelist if application-level code such as\r\nExplorer and the Control Panels were improved, but let's assume I'm wrong and a whitelist is needed.\r\nThe default UAC setting in Windows 7 is: \"Don't notify me when I make changes to Windows settings.\"\r\nWhat this really means is: \"Don't notify me when Microsoft applications* require administrator rights.\"\r\n(*Or malware, but let's pretend the whitelist could be made secure for a moment.)\r\nAt the moment the whitelist, if you use it at all, is hardcoded and only for Microsoft's own code. Users cannot add\r\nthird-party apps to the list. Users also cannot remove Microsoft apps from the list. This was confirmed by\r\nMicrosoft Online Community Support in a microsoft.public.win32.programmer.kernel thread:\r\nThe change we made in Windows 7 default UAC settings is that any operation that is necessary to\r\nmanage windows will not require an elevation - which in technical terms translates into a white list of\r\ntrusted action / binaries which the user can make perform without UAC prompting from an elevation.\r\nThis list does include windows file operations.\r\nYou see a prompt in your File Manager program because your binary is not an inbox binary - i.e. not\r\nan executable which ships with windows. Hope that explains and clarifies. For security considerations,\r\nWindows 7 does not allow any 3rd party binary to be in the Windows trusted list. Therefore, your File\r\nManager program still needs to handle the elevations.\r\nThere are several other worthwhile comments in the short thread discussing user experience issues as well as the\r\npitfalls of developers having to workaround the problem via their own solutions in order to provide parity with\r\nMicrosoft's components.\r\nThe \"for security considerations\" part of the quote above is particularly ironic given it is this very whitelist which\r\nhas opened a hole in UAC which allows silent elevation for any process that doesn't care about doing things\r\nhttp://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nPage 13 of 23\n\nproperly (or 100% reliably) and uses the backdoor.\r\nIf we are to have whitelisting then why is it limited to only Microsoft's code? And why can't the user remove\r\nparticular Microsoft binaries from the whitelist?\r\nMicrosoft cannot argue that it's too risky to let users whitelist third-party code:\r\nBy creating so many obvious security flaws just in the way UAC has been abused in Windows 7, Microsoft\r\nhave demonstrated -- without the need to look through history -- that they are no better at making secure\r\napplication-level code than anyone else. Microsoft's user-mode executables have not earned special\r\ntreatment when it comes to security or trust. The core OS should treat them with the same level of distrust\r\nas any other unelevated process making the same API calls.\r\nIf people want to whitelist some of the Microsoft executables then that's up to them but there is nothing\r\ninherently trustworthy about them. (In addition, since they are well known and installed on every system,\r\ngranting them whitelist status is more risky than doing the same to third-party or unbundled code.)\r\nMicrosoft cannot argue that it's too risky to let users whitelist third-party code because Microsoft's own\r\ncode has shown a disregard for preventing other processes hijacking its special elevation status.\r\nAllowing users to add third-party code to the whitelist cannot make things less secure, only less\r\nannoying:\r\nAs it stands, if the whitelist is enabled at all, UAC prompts can be bypassed by anything that wants to. It is\r\ntherefor hard to imagine how UAC could provide less security if the user was able to whitelist chosen,\r\ntrusted and regularly used third-party programs.\r\nWith the whitelist enabled UAC prompts are nothing more than security theater that protects against very\r\nlittle and only really gets in the way of legitimate programs and user-triggered actions, both of which the\r\nuser will consent to when prompted. Seeing a UAC prompt when you do certain things in certain programs\r\nmay give the illusion that UAC is still doing something towards your security but in reality it isn't doing\r\nmuch.\r\nThe prompts in Vista, and in Windows 7 if you change to Always Prompt mode, made it very difficult for\r\nunelevated processes to gain elevation. In Windows 7's default mode you might as well turn the prompts\r\noff entirely.\r\nThis also applies to non-bundled Microsoft applications such as the SysInternals tools. Why is it that Task\r\nManager can create an elevated version of itself without prompting but if you use the superior Process\r\nExplorer then you have to confirm its launch via a prompt? Where is the security benefit here given that\r\nmalicious code can bypass the prompt and Microsoft, so far, seem to say they don't care and have no\r\nintention of changing anything?\r\nThe inability to remove unused apps from the whitelist means security is being traded for nothing in\r\nreturn:\r\nhttp://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nPage 14 of 23\n\nA whitelist is about trading some security for some convenience. Every program on the whitelist adds to\r\nthe attack surface of code that potentially can be exploited to gain admin rights. Every single item on the\r\nwhitelist trades off a bit of security by making such an exploit more likely to be found.\r\nIf some of the whitelisted components are ones which the user rarely/never uses, what exactly is gained in\r\nreturn for this reduced security?\r\nFor example, I do not use Windows Explorer; I use another file manager. If I left the whitelist on then I\r\nwould want to remove Explorer from. The only thing that might try to modify a protected folder on my\r\nmachine using Explorer is a piece of software remote controlling Explorer either by sending mouse and\r\nkeyboard events to it or, like my proof-of-concept program, by code-injection. I gain no convenience by\r\nhaving Explorer on the whitelist.\r\nI also gain no convenience from having things like Calc.exe, Notepad.exe and MSPaint.exe on the COM\r\nelevation whitelist when they are programs which never actually use COM elevation unless something else\r\nhas injected code into them!\r\nToo many UAC prompts encourage users to turn off UAC; it doesn't matter which vendor causes the\r\nprompts:\r\nPeople typically use software because it lets them do what they want, not because it's internally well\r\ndesigned or secure. If someone wants to use a program that triggers a lot of UAC prompts then they are\r\nmore likely to turn off UAC than to switch programs.\r\nSo, if the aim of the whitelist is to make UAC more bearable and discourage people from turning off\r\nprompts entirely then people need to be able to whitelist whichever applications they want. That way they\r\nwill keep UAC on and UAC will still catch things done by programs they don't use often, or new programs.\r\n(Assuming, of course, that Microsoft manage to improve the UAC whitelist implementation so that\r\nmalicious software cannot bypass the whole thing!)\r\nAs said earlier, the excuse that UAC is supposed to make developers write better code does not wash when\r\nMicrosoft's response to that challenge was to exempt their own code from UAC. If it's good for the goose\r\nthen it's good for the gander.\r\nPrevious Windows 7 UAC issues\r\nFor completeness, a quick note about two other issues which were found in Windows 7's UAC shortly after the\r\npublic beta was released. These were discovered and proved by Rafael Rivera Jr. and Long Zheng.\r\nMicrosoft initially seemed to disregard these two issues but, in the face of widespread criticism, apparently had a\r\nchange of heart and said they'd be fix them in the Windows 7 release candidate.\r\n(Let me stress that fixes for these two issues do not affect the code-injection issue that most of this page is about.\r\nThe code-injection issue has so far had no substantial response from Microsoft.)\r\nSendKeys:\r\nhttp://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nPage 15 of 23\n\nSince the UAC control panel was not an elevated process/UI it was possible for a very simple piece of VBScript to\r\nopen the control panel and then send keyboard events which moved the UAC slider and applied the change. Due\r\nto the elevated COM object which controls UAC being on the whitelist (list 2 in the section far above) there was\r\nno UAC prompt when the change was made. Microsoft have since promised that the UAC control panel will be in\r\nan elevated process/UI to prevent this from working. However, they themselves point out that many other control\r\npanels will still be in unelevated processes/UIs, using silently elevated COM objects. That means the SendKeys\r\nattack can still be used in lots of other places to mess with admin settings unless you set UAC to Always Prompt.\r\nRafael's Within Windows: Malware can turn off UAC in Windows 7; \"By design\" says Microsoft\r\nI Started Something: Sacrificing security for usability: UAC security flaw in Windows 7 beta (with proof\r\nof concept code)\r\nI Started Something: Microsoft dismisses Windows 7 UAC security flaw, continues to insist it is \"by\r\ndesign\"\r\nI Started Something: Microsoft changes Windows 7 UAC control panel behavior to address security flaw\r\nRunDll32.exe\r\nRafael discovered that RunDll32.exe was given auto-elevate (list 1) status. RunDll32.exe is a program which can,\r\nessentially, be told to run any other program. Because it auto-elevated it could be used to run anything with\r\nadministrator rights without triggering a UAC prompt and without the launching process requiring administrator\r\nrights.\r\nThis is supposed to have been fixed in later internal betas but, as far as I know, there has not yet been any\r\nconfirmation of this or what the fix is, exactly.\r\nRafael's Within Windows: Windows 7 auto-elevation mistakes lets malware elevate freely, easily\r\nI Started Something: Second Windows 7 beta UAC security flaw: malware can silently self-elevate with\r\ndefault UAC policy\r\nDeja Vu: Joanna Rutkowska and Vista\r\nAlthough they're about Vista rather than Windows 7, it's also worth reading Joanna Rutkowska posts from\r\nFebruary 2007 and the responses (or lack of) they generated, for deja vu if nothing else:\r\nInvisible Things: Running Vista Every Day!\r\nInvisible Things: Vista Security Model -- A Big Joke?\r\nInvisible Things: Confusion about the \"Joke Post\"\r\n(Yep, UAC wasn't perfect back then either, but shouldn't Joanna's WM_KEYDOWN issue have been fixed rather\r\nthan dismissed? If it required changes to accessibility software then fine, say so and make it an aim for the future,\r\nbut don't say it's not important. Shouldn't the aim be to make UAC as secure as possible rather than to move in the\r\nopposite direction and make it a joke which insults third-party developers and tricks users into a false sense of\r\nsecurity?)\r\nTo those saying, \"but it requires code to get on the box\"\r\nhttp://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nPage 16 of 23\n\nEngineering Windows 7 blog:\r\nI really don't buy the logic behind this statement on Microsoft's Engineering Windows 7 blog (which was written\r\nafter the RunDll32.exe issue was found but before this page/issue was published):\r\nIt is important to look at the first step—if the first step is \"first get code running on the machine\" then\r\nnothing after that is material, whether it is changing settings or anything else.\r\nThis isn't true. Yes, a problem which allows remote execution is far more important than one which allows local\r\nelevation. However, it very much is material whether or not a remote execution exploit can be turned into a remote\r\nadmin code execution exploit. And there are other ways to get code to run on a box. Indeed, if all code already on\r\nthe machine was immaterial then why do we have UAC prompts for anything in the first place? Are the prompts\r\njust there for show; just security theater?\r\nAlso, why do we have the Secure Desktop for UAC prompts if not to prevent running, supposedly-trusted\r\napplications from clicking their own UAC pompts and elevating without the user's permission?\r\n(In both Windows 7 and Vista you can configure UAC to \"Elevate Without Prompting\". That most keeps UAC on\r\nbut automatically accepts all elevation requests. It still forces developers to write code that supports UAC, over-the-shoulder elevation for non-admin users, running minimal code at admin level, and so on. So the excuse that\r\nUAC prompts only exists to pester developers doesn't wash either.)\r\nEither it is important to prevent random processes from elevating arbitrarily and silently, or it isn't:\r\nIf it is important then Microsoft cannot dismiss this code-injection issue (or the SendKeys/RunDll32.exe\r\nissues which the E7 post was responding to).\r\nIf it isn't important then the default UAC mode should get rid of all UAC elevation prompts for all\r\napplications, not just the Windows ones and the ones that bypass the prompts via exploits. In other words,\r\nrun in the \"UAC but without any prompts\" mode that Vista already had.\r\nI can see arguments for and against both bullet points.\r\nSome people want to know when code they run requests full admin: More security and less convenience.\r\nSome people implicitly trust any code they run and have it granted automatically: Less security and more\r\nconvenience.\r\nI'm cool with people in either camp. What I cannot accept is an argument for any mixture of the two: Less security\r\nand less convenience. It makes no sense to punish well-behaved apps by making them inflict UAC prompts on\r\ntheir users while ignoring apps that use exploits by allowing them to bypass the prompts (not to mention the\r\nmalware that people do end up running, one way or another).\r\nIf prompts are important then they should not be something you can bypass with a trivial amount of code. On the\r\nother hand, if prompts are not important then let's get rid of them completely by default. Pick one.\r\nYou can't say that process elevation is worth protecting against when it's convenient (i.e. in places where Windows\r\n7 already prompts by default and requires no code/design changes) while simultaneously saying that process\r\nhttp://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nPage 17 of 23\n\nelevation isn't an issue in cases where it isn't convenient (convenient to the Windows 7 ship date, that is :-)). That's\r\nillogical, captain.\r\nWhen the prompts are so easy to bypass by anything that wants to, having the prompts at all is pure security\r\ntheater.\r\nSecunia (via The Register):\r\nSecunia said something similar in response to The Register's coverage of this code-injection issue:\r\nThis isn't a major issue; after all it requires that the user already downloaded some executable code\r\nand decided to run it. No matter which security features have been built into the operating system, then\r\nthe user should never run code, which they don't trust in the first place. Untrusted code should only be\r\nrun on dedicated test systems.\r\nFirst, it seems that Secunia's response is aimed at corporations who are unlikely to be affected by the problem at\r\nall because they tend to run everyone as non-admin anyway. General home users are unlikely to have \"dedicated\r\ntest systems\" on which to test untrusted code.\r\nSecond, as for it not being a \"major issue:\" I don't dispute that there are more important issues, in particular\r\nremote code execution issues. Obviously. That does not mean that this issue is not worth worrying about, however.\r\nIt can be used in conjunction with a remote code execution to worsen the damage. You do not wait until someone\r\ncombines issues into a blended attack before you acknowledge them. Malicious code does get on to people's\r\nmachines. That's a fact of life. People can be tricked into running things that don't look like executables, which is\r\nthe rampant Conflicker Worm is doing as I type this. Even if we ignore trickery, exploits are regularly found\r\nwhich allow remote code execution though no action or fault of the user.\r\nOnce code gets on to a machine, one way or another, it's important to minimize what it can do. If someone finds a\r\nremote execution exploit in a non-admin process then it should not be easy for them to use it to gain full admin\r\naccess. They can still do damage to an affected user's files but damaging the entire machine/OS should not be\r\nmade easy, especially with methods which are completely silent to the user and do not arouse any suspicion (e.g.\r\nunexpected UAC prompts or visible user-interface remote-control). Especially when this problem was not that in\r\nVista. The hole I have found allows non-admin code to elevate to full admin without the user seeing anything at\r\nall. The only reason the proof-of-concept videos show a UI is for demonstration purposes.\r\nSo while it isn't the most important security hole in the world -- and nobody ever said it was -- I find it strange that\r\nit could be considered unimportant... I guess it's all relative, though. (It is relatively unimportant compared to a lot\r\nof what Secunia look at, to be fair!) And, certainly, it's not important if you turn UAC up to its highest level, but\r\nthe defaults need to be considered because that's what most people will use.\r\nIf you do consider it unimportant that, with the default settings, code can elevate itself freely once on the box then\r\nyou must follow that to its logical conclusion. If local process elevation is a non-issue, and given that it's broken\r\nby default in Windows 7 anyway, then Windows 7 should default to elevate without prompting and not inflict\r\nUAC prompts on any programs. If people want to argue that then it's fine by me, provided I still have the option of\r\nsetting UAC to always prompt on my own machine.\r\nhttp://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nPage 18 of 23\n\nMore to the point, there were better ways that Microsoft could have made UAC less annoying without opening\r\nsuch a large hole, as I explained in detail above.\r\nTo those saying, \"but UAC isn't a security boundary\"\r\nThat is a cop-out, IMO. Yes, there were ways things could piggy-back on or spoof elevations on Vista. Just\r\nbecause you can break some glass to enter a house doesn't mean you leave the doors unlocked, though.\r\nFirst, I'm not aware of any UAC hole in Vista that could not be fixed. Changing the command prompt registry\r\nsetting is often brought up as an example, so I'll use that: MS could fix that by making admin command prompts\r\nignore the HKCU settings and only read from HKLM or an admin-ACL'd part of HKCU. Or by making either the\r\nUAC prompt itself or the admin process confirm to the user what it was about to run before it happens. (The OS\r\nneeds to prove some way for elevated processes, whether by admin-approval or over-the-shoulder, to confirm\r\nwhat they ahve been asked to do before they go and do it.) Or maybe stuff like making Windows Defender alert\r\nyou if the HKCU value is changed... There's a bunch of ways that problem could be addressed, as with every other\r\nI'm aware of. None of them are an excuse to ignore the code-injection issue in Windows7; rather, they are just\r\nother flaws in UAC (and how UAC is used) which should also be addressed.\r\n(Following on from that, almost all of the piggy-back and spoofing issues apply eqally to over-the-shoulder\r\nelevation.)\r\nSecond, I think there's a significant difference between a program being able to gain elevation silently, the\r\nmoment it wants to, and one which has to lie in wait for the user to do something it can exploit. Using the same\r\nexample agan, if something wants admin on my box and modifies the command prompt settings in HKCU, it still\r\nhas to wait for me to launch an elevated command prompt. It could be days before I trigger the action it is waiting\r\nfor. Meanwhile it has to hope that I don't notice whatever changes it has made and, more importantly, that my anti-virus tool doesn't get an update which detects those changes. On the other hand, if something doesn't have to wait\r\nto get full admin access then it can immediately install a rootkit which means the anti-virus tool may not be able to\r\ndetect it even after a signature update.\r\nI mean, think about a typical single-user home or small office computer: What's important? Your data is important.\r\nYou don't want something to delete or steal your private data, but full admin rights are not required for that so\r\nUAC is irrelevant to that discussion. It's also important to prevent your computer from being remote controlled,\r\ne.g. as a spam zombie, but once again admin rights are not required for that. Admin rights let things jump from\r\none user to another but typically there only is one real user (possibly with multiple accounts) on the machines\r\nwhere UAC is used at all.\r\nThe main reason I can think of that a typical home user should care about software gaining full admin rights, over\r\ngaining any control to the system at all, is that with those rights it can hide itself deeply and never be detected (or\r\nonly be detected a very long time in the future), or maybe install low-level stuff like keyboard hooks to sniff\r\npasswords. In cases like those I think it does matter how long something has to wait to gain that access. If\r\nsomething has got on my machine through a remote execution exploit in Adobe Flash (or whatever) and I've had\r\nmy data compromised, or become part of a botnet, then that really sucks. But it'll suck even more if I don't realise\r\nit's going on for six months instead of a day. I'm not saying a solid UAC will always prevent that from happening\r\nhttp://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nPage 19 of 23\n\nbut it could prevent it in some cases and should do a hell of a lot more than a UAC which can be trivially\r\nbypassed.\r\nThird, what is UAC actually supposed to do? The reality is that you'll get a different answer from different people.\r\nSometimes if you ask the question in different contexts you will get a different answer from the same people.\r\nBecause UAC is a fuzzy thing that's supposed to kinda help make things sort-of more secure and also to kinda\r\nforce developers to do some stuff differently, without breaking anything or annoying any one too much, and it's all\r\na bit undefined, and Microsoft now have one set of rules for themselves and another set of rules for everyone\r\nelse... The realiy is that UAC does whatever it's most convenient to tell you it does at any particular time, and\r\ngoals that UAC had in Vista have apparently been reduced -- or removed entirely by revisionism -- in Windows 7.\r\nI'm asking for UAC's purpose to be properly and explicitly defined and for Microsoft to then consistently and\r\nfairly stand behind whatever that is, for both their own software and third-paty software. (And if getting people to\r\nrun as standard user is really the aim of UAC, and not just a BS excuse to ignore the problems people raise, then\r\nit'd be nice if Microsoft actually made doing that not a giant pain in the behind that is even worse than the UAC\r\nprompts they know people don't like.) There are more of my arguments along these lines throughout this page but\r\nI'll repeat one more example of the schizophrenia: Why do we have a Secure Desktop for UAC prompts if it\r\ndoesn't matter that applications can silently elevate via a backdoor?\r\nTo those saying, \"but it's only a beta\"\r\nOf course Windows 7 is only a beta. All of us trying to expose the problems introduced by the UAC changes hope\r\nthat Microsoft will improve things before Windows 7 ships. However:\r\nIt took a lot of people making a lot of fuss to make Microsoft take notice of the first two UAC flaws.\r\nIgnoring the Web2.0 abuse of the phrase, the point of a beta version is to allow testing and feedback. We\r\nare testing and providing feedback on UAC. Too many people seem to think that \"beta\" means \"a way for\r\nme to get a shiny new piece of software early.\" Stop it.\r\nLike it or not, Microsoft tend to do a terrible job at fixing things in a reasonable amount of time. There are\r\nmany examples but for a particularly bad one, consider the file-corruption bug in Windows Home Server\r\nwhich was known about when the OS was in beta and not fixed until a year after it was released to retail.\r\nSecurity design and code is best done sooner rather than later. It is very difficult to take an insecure design\r\nand make it secure. The sooner problems start to be addressed the better.\r\nMicrosoft have said there will not be another public beta of Windows 7. The next public release will be\r\nRC1. Windows 7 is clearly on an aggressive release schedule.\r\nThere is no point waiting until the retail release of Windows 7 to complain. Getting Microsoft to change\r\nanything in Windows after a version has shipped is like pulling teeth. By then it is too late. It may already\r\nbe too late but we live in hope.\r\nUpdate: Windows 7 RC1 (build 7100) is out now and nothing has changed in this area. (A lot of other stuff\r\nhas changed and it's a better version of Windows, but the UAC/injection stuff still works like it used to.) It\r\nnow seems even more unlikely that anything will be changed in time for the RTM, especially as MS still\r\nhaven't replied to my offers to give them full details.\r\nQuick response to a couple of newer things:\r\nhttp://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nPage 20 of 23\n\nI should work these into the main page but don't have the time/energy, so I'll put them here for now.\r\nInside Windows 7 User Account Control by Mark Russinovich in the July 2009 TechNet Magazine:\r\nSome good technical information there explaining how the manifests etc. work.\r\nIMO, though, it contains the usual contradictory reasoning about what UAC prompts are for and not for\r\nthat is coming out of Microsoft. I have a lot of respect for Mark Russinovich and he obviously knows more\r\nabout Windows than I do but I disagree with much of what he says on this matter.\r\n\"From the perspective of malware, Windows 7's default mode is no more or less secure than the Always\r\nNotify mode (\"Vista mode\"), and malware that assumes administrative rights will still break when run in\r\nWindows 7's default mode.\"\r\nFollowing that argument through, the \"silently elevate\" setting is no more or less secure as well, so why\r\naren't Microsoft using that as the default? Why are they making third party apps (as well as Mark's own\r\napps!) look bad and annoy users if it provides no benefit?\r\nIf the UAC prompts serve no purpose for admin users, except to force vendors to change their apps, then\r\nwhy did MS fail to change their own apps and why did they make themselves exempt from the prompts but\r\nnot allow others to do the same?\r\nHe says the code-injection method isn't trivial, yet it only took me a couple of days to research \u0026 write\r\nfrom scratch and I'm an app developer, not a hacker/cracker. Perhaps not trivial but not time consuming,\r\neither. It'll certainly be trivial once the source code is released (by me or by or someone else who bothered\r\nto write something similar) as you just call an function with the command you want to run and it happens.\r\nHowever, I do agree that it's not something legitimate software should rely upon. (And yet, if third parties\r\nwant to offer the same user experience which Microsoft allow for their own software, using this method is\r\nthe least-work alternative. That sucks. The other alternatives are convincing users that the UAC prompts\r\nare pointless and that they should turn them -- but not UAC itself -- off, or writing a service which runs as\r\nadmin and accepts requests for work that requires admin rights, which is a lot more effort, difficult to\r\nsecure and wasteful of resources. That sucks, too!)\r\nIf the prompts provide no security for admin accounts, and you don't care if the prompts can be\r\nbypassed for admin accounts, then turn the prompts off for admin accounts for all apps. You can still\r\nkeep UAC and make it so that apps have to ask for administrator rights to get them (so that old malware\r\nfails by default and so that apps support elevatrion from standard user account). What is the benefit of the\r\nprompts for admin users if Microsoft do not want to make the improvements required to turn them into a\r\nsecurity feature (and indeed if MS are working in exactly the opposite direction)? There is none. So turn\r\noff the prompts for admin users (without turning UAC itself off).\r\nAnd, as I've said already, if MS think people are going to switch to standard user accounts and type a\r\npassword for every elevation -- while also making changes to Windows 7 which admit that the less-annoying UAC button-click prompts for admin accounts in Vista were too annoying for many people to use\r\n-- then they must be smoking high-strength crack.\r\nhttp://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nPage 21 of 23\n\n\"We understand the aggravation, and there might be a legitimate reason that those applications can't run\r\nwithout administrative rights, but the risk is too high that developers will avoid fixing their code to work\r\nwith standard user rights.\"\r\nThat comment seems disingenuous to me. Making do not prompt the default UAC level (at least for COM\r\nelevation) would not allow developers to avoid fixing their code. Developers would still need to deal with\r\nthe UAC API and request elevation in a way which would work under standard user accounts. The only\r\ndifference would be that the requests would not trigger a prompt. That's how it works for Explorer in\r\nWindows 7; why can't it work that way for everyone?\r\nIt makes no sense. The argument seems to be that, simulataneously, silent elevation from limited admin to\r\nfull admin is too dangerous to allow third-parties to use and yet it's no problem at all -- not even worth\r\nasking for the full details of! -- if it can be triggered via a workaround. If the UAC prompts are so useless\r\nthen switch them off.\r\nThe current Windows 7 defaults are anti-competitive security theater. Microsoft need to stand up and admit\r\nit.\r\nThe discussion after Vista should have been about how to make it harder to spoof UAC prompts -- e.g. by\r\nthe protected-side code telling you more information about what it had been asked to run by the\r\nunprotected-side code, and closing off holes like the HKCU cmd.exe registry settings -- and about how to\r\ndesign software to minimize the number of prompts -- and retarded prompts-about-prompts in particular --\r\nper logical operation. (Or you could give up and turn off the prompts for admin users in all software, but\r\nthat still doesn't make UAC stop sucking for the barely-existent \"standard user account that might elevate\"\r\ncase who seems to be the excuse for the mess. I'm not saying there aren't a lot of standard-user accounts out\r\nthere in businesses but I am saying that very few of them use UAC to elevate to administrator, and in the\r\nhome it's similar because it's such a pain to type the password for every UAC prompt, which MS know and\r\nadmit by their changes to Win7's admin accounts.) Instead the discussion is this waste of time where we're\r\narguing about the validity of MS adding a hack just for themselves which makes things even worse. Sigh.\r\nMark also fails to acknowledge that many UAC prompt spoofs which would work with an admin account\r\non Vista would work just as well with a standard user account on Vista or Windows 7. He's pointing out a\r\nflaw in the old system as an excuse for the new system's design, yet that flaw still exists in the new system.\r\nI have a lot of respect for Mark but I think his reasoning is inconsistent here. It reads more like an after-the-fact excuse for a poorly designed, unfair and schizophrenic system rather than a solid set of design goals\r\nwhich producted a system that works as well as it could.\r\nPCMag: Bogus Claims of Win7 UAC Vulnerabilities\r\nThis blog post was published in a couple of places. I'll re-post my response here (which so far has not been\r\nreplied to):\r\nLarry,\r\nhttp://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nPage 22 of 23\n\nYou seem to fall into the \"UAC is pointless\" side of the camp, which is fine. Argue for it [the prompts] to\r\nbe turned off completely in that case. That has not happened, though, so you should be just as annoyed by\r\nthe Windows 7 changes as anyone else as they have made UAC *even more pointless*.\r\nYou also seem to be saying it doesn't matter because people should be running as standard user, and not\r\ndoing admin things at all. While it may be true that they should be, it is not true that they are. It is unlikely\r\nto ever be true unless Microsoft significantly improve the experience of standard users, which they have\r\nnot.\r\nThe facts are:\r\nAdministrator is the default. You have to go out of your way to change it.\r\nPeople *do* do Administrator tasks. If they didn't then UAC would not have annoyed anyone in the\r\nfirst place and the Windows 7 changes would never have happened. I doubt that will ever change.\r\nPeople were too annoyed by the UAC prompts on Vista when running as an Administrator and\r\nMicrosoft clearly realised this (but their solution is terrible). (PERSONALLY, I thought UAC in\r\nVista was fine, but perhaps that's because I don't use Windows Explorer which is the reason for a lot\r\nof UAC's irritation.)\r\nIf people were annoyed by the UAC prompts on Vista there is absolutely no way they will put up\r\nwith the standard user prompts in Windows 7 (which are essentially the same as they were in Vista,\r\nand much *worse* than the admin prompts in Vista which caused the UAC backlash in the first\r\nplace).\r\nWindows 7's changes have made it *more* tempting to run as an administrator, not less. They're a\r\nstep in the wrong direction if your aim is for everyone to run as standard user.\r\n\"Bear in mind that you and Davidson are arguing for the Vista-style UAC.\"\r\nI am not so much arguing for Vista-style UAC as against Windows 7-style UAC. You're creating a false\r\ndichotomy by equating the two positions.\r\n\"Isn't the consensus that this was a flop in the market? Do you have any constructive advice for\r\nMicrosoft?\"\r\nYes, plenty. Did you actually read my page? :) I know it's long and rambling and really needs editing, but it\r\nis full of examples of how UAC could have been done better without the Windows 7 mess.\r\nNot just theoretical examples, either. Many of the examples are implemented in a commercial app where\r\nthe UAC-related code was written back in 2007 before anyone had heard of Windows 7.\r\nAs I've said in several places, people asked for change but nobody asked for *this*.\r\nSource: http://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nhttp://www.pretentiousname.com/misc/win7_uac_whitelist2.html\r\nPage 23 of 23",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"http://www.pretentiousname.com/misc/win7_uac_whitelist2.html"
	],
	"report_names": [
		"win7_uac_whitelist2.html"
	],
	"threat_actors": [
		{
			"id": "aa73cd6a-868c-4ae4-a5b2-7cb2c5ad1e9d",
			"created_at": "2022-10-25T16:07:24.139848Z",
			"updated_at": "2026-04-10T02:00:04.878798Z",
			"deleted_at": null,
			"main_name": "Safe",
			"aliases": [],
			"source_name": "ETDA:Safe",
			"tools": [
				"DebugView",
				"LZ77",
				"OpenDoc",
				"SafeDisk",
				"TypeConfig",
				"UPXShell",
				"UsbDoc",
				"UsbExe"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "e993faab-f941-4561-bd87-7c33d609a4fc",
			"created_at": "2022-10-25T16:07:23.460301Z",
			"updated_at": "2026-04-10T02:00:04.617715Z",
			"deleted_at": null,
			"main_name": "Longhorn",
			"aliases": [
				"APT-C-39",
				"Platinum Terminal",
				"The Lamberts"
			],
			"source_name": "ETDA:Longhorn",
			"tools": [
				"Black Lambert",
				"Blue Lambert",
				"Corentry",
				"Cyan Lambert",
				"Fluxwire",
				"Gray Lambert",
				"Green Lambert",
				"Magenta Lambert",
				"Pink Lambert",
				"Plexor",
				"Purple Lambert",
				"Silver Lambert",
				"Violet Lambert",
				"White Lambert"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "70db80bd-31b7-4581-accb-914cd8252913",
			"created_at": "2023-01-06T13:46:38.57727Z",
			"updated_at": "2026-04-10T02:00:03.028845Z",
			"deleted_at": null,
			"main_name": "Longhorn",
			"aliases": [
				"the Lamberts",
				"APT-C-39",
				"PLATINUM TERMINAL"
			],
			"source_name": "MISPGALAXY:Longhorn",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "23dfc9f5-1862-4510-a6ae-53d8e51f17b1",
			"created_at": "2024-05-01T02:03:08.146025Z",
			"updated_at": "2026-04-10T02:00:03.67072Z",
			"deleted_at": null,
			"main_name": "PLATINUM TERMINAL",
			"aliases": [
				"APT-C-39 ",
				"Longhorn ",
				"The Lamberts ",
				"Vault7 "
			],
			"source_name": "Secureworks:PLATINUM TERMINAL",
			"tools": [
				"AfterMidnight",
				"Assassin",
				"Marble Framework"
			],
			"source_id": "Secureworks",
			"reports": null
		}
	],
	"ts_created_at": 1775434428,
	"ts_updated_at": 1775791877,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/d450f878fa7e9d72fb598857abddbb92122e7aad.pdf",
		"text": "https://archive.orkl.eu/d450f878fa7e9d72fb598857abddbb92122e7aad.txt",
		"img": "https://archive.orkl.eu/d450f878fa7e9d72fb598857abddbb92122e7aad.jpg"
	}
}