Attackers Don't Hack, They Log In.

Originally published by Sonrai Security.

Written by Eric Kedrosky.

Lessons from the LastPass Breach

Below we’ll detail the latest LastPass incident, discuss the implications of this attack, and finally recommend how organizations can protect their critical cloud assets.

What Happened

The threat actor exploited a vulnerability in third-party consumer software running on an employee’s machine, bypassed existing controls, and eventually accessed production and database cloud-based backup storage, including LastPass customer data. The attacker(s) are unknown, have yet to make any demands, and LastPass sees no sign of activity since October of 2022.

How Did This Happen

The attack leveraged vulnerable third-party software and targeted one-of-four senior DevOps engineers. The threat actor exploited the vulnerability to deliver malware, installed a keylogger, gained access to LastPass and acquired decryption keys the engineer had access to. The decryption keys allowed access to a broader set of LastPass customer and encrypted vault data stored in AWS S3 buckets. The data accessed from those backups contained configuration data, API secrets, third-party integration secrets, customer metadata, and backups of all LastPass customer vault data.

The Cloud Attack Path

As we know, LastPass experienced an initial breach, this is where the attacker was able to execute recon, and know what S3 buckets and associated data they wanted, and who could get them access. Next, in this second incident, is when the third-party software vulnerability was leveraged against the Senior Engineer. This software was present on the employee’s personal device, on-prem.

One element to the story we’d like to call-out is the nature of entry. Today’s cloud security market is hyper-focused on vulnerability management, and platform security, CWPP & CSPM respectively. However, in this case, neither of those solutions could have prevented this incident. Why? Because this wasn’t a case of a cloud misconfiguration nor a cloud vulnerability. Many CWPP solutions market their agentless scanning capabilities, but with this being a consumer product on the employee’s own device, enterprise cloud-based scanning would not have been relevant. Once the employee was compromised, the attacker had exactly what they needed. That identity held the keys to the kingdom with a relatively simple path forward: List:Object to find all S3 buckets, and Get:Object command to retrieve their contents. They had the names of the S3 buckets from their previous recon.

This story rings true to one of our core beliefs: it’s not about whether attackers can get in, but instead about what they can do and access once they’re in. “What can they do?” is almost entirely dependent on identity and privilege, which is why we steadfastly claim identity and access to be the most critical element of enterprise cloud security.

Permissions, Access, and Lateral Movement

In this incident, there was little to no confirmed lateral movement needed as the DevOps engineer was senior enough they held highly privileged access to high-impact data. However, typically, this is where an attacker must jump from identity to identity and permission to permission to find what they want. Mitigating this leeway is the only way to reduce your attack surface and prevent asset access.

If reducing your attack surface is your first line of defense, your next layer is continuous monitoring and anomaly detection for when malicious activity slips through the cracks.

Through continuous monitoring of access logs, suspicious behavior can be detected. It would have been unusual for the DevOps engineers’ identity to be accessing let alone reading and exfiltrating the backup data, from an unusual geo-location, ideally alerting LastPass cloud security teams.

How Can I Protect My Critical Assets?

The LastPass incident can serve as an example to learn from and as a reminder to lock down your cloud. If you’re ready to tackle this challenge: your strategy must take a three-prong approach: 1. Restrict Movement 2. Restrict Access and 3. Monitor for Deviation.

Step 1. Restrict Movement.

Organizations must start by gaining a full picture of all the identities in their cloud – both human and machine. With a full identity inventory, and one that is continuously updated to account for departures and additions, then comes understanding the permissions tied to all these identities. This is revealing their Effective Permissions – the true end-to-end scope of an identities abilities, no matter how many degrees of separation away they gain this permission (think: trust relationships, managed policies, nested groups, etc.) This insight is critical, yet hard to achieve. It is the only way to reveal troublesome permissions and access including privilege escalation capabilities and toxic combinations creating risky and unintended access. Then you are able to strip excessive permissions and remediate toxic ones. We recommend a Least Privilege Policy, meaning identities hold only the permissions they absolutely need in order to accomplish their job. This is your locked in and secure baseline that you will use to monitor against.

Step 2. Restrict Access.

We believe securing your cloud from the inside out is a priority, meaning starting with your data and moving outwards. To begin, organizations must know where all their data is, not where it’s supposed to be or where they think it is. This is gaining a data inventory. Once all your data is located, you must classify it. This means understanding what your data is and how it’s important to your business, as not all data is created equal. Data tagging is a common practice, often labeling with a ‘name tag’ and a ‘value tag’ e.g. DataClassification:Confidential or DataType:CustomerPII. This step is critical in prioritizing your most sensitive assets. Once you have a program in place allowing you to understand and detect security risks, the next step is actually protecting your data. This means stripping away access to your most sensitive assets. Data locating and classification enables your teams to work towards achieving Least Access. Least Access enforces data protection from the inside out, meaning, starting with the data, and working outwards to determine who and what can access it. Then stripping that access to only those that need it. This is your secure baseline.

Step 3. Monitor for Deviations.

Once you have visibility into your data, and enforce Least Access, you must continuously monitor data activity to detect anomalous access. Periodic or sporadic auditing is not sufficient in the cloud when machine identities are accessing your data for seconds at a time, at multiple times a day. When monitoring, you’re looking for unusual behavior that deviates from both a Least Privilege and Least Access baseline, this can include: an identity using a permission not typically associated with it, or accessing an asset from an unusual location. All these signs should be flagged as they can potentially alert security teams to attacker activity.

So what’s learned?

Every major breach stirs up conversation. The conversation we’ve been having at Sonrai is that this breach was complicated. There’s no one, catchall, easy solution to prevent this incident, and looking back in retrospect to architect the perfect one is always easier said than done. While an organization can’t always control how an attacker enters their environment, one thing they can control is what the attacker can execute and access once they’re in. We empathize with the employees of LastPass, and are always looking for ways to enable and help the security community.