Lessons Learned in Cloud Security from Lapsus$ Surfacing

Over the past few days, new information about the Lapsus$ cybercrime group has surfaced and provided fresh insights into the actual practices of cyber security adversaries. While it’s not clear exactly who they are (it’s been reported that the mastermind behind this group could be a teenager!), or the extent of their accomplishments - cloud security practitioners can already learn a lot about the best practices that reduce the threat from groups like Lapsus$.

You can read a lot about the activity of Lapsus$ elsewhere (most notably we recommend the post on the Microsoft Security Blog and the post by KerbsOnSecurity) and the detailed response by Okta’s CSO about their incident, so what we’ll try to do here is outline a few quick effective action items / lessons you can take away from this incident to improve the security posture of your cloud environment.

The following recommendations are in no way new or sensational - but if there was ever a time to leverage the news cycle to drive your security forward - this is it.

Gaining access using humans - The front line will be breached

What really stands out about Lapsus$ is their efforts to gain access using humans - either by manipulating people, tricking cellular providers (with SIM swapping) or even by straight-out bribing employees to betray their employers’ trust and provide access to their resources.

This vividly highlights the fact that if humans work for you, you are vulnerable to social engineering. No one should be treated as incorruptible. But even if a person IS incorruptible, they may still be vulnerable to some of the other techniques the group has used such as “deploying the malicious Redline password stealer to obtain passwords and session tokens”. The immediate implication for cloud resources is that you should reduce the access permissions people have to the very minimum they actually require in order to perform their job. As the cloud usually stores very sensitive resources, providing anyone who might be breached (virtually everyone!) with excessive permissions can cause unwarranted exposure to the crown jewels of the organization.

You can right-size access both by limiting the permissions granted and by placing guardrails on access to sensitive resources (this capability is granted by some of the major cloud providers). Providing just the right permissions in cloud infrastructure environments is hard to do from a technical standpoint. On top of that, anyone who ever tried imposing security restrictions on a development organization knows that it can be a political challenge as well. It’s also important to define organizational roles and cloud entitlements such that any one person can’t do too much damage.

In the specific case of the Okta incident, the breach (according to their statement) occurred because a machine used by a support engineer contractor was accessed via RDP by the malicious actor. As we all know, third party personnel are legally and technically harder to manage - and therefore, the principle of least privilege should be applied much more rigorously to the identities they access.

In addition to enforcing least privilege, you must prepare to handle a breach correctly once it occurs. First, you should have an effective logging solution that you are trained to use, so when an investigation is required you can proceed quickly without having to start figuring it out at the worst possible time. Second, you should have a proper framework for reviewing and analyzing logs so you can detect unusual activity, either using a cloud vendor-native tool or a 3rd party solution.

Finally, prepare for a breach with an incident response playbook that is well defined, accepted organization-wide and tested periodically. It’s crucial to verify that all the procedures and tools required for handling a breach are only available, and the personnel throughout your organization know how to use them. Often CISOs are fired not because a breach occurred, but rather because the incident was handled badly, so your job may depend on it.

Stop using static credentials!

Pardon the capitalization, but this is a very important lesson we keep coming back to (e.g. see our response to the log4j vulnerability) and it can’t be stressed often enough just how important this is.

As reported by Microsoft, as part of their kill chain, Lapsus$ are: “Searching code repositories and collaboration platforms for exposed credentials and secrets”.

Looking for static credentials stored in plain text is such low hanging fruit for malicious attackers that most of the time, using them could be considered negligent. For some APIs and SaaS interfaces there’s no alternative way to access them without generating static credentials - and then all you can do is to rotate them frequently and only store them using encrypted and secure tools which are designed for sensitive strings.

However, when it comes to cloud environments there’s almost always a good alternative to using static credentials and they should be avoided. It’s especially critical NOT TO PROVIDE THEM TO 3RD PARTIES! We’re holding a workshop on this very topic in just a few weeks - stay tuned!

Takeaway from the Microsoft report - Track your inventory

Another interesting takeaway from the Microsoft report is that the group used provisioning of assets as a key link in their campaigns, for example:

“leveraging access to cloud assets to create new virtual machines within the target’s cloud environment, which they use as actor-controlled infrastructure to perform further attacks across the target organization”

While this is another great example of why you should always employ the principle of least privilege in order to prevent abuse and to enable monitoring for anomalous behavior - it’s also a good reminder to keep close tabs on your inventory. Any compute resource can be used against you. Having a reliable and (at least near) real-time inventory management solution is not only important for asset management - but also for security.

Your Identity Provider is Not Bulletproof

Finally, even if the eventual fallout from the attack on Okta is limited, in the wake of this event, many people confronted for the first time the notion that their identity provider is in fact susceptible to cyber attacks, just like any software or infrastructure.

When you federate your identity provider to your cloud environment you delegate the ability to provide access to cloud resources to the identity provider (of course by using permissions you configure). The identity provider will also be responsible for things such as enforcing MFA for logging-in or password complexity. Therefore, if the identity provider is breached and user identities can in turn be breached, it could have serious consequences.

Many companies fail to realize that when they use an external IdP, they shift a great deal of the responsibility for configuring cloud identity and access management (which, under the shared responsibility model, belongs to you rather than the cloud provider) to a SaaS platform that is not bulletproof.

On top of that, as we’ve shown in the case of AWS, federation of users from an identity provider can make it quite difficult for you to investigate the activity of each separate user.

For these reasons, applying the principle of least privilege for identities federated from identity providers is especially crucial and implementing a logging platform that makes it easy for you to investigate and audit the activity of each federated user separately should be an important part of your security framework.

In summary

If there’s one thing we can take away from the reports of this cyber crime group, it is that it probably doesn’t take a nation state to break into major corporations. No organization should take these kinds of threats lightly.

If you’re managing an enterprise cloud security strategy, an event with such a high profile can be a great chance for you to raise awareness (and perhaps some budget) to implement the lessons outlined here. Make sure you make the most of it!