A late 2022 theft of LastPass’s decrypted password vaults has been tracked to one of the company’s DevOps engineers, as attackers reportedly targeted a vulnerability in a media software package on the employee’s home computer. The victim was reportedly one of only four employees at the company that had access to a shared folder that provided the keys to customer vaults.
This incident is related to the 2022 theft of encrypted customer password vaults from LastPass’s network, as the company says that the same threat actor was responsible for both of the intrusions. The decrypted vault looks to have given the attacker access to encryption keys used to secure customer backups stored on an Amazon S3 server.
LastPass DevOps engineer targeted by skilled attacker
LastPass’s public notice of the incident provides further clarity to the previously reported theft of customer vaults, in terms of both timeline and what level of damage customers can expect from the incident.
The threat actor’s first incursion began sometime prior to August 12 2022, and ended on that date; the company believes this was an initial reconnaissance effort that ultimately yielded a means of network access along with the theft of some internal company information. The attacker then returned for an assortment of activities, including the various thefts of customer password vaults and company secrets, through October 26.
The company says that the backup keys were stored in a “segregated and secured” platform in the development environment, which has led to some confusion about how the attacker ultimately obtained the customer password vaults. This new information indicates that the attacker was able to access these encryption keys via an alternate route: the accounts of four DevOps engineers that shared a folder used for administrative duties.
The attacker appeared to be aware of the identity of at least one of these DevOps engineers, and targeted vulnerabilities on their home computer. Specifically, a vulnerability in a “third-party media software package” that allowed for remote code execution and enabled the attacker to plant a keylogger.
Concerns about the password vault thefts were already very high given LastPass’s communications about the incident. After the initial breach notification in August, it took nearly four months for the company to reveal that customer files had been stolen in the breach. It has now been nearly seven months as these new details emerge.
LastPass did not reveal which media software package was exploited on the DevOps engineer’s home computer, but Ars Technica is reporting that an anonymous inside source says it was the Plex streaming service and media player, which suffered its own data breach (that included customer login information) on August 24. Plex says that it has not communicated with LastPass about the incident as of yet.
Theft of password vaults, questionable incident response a severe blow to LastPass’s business
To date LastPass has only advised customers to change their master password, but this latest news may be enough to convince what’s left of its customer base to simply find another service.
The DevOps engineer should not have been able to open customer password vaults or other encrypted resources that customers have protected with their own password, but the loss of the files creates the possibility that hackers will attempt to “brute force” them open with password guessing over time. The specific targeting of the home computer of the DevOps engineer indicates the attackers are sophisticated and know exactly what they’re looking for, and LastPass customers with crypto assets or stored keys to substantial financial resources should assume that their password vaults have been moved to the front of the list for cracking. Those with relatively short or simple passwords should also assume their files will eventually be compromised.
The fact that a range of “internal company secrets” was taken during the various incursions is also highly troubling, as these might reveal some weakness in the encryption scheme or provide the attackers with ways to get back into the system. And there is still no news about the identity of the threat actor, as information related to the password vault thefts has yet to emerge on the dark web or other known underground markets.
LastPass has promised the usual assortment of security improvements in the wake of the incident: bringing in Mandiant for a forensic investigation, enabling new multi-factor authentication options, rotating the compromised credentials and certificates, improving threat detection and response capabilities, and “hardening the home defenses” of the DevOps engineers that hold privileged access. All of this may well come as too little too late for the company’s customers, which have been taken on a half-year ride from “the development environment was compromised and nothing was stolen” to “encryption keys were taken and your password vaults are now out in the open.”
However, Sharon Nachshony (Security Researcher at Silverfort) notes that many organizations are similarly vulnerable and simply haven’t been as unlucky (or highly targeted) as of yet: “Given the number of people who rely on LastPass it’s easy to pass quick judgment on back-to-back incidents, however, what this really shows is the difficulty of detecting attacks that use seemingly legitimate, yet stolen, credentials. By obtaining these credentials, the threat actor was able to masquerade as a highly trusted user, giving them the freedom to pivot into the cloud storage environment. The corporate vaults holding privileged credentials often become a single point of failure. Given enough reconnaissance time a motivated attacker will try to understand how to compromise such vaults because, once they have such credentials, it’s like having a VIP pass to corporate resources. In the case of this attack, an additional layer of MFA to authenticate into the cloud storage environment may have provided additional protection.”
Dr. Ilia Kolochenko, Founder of ImmuniWeb, anticipates a coming “surge” of highly targeted attacks on individual employees: “This is an emerging vector of sophisticated cyber-attacks: targeting victim’s employees, who have privileged access to internal systems, instead attacking the victims directly. Following a series of devastating supply-chain attacks in the last three years, most organizations now take their third-party security extremely seriously and significantly limit data sharing with their external suppliers or vendors. Creative cybercriminals have, however, discovered another low-handing-fruit attack vector – a grim derivate of the pandemic and working-from-home trend – victim’s employees.”
“Moreover, when working-from-home employees are using employer’s equipment, many foundational security tasks, such as timely installation of patches or restrictions to use unvetted software, may become less efficient and flawed. Eventually, instead of running frontal attacks against a well-protected corporation, cyber gangs stealthily steal the “keys to the Kingdom” from a breached employee’s machine. Worst, such intrusions are hardly detectable by various anomaly detection systems and thus oftentimes remain unnoticed. In 2023, we should expect a surge of sophisticated attacks on privileged tech employees aimed at stealing their access credentials and getting access to the “Crown Jewels”. Organizations should urgently consider reviewing their internal access permissions and implement additional patterns to be monitored as anomalies, such as excessive access by a trusted employee or usual access during non-business hours,” added Kolochenko.
Dror Liwer, co-founder of Coro, believes that the only feasible response at this point is a “draconian” access control policy for devices used from home: “The concept of personal, home, or corporate device represents an outdated way of thinking about security. Any device used to access any company data, and that includes email, should be protected. The issue of course is that employees are reluctant to put corporate mandated security tools on their private devices. The right policy must be about access control: Devices that are not protected, or that do not comply with company guidelines for security posture should simply not be allowed access. It sounds draconian – but it gives the employee the option to either use their private device with company issued security tools, or corporate device only.”
