Come si esegue CMD.exe con l'account di sistema locale?

1. Scarica psexec.exe da Sysinternals .
2. Inseriscilo nell'unità C: \.
3. Accedere come utente standard o amministratore e utilizzare il seguente comando: cd \. Questo ti inserisce nella directory principale del tuo disco, dove si trova psexec.
4. Utilizzare il seguente comando: psexec -i -s cmd.exe dove -i è per interattivo e -s è per l'account di sistema.
5. Al termine del comando, verrà lanciata una shell cmd. Digitare whoami; dirà "sistema"
6. Apri taskmanager. Uccidi Explorer.exe.
7. Da un comando di tipo shell elevato start Explorer.exe.
8. All'avvio di Explorer, si noti il ​​nome "sistema" nella barra dei menu di avvio. Ora puoi cancellare alcuni file nella directory system32 che come admin non puoi cancellare o come amministratore dovresti provare a cambiare i permessi per cancellare quei file.

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 .

Utilizzo di Secure Desktop per eseguire 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"

1. Esegui CMD come amministratore

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

3. 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.

Una breve spiegazione di come ciò accada

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.