The Service Accounts Challenge: Can’t See or Secure Them Until It’s Too Late

Here’s a hard question to answer: ‘How many service accounts do you have in your environment?’. A harder one is: ‘Do you know what these accounts are doing?’. And the hardest is probably: ‘If any of your service account was compromised and used to access resources would you be able to detect and stop that in real-time?’.

Since most identity and security teams would provide a negative reply, it’s no wonder that one of the immediate actions today’s attackers are doing following an initial endpoint compromised is hunting down unwatched service accounts. And it’s even less of a wonder that in most cases, they would succeed in finding one and leveraging it to spread within the entire environment, getting noticed only when it’s too late – after workstations and server got encrypted by ransomware or sensitive data was stolen.

In this article, we unfold the reasons that have caused service accounts to become one of the most dangerous weaknesses in an Active Directory environment, explain how this weakness power fuels ransomware attacks, and finally, get to know how Silverfort’s unified identity protection platform enables organizations to overcome what was until now an insolvable security challenge.

Service Accounts: User Accounts That Are Not Associated With Any Real Person And Are Used For Machine-To-Machine Communication

User accounts are one of the key building blocks in the enterprise environment. Intuitively, we associate user accounts with actual people. However, there are also user accounts that are not associated with any human being. These accounts are created for machine-to-machine communication, automation of repetitive tasks, and other assignments that are meant to take place in the background without human intervention. They are generally known as ‘service accounts’ and apart from their dissociation from a real person, are identical in all aspects to the other, ‘people-associated’ user accounts.

These service accounts are created in two main ways. The first, is an IT personnel that determines that a certain hygiene, monitoring, or any other task would be better done in an automated manner, rather than manual manner. The second, is in the course of installing an enterprise software on-prem. In that case, some service accounts are created per the instruction of the specific software – in the course of the installation itself – and are tasked with scanning, distributing updates and similar maintenance assignments.

Service Account Security Challenges: Invisible, Highly Privileged, And Extremely Hard To Protect

Let’s understand what makes service accounts an unattended attack surface:

• Lack of visibility: As strange as it may sound, there is no utility within the identity infrastructure that can automatically filter out service accounts from the overall pool of users. Nor is there any automated documentation process in place that indicates a service account’s creation.
• High access privileges: Since service accounts are created for machine-to-machine communication, it goes without saying that they must possess the required privileges to access all these machines, meaning that they are an administrative user, no different than any IT admin.
• No PAM protection: The common practice is to secure administrative accounts by placing them in a PAM solution’s vault and rotate their passwords. However, this approach can’t be applied to service accounts because their passwords are hardcoded in the scripts that run their tasks. As such, any password rotation would invalidate the password in the scripts, preventing the service account from accessing its target resource, and subsequently break any process that relies on the service accounts’ task.

How Attackers Leverage The Low-Hanging Fruit Of Service Accounts For Lateral Movement And Ransomware Spread

Let’s assume that a ransomware actor has successfully compromised an endpoint (workstation or server are the same for that matter). This, of course, is just the first step. The next step is to start scanning the environment to discover user accounts to compromise that would enable the adversary to laterally move within the environment and plant the ransomware payload in as many machines as possible.

But what account to choose? The adversary needs an account that’s privileged enough to access other servers and workstations. But it should also be an account that can be used under the radar without drawing unwanted attention.

This is why service accounts are the best compromise target. Attackers know that there’s a good chance, that no one is looking on this account, or even better – that nobody even knows that this account exists. It might have been created years ago by an admin that has since left the company without bothering to delete the service accounts he created.

Service Account Attack Example #1: Ransomware Attack Pattern Using Compromised Microsoft Exchange Server’s Service Account

The diagram below shows a sample attack – one of many we’ve analyzed in the recent year – in which the adversary has utilized a compromised Exchange Server’s service account for the first part its lateral movement, followed by an additional compromise of an admin credentials.

See the details of each stage below:

1. Initial Access: Compromising the Exchange Server exploiting the Proxyshell vulnerability
2. Credential Compromise: Obtaining credentials for domain user
3. Lateral Movement 1: Utilizing the service accounts to access additional machines
4. Credential Compromise 2: Obtaining credentials of admin user
5. Lateral Movement 2: Utilizing the admin credentials for mass propagation across multiple machines
6. Malware Execution: Plant and execute ransomware on the machines

Service Account Attack Example #2: Lateral Movement in Uber’s Hybrid Environment

The famous attack on Uber that took place a few months ago incorporated a significant use of compromise and use of service account. In that case, it was a service account that has access to the PAM in place. The attackers found the script with the service account credentials in a shared network drive and utilized it to extract passwords to multiple resources from the PAM’s vault.

See the details of each stage below:

1. Initial Access: MFA bombing to gain access via VPN.
2. Credential Compromise 1: Steal service account credentials from a shared folder.
3. Credential Compromise 2: Steal secrets from the PAM’s Secret Server.
4. Lateral Movement: Use secrets to access variety of sensitive resources

Silverfort Automated Discovery, Monitoring And Protection For Service Accounts

Silverfort’s unified identity protection platform is the first solution that fully automates the security lifecycle of service account with near-zero effort from the user’s side:

Discovery of all service accounts and mapping of their activity

Silverfort’s native integration with Active Directory enables it to analyze every incoming authentication and access attempt of all user accounts, and easily detect if an account features the predictable and repetitive behavior that differentiates service accounts from standard users. Based on this analysis, Silverfort generates an output of all the service accounts within the environment. Moreover, this discovery goes beyond just a list of accounts to also show the account’s privileges, it’s sources and destinations, activity level and other behavioral features.

Continuous risk analysis to disclose if a service account shows indications of compromise

Silverfort identifies the baseline behavior of every service account and continuously monitors its activity. For a service account, the clearest indication of compromise is a deviation from its fixed behavior, so whenever a deviation occurs – such as accessing a new workstation or server, or suddenly increasing the activity volume – Silverfort’s engine will elevate the account’s risk score.

Active protection with auto-created policies, activated in a single click

Silverfort automates the creation of an access policy for each of the service accounts it discovers. This policy is activated whenever the service account deviates from its normal behavior (as previously explained) or when its risk level increased due to detected identity threats (Pass-the-Hash, Kerberoasting, Pass-the-Ticket etc.). The policy can trigger either an alert or actual blocking of the service account access, per the user’s configuration. The only interaction required from the user side is click the policy activation button.

Looking for a way to secure your service accounts? Schedule a call with one of our experts to learn how Silverfort can assist.

Source: thehackernews.com/