Skip to content
 

Protecting endpoints with agent-based privilege elevation

  

You’re facing potential adversaries on multiple fronts, each with different attack techniques and objectives. Should you rely on local intelligence on the ground to interpret and respond to their actions, or do you want all decisions to go through central command?

That’s the choice you face when you build a strategy for protecting endpoints from identity-based attacks. The challenge is especially difficult when you’re trying to secure a multi-cloud environment with a mix of Windows, Linux, and Unix systems.

In this blog, you’ll learn the differences between agentless and agent-based approaches to Privileged Access Management (PAM) by seeing how they operate when an organization is under attack. You’ll understand how agents empower servers to self-protect with granular visibility and intelligent, policy-based controls.

For context, let’s look at how PAM solutions protect your endpoints by limiting privileged access.

How to enforce least privilege with elevation controls

To align with the Principle of Least Privilege, human and machine identities should only be granted minimum permissions to access your IT systems and data. That way, even if a cyberattacker or malicious insider steals credentials and breaches your defenses, their movements are limited, and damage is contained. PAM solutions help you discover excessive and unused privileges and eliminate them so you can meet least privilege requirements.

Under these conditions, what happens when someone needs to perform an administrative function on a server?

As part of a comprehensive PAM strategy, Privileged Elevation and Delegation Management (PEDM) provides the mechanism to elevate privileges when necessary. Policy-based privilege elevation controls operate Just-in-Time so that an employee, third party, or machine identity can access exactly what they need, when they need it, subject to approval. Once the requirement is over, the PAM solution automatically revokes the elevated privileges.

There are two methodologies for implementing these types of privilege elevation controls on endpoints—agentless and agent-based.

To illustrate the difference, let’s return to our 'adversaries on multiple fronts' analogy.

Think of an agentless approach like a team that must wait for remote headquarters to receive word of a threat and then issue instructions. Unfortunately, those at headquarters may not have the full context to understand the nuances of a situation.

In contrast, in an agent-based model, those in the field have the most information, so they are empowered to use independent judgment to defend themselves. They understand the rules of engagement through policy-based controls, but they can execute those controls immediately as the situation warrants.

The agent-based approach recognizes the value of local intelligence.

For example, while an agentless solution may monitor and record privileged sessions on a server, it’s only looking from the outside in, and visibility is limited. In comparison, an agent on a box can interrogate a server’s operating system. It can interrogate the shell and process layer to unambiguously identify what system commands and applications are executing from the command line, or obfuscated in a shell or alias command. 

These capabilities stem from architectural differences between agentless and agent-based approaches to PAM.

Agentless vs. Agent-based Diagram

Agentless privilege elevation controls

With agentless PAM, the security architecture is configured so that the only way for a user to reach an endpoint is through a central gateway that must first log into the target and create a privileged account for the requestor.

Once a user accesses an endpoint, native operating system controls govern what they can do, with few options for permission levels (“read,” “write,” or “execute”). Typically, a system owner has standing permissions for all three.

In a Windows environment, the gateway would typically add a user to a local administrator group in Active Directory to set admin-level permissions. In a Unix/Linux environment, however, systems aren’t tied to Active Directory, which makes privilege management more painful and Just-in-Time, policy-based privilege elevation virtually impossible.

Agent-based privilege elevation controls

Agent-based PAM solutions add layers of security through software installed on endpoints such as servers and workstations across your IT environment. Instead of relying solely on a faraway point of control, agent-based PAM solutions empower endpoints with local security that allows them to protect themselves. This framework for centralized control and distributed implementation aligns with best practice architectural models like NIST Zero Trust architecture.

In this model, agents enroll endpoints in your PAM stack and confirm a trusted relationship, obtaining a machine identity in the process. This enables mutual authentication, so when the agent reaches back to the PAM management plane to obtain policies its unique identity and access privileges can be confirmed.

With this approach, a user can operate with standard permissions in accordance with least privilege best practices until they require privilege elevation. Then, the agent can elevate privileges based on fine-grained policies that define exactly what the user can and can’t do on a specific endpoint. This approach elevates privileges only for the application or command being run, not for the login session. Once the command or application completes, the elevated privileges are gone. 

Since the agent on the host is trusted, we are content that access and permissions are sanctioned, based on legitimate policies. This is critical. There's no concern that an unknown and untrusted external entity is logging in with an admin account and creating another admin account. It might be a PAM gateway, but it might also be an adversary with a compromised credential or a tool like .Metasploit. 

Agent-based PAM can operate with equal effectiveness whether the server it’s installed on is Windows, Unix, or Linux. Agents can join Unix/Linux systems to Active Directory and make them part of an AD domain so you can centralize PAM policies and manage everything through a unified interface.

Plus, with agent-based PAM, security controls operate even when a system is offline. This capability is particularly helpful for user workstations.

How do privilege elevation controls protect endpoints?

Next, let’s dig into examples of endpoint attack scenarios that illustrate the differences between agent-based and agentless security mechanisms.

Attack scenario 1: Nefarious command with an alias

Imagine a stealthy attacker has found their way inside your network using a stolen privileged account. They create an alias for a string of commands to execute on a server that contains highly sensitive data. They name the command “mail”.

Without a PAM agent on your endpoint:
Only the name of the command—“mail”—is visible to the gateway. It seems innocuous so no defensive action is taken. Session monitoring through a proxy visually records what is shown on the screen, but “mail” slips under the radar.

With a PAM agent on your endpoint:
Not only can the agent on the box see the name of the command, but it can also look under the hood to understand what the command is designed to do. It turns out that “mail” is an alias that expands to multiple commands that create and install a back-door SSH key on the system. The adversary intends to use SSH instead of the compromised ID and password going forward. Security controls immediately flag the threat, revoke privileges for the identity, and alert the security team to remediate and prevent the impending attack.

Logs show all the detail of privileged identities and events on the server. That’s because session recording not only captures the command, but also the metadata of any actions executed. It writes these events to a log, feeds your SIEM, and correlates with additional information to enrich detection.

Attack scenario 2: Backdoors and lateral movements

Now, imagine that an insider with administrative access creates backdoor login accounts so they can gain direct access to a server whenever they want. Let’s say the same set of credentials unlocks access to multiple servers.

Without a PAM agent on your endpoint:
Because the user bypasses the gateway, centralized controls can’t do their job to authenticate or authorize access. The server can’t tell if a user is friend or foe because legitimate, highly privileged credentials are presented. In fact, the user—or anyone who steals those credentials—can move laterally from one server to another without detection.

With a PAM agent on your endpoint:
Because of the least privilege model, the user wouldn’t have the necessary permissions to create a backdoor account in the first place. Instead of broad access rights, even server administrators would have elevated permissions only when necessary, and then only for a limited period.

In addition, each server in your environment can self-protect by validating that the connection attempt is coming from a trusted source, not malware or a compromised account, for example, by requiring MFA on login. Server controls are independent of each other to prevent lateral movements from server to server.

What about the management effort?

Despite the obvious benefits of an agent-based solution for PAM and privileged elevation, some organizations worry about extra deployment effort and maintenance overhead.

This concern is easily addressed. You can eliminate any unnecessary burdens and ensure fast time to value with PAM solutions that centralize management of agents, including automatic deployment and updates at scale.

On the other hand, cons of an agent-less approach can’t be overcome. They’re technical restrictions built into the design that deliver less value for your identity security program.  

In summary, while agentless solutions offer a simplified approach to privileged access management, you get what you pay for. Agent-based PAM provides more robust and comprehensive endpoint protection. An agent-based trust relationship with endpoints enables granular access control, centralized PAM policy management, and deeper visibility into privileged activities for intelligent detection and rapid response.

See how it works

You can see how agent-based PAM works in this interactive demonstration.

Least Privilege Discovery Tool

See which IT systems and users have higher privileges than they need

Our Least Privilege Discovery Tool makes it easy.