IIS Application - service account permissions

Question

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?

Answer 1

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.

Answer 2

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.