Use the disclosure timeline carefully

LastPass’s 22 December 2022 notice reported access to cloud backup storage and a copied backup of customer vault data. It described both unencrypted metadata and encrypted sensitive fields. The date attached to this case is that disclosure date, not a claim that the intrusion or copying happened on that day. The March 2023 update provides additional findings about two connected incidents.

In that update, LastPass described an initial compromised engineering laptop and development access, followed by a targeted senior DevOps engineer and access to cloud backups. It said information from the first incident helped initiate the second. These are attributed findings from LastPass’s investigation; this article does not reproduce obsolete customer instructions or independently assess the vendor’s current architecture.

The real boundary follows data and keys

Our analysis: calling an environment non-production does not reduce the impact of the production data and credentials it contains. Backup stores, developer documentation and administrative vaults can create a path around controls applied to the live application. Map where sensitive data is copied and which keys decrypt each layer, including who can obtain those keys from their ordinary workstation.

Separate privileged administrative work from personal software and routine external-content handling. Review whether a single endpoint can obtain storage credentials, decryption material and unrestricted access to the resulting data. A backup protected by encryption can still be exposed if the same reachable identity can read the encrypted objects and retrieve their keys. Conversely, do not assume every encrypted field is immediately readable without investigating its protection.

A stolen encrypted copy changes recovery assumptions

If an attacker holds a copy of an encrypted dataset, changes to the live service cannot remove that copy. Assess the protection of the particular data and the credentials or recovery material it contains. Prioritize secrets according to their reachable impact and replace them at the service that accepts them. Changing a vault login password alone does not invalidate the underlying third-party credentials recorded in a stolen historical vault.

Build a rotation plan that accounts for service identities, integration keys, recovery codes and signing material as well as ordinary passwords. Track which secrets were present during the relevant backup period and which have already been replaced. Keep the evidence and operational tasks separate so the team can investigate historical scope while containing currently valid authority.

Test whether the backup boundary is independent

Use synthetic backup data and designated test identities to verify which combinations of permissions can list, read, decrypt and delete it. Confirm that an ordinary production application or developer identity cannot perform all of those actions. Test the alerting path for unusual backup access and the ability to revoke a privileged identity without destroying every recovery option.

Rehearse a response where the stolen backup cannot be retrieved and the exact contents require reconstruction. Ask who owns customer communication, credential prioritization and restoration approval. Recovery evidence should demonstrate both usable backups and controlled access to them. The case’s durable lesson is to include backup systems and privileged endpoints within the same data-threat model as the live product.

Controls to take away

  • An environment label does not change the sensitivity of its contents.
  • A stolen historical copy cannot be revoked like a live session.
  • Backup protection requires independent access and key boundaries.

Take this to your next review

Working checklist

Use this as a starting point, then assign owners and record evidence in your team's own system. Checks here reset when you leave or reload this note.

Review actions for LastPass 2022: backup access can be the production-data incident

0 of 5 reviewed

Sources & further reading

Incident facts are attributed to the reports below. Controls and recommendations are our interpretation; this is not an independent forensic investigation.

  1. LastPass: notice of security incident, 22 December 2022 ↗
  2. LastPass: investigation update, 1 March 2023 ↗

A correction or a better primary source? Send Raiders the article URL and evidence. Editorial policy.