I'm looking at a application running on IIS which requires service account(s) to run some services/software, however the service account requires LOCAL ADMIN access which is against policy.

Are there any alternatives? Is this a sign of an application that is badly made that it requires service accounts to need local admin access?

  • Sounds really sketchy to me... I would reach out to the developers to find out what they recommend for hardening and not deploy it into production. I would also ask that they show any pentesting results for their application. That sounds like a critical failure waiting to happen. – Steve Kline Jun 25 '18 at 17:32

That sounds super sketchy man. The policy is right... Sounds like an app I'd like to deploy and test my pentesting skills on. :)

I'd go with the policy and push on the devs to provide a standard hardening guide to the minimum rights possible to avoid vulnerabilities to your host and ultimately your entire network if the host is compromised. Weak vulnerabilities in a web application could allow a hacker to generate shell to run commands on your host, gain a foothold in your network, and begin attacks within your network...

I would probably test it in a dev lab server... keep tweaking and hardening with basic user rights. Then keep hardening until the application breaks. Once hardened, you should only use a non-domain admin account on the box. Most importantly with a non-domain admin, it should be a very complex, non-dictionary word, and at least 14-character password that's only used for that box. Avoid credential recycling.

Then when you login as the admin after all domain creds have been cleared and the box has been hardened, if the box admin account is obtained thru privilege escalation attacks, it will reduce the rapidly growing threat surface of the attack. The attacker has to start backover at ground-0 on the pivot because the credentials for domain admins will not be resident on the system from tools like mimikatz or fgdump. Then they have to enumerate and start over from scratch, giving your security operations team time to respond. It's not a lot of time, but enough to detect the service accounts abnormal behaviors.

If you're just looking for a basic set of instructions on how to start basic hardening work in Windows. You may want to take a deep-dive and experiment with an Isolated Dev box for Windows until you have your hardening down. Just setup IIS with a basic "Web shell" and lock it down until your web shell is almost useless. You can google "ASP Webshell" and it will give you some code to test in IIS. Then remove the webshell from the system entirely! <- very important for obvious reasons!

Keep tuning your hardening until you're ready to make your production setup run and make sure you take lots of notes. I'm sure there are guides out there and MSDN has a lot of resources to assist.

Basic overview of what you'll be doing... this is mostly ran off of memory of essential basics, please check out hardening guides from CIS for more fine-grained policy recommendations.

  1. Create a functional account
  2. Remove User rights to that account
  3. Preferably on-board that account into a password solution like CyberArk
  4. Create a security group for "Run as a Service" rights
  5. Open SecPol and remove all rights to Run as a Service except your new security group
  6. Add that functional account to that security group
  7. Restrict that security group from a lot of basic user functions other than minimum requirements
  8. Configure IIS and the Application Pool services to run on these restricted accounts and never trust the app to run with "network services" because an attacker will immediately gain "System" level privileges if an attack is successful.
  9. Ensure that this system is not trusted for any AD Privileges.
  10. Harden the file system from that service account and only allow it access to the minimum amount of data required to operate. (.Net Libraries as needed, IIS logging, etc.)
  • Silly question - is it possible to find out what specific rights the LOCAL ADMIN has that a normal account does not on IIS? Would admins have access and rights to do everything and anything on the box? – deltzy Jun 25 '18 at 21:27
  • 1
    @deltzy you can look at the local secpol, security groups, and yes admins have full rights. – Steve Kline Jun 26 '18 at 21:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.