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 les processus actuels s'exécutent-ils? (Pilotes vidéo/audio, session de connexion, tout logiciel serveur, commandes d’accessibilité, etc. Ils ne peuvent être ni un utilisateur ni 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 exécuter après la fermeture de session (par exemple, HTTP, serveurs FTP, etc.) passent-ils au compte système? Si un processus lancé par l'utilisateur bascule sur SYSTÈME, cela indique une vulnérabilité très grave. Le processus s'exécute-t-il en tant qu'utilisateur continuer à s'exécuter sous cet utilisateur après sa déconnexion?
Est-ce pour cela que le hack SETHC vous permet d'utiliser CMD en tant que SYSTEM?
Lorsque personne n'est connecté à Windows (l'écran de connexion s'affiche), sous quel utilisateur les processus actuels s'exécutent-ils? (Les pilotes vidéo/audio, la session de connexion, tout logiciel serveur, les contrôles d’accessibilité, etc.
Presque tous les pilotes fonctionnent en mode noyau ; ils n'ont pas besoin d'un compte, à moins qu'ils ne lancent des processus en espace utilisateur. Les quelques pilotes d’espace utilisateur s’exécutent sous SYSTEM.
La session de connexion, je ne peux pas 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 voir tout 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, etc.). Basculent-ils sur le compte SYSTEM?
Il existe trois types ici:
Vieux processus "d'arrière-plan". Ceux qui fonctionnent 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.
"HTTP, les serveurs FTP et autres éléments de réseau" ne s'exécutent pas en tant que processus d'arrière-plan standard. Ils fonctionnent comme des services.
Windows "service" processus. 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 le dérange. Ils installent simplement XAMPP ou WampServer ou une autre foutaise, et le laissent fonctionner en tant que SYSTEM, toujours dépourvu.)
Sur les systèmes Windows récents, je pense que les services peuvent aussi avoir leurs propres SID, mais encore une fois, je n'ai pas encore fait beaucoup de recherches à ce sujet.
Tâches planifiées. Celles-ci sont lancées par le service "Planificateur de tâches" "en arrière-plan" et sont toujours exécutées 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 passe à 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 faire pratiquement tout .
(voir aussi divers autres non-vulnérabilités du même genre)
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’exécuter un shell (tel qu’une invite CMD) en tant que système sur certaines versions de Windows consiste à remplacer un programme d’accessibilité, tel que le lecteur d’écran, la loupe ou le clavier visuel, par une copie de (ou link to) 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'a été connecté, et CMD sera exécuté en tant que SYSTEM.
(Remarque: ceci est évidemment dangereux car cela permet aux utilisateurs de contourner le processus de connexion Windows. Vous ne devriez jamais configurer un ordinateur de cette façon et le laisser comme ça.)
Ils ne "basculent" vers rien; ces processus jamais s'exécutent dans le contexte utilisateur actuel.
Ils appartiennent à l'utilisateur SYSTEM.
Tous les processus et services appartenant à un utilisateur individuel sont terminés lors de la déconnexion.
C'est ce que se déconnecter signifie.