- Creating a complete memory dump without a Blue Screen - Mon, Apr 27 2020
- How to access the SAM and SECURITY hives in the Registry using the SYSTEM account - Thu, Apr 16 2020
- Capturing error messages and looking up text for error code numbers - Mon, Apr 13 2020
Why is it like this? Well it wasn't always this important, and up to Windows 2000, things were a little different as Microsoft was still building different operating systems for consumers other than enterprises.
When consumers had Windows 95, enterprises had Windows NT; when consumers had Windows ME, enterprises had Windows 2000. With the introduction of Windows XP, Microsoft merged these lines and started offering the same products to both of them. Enterprise users didn't have to have admin rights as they could call the service desk, but consumers needed to have admin rights as they didn't have a service desk to call.
This meant consumers running as full admins were at high risk of accidentally destroying their computers by, for example, right-clicking Program Files and hitting Delete. This is when Microsoft started moving more and more rights to the SYSTEM account and away from the Administrator account.
The SYSTEM user:
- Has more privileges than the admin
- Can see things the admin can't
- Can stop processes the admin can't
- Has a higher integrity level than the admin
- Can bypass most policies
Let's look at an example where you would like to verify whether the computer account password actually changes when you are troubleshooting issues with a computer that has lost the trust relationship with the domain. The Active Directory computer account has a password attribute, but locally it is stored in the Registry. Let's open regedit.exe and see we can't access it:
Let's try the same thing with the SYSTEM account. We'll use PsExec.exe from Sysinternals for this.
First, start a command prompt via Run As Administrator and run:
-psexec -sid cmd.exe
From the new command prompt, you can verify you are running as SYSTEM via WhoAmi.exe.
Now start regedit.exe (you need to close other instances of RegEdit or use the -m parameter).
As you can see, you can now access many places admins can't, like SECURITY, SAM, or the hives for AppLocker.
Another great example is trying to figure out how Group Policy background sync triggers. In Windows 7, the GPClient service was running all the time and would sync Group Policy Objects (GPOs) every 90–120 minutes. In Windows 8, Microsoft changed this as GPClient was just consuming CPU power when it wasn't needed for anything.
Try to open the Task Scheduler with an admin account to see the Group Policy tasks. Nothing is there.
Now open taskschd.msc running as SYSTEM from the prompt and look again.
So as you can see, you can see many things as the SYSTEM account and not as Administrator.