7

When setting up a Windows service, one specifies a user account to use for authentication, as well as the password for that user. In their guidelines for user account selection, Microsoft states that when using a domain user account,

Be aware that even though the service control manager (SCM) stores the password in a secure portion of the registry, it is nevertheless subject to attack.

They make no mention of what such an attack would look like. I assume that one would want to have administrative privileges on the OS hosting the service, and it would seem that the password is only used when the service is started, so that restarting it could play a role.

So, the question is: What does Microsoft mean when they say that a domain user's password is subject to attack? And, are there any substantial differences between the (more recent) versions of the OS?

fuglede
  • 173
  • 1
  • 1
  • 4

2 Answers2

5

One method to access LSA secrets is documented here.

In a nutshell:

  • Call the Enable-TSDuplicateToken function.

  • Copy the existing registry keys to another, temporary key.

  • User Powershell or another framework to call the functions to read the secrets.

You can also use the NirSoft LSASecretsView tool.

You do indeed have to already have admin privileges on the system, and as far as I know there are no differences in recent versions of Windows (other than the mitigations that McMatty already pointed out).

Royce Williams
  • 9,128
  • 1
  • 31
  • 55
  • Absolutely excellent; exactly what I was looking for while being more than I could have hoped for. – fuglede Jan 26 '18 at 18:36
  • 1
    Using the two scripts from the blog posts out of the box, I run into a `Exception calling "PtrToStructure" with "2" argument(s): "The specified structure must be blittable or have layout information.` Applying the patch from https://github.com/samratashok/nishang/commit/9abdbb78eedb7f0a9be9e610b2ca263d29e996c5 takes care of that, and from then on it's smooth sailing on both Windows 8 and Windows Server 2008 R2. Surprisingly and eerily smooth really. – fuglede Jan 26 '18 at 19:27
0

So the first thing is that this account is going to have a credential pair that if extracted will grant additional access around the network. Some of your machines may be setup to allow Domain User to log on to machines or this account has access to a machine an attacker is trying to reach. So this service account identity now has access to other resources.

Attacks

The following are just attacks against the machine and account - hashes can also be intercepted and cracked offline or used in pass-the-hash attacks

A user account credentials may also be set up a person that chooses a weak guessable password and depending on lockout settings (if they are enabled) it could be brute forced.

Given System or Administrator rights an attacker can attempt to run mimikatz to extract the credentials from the service account.

Mitigations

For a service that requires permissions to other domain resources if you can use a managed service account - this eliminates the password aspect as it is now managed and rotated by the computer.

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd560633(v=ws.10)

Credential guard on Windows 10 and Server 2016. It will remove the ability for mimikatz and other memory based attacks to extract credentials from the lsa.

https://blog.nviso.be/2018/01/09/windows-credential-guard-mimikatz/

McMatty
  • 3,192
  • 1
  • 7
  • 16