Comment exécutez-vous CMD.exe sous le compte système local?
J'utilise actuellement Vista et j'aimerais effectuer manuellement les mêmes opérations que mon service Windows. Étant donné que le service Windows est exécuté sous le compte système local, j'aimerais émuler le même comportement. Fondamentalement, je voudrais exécuter CMD.EXE sous le compte système local.
J'ai trouvé des informations en ligne qui suggèrent de lancer le fichier CMD.exe à l'aide de la commande du planificateur de tâches DOS AT, mais j'ai reçu un avertissement à Vista indiquant que "pour des raisons de sécurité, cette tâche sera exécutée à cette heure mais de manière non interactive". Voici un exemple de commande:
AT 12:00 /interactive cmd.exe
Une autre solution a suggéré de créer un service Windows secondaire via le contrôle de service (sc.exe) qui lance simplement CMD.exe.
C:\sc create RunCMDAsLSA binpath= "cmd" type=own type=interact
C:\sc start RunCMDAsLSA
Dans ce cas, le service ne parvient pas à démarrer et génère le message d'erreur suivant:
FAILED 1053: The service did not respond to the start or control request in a timely fashion.
La troisième suggestion était de lancer CMD.exe via une tâche planifiée. Bien que vous puissiez exécuter des tâches planifiées sous différents comptes, je ne pense pas que le compte système local en soit un.
J'ai aussi essayé d'utiliser les Runas, mais je pense que je rencontre la même restriction que celle rencontrée lors de l'exécution d'une tâche planifiée.
Jusqu'ici, chacune de mes tentatives s'est soldée par un échec. Aucune suggestion?
Bien que je n’aie pas personnellement testé le système, j’ai de bonnes raisons de croire que la solution AT décrite ci-dessus fonctionnera sous XP, 2000 et Server 2003. Selon les tests de mon et Bryant, nous avons constaté que la même ne fonctionne pas avec Vista ou Windows Server 2008 - très probablement en raison de la sécurité accrue et du commutateur/interactive obsolète.
Cependant, je suis tombé sur ce article qui illustre l'utilisation de PSTools à partir de SysInternals (acquis par Microsoft en juillet 2006). J'ai lancé la ligne de commande via ce qui suit et j'ai fonctionnait sous le compte administrateur local comme par magie:
psexec -i -s cmd.exe
PSTools fonctionne bien. C'est un ensemble d'outils léger et bien documenté qui fournit une solution appropriée à mon problème.
Un grand merci à ceux qui ont offert de l'aide.
- Téléchargez psexec.exe depuis Sysinternals .
- Placez-le dans votre lecteur C: \.
- Connectez-vous en tant qu'utilisateur standard ou administrateur et utilisez la commande suivante:
cd \. Cela vous place dans le répertoire racine de votre lecteur, où se trouve psexec. - Utilisez la commande suivante:
psexec -i -s cmd.exeoù -i correspond à interactif et -s correspond au compte système. - Une fois la commande terminée, un shell cmd sera lancé. Tapez
whoami; il va dire 'système " - Ouvrez le gestionnaire de tâches. Tuez Explorer.exe.
- A partir d'une commande surélevée Shell, tapez
start Explorer.exe. - Lorsque Explorer est lancé, notez le nom "système" dans la barre de menus. Vous pouvez maintenant supprimer certains fichiers du répertoire system32 qui, en tant qu'administrateur, ne peuvent pas être supprimés ou, en tant qu'administrateur, vous devrez vous efforcer de modifier les autorisations pour supprimer ces fichiers.
Les utilisateurs qui essaient de renommer ou de supprimer des fichiers système dans n’importe quel répertoire protégé de Windows doivent savoir que tous les fichiers Windows sont protégés par DACLS lorsqu’un nouveau fichier est renommé. appartient au groupe d'administrateurs en tant que propriétaire du fichier, puis essayez de le renommer après avoir modifié l'autorisation. Cela fonctionnera et pendant que vous exécutez Windows Explorer avec les privilèges du noyau, vous êtes quelque peu limité en termes d'accès réseau pour des raisons de sécurité. pour moi d'avoir de nouveau accès
Vous avez trouvé une réponse ici qui semble résoudre le problème en ajoutant/k start au paramètre binPath. Donc cela vous donnerait:
sc create testsvc binpath= "cmd /K start" type= own type= interact
Cependant, Ben a déclaré que cela ne fonctionnait pas pour lui et que lorsque je l'ai essayé sous Windows Server 2008, il a créé le processus cmd.exe sous un système local, mais il n'était pas interactif (je ne pouvais pas voir la fenêtre).
Je ne pense pas qu'il existe un moyen facile de faire ce que vous demandez, mais je me demande pourquoi vous le faites du tout? Êtes-vous simplement en train d'essayer de voir ce qui se passe lorsque vous utilisez votre service? On dirait que vous pourriez simplement utiliser la journalisation pour déterminer ce qui se passe au lieu de devoir exécuter le fichier exe en tant que système local ...
Je vous recommanderais de définir le jeu d'autorisations minimales dont votre service a réellement besoin et de l'utiliser, plutôt que le contexte de système local trop privilégié. Par exemple, Service local .
Les services interactifs ne fonctionnent plus - ou du moins, ne montrent plus l'interface utilisateur - sous Windows Vista et Windows Server 2008 en raison de session 0 isolement .
Utilisation de Secure Desktop pour exécuter cmd.exe en tant que system
Nous pouvons facilement accéder au noyau via CMD dans Windows XP/Vista/7/8.1 en attachant un débogueur:
REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\osk.exe" /v Debugger /t REG_SZ /d "C:\windows\system32\cmd.exe"
Exécutez
CMDen tant qu'administrateurPuis utilisez cette commande dans Elevated:
CMD REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\osk.exe" /v Debugger /t REG_SZ /d "C:\windows\system32\cmd.exe"Ensuite, exécutez
osk(onscreenkeyboard). Il ne fonctionne toujours pas avec le niveau d'intégrité du système si vous vérifiez via l'Explorateur de processus, mais si vous pouvez utiliser OSK dans une session de service, il s'exécutera sous la formeNT Authority\SYSTEM.
j'ai donc eu l'idée de l'exécuter sur Secure Desktop.
Commencez n'importe quel fichier en tant qu'administrateur. Lorsque les invites UAC apparaissent, appuyez simplement sur Win+U et lancez OSK et il démarrera CMD à la place. Ensuite, dans l'invite surélevée, saisissez whoami et vous obtiendrez NT Authority\System. Après cela, vous pouvez démarrer Explorer à partir de la commande système Shell et utiliser le profil Système, mais vous ne pouvez pas vous limiter à ce que vous pouvez faire sur le réseau grâce aux privilèges SYSTEM pour des raisons de sécurité. J'ajouterai d'autres explications plus tard, comme je l'ai découvert il y a un an.
Une brève explication de la façon dont cela se produit
Exécution de Cmd.exe sous Compte système local sans utiliser PsExec. Cette méthode exécute la technique d'interruption du débogueur découverte précédemment. Cette technique a ses propres avantages. Elle peut également être utilisée pour piéger un ver ou un logiciel malveillant artificiel dans le débogueur et exécuter un autre exécutable à la place pour arrêter la propagation ou les dommages temporaires. Ici, cette clé de registre piège le clavier à l'écran dans le débogueur natif de Windows et exécute cmd.exe à la place, mais cmd continuera à s'exécuter avec les privilèges Connecté sur les utilisateurs. Toutefois, si nous exécutons cmd dans session0, nous pouvons obtenir le système Shell. Nous ajoutons donc ici une autre idée: nous couvrons la commande sur un bureau sécurisé. Nous rappelons que le bureau sécurisé s’exécute à la session 0 sous le compte système et nous obtenons le système Shell. Ainsi, chaque fois que vous exécutez quelque chose d'aussi élevé, vous devez répondre à l'invite UAC et les invites UAC sur un bureau sombre et non interactif. Une fois que vous le voyez, vous devez appuyer sur Win+U puis sélectionnez OSK vous obtiendrez CMD.exe sous les privilèges du système local. Il y a encore plus de façons d'obtenir un accès au système local avec CMD
une alternative à ceci est Process hacker si vous allez dans Exécuter en tant que ... (Interactif ne fonctionne pas pour les personnes avec des améliorations de sécurité mais ce n'est pas grave) et lorsque la boîte s'ouvre, mettez Service dans le type de boîte et mettez SYSTEM dans la boîte utilisateur. et mettez C:\Utilisateurs\Windows\system32\cmd.exe laisser le reste cliquez sur ok et boch vous avez une fenêtre avec cmd dessus et exécutez en tant que système faites maintenant les autres étapes pour vous-même car je vous suggère de les connaître
Il y a un autre moyen. Il existe un programme appelé PowerRun qui permet d’exécuter une cmd élevée. Même avec les droits TrustedInstaller. Il permet à la fois la console et les commandes de l'interface graphique.
si vous pouvez écrire un fichier de commandes qui n'a pas besoin d'être interactif, essayez de l'exécuter en tant que service afin de faire le nécessaire.
À l'aide du planificateur de tâches, planifiez une exécution de CMDKEY sous SYSTEM avec les arguments appropriés de/add:/user: et/pass:
Pas besoin d'installer quoi que ce soit.
J'utilise l'utilitaire RunAsTi pour s'exécuter en tant que TrustedInstaller _ (privilège élevé). L'utilitaire peut être utilisé même en mode de récupération de Windows (le mode que vous avez entré en faisant Shift + Restart), l'utilitaire psexec _ n'y fonctionne pas. Mais vous devez ajouter vos chemins C:\Windows et C:\Windows\System32 (et non pas X:\Windows et X:\Windows\System32) à la variable d'environnement PATH; sinon, RunAsTi ne fonctionnera pas en mode de récupération, il imprimera simplement: AdjustTokenPrivileges for SeImpersonateName: Tous les privilèges ou groupes référencés ne sont pas attribués à l'appelant} _.