The LAPSUS$ hacking group has been around for a few months now (at least publicly, based on their achievements they must have been around for much longer). Two people associated with it were even arrested, and no new dumps were released in the last couple of months.
Recent requests we’ve been getting from our customers, regarding similar vectors and attackers, motivated us to take a closer look at what was publicly available about these attacks and how Solvo’s platform can be leveraged in order to prevent similar incidents.
But still, what can be done? I’d recommend making sure you know which ones of your crown-jewels have access to the internet, external accounts and 3rd parties.
2. 3rd parties access (aka Supply chain attacks) – we all use them in our code, infrastructure or applications. Attackers love them because a single point of failure could become an entrance vector to many other organizations (that’s actually another form of energy preservation).
The previous two sections were examples of the entrance vectors used by hacking groups such as LAPSUS$, and potential ways to reduce the risk to your cloud assets. Now, let’s look at some risks and misconfigurations that grant the hackers with privileges to perform reconnaissance, privilege escalation and execution of other risky actions:
3. Listing permissions (as part of a reconnaissance) – knowing what kind of permissions exist in the account is very important. The attacker would know what identities might be more valuable than others and try to get themselves with their permissions. We, the human users, usually name assets and identities with indicative names (Admin, Administrator, DevOps,FullAccess etc), so finding the highly privileged permissions is not hard. So, you might want to know who can actually list the permissions you have in your account and make sure only entities that actually need to make that kind of list can do that. Remove permissions from unnecessary users and assets, and consider removing the iam:List* actions from the policies where it exists.
In the example below you can see who can run the ListPolicies call:
You don’t have to “settle” for listing the actions. Instead, you can run a query and look who can read or list from an IAM resource:
In the example above, we filtered in only users and Lambda functions who can read/list IAM actions.
Actions from the listing family are very handy when looking for sensitive S3 buckets. In this case below, you would want to make sure that a flow of the actions mentioned is not available to unauthorized entities:
3. S3:GetObject – now we want to make sure that even if someone has access to the metadata of your cloud account, they can’t actually obtain items out of it.
4. Excessive permissions – you’d be surprised to learn about the funky hacks you can run using excessive permissions you didn’t think of. I’m not referring to the trivial Administrator or root access, but to other, less audited, permissions. For example, access to your Parameter Store. This popular AWS service is integrated/accessible with other services like KMS, SNS compute and code services. Being able to list parameters might expose where your crown-jewels are and potentially how to obtain them.
We have countless similar examples, and there’s no end in sight. The more we use the cloud, the more attackers use it, and learn how to exploit it in new and creative ways. No product can promise you to block or detect 100% of attack attempts, just because there isn’t a finite number of patterns. Every service can be exploited when misconfigured, what we might be able to control is the blast radius. The more excessive permissions we have, the wider the radius is.
It’s not easy, and it doesn’t make much sense to audit your cloud account policy by policy, looking for the wildcards, sensitive actions and possibly-risky configurations. This is exactly why Solvo create two products to make your life easier:
Do you think your account is well configured? Try out our NEW SecurityGenie report, and see the top risks found by theIAMagnifier.