LastPass 2022: How a Developer's Home Computer Became the Attack Surface

In December 2022, LastPass disclosed a breach that had unfolded in two distinct phases between August and November of that year. The disclosure — which grew more detailed and more alarming across several subsequent updates — revealed that an attacker had compromised a senior DevOps engineer’s personal home computer, extracted cloud storage credentials stored on that machine, and used those credentials to access a shared cloud environment containing decrypted backup files. From that environment, the attacker copied encrypted customer vault data belonging to approximately 25 million LastPass users.

The technical root cause was not a vulnerability in LastPass’s core infrastructure. It was the intersection of a personal device, persistent privileged credentials, and the absence of controls that would have detected or limited either.

Phase 1: The developer’s home machine

In August 2022, the attacker compromised the personal laptop of a senior DevOps engineer who had legitimate access to LastPass’s shared cloud storage environment. The initial access vector was a remote code execution vulnerability in a third-party media player application installed on the laptop — a consumer software package entirely outside LastPass’s security perimeter, running on hardware LastPass neither owned nor managed.

Through that foothold, the attacker deployed a keylogger. They used it to capture the engineer’s master password for their personal LastPass vault, which the engineer used to store corporate credentials including, critically, access keys for the shared cloud storage environment. Those keys were long-lived — not session credentials tied to a role assumption, but persistent AWS access keys stored as a convenience for the engineer’s regular operational work.

Phase 2: Cloud storage access, four months later

With the cloud storage credentials in hand, the attacker waited. In November 2022 — four months after the initial compromise — they used those credentials to authenticate to the shared cloud environment, a third-party cloud storage service that LastPass used in conjunction with AWS for backup storage.

Inside that environment, they found backup archives containing LastPass infrastructure data, configuration information, and — most critically — decrypted copies of customer vault backup data. These backups were stored in a format that was decryptable at rest using keys that the cloud environment itself held. The attacker copied the backup archives, which included encrypted customer vaults, and exfiltrated them.

The encrypted vaults remain protected by each customer’s master password, which LastPass never stores. But the exfiltration of the vault data itself — combined with the infrastructure data in the backups — represented a significant breach, as it enables offline brute-force attacks against master passwords.

The configuration failures

Several layers of configuration and policy failed independently.

Long-lived credentials on a personal endpoint. The engineer held persistent AWS access keys — not temporary session credentials issued via sts:AssumeRole — stored on a personal device that LastPass did not control, monitor, or patch. Long-lived credentials are a standing target: they do not expire, they do not require re-authentication, and if they are exfiltrated, the attacker’s access persists until the key is explicitly rotated or revoked. The correct model for privileged cloud access is just-in-time credentials: the engineer authenticates to a managed identity system, receives a time-limited session credential via sts:AssumeRole, and that credential expires when the session ends.

Decryptable backups stored in a shared environment. Backup archives containing sensitive data should be encrypted with keys that are not co-located with the data. If the backup environment holds both the data and the decryption keys, it is effectively unencrypted from an attacker’s perspective. The correct model is envelope encryption: data is encrypted with a data key, the data key is encrypted with a KMS key, and access to the KMS key requires a separate IAM permission that is audited and can be restricted to specific principals.

No anomaly detection on large data exports. The four months between Phase 1 and Phase 2 suggest that the attacker was deliberate and patient. But when the bulk copy of backup archives occurred in November, it should have generated an anomalous access pattern: a large volume of s3:GetObject calls, potentially from an unusual IP or at an unusual time, using credentials that had not recently been used for operational tasks. S3 data event logging — disabled by default — would have captured every object-level read. Amazon Macie would have flagged the large-scale access to buckets containing sensitive data types. Neither was in place.

Privileged work on unmanaged hardware. The engineer’s home machine was outside LastPass’s endpoint detection and response (EDR) coverage. A privileged access workstation (PAW) model would have required that any access to production cloud environments originate from a managed, hardened device — one with EDR, patch enforcement, application allowlisting, and no consumer software installed. The media player vulnerability exploited in Phase 1 would not have been present on such a device.

The remediation playbook

Eliminate long-lived access keys for humans. Replace all persistent IAM access keys used by engineers with role-based federation: aws sso login, SAML-based identity provider federation, or sts:AssumeRole via a privileged access management system. Set a Service Control Policy that denies iam:CreateAccessKey for human users.

Enforce privileged access workstations. Require that all access to production cloud consoles, CLIs, and APIs originate from managed devices. Enforce this with IP allowlists tied to corporate VPN egress, or with IAM condition keys (aws:SourceIp, aws:ViaAWSService) that restrict API access to known network ranges.

Encrypt backups with externally managed KMS keys. Store backup data encrypted with AWS KMS CMKs. Use key policies that restrict kms:Decrypt to specific IAM roles, and enable KMS CloudTrail logging so every decryption operation is recorded.

Enable S3 data event logging on backup buckets. Configure a CloudTrail trail with s3:GetObject and s3:PutObject data events on any bucket containing sensitive data or backups. Route events to CloudTrail Lake and alert on high-volume reads from a single identity within a short window.

Takeaway

LastPass was not breached through a flaw in its encryption design or a zero-day in its cloud infrastructure. It was breached through the predictable failure point of privileged credentials stored on a personal device that no one was responsible for securing. The controls that would have prevented it — just-in-time credentials, managed endpoints, encrypted backups with separated keys, and data event logging — are not exotic. They are the baseline that any organization storing sensitive customer data should apply before granting privileged cloud access to any individual on any device.