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 1 (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 2 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.
1 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.
2 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.