Hackfest 2020

Session's objectives
1. Understand Azure better – its IAM and permissions architecture
2. Learn on the new threat of Azure and AWS Shadow Admins
3. Get recommendations and a free open-source tool for mitigation

Nowadays, cloud technologies are everywhere, and specifically, Microsoft’s Azure cloud is gaining more and more popularity. Many companies use the different Azure services and rely on the Azure AD as part of their Office 365 solution. With that increasing adoption, the risk of having Shadow Admins grows as well. We at CyberArk Labs researched Azure cloud and its permission architecture and discovered 10 specific privilege escalation techniques. In the session, we will present the research and how users that seem to have limited privileges at first glance, can actually impersonate and take control of other users that have full Azure admin rights. We called those kinds of unintended privileged users, Shadow Admins. They aren’t full admins at first, but they control other existing admins and can take action on their behalf. The session will also include two demos to present Shadow Admins abuse and actionable mitigation takeaways. In addition we will present a previous research we did on Shadow Admins in AWS environment.
Examples for Shadow Admins are:
Azure applications can have dedicated Azure permissions. Users who manage the applications can be assigned with the Application Administrator Role in Azure AD. This role is considered to be “limited” and has only the permissions to manage applications. But in fact, it can be used to escalate privileges by taking control over a more permissive application or by registering a new malicious application with privileged permissions that the user didn’t have initially.
Another example is a user with only one single permission: “Microsoft.Authorization/roleAssignments/write”. With this sole permission, a user can assign itself the all 5,000 available permissions in Azure RBAC mechanism.
And what about a user who is the OWNER (not a member) of privileged AAD group? It’s also a privileged user as well. It doesn’t matter if this user has other permissions at all or if it’s currently a member in this group. Because at any moment, this user can add itself to that admins group and become an admin.
Attackers can also create their own Shadow Admins as part of their persistence efforts.
In the past, we researched Shadow Admins in on-premises domain networks, and at RSA USA 2018 we presented Shadow Admins in AWS.
The research we did on AD Domain Shadow Admins included a blog post and a tool “ACLight”:
https://www.cyberark.com/threat-research-blog/shadow-admins-stealthy-accounts-fear/
https://github.com/cyberark/ACLight
The research we did on AWS Shadow Admins also included a summary post and a new scanning tool “SkyArk”:
https://www.cyberark.com/threat-research-blog/cloud-shadow-admin-threat-10-permissions-protect/
https://github.com/cyberark/SkyArk
As part of this Azure research, we’re going to add a new scanning module for targeting this risk of Azure Shadow Admins. The scan is called AzureStealth, and it’s part of the free open-source SkyArk.
Organizations worldwide should discover, identify those admins, and make sure they are well secured.
We published our last Azure research here:
https://www.cyberark.com/resources/threat-research-blog/diy-hunting-azure-shadow-admins-like-never-before-2