Can’t See or Secure Them Until It’s Too Late

Service account challenges

A difficult question to answer: “How many service accounts do you have in your environment?” The harder question is, “Do you know what these accounts are doing?” And perhaps the hardest part is, “If one of your service accounts is compromised and used to access your resources, can you detect and stop it in real time?”

Most identity and security teams will answer negatively, One of the actions attackers are taking today after their first endpoint is compromised is to seek out unmonitored service accounts. And, in most cases, it can only be discovered when it’s too late, after workstations and servers have been encrypted by ransomware, or sensitive data stolen, and used to spread throughout the environment. It is even less surprising that the

This article reveals why service accounts have become one of the most dangerous weaknesses in Active Directory environments, explains how the power of this weakness facilitates ransomware attacks, and finally, Silverfort’s Federated Identity Protection Understand how the platform enables your organization. To overcome previously unsolvable security challenges.

Service Account: A user account that is not associated with a real person and is used for machine-to-machine communication

user account It is one of the key building blocks in enterprise environments. Intuitively, users associate her account with a real person. However, some user accounts are not associated with humans. These accounts are created for machine-to-machine communication, automation of repetitive tasks, and other assignments intended to happen in the background without human intervention. They are commonly known as “service accounts” and are identical in all respects to other “person-associated” user accounts, except for their separation from a real person.

These service accounts are created in two main ways. First, when IT personnel decide that certain sanitation, monitoring, or other tasks are better done in an automated way rather than manually. The second is the process of installing enterprise software on-premises. In that case, several service accounts are created as directed by the specific software (during the installation process itself) to be responsible for scanning, distributing updates, and similar maintenance assignments.

Service Account Security Challenges: Invisible, Highly Privileged, and Extremely Hard to Protect

Understand why service accounts are an unattended attack surface.

  • lack of visibility: As strange as it sounds, there is no utility within the identity infrastructure that can automatically exclude service accounts from the entire pool of users. Also, there is no automated documented process for creating service accounts.
  • high access: The service account is created for machine-to-machine communication, so of course the service account must have the necessary privileges to access all these machines. In other words, service accounts are administrative users, no different than IT administrators.
  • No PAM protection: A common practice is to put administrator accounts in the vault of a PAM solution and protect them by rotating passwords. However, this approach doesn’t apply to service accounts because the service account password is hard-coded into the script that runs the task. Therefore, password rotation invalidates the password in the script, prevents the service account from accessing the target resource, and subsequently suspends all processes that depend on the service account’s tasks.

Four Steps to Comprehensive Service Account Security

Every organization has countless service accounts. These accounts can be high-risk assets, and if left unchecked, threats can spread undetected throughout your network. Check out this eBook to discover 4 simple steps to keep your service accounts secure.

How Attackers Leverage Off-the-shelf Service Account Achievements for Lateral Movement and Ransomware Spread

Let’s assume a ransomware attacker successfully compromises an endpoint (workstation or server is the same). Of course, this is only the first step. The next step is to start scanning the environment to discover the compromised user her account, which allows the adversary to move laterally through the environment and plant the ransomware payload on as many machines as possible. That’s it.

But which account should you choose? Attacker needs an account with sufficient privileges To access other servers or workstations.but it should also be An account that can be used under the radar without attracting unnecessary attention.

this is the reason Service accounts are prime compromise targets. The attacker knows that this account is likely unseen by anyone. know This account must exist. Years ago, the service she created might have been created by an administrator who retired without bothering to delete her account.

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

The diagram below shows an example of an attack. This is one of many attacks we have analyzed in recent years. The attackers leveraged a compromised Exchange Server service account for the first part of their lateral movement, followed by further compromise of administrator credentials.

Service account challenges

See details for each stage below.

  1. Initial access: Exploit Proxyshell Vulnerability to Compromise Exchange Server
  2. Compromised Credentials: Acquiring Domain User Credentials
  3. Lateral movement 1: Access additional machines using service accounts
  4. Credential Compromise 2: Get admin user credentials
  5. Lateral movement 2: Utilizing admin credentials for mass propagation to multiple machines
  6. Malware execution: Plant and run ransomware on your machine

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

A few months ago, a high-profile attack on Uber involved a security breach and abuse of service accounts. In that case, it was a service account with access to PAM. The attackers found a script containing service account credentials on a shared network drive and used it to extract passwords to multiple resources from PAM’s vault.

Service account challenges

See details for each stage below.

  1. Initial access: MFA bombing for access via VPN.
  2. credential compromise 1: Steal service account credentials from a shared folder.
  3. credential compromise 2: Steal secrets from PAM’s secret server.
  4. Lateral movement: use secrets to access various sensitive resources

Auto-discovery, monitoring and protection of Silverfort service accounts

Silverfort’s unified identity protection platform is the first solution to fully automate the security lifecycle of service accounts with near zero effort on your part.

Discover all service accounts and map their activities

Because Silverfort is natively integrated with Active Directory, it analyzes all incoming authentications and access attempts for all user accounts, and accounts contain predictable and repetitive behavior that distinguishes between service accounts and standard users. You can easily detect if Based on this analysis, Silverfort produces output for all service accounts in your environment. Additionally, this detection provides not only a list of accounts, but also account permissions, sources and destinations, activity levels, and other behavioral characteristics.

Ongoing risk analysis to disclose whether service accounts show signs of compromise

Silverfort identifies the basic behavior of all service accounts and continuously monitors their activity. For service accounts, the most obvious sign of a security breach is a deviation from fixed behavior, so whenever a deviation occurs (e.g. accessing a new workstation or server, a sudden increase in activity volume, etc.) Silverfort’s engine increases your account’s risk score.

Active protection with auto-created policies that activate with a single click

Silverfort automates the creation of access policies for each service account it discovers. This policy applies when service accounts deviate from normal behavior (as described above) or when detected identity threats (Pass-the-Hash, Kerberos, Pass-the-Ticket, etc.) increase the risk level. becomes active. A policy can trigger either an alert or an actual block of service account access, per user configuration. All the user needs to do is click the Enable Policy button.

Looking for a way to secure your service account? Book a call with one of our experts to find out how Silverfort can help.

Did you find this article interesting?Please follow us twitter and LinkedIn to read more exclusive content we post.



Source link

Leave a Reply

Your email address will not be published. Required fields are marked *