LastPass DevOps engineers were compromised because they had access to the decryption keys. LastPass detailed an “organized second attack” in which a threat actor took data from Amazon AWS cloud storage servers for two months. Threat actors obtained partially encrypted password vault data and customer data from LastPass in December.
The well-known password manager LastPass has revealed additional details about a planned attack that led to data loss from Amazon AWS cloud storage servers for over two months. Threat actors took customer data and password vault data that was only partially encrypted, according to the company’s original disclosure of the breach in December. The business has now revealed further information about the attack’s execution strategy.
According to LastPass, the hackers installed a keylogger on the computer of a senior DevOps engineer using information acquired in an August data breach, information from another data breach, and a remote code execution vulnerability. The stolen information from the first hack was used in this second coordinated effort to access the company’s encrypted Amazon S3 buckets.
Hackers Choose A LastPass DevOps System
The threat actor chose one of the four LastPass DevOps engineers because they had access to the decryption keys. By taking advantage of a remote code execution flaw in a piece of third-party media software, the hackers successfully installed a keylogger on the employee’s device. The threat actor gained entry to the DevOps engineer’s LastPass business vault using this technique, which also allowed it to capture the employee’s master password as it was being typed.
The hackers gained access to the corporate vault and exported the native corporate vault entries and shared folder content. These files contained encrypted secure notes with the access and decryption keys required to access the AWS S3 LastPass production backups, other cloud-based storage resources, and some related critical database backups.
According to LastPass, the use of legitimate credentials made it difficult for the company’s analysts to identify the threat actor’s behavior, allowing the hackers to access and steal data for more than two months, from August 12, 2022, to October 26, 2022.
Finally, LastPass discovered the abnormal behavior. As the threat actor attempted to exploit Cloud Identity and Access Management (IAM) roles to conduct unlawful activities, LastPass eventually discovered the odd behavior through AWS GuardDuty Alerts.
Since then, according to the organization, they have changed their security posture by revoking certificates, rotating sensitive credentials and authentication keys/tokens, adding more logging and alerting, and implementing tougher security standards. LastPass has specified exactly which customer data was taken during the incident as part of today’s announcement.
Depending on the specific customer, the stolen data may include split knowledge component (“K2”) keys for Federated business customers, MFA API integration secrets, or multifactor authentication (MFA) seeds. This information may be used to access user accounts without authorization and could compromise sensitive data.
A detailed list of the information that was taken has been made public by LastPass and can be seen on their support page.
The concerted attack on LastPass emphasizes the significance of continuing to maintain strong security procedures to safeguard sensitive data. In order to limit damage, businesses must also put in place strict security measures to stop such assaults and detect them as quickly as feasible.
Tons of Data Accessed
A more thorough and easier-to-read chart may be found on a support website; however, the list of all stolen data is provided here.
Data retrieved in Incident 1 summary:
- 14 out of 200 software repositories were on-demand, cloud-based development and source code repositories.
- Secrets and certificates for LastPass were contained in internal scripts from the repository.
- Technical information that explained how the development environment worked was provided in internal documents.
Data retrieved in Incident 2 summary:
- Restricted “DevOps Secrets” were used to access our cloud-based backup storage.
- Configuration information, API secrets, third-party integration secrets, customer metadata, and backups of all customer vault data were all stored in cloud-based backup storage. As a result, they were not part of the data that was stolen.
- Except for URLs, file paths to installed versions of the LastPass Windows or macOS software, and some use cases involving email addresses. All sensitive customer vault data was encrypted using our Zero knowledge model and can only be unlocked using a unique encryption key derived from each user’s master password.
- In case you forgot, LastPass never has access to end-user master passwords and does not store or manage them.
- Phone numbers needed for the MFA backup option, LastPass Authenticator seeds, and a split knowledge component (the K2 “key”) required for LastPass federation were all included in the backup of the LastPass MFA/Federation database (if enabled).
- Although this database was encrypted, the decryption key was separately held and was taken by the threat actor during the second event.
In a PDF document titled “Security Incident Update and Suggested Steps,” LastPass provides additional details regarding the breach and the data that was taken.
Also, the business produced support materials with suggested activities for LastPass Business Administrators, Free, Premium, and Family users. Use different passwords for every account, whenever possible, use multi-factor authentication, and keep an eye on your accounts for any suspicious behavior.
Conclusion
LastPass’s December 2022 data breach, which allowed threat actors to access encrypted password vaults, was caused by the same adversary’s second attempt. The company stated one of its DevOps engineers had their home computer breached and infected with a keylogger as part of a prolonged cyber attack that exfiltrated confidential data from its Amazon AWS cloud storage servers.
From August 12 through October 26, 2022, this infiltration targeted the company’s infrastructure, resources, and one employee. The password management service claimed the threat actor used information from the first incident, a third-party data breach, and a media software weakness to perform a coordinated second attack. On August 12, 2022, the original incident ended.
