
Can’t See or Secure It Until It’s Too Late
Here’s a tough question to answer: ‘How many service accounts do you have in your environment?’. What’s more difficult is: ‘Do you know what these accounts do?’. And the most difficult one is probably: ‘If one of your service accounts is compromised and used to access resources, will you be able to detect and stop it in real time?’.
Since most identity and security teams would give a negative answer, it’s no surprise one of the immediate actions attackers take today after the initial endpoint is compromised is to hunt down unattended service accounts. And it’s not even surprising that in many cases, they will manage to find one and exploit it to spread throughout the environment, only to be discovered when it is too late – after workstations and servers have been encrypted by ransomware or sensitive data has been stolen.
In this article, we break down why service accounts are one of the most dangerous vulnerabilities in Active Directory environments, explain how the strengths of these vulnerabilities fuel ransomware attacks, and finally explore how Silverfort’s unified identity protection platform enables organizations to address what has hitherto been a unsolvable security challenges.
Service Account: A User Account That Is Not Associated With Any Real Person And Is Used For Machine-To-Machine Communication
User account is one of the main building blocks in the corporate environment. Intuitively, we associate user accounts with actual people. However, there are also user accounts that are not associated with any human. These accounts are created for machine-to-machine communication, automation of repetitive tasks, and other tasks that are intended to be performed in the background without human intervention. They are commonly known as ‘service accounts’ and apart from their separation from real people, are identical in all aspects to other ‘person-related’ user accounts.
These service accounts are created in two main ways. The first is IT personnel determining that certain cleaning, monitoring, or any other tasks would be better done automatically, rather than manually. The second, is installing on-site enterprise software. In this case, multiple service accounts are created per specific software instructions – during the installation itself – and assigned to scan, distribute updates, and similar maintenance tasks.
Service Account Security Challenges: Invisible, Highly Privileged, And Extremely Hard to Protect
Let’s understand what makes a service account an unattended attack surface:
- Lack of visibility: Odd as it may sound, there is no utility in the identity infrastructure that can automatically filter out service accounts from the entire user pool. There is also no automated documentation process indicating the creation of a service account.
- High access rights: Since service accounts are created for machine-to-machine communication, it goes without saying that they must have the necessary privileges to access all these machines, meaning they are administrative users, not unlike any IT admin.
- No PAM protection: A common practice is to secure the administrative account by placing it in a PAM solution vault and rotating the password. However, this approach cannot be applied to service accounts because their passwords are hardcoded in scripts that perform their tasks. Thus, any password rotation will invalidate the password in the script, prevent the service account from accessing its target resources, and subsequently terminate any process that depends on the service account task.
4 Steps To Comprehensive Service Account Security
There are many service accounts in any organization. These accounts can be high-risk assets which, if left unchecked, can allow threats to spread across networks undetected. Check out this eBook to find 4 simple steps to help keep your service account secure.
How Attackers Leverage Low-Dependent Service Account Pieces For Lateral Movement And Spread Of Ransomware
Let’s assume that the ransomware actor has managed to compromise the endpoint (workstation or server alike for that matter). This, of course, is only the first step. The next step is to begin scanning the environment to find user accounts to compromise which will allow an adversary to move laterally within the environment and plant the ransomware payload on as many machines as possible.
But which account to choose? The enemy requires a fairly special account to access servers and other workstations. But it also has to be an account that can be used under the radar without attracting unwanted attention.
This is why service account is the best compromise target. The attacker knows that there is a good chance, that no one sees this account, or even better – nobody even know that this account exists. It was probably created years ago by an admin who had left the company without bothering to delete the service account he created.
Service Account Attack Example #1: Ransomware Attack Pattern Using Compromised Microsoft Exchange Server Service Accounts
The diagram below shows an example of an attack – one of many we have analyzed in recent years – where an adversary has used a compromised Exchange Server service account for the first part of its lateral movement, followed by an additional compromise of admin credentials.

See details for each stage below:
- Early Access: Compromising Exchange Server exploiting the Proxyshell vulnerability
- Credential Compromise: Get the credentials for the domain user
- Lateral Movement 1: Make use of service accounts to access additional machines
- Credential Compromise 2: Obtain admin user credentials
- Lateral Movement 2: Leverages admin credentials for mass deployment across multiple machines
- Malware Execution: Plant and run the ransomware on the machine
Service Account Attack Example #2: Lateral Movement in an Uber Hybrid Environment
The infamous attack on Uber that occurred a few months ago included the use of compromise and significant use of service accounts. In this case, it’s the service account that has access to the PAM. The attacker finds scripts with service account credentials on shared network drives and uses them to extract passwords to various resources from the PAM vault.

See details for each stage below:
- Early Access: Bombing MFA to gain access via VPN.
- Credential Compromise 1: Steal service account credentials from shared folders.
- Credential Compromise 2: Stealing secrets from the PAM Secret Server.
- Move Sideways: Use secrets to access sensitive resources
Silverfort Automatic Discovery, Monitoring, and Protection For Service Accounts
Silverfort’s unified identity protection platform is the first solution to fully automate the service account security lifecycle with near-zero effort on the user’s side:
Discovery of all service accounts and mapping of their activity
Silverfort’s native integration with Active Directory allows it to analyze every incoming authentication and attempt to access all user accounts, and easily detect if an account displays the predictable and repetitive behavior that differentiates service accounts from standard users. Based on this analysis, Silverfort generates output of all service accounts in the environment. In addition, this discovery goes beyond a list of accounts to also show account privileges, source and destination, activity level, and other behavioral features.
Ongoing risk analysis to reveal if the service account shows any indication of compromise
Silverfort identifies the basic behavior of each service account and continuously monitors its activity. For service accounts, the most obvious indication of compromise is a deviation from its established behavior, so any time an deviation occurs – such as accessing a new workstation or server, or a sudden increase in activity volume – the Silverfort engine increases the account’s risk score.
Active protection with automatically generated policies, activated in one click
Silverfort automates the creation of access policies for every service account it finds. This policy is activated whenever a service account deviates from its normal behavior (as previously described) or when its risk level increases due to detected identity threats (Pass-the-Hash, Kerberoasting, Pass-the-Ticket, etc.). Such policies may trigger warnings or actual blocking of service account access, according to user configuration. The only interaction required from the user’s side is to click on the activate policy button.
Looking for a way to secure your service account? Schedule a call with one of our experts to learn how Silverfort can help.