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^[1]
with one of our experts to learn how Silverfort can assist.