Mark Russinovich’s technical blog covering topics such as Windows troubleshooting, technologies and security.
PingBack from http://winblogs.security-feed.com/2006/05/01/the-power-in-power-users/
# re: The Power in Power Users
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?
5/1/2006 12:55:00 PM by Kevin Dente
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".
5/1/2006 12:58:00 PM by Adam Gates
Perhaps you're referring to Domain Controller installs of the server OSs?
Correct, thanks. I've changed the text to clarify.
5/1/2006 1:01:00 PM by Mark Russinovich
Power Users does not have backup or restore privileges.
5/1/2006 1:03:00 PM by Mark Russinovich
The Macromedia issue is supposed to have been fixed:
5/1/2006 3:16:00 PM by Aaron Margosis
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
5/1/2006 3:19:00 PM by Paul Kierstead
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.
5/1/2006 3:21:00 PM by Mark Russinovich
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)
5/1/2006 4:54:00 PM by Anonymous
I found a very nice GUI tool to edit DACL's on services: http://msdn.microsoft.com/msdnmag/issues/05/03/SecurityBriefs/
5/2/2006 7:45:00 AM by Anonymous
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.
5/2/2006 9:27:00 AM by 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?
5/2/2006 12:21:00 PM by Sean P. Kane
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.
5/2/2006 4:00:00 PM by Paul Kierstead
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.
5/2/2006 5:44:00 PM by Anonymous
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.
5/2/2006 9:30:00 PM by jsminch
Paul - take a look at this analysis done by eWeek:
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.
5/2/2006 9:47:00 PM by Wes
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.
5/2/2006 10:53:00 PM by Anonymous
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.
5/3/2006 8:04:00 AM by Mark Russinovich
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.
5/3/2006 8:47:00 AM by Wes
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. :-)
5/3/2006 1:06:00 PM by Anonymous
Thanks Mark! That was very insightful and interesting...
5/3/2006 8:43:00 PM by Michael
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
5/4/2006 2:40:00 AM by mats
"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.
5/4/2006 8:32:00 AM by Anonymous
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?
5/4/2006 1:45:00 PM by Michael Gibson
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?
5/5/2006 11:35:00 AM by Anonymous
No. Group memberships don't behave that way. If the user is an administrator, they are an administrator.
5/5/2006 3:49:00 PM by Wes
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.
5/8/2006 4:38:00 PM by Anonymous
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.
5/8/2006 6:04:00 PM by Anonymous
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.
5/9/2006 12:57:00 AM by stephen
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?
5/9/2006 6:56:00 AM by Paul Coddington
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?
5/9/2006 1:05:00 PM by jawz101
This was Digg-ed before - but it deserved front page status...
Let's try again. The Article and the Comments are quite helpful
5/9/2006 9:48:00 PM by http://search-engines-web.com/
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
Thanks Mark for the article.
5/10/2006 10:28:00 AM by Eric T
Eric T., thank you very much for information and step-by-step instructions.
5/10/2006 12:35:00 PM by Anonymous
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: http://www.adobe.com/support/techdocs/331688.html
The Macromedia License Manager buletin and update are available here: http://www.adobe.com/devnet/security/security_zone/mpsb05-04.html
There is also a list of all current security bulletins and a signup page for notifications available from http://www.adobe.com/support/security
Secure Software Engineering
Adobe Systems, Inc
5/11/2006 11:08:00 AM by 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?
5/11/2006 1:41:00 PM by Eric T
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 microsoft.com/download after installation automaticaly trigger critical security update.
5/12/2006 11:49:00 PM by Anonymous
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? :-)
5/15/2006 10:56:00 PM by Anonymous
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?
5/25/2006 10:57:00 AM by Anonymous
Cool writing! I'll definitely be looking into writing services the next week!
th ej or ak |AT| gm ai l. co m
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
# Johnny has admin privileges
5/26/2006 11:09:00 AM by KRundern
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.
5/28/2006 11:38:00 AM by KevFrey
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.
5/29/2006 9:58:00 PM by Anonymous
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...
5/30/2006 5:40:00 AM by Anonymous
No doubt the Vista team has read the blog and signed the obligitory check to Mark once again.
6/1/2006 8:15:00 PM by Anonymous
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.
6/7/2006 11:00:00 AM by KhyberKitsune
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
6/8/2006 4:26:00 AM by William Gunaratne
there is no cookie for you..
Move out to a supermarket, or a bar nearby to pick up some for the night
6/8/2006 6:33:00 AM by Anonymous
Greate article Mark
I miss you new articles, make some more
6/8/2006 6:38:00 AM by Anonymous
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.
6/9/2006 9:30:00 PM by Anonymous
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.
6/17/2006 8:47:00 PM by Anonymous
>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: http://www.microsoft.com/downloads/details.aspx?familyid=9d467a69-57ff-4ae7-96ee-b18c4790cffd
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.
6/19/2006 12:03:00 PM by Eric T
Ops, I posted wrong url. The correct is: http://www.microsoft.com/downloads/details.aspx?FamilyID=e8ba3e56-d8fe-4a91-93cf-ed6985e3927b
6/19/2006 12:23:00 PM by Eric T
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).
6/19/2006 5:10:00 PM by John M
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.
6/19/2006 10:45:00 PM by ytjohn
You have to have administrative powers to begin with to replace logon.scr. Here's the output of Accesschk:
R BUILTIN\Power Users
RW NT AUTHORITY\SYSTEM
6/20/2006 8:04:00 AM by Mark Russinovich
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?
6/24/2006 2:24:00 AM by Anonymous
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?
6/27/2006 6:49:00 AM by Anonymous
>>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 http://www.lvllord.de/?lang=en&url=tools for example.
I do not know if a power user is given write access to tcpip.sys by default.
6/29/2006 11:44:00 PM by Anonymous
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.
7/9/2006 5:27:00 AM by Brugte biler
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...
7/9/2006 10:37:00 AM by Anonymous
7/20/2006 7:10:00 AM by Mark Russinovich
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.
7/21/2006 1:07:00 PM by rex
Great article (as usual), very instructive about how to think about priviledge excalation.
Regarding your June 20th post (apparently) answering June 8th Will Gunaratne's remark about logon.scr: I understand Will was speaking about NT4; and on NT4, AccessChk definitively shows RW access (including for Everyone):
RW BUILTIN\Opers. de servidores
7/24/2006 9:46:00 AM by Antoine
Regarding PatchGuard in XP x64, PatchGuard does a conditional jump if there is a kernel debugger present and skips activation. A hexedit could turn the conditional jump into an unconditional jump.
8/1/2006 7:19:00 PM by andreyvul
If you have physical access to a computer you can get in and do anything you want.
What you want to prevent is a program running as user or power user from getting administrator rights and doing anything it wants. (spy/adware keylogers worms)
Mark used to sell a nice utility called locksmith that did a fine job of changing the administrator password.
And with a PE disk you can do anything to the file system because your system
There are ways to secure your physical computer. But most places don’t bother.
If you are an “End user” at a corporation and you are thinking about trying anything in this posting you better have a backup job. At my company we have fired employees for much less rooting there box.
8/1/2006 9:52:00 PM by Chris Thornton
At school, I had to install dlportio (turing parallel port driver). It required admin priveleges, so I pooped in a password recovery floppy to copy the hashes. The weaknesses of the NT LM hash allowed me to "un-hash" the passwords.
If the computer has a floppy, the password is recoverable (loginrecovery.com)
You could also try putting the image onto a USB key.
8/3/2006 2:35:00 PM by andreyvul
There is a simple way for a Power User to create a local admin account, if they can use the MMC, which worked for me on an XP-SP1 machine. Mark's technique is interesting but likely to be useful only to those who don't really need it, whereas my technique could be used by a child. Which is why I won't post it. A serious problem with User accounts that we have here at the (big) bank is that the local support staff keeps elevating them to admins. So the IT department doesn't know, or doesn't know the extent, that their account policies are not being enforced. The attempt to lock down the desktop here is quite a farce, given that Microsoft Office is installed everywhere, not to mention WSH, etc. Since the IT department has demonstrated that they can't get the apps to install and run consistently for Users, it would be best to just make everyone a Power User. If the end user is truly incompetent, which some are, they can be demoted to User. And if they elevate to Admin on their own, they can be shown the door.
(Snail) Mail specialist
9/26/2006 5:28:00 PM by Anonymous
Love the article. Is there a way to use Accesschk with a domain group? I try it and I get 'The specified user does not exist'. If not does anyone know of one?
9/26/2006 6:14:00 PM by eric
A little over a year ago I set out to determine exactly why, prior to Window Vista, the Power Users security