Comment exécutez-vous CMD.exe sous le compte système local?

J'utilise actuellement Vista et je souhaite effectuer manuellement les mêmes opérations que mon service Windows. Étant donné que le service Windows fonctionne sous le compte système local, je voudrais émuler ce 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 CMD.exe à l'aide de la commande DOS Task Scheduler AT, mais j'ai reçu un avertissement Vista que "en raison des améliorations de sécurité, cette tâche s'exécutera à ce moment-là, sauf mais pas de manière 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 démarre pas 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 fasse partie.

J'ai également essayé d'utiliser les Runas, mais je pense que je rencontre la même restriction que celle trouvée lors de l'exécution d'une tâche planifiée.

Jusqu'à présent, chacune de mes tentatives s'est soldée par un échec. Aucune suggestion?

Bien que je n'ai pas personnellement testé, j'ai de bonnes raisons de croire que la solution AT COMMAND indiquée ci-dessus fonctionnera pour XP, 2000 et Server 2003. Selon les tests de My et Bryant, nous avons identifié que la même approche ne fonctionne pas avec Vista ou Windows Server 2008 - probablement en raison d'une sécurité accrue et du commutateur / interactive obsolète.

Cependant, je suis tombé sur cet article qui démontre l'utilisation de PSTools de SysInternals (qui a été acquis par Microsoft en juillet 2006.) J'ai lancé la ligne de commande via ce qui suit et soudain je fonctionnais sous le compte administrateur local comme par magie:

psexec -i -s cmd.exe

PSTools fonctionne bien. C'est un ensemble d'outils légers et bien documentés qui fournit une solution appropriée à mon problème.

Un grand merci à ceux qui ont offert leur aide.

1. Téléchargez psexec.exe depuis Sysinternals .
2. Placez-le dans votre lecteur C: \.
3. Ouverture de session en tant qu'utilisateur standard ou admin et utilisez la commande suivante: cd \. Cela vous place dans le répertoire racine de votre lecteur, où se trouve psexec.
4. Utilisez la commande suivante: psexec -i -s cmd.exeoù -i est pour interactif et -s pour le compte système.
5. Une fois la commande terminée, un shell cmd sera lancé. Type whoami; il dira «système»
6. Ouvrez le gestionnaire de tâches. Tuez explorer.exe.
7. À partir d'un type de shell de commande élevé start explorer.exe.
8. Lorsque l'explorateur est lancé, notez le nom "système" dans la barre de menu de démarrage. Vous pouvez maintenant supprimer certains fichiers du répertoire system32 que vous ne pouvez pas supprimer en tant qu'administrateur ou, en tant qu'administrateur, vous devrez essayer 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 lors du changement de nom d'un fichier, vous devez changer le propriétaire et remplacer TrustedInstaller qui possède le fichier et rendre tout utilisateur comme un utilisateur qui appartient au groupe administrateur 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 l'explorateur Windows avec les privilèges du noyau, vous êtes quelque peu limité en termes d'accès au réseau pour des raisons de sécurité et c'est toujours un sujet de recherche pour moi de récupérer l'accès

Nous avons trouvé ici une réponse qui semble résoudre le problème en ajoutant / k start au paramètre binPath. Cela vous donnerait donc:

sc create testsvc binpath= "cmd /K start" type= own type= interact

Cependant, Ben a dit que cela ne fonctionnait pas pour lui et quand je l'ai essayé sur Windows Server 2008, cela a créé le processus cmd.exe sous le système local, mais ce 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? Essayez-vous simplement de voir ce qui se passe lorsque vous exécutez votre service? On dirait que vous pourriez simplement utiliser la journalisation pour déterminer ce qui se passe au lieu d'avoir à exécuter l'exe en tant que système local ...

Je vous recommande de définir l'ensemble d'autorisations minimum dont votre service a vraiment besoin et de l'utiliser, plutôt que le contexte du système local beaucoup trop privilégié. Par exemple, Service local .

Les services interactifs ne fonctionnent plus - ou du moins, n'affichent plus l'interface utilisateur - sur Windows Vista et Windows Server 2008 en raison de l' isolement de la session 0 .

Utilisation de Secure Desktop pour s'exécuter en cmd.exetant quesystem

Nous pouvons facilement accéder au noyau via CMDWindows 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"

1. Exécuter en CMDtant qu'administrateur

2. Ensuite, 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"
   

3. Puis exécutez osk(sur le clavier à l'écran). 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 la session de service, il fonctionnera commeNT Authority\SYSTEM

j'ai donc eu l'idée de l'exécuter sur Secure Desktop.

Démarrez n'importe quel fichier en tant qu'administrateur. Lorsque les invites UAC apparaissent, appuyez simplement sur Win+ Uet démarrez OSKet il démarrera à la CMDplace. Ensuite, dans l'invite élevée, tapez whoamiet vous obtiendrez NT Authority\System. Après cela, vous pouvez démarrer l'Explorateur à partir du shell de commande système et utiliser le profil système, mais vous êtes quelque peu limité à ce que vous pouvez faire sur le réseau via les privilèges SYSTEM pour des raisons de sécurité. J'ajouterai plus d'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 Cmd.exesous un compte système local sans utiliserPsExec. Cette méthode exécute la technique Debugger Trap qui a été découverte plus tôt, eh bien cette technique a ses propres avantages, elle peut être utilisée pour piéger certains vers rusés / malveillants ou logiciels malveillants dans le débogueur et exécuter un autre exe à la place pour arrêter la propagation ou endommager temporairement. 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 fonctionnera toujours avec les privilèges des utilisateurs connectés, mais si nous exécutons cmd dans session0, nous pouvons obtenir le shell système. nous ajoutons donc ici une autre idée, nous couvrons la cmd sur un bureau sécurisé, rappelez-vous que le bureau sécurisé s'exécute dans la session 0 sous le compte système et nous obtenons le shell système. Ainsi, chaque fois que vous exécutez quelque chose d'aussi élevé, vous devez répondre à l'invite UAC et aux invites UAC sur un bureau sombre et non interactif et une fois que vous le voyez, vous devez appuyer sur Win+ U, puis sélectionnerOSKvous vous CMD.exelancerez sous les privilèges du système local. Il existe encore plus de façons d'accéder au système local avecCMD

Une alternative à cela est Process hacker si vous entrez dans Run as ... (Interactive ne fonctionne pas pour les personnes avec les améliorations de sécurité mais cela n'a pas d'importance) 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 : \ Users \ Windows \ system32 \ cmd.exe laissez le reste cliquez sur ok et boch vous avez une fenêtre avec cmd dessus et exécutez en tant que système maintenant faites les autres étapes pour vous-même parce que 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 les commandes de la console et de l'interface graphique.

si vous pouvez écrire un fichier de commandes qui n'a pas besoin d'être interactif, essayez d'exécuter ce fichier de commandes en tant que service, pour faire ce qui doit être fait.

J'utilise l' utilitaire RunAsTi pour 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 entrez en faisant Shift+ Restart), l' utilitaire psexec n'y fonctionne pas. Mais vous devez ajouter vos chemins C:\Windowset C:\Windows\System32(non X:\Windowset X:\Windows\System32) à la PATHvariable d'environnement, 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 .

À l'aide du planificateur de tâches, planifiez une exécution de CMDKEY exécutée sous SYSTEM avec les arguments appropriés de / add: / user: et / pass:

Pas besoin d'installer quoi que ce soit.