25

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?

  • "Switching users" is actually not a black&white operation on Windows. A service can impersonate multiple users at the same time, and still be using the original account as well. This is useful for services that need to act on behalf of specific users, say authenticated website visitors. – MSalters Oct 5 '15 at 12:24
  • 3
    Windows is multi-user operating system, which means that different processes may belong to different users at the same time. It's not like that once you log in whole computer "switches" to your account. – el.pescado Oct 5 '15 at 19:07
40

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)

  • 4
  • 2
    It might be worth noting that much of IIS runs under lower privileged accounts created specifically for IIS processes out of the box. (This would cover many Windows HTTP, FTP, etc. servers.) See here for some details. So it often depends on the defaults of whatever program you're using. – jpmc26 Oct 5 '15 at 4:05
  • 1
    SYSTEM and Local Administrator are essentially one and the same. Once you have one, you can get the other, and the OS only puts up roadblocks meant primarily to prevent mistakes. (Note: The Old New Thing is not official Microsoft documentation.) – a CVn Oct 5 '15 at 8:42
  • 3
    These days many services run as NetworkService or LocalService, not LocalSystem. – Ben Voigt Oct 5 '15 at 17:29
  • 2
    Starting with Windows 7 and 2008 R2, Managed Service Accounts and Virtual Accounts allow for running services under their own identities, so you don't have a bunch of services sharing LocalService/NetworkService/LocalSystem, limiting access if one service has a vulnerability. – afrazier Oct 6 '15 at 13:01
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.)

  • 1
    Works on Windows 7, replaced sethc.exe with cmd.exe in C:\Windows\System32\ – user452888 Oct 9 '15 at 18:42
1

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.

  • I'm not sure... Firstly, I found an MS Technet post where (not like this means much) a staff accepted answer stated that services are not terminated on logout. I'm not sure this is an accurate definition of logout more generally either: I saw several daemons on Linux stay around after I log out one user then ps as another – underscore_d Oct 5 '15 at 13:26
  • 1
    That's not correct. Services can be started as another user and they will start and continue to run without that user "logged in". They will start their own session with that users credentials, so actually the user will be logged in while the service runs, but the desktop/autostart programs etc. wont be run, and that is what normal users understand as "logged in". Still the service will run with that user credentials and has access to that users files. – Josef Oct 5 '15 at 14:12
  • @Josef: Your argument appears to boil down to "some people misuse the term 'logged in'". The actual meat of your comment agrees with my answer: that user is deemed logged in for as long as they have services/processes running against their account. – Lightness Races with Monica Oct 5 '15 at 14:15
  • @LightnessRacesinOrbit no, there is a actual difference. If you create a service with your account and that is run at boot, there won't be any process started for you to show the desktop, (so no dwm.exe or explorer.exe running), all your autostart programs won't be running etc. So if you have a interactive login session, a lot more things are active than if only service session is running. What exactly is "logged in" is open to debate. Even if a service runs with your credentials, you still have to log in to use Windows yourself! – Josef Oct 5 '15 at 14:26
  • 1
    Well, "such processes never run under the current user context" is still wrong. Services run under the user context set for them. For builtin windows services, that is one of the system accounts. For other services, it can be any account. Especially server software should create a new user account and run wit that credentials. – Josef Oct 5 '15 at 14:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.