Cloud Security Office Hours Banner

LastPass 2022–23 — 2022

Step-by-step kill chain mapped to MITRE ATT&CK Cloud, sourced from official post-mortems and primary technical analyses.

Aug 2022 – Jan 2023 Critical AWS S3

LastPass – Dev Env Breach → Source Code Recon → DevOps Home PC (Plex Exploit) → Keylogger → AWS S3 Vault Backup Exfil

A two-stage attack first compromised LastPass's development environment, then used the stolen technical knowledge to target a specific DevOps engineer — one of only four people with access to production decryption keys. The attacker exploited a years-old unpatched vulnerability in Plex Media Server on the engineer's personal home computer to install a keylogger, captured the master password, unlocked the engineer's personal LastPass vault, and used the cloud credentials inside to exfiltrate encrypted customer vault backups from AWS S3. The entire chain required no zero-days in LastPass's production infrastructure.

33M customers notified
Encrypted vaults of all customers exfiltrated
2 stages across 5 months
Threat actor: Sophisticated, likely financially motivated or state-adjacent
📄 LastPass March 2023 disclosure ↗ 📄 LastPass Incident 2 technical detail ↗
⚡ Stage 1 — Development Environment Breach (August 2022)
01
Developer endpoint compromised — source code, technical documentation, and build secrets exfiltrated
T1195.002 – Compromise Software Supply Chain

A LastPass software developer's endpoint was compromised via a third-party software package. The attacker used this foothold to access the developer's credentials and the shared development environment, exfiltrating source code, technical documentation, internal secrets, and some customer metadata. LastPass disclosed this breach in August 2022, describing it as a development environment incident with no customer data or vault content accessed. What wasn't known at the time: the stolen technical documentation would be used to plan Stage 2.

Exfiltrated in Stage 1: Source code repositories, internal technical documentation, build environment secrets
Customer impact at Stage 1: None disclosed — no production access, no vault data
Strategic value to attacker: Infrastructure topology, S3 bucket names, backup key architecture, target identity (DevOps engineer)
Dev EnvironmentSource CodeT1195.002Stage 1
🔍 Reconnaissance — Target Selection from Stolen Docs
02
Stolen technical documentation used to identify the four DevOps engineers with production backup key access
T1591 – Gather Victim Org Information

Using the documentation stolen in Stage 1, the attacker understood exactly how LastPass's production backup encryption worked: a small set of DevOps engineers held decryption keys for the production S3 backup environment. Only four employees had access. The attacker identified one of these four as the target for Stage 2 — choosing home infrastructure as the attack surface because personal endpoints are outside corporate MDM and EDR coverage.

Target profile: DevOps engineer — one of four employees with access to production backup decryption keys
Attack surface chosen: Personal home computer — outside corporate MDM, EDR, and monitoring
Intelligence source: Stage 1 stolen technical documentation and internal runbooks
Target SelectionOSINTHome PC VectorT1591
💥 Stage 2 — Home Computer Exploitation (November 2022)
03
Unpatched Plex Media Server vulnerability exploited on DevOps engineer's home PC — remote code execution
T1203 – Exploitation for Client Execution

The targeted DevOps engineer ran Plex Media Server on their personal home computer. The attacker exploited a known vulnerability in Plex that had been publicly disclosed years prior and had a patch available — but the engineer's home installation was unpatched. Plex itself disclosed separately that it had been notified of this exploitation and confirmed the CVE was over two years old with a patch available. The exploit provided remote code execution on the home machine.

Vulnerable software: Plex Media Server — personal home installation, unpatched
Vulnerability age: Over 2 years old with patch available at time of exploitation
Attack surface: Personal home computer — no corporate EDR, no MDM, no monitoring
Result: Remote code execution on the DevOps engineer's home machine
Plex ExploitUnpatched Home PCRCET1203
🔑 Keylogger → Master Password Capture
04
Keylogger installed on home PC — DevOps engineer's LastPass master password captured
T1056.001 – Keylogging

Using the RCE foothold, the attacker installed a keylogger on the DevOps engineer's home PC. When the engineer next unlocked their personal LastPass vault, the master password was captured in plaintext. LastPass confirmed the keylogger captured the master password while the MFA was bypassed — the engineer's vault was on a personal device where MFA state was already trusted, meaning only the master password was needed to decrypt the local vault.

Technique: Keylogger capturing master password at vault unlock
MFA bypass: Personal device was a trusted device — MFA not re-prompted at each vault unlock
What was captured: Master password for the DevOps engineer's personal LastPass vault
KeyloggerMaster PasswordT1056.001Trusted Device Bypass
🔓 Vault Decryption → AWS Credential Extraction
05
Engineer's LastPass vault decrypted — AWS S3 production backup credentials and decryption keys extracted
T1555 – Credentials from Password Stores

The attacker used the captured master password to decrypt the DevOps engineer's LastPass vault. Inside were the credentials the engineer used day-to-day: AWS IAM access keys, cloud infrastructure credentials, and the decryption keys for the LastPass production backup environment stored in S3. The vault effectively contained the keys to the kingdom — by targeting the one person whose vault was both accessible from a personal device and contained production credentials, the attacker bypassed all of LastPass's production security controls in a single step.

Vault contents obtained: AWS IAM credentials · S3 backup bucket access keys · Production decryption keys · MFA seeds
Irony: A password manager's own vault was the attack vector against its production infrastructure
Architectural failure: Production credentials stored in a personal vault on an unmanaged device
Vault DecryptionAWS KeysT1555Production Credentials
📤 Exfiltration — Customer Vault Backups from AWS S3
06
Encrypted customer vault backups exfiltrated from AWS S3 — 33M customers affected
T1530 – Data from Cloud Storage

Using the AWS credentials from the decrypted vault, the attacker accessed LastPass's production S3 backup buckets and exfiltrated a copy of all encrypted customer vault backups. The backup files also contained unencrypted metadata: website URLs, usernames, billing information, IP addresses, and MFA seeds for some accounts. The encrypted vault data itself is protected by each customer's master password — but weak master passwords remain vulnerable to offline brute-force attacks against the exfiltrated data.

Data exfiltrated: Encrypted customer password vaults (AES-256 PBKDF2) for 33M customers
Unencrypted metadata also taken: Website URLs, usernames, billing data, IP history, MFA seeds
Ongoing risk: Offline brute-force attacks against encrypted vaults using weak master passwords
Also taken: API integration secrets, multi-factor authentication seeds, customer keys
S3 ExfilEncrypted Vaults33M CustomersT1530

🛡 How to Defend Against This Chain

Never store production credentials in personal vaults on unmanaged devices. Production AWS keys, infrastructure credentials, and decryption keys must live in corporate-managed secrets stores (AWS Secrets Manager, HashiCorp Vault) accessed only from managed, MDM-enrolled, EDR-monitored devices. A personal laptop running home media software is not an appropriate platform for production credential access.
Apply patch management to home machines used for work — or prohibit personal device production access entirely. The Plex vulnerability was over two years old with a patch available. If employees access production systems from home machines, those machines must meet a minimum security baseline: OS patches current, no unnecessary server software, corporate EDR installed. Better still: use a dedicated corporate-issued workstation for production access.
Segment production access behind hardware MFA that doesn't trust device state. Require a fresh FIDO2 hardware key challenge for every production credential retrieval — regardless of whether the device is "trusted." This would have broken the chain at Step 4: even with the master password, the attacker would have needed the physical hardware key.
Limit the blast radius of any single employee's credential access. Only four employees needed production backup key access. For each, access should require dual authorisation (two-person integrity), be time-limited with break-glass logging, and use separate credentials that cannot be stored alongside day-to-day vault contents.
Alert on anomalous S3 access patterns from production credential use. An AWS access key that normally accesses a small set of S3 paths should trigger an alert if it suddenly issues GetObject calls across entire bucket prefixes. GuardDuty's S3 anomaly detection and CloudTrail + SIEM rules can catch bulk exfiltration even when credentials are legitimate.

// Know a breach with a detailed post-mortem?

This is a community resource. Submit a PR to add a new kill chain — include MITRE technique IDs and link to primary sources.

→ Contribute on GitHub