How To Compromise Services With Built In Network Service Account

Windows service accounts are one of the preferred attack surface for privilege escalation. If you are able to compromise such an account, it is quite like shooting fish in a barrel to get the highest privileges, mainly due to the powerful impersonation privileges that are granted by default to services by the operating system.

Fifty-fifty if Microsoft introduced WSH (Windows Service Hardening), there isn't much you can do to "lower" the power of standard Windows services, but if you need to build or deploy a 3rd-party service y'all tin definitely strengthen it by using WSH.

In this post I will show you some useful tips.

Brand use of Virtual accounts

Apparently a service must be run with a specific account. There are some built-in Windows accounts like SYSTEM (oh no !!), Local Service, and Network Service. But there is also the ability to use Virtual Accounts (I won't write about "Group Managed Service Accounts" in this mail) which are self-managed (no need to deal with passwords) and y'all tin can grant specific permissions by setting the correct ACL's on the resources. This allows you to isolate the service and in case of compromise, they tin only access the resources y'all accept immune. Virtual accounts can too admission network resources, only in this instance they will impersonate the computer business relationship (COMPUTERNAME$)

Configuring Services with Virtual Accounts

First of all, you lot don't need to create VSAs, when the service is installed, a matching business relationship is automatically created for yous in the grade:

NT SERVICE\<service name>

all you need is to assign the account to your service:

Don't forget to leave the countersign field blank!

Restricting access to Virtual Accounts

At present that your service runs under a specific account and not a generic one like Local Service or Network Service , you can implement fine-grained admission control on resources like files and directories:

Removing unnecessary privileges

Impersonation privileges are a nightmare, so if your service doesn't need to impersonate, why should we grant them to this service user?

Is it possible to remove this default privilege? In that location is a good news, yes! Nosotros can configure the privileges directly in registry or past using the "sc.exe" command:

And these values will be written into registry:

Permit'southward see if the the privilege is removed:

Oh yeah! The dangerous privilege has been removed and it's no more possible to get him back, for instance using @itm4n 'south trick described in this great post.

Write Restricted Token

If you add this extra group to your service tokens, you lot tin can further limit the permissions of your service account.

This means that past default you lot can only read or execute resources unless yous explicitly grant write access:

A cracking enquiry nearly write restricted tokens tin can exist found in Forshaw's postal service

Conclusions

I hope that this very short post can be useful for us who must secure our Windows Sytems (Offensive sec is just a joke for me 🙂 )

In the adjacent post I will show y'all how to remove impersonation privileges in other critical services… stay tuned

UPDATE

Following Forshaw's recent blog post and hint and his post on "Sharing a Logon Session a Little Too Much" I can confirm that you gain back your privileges with the "loopback pipe trick". This is possible because you will go the original token stored in LSASS without stripped privileges by the Service Command Manager. So the simply solution to prevent this is to acquaintance a Write restricted Token to your service.

That's all 😉