Is Your PAM Solution Enough to Block Credential Theft?

I was recently working with a large US-based company that suffered from repeated breaches to their corporate network. After we deployed the Preempt Platform and started monitoring all traffic, we quickly found several hacked privileged accounts that attackers were using. The interesting thing was that all privileged accounts were protected with password vaults and their passwords were rotated every 24 hours. In that particular case, the attackers compromised a web gateway that some admins logged into each day using a plaintext password. Using this weakness, attackers easily defeated the Privileged Access Management (PAM) solution, they simply had to harvest the password each day and do whatever they wanted with it.

Many companies think their PAM solution is a silver bullet that can mitigate all credential theft attempts by itself. The truth is that in many respects, PAM solutions are similar to smart cards (which I blogged about in the past): they offer an important element that helps strengthen authentication, but unfortunately don’t comprehensively address all the core issues involved with fighting account compromise. In this blog, I’ll highlight some of these points and aim to convince you why these solutions have built in logical flaws and require additional protection.


PAM is only for “privileged” accounts

Perhaps the main point to note about PAM solutions is that usually not all accounts are protected by the PAM solution. As the name suggests, the main focus is on protecting a small group of privileged accounts. That may work for several desktop admins and special accounts that perform wire transfers, but typically in major enterprises,most accounts are not protected by password vaults. The accounts that are unprotected often can be traditionally classified as “privileged,” but overlooked for various reasons. Reasons behind these accounts going under the radar include stealthy admins (users with special delegated permissions) that admins are not aware of, and service accounts (e.g. 3rd party applications), which most admins will not bother to integrate with PAM since it requires complex integration. Furthermore, there are accounts that are not traditionally considered “privileged” by IT definitions, but are critical to the organization business-wise. Such accounts might include the social media manager, a financial controller in charge of wire transfers that if hacked would cause severe damage. Heck, even your CEO’s password is often not protected by a PAM solution…


PAM is a static solution

A PAM solution can be both restrictive technologically (applications often have to integrate directly with PAM solution) and cumbersome (requires specific access methods such as jump servers). Now that we understand that the scope needs to be bigger than just “privileged” accounts and should protect various other users, it is probably not the right fit. A solution that protects all user accounts needs to be much easier to use and cause less friction. As Gartner reports in their Market Guide for Privileged Access Management: “PAM deployments without proper scoping, roadmap development and stakeholder support struggle to achieve the desired business value and risk reduction, due to a mixture of political and cultural issues.”

This highlights the static nature of the PAM solution. Essentially, each login request is protected (password is vaulted, two factor can be enforced) when the reality is that in many cases you’ll want an adaptive solution – for lower privileged users you might want to only trigger stronger authentication requests when user activity is anomalous, and when users go by their usual activity, you’ll want to make you security tool “invisible” to prevent unnecessary friction for your business. On the other hand, for privileged accounts, enforcing stronger authentication for login alone might not be enough. To truly protect the privileged credentials from being misused by malware, it is necessary to enforce additional MFA requests if an anomalous action by the privileged account is performed.

Attackers can bypass PAM

When using a PAM solution, the password is automatically generated and rotated at regular time intervals. Furthermore, an additional policy can enforce that all privileged accesses will be done via a jump server. While these seem like powerful protection mechanisms, malicious actors have adapted and found ways to bypass these protections. I’ll try to break down piece by piece where the weak points are in such solutions:

Jump Servers

In the real world, some applications require direct use of a privileged account’s password and the rotating password is copied from the PAM solution, thus skipping the jump server entirely. If the password is copied, then the account attack surface is considerably bigger, and as with our example above, once attackers compromise a system in which a password is used, it is practically game over.

Rotating Passwords

Even if a password is rotated every 12 hours, it only takes one time for a password to be compromised for an attacker to do serious damage. Once a privileged password is compromised, the attacker can deploy back doors on critical servers, dump domain secrets, add new users (that can often have stealthy privileges) or in some cases even complete their malicious mission (e.g. installing ransomware on all machines in the network).

Protocol Attacks

Following the previous example, it’s not just the plaintext password that can be stolen. Every network is only as strong as its weakest link. Even if a PAM solution protects the plaintext password, all protocol vulnerabilities and attacks can still be used. If the attacker is able to compromise a machine that an admin has logged on to, they could harvest Kerberos tickets and password hashes and launch pass-the-hash or pass-the-ticket attacks. Interestingly, a Kerberos ticket will remain valid even after password is rotated, this means that after a domain is compromised, a Kerberos golden ticket can be used to bypass PAM completely. The underlying authentication protocols might also allow an attack. NTLM is a great example: when using NTLM, the authentication session can be often be relayed using NTLM relay techniques.

No detection/visibility  

Finally, I’m a firm believer in a “defense in depth” approach. This means that you should not blindly trust any protection system and always assume each perimeter is going to be breached. Following that principle, it is evident that a comprehensive strategy to defend against account compromise should include general visibility into all user activities, threat hunting capabilities and an anomaly detection engine to look for “unknown unknowns” and detect stealthy attacks that were able to bypass all other security measures.

*** This is a Security Bloggers Network syndicated blog from Preempt Blog authored by Yaron Zinar. Read the original post at: