Quel compte Windows est utilisé lorsque personne n'est connecté?

Lorsque personne n'est connecté à Windows, (l'écran de connexion s'affiche) sous quel utilisateur s'exécutent les processus actuels? (Les pilotes vidéo / audio, la session de connexion, tout logiciel serveur, les contrôles d'accessibilité, etc. Ils ne peuvent pas être un utilisateur ou un 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 à s'exécutent après la fermeture de session? (Par exemple, les serveurs HTTP, FTP et autres éléments de mise en réseau.) Basculent-ils vers le compte SYSTEM? Si un processus démarré par l'utilisateur bascule vers SYSTEM, cela indique une vulnérabilité très grave. Le processus s'exécute-t-il en tant qu'utilisateur continuer à fonctionner en tant qu'utilisateur après s'être déconnecté?

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

windows process uac

— Kunal Chopra
source

"Changer d'utilisateur" n'est en fait pas une opération en noir et blanc sous Windows. Un service peut emprunter l'identité de plusieurs utilisateurs en même temps et utiliser le compte d'origine également. C'est utile pour les services qui doivent agir au nom d'utilisateurs spécifiques, disent les visiteurs authentifiés du site Web.

— MSalters

Windows est un système d'exploitation multi-utilisateurs, ce qui signifie que différents processus peuvent appartenir à différents utilisateurs en même temps . Ce n'est pas comme ça une fois que vous vous connectez, un ordinateur entier "passe" à votre compte.

— el.pescado

Réponses:

Lorsque personne n'est connecté à Windows, (l'écran de connexion s'affiche) sous quel utilisateur s'exécutent les processus actuels? (Les pilotes vidéo / audio, la session de connexion, tout logiciel serveur, les contrôles d'accessibilité, etc.

Presque tous les pilotes s'exécutent en mode noyau ; ils n'ont pas besoin de compte, sauf s'ils démarrent des processus de l'espace utilisateur. Les quelques pilotes de l'espace utilisateur s'exécutent sous SYSTEM.

La session de connexion, je ne peux pas la vérifier pour le moment, mais je suis sûr qu'elle utilise également SYSTEM. Vous pouvez voir logonui.exe dans Process Hacker ou SysInternals ProcExp . En fait, vous pouvez tout voir de cette façon.

"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, HTTP, serveurs FTP et autres éléments de mise en réseau). Basculent-ils vers le compte SYSTEM?

Il en existe trois sortes:

Processus "d'arrière-plan" clairs et anciens. Ceux-ci 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 déconnexion. Le processus de déconnexion les tue tous.

"HTTP, serveurs FTP et autres éléments de mise en réseau" ne s'exécutent pas en tant que processus d'arrière-plan standard. Ils fonctionnent comme des services.
Processus "service" Windows. Ceux-ci ne sont pas lancés directement, mais via Service Manager. Par défaut, les services s'exécutent en tant que LocalSystem (ce qui, selon Isanae, est égal à SYSTEM), bien qu'ils puissent avoir des comptes dédiés configurés.

(Bien sûr, pratiquement personne ne dérange. Il suffit d'installer XAMPP ou WampServer ou d'autres conneries, et de le laisser fonctionner en tant que SYSTEM, sans correction pour toujours.)

Sur les systèmes Windows récents, je pense que les services peuvent également avoir leurs propres SID, mais encore une fois, je n'ai pas encore beaucoup recherché.
Tâches planifiées. Celles-ci sont lancées par le service "Task Scheduler" "en arrière-plan", et s'exécutent toujours sous le compte configuré dans la tâche (généralement celui qui a créé la tâche).

Si un processus démarré par l'utilisateur bascule sur SYSTEM, cela indique une vulnérabilité très grave

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

(voir aussi diverses autres non-vulnérabilités du même type)

— grawity
source

SYSTEM et LocalSystem représentent tous deux le même compte avec le SID S-1-5-18.

— Isanae

Il convient de noter qu'une grande partie d'IIS s'exécute sous des comptes privilégiés inférieurs créés spécifiquement pour les processus IIS prêts à l'emploi. (Cela couvrirait de nombreux serveurs HTTP, FTP, etc. Windows.) Voir ici pour plus de détails. Cela dépend donc souvent des paramètres par défaut du programme que vous utilisez.

— jpmc26

SYSTÈME et Administrateur local sont essentiellement une seule et même chose. Une fois que vous en avez un, vous pouvez obtenir l'autre, et le système d'exploitation ne met en place que des barrages routiers destinés principalement à éviter les erreurs. (Remarque: The Old New Thing n'est pas une documentation officielle de Microsoft.)

— un CVn du

De nos jours, de nombreux services s'exécutent en tant que NetworkService ou LocalService, et non LocalSystem.

— Ben Voigt

À partir de Windows 7 et 2008 R2, les comptes de services gérés et les comptes virtuels permettent d'exécuter des services sous leur propre identité, vous n'avez donc pas un tas de services partageant LocalService / NetworkService / LocalSystem, limitant l'accès si un service présente une vulnérabilité.

— afrazier

Les processus de connexion et de pré-connexion s'exécutent tous en tant que SYSTEM (également appelé LocalSystem). En fait, une façon d'obtenir un shell (tel qu'une invite CMD) s'exécutant en tant que SYSTEM sur certaines versions de Windows consiste à remplacer un programme d'accessibilité, tel que le lecteur d'écran, la loupe ou le clavier à l'écran, par une copie de (ou lien vers) CMD.EXE, puis utilisez le raccourci pour activer cette fonctionnalité d'accessibilité avant de vous connecter. Vous obtiendrez une invite de commande, même si aucun utilisateur n'est connecté, et CMDvous exécuterez en tant que SYSTEM.

(Remarque: cela est dangereux, évidemment, car il permet aux gens de contourner le processus de connexion Windows. Vous ne devez jamais configurer un ordinateur de cette façon, puis le laisser comme ça.)

— CBHacking
source

Fonctionne sur Windows 7, a remplacé sethc.exe par cmd.exe dans C: \ Windows \ System32 \

Ils ne "passent" à rien; ces processus ne s'exécutent jamais dans le contexte utilisateur actuel.
Ils appartiennent à l' SYSTEMutilisateur.

Tous les processus et services appartenant à un utilisateur individuel sont interrompus lors de la déconnexion.
C'est ce que signifie la déconnexion .

— Courses de légèreté avec Monica
source

Je ne suis pas sûr ... Tout d'abord, j'ai trouvé un poste MS Technet où (pas comme cela signifie beaucoup) une réponse acceptée par le personnel a déclaré que les services ne sont pas interrompus à la déconnexion. Je ne suis pas sûr que ce soit une définition précise de la déconnexion plus généralement non plus: j'ai vu plusieurs démons sous Linux rester autour après avoir déconnecté un utilisateur puis psun autre

— underscore_d

Ce n'est pas correct. Les services peuvent être démarrés en tant qu'un autre utilisateur et ils démarreront et continueront à s'exécuter sans que cet utilisateur soit "connecté". Ils démarreront leur propre session avec les informations d'identification de cet utilisateur, donc en fait l'utilisateur sera connecté pendant que le service s'exécute, mais les programmes de bureau / démarrage automatique, etc. ne seront pas exécutés, et c'est ce que les utilisateurs normaux comprennent comme "connecté". Le service fonctionnera toujours avec les informations d'identification de l'utilisateur et aura accès aux fichiers de ces utilisateurs.

— Josef

@Josef: Votre argument semble se résumer à "certaines personnes abusent du terme" connecté "". La chair réelle de votre commentaire est d'accord avec ma réponse: cet utilisateur est réputé connecté tant qu'il a des services / processus exécutés sur son compte.

— Courses de légèreté avec Monica

@LightnessRacesinOrbit non, il y a une réelle différence. Si vous créez un service avec votre compte et qui est exécuté au démarrage, aucun processus ne sera démarré pour que vous puissiez afficher le bureau (donc aucun dwm.exe ou explorer.exe ne fonctionne), tous vos programmes de démarrage automatique ne seront pas être en cours d'exécution, etc. Donc, si vous avez une session de connexion interactive, beaucoup plus de choses sont actives que si seule la session de service est en cours d'exécution. Ce qui est exactement "connecté" est sujet à débat. Même si un service fonctionne avec vos informations d'identification, vous devez toujours vous connecter pour utiliser Windows vous-même!

— Josef

Eh bien, "de tels processus ne s'exécutent jamais dans le contexte utilisateur actuel" est toujours faux. Les services s'exécutent dans le contexte utilisateur défini pour eux. Pour les services Windows intégrés, c'est l'un des comptes système. Pour les autres services, il peut s'agir de n'importe quel compte. En particulier, le logiciel serveur doit créer un nouveau compte d'utilisateur et s'exécuter avec ces informations d'identification.

— Josef