Sysinternals Freeware - Mark Russinovich & Bryce Cogswell

Mark's Sysinternals Blog

The Power in Power Users

Placing Windows user accounts in the Power Users security group is a common approach IT organizations take to get users into a least-privilege environment while avoiding the many pains of truly running as a limited user. The Power Users group is able to install software, manage power and time-zone settings, and install ActiveX controls, actions that limited Users are denied.

What many administrators fail to realize, however, is that this power comes at the price of true limited-user security. Many articles, including this Microsoft Knowledge Base article and this blog post by Microsoft security specialist Jesper Johansen, point out that a user that belongs to the Power Users group can easily elevate themselves to fully-privileged administrators, but I was unable to find a detailed description of the elevation mechanisms they refer to. I therefore decided to investigate.

Before I could start the investigation, I had to define the problem. In the absence of a security flaw such as a buffer overflow privilege escalation is possible only if an account can configure arbitrary code to execute in the context of a more-privileged account. The default accounts that have more privilege than Power Users include Administrators and the Local System account, in which several Windows service processes run. Thus, if a Power Users member can modify a file executed by one of these accounts, configure one of their executables to load an arbitrary DLL, or add an executable auto-start to these accounts, they can obtain full administrative privileges.

My first step was to see what files and directories to which the Power Users group has write access, but that limited users do not. The systems I considered were stock Windows 2000 Professional SP4, Windows XP SP2, and Windows Vista. I'm not going to bother looking at server systems because the most common Power Users scenario is on a workstation.

The brute force method of seeing what file system objects Power Users can modify requires visiting each file and directory and examining its permissions, something that’s clearly not practical. The command-line Cacls utility that Windows includes dumps security descriptors, but I’ve never bothered learning Security Descriptor Description Language (SDDL) and parsing the output would require writing a script. The AccessEnum utility that Bryce wrote seemed promising and it can also look at Registry security, but it’s aimed at showing potential permissions weaknesses, not the accesses available to particular accounts. Further, I knew that I’d also need to examine the security applied to Windows services.

I concluded that I had to write a new utility for the job, so I created AccessChk. You pass AccessChk an account or group name and a file system path, Registry key, or Windows service name, and it reports the effective accesses the account or group has for the object, taking into consideration the account’s group memberships. For example, if the Mark account had access to a file, but Mark belongs to the Developers group that is explicitly denied access, then AccessChk would show Mark as having no access.

In order to make the output easy to read AccessChk prints ‘W’ next to the object name if an account has any permissions that would allow it to modify an object, and ‘R’ if an account can read the object’s data or status. Various switches cause AccessChk to recurse into subdirectories or Registry subkeys and the –v switch has it report the specific accesses available to the account. A switch I added specifically to seek out objects for which an account has write access is –w.

Armed with this new tool I was ready to start investigating. My first target was a Windows XP SP2 VMWare installation that has no installed applications other than the VMWare Tools. The first command I executed was:

accesschk –ws “power users” c:\windows

This shows all the files and directories under the \Windows directory that the Power Users group can modify. Of course, many of the files under \Windows are part of the operating system or Windows services and therefore execute in the Local System account. AccessChk reported that Power Users can modify most of the directories under \Windows, which allows member users to create files in those directories. Thus, a member of the Power Users group can create files in the \Windows and \Windows\System32 directory, which is a common requirement of poorly written legacy applications. In addition, Power Users needs to be able to create files in the \Windows\Downloaded Program Files directory so that they can install ActiveX controls, since Internet Explorer saves them to that directory. However, simply creating a file in these directories is not a path to privilege elevation.

Despite the fact that Power Users can create files underneath \Windows and most of its subdirectories, Windows configures default security permissions on most files contained in these directories so that only members of the Administrators group and the Local System account have write access. Exceptions include the font files (.fon), many system log files (.log), some help files (.chm), pictures and audio clips (.jpg, .gif, and .wmv) and installation files (.inf), but none of these files can be modified or replaced to gain administrative privilege. The device drivers in \Windows\System32\Drivers would allow easy escalation, but Power Users doesn’t have write access to any of them.

I did see a number of .exe’s and .dll’s in the list, though, so I examined them for possible exploits. Most of the executables for which Power Users has write access are interactive utilities or run with reduced privileges. Unless you can trick an administrator into logging into the system interactively, these can’t be used to elevate. But there’s one glaring exception: ntoskrnl.exe:

That’s right, Power Users can replace or modify Windows’ core operating system file. Five seconds after the file is modified, however, Windows File Protection (WFP) will replace it with a backup copy it retrieves, in most cases, from \Windows\System32\Dllcache. Power Users doesn’t have write access to files in Dllcache so it can’t subvert the backup copy. But members of the Power Users group can circumvent WFP by writing a simple program that replaces the file, flushes the modified data to disk, then reboots the system before WFP takes action.

I verified that this approach works, but the question remained of how this vulnerability can be used to elevate privilege. The answer is as easy as using a disassembler to find the function that Windows uses for privilege checks, SeSinglePrivilegeCheck, and patching its entry point in the on-disk image so that it always returns TRUE, which is the result code that indicates that a user has the privilege being checked for. Once a user is running on a kernel modified in this manner they will appear to have all privileges, including Load Driver, Take Ownership, and Create Token, to name just a few of the privileges that they can easily leverage to take full administrative control of a system. Although 64-bit Windows XP prevents kernel tampering with PatchGuard, few enterprises are running on 64-bit Windows.

Replacing Ntoksrnl.exe isn’t the only way to punch through to administrative privilege via the \Windows directory, however. At least one of the DLLs for which default permissions allow modification by Power User, Schedsvc.dll, runs as a Windows service in the Local System account. Schedsvc.dll is the DLL that implements the Windows Task Scheduler service. Windows can operate successfully without the service so Power Users can replace the DLL with an arbitrary DLL, such as one that simply adds their account to the Local Administrators group. Of course, WFP protects this file as well so replacing it requires the use of the WFP-bypass technique I’ve described.

I’d already identified several elevation vectors, but continued my investigation by looking at Power Users access to the \Program Files directory where I found default permissions similar to those in the \Windows directory. Power Users can create subdirectories under \Program Files, but can’t modify most of the preinstalled Windows components. Again, the exceptions, like Windows Messenger (\Program Files\Messenger\Msmgs.exe) and Windows Media Player (\Program Files\Windows Media Player\Wmplayer.exe) run interactively.

That doesn’t mean that \Program Files doesn’t have potential holes. When I examined the most recent output I saw that Power Users can modify any file or directory created in \Program Files subsequent to those created during the base Windows install. On my test system \Program Files\Vmware\Vmware Tools\Vmwareservice.exe, the image file for the Vmware Windows service that runs in the Local System account, was such a file. Another somewhat ironic example is Microsoft Windows Defender Beta 2, which installs its service executable in \Program Files\Windows Defender with default security settings. Replacing these service image files is a quick path to administrator privilege and is even easier than replacing files in the \Windows directory because WFP doesn’t meddle with replacements.

Next I turned my attention to the Registry by running this command:

accesschk –swk “power users” hklm

The output list was enormous because Power Users has write access to the vast majority of the HKLM\Software key. The first area I studied for possible elevations was the HKLM\System key, because write access to many settings beneath it, such as the Windows service and driver configuration keys in HKLM\System\CurrentControlSet\Services, would permit trivial subversion of the Local System account. The analysis revealed that Power Users doesn’t have write access to anything significant under that key.

Most of the Power Users-writeable areas under the other major branch of HKLM, Software, related to Internet Explorer, Explorer and its file associations, and power management configuration. Power Users also has write access to HKLM\Software\Microsoft\Windows\CurrentVersion\Run, allowing them to configure arbitrary executables to run whenever someone logs on interactively, but exploiting this requires a user with administrative privilege to log onto the system interactively (which, depending on the system, may never happen, or happen infrequently). And just as for the \Program Files directory, Power Users has default write access to non-Windows subkeys of HKLM\Software, meaning that third-party applications that configure executable code paths in their system-wide Registry keys could open security holes. VMWare, the only application installed on the system, did not.

The remaining area of exploration was Windows services. The only service permissions AccessChk considers to be write accesses are SERVICE_CHANGE_CONFIG and WRITE_DAC. A user with SERVICE_CHANGE_CONFIG can configure an arbitrary executable to launch when a service starts and given WRITE_DAC they can modify the permissions on a service to grant themselves SERVICE_CHANGE_CONFIG access. AccessChk revealed the following on my stock Windows XP SP2 system:

I next ran PsService to see the account in which the DcomLaunch service executes:

Thus, members of the Power Users group can simply change the image path of DComLauncher to point at their own image, reboot the system, and enjoy administrative privileges.

There can potentially be other services that introduce exploits in their security. The default permissions Windows sets on services created by third-party applications do not allow Power Users write access, but some third party applications might configure custom permissions to allow them to do so. In fact, on my production 64-bit Windows XP installation AccessChk reveals a hole that not only Power Users can use to elevate themselves, but that limited users can as well:

I’d now finished the major phase of my investigation and just confirmed what everyone has been saying: a determined member of the Power Users group can fairly easily make themselves full administrator using exploits in the operating system and ones created by third-party applications.

My final step was to see how Microsoft’s approach to the Power Users account has evolved over time. This 1999 Microsoft Knowledge Base article documents the famous screen-saver elevation vulnerability that existed on Windows NT 4, but Microsoft closed that hole before the release of Windows 2000. The KB article also shows that Microsoft was apparently unaware of other vulnerabilities that likely existed. Windows 2000 SP4 also includes holes, but is actually slightly more secure than the default Windows XP SP2 configuration: Power Users don’t have write access to Ntoskrnl.exe or the Task Scheduler image file, but instead of write-access to the DComLauncher service they can subvert the WMI service, which also runs in the Local System account.

Windows XP SP1 added more Power Users weaknesses, including write access to critical system files like Svchost.exe, the Windows service hosting process, and additional services, WMI and SSDPSRV, with exploitable permissions. Several services even allowed limited users to elevate as described in this Microsoft KB article from March of this year.

Microsoft’s newest operating system, Windows Vista, closes down all the vulnerabilities I’ve described by neutering Power Users so that it behaves identically to limited Users. Microsoft has thus closed the door on Power Users in order to force IT staffs into securing their systems by moving users into limited Users accounts or into administrative accounts where they must acknowledge end-user control over their systems.

The bottom line is that while Microsoft could fix the vulnerabilities I found in my investigation, they can’t prevent third-party applications from introducing new ones while at the same time preserving the ability of Power Users to install applications and ActiveX controls. The lesson is that as an IT administrator you shouldn’t fool yourself into thinking that the Power Users group is a secure compromise on the way to running as limited user.

posted by Mark Russinovich @ 11:01 AM

Great article. One question though. You say "note that the Power Users group doesn’t exist on server operating systems like Windows 2000 Server and Windows Server 2003". But the "Power Users" group definitely does exist on server OSs (at least on mine they do). Perhaps you're referring to Domain Controller installs of the server OSs?
Another way has to do with the Power Users right's to Backup and Restore files.
During the Restore Operation the Power User has to create the ACL for restored object.
During this process the to Power User is granted something called a Program Right? This right allows them to modify the ACL to whatever it was when the file was backed up in spite of the fact they may not have permissions to the current object or file.

Internal Microsoft Support has a tiny .Exe that mimics this situation and allows you to change the permissions on files and objects at will as if they were being "restored from tape".
Perhaps you're referring to Domain Controller installs of the server OSs?

Correct, thanks. I've changed the text to clarify.
Another way has to do with the Power Users right's to Backup and Restore files.

Power Users does not have backup or restore privileges.
The Macromedia issue is supposed to have been fixed:
Although you are certainly right in that Power Users does not stop a focused attack, it certainly helps limit *accidental* damage (often well meaning) by users, which is a large part of what IT departments deal with. In that respect, it remains a useful comprimise.

Of course, the difference between preventing fraud and preventing error is rarely differeniated by vendors, making it difficult to assess the use of many features
Although you are certainly right in that Power Users does not stop a focused attack, it certainly helps limit *accidental* damage

All you need is a piece of malware to accidentally take advantage of the elevation path.
@Aaron Margosis:

There are several other unfixed third-party services:

- Adobe License Manager (Photoshop and Co. - wooh, I needed a crack to make it run without AdobeLM)
- Novell NetDrive (damn, I liked it)
- under certain conditions: Superior SU
- Apple's Bonjour
- VMware has already been named
- even the SafeDisc CD Copy Protection driver that is shipped with Windows will be messed up after being updated by any modern game (even after uninstallation)
I found a very nice GUI tool to edit DACL's on services:
The downside of limiting access is that it makes removing malware more difficult. On the one hand, you're making it more difficult for malware to take hold, and on the other, more difficult to remove the ones that get in. The problem remains the same: The design of Windows is severely flawed as far as security is concerned. They should've kept it simpler by segregating the registry better, ditching COM and IE from the core OS functionality. Now, it's just a hodge-podge of tweaks to close this hole or that hole The cheese remains swiss:-) Good article.
jason star-

Difficult removal of malware that takes hold in a user account is news to me. Isn't it as simple as logging on to a local Administrator account (obviously not by an end-user) and continuing with normal malware removal techniques?
All you need is a piece of malware to accidentally take advantage of the elevation path.

Not all security is about malicious attacks. In fact, quite a large amount of security is about preventing errors. In this context, the Power Users account makes some sense; it is not useless at all. In addition, it provides *some* level of defense against attacks, but reducing the number of available attack vectors and blocking/limiting numerous known attacks.

I am not defending the limitations of using it, simply pointing out that it has its uses in the evironment that we are stuck with at this time. For TRA purposes, it closes some problems over Administrator and may be work the risk for some. That said, I do look forward to improved windows security in Vista, but I am not holding my breath.
Thus, members of the Power Users group can simply change the image path of DComLauncher to point at their own image, reboot the system, and enjoy administrative privileges.

Pardon me for being ignorant, but I just don't understand the above concept. What is image path? How can I change it?

Can someone, please, enlighten me or just put me in the right direction.

Thank you very much.
the Power Users account makes some sense; it is not useless at all.

I agree. It's nice to be able to perform some administrative tasks (installing programs, changing some system settings, etc.) without logging on as an administrator. Like Mark pointed out, some exploits could count on an administrator logging on interactively.
"Run as" takes care of some of this though (esp. in XP) and Vista's "User Account Control" will hopefully take care of the rest. If it does, then Power User will be truely useless, if not, then I will miss it quite a bit.
Paul - take a look at this analysis done by eWeek:,1759,1891447,00.asp

In it, they compared the vulnerabilities picked up when running XP and 2000 as User, Power User, and a local Administrator. The reality is that it provided almost no protection. The Power User group is far too close to an Administrator (which is what Mark's analysis really showed) to do much good. The use of Power Users (and the fact that the group exists) generally provides a false sense of security. Take a look at Jesper's post - linked from within Mark's post here - which will point out that even in a senior Microsoft Security expert's opinion, a Power User is an Administrator who hasn't made themselves one yet.
Again a useful investigation Mark,

As has already been mentioned by a few other posters, the Power Users account also helps to prevent shooting oneself in the foot. I think you would have to be living on a different planet to think that the Power Users concept was bulletproof, but you would have to agree that you are 'safer' under power users than under administrator. While it doesn't prevent someone on a mission to elevate themselves, I believe it is better than nothing when it comes to somewhat restricting access to average computer users.

Until you can change the time and switch power modes, limited user accounts are simply too impractical for a lot of people (especially laptop users) every day use.

Is there any technical reason that anyone other than the administrators group would need access to the kernal? I can't think of one.

Note that the eWeek study shows that most malware writes to the Run key in HKLM\Software and the \Windows directory and so doesn't work in a limited-user environment, but does in Power Users. That will change over time, especially after the release of Vista, as malware adapts to a limited-user environment.

The study does not reflect the fact that malware can take control of the system using the techniques I outline.

Just another reason not to run as Power Users.
There is a policy which can be modified to allow accounts - including users - to change the system time. If users honestly need to modify the power configuration on a regular basis, the ACL for the power configuration key in the registry can be loosened to allow it. Neither is a strong enough reason to blow holes in security and have users run as Power Users.
Mark, I really appreciate the way you "think out loud" for lack of a better description. It helps clarify my own thought processes and increases my problem solving ability.

Please keep it up. :-)
Thanks Mark! That was very insightful and interesting...


The Idea behind using Power Users isn't about stopping malware or other unwanted code.

It is about preventing user errors. In some cases you simply can't have the users running as users. Then the alternatives are power users or administrators.

Even though malware can exploit power users it still is better then making them admins in the first place.

in this matter I'm not worried about users that know how to elevate themselfes, I'm worried about the users that doesn't have any clue about that they are doing. Here the few restrictions on power users will save us some work
"a Power User is an Administrator who hasn't made themselves one yet."

I know I have :)

seriously, if you install a service standard on every desktop that runs as localsystem, make sure the user can't replace it with their own. In this case PCAnywhere.
After reading this, I investigated my PC (XP with SP2 integrated into the install files), and discovered something worrying about the first account that is created.

That first account is by default a member of the Administrators group, and even after changing it to a Limited User, the account retains many write privileges to files in \WINDOWS\Driver Cache\i386 and \WINDOWS\system32 - presumably owner rights?
Anyone know if adding a user to all groups would limit a user's permissions even though they are in the administrator/power user groups. Do lower groups take any precedence if they are in more than one?
No. Group memberships don't behave that way. If the user is an administrator, they are an administrator.
same guy as 2 above:
I'd agree but my mgr recently added an account for desktop personnel to all other groups (pwr users, bckup ops, remote desktop, guests, users, etc) so other depts that had local admin rights who deleted our local admin permissions may not restrict all of our permissions on the pc's.
I don't know why he chose to do that, but in light of it when we log on we our now unable to use Window's Updates site. Once we removed our group out of the Guests local group it worked. It seems the Guest group superceded other local permissions.
For interest I had a look at a couple of popular anti-virus services and some exhibit similar permission problems.

In particular TrendMicro PCCillin makes it very trivial for any normal user (not even PowerUser) to obtain admin permissions. I knocked up a quick service replacement for tmntsrv.exe that grants a nominated user administrative privileges and without even needing a restart. As a normal user I was able to stop the real service, replace the service EXE with the new one, restart the service and was easily granted admin permissions (tmntsrv.exe runs as System). Extremely trivial to accomplish. Why normal users have change permissions to the EXE in Program Files is a concern.
For interest I had a look at a couple of popular anti-virus services and some exhibit similar permission problems.

I think the easiest way is to open up the Windows task manager and look for those processes run as system. On my machine I can easily replace several of these third party services with my own to run as system and administrative privilege is obtained.
It seems to me that the Power User group is frequently abused as a shortcut to making a program work that merely requires write access to a badly placed INI file.

It should be possible to set the folder permissions to allow a writable INI yet still lock down all executable file permissions within the folder to prevent substitution. Problem is: someone has to do it.

One of the things that strikes me as ironic is how certain popular anti-spyware and antivirus programs require the user to have administrator privileges. Sort of a 'we’ll protect you from 70% of burglars if you allow them all unrestricted access to your house' policy.

I wonder what proportion of malware can be blocked by running as a standard user account?

I also wonder if this question is never asked because it is bad for sales?
Same Anonymous user from a few posts ago:

Our desktop mgr had our desktop group added to all groups because some techs in other depts were removing us from local admins and he wanted to insure that we had some rights on the machines (I don't know why but he included us in the pwr usr group as well as users, bckup ops, and guests)
With us added to the guests group it wouldn't allow us to run Windows Update site even though we were in the local admin group. Should Guests permissions supercede Local Admin rights like that?
This was Digg-ed before - but it deserved front page status...

Let's try again. The Article and the Comments are quite helpful

Digg Article
The following services are exploitable from every account:

Adobe LM Service
Macromedia Licensing Service
Autodesk Licensing Service

Here is an example for AutoCAD 200? users:

sc stop "Autodesk Licensing Service"
sc config "Autodesk Licensing Service" type= own type= interact
sc config "Autodesk Licensing Service" binpath= "cmd /c start cmd"
sc start "Autodesk Licensing Service"

Now run pwdump2 or pwdump3 & after that LC4.

If you get the admin password there is no need for:
net localgroup administrators your_user_account /add

Have fun.

Thanks Mark for the article.
Eric T., thank you very much for information and step-by-step instructions.
Hi Mark,

This is a great article. If I may, I'd like to point people to a couple of security bulletins that were published about a year ago that provide fixes for the issues you note in Macromedia and Adobe Systems products.

The Adobe License Manager bulletin and update are available here:

The Macromedia License Manager buletin and update are available here:

There is also a list of all current security bulletins and a signup page for notifications available from


Adrian Ludwig
[email protected]
Secure Software Engineering
Adobe Systems, Inc
@Adrian Ludwig:
If I may, I'd like to point people to a couple of security bulletins that were published about a year ago …

Yeah, yeah first release a crippleware then waits someone to say “ouch, there is a security problem here” & after that issue fixes. Again and again the picture is the same.

1. Why use a service for licensing purposes?
2. How many SOHU users read security bulletins for 3rd party products?

Interestingly when MS will incorporate in the OS an automatic patch management system for 3rd party products?

Interestingly when MS will incorporate in the OS an automatic patch management system for 3rd party products?

Only after they will stop distributing unpatched software on their own /downloads website.

For example Microsoft Excel 20003 viewer directly downloaded from after installation automaticaly trigger critical security update.
@Adrian Ludwig:

This is untrue. Photoshop CS2 still suffers from exactly that problem, and I'm afraid to tell you we had to use a crack to make this legally purchased product get running (and it runs fine without AdobeLM). And when will you fix that damn installer? There's absolutely no need for the dependency on IIS Virtual RootFolders components.

> Only after they will stop
> distributing unpatched software on
> their own /downloads website.

Like MSIE? :-)
Hello Everyone, I was also curious about image paths being a noob...? AF

Mark, another great article! thank you...oh hey, can I look in your window internals book to find this answer?
Cool writing! I'll definitely be looking into writing services the next week!

- KRundern
th ej or ak |AT| gm ai l. co m

PS: @Anonymous:
Guest "privileges" superseed Admin privileges because it has the DENY setting set, and DENY "is greater" than the ALLOW setting that the Admins have. If the Guest group didn't have the settings tagged at all, your Administrator privileges would superseed, but as the DENY flag is set, it doesn't.

Unlucky you, have fun and go slap your "guru"...

Privilege Escalation, you said? Surprisingly easy at these times...
I just tried the old GetAdmin exploit (first exploit I ever used), and - it worked!
Windows XP sp2, fully patched (I turned off my antivir that blocked it :)
Elegant and easy
>getadmin.exe johnny
# Johnny has admin privileges
Adam wrote: Until you can change the time and switch power modes, limited user accounts are simply too impractical for a lot of people (especially laptop users) every day use.

There are several reasons to not ever allow domain users (and one might argue especially for mobile users) to change their system time - not the least of which is keeping a consistent time across all systems (synched with a central time server) in your enterprise for log and event correlation. Additionally, Kerberos can get really whacked out (technical term ;-) with significant time changes, and many replication-enabled programs can be thrown into disarray with erratic time changes (future, then back to past across replication events).

However, most importantly from a security standpoint, if a user is allowed to change his or her system time, forensic time stamps for breach or abuse cases becomes invalid: E.g. A user wants to steal intellectual property from your organization (engineering documents, source code, etc.) and then take that information to a competitor during a job change (even if the competitor has no knowledge of this), the user can change the system time to some point in the past (say, 3 years) to hide the data copy event then change it back. Thus, a forensic analysis of the disk and copy activity would not show a correlation between that data copy event and the time frame in question (job change).

Since it is out-of-scope for this topic, we won't get into the ability to boot from CD (protected via BIOS password and boot order configuration) for a user to reinstall Windows or otherwise wipe a machine to blow away forensic evidence, but those are real systemic issues to consider when allowing users to change their own system times.
There are always things that will be critical on some systems and not a concern on others. I do not deny the need to control who has access to change the time, in fact my software is time critical. Of course the time provided by the client workstation is automatically corrected when they change it ;), but I think my point was somewhat missed possibly because I was not clear enough.

It is a bad thing for users to log themselves in as administrators, (or as discussed in the article and comments even power users). As developers, it is our responsibility to assist users and admins correct these bad habits.

To do this effectively, I put forward that we the developers must take a dose of our own medicine. If we are limited users when we develop, then we are less likely to encounter problems when we deploy, and our support departments will not have to issue workarounds that involve elevating privileges.

I simply isolated two areas of running as a limited user that really ticked me off. I will mention at this point that I am now able to change the system time and change power modes whilst still being a limited user. This involved changing the security to several registry keys as well as enabling some policy rules. I do not have a problem with these actions being denied by default (although I still can not see why power mode is relevant), the point is that administrators need an easier way to allow it.

Btw, no version control system worth having would trust a client provided timestamp for tracking, and certainly no software solution is going to stop someone flicking a few jumpers on a motherboard.

But that is beyond the point here. I need to change my system clock constantly to simulate various things which is why I needed it enabled.

I have found the next annoyance if anyone is interested. When logged in as Admin/Pwr user and windows update does its thing, you get the choice to restart now or later. As limited user, you get 5 minutes with no option to cancel. I will shutdown after work and it can do its thing tomorrow morning when I boot up. I am never in a hostile environment, I do not have a wireless card in my laptop, I have both software firewalls and hardware firewalls wherever it is docked, and I am running as a limited user. I'll take my chances thankyou.

really wondering what "version" of GetAdmin you used. I tried three of them and neither one worked on my Windows XP SP2 fully patched.

Would, please, someone explain what is image path and how to change it. Thank you...
No doubt the Vista team has read the blog and signed the obligitory check to Mark once again.
Nice article, Mark. That helped me out tremendously because I've noticed several compromised workstations. Run an MD5 hash check and I see one thing you pointed out - ntoskrnl has been modified from the original. Now I know where to start, I'm going to do a full re-imaging of all compromised machines and start running keyloggers on them to figure out who's doing what. On a side note, EMI has just released some new P2P service, and their software replaces tcpip.sys in Windows. Do you have any idea what this modified TCPIP file does? EMI just tells joe sixpack to wantonly click through all warnings. I have suspicions about this.
Great article, its great to see this type of system-assisted hacking still in use. I remember the good old NT4 days when all you needed to do was rename logon.scr and copy cmd.exe and rename it to logon.scr and then play the waiting game.
I'm also pleased to see this type of open dialogue on security and even more pleased to see we've sorted this in Vista
William Gunaratne,
there is no cookie for you..
Move out to a supermarket, or a bar nearby to pick up some for the night
Greate article Mark
I miss you new articles, make some more

Here's how to prevent Windows from automatically rebooting after installing updates when running as a limited user:

1. Open gpedit.msc from the Run dialog box.

2. Right click on Administrative Templates under Computer Configuration and choose Add/Remove Templates.

3. Press the Add button.

4. Browse to the C:\WINDOWS\Inf directory. (It should default to this location automatically.)

5. Double-click on wuau.adm

6. Click the Close button.

7. Now back in the Group Policy window expand the Administrative Templates folder, followed by the Windows Components folder. You should see a Windows Update folder.

8. In the Windows Update folder is a group policy option called "No auto-restart for scheduled Automatic Updates installations." Set this option to enabled.

Note that these steps won't work on XP Home edition due to the lack of Group Policy control. (gpedit.msc won't work) It should still be possible to get the same thing done on XP Home with a little research though. If you can figure out what registry changes the group policy setting makes you could manually apply them to a XP Home system since group policy settings are nothing more than registry modifications.

Funny part you are all missing is why arent you locking things down in the first place.

A few pointers:

Get to know Subinacl.exe and review the default OS permissions on registry services,files and folders, and drop power-users down to size if you think its such a threat.

( easy to write a subinacl.exe script to remove power users rights on all services and registry and make them as weak as the users group)

Secondly, you can use security templates via GPO's to drop the required NTFS permissions you want on files and folders, and audit modification of them from a central utility. Again baseline hardening, you don't do it up front, you bound to pay in the end.

>Funny part you are all missing is why arent you locking things down in the first place.

There is no “in the first place” for buggy third party applications. Do you expect every Small Office/Home User to become IT security paranoid – rechecking the security of its PC(s) after each software installation or even after each software update?

>Get to know Subinacl.exe and review the default OS permissions on registry services,files and folders ...

Thanks for this pointer. SubInACL is available for download from:

The version of SubInACL that is included in Windows Server 2003 Resource Kit Tools is buggy (version 4, 0, 1, 1604) – it may not parse the command line arguments correctly.

To display the security settings of all services:

subinacl /verbose=1 /nostatistic /service *

c or f grant permission for Everyone in some service probably signifies a problem.
Ops, I posted wrong url. The correct is:
A few posters have asked what is an image path. The image path is a registry entry called ImagePath, under the registry key for a service. The ImagePath controls the executable that's launched when a service starts. E.g, for the DComLauch service, the registry key is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DcomLaunch and the ImagePath setting is (on Windows 2003): %SystemRoot%\system32\svchost.exe -k DcomLaunch

so when you start the DComLaunch service, it's like typing: c:\winnt\system32\svchost.exe -k DcomLaunch at a command line (I'm oversimplifying, but I hope you get the point).
Good article. One thing that I've used many times on customer's computers is to copy cmd.exe over top of logon.scr as pretty much any power user and then log out. Wait 10-15 minutes and you get a command prompt running as SYSTEM. Type explorer and you get your basic windows desktop while running as the user SYSTEM. From here I can do anything I need to fix the system.
You have to have administrative powers to begin with to replace logon.scr. Here's the output of Accesschk:

R BUILTIN\Power Users
RW BUILTIN\Administrators
Nice article. This is further proof to me that Microsoft OS products continue to serve as nice examples of how *not* to design a computer operating system. You just can't patch security into an operating system. Will Vista finally get this right?
Interesting. Fear of Power Users had led CIS and others to remove that Power User ACL wholesale (or as much as they could find) throughout the system. This caused massive application compatibility issues for XP. I'm often steering customers away from that and towards use of Restricted Groups--place Power Users in the Restricted Groups--to block use of that security group altogether. That seems to alleviate the application compatibility issues and accomplish the same thing a lot more simply. What do you think of this approach?
>>On a side note, EMI has just released some new P2P service, and their software replaces tcpip.sys in Windows. Do you have any idea what this modified TCPIP file does?

I'm not really qualified to tell you exactly what that application does to tcpip.sys, but I know of at least one legitimate change that can be made. Hard-coded into the stock version is a limit to the number of simultaneous outbound connection attempts that can be made in one second. Several patches I have seen allow users to change this value, and the changes do trigger a warning from Windows about it being changed. See for example.

I do not know if a power user is given write access to tcpip.sys by default.
On the one hand, you're making it more difficult for malware to take hold, and on the other, more difficult to remove the ones that get in. The problem remains the same: The design of Windows is severely flawed as far as security is concerned.
Nice article Mark. Just one note, IIRC Power Users can execute AT.EXE command. Or am I wrong? It's trivial to elevate privileges using AT command...
to Anonymous(previous): you may try to change privilegies with system accounts, but at many (all, as I tried) time you will cannot do it. SYSTEM is a kernel 'administrator' with personal rights, which even not fully showed in NTFS.
Anyway, you will not be able to change local user`s privilegies to administrator role without change some files (or put them) and had logon of "real" Administrator.
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?

RSS Feed



Full Blog Index

Recent Posts

Why Winternals Sued Best Buy
The Case of the Mysterious Driver
Running as Limited User - the Easy Way
Using Rootkits to Defeat Digital Rights Management
Inside the WMF Backdoor
Rootkits in Commercial Software
The Antispyware Conspiracy
Sony Settles
Circumventing Group Policy as a Limited User
Premature Victory Declaration?


03/01/2005 - 03/31/2005
04/01/2005 - 04/30/2005
05/01/2005 - 05/31/2005
06/01/2005 - 06/30/2005
07/01/2005 - 07/31/2005
08/01/2005 - 08/31/2005
09/01/2005 - 09/30/2005
10/01/2005 - 10/31/2005
11/01/2005 - 11/30/2005
12/01/2005 - 12/31/2005
01/01/2006 - 01/31/2006
02/01/2006 - 02/28/2006
03/01/2006 - 03/31/2006
04/01/2006 - 04/30/2006
05/01/2006 - 05/31/2006
07/01/2006 - 07/31/2006

Other Blogs

Raymond Chen
Dana Epp
Aaron Margosis
Wes Miller
Larry Osterman
Bruce Schneier
Larry Seltzer