Lapsus$’s Breaches — A Wake Up Call for Defense of Identity in Depth

In honor of Cybersecurity month, we wanted to take a look at one of the most confusing, if not successful, threat actors who have been on everyone’s minds this year. 

I’m speaking of course of Lapsus$.

In the past 10 months, the group has hit a string of big name companies in what we can genuinely call a display of talented social engineering and head scratching motivations.

As a group, we can best describe them as somewhere between chaotic neutral and evil. Hacking for some coin, but mostly because they can and none of their corporate targets have managed to stop them from doing so. 

Okta, Uber, Rockstar, Samsung, Microsoft, Ubisoft, and others have all found themselves in the headlines for having been breached by the Lapsus$ crew, which if we’re being honest, we don’t really know much about. Claiming to be a couple of teens, maybe located in Brazil or the UK (but who really knows) this group has been serving up a steady stream of breaches with methods that far too many have called “sophisticated”. 

In every single case where their involvement has been confirmed or closely enough as is, they have managed to hack large organizations with supposedly strong security departments by going not through the back door, but right up through the front gate using stolen credentials and a bit of social engineering.

Identity is the New Battlefield 

According to the Verizon Data Breach Investigation Report (DBIR), 48% of breaches involved the illegitimate use of credentials. 

This means that the attackers did not have to break in with clever coding, but simply by using real credentials that ostensibly gave them the right to be within the organization’s perimeter, mulling about looking for goodies. 

This 48% statistic is against the backdrop of the total 82% of breaches that stem from the “human element” that involves credentials, phishing, misuse, and simple error. 

The reason for identity being under assault is clear. It is the key for how we access all of our apps and services, especially in the era of hybrid work and our increasing reliance on the cloud. 

Once we move out of the classic on-prem perimeter with its firewalls, we need to add effective protections to keep the bad guys and gals out.

One way of trying to do this is by asking them to authenticate more than once.

Multi-Factor Authentication is Nice but Not Enough

Time after time, hackers claiming to be with Lapsus$ have exploited the identity layer, using basic yet effective techniques to skirt around Multi-factor Authentication (MFA) protections. 

That this crew is having great success in popping their targets via stolen credentials and breaking through the barriers of authentication should not be too surprising. Organizations are only recently really catching up with the fact that they need to implement strong authentication protocols like MFA to help protect their identities from being exploited.

According to Microsoft, they claimed back in August 2019 that 99.9% of attacks could be prevented if MFA was implemented. Despite the obvious advantages, Redwood reported this past February that only 22% of enterprise customers had adopted MFA. 

This is hardly an optimal situation. But it gets worse. 

MFA was supposed to be the technology that kept the attacker outside the gates. But like every other attacker in history, they continue to make it past the walls and onto the soft insides of the organization’s assets.

If Lapsus$, a group of supposed youngsters allegedly hacking for the lulz is getting around MFA on the regular, then we should probably be concerned about how successful more experienced and motivated actors can be once they put their mind to it. 

Following the most recent round of breaches, a lot of digital ink has been spilled on how password replacements like FIDO2 and other passwordless options could have saved one victim or the other. Of course, the fantastic Yubikeys with their physical token would likely have defeated attempts at social engineering. But good luck dealing with all the folks who forget their keys in their “other bag” and clog up Help Desk support.  

All these advances in MFA are wonderful. Even the much maligned (see the latest Uber hack) MFA classic with push notifications is a great step that we are waiting for most of the world to catch up to if only they’d implement it. Having solid MFA in place can help keep out the low hanging fruit that most of the bottom feeders are willing to go after. We should yearn for the day when our biggest problem is that users’ MFA is being defeated and not that they do not have it in place.

But what Lapsus$ has shown us time and again is that they are more than able to break through these barriers, leaving us with the question of what to do once the more determined attackers are past our gates. 

How do we defend our data when we assume that the breach has already happened and start mitigating the damage?

3 Steps for Achieving Defense In-Depth

Security is like dressing for the cold. It is best done in layers.

Authentication is only one layer of defense, but there are plenty of additional layers that need to be in place before and after it. It is not enough to prove that you have credentials when the identity is so easy to compromise. 

Authorization is a critical layer of protection because it allows us to limit what the identity is able to access in the first place, and what those identities can do with their privileges. 

Below are three key areas where proper authorization can significantly reduce your risk and help you to stay secure moving forward. 

1. Reduce Your Threat Surface to Achieve Least Privilege 

The Principle of Least Privilege calls for granting the minimal amount of access that an identity requires to do their job. No more, no less. Every bit of over privilege represents an unnecessary risk for an attacker to use their access to harm the organization. 

The trick is striking the right balance that allows everyone to do what they need to effectively and efficiently without expanding the threat surface. 

Authomize takes the guesswork out of achieving Least Privilege detecting all of the identities, assets, and access privileges in your cloud environments. By understanding who has access to what, we can track activities and analyze how the access privileges are being used.

If a privilege hasn’t been used in say 30 or 60 days, does the identity still need it to do their job? 

With our usage data, combined with data pulled from Identity Providers like Okta, Ping Identity, and Azure AD to name a few, cloud assets like AWS, Azure, GCP, Salesforce, GitHub, GitLab, O365, GSuite, DropBox, and anything else that you want to connect with using our native connectors or REST API, our proprietary Machine Learning SmartGroups can detect over privilege and offer contextual recommendations to remediate. 

What you want to do here is run an access review to achieve a secure baseline of privileges, removing any superfluous ones. 

This means getting rid of the stale accounts and privileges that have not been used and are just waiting to be abused. Knocking these out is especially important for avoiding partial off-boarding issues where a former employee’s identity retains privileges in some of their accounts. 

A classic example of this is a developer who has their access revoked in AWS through their Okta account, but their personal GitHub account with its “Bring your own identity” model retains access to the company’s private repositories. 

If the security and identity teams are only using the visibility that they have from Okta but not seeing what is happening from their application and service (the assets) side of the equation, then they are only seeing part of the picture. 

Running an access review with all of the elements in your cloud environments can help you to get rid of excessive privileges and reduce your risk from an overly exposed threat surface. 

2. Eliminate Privilege Escalation Paths 

Having comprehensive yet granular visibility across all of the environments is also important for assessing less obvious risks like Privilege Escalation.

These risks can include Shadow Admins who pull together different “non admin” privileges to make themselves essentially admins. It could also be a situation where someone can create an EC2 and become an admin there, thereby becoming an admin everywhere. 

Understanding all the paths to access allows us to stop these escalations, but first we need to know what our effective access is to our assets. 

Tools like our Access Explorer correlate the data from the IdP all the way to the asset, regardless of how many environments, roles, or groups it “jumps” through to get there. Getting this right is harder than it may seem because of barriers to visibility between the environmental silos.  

One example of this lack of visibility is that federated identities (those identities that are managed through an IdP) become difficult to track once they enter AWS. This is because the IdP shows which roles a user can assume, but “loses sight” of them once they assume that role. 

Authomize with its cross-environmental visibility sees the effective access, understands all of the potential paths and how to prevent them, giving us a leg up over solutions that can only see access through an IaaS, SaaS, or Data vertical.     

3. Monitor Privilege Activities for Indicators of Compromise

Once you have reduced your privileges to a secure baseline and blocked off privilege escalation paths, it’s time to monitor and maintain the right level of privileges. 

Authomize’s security policies allows security teams to continuously monitor for risks and threats across their identity and access layer. 

Policies can be used to monitor for threats like changes to privileges. Classic examples from cases like SolarWinds where the adversaries created new admins are definitely important to be alerted about. 

After an alert has been issued by Authomize, we need to use it effectively to take action. 

Using our webhooks with SIEMs, SOARs, ITSMs, and XDRs, Authomize can automatically trigger workflows in those security orchestration tools, providing the context they need to lead to a speedy and effective remediation. Bidirectional communication with these tools can then close the loop, letting teams know that the issue has been resolved.  

Be a Pomegranate 

Security is about having lots of layers and taking very little for granted. Never trust, always verify.

No matter how hard we make our perimeters, using good, dynamic MFA, we also need to implement lots of segmentation for the inside for when the attackers make it past the gates. 

Our job is to severely limit what the attacker is able to reach. Using the right tools, we can minimize the penetrable surface, and waste their time if they do make it in.

An analogy that I like to use here is that of a walnut versus a pomegranate. 

Sure the walnut is hard on the outside, but it is soft and chewy on the inside. 

The pomegranate on the other hand is fairly hard on the outside but each juicy seed is segmented heavily. Getting to each one of them takes time, making even the most determined eater wonder if the juice is worth the squeeze. 

To learn more about how Authomize’s Cloud Identity and Access Security Platform can give would-be hackers like Lapsus$ a bad day, contact us today for more information and request a demo of our platform.

The post Lapsus$’s Breaches — A Wake Up Call for Defense of Identity in Depth appeared first on Authomize.

*** This is a Security Bloggers Network syndicated blog from Authomize authored by Gabriel Avner. Read the original post at:

Avatar photo

Gabriel Avner

Gabriel is a former journalist who loves learning and writing about the cat and mouse game of security. These days he writes for WhiteSource about the issues impacting open source security and license management and training Brazilian Jiu-Jitsu.

gabriel-avner has 51 posts and counting.See all posts by gabriel-avner