8

I've been trying to wrap my head around how computers are identified and granted access to a Windows domain. More specifically, I've been asking myself if whatever mechanism is involved really prevents faking the identity of a computer or not, and if so, then how?

Assuming one has full access to a computer that is already on the domain, I'm thinking that whatever information the domain controller relies on for identification could be replicated on another computer.

(As I understand it, what identifies a computer in a domain is one LSA shared secret. According to this Technet blog, LSA shared secrets can be decrypted and extracted.)

According to this answer to a question on Server Fault about re-joining a wiped computer to a domain it used to be on, and here on Information Security, this one about similar topics, it's not possible to have a computer assume even an existing identity in a windows domain.

If this is true, I would like to know the principle of behind this prevention mechanism. The answers given in the above links to me do not contain enough insight.

If the above claims are false, and it is in fact possible to fake the identity of a computer on the domain given the right circumstances, I would like in summary to know what steps would be involved.

Thank you beforehand for any effort to help me out.

Community
  • 1
Oskar Lindberg
  • 393
  • 3
  • 10
  • Usually the identification of a computer isn't really what keeps the system safe. A lot of time it is an identifier. Usually there is another method coupled with this like a username and password which is harder to fake. – Terry Mar 01 '16 at 13:32

1 Answers1

7

When workstation joins domain, following happens:

  • Workstation creates some random password, asks Domain Controller to create machine account and associate it with this password. User account must have "Add machine to domain" permission, domain admins do have this permission.
  • Since Windows does not use names internally, but use SIDs for any account, workstation sid (may be checked with psgetsid) is stored in domain with associated password (password is stored in unicodepwd as any user password, see https://technet.microsoft.com/en-us/magazine/ff848710.aspx)

  • Machine stores password in HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\$MACHINE.ACC. Only NT AUTHORITY\SYSTEM has access to this hive. Even local admin does not have (it is not registry permission, it is something hardcoded in Windows, I am sure).

  • DC and workstation change password periodically. Funny, but old password stored there too (oldVal subkey). Pass may be reset manually: https://support.microsoft.com/en-us/kb/260575

This process is described here: https://blogs.technet.microsoft.com/askds/2009/02/15/machine-account-password-process-2/

Since all passwords for accounts are stored in HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets and only NT AUTHORITY\SYSTEM has access to this hive, person from article used powershell to impersonate its process to this account. You can do the same with psexec -i -s cmd.exe, and them launch regedit from there. Open $MACHINE.ACC and check it for CurrVal.

This hive also stores information about security permissions each account have, and all this is part of Local Security Policy (see https://msdn.microsoft.com/en-us/library/windows/desktop/ms721785(v=vs.85).aspx) managed by lsass.exe.

So, to fake PC you should at least be able to:

  • Log into it
  • Be able to run code as NT AUTHORITY\SYSTEM (be local admin and use tool like psexec)
  • Read its password from $MACHINE.ACC
  • Read its sid (with psgetsid)

And on another machine

I am not sure if it is enough to fake PC or not, but even this thing is does not look very easy: at least you need local admin permissions on another PC to impersonate System, and good IT whould never give you this access.

user996142
  • 308
  • 1
  • 7
  • This is a really good and informative answer - thank you! Regarding the setting of a specific machine SID there are several options, e.g. [SIDCHG](http://www.stratesave.com/html/sidchg.html). – Oskar Lindberg Mar 02 '16 at 07:13
  • I would like to ask for clarification on one thing; Am I correct in assuming that, in your opinion, there's nothing in theory that prevents the transferring of one computer identity onto another? That is, you agree with my assumption that given access to enough information, it can be faked, and the domain controller will not be able to tell the difference - the claims made that it's _impossible_ to impersonate a computer on the domain, are false? – Oskar Lindberg Mar 02 '16 at 10:29
  • @OskarLindberg if you have full access to PC1 then yes, you may fool domain controller and make it believe that PC2 is PC1. But if you have full access, you can do anything! You can copy image (using backup) and restore it no another PC. – user996142 Mar 02 '16 at 15:11
  • Yes. I just wanted to learn and understand. I guess the domain controller _could have_ signed the information on the local computer or something, if Microsoft wanted to further prevent fiddling with it. I don't really see any problem with any of it, given the context. At least not more than with people i general sharing their secrets with others. And it's hard to see any real life practical application. I'm no ninja hacker though. – Oskar Lindberg Mar 02 '16 at 15:47
  • Anything stored on PC1 (including signed data) could be moved to PC2 if one has full access to PC1:) In theory, you may bind to nic mac address, hardware serial numbers (there are a lot of on modern mother boards)), but you do not want your PC to be unrecognized by DC just because you changed network controller:) You are right, there is no reason to still computer password unless someone gave some access to PC for network share or some other place, but I hope people do not do that. d – user996142 Mar 02 '16 at 16:11
  • Yes I get that, but if the signature was combined with a hash I thought it might prevent changing the value on PC2 (because you can't re-sign it with the theoretical domain secret key). But you're right, I didn't think that through. I'm not sure what data should actually be signed in this case, to make it work. – Oskar Lindberg Mar 02 '16 at 16:14