Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Ok, so I know on many unix variants, you can set up a root / admin user, a standard user, etc. And by default sometimes on some distros of Linux the 'root' superuser is known to have a default password. For example (example only) on an Oracle Linux distro the default password could be just 'oracle'.

Now on the Windows side, I'm trying to get into the system account as apparently access is being denied even running things as 'Administrator' on the computer, like regedit, can still deny me access.

I notice in task scheduler and a few other areas, there seems to be some special or encrypted password for the 'LocalService' & 'NetworkService' users, that by Microsoft were programmed to do things like start the task scheduler, run background processes, etc. So if there's a way to find out the default passwords used for these accounts, that would offer a lot of help. If not able to just de-encrpyt them, then I'll reset them if anything.

Either way, is there a default system password for Windows? I essentially need super-user access to my local machine so if there's any way you can, I'd appreciate it.

P.S. I know in the past there were some exploits I used to take advantage of (for my own use) in Windows on my machine to run things at a higher privilege level. On Windows XP, killing explorer through task manager, then starting it again via schedtasks due to a security hole that allowed this, etc.

So if at all, (and this is for my machine only, I'm not trying to do this on someone else's machine) I need to gain access to the (a?) superuser account on the machine. My best bet at this point would be to use LocalService, or SYSTEM, as it'd be far powerful enough to get the stuff I need to do done.

Thanks for your help!


share|improve this question
If you hold shift and right-click the file and select run as a different user and provide admin privileges, does this not allow the programs to work properly? – Serodis Jan 4 '12 at 0:00
For example, I need to delete a locked key, the administrator account cannot do this, but a higher-level one, like LocalService or SYSTEM, can, because it has a higher privilege level, and therfor can delete the locked key. I've tried running regedit as administrator mode, but this does not help. But please don't try and focus the question mainly on regedit, I need this for other things as well. – John Robertson. Jan 4 '12 at 0:08
Notice even though an Admin may be initially denied, an Admin also has the seize ownership priv and can thus change any permissions at will. – surfasb Jan 4 '12 at 0:11
@JohnRobertson.: The same ACLs that will lock a reg key from the Admin account can also be used to deny the System account. You can even deny file permissions to the System account. – surfasb Jan 4 '12 at 0:17
@JohnRobertson: Maybe you are doing it the wrong way. I'm curious which keys and subkeys you need access. Rarely if ever am I messing with the ACLs of the Registry itself. There are good tools out there to do it for you. – surfasb Jan 4 '12 at 0:31

The SYSTEM and NETWORK SERVICE accounts are not real account and do not exist in the SAM – in other words, they cannot have a password set, and you cannot login into them. They only exist as "well-known SIDs" (security identifiers) – Windows simply gives special treatment to such SIDs as S-1-5-18 or S-1-5-20, similar to how uid 0 is special in Unix, and privileged programs can use this account by creating tokens themselves (similar to calling setuid()+capset() in Unix).

An easy way of running programs with SYSTEM privileges is via PsExec from Sysinternals:

psexec -dsi cmd

However, unlike Unix root, not even SYSTEM is allowed to bypass object ACLs – that's why all registry entries, system files and other things explicitly show SYSTEM in their ACLs. Instead, if an administrator needs for some reason to override an object's ACL, they can take ownership of that object using SeTakeOwnershipPrivilege1 (granted by default to all Administrators). This works because an object's owner is always allowed to change its ACLs, even if they explicitly deny it; this is the only2 exception Windows makes.

Sometimes access is being denied due to other reasons – many antivirus programs come with "self defense" kernel drivers, which patch various functions in the Windows kernel itself and make them reject modifications to specific keys or files based solely on their name; the block is before the original ACL checks take place, and no permission or privilege can override it. The only way to bypass such protection is to undo the kernel modifications; any kernel debugger can be used for this. Such tools as Kernel Detective can list all entries in the SSDT, which kernel driver has modified which function, and even have commands to reset the default values.

1 If curious, you can use Process Explorer to view all SIDs and privilege bits assigned to a particular process. You'll see that not even the system processes have any sort of generic "override security" privilege; instead, only specific privileges such as SeImpersonate, SeTakeOwnership or SeCreateToken exist.

2 For files, someone holding SeBackupPrivilege can read a file in "backup mode" – an archive containing the data, metadata, ACLs, ownership... – then optionally modify it, and restore it to the filesystem again. That is, assuming someone has reverse-engineered the structure of these backup archives. This is not available for other kinds of objects.

share|improve this answer
Is there a way to add it to SAM then, if possible? – John Robertson. Jan 4 '12 at 0:06
@JohnRobertson.: You would be breaking all sorts of components. For one, you wouldn't ever be able to login to a domain. What in the world are you trying to do?? – surfasb Jan 4 '12 at 0:08
@JohnRobertson: SYSTEM is not "higher level" in any way. It's not magic either. It just has more privileges by default, since they are necessary for services to worn, but nothing stops you from assigning the same privileges to any user account via secpol.msc. However, if a program - say, an antivirus - adds its own protection layer via kernel patching, there is nothing you can do while the protection is active (although it's often possible to deactivate it via kernel debugging tools; I used "Kernel Detective" once). – grawity Jan 4 '12 at 0:35
@JohnRobertson.: To override privilege restraints, boot from a WinPE disk, or any offline disk. The privilege restraints are controlled by the Session Manager. Disabling it also means winlogon never run, which means you couldn't ever login in the first place as a System account. Basically, to bypass the kernel, you have to be lower than the kernel, which at that level has no accounts. – surfasb Jan 4 '12 at 0:37
@grawity: you can use backup/restore privilege to override file ACLs without having to deal with the "archive" format used by BackupRead/BackupWrite. See the FILE_FLAG_BACKUP_SEMANTICS flag for CreateFile. Using this flag, you can read/write data regardless of the ACLs, read/change ACLs without being the owner or having explicit permission, and even do things (like setting the owner of a file to another user) that would normally be against the rules! – Harry Johnston Jan 5 '12 at 21:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .