LastPass Hack: Attacker Accessed DevOps Engineer’s Home Computer to Steal Decrpytion Keys

[Editor’s note: This article has been updated to reflect the company’s official statement on the new updates.]

The same threat actor that accessed portions of the LastPass development environment and source code that has forced the company since August 2022 to provide updates as new information is revealed, apparently accessed a shared cloud-storage environment obtained access keys and decryption keys by targeting a developer’s home computer.

The security incident, now thought to be related to an August 2022 incident, is the fourth update the company has issued on the matter and sheds light on the security issues inherent in distributed work environments and vulnerability of home networks.

According to Boston, Mass.-based LastPass, the threat actor leveraged information stolen during the first incident, information available from a third-party data breach, and a vulnerability yin a third-party media software package to launch the coordinated second attack.

In an update, the company says the attack targeted LastPass infrastructure, resources and an employee. The attack leveraged different tools and methods from the attack discovered last summer, leading the company to at first believe that the incidents were not related.

“Our investigation has revealed that the threat actor pivoted from the first incident, which ended on August 12, 2022, but was actively engaged in a new series of reconnaissance, enumeration, and exfiltration activities aligned to the cloud storage environment spanning from August 12, 2022 to October 26, 2022,” the company says in a new update.

In response, LastPass created a guide to help LastPass business administrators and security analysts assess and understand the actions they should take.

The company has also created a PDF document that details the incidents, what data was accessed, what actions business and consumers should take, what the company has done in response and what LastPass will do going forward.

However, the information was originally difficult to find on the company’s website earlier this week. Spotted by Bleeping Computer, the support documents about the incident are not listed in search engines, as the company added <meta name=”robots” content=”noindex”> HTML tags to the document to prevent them from being indexed by search engines.

However, CEO Karim Toubba gave an official statement on the new updates, essentially repeating what those advisories and documents say, as well as explaining the company’s response timeline.

“We have heard and taken seriously the feedback that we should have communicated more frequently and comprehensively throughout this process,” Toubba says. “The length of the investigation left us with difficult trade-offs to make in that regard, but we understand and regret the frustration that our initial communications caused for both the businesses and consumers who rely on our products. In sharing these additional details today, and in our approach going forward, we are determined to do right by our customers and communicate more effectively.”

New information emerges

According to the company’s update, the threat actor leveraged valid credentials stolen from a senior DevOps engineer to access a shared cloud-storage environment, making it difficult for investigators to differentiate between threat actor activity and legitimate use.

Amazon Web Services (AWS) GuardDuty Alerts informed LastPass of the anomalous behavior as the threat actor attempted to use Cloud Identity and Access Management (IAM) roles to perform unauthorized activity, the company says.

To access the cloud-based storage resources – notably S3 buckets which are protected with either AWS S3-SSE encryption, AWS S3-KMS encryption, or AWS S3-SSE-C encryption – the threat actor needed to obtain AWS Access Keys and the LastPass-generated decryption keys. The encrypted cloud-based storage services house backups of LastPass customer and encrypted vault data.

As mentioned in the first incident summary, certain LastPass credentials stolen during the first attack were encrypted and the threat actor did not have access to the decryption keys, which could only be retrieved from two locations:

A segregated and secured implementation of an orchestration platform and key-value store used to coordinate backups of LastPass development and production environments with various cloud-based storage resources, or
A highly restricted set of shared folders in a LastPass password manager vault that are used by DevOps engineers to perform administrative duties in these environments.

To obtain those decryption keys needed to access the AWS S3 buckets, the threat actor targeted one of the four DevOps engineers who had access to those decryption keys. The threat actor targeted the engineer’s home computer, exploited a third-party media software package bug to gain remote code execution and implanted keylogger malware.

This allowed the attacker to capture the employee’s master password as it was entered, after the employee authenticated with MFA, and gained access to the DevOps engineer’s LastPass corporate vault.

The threat actor then exported the native corporate vault entries and content of shared folders, which contained encrypted secure notes with access and decryption keys needed to access the AWS S3 LastPass production backups, other cloud-based storage resources, and some related critical database backups, the company says.

The company says it has performed the following work:

With the assistance of Mandiant, we forensically imaged devices to investigate corporate and personal resources and gather evidence detailing potential threat actor activity.

We assisted the DevOps Engineer with hardening the security of their home network and personal resources.

We enabled Microsoft’s conditional access PIN-matching multifactor authentication using an upgrade to the Microsoft Authenticator application which became generally available during the incident.

We rotated critical and high privilege credentials that were known to be available to the threat actor; we continue to rotate the remaining lower priority items that pose no risk to LastPass or our customers.

We began revoking and re-issuing certificates obtained by the threat actor.

We analyzed LastPass AWS S3 cloud-based storage resources and applied or started to apply additional S3 hardening measures:

We put in place additional logging and alerting across the Cloud Storage environment with tighter IAM policies enforced.

We deactivated prior development IAM users.

We enabled a policy that prevents the creation and use of long-lived development IAM users in the new development environment.

We rotated existing production service IAM user keys, applied tighter IP restrictions, and reconfigured policies to adhere to least privilege.

We deleted obsolete service IAM users from the development and production environments.

We are enabling IAM resource tagging enforcement on accounts for both users and roles with periodic reporting on non-compliant resources.

We rotated critical SAML certificates used for internal and external services.

We deleted obsolete/unused SAML certificates used for development, services, or third parties.

We revised our 24×7 threat detection and response coverage, with additional managed and automated services enabled to facilitate appropriate escalation.