Unmasking the Real Threat in the LastPass Saga

Why BYOD policies aren't the answer to your security woes

Now that everyone's heads have cooled down regarding the LastPass breach reports, I'd like to circle back to the incident and explore a few threads that were promptly ignored during the outrage that ensued. I specifically want to focus on the second incident.

A quick recap for those not familiar with the incident:

• The attacker compromised media software on a DevOps engineer's home computer.

• They installed a keylogger to sniff the master password, which gave them access to the Corporate Vault.

• This engineer was one of the four people to have access to this vault.

• This vault contained hard-coded AWS IAM access keys to download and decrypt backups on S3 (databases with customer data and more).

Following this disclosure—kudos to LastPass, by the way—almost every pundit jumped to the same conclusion: "Damn it, we should forbid personal devices from accessing corporate assets", "Companies need a strong Bring Your Own Device (BYOD) policy"…

BYOD this, BYOD that... as if that same scenario could not be replayed on a corporate laptop...

What's stopping the attacker? An antivirus? An EDR?

Ha—give me a break. We don't even have to go far to refute this theory. LastPass's previous incident actually involved a corporate laptop. You know what the attacker did to that EDR? They disabled it and moved on.

Whether it's a corporate managed device or a personal one, the attacker had no trouble getting what they wanted from the company. Therefore, this story is clearly not about BYOD facilitating a breach.

This is the story of compromised admin access. If companies miss this insight, they will draw the wrong conclusion and spend valuable time and resources on the wrong set of problems...

In almost any company, compromised admin access is arguably the most difficult scenario to mitigate. Period. The attacker is running code on the admin's machine. Forget about WebAuthn 2FA, password vaults, keychains, and other protections—the attacker can sniff all those out. They carry out their attacks from the admin's machine, proxying all their packets through the victim's IP address and avoiding classic network detection alerts. For all intents and purposes, they are the admins.

Let's dissect this threat and explore potential mitigations.

Fewer people, fewer problems

Every company has a group of people who hold the keys to the kingdom: the security team with admin access to the Single Sign-on (SSO) Platform, DevOps/SRE managing the AWS platform, corporate IT administering Active Directory, and developers with admin access to databases, among others.

However, when a company reaches a critical mass, the risk of someone misusing their extensive privileges becomes too significant to ignore. As an attacker, I can target any of the numerous developers within the company and gain unrestricted access to databases containing customer data. Phishing and water holing attacks are a numbers game—the larger the target, the higher my chances of success.

To address this issue, the first intuitive security measure often implemented involves reducing the number of people with admin access. This may include removing developer access to databases and limiting marketing's direct access to the warehouse, among other measures.

This direct access is replaced by more mature tooling, which allows a predefined subset of commands and enforces necessary checks and controls. For instance, the SRE team might use Infrastructure as Code (IaC) tools like Terraform and Ansible to avoid leveraging their admin privileges when updating critical components. Developers can deploy their changes using a GitOps approach (e.g., ArgoCD and FluxDB) instead of connecting directly to the server.

Despite these measures, there remains a core group of 4 or 5 individuals who must retain full root powers over specific components because, in the end, someone needs the ability to override the system in case of an incident. These select admins typically perform migrations, set up databases, investigate infrastructure issues, and create tooling for the rest of the team.

Slicing the scope

We have significantly reduced what was once a large attack surface (hundreds of people) to a small group of 4 or 5 individuals, through which an attacker must now navigate to obtain their prize.

However, if the prize is substantial enough (millions of dollars, passwords for millions of users, etc.), an attacker will bloody slither through this narrow gap like a snake slipping through a crevice. They may employ spear phishing, deep reconnaissance, tailored exploits, and more. It's safe to assume that given enough time and resources, the attacker will eventually breach their target. They possess the advantage of the first strike and the luxury of time.

To limit the impact of such an intrusion, one powerful approach is to divide the admin scope into multiple distinct scopes. There is no single pair of keys to the kingdom; no one person has admin access to everything. Backups are managed by two individuals in team A, while storage is overseen by another group in team B, and the SSO falls under yet another team, and so forth.

But what happens if the 2 or 3 people managing critical databases get hacked? Isn't that what ultimately occurred with LastPass?

Indeed, this measure does not entirely prevent an attacker from inflicting serious damage. If they are fortunate enough to compromise the right admin account with access to databases, they may not need much else. But if they breach the corporate IT, they would be limited to directory data (names, emails, etc.) and would face difficulty accessing the platform. Even if they manage to do so, they are likely to generate enough signals to be detected.

This approach significantly restricts the impact of an attack to specific components and their immediate neighbors. However, it assumes a sufficient number of personnel, which is not always the case for every company. Often, an entire infrastructure is managed by a small team of just 4-5 people.

Hunting down SPOF

At a certain scale, slicing scope and people is no longer enough. The potential impact of a single compromise becomes so significant that even a minuscule likelihood cannot adequately contain it. At this point, the company needs to transition to a multi-tier admin model.

In this model, no single admin can decrypt databases, access the AWS root account, download data from a critical S3 bucket, or access the all-powerful shared vault. Instead, two, three, or even four people may be required, depending on the desired level of security.

While it might initially seem like a productivity-crippling proposition, most admin actions are not needed on a daily basis. For example, people do not delete, restore, or export databases every day, nor do they access the backup vault every hour. These infrequent yet powerful events can be subject to multi-tier validation without significantly impacting productivity.

Surprisingly, almost no SaaS tools offer this capability, necessitating custom in-house tooling (e.g., an approval system using Lambda state machines, forbidding these actions with AWS SCPs that only another admin can override) or clever use of encryption algorithms (separating keys and ciphertext in different vaults, requiring m out of n keys). However, a company that has matured to the point of needing this level of protection can likely afford it.

Consider the LastPass attack scenario. Ideally, even if an attacker gains access to an admin's vault, they should be unable to use the backup IAM access keys, as those credentials can only be decrypted with a key held by another admin. While the compromised admin account remains powerful—capable of spawning machines or changing network configurations—it cannot dump the entire database or delete backups. Such actions would require another admin's approval.

Detection, detection, detection

Now, These measures effectively reduce the attack surface and create substantial obstacles for potential attackers. However, a clever group of adversaries might still find a way to manipulate enough admins to achieve their goals through bribery, extortion, targeted malware, and more. This is where our last line of defense comes into play: detection!

Specifically, we need detection capable of identifying unusual behavior and rare events that should not occur.

For example, during a given period, an admin may have permission—under the two-tier model—to debug calls to AWS Secrets Manager, the vault used by applications to store their passwords. A typical maintenance operation might involve reading one secret and altering another. It certainly wouldn't involve reading 20 secret values per hour, which is more in line with an attacker searching for an admin password.

Generalizing this principle, we can map out normal admin activity and alert on any deviations. An admin may have temporary access to an S3 bucket containing critical data, but they would likely only download one or two files for debugging purposes, not empty the entire bucket. This type of false positive might occur once a year, but that's an acceptable rate in most situations.

Conducting this exercise to identify privilege abuse can significantly reduce the impact of admin compromise. As soon as an attacker, emboldened by their newly acquired access, deviates from the normal usage patterns, we can detect their actions and promptly revoke access.

The other form of detection involves identifying events that should never happen. A break-glass account should never be used, a service account should not operate outside specific IP address ranges, and no one should download data from a cold storage backup folder. All of these events should trigger alerts, prompting swift responses.

While these events might occasionally occur—perhaps once or twice a year—the security team should be notified beforehand and can quickly clear any false positives.

To recap,

Protecting against a compromised admin is not an easy task and involves a meticulous exercise of studying the impact of every compromised asset and finding creative ways of reducing that impact without cutting productivity and flexibility. The equation is hard to balance. It often requires custom tooling and a mature tech environment that strives for quality. It’s not as simple as “forbid personal devices and patch your systems…”