7 mins to read
Good security has long been about creating a barrier to entry. It’s been about ‘keeping them out.’ The spotlight, attention, and budget, has been dedicated to that pivotal moment – whether the perimeter is breached or not.
This approach worked on-prem (for good reason) but things are different in the cloud.
Our big take: securing high-value cloud permissions should be the (time, resources, and budget) priority after perimeter defense. Here’s why we think that.
No matter what effort you focus on whether its vulnerability and workload management, platform and configuration controls, or employee security awareness training, clouds are still being breached. These solutions or practices will never be 100% successful.
So, if we know attackers are finding their way in, maybe it’s time to approach security differently. Maybe, it’s time to make a plan for when they’re in.
You Should Secure Cloud Permissions, Not Just Perimeter. Here’s Why:
The way to build a security program that protects your applications and data once your cloud perimeter is breached, is to focus on a robust access and permissions management plan. This is because the cloud attack formula relies heavily on the abuse of privilege. Permissions are the thread tying together all your identities, cloud resources, services, accounts, environments, and most importantly, your data.
Abuse of privilege is how an attacker hops from one identity to the next, across accounts or clouds, all in search of the perfect combination of permissions that unlocks their plan.
To illustrate these concepts, we’ll review three ‘case study’ breaches and examine how the attacks were executed. There’s one major theme throughout them all (hint: every one relied on the abuse of cloud permissions and access to cause destruction.) We will also detail how proper cloud permission and access control, specifically a Cloud Infrastructure Entitlement Management (CIEM) solution, would have helped.
The Credential Compromise Attack
What happened
Just under 70,000 SendTech customers’ and contractors’ data was breached including names, emails, and credit card information. This resulted in a $10k compliance fine for improper storage of sensitive data, not to mention the brand damage that occurred.
How did the attack happen
An access key created in 2015 was untouched and unrotated in the six years leading up to the incident. It is suspected that the key was compromised via remote work in a public setting. Not only did current employees have broad access to this key, but all former developers still held access even after their departure from the company.
With this access key, the attacker gained administrative privilege. It is unclear whether the key directly offered admin privilege, or it was inherited through lateral movement. With this administrative privilege, the attacker was able to indirectly escalate their privilege and create another admin identity. With this additional identity they were able to query the AWS S3 buckets containing the customer and contractor PII. Source.
Analysis of permission and access abuse
To illustrate this attack better, we can reference the visual below. This attack path is almost entirely driven by the abuse of cloud privilege. The second the attacker gained entry via the compromised access key, they were able to make their way to the data through lateral movement and privilege escalation.
To detail how proper control of cloud permissions and access could have helped in this scenario we’ll walk through points 1-4. At point 1, a CIEM solution would have alerted to not only the existence of unused identities/ infrastructure belonging to the former developer employees, but also the unused permission to access the key by those entities. As 30, 60 days go by, this would trigger a least privilege policy violation. This would give teams the chance to not only clean up and remove those unused identities, but detach the policies granting them access to the credentials.
At point 2, a CIEM would alert to an overprivileged access key. It was alarming that gaining this access key offered the attacker admin level privilege. A CIEM would flag this and allow your team to certify or remediate this level of sensitive privilege.
At point 3, a CIEM would alert to a privilege escalation potential. One of CIEM solution’s greatest strengths is tying all the pieces together and illuminating attack paths to data. It would have alerted to the potential for an attacker to indirectly escalate their privileges by creating another admin identity (ultimately offering dangerous levels of access and power.)
Finally, at point 4, let’s say all of these preventative measures were missed, a CIEM would have alerted to anomalous activity (the querying of the S3 buckets.) CIEM continuously monitors for changes to permission usage or access to valuable resources. This could then trigger automatic bot incident response detaching the policy granting access, thereby isolating the bucket from all access, and even force ending the attacker’s session.
The Social Engineering Attack
What happened
MGM faced $100M in revenue loss due to total business disruption. They faced a ransom after their workloads were disrupted, assets were encrypted, and sensitive customer information (names, emails, even Social Security numbers) were breached.
How did the attack happen
The adversary targeted an MGM employee after doing recon on Linkedin and called the helpdesk impersonating the employee. The adversary manipulated the help desk into resetting the user’s multi-factor authentication, giving the attacker the user’s credentials and gaining entry into MGM’s on-prem systems. They had access to the IT management software Okta, where they created a new Identity Provider (IdP) using the inbound federation feature.
This compromise of MGM’s IAM platform was enough for the attack group to shut down the casino’s operations, but the attack persisted. From Okta they were able to federate into Azure, breaching the cloud. This federation gave them global admin access in Azure. With this privilege they could access sensitive cloud assets, encrypt them, execute their ransom, and disrupt cloud workloads. Source.
Analysis of permissions and access abuse
This example illustrates an important point; The human element is ever present and unfixable. We cannot control human error, and human-centered security will always be imperfect. This will lead to perimeter breaching. However, once MGM’s on-premises systems were compromised, this attack did not need to originate in the cloud to ultimately affect the cloud. The critical turning point was improper cloud access control and the abuse of inbound federation from Okta into Azure.
Once this breach stepped into the cloud, that is where a CIEM holds jurisdiction. Let’s break down the permission and access abuse:
At point 1, a CIEM would compute all possible attack paths to data via the global admin identity, and any potential pathways to assuming that global admin identity. With a CIEM, your teams are aware of every entity in your cloud with admin level privilege – whether explicitly assigned admins, or identities that inherit admin privilege more discreetly (a great danger.) A CIEM would alert to sensitive data access, a case of overprivileging or potential for lateral movement, all allowing the team to accept the risk or revoke the privilege to break the attack chain.
Really, this is largely a matter of prevention, as protecting admin privilege is of the utmost importance. Once an attacker gains admin privilege, they can essentially have their way with your cloud. If an attacker is smart, once they are an admin they can create a Global Policy that prevents them from having their permissions removed. This would make it so no incident response efforts are useful. It’s only speculative if that was the case in this MGM attack.
For the sake of point 2, let’s say again, none of these preventative measures worked, and the attacker did not protect their own privilege, then there is the detection and response feature of a CIEM. The anomalous activity including asset access, data exfiltration, or virtual machine disruption would be detected, teams alerted, and auto remediation or bots would respond to end the session.
The Vulnerability Attack
What happened
2 million customers’ data was breached, encrypted, and ONUS faced a $5M ransom demand. After the company refused payment, the data of 2 million customers was put up for sale online.
How did the attack happen
Threat actors successfully exploited the Log4Shell vulnerability on a Cyclos server within ONUS. Cyclos warned ONUS of the issue, and the vulnerability was patched, but it was too late. This vulnerability was on a sandbox server which hosted a misconfiguration allowing the attackers to access a file containing AWS credentials. These credentials offered full Amazon S3 access in a production environment, where the attackers could exfiltrate the data and demand ransom. Source.
Analysis of permissions and access abuse
This case exemplifies how permissions and access tie together the cloud. The attacker was able to move from a vulnerability in a sandbox server, to Amazon S3 in a production environment. A server compromise doesn’t need to translate into a data breach, but because of insecure access credentials and overprivileging, it did.
Taking a closer look, we can hone into point 1, where a CIEM would discover access keys and credentials that may be lost, forgotten about, or improperly stored in your environment. From there, they are computed into possible attack paths and how they could be used to move laterally. This could have given the team a chance to discover the key itself, remove unnecessary access, and reveal any dangerous attack paths.
At point 2, a CIEM would alert to how overprivileged the access keys were; it is unlikely the credentials needed such broad access to the S3 service – especially access that moved across environments. This gives the organization the opportunity to reduce the privilege associated with the key.
Finally, at point 3, if all of these preventative measures were insufficient, a CIEM would alert to the anomalous activity of exfiltrating the data in S3 to allow manual or bot incident response.
Focusing On Permissions to Protect Your Cloud
These three examples are just a few of the many ways threats enter the cloud. In these examples, multi-factor authentication, Privileged Access Management, Cloud Security Posture Management, and Vulnerability Management, were not enough to stop the perimeter from breach. Even with the best solutions in place protecting your perimeter, credentials are often stolen or sold, allowing attackers to simply log into your cloud. If we can’t stop attackers from getting in, why not focus on stripping them of the tool they weaponize to execute their attacks – privilege.
A cloud perimeter breach doesn’t need to turn into a data breach. With proper governance over privilege, identities can be protected at least privilege, and the attack paths starting at servers, workloads, on-prem entry or third parties can be broken, leaving attackers at dead ends.
You can watch this in action with a recorded demo of the Sonrai Platform.
