Service accounts, by design, are created to perform specific tasks for services running on endpoints. Depending on the service and how the service account is configured, service accounts can have a range of different privilege levels. Malicious actors understand that service accounts typically have higher privileges than normal user accounts, and often target these accounts and their associated privileges in order to move laterally within an environment.  However, many organizations overlook the risk associated with these accounts during configuration and implementation, leaving them vulnerable to attack.

With this in mind, does your organization have any controls or practices set in place to mitigate the risk of service accounts misuse? If your organization is looking for additional controls or practices, here’s a few practices you can implement to help combat the attack vector that service accounts present.

1. Configure your service accounts to deny interactive logons

When a service account is configured to allow interactive logins like Logon Types 2, 10, and 11, this presents a way for a person to exploit privileges that administrators might have not originally given to that person. Since service accounts are designed for services or applications to log into in order to interact with the operating system, interactive logins of these accounts prevent an accurate audit trail since there is typically no way to clearly identify who performed the interactive login through logs.

Service accounts should only be used by applications or services – not users. Due to the accounts’ intended function, interactive logons should not be permitted by default. The Group Policy Object (GPO) policies ‘Deny log on locally’ and ‘Deny log on through Remote Desktop Services’ will help your organization in preventing a service account from logging in interactively.

Configure service accounts with the following GPO policies: ‘Deny Logon locally’ (above) and ‘Deny logon through Remote Desktop Services’ (below) to help prevent service accounts from logging on interactively.

We advise creating two groups, one that is set with ‘Deny log on locally’ and ‘Deny log on through Remote Desktop Services’ policies and the other with ‘Allow log on locally’ and ‘Allow log on through Remote Desktop Services’ policies. You can name the groups something like ‘Service Account – AllowInter’ and ‘Service Account – DenyInter’. This will help address a situation in which a member of your organization needs to leverage the service account locally.  If this becomes true, all an administrator needs to do is remove the service account from the group ‘Service Account – DenyInter’ and add it to the group ‘Service Account – AllowInter’.

Give the groups descriptive names like ‘Service Account – AllowInter’ (pictured above) and ‘Service Account – DenyInter’ to help address a situation in which a member of your organization needs to leverage the service account locally.

To further harden the group ‘Service Account – AllowInter’, your organization can assign the group GPO policies ‘Log On To’ and ‘Logon Hours’.  The ‘Log On To’ GPO will allow your team to specify certain domain joined machines that the service account can only log on to and ‘Logon Hours’ will allow your team to a specify the time frame from which logins will be permitted for the service account.

To strengthen the group ‘Service Account – AllowInter’, assign the group GPO policies ‘Log On To’ (above) and ‘Logon Hours’ (below) so your team can specify certain domain-joined machines and time frames permitted for the service account.

2. Practice the principle of least privilege with service accounts

The principle of least privilege is a dated best practice that still holds its weight in a continually evolving information technology landscape.  The root of the principle is to give users, programs, or services the minimal amount of privileges necessary to perform their intended function. With the assistance of Active Directory, we can help achieve the principle of least privilege with our service accounts.

Service accounts and privileged groups

Vendor permission requirements often state their product needs explicit and sensitive permissions, when in reality they do not.  For example, why would a SQL service need Domain Admin rights? It doesn’t. Working closely with the vendor to uncover the absolute specific rights the service needs to function will help your organization in assigning a service account permissions that are consistent with its function. If the service does not require permissions defined by any built-in privileged groups, your organization should create a new privileged security group for the corresponding service account following the principle of least privilege. In the event that the service requires permissions defined by a built-in privileged group, it’s advised to replicate the permissions and create a new privileged security group for only the corresponding service account. This will help combat nonrepudiation since each member of a built-in privileged group will have access to the credentials of the service account.

Securing sensitive objects

Understanding what a sensitive object is in your environment will help your organization in applying DACL (Discretionary Access Control List) to prevent the account from accessing the object. Like an implicit deny firewall ACL rule, DACL in Active Directory provides the ability to deny permissions to objects in your environment. Implementing DACL on your sensitive files and folders will help combat misuse of the account in the event the account is compromised. One of the first steps an attacker will conduct with a compromised account is to understand what they can do and access with the account. Denying access to sensitive objects for your service accounts will make it difficult for an attacker to complete their actions on objective with the account.

3. Implement a change management process for service accounts.

At its core, change management processes are used to track, schedule, communicate, and define scope of a change in your environment. After the initial creation and deployment of a service account, there should be minimal changes made to the account. In the event a change is needed, or a new service account needs to be created, your organization should have a formal change management processes in place.

Implementing a formal approval and change management process for your service accounts will help ensure the change does not go unnoticed. Traditionally, these changes may fall under your organization’s Standard Change process rather than a Normal Change process; but if applicable, we recommend following a Normal Change process.

Using a Normal Change process rather than a Standard Change process will ensure that the change is reviewed by a change-advisory board.  The process could look something like this: In order to change an attribute of the service account or create a new service account, you should draft a formal proposal that defines the reason for the change or addition, the impact it will have, the personnel conducing the change, and the scope of change.  Then, you can present this to the person or persons your organization has granted permission to approve or deny the change.

By using a defined Normal Change process change for service accounts, your organization will have a better control in place to ensure the accounts are not configured or changed to a state that will make them more vulnerable than they already are. This implementation will also provide your organization the visibility needed to establish an accurate normal baseline for the accounts, which in return will assist in auditing and conducting periodic privilege audits of the accounts in the environment.  Any deviations in a service accounts baseline that does not match the proposal created for the change or creation could be a sign the account is being misused.

How ReliaQuest GreyMatter accelerates detecting, investigating, and hunting for service account misuse

ReliaQuest GreyMatter, our SaaS security platform, offers unparalleled visibility by integrating and normalizing data from disparate technologies including SIEM, EDR, multi-cloud and point tools, on demand, so you always have a unified view to immediately and comprehensively detect and respond to threats from across your environment. With this visibility, organizations not only find themselves with clear and relevant data to quickly and thoroughly investigate incidents, it also provides the ability to transition from reactive to proactive security programs. Through GreyMatter’s threat hunting capabilities, our customers can create custom Hunts or leverage Hunt packages developed by our R&D team to identify Service Account misuse. GreyMatter Detect also gives our customers access to a content library of over 600 technology agnostic alerts, 30+ of which are specifically focused around detecting Service Account misuse.