No Windows 7, como posso recuperar / definir senha do sistema (não administrador)?

Question

Ok, então eu sei que em muitas variantes unix, você pode configurar um usuário root / admin, um usuário padrão, etc. E por padrão algumas vezes em algumas distribuições Linux o superusuário 'root' é conhecido por ter uma senha padrão . Por exemplo (apenas exemplo) em uma distribuição do Oracle Linux, a senha padrão pode ser apenas 'oracle'.

Agora, no lado do Windows, estou tentando entrar na conta do sistema, pois aparentemente o acesso está sendo negado, mesmo executando coisas como 'Administrador' no computador, como regedit, ainda pode me negar acesso.

Eu observo no agendador de tarefas e em algumas outras áreas, parece haver alguma senha especial ou criptografada para o 'LocalService' & Usuários do 'NetworkService', que pela Microsoft foram programados para fazer coisas como iniciar o agendador de tarefas, executar processos em segundo plano, etc. Então, se há uma maneira de descobrir as senhas padrão usadas para essas contas, isso ofereceria muita ajuda. Se não for capaz de simplesmente decodificá-los, eu os restaurarei se houver alguma coisa.

De qualquer forma, existe uma senha de sistema padrão para o Windows? Eu essencialmente preciso de acesso de superusuário para minha máquina local, então se você puder, agradeço.

P.S. Eu sei que no passado havia alguns exploits que eu costumava aproveitar (para meu próprio uso) no Windows em minha máquina para executar coisas em um nível de privilégio mais alto. No Windows XP, matando o explorador através do gerenciador de tarefas e, em seguida, iniciando-o novamente via schedtasks devido a uma falha de segurança que permitia isso, etc.

Então, se de alguma forma, (e isso é apenas para minha máquina, não estou tentando fazer isso na máquina de outra pessoa) Eu preciso ter acesso à conta de superusuário (a?) na máquina. Minha melhor aposta neste momento seria usar LocalService, ou SYSTEM, já que seria muito poderoso o suficiente para obter as coisas que eu preciso fazer.

Obrigado pela sua ajuda!

Atenciosamente

    

Answer 1

As contas SYSTEM e NETWORK SERVICE não são contas reais e não existem no SAM - em outras palavras, elas não podem ter uma senha definida e você não pode fazer login nelas. Eles existem apenas como "SIDs conhecidos" ( identificadores de segurança ) - O Windows simplesmente dá um tratamento especial a esses SIDs como S-1-5-18 ou S-1-5-20 , semelhante a como o uid 0 é especial no Unix, e programas privilegiados podem usar isso conta criando próprios tokens (semelhante a chamar setuid() + capset() no Unix).

Uma maneira fácil de executar programas com privilégios SYSTEM é através do PsExec da Sysinternals:

psexec -dsi cmd

No entanto, ao contrário do Unix root , nem mesmo SYSTEM tem permissão para ignorar ACLs de objeto - é por isso que todas as entradas de registro, arquivos de sistema e outras coisas mostram explicitamente SYSTEM em suas ACLs. Em vez disso, se um administrador precisar, por algum motivo, substituir a ACL de um objeto, ele poderá apropriar-se desse objeto usando SeTakeOwnershipPrivilege ¹ (concedido por padrão a todos os administradores). Isso funciona porque o proprietário de um objeto tem permissão para alterar suas ACLs, mesmo que elas o neguem explicitamente; esta é a única exceção ² que o Windows faz.

Às vezes, o acesso está sendo negado devido a outros motivos - muitos programas antivírus vêm com drivers de kernel de "autodefesa", que corrigem várias funções no próprio kernel do Windows e os rejeitam a modificações em chaves ou arquivos específicos baseados somente em seus nomes; o bloco é antes das verificações de ACL originais, e nenhuma permissão ou privilégio pode substituí-lo. A única maneira de contornar essa proteção é desfazer as modificações do kernel; qualquer depurador de kernel pode ser usado para isso. Ferramentas como Kernel Detective podem listar todas as entradas no SSDT, o qual o driver do kernel modificou qual função, e até ter comandos para redefinir os valores padrão.

¹ Se curioso, você pode usar o Process Explorer para visualizar todos os SIDs e bits de privilégios atribuídos a um processo específico. Você verá que nem mesmo os processos do sistema têm qualquer tipo de privilégio genérico "substituir segurança" ; Em vez disso, apenas privilégios específicos como < SeImpersonate, SeTakeOwnership ou SeCreateToken existem.

² Para arquivos , alguém segurando SeBackupPrivilege pode ler um arquivo no "modo de backup" - um arquivo contendo dados, metadados, ACLs , propriedade ... - então, opcionalmente, modifique-o e restaure-o no sistema de arquivos novamente. Ou seja, supondo que alguém tenha feito engenharia reversa na estrutura desses arquivos de backup. Isso não está disponível para outros tipos de objetos.