The ISC shares some of the security risks associated with corporate service account and the need for best practices to protect resources so that these accounts can’t be used interactively to log in. 

ISC link – Corporate Service Account protection

Windows Service Accounts have been one of those enterprise “neccessary evils” – things that you have to have, but nobody ever talks about or considers to be a problem.  All too often, these service accounts are in the Domain Admins group, with passwords like “Service123”, “S3rvic3” or something equally lame.  And all too often, application vendors that use these services insist on just such a configuration.

Why is using actual service accounts a bad thing?  Aside from the fact that the passwords are generally set to never change, the passwords are stored in the registry, in a text format that is easily captured to arrive at the actual password.  Needless to say, this generally allows an attacker to fly under the radar and move laterally to other hosts – pillaging your AD Domain at will.

Fixing the Problem –  Microsoft has come up with a decent way to mitigate this issue.  Where possible, have your services run as “LocalSystem“, “NT AUTHORITY\LocalService” or “NT AUTHORITY\NetworkService” … These settings are run levels for services only (they can’t be used for interactive login), with differing security permissions, but NO PASSWORD.  What this means is that the service has the authority that it needs, but there isn’t a password to crack, and the account can’t be used for a normal interactive login session.