On Windows 7, how can I retrieve/set system (not administrator) password?

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!

Regards

Solution 1:

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 SeTakeOwnershipPrivilege¹ (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 only² 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.

¹ 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.

² 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.