Tracking Down Rogue or Forgotten Service Accounts in Active Directory

How to Spot Service Accounts in Active Directory

Service accounts often blend in with regular users, making them tricky to find. They can be broken down into two categories:

1. Known Service Accounts: The service accounts that have been intentionally created, maintained in an appropriate way, and documented in a thorough manner. The ownership and intended use or purpose of the accounts is documented in a CMDB (Configuration Management Database) or similar documentation. Password management is performed through mechanisms such as LAPS, or manually using such means as auditing for passwords that are rotated or expired based upon regulatory compliance obligations.
2. Unknown/ Rogue Service Accounts: The unknown service accounts exist in Active Directory and there is a significant security risk to the account because there is no proper management or documentation regarding use. Service accounts may display generic names that appear to be random or generic for the purpose of identifying the type of account it is. Service accounts may also become orphaned when the accounts have not been used for a period of time, usually greater than ninety days. Generally, no administrator or system could exist to ideally claim ownership of the account so they remain unowned.

6 Key Steps to Find Service Accounts in AD

Not sure where to start? We’ll walk through six practical steps you can use to uncover service accounts in your environment.

1. Documentation Review: The first step in the process is to review any inventory lists or documents that may contain information on the service accounts. These may include names, descriptions, and related scripts or apps.
2. Utilize Active Directory Tools: You can use the built-in Active Directory search tools to help identify service accounts. The Active Directory Users and Computers (ADUC) console is an example of one of these built-in tools. You can find accounts that have some attributes that are used for service accounts and search the description field for “ServiceAccount.” You would do this by starting with the ADUC console, browsing to your domain and using the search functions.
3. Identify Special Account Flags: Service accounts also have special account flags that can help you identify their purpose. For service accounts, these will include flags as “DONT_EXPIRE_PASSWORD” and “PASSWORD_NOT_REQUIRED.” With special flags applied, you can use LDAP queries or Power Shell command lines to identify accounts with these flags.
4. Review Group Membership: Service Accounts are members of specific security groups to give them enough permissions to perform their job. Review the membership of groups known to have higher privileges such as “Domain Admins,” “Enterprise Admins,” and others.
5. Evaluate Application Dependencies: The application or services that require service accounts to operate should be evaluated. To understand the service accounts in relation to applications, reach out to the application’s owner or system administrator.
6. Regular Audit Event Logs: All event logs for service accounts should be regularly reviewed on domain controllers and other critical servers. To determine service accounts that have been used, look for relevant activity such as password changes, or logon events. To maintain the security of your Active Directory environment, regularly review and update their permissions, enforce a strong password policy, and monitor their activities.

Proven Techniques to Detect Hidden Service Accounts

Below are key techniques for identifying both known and unknown service accounts in Active Directory.

1. Search by SPNs ( Service Principal Name): Searching for accounts with registered Service Principal Names (SPNs) is one of the best methods for locating service accounts. Kerberos authentication uses SPNs, which are distinct identifiers, to link a service instance to a service logon account. This method provides a powerful indicator of service utilisation because Service Accounts need SPNs. It is helpful to run the following command to identify accounts used for Kerberos authentication.
   Get-ADUser -Filter { ServicePrincipalName -like "*" } -Properties ServicePrincipalName
2. Filter by ‘Password Never Expires’ or ‘Cannot Change Password’: Another method is to look for user accounts that have the “Password Never Expires” or “Cannot Change” characteristics set. These settings are frequently used on service accounts to stop unscheduled service interruptions brought on by invalid login credentials or illegal password changes. Use the following Powershell query to identify these accounts, which aids in identifying accounts set up to function similarly to service accounts.
   Get-ADUser -Filter * -Properties PasswordNeverExpires | Where-Object { $_.PasswordNeverExpires -eq $true }
3. Check for Old or Stale Accounts: Service Accounts that are no longer in use may remain in the directory and provide a possible point of attack. The detection of orphaned accounts once-used but now abandoned can be helped by identifying old or stale accounts, particularly those that haven’t signed in for more than ninety days. Permissions are still held by older accounts, which an attacker could use to move laterally throughout the network if they were compromised. The Powershell command listed below assists in identifying these accounts in order to reduce risks and clean up Active Directory.
   Search-ADAccount -AccountInactive -UsersOnly -TimeSpan 90.00:00:00
4. Looking for Accounts Running as Service: Users’ endpoints or servers’ services are directly linked to accounts. By requesting Windows services from the local system, this method displays the account that each service is set up to operate under. It is possible to detect undocumented or misused service accounts by tracking which accounts are using shared resources or carrying out scheduled actions using third-party tools like Lepide or native tools like file server audit logs. To list all the services and the accounts they are operating under, use the PowerShell command.
   Use PowerShell: Get-WmiObject -Class Win32_Service | select Name, StartName

Note: It is crucial to keep in mind that even administrators with the best of intentions frequently neglect to record each service account that is established, particularly when implementing system rollouts, urgent updates, or legacy migrations.

How to Map Permissions Access for Service Accounts

It’s not enough to find service accounts, you also need to know what they can access. We’ll discuss how to map their permissions and scope of control.

1. Review NTFS and File Share Access: Determine which file system locations service accounts have access to first by reviewing NTFS and file share access. This includes key directories, shared folders, and legacy file servers. Check which users or service accounts have read, write, or full control privileges on particular resources by using PowerShell’s Get-ACL cmdlet.
   Get-Acl "C:\Path\To\Folder" | Format-List
2. Check Group Memberships: Permissions can be passed down to Service Accounts via group membership. The PowerShell command that follows can be used to determine which group a service account is a part of. This would be helpful in understanding what level of access the account actually has , even if it appears limited at first glance.
   Get-ADUser svc_account -Properties MemberOf
3. Audit Privileged Groups: Whether any service accounts belong to high-privilege groups like Domain Admins, Enterprise Admins, Account Operators, or Schema Admins must be routinely audited. The fact that these groups contain service accounts is a serious red flag. These accounts should be looked at right away because they could be used to corrupt an entire domain.
   Get-ADGroupMember "Domain Admins"

Note: It is easier to determine which service accounts require restriction or removal when regular access evaluations are used in conjunction with Lepide’s risk rating engine. In terms of current Active Directory security hygiene, this is not only a best practice but also a must.

How to Detect Rogue or Abandoned AD Accounts

Forgotten or rogue service accounts are a serious security gap. Here’s how you can detect them before attackers do.

1. Signals that indicate an Account is Abandoned or Rogue

The following signals suggest that an account may be abandoned or rogue:

1. No Logon Activity: Accounts that haven’t been used in 90 days or more may be orphaned, especially if they were linked to temporary projects, retired systems, or employees who have left the organization.
2. Active but Tied to Defunct Applications: Some service accounts have continued to function long after the decommissioning of the applications they were utilised for. No one took the time to clean up these accounts, thus they might still be empty.
3. Logins at Unusual Hours: When an account is seen to be logged in outside of regular business hours, it may indicate abuse or breach. Service Accounts should exhibit regular consistent usage; deviations from these patterns are cause for concern and should be looked into.
4. Assigned to High-Privilege Groups without Reason: If high-level access is granted to an account with no apparent operational reason, it can have been created maliciously or, worse, incorrectly configured. There should be a business necessity and a recognised owner for each privileged account.

2. Audit Alerting: Catch Risks Before Attackers Do

Finding accounts once isn’t enough; you need ongoing monitoring. Let’s show you how audits and alerts help detect suspicious account activity in real time.
Finding accounts once isn’t enough; you need ongoing monitoring. Let’s show you how audits and alerts help detect suspicious account activity in real time.

Examine the Logoff and Logon Events : Understanding how and when accounts are utilised requires tracking logon/logoff behaviour. To be more precise: Event ID 4624: Successful login , Logoff Event ID 4634 – Frequent auditing of these occurrences can assist in identifying dormant accounts and spotting odd access patterns.

Monitor Account Creation and Changes: Alerts should be triggered by account changes, particularly if they include: New accounts are being made, alterations to the group membership, Changes to permissions or a reset password. These can be seen in occasions like: Account creation and deactivation (Event ID 4720–4726), Group membership changes (Event ID 4732–4738).

Utilize Alerting and Monitoring Tools: Both native Windows utilities and third-party solutions, such as Lepide, which offers historical audits and real-time alerts, are available: Using Group Policy to Configure Advanced Audit Policies, Security log viewer (Event Viewer), Scripts in PowerShell for routine health checks. These technologies can assist with investigations, warning generation, and automated detection of suspect account behaviour.

Best Practices to Secure Service Accounts in AD

Securing Service Accounts in Active Directory (AD) is important for maintaining organizational security. Below will cover proven best practices for reducing their risk.

Group Policy Recommendations

• Implement Secure Password Policies: Service account passwords should be complicated, long (passphrases or at least 16 characters), unique, and changed frequently. For added security, use a policy that interfaces with password managers and prevents hacked credentials.
• Deny Logon via GPO: Use GPO Service to prevent interactive login Accounts should not be used to log in using the GUI or RDP because this invites credential theft and subpar audits. For these accounts, you can make a security group and enforce “Deny log on locally” and “Deny log on through Remote Desktop Services” with a GPO to prevent interactive access.
• Regular Password Rotation: Automating password rotation reduces the possibility of static or stale credentials, particularly when employing MSAs or gMSAs.
• Disable GPO Inheritance: Disabling GPO inheritance reduces unintentional exposure to wider settings and helps guarantee that only intended rules apply to Organisational Units (OUs) that contain service accounts.
• Tiering Model: In the conventional ESAE/ Red Forest model, administrative duties are divided into many levels:
• Enterprise/Admin accounts and domain controllers make up Tier 0.
  • Enterprise/Admin accounts and domain controllers make up Tier 0.
  • Server admins are Tier 1.
  • Workstation admins are Tier 2.

This tiering helps limit the mobility of possible attackers. Put service accounts at the right tiers and limit mobility. Lateral escalation is limited when service accounts stay within their functional tier and avoid moving across tiers. With the help of RAMP, Microsoft is moving from Red Forest to EAM. As a default recommendation, ESAE has been formally retired. As part of their Rapid Modernisation Plan (RAMP), Microsoft is now pushing the Enterprise Access Model (EAM), which is more scalable, compatible with hybrid settings, and in line with Zero-Trust.

Least Privilege Best Practices

• Allocate Necessary Permissions: Give service accounts just the necessary permissions. Keep in mind that often minimum rights are sufficient, even if vendors promote them.
• Managed Service Accounts (MSAs / gMSAs): The purpose of these account categories is to use non-interactive services. They facilitate automatic password rotation, remove the possibility of GUI login, and make SPN administration easier, particularly for gMSAs spanning several hosts.
• Exclude from Domain Admins: High-level groups like Domain Admins shouldn’t have service accounts unless there is an urgent operational requirement.

Automate Service Account Security with Lepide

The Lepide Data Security Platform, offers behavior-based threat detection, automated response capabilities and live auditing. Lepide Auditor captures comprehensive audit trails of AD changes – “who-what-when-where” that would help to monitor the implementation of service accounts and changes made to them. In addition to protecting service accounts, the Lepide solution can assist with managing inactive user accounts, exploring full logs and reporting on service account activity, eliminating unnecessary access rights, as well as monitoring the login times of service accounts.

Lepide Auditor enables flexible reporting and dashboards to monitor inactive accounts, management of lockout accounts, management of privileged groups, and more. It also contains user friendly dashboards whose functionality may sometimes be AI-enabled via Lepide IQ showing at-a-glance risk indicators accounts that are inactive, excessive permission usage, unusual login behaviour, and permission sprawl, etc.

The Lepide Auditor systematically scans and inventory accounts in Active Directory where they can identify service accounts, stale accounts, or accounts that have excessive rights. The Lepide Trust feature can help determine effective rights spanning your directory, as well as identifying service accounts that have excessive rights. Both the Lepide Trust and the Lepide Protect function can trigger automated responses such as disabling suspicious accounts, or revoking access that is over and above administrative rights or membership in privileged groups.

See how Lepide secures your service accounts with real-time discovery, audit, alerts, and visualization all in one platform. Schedule a demo or download a free trial today to keep your accounts secure, visible, and compliant.