Comment faites-vous tourner CMD.exe sous le compte du système Local?
j'exécute actuellement Vista et je voudrais effectuer manuellement les mêmes opérations que mon service Windows. Comme le service Windows fonctionne sous le compte système Local, je voudrais imiter ce même comportement. En gros, je voudrais exécuter CMD.EXE sous le compte du système Local.
j'ai trouvé de l'information en ligne qui suggère de loucher le CMD.exe utilisant le planificateur de tâches DOS à la commande, mais j'ai reçu un avertissement Vista que "en raison de la sécurité améliorations, cette tâche sera exécutée au moment excepté mais pas de façon 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 ne fait que lancer 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 il en résulte 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 un Tâche Planifiée. Bien que vous puissiez exécuter des tâches programmées sous différents comptes, Je ne crois pas que le compte système Local soit l'un d'eux.
j'ai essayé D'utiliser les Runas aussi, mais je pense que je suis en train de rencontrer la même restriction que trouvée lors de l'exécution d'une tâche programmée.
jusqu'à présent, chacune de mes tentatives s'est soldée par un échec. Toutes les suggestions?
9 réponses
même si je n'ai pas personnellement testé, j'ai de bonnes raisons de croire que la solution de commande mentionnée ci-dessus fonctionnera pour XP, 2000 et Server 2003. Selon les tests de my et de Bryant, nous avons déterminé que la même approche ne fonctionne pas avec Vista ou Windows Server 2008 -- probablement en raison d'une sécurité accrue et du fait que le commutateur /interactif est déprécié.
cependant, je suis tombé sur cet article qui démontre l'utilisation de PSTools à partir de SysInternals (qui a été acquise par Microsoft en juillet 2006.) J'ai lancé la ligne de commande via la commande suivante et soudain, j'ai été exécute sous le Compte Admin 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.
merci Beaucoup à ceux qui ont offert leur aide.
- télécharger psexec.exe de Sysinternals .
- placez-le dans votre lecteur C:\.
- Se connecter en tant qu'utilisateur standard ou administrateur et utiliser la commande suivante:
cd \. Cela vous place dans le répertoire racine de votre lecteur, où psexec est situé. - , Utilisez la commande suivante:
psexec -i -s cmd.exeoù i est interactif et -s pour compte du système. - quand la commande terminé, un shell cmd sera lancé. Type
whoami; il dira "système " - Ouvrir le gestionnaire des tâches. Tuer explorer.EXE.
- D'un shell de commandement élevé du type
start explorer.exe. - lorsque l'explorateur est lancé, notez le nom" système " dans la barre de menu Démarrer. Maintenant, vous pouvez supprimer certains fichiers dans le répertoire system32 que vous ne pouvez pas supprimer en tant qu'administrateur ou en tant qu'administrateur.
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 de la renommer 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 essayer de le renommer après avoir changé la permission, il fonctionnera et pendant que vous exécutez Windows explorer avec les privilèges du noyau vous êtes un 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 pour obtenir l'accès retour
a 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 dit que cela ne marchait pas pour lui et quand je l'ai essayé sur Windows Server 2008 il a créé le cmd.processus exe sous le système local, mais il n'était pas interactif (Je ne pouvais pas voir la fenêtre).
Je ne pense pas qu'il y ait une façon facile de faire ce que vous demandez, mais je me demandais pourquoi vous le faites? Essayez-vous juste de voir ce qui se passe quand vous dirigez votre service? Il semble que vous pourriez juste utiliser la journalisation pour déterminer ce qui se passe au lieu d'avoir à exécuter l'exe comme système local...
je vous recommande d'élaborer l'ensemble de permission 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, ne montrent plus D'interface utilisateur-sur Windows Vista et Windows Server 2008 en raison de session 0 isolation .
une alternative à cela est le Process hacker si vous allez dans run as... (Interactive doesnt work for people with the security enhancments but that wont matter) le type de boîte et mettre le système dans la boîte de l'utilisateur et mettre C:\Users\Windows\system32\cmd.exe quitter le reste cliquez sur ok et boch vous avez une fenêtre avec cmd sur elle et exécuter comme le système maintenant faire les autres étapes pour vous-même parce que je suggère que vous les connaissez
utilisant un bureau sécurisé pour exécuter cmd.exe système
nous pouvons obtenir l'accès au noyau par CMD dans windows XP/Vista/7/ 8.1 facilement en attachant un debugger REG ajouter "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\osk.exe " / V Debugger / t REG_SZ / d "C:\windows\system32\cmd.exe 151910920"
1.Exécuter CMD en tant qu'administrateur
2.ensuite, utilisez cette commande dans le CMD Elavated REG ajouter "HKLM\SOFTWARE \ Microsoft\Windows NT\CurrentVersion\Image File Execution Options\osk.exe " / V Debugger / t REG_SZ / d "C:\windows\system32\cmd.exe 151910920"
3.Ensuite, lancer osk onscreenkeyboard il ne fonctionne toujours pas avec le niveau D'intégrité du système Si vous vérifiez le processus explore, mais si vous pouvez utiliser OSK en session service Oui, il sera exécuté comme système d'authentification NT
donc, j'ai une idée, vous devez l'exécuter sur le Bureau Sécurisé
démarrer n'importe quel fichier en tant qu'administrateur lorsque UAC demande apparaît juste appuyez sur la touche windows + U et démarrer OSK et il va démarrer CMD à la place, puis dans Whoami élevé prompt type commande et vous obtiendrez sortie système D'Autorité NT et vous pouvez commencer explorer à partir de la commande shell système et entrer profil du système, mais vous êtes quelque peu limité ce que vous pouvez faire sur le réseau à travers les privilèges du système pour des raisons de sécuritéSi va ajouter plus d'explication plus tard comme je l'ai découvert il ya un an. Une brève explication de la façon dont cela se produit
Exécution De La Commande Cmd.EXE Sous Compte Système Local Sans Utiliser PsExec. Cette méthode exécute la technique de trappe de débogueur qui a été découverte plus tôt, bien cette technique a ses propres avantages, elle peut être utilisée pour piéger certains vers malicieux/malicieux ou malware dans le débogueur et exécuter un autre exe à la place pour arrêter la propagation ou les dommages temporaires. ici, cette clé de registre bloque le clavier à l'écran dans Windows native debugger et exécute cmd.exe à la place mais cmd continuera à fonctionner avec les privilèges des utilisateurs connectés, cependant si nous exécutons cmd dans la session0 on peut avoir shell système. donc, nous ajoutons ici une autre idée nous enjambons le cmd sur le bureau sécurisé rappelez-vous que le bureau sécurisé fonctionne dans la session0 sous le compte système et nous obtenons shell système.donc, chaque fois que vous lancez quelque chose comme elevated vous devez répondre à l'invite UAC et UAC sur dark non interactive desktop et une fois que vous le voyez, vous devez appuyer sur Windows key + U et ensuite sélectionner OSK vous obtiendrez CMD.exe fonctionnant 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
il y a un autre moyen. Il existe un programme appelé PowerRun qui permet d'exécuter des cmd élevés. Même avec TrustedInstaller droits. Il permet à la fois les commandes console et GUI.
j'utilise le RunAsTi utilitaire pour exécuter en tant que TrustedInstaller (haut droit). L'utilitaire peut être utilisé même dans le mode de récupération de Windows (le mode que vous entrez en faisant Shift + Restart ), le PsExec utilitaire ne fonctionne pas là. Mais vous devez ajouter vos chemins C:\Windows et C:\Windows\System32 (pas X:\Windows et X:\Windows\System32 ) à la variable d'environnement PATH , sinon RunAsTi ne fonctionnera pas en mode récupération, il se contentera d'imprimer: Adjusttokenprivilèges pour SeImpersonateName: tous les privilèges ou groupes référencés ne sont pas attribués à l'appelant .