What Windows account is used when no one is logged in?

When no one is logged into Windows, (the log in screen is displayed) which user are the current processes running as? (The video/sound drivers, login session, any server software, accessibility controls, etc. They can't be any user or the previous user because no one is logged in. What about processes that have been started by a user but continue to run after logoff? (For example HTTP, FTP servers, and other networking stuff). Do they switch to the SYSTEM account? If a user-started process switches to SYSTEM, that indicates a very serious vulnerability. Does the process run as that user continue to run as that user after they have logged off?

Is this why the SETHC hack allows you to use CMD as SYSTEM?

Solution 1:

When no one is logged into Windows, (the log in screen is displayed) which user are the current processes running as? (The video/sound drivers, login session, any server software, accessibility controls, etc.

Almost all drivers run in kernel mode; they do not need an account, unless they start userspace processes. The few user-space drivers run under SYSTEM.

The login session, I can't check right now, but I'm sure it uses SYSTEM as well. You can see logonui.exe in Process Hacker or SysInternals ProcExp. In fact, you can see everything that way.

"Server software", see Windows services below.

What about processes that have been started by a user but continue to run after logoff? (For example HTTP, FTP servers, and other networking stuff). Do they switch to the SYSTEM account?

There are three kinds here:

1. Plain old "background" processes. Those run under the same account as whoever started them, and do not run after logoff. The logoff process kills them all.

   "HTTP, FTP servers, and other networking stuff" do not run as regular background processes. They run as services.

2. Windows "service" processes. Those are not launched directly, but via Service Manager. By default services run as LocalSystem (which isanae says equals SYSTEM), though they can have dedicated accounts configured.

   (Of course, practically nobody bothers. They just install XAMPP or WampServer or some other crap, and let it run as SYSTEM, forever unpatched.)

   On recent Windows systems, I think services can also have their own SIDs, but again I haven't researched this much yet.

3. Scheduled tasks. These are launched by the "Task Scheduler" service "in background", and always run under the account configured in the task (usually whoever created the task).

If a user-started process switches to SYSTEM, that indicates a very serious vulnerability

It's not a vulnerability because you must already have Administrator privileges to install a service. Having Administrator privileges already lets you do practically everything.

(see also various other non-vulnerabilities of the same kind)

Solution 2:

Login and pre-login processes all run as SYSTEM (also called LocalSystem). In fact, one way to get a shell (such as a CMD prompt) running as SYSTEM on some Windows versions is to replace an accessibility program, such as the screen reader, magnifier, or on-screen keyboard, with a copy of (or link to) CMD.EXE, and then use the shortcut to enable that accessibility feature before logging in. You will get a command prompt, even though there aren't any users logged in, and CMD will be running as SYSTEM.

(Note: this is dangerous, obviously, since it lets people bypass the Windows login process. You should never configure a computer this way and then leave it like that.)

Solution 3:

They don't "switch" to anything; such processes never run under the current user context.
They are owned by the SYSTEM user.

Any processes and services owned by an individual user are terminated on log-out.
That's what logging out means.