Windows Server services security
Windows Server services security. Interactive user account
Sometimes if you’re installing some application, additional service has been also created. Unfortunately it can’t work on standard permissions and you decided to give them local administrator account privileges. It works but it’s a really bad thing. It’s first step to have major problem with Windows Server services security. Interactive user account is not designed to be used for services.
Understanding the problem
Running the service on user account is always a bad idea. Why? Because password of account which is used by service is stored in registry. It’s mean that possibility to get them is easy. After password will be compromised can be used for bad things.
How it works?
Let’s see the example. We have a service called 10itreporter. On every server start creating report with every service which is created in that OS. Cool and simple. Unfortunately it works on domain administrator account: 10it\administrator. It’s easy to get password from registry for that account. We need for that two things: SAPD tool and PSexec from PStools.
- Open cmd and go to the SAPD tool location,
- Type (10itreproter is a service name),
SAPD 10itreporter
The correct name be checked with Powershell by typing
get-service *10it*
Get-service Powershell command to see the name of service Normally display name is different that name which you should use in cmd to call service.
- You will receive information that user password for that service can’t be find in registry.
Windows Server services security. Interactive user account Unfortunately is not a true. It’s only mean that you don’t have sufficient rights to see registry hive where password is stored. To solve that go to pstools folder and start PSexec by typing:
psexec -s -i -d cmd
New cmd window will be shown. Type
whoami
and check if you have system rights already.
PSexec tool which allow start cmd as system - As system go back to SAPD folder and type ocne again:
SAPD 10itreporter
Password with dots should be visible.
User account used for service is visible
Conclusion
It’s too easy to get user account password which is using for service. Too easy to grant them interactive account permissions. If there is really no way to start service on dedicated accounts, then create separated one which will be not able to login to any machine and give them minimal rights only to run service needed.
More information
SAPD tool – LINK
PSexec tools – LINK
Password theft of Windows DOMAIN administrator account – LINK
Password hack of Windows LOCAL administrator account – LINK
