How to access the SAM and SECURITY hives in the Registry using the SYSTEM account

• Author
• Recent Posts

Sami Laiho

Sami Laiho has been a Microsoft Most Valuable Professional (MVP) since 2011 and one of the world's leading IT experts for Windows and security. He has been teaching OS troubleshooting, management, and security since 1996. In 2019 TiVi-magazine chose Sami as one of the top 100 influencers in IT in Finland. For more info, go to https://samilaiho.com.

Latest posts by Sami Laiho (see all)

• Hardening AppLocker - Thu, Jun 25 2020
• AppLocker Audit vs. Enforced mode - Tue, Jun 23 2020
• Creating AppLocker rules from the Windows event log - Wed, Jun 17 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:

Regedit.exe running as Administrator is not able to see the SECURITY hive's content

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

Starting a command prompt with the SYSTEM account

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

Running regedit.exe as SYSTEM

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.

Scheduled tasks shown as an admin

Now open taskschd.msc running as SYSTEM from the prompt and look again.

Scheduled tasks shown as SYSTEM

So as you can see, you can see many things as the SYSTEM account and not as Administrator.