Protected Users Group

This is a follow up from my last post on Abusing Windows Cached Credentials. @blueteamer pointed out a very good observation that is sometimes over looked. I know I forgot about it. If you are on a Server 2012 R2 or newer there is a group called protected users. I am going to target the account rootsecdev to this group.

Before being added to the group:

Since I already have a shell to the Win7 client I am going to add this account to the group since I am nice like that.

Well I’ve been denied.. that’s not good.. but I am running under the context of NT Authority\system

At this point I need to impersonate a user

Now that I successful impersonated rootsecdev’s token I should be able to add the account to the protected users group.

A small note on impersonating tokens. The user does have to be logged onto the system at the time to impersonate the token.

Now that I’ve verified they are a part of the protected users group

Some Follow up once added to the group.

1. Being a protected user doesn’t protect your current credentials on each workstation automatically. Once a network id is added to the “protected users” group please change the password immediately before you log into any more workstations/servers.
2. On Windows 7, 2008 R2, Windows Server 2012 you will need to apply Advisory 2871997 to get protection >> https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2016/2871997
3. Once the security advisory is applied and the target workstation is rebooted you should see that you are no longer able to obtain the salted hash on the protected group credential

This will also shut down some other avenues of access. For example lets use the module windows/smb/psexec with the current stolen credential.

As you can see in the above screen shot the psexec exploit failed because of a service Status Account Restriction.