Most systems administrators will be familiar with the concept of a “service account” in a Microsoft Windows network infrastructure. What many do not realise is that this concept is a purely human one. Neither Active Directory, nor any individual workstations or servers by default distinguish between a user account which relates to an individually identifiable person and a user account which is purely intended to perform some automated, routine, process.
There are ways of specifically marking “service accounts” as distinct entities. These involve the use of specific logon permissions, temporal restrictions, and the “setspn” command, which is discussed in the Microsoft TechNet article at the following URL. In the vast majority of network infrastructures upon which Dionach have performed penetration testing, these processes have not taken place, and so, for all practical purposes, there is no difference between a user account and a “service account”.
https://social.technet.microsoft.com/wiki/contents/articles/717.service-…
The configuration of user accounts intended for use in managing automated tasks introduces some interesting security flaws, particularly from the point of view of penetration testing. Some of these are discussed below.
In many cases, “service accounts” are highly privileged, being members of either a local administrators group on a given set of systems, or in extreme cases, being members of “Domain Admins” or equivalent groups within Active Directory. This means that, should the service process be compromised in any way, so too will any systems over which the account has privileged control. An extremely common example of this is an account to support automated server backup processes.
Often, “service accounts” will be configured to launch a system service locally. This means that the “service account” credentials will be stored locally on a given host. Common examples for this include processes such as local database engines such as SQL Server or Oracle. These credentials can be stored in local configuration files, or cached in a protected area of the local registry, the LSA Secrets repository. These credentials are not normally visible to interactive users, however, they can be accessed by the builtin SYSTEM account. All members of the local Administrators security group can escalate their privileges to SYSTEM in order to view these credentials, and there are a number of freely available tools which can be used to do this, one such being Oxid Cain (www.oxid.it), through the “ABLE” module.
Due to the nature of the way that “service accounts” are used, they generally have passwords which do not expire – as this would necessitate reconfiguring the service credentials on any number of hosts on which the “service accounts” run. This means that the credentials, and bear in mind the potentially highly privileged nature of these accounts, are potentially known to a large group of people, many of whom may have left the organisation for various reasons. They also, if used for a sufficient period of time, may not be subject to the same restrictions as other user accounts, and so frequently will be configured with relatively weak passwords such as “s3rv1c3” or words or phrases related in some way to their function, “v1ru5” being a popular example. Even where weak passwords are not used for such accounts, the passwords will generally be written down or stored somewhere for ease of reference; a common place being in the “description” field of the Active Directory account object.
While detailed guidance on configuring “service accounts” is not possible in this blog post, as it will depend upon the specific service, and the needs of your local infrastructure, the following guidelines will help to ensure that these accounts are secured as far as is practical.
1. Identify the exact privileges needed (or as near as is practical) for the “service account” to fulfil its intended role. For example, backup services rarely need full “Administrator” access, and can generally perform adequately with “Backup Operator” role membership, or equivalent.
2. Determine the systems to which the “service account” will need access, and the nature of this access. For example, an antivirus definition update will not typically require an interactive user interface, and so should not be configured to use interactive logon. Such restrictions can be configured through Active Directory user account properties.
3. Identify whether the service will require local access or network access, or both. If only one, disable access through the other.
4. Determine when the service will need access to the necessary hosts. For example, backup routines are typically run out of hours, and so access to hosts during business hours is not needed for any account used to perform this function. Such temporal restrictions can be set through user account properties in Active Directory.
5. Configure a strong, long, highly complex password for the “service account”, and ensure that, if it needs to be stored for retrieval, such retrieval cannot be performed without specific authorisation. A popular mechanism to enforce this is storage of a “service account” password in a fireproof safe at an off-site location, however, any solution should be appropriate for the business needs, and be risk-assessed.
6. Determine a regular process of review of the “service account” use, including privileges specified and password rotation. In most cases, changing the password of a “service account” every thirty days etc. is simply not practical, however, changing it every year may well be.
7. Ensure that the “service account” is readily identifiable as such; avoiding the common practice of using the built-in “Administrator” account. Using a uniquely identifiable account will mean that identifying suspicious activity by this account will be more straightforward, and also help to prevent privilege creep. Use of a shared, non-unique, account may also impact on compliance with standards such as PCI DSS and ISO 27001.
8. Institute an appropriate monitoring and alerting system for the use of the “service account”. For example, if the account should only be used to backup 6 servers between the hours of midnight and 5 am, then access to a 7th server at 2pm should immediately raise suspicion. A task tied to the “Domain Logon” event in Active Directory may be one way to identify this abnormal behaviour.
9. Finally, specify a unique Service Principal Name, as discussed in the Microsoft TechNet article above, to ensure that the “service account” can be uniquely controlled through the Kerberos sub-system, which will help to limit the potential for the “service account” to be used outside of its intended function.
Please note that the above list is not a prescriptive, or exhaustive, list of steps to follow when configuring unattended services in an Active Directory subsystems, but should hopefully help with fine-tuning existing procedures, and lead to an overall continual improvement in information security.