My company is looking to install a 3rd party application on our infrastructure and this application will be installed on an IIS Server with a connection to a SQL server. They require an AD service account with the following permissions, some of which look sketchy to me. What would the risk be of giving an account such permissions, given if a malicious actor compromised the account they could do the following:

  1. Full read write permissions to specific application folders - not an issue.
  2. Read and logon to SQL Server - not an issue.
  3. Must be able to start services - ending services would be a worrying, but any risks associated with starting services?
  4. Starting .exe files - again need to investigate why, but I would assume starting .exe files would potentially allow a malicious user to execute malicious .exe files if the service account was comprimised?
  5. Run .bat files - any thoughts?

2 Answers 2


The only one of those that is even potentially a major risk is starting services, because services run as their own user instead of inheriting the security token of the process that started them. If the service account can launch more-privileged services, especially if any of them take parameters and/or otherwise consume data that the service account can tamper with, then that is a definite risk.

Everything else is just stuff that an attacker (who manages to compromise the application), or the application itself (if it is malicious) could effectively already do. If a malicious actor already controls code running on your machine, there's not really any need to spawn a new process with the same security token (which is what happens when you launch an EXE or BAT file), although it would make post-exploitation easier. Starting services means running code with different permissions, though, and that's potentially enough to break out of a low-privilege service account and take over the whole, ahem, "SYSTEM".

Obviously you shouldn't give your sandboxes any privileges they don't need - for example, Chrome's render processes cannot launch child processes, even though their permissions are so limited it would barely matter - but as long as the access restrictions on the service account are tight enough it's no big deal to be able to launch EXEs (including cmd.exe, which is all that "Run .bat files" actually does) and if the permissions of the service account are too broad, an attacker who gets code execution within the application won't need any other processes.

  • Great answer, would you happen to know of any examples of such services could be maliciously used to break out of a low priv service account?
    – deltzy
    Commented Jun 15, 2019 at 8:43
  • 1
    Not off the top of my head. The three questions you'd ask for each candidate service are: (1) What account does this service run as, and what permissions does that account have that your IIS service lacks? (2) What permissions does this service grant your IIS service? In addition to the SCM regulating what accounts can interact with services in general, each service controls what actions each account can take on it. (3) In what ways could the service be influenced by your IIS service (take parameters, read files, accept network traffic, etc.) and could the service be abused maliciously?
    – CBHacking
    Commented Jun 17, 2019 at 23:53
  • 1
    Highly-privileged services (it is common to run services as the fully-privileged SYSTEM account, for example) are a risk. Highly-accessible services can be a risk (for example, any service that grants a non-admin the SERVICE_CHANGE_CONFIG right can be used to take over the system); see docs.microsoft.com/en-us/windows/desktop/services/… for more info. Note that there is no such thing as "can start services" permission, it's always per-service (though an account needs to be able to connect to the SCM to do anything with services).
    – CBHacking
    Commented Jun 18, 2019 at 0:09

Those all look fairly normal for a server to run with self-monitoring and self-recovery scripts. Granted, the use of .bat files is a bit old fashioned, but not uncommon.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .