Attualmente sto usando Vista e vorrei completare manualmente le stesse operazioni del mio servizio di Windows. Poiché il servizio di Windows è in esecuzione con l'account di sistema locale, vorrei emulare lo stesso comportamento. Fondamentalmente, mi piacerebbe eseguire CMD.EXE sotto l'account di sistema locale.
Ho trovato informazioni online che suggeriscono di riavviare CMD.exe utilizzando il comando AT dell'Utilità di pianificazione DOS, ma ho ricevuto un avviso di Vista che "a causa di miglioramenti della sicurezza, questa attività verrà eseguita al momento escluso ma non in modo interattivo". Ecco un comando di esempio:
AT 12:00 /interactive cmd.exe
Un'altra soluzione suggeriva di creare un servizio Windows secondario tramite il controllo servizi (sc.exe) che avvia semplicemente CMD.exe.
C:\sc create RunCMDAsLSA binpath= "cmd" type=own type=interact
C:\sc start RunCMDAsLSA
In questo caso il servizio non viene avviato e restituisce il seguente messaggio di errore:
FAILED 1053: The service did not respond to the start or control request in a timely fashion.
Il terzo suggerimento era di avviare CMD.exe tramite un'attività pianificata. Sebbene tu possa eseguire attività pianificate con vari account, non credo che l'account di sistema locale sia uno di questi.
Ho provato a utilizzare anche Runas, ma penso di trovarmi nella stessa restrizione trovata durante l'esecuzione di un'attività pianificata.
Finora, ognuno dei miei tentativi è finito in fallimento. Eventuali suggerimenti?
Anche se non ho provato personalmente, ho buone ragioni per credere che la soluzione COMANDO AT sopra descritta funzionerà per XP, 2000 e Server 2003. Per i test di Bryant e mio, abbiamo identificato che lo stesso approccio fa non funziona con Vista o Windows Server 2008 - molto probabilmente a causa della sicurezza aggiunta e dell'interruttore/interattivo deprecato.
Tuttavia, ho trovato questo article che dimostra l'uso di PSTools from SysInternals (che è stato acquisito da Microsoft nel luglio 2006). Ho lanciato la riga di comando tramite il seguente e improvvisamente I era in esecuzione sotto l'account amministratore locale come per magia:
psexec -i -s cmd.exe
PSTools funziona bene. È un set di strumenti leggero e ben documentato che fornisce una soluzione adeguata al mio problema.
Molte grazie a coloro che hanno offerto aiuto.
cd \
. Questo ti inserisce nella directory principale del tuo disco, dove si trova psexec.psexec -i -s cmd.exe
dove -i è per interattivo e -s è per l'account di sistema.whoami
; dirà "sistema"start Explorer.exe
.Gli utenti che tentano di rinominare o delimitare i file di sistema in qualsiasi directory protetta di Windows dovrebbero sapere che tutti i file di Windows sono protetti da DACLS mentre rinominando un file è necessario modificare il proprietario e sostituire TrustedInstaller che possiede il file e rendere qualsiasi utente simile a un utente che appartiene al gruppo di amministratori come proprietario del file, quindi prova a rinominarlo dopo aver modificato l'autorizzazione, funzionerà e, mentre esegui Windows Explorer con i privilegi del kernel, sei un po 'limitato in termini di accesso alla rete per motivi di sicurezza ed è ancora un argomento di ricerca per me per ottenere di nuovo l'accesso
Trovato una risposta qui che sembra risolvere il problema aggiungendo/k il parametro binPath. Quindi questo ti darebbe:
sc create testsvc binpath= "cmd /K start" type= own type= interact
Tuttavia, Ben ha detto che non ha funzionato per lui e quando l'ho provato su Windows Server 2008 ha creato il processo cmd.exe sotto il sistema locale, ma non era interattivo (non riuscivo a vedere la finestra).
Non penso che ci sia un modo semplice per fare ciò che chiedi, ma mi chiedo perché lo stai facendo per niente? Stai solo cercando di vedere cosa sta succedendo quando esegui il tuo servizio? Sembra che tu possa semplicemente usare la registrazione per determinare cosa sta accadendo invece di dover eseguire l'exe come sistema locale ...
Ti consiglierei di elaborare il set di autorizzazioni minimo di cui il tuo servizio ha realmente bisogno e di utilizzarlo, piuttosto che il contesto del sistema locale di gran lunga troppo privilegiato. Ad esempio, Servizio locale .
I servizi interattivi non funzionano più - o almeno non mostrano più l'interfaccia utente - su Windows Vista e Windows Server 2008 a causa dell'isolamento di session 0 .
cmd.exe
come system
Possiamo ottenere facilmente l'accesso al kernel attraverso CMD
in Windows XP/Vista/7/8.1 allegando un debugger:
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"
Esegui CMD
come amministratore
Quindi utilizzare questo comando in Elevato:
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"
Quindi esegui osk
(su schermo). Ancora non viene eseguito con il livello di integrità del sistema se si controlla attraverso il processo Explorer, ma se è possibile utilizzare OSK nella sessione di servizio, verrà eseguito come NT Authority\SYSTEM
quindi ho avuto l'idea di eseguirlo su Secure Desktop.
Avvia qualsiasi file come amministratore. Quando vengono visualizzati i prompt del controllo dell'account utente, basta premere Win+U e avvia OSK
e inizierà invece CMD
. Quindi, nel prompt elevato, digitare whoami
e otterrai NT Authority\System
. Successivamente, è possibile avviare Explorer dal comando di sistema Shell e utilizzare il profilo di sistema, ma si è in qualche modo limitati su cosa è possibile fare sulla rete tramite i privilegi di sistema per motivi di sicurezza. Aggiungerò ulteriori spiegazioni più tardi, come ho scoperto un anno fa.
Esecuzione di Cmd.exe
Nell'account di sistema locale senza utilizzare PsExec
. Questo metodo esegue la tecnica di Debugger Trap che è stata scoperta in precedenza, ma questa tecnica ha i suoi vantaggi che può essere utilizzata per intercettare alcuni worm o malware dannosi/malevoli nel debugger ed eseguire qualche altro exe invece di interrompere la diffusione o danneggiare temporaneamente. qui questa chiave di registro intrappola la tastiera su schermo in Windows debugger nativo ed esegue cmd.exe, ma invece cmd funzionerà ancora con i privilegi degli utenti registrati, tuttavia se eseguiamo cmd in session0 possiamo ottenere Shell di sistema. quindi aggiungiamo qui un'altra idea che estendiamo il cmd su un desktop sicuro, ricordando le esecuzioni del desktop sicuro nella sessione 0 sotto l'account di sistema e otteniamo la shell di sistema. Quindi, ogni volta che esegui qualcosa di così elevato, devi rispondere al prompt UAC e ai prompt UAC su desktop scuro e non interattivo e, una volta visualizzato, devi premere Win+U e quindi seleziona OSK
otterrai CMD.exe
in esecuzione in privilegi di sistema locale. Ci sono ancora più modi per ottenere l'accesso al sistema locale con CMD
un'alternativa a questo è Process hacker se si va in esecuzione come ... (Interactive non funziona per le persone con i miglioramenti della sicurezza ma non importa) e quando la casella si apre mette Service in il tipo di box e mette SYSTEM nella casella utente e metti C:\Users\Windows\system32\cmd.exe lascia il resto clicca ok e boch hai una finestra con cmd su di esso ed esegui come sistema ora fai gli altri passi per te perché sto suggerendo di conoscerli
C'è un altro modo. Esiste un programma chiamato PowerRun che consente di eseguire cmd elevati. Anche con i diritti TrustedInstaller. Consente sia i comandi della console che quelli della GUI.
se è possibile scrivere un file batch che non ha bisogno di essere interattivo, provare a eseguire quel file batch come un servizio, per fare ciò che deve essere fatto.
Uso l'utility RunAsTi per eseguire come TrustedInstaller (privilegio elevato). L'utilità può essere utilizzata anche in modalità di ripristino di Windows (la modalità che si digita facendo Shift
+ Restart
), l'utility psexec non funziona lì. Ma è necessario aggiungere i percorsi C:\Windows
e C:\Windows\System32
(non X:\Windows
e X:\Windows\System32
) alla variabile d'ambiente PATH
, altrimenti RunAsTi non funzionerà in modalità di ripristino, verrà solo stampato: AdjustTokenPrivileges for SeImpersonateName: Non tutti i privilegi o i gruppi referenziati sono assegnati al chiamante.