Group Managed Service Accounts (gMSA) vs. Service Accounts. How to use them?

First of all, you need to download some things. We’re going to use two tools:

• PsExec

A tool was written by Mark Russinovich, which you can download from sysinternals.com. We will need this tool to elevate to the local system account. In this way we’re going to have effective local system accounts privileges – these are the ones that are needed to get access to the registry.

• CQ Secrets Dumper

We’re going to be extracting passwords from the registry by getting access to LSASS secrets using our CQURE Academy tool – CQ Secrets Dumper, which is a custom-built tool by our team. We practically use it in a penetration test.

Access to the CQ Secrets Dumper tool:
 

Let’s look at Freddy Krueger…

This particular service represents a situation seen in many companies, where the services are misconfigured. This one is running on a dedicated account. In this case, it’s Freddy Krueger, but of course, it can be anything. It can be SVC_ something. The problem that we have here is:

• probably the password for that account never expires,
• probably the password is also used within the different service accounts,
• probably the password is simple, and if it’s not simple, then for sure it is stored in the registry because this is how Logon as a service works.

Not to really mention over here what can else be wrong with this particular service and service account, but quite often what we see are wrongly configured SPNs or service principal names. But this is the subject for another time.

How to elevate to localsystem using PsExec tool?

We got here console running as Administrator. We will launch regedit, and we got a security hive that we need to get access to. Unfortunately, we cannot get access to it, because permissions say the system has full control, but Administrators not, they don’t even have read access.

What we should do is to elevate to localsystem.

We are going to use a tool that is called PsExec, which you previously downloaded from sysinternals.com.

We going to use it with the following parameters. -s -i -d CMD.EXE.

These parameters stand for -s to run also localsystem, -i to make it interactive, (because we are running this as a service), -d to run it in a separate window. We’ve got a CMD.EXE as a process to start.

As you can see, we are NT Authority\System. This is all good. It’s worth mentioning that by default the console is not red. We made it red to differentiate between what is running as a localsystem, and what is running as an admin. It’s very convenient since the titles of the consoles are exactly the same, so this is how we’re able to quickly see.

How to get the password of the service account using CQ Secrets Dumper?

In order to get the password for that service account, we will use the tool that our team has written.

We are going to use it for the service account, so we will use the service parameter.

Now, we will specify the name of the service which is PJService. This is how the service is visible in the registry. You can see that the password that we got right now in clear text. This is exactly the password for the Freddy Krueger account.

How can we mitigate this?

The answer to that question is quite simple.

For that purpose, we will use the group managed service accounts that can be running within the company, within the domain, where you’ve got the domain updated, to the schema updated to at least Windows Server 2012. From the functional level perspective, it needs to be at least 2003, but it’s better when it’s 2008 – then you don’t have to register manually SPNs that we’ve mentioned before.

When we got it all set, it’s time to switch to the domain controller to generate something that we call a key distribution service root key. We have to generate it once because this will be the key from which we will be generating passwords for the gMSAs. For that, we need to switch right to the domain controller.

Once we are on the domain controller machine, in order to generate, the KDS root key, we put command: Add-KdsRootKey. There is a parameter, which is called: EffectiveImmediately. This is quite an interesting parameter because it indicates that things can happen immediately. But not really. Things will happen, so the key will be generated in ten hours. It’s effective in ten hours – that means that you have to wait ten hours. We can also use a little trick as well for our test environment, where we will specify that the effective time will be ten hours ago.

You can run overnight the EffectiveImmediately parameter, come in the morning, and then things will happen. This is what we run within the production environment, but within our lab environment, we can run it with the EffectiveTime parameter. We are specifying (get-date).AddHours(-10) as a value. This is effective ten hours ago. A little bit of cheating here, but it’s good for the lab environment if you want to play with the gMSAs, if you want to start using them now.

How to create group Managed Service Accounts?

We are ready to go. Now, it’s time to switch back to the server with the service.
We will use PowerShell to perform all activities to create gMSAs (group Managed Service Accounts). In order to do that on a server that is different from a domain controller, we have to install the PowerShell module for the active directory, which is part of the RSAT (remote server administration tools), which you can find built-in, in the servers. For that purpose, to create the gMSA, we have to use the New-ADServiceAccount cmdlet that where we specify -Name, and our name could be, for example, CQUREHacks.

The next parameter that we are using, it’s DNSHostName. That DNS hostname is actually a fully qualified domain name of the domain controller that holds the KDS root key that we were playing with. So, in our case, it is WS12R2-DC.cqured.tec. Now, we need to specify a quite interesting parameter, which is PrincipalsAllowedToRetrieveManagedPassword. And that’s the parameter that allows you to specify either a group of the servers that you’re going to be running this particular gMSA on or you can specify the particular hostname.

In our case, we will use the hostname. We can put here the W12R2-NODE2$. If you’re going to put here a different server, then we will not be able to install it on the note too. You have to specify here particular servers that you’re going to be using with gMSAs for future. As soon as we got it done, we have to install this particular account. You should use Install-ADServiceAccount with the parameter “-Identity CQUREHacks”. Then let’s test if everything went fine. For us, it’s “Test-ADServiceAccountIdentity -Identity CQUREHacks”. The result is “True”, which means it’s all good.

Now, we are happy to change Freddy Krueger’s account into our group managed service account. Here we can specify object types. We’ve got a built-in security principal, because this is just a local workstation, we can get into the active directory, so let’s do it. And in object types, you’ve got right now service accounts and regular users.

Now it’s time to specify here CQUREHacks. Remember to check names. Look out, because if you do apply, it says valid. You do not need to enter a valid password. If you do it like this, the password will be automatically generated. Click ‘Apply’. This particular account has been granted a log on as a service right and it will not be effective for the service until we restart it.

If everything is ok, let’s do it: right-click, restart. This service right now works as the CQUREHacks, gMSA. We need to verify, using the same technique with the CQ Secrets Dumper tool. We verify what’s the password, and, this is quite tricky, because the password is still in their registry, yes? So, we are using this for the PJ service, but we have just changed this account. What’s wrong? Well, sometimes it happens like this, so if you’re going to be in this situation, don’t forget to go regedit, then go to the HKLM, Security, policy, and then secrets. Then you can delete a secret for the PJ service because it’s no longer used. We are right now using the gMSA service, so you can just delete it. Effectively we are all on the safe page. The secret, the password, it’s no longer in the registry.

I hope that you like it. If you have any questions, please drop them in the comments section.

Stay CQURE!

Keep an eye on Active Directory – take the 2-hours training from CQURE CyberBytes series and stay prepared for advanced attacks