Como o MarkM já explicou por que não devemos substituir e restaurar senhas de usuário, tentarei abordar como o sistema nos impede de fazer essas alterações.
No Unix, os hashes de senha eram originalmente armazenados em /etc/passwd e podiam ser lidos por qualquer pessoa. Percebendo que isso permitia que qualquer usuário potencialmente roubasse senhas, os sistemas unix mais recentes armazenam os hashes de senha em /etc/shadow , o que só é legível por root .
O Windows seguiu um caminho semelhante. Em um ambiente de domínio, os hashes de senha dos usuários de domínio são armazenados na seção de registro SAM em cada controlador de domínio. Você provavelmente já está familiarizado com colmeias como HKLM e HKCU.
A partir do Windows 2000, o hive SAM é criptografado com uma chave de criptografia de senha de 128 bits, que é criptografada usando o SYSKEY . Deve ficar evidente que, como o sistema operacional deve ler o conteúdo da seção para autenticar os usuários no logon, a chave de criptografia deve ser salva no computador em algum lugar. Para uma cobertura mais aprofundada das técnicas de obscurecimento usadas, confira o SysKey e o SAM .
O Windows tenta impedir que usuários administrativos leiam / gravem os hashes diretamente e, normalmente, apenas lsass.exe executando como o usuário SYSTEM é capaz de ler os hashes.
No entanto, tenho certeza de que você encontrou ferramentas que ignoram essas proteções. Por exemplo, fgdump é capaz de exportar hashes de senha de um sistema ativo injetando código em lsass.exe , embora isso possa potencialmente travar todo o sistema. E há uma grande variedade de ferramentas inicializáveis que podem substituir hashes de senha quando o Windows não está em execução.
Embora seja teoricamente possível substituir as senhas de usuário, primeiro é necessário contornar uma ampla variedade de proteções incorporadas ao sistema operacional Windows. Qualquer um desses métodos tem o potencial de desestabilizar seu sistema e nunca deve ser usado em um ambiente de produção.