Skip to content
Naked Security Naked Security

LastPass source code breach – incident response report released

Wondering how you'd handle a data breach report if the worst happened to you? Here's a useful example.

If the big story of this month looks set to be Uber’s data breach, where a hacker was allegedly able to roam widely through the ride-sharing company’s network…

..the big story from last month was the LastPass breach, in which an attacker apparently got access to just one part of the LastPass network, but was able to make off with the company’s proprietary source code.

Fortunately for Uber, their attacker seemed determined to make a big, quick PR splash by grabbing screenshots, spreading them liberally online, and taunting the company with shouty messages such as UBER HAS BEEN HACKED, right in its own Slack and bug bounty forums:

The attacker or attackers at LastPass, however, seem to have operated more stealthily, apparently tricking a LastPass developer into installing malware that the cybercriminals then used to hitch a ride into the company’s source code repository:

LastPass has now published an official follow-up report on the incident, based on what it has been able to figure out about the attack and the attackers in the aftermath of the intrusion.

We think that the LastPass article is worth reading even if you aren’t a LastPass user, because we think it’s a reminder that a good incident response report is as useful for what it admits you were unable to figure out as for what you were.

What we now know

The boldface sentences below provide an outline of what LastPass is saying:

  • The attacker “gained access to the [d]evelopment environment using a developer’s compromised endpoint.” We’re assuming this was down to the attacker implanting system-snooping malware on a programmer’s computer.
  • The trick used to implant the malware couldn’t be determined. That’s disappointing, because knowing how your last attack was actually carried out makes it easier to reassure customers that your revised prevention, detection and response procedures are likely to block it next time. Many potential attack vectors spring to mind, including: unpatched local software, “shadow IT” leading to an insecure local configuration, a phishing click-through blunder, unsafe downloading habits, treachery in the source code supply chain relied on by the coder concerned, or a booby-trapped email attachment opened in error. Hats off to LastPass for admitting to what amounts to a “known unknown”.
  • The attacker “utilised their persistent access to impersonate the developer once the developer had successfully authenticated using multi-factor authentication.” We assume this means that the hacker never needed to acquire the victim’s password or 2FA code, but simply used a cookie-stealing attack, or extracted the developer’s authentication token from genuine network traffic (or from the RAM of the victim’s computer) in order to piggy-back on the programmer’s usual access:
  • LastPass didn’t notice the intrusion immediately, but did detect and expel the attacker within four days. As we noted in a recent article about the risks of timestamp ambiguity in system logs, being able to determine the precise order in which events occurred during an attack is a vital part of incident reponse:
  • LastPass keeps its development and production networks physically separate. This is a good cybersecurity practice because it prevents an attack on the development network (where things are inevitably in an ongoing state of change and experimentation) from turning into an immediate compromise of the official sofware that’s directly available to customers and the rest of the business.
  • LastPass doesn’t keep any customer data in its development environment. Again, this is good practice given that developers are, as the job name suggests, generally working on software that has yet to go through a full-on security review and quality assurance process. This separation also makes it believable for LastPass to claim that no password vault data (which would have been encrypted with users’ private keys anyway) could have been exposed, which is a stronger claim than simply saying “we couldn’t find any evidence that it was exposed.” Keeping real-world data out of your development network also prevents well-meaning coders from inadvertently grabbing data that’s meant to be under regulatory protection and using it for unofficial test purposes.
  • Although source code was stolen, no unauthorised code changes were left behind by the attacker. Of course, we only have LastPass’s own claim to go on, but given the style and tone of rest of the incident report, we can see no reason not to take the company at its word.
  • Source code moving from the development network into production “can only happen after the completion of rigorous code review, testing, and validation processes”. This makes it believable for LastPass to claim that no modified or poisoned source code would have reached customers or the rest of the business, even if the attacker had managed to implant rogue code in the version control system..
  • LastPass never stores or even knows its users’ private decryption keys. In other words, even if the attacker had made off with password data, it would have ended up as just so much shredded digital cabbage. (LastPass also provides a public explanation of how it secures password vault data against offline cracking, including using client-side PBKDF2-HMAC-SHA256 for salting-hashing-and-stretching your offline password with 100,100 iterations, thus making password cracking attempts very much harder even if attackers make off with locally-stored copies of your password vault.)

What to do?

We think it’s reasonable to say that our early assumptions were correct, and that although this is an embarrassing incident for LastPass, and might reveal trade secrets that the company considered part of its shareholder value…

…this hack can be thought of as LastPass’s own problem to deal with, because no customer passwords were reached, let alone cracked, in this attack:

This attack, and LastPass’s own incident report, are also a good reminder that “divide and conquer”, also known by the jargon term Zero Trust, is an important part of contemporary cyberdefence.

As Sophos expert Chester Wisniewski explains in his analysis of the recent Uber hack, there’s a lot more at stake if crooks who get access to some of your network can roam around wherever they like in the hope of getting access to all of it:

Click-and-drag on the soundwaves below to skip to any point. You can also listen directly on Soundcloud.


I’m a computer user from the 286 era, aware that I know about security as well as I know the constituents in pencil lead, it’s soft or hard.

I bought into Dr Solomon in the early days and have never regretted it.

In the intervening years I’ve had two glitched, resolved by Sophos, and intend to stay on the path I’ve come to trust.

I do read the articles and act where I’m able but in all honesty that’s the best I can, or want to do.

Some of us are like many drivers, we know how to drive but not how the engine works, so we leave problems to the professionals.


I first learned about LastPass after Steve Gibson of Security Now podcast gave it high marks. Everything has flaws.You can divide systems into those that have been hacked and those that will be hacked. As Stuxnet showed us back in 2010, even an airgap can be compromised.

I am a retired network admin. Most.people have relatively modest password management need. But in a professional environment, password management is a must. The company I worked for prior to my retirement had approx. 500 employees and somewhere north of 4,000 critical credentials – device logins, service logins, accounts with 3rd party vendors, and more. In such an environment, a password manger is not optional. We always tried to limit access to our various systems to those with a need to know. But it was not a perfect system. We were continuously in a cycle of discovering faults, evaluating them, deciding the best way to adress them. Some problems could be fixed with code changes; others might prompt policy changes. A lot of times both were needed. Occasionly new hardware was needed. We also worked with an outside firm to regularly test to be sure all well-known exploits were closed.

At the end of the day, what matters most is how a company like LastPass handles these breaches. I used LastPass professionally for 20 years. Seeing the way they handled this, with thorough analysis, admitting what they dont know, then disclosing to the public a large percentage of what they discovered – all of this in no way diminishes my confidence in LastPass. To the contrary, it strengthens my confidence in LastPass. I wish more company handled breaches in the same way. In many ways, LastPass sets the standard for how these breaches should be handled.


“The trick used to implant the malware couldn’t be determined.” ??? This seems someone from inside was involved just like most of successful attacks. :)


I don’t think it’s true that “most successful cyberattacks” involve insiders. (To be clear, I am treating phishing as an “outsider attack”, even though it requires an insider to make a blunder.)

And I don’t think there is any reason to assume that an attack they can’t be fully explained must, iPod facto, be down to an insider.


Leave a Reply

Your email address will not be published. Required fields are marked *

Subscribe to get the latest updates in your inbox.
Which categories are you interested in?
You’re now subscribed!