Quel compte Windows est utilisé par le système lorsque personne n'est connecté?

Si vous êtes curieux et que vous en savez plus sur le fonctionnement de Windows sous le capot, vous vous demandez peut-être quels processus «comptes» actifs sont exécutés lorsque personne n'est connecté à Windows. En gardant cela à l’esprit, le post de SuperUser d’aujourd’hui répond à un lecteur curieux..

La séance de questions et réponses d'aujourd'hui nous est offerte par SuperUser, une sous-division de Stack Exchange, un groupe de sites Web de questions-réponses dirigé par la communauté..

La question

Le lecteur superutilisateur Kunal Chopra souhaite savoir quel compte est utilisé par Windows lorsque personne n'est connecté:

Lorsque personne n'est connecté à Windows et que l'écran de connexion s'affiche, sous quel compte utilisateur les processus en cours sont-ils exécutés (pilotes vidéo et audio, session de connexion, logiciel serveur, commandes d'accessibilité, etc.)? Il ne peut s'agir d'aucun utilisateur ni de l'utilisateur précédent car personne n'est connecté.

Qu'en est-il des processus qui ont été démarrés par un utilisateur mais continuent de s'exécuter après la fermeture de session (par exemple, les serveurs HTTP / FTP et d'autres processus de mise en réseau)? Basculent-ils sur le compte SYSTEM? Si un processus lancé par l'utilisateur est basculé sur le compte SYSTEM, cela indique une vulnérabilité très grave. Un tel processus exécuté par cet utilisateur continue-t-il à s'exécuter sous son compte après sa déconnexion??

Est-ce pour cela que le hack SETHC vous permet d'utiliser CMD en tant que SYSTEM?

Quel compte est utilisé par Windows quand personne n'est connecté?

La réponse

Grawity, contributeur au superutilisateur, a la solution pour nous:

Lorsque personne n'est connecté à Windows et que l'écran de connexion s'affiche, sous quel compte utilisateur se trouvent les processus en cours d'exécution (pilotes vidéo et audio, session de connexion, logiciel serveur, commandes d'accessibilité, etc.).?

Presque tous les pilotes fonctionnent en mode noyau; ils n'ont pas besoin d'un compte à moins qu'ils commencent espace utilisateur processus. Ceux espace utilisateur les pilotes fonctionnent sous SYSTEM.

En ce qui concerne la session de connexion, je suis sûr qu’elle utilise également SYSTEM. Vous pouvez voir logonui.exe à l'aide de Process Hacker ou de SysInternals Process Explorer. En fait, vous pouvez tout voir de cette façon.

En ce qui concerne le logiciel serveur, voir les services Windows ci-dessous.

Qu'en est-il des processus qui ont été démarrés par un utilisateur mais continuent de s'exécuter après la fermeture de session (par exemple, les serveurs HTTP / FTP et d'autres processus de mise en réseau)? Basculent-ils sur le compte SYSTEM?

Il existe trois types ici:

1. Processus d'arrière-plan simples: ils s'exécutent sous le même compte que celui qui les a démarrés et ne s'exécutent pas après la fermeture de session. Le processus de fermeture de session les tue tous. Les serveurs HTTP / FTP et autres processus de mise en réseau ne s'exécutent pas en tant que processus en arrière-plan standard. Ils fonctionnent comme des services.
2. Processus de service Windows: ils ne sont pas lancés directement, mais via le Gestionnaire de services. Par défaut, les services exécutés en tant que LocalSystem (dont isanae dit égal à SYSTEM) peuvent avoir des comptes dédiés configurés. Bien sûr, pratiquement personne ne se soucie de rien. Ils installent simplement XAMPP, WampServer ou un autre logiciel et le laissent exécuter en tant que SYSTEM (non corrigé pour toujours). Sur les systèmes Windows récents, je pense que les services peuvent aussi avoir leur propre SID, mais encore une fois, je n'ai pas encore fait beaucoup de recherche à ce sujet..
3. Tâches planifiées: elles sont lancées par le Service du planificateur de tâches en arrière-plan et toujours exécuté sous le compte configuré dans la tâche (généralement celui qui a créé la tâche).

Si un processus lancé par l'utilisateur est basculé sur le compte SYSTEM, cela indique une vulnérabilité très grave.

Ce n'est pas une vulnérabilité car vous devez déjà disposer des privilèges d'administrateur pour installer un service. Avoir les privilèges d'administrateur vous permet déjà de tout faire pratiquement.

Voir également: Diverses autres non-vulnérabilités du même genre.

Assurez-vous de lire le reste de cette discussion intéressante via le lien ci-dessous.!

Avez-vous quelque chose à ajouter à l'explication? Sound off dans les commentaires. Voulez-vous lire plus de réponses d'autres utilisateurs de Stack Exchange doués en technologie? Découvrez le fil de discussion complet ici.