System Account in Windows

Question

I was thinking about SYSTEM account on windows 7 and while researching about it, I came to know that it is predefined account used by service control manager (SCM),The account is not recognised by security subsystem what does it mean? I want to know if this account has a profile name on windows 7, 8, 8.1 etc., why can't we login into that account, why is the account not associated with any logged in user account? If we do anything under SYSTEM account like rename a file is it logged in event manager? Does this account has a password or username? Almost everyone knows that we can run windows explorer under SYSTEM account and explore the SYSTEM profile but when I did it I often have difficulty like deleting, renaming etc why?

Answer 1

The SYSTEM account is a pseudo-account similar, but not identical, to root on Linux. The two primary differences are that (a) the SYSTEM account is a service account, and therefore does not have a user profile (at least not in the same sense as a desktop user), and (b) the Windows permissions model still enforces ACLs such that objects can exist which SYSTEM cannot directly access (though it can still grant a privilege to a token and gain access that way).

The SYSTEM account is the highest privilege level in the Windows user model. It exists to provide ownership to objects that are created before a normal user logs on, such as the Local Security Authority Subsystem (LSASS) and the Session Management Subsystem (SMSS).

To answer your questions directly:

The account is not recognised by security subsystem what does it mean?

It is recognised by the security subsystem, but it doesn't strictly exist as a user. This concept is a little confusing, but think of it this way: the computer itself isn't a user, but there are lots of things that the computer needs to do with securable objects, so you need a way of representing it as an entity in the security model.

The Windows access control system uses discretionary access control lists (DACLs) to secure objects. These DACLs consist of access control entries (ACEs) which each grant or deny a particular set of access rights to a particular "trustee", represented by a security identifier (SID). That SID represents a security principal. Users and groups are examples of security principals, but there are principals that are neither users nor groups. For example, ANONYMOUS LOGON (SID S-1-5-7) represents the security identity of a connection to the system without a username or password, but it is not itself a user. Another example is AUTHENTICATED USERS, which is a security principal that acts like a group containing all users that are authenticated on the system at any given time. It isn't a group in the sense that you can add or remove users to it.

SYSTEM (SID S-1-5-18) is a security principal that represents the identity of the operating system and many of its services. It can be used in a similar way to an account, but it isn't technically a user account.

I want to Know if this account has a profile name on windows 7,8,8.1 etc

SYSTEM doesn't have a user profile in the normal sense because it isn't an interactive user, nor is it strictly a user. You can't log in with SYSTEM, neither locally nor remotely. This goes for other service accounts too, such as LOCAL SERVICE and NETWORK SERVICE. The special case for local service accounts (including SYSTEM) is that they don't exist outside the machine they are attached to, so they are not part of the domain. You can have domain service accounts, but these exist as part of AD rather than accounts on a machine.

For practical reasons, some parts of the regular user account infrastructure are replicated for built-in security principals that a process can execute under the context of. For example, there are special directories that are used as storage locations for when a process running with one of these security identities tries to access %APPDATA% or a similar account-specific location.

why can't we login into that account,why is the account not associated with any logged in user account?

The SYSTEM account is a service account, not a user account. It is not a member of the interactive users group (SID S-1-5-4). It has no desktop user profile associated with it. It's simply there to facilitate the operation of the operating system and its services. For example, usermode services associated with drivers may need to run at boot time, before the user logs in, so they run as SYSTEM in order to get the process to execute on boot and have the necessary privileges to communicate with drivers.

if we do anything under SYSTEM account like rename a file is it logged in event manager

Not any more so than any other account. You can indeed enable auditing and other logging as part of your filesystem auditing features or as part of the local (or group) security policy, but this goes for any other account too.

Does this account has a password? or username?

The full name of the SYSTEM security principal is NT AUTHORITY\SYSTEM. The question as to whether it has a password or not is complicated. The simple answer is no, but that doesn't tell the full story. It has something called evidence, which is a term used in the Windows security model to mean any form of identifying data that proves you are who you say you are. This isn't as clear-cut as just passwords or certificates, but extends to things like security tokens attached to threads or processes. As such, it doesn't have a password in the sense that you could type something in and log into it, but it does have evidence that proves it is the SYSTEM account in order to prevent a local process from impersonating it.

Almost Everyone knows that we can run windows explorer under SYSTEM account and explore the SYSTEM profile but when i did it i often have difficulty like deleting ,renaming etc why?

The important thing to remember here is that a process can run as SYSTEM but still have handles to objects that exist under a different session. Keep in mind that sessions aren't the same as users - they're container objects that are instantiated for users when they log on. By default, services run under the null session, which you can't see. These are called non-interactive services, and they're usually owned by SIDs that are not in the INTERACTIVE USERS built-in group. When you run Explorer as SYSTEM under your own session, its window handles exist in the current session that you're logged into, but are owned by SYSTEM. The important distinction is that you don't own that process or its handles, but you own the session under which the window exists. This is at best a hack - you're tricking a non-interactive service process into owning handles that exist in an interactive session.

As for why you had trouble with deleting and renaming, I'm not sure. I've not tried running explorer as SYSTEM in 8.1, but back in XP and Win7 it worked just fine. I'd suggest trying cmd or something similar rather than Explorer.

My advice would be to read the security model sections of the Windows Internals book by Mark Russinovich, which has really in-depth explanations about how all this works.