Hybrid Identities: The On-Prem to Cloud Connection
Everybody has packed their bags and moved to the cloud, or have they?
Not long ago, I read a post by Andy Robbins, “Like it or not: Active Directory is here to stay” and I totally agree with the sentiment we are not going to get rid of Active Directory any time soon That means we need to learn to live with it and the complexities it brings into our reality.
In this post, we’ll discuss why we should invest in hybrid identity security, and not just follow the current fashions and trends in the identity security realm, which are mainly cloud-focused nowadays.
In the era of identity-first security, organizations know they must protect their privileged identities, whether they are on-prem or in the cloud, from Domain Admins to Global administrators and Root accounts.
Initially, most organizations have (or will have) their passwords managed by a PAM solution, they will enforce MFA and they will continue to invest heavily in long-term projects around them. But there is still a gap.
What is missing, you ask? The answer is simple, a cloud privileged identity is not necessarily an on-prem privileged identity.
The on-prem connection Azure
Most organizations do not manage separate accounts for their Active Directory users and their Azure Active Directory users because Microsoft developed them to work as seamlessly as they could together.
Microsoft invested heavily in making the consumption of Azure related services as approachable as they could, and they offer integral synchronization mechanism between on-prem AD and Azure AD in the form of:
These of course also support hybrid authentication mechanisms:
- Azure AD password hash synchronization
- Azure AD pass-through authentication
- Federated authentication
The classic scenario is that hybrid identities have the same password for their on-prem AD user as they do for their synced Azure AD user.
Vertical movement is a term used to describe attackers’ movement from the on-prem plane to the cloud plane and vice versa.
So, what do we know so far:
- Azure admins are not necessarily AD admins
- We are most likely to encounter hybrid environments where the on-prem identity and the Azure identity use the same password for authentication
This means attackers will probably encounter on-prem users which are less monitored and less protected, but still have a synced privileged account in Azure.
If an attacker compromises the on-prem account, then they will able to move vertically to Azure and compromise the Azure tenant (this will probably also allow them to vertically move back to the on-prem domain and compromise it as well).
What about MFA?
There is a good chance a privileged Azure account will require MFA.
So even if an attacker compromises the password of the account, he will still have to satisfy the MFA requirement.
There are several methods by which attackers can bypass this security mechanism, one of them has to do with the notorious PRT (Primary Refresh Token).
Hybrid environments are very likely to also use hybrid-joined devices or at least Azure AD registered devices, both of them leverage primary refresh tokens for a smooth authentication experience and both can be used for MFA bypass.
Known PRT attacks to help with MFA bypass:
- Pass the PRT
- Leveraging the PRT on a compromised endpoint for Azure AD related authentication
ACME ltd. Is a very security-oriented organization.
ACME utilizes a hybrid Azure environment.
The on-prem AD is synced to the Azure AD via Azure AD connect and utilizes password hash sync for authentication.
They utilize a PAM solution to protect their on-prem admin accounts and they enforce MFA for all of their Azure privileged accounts.
John[@]acme.com is a regular domain user in the ACME on-prem domain- therefore he is not managed by PAM.
John’s Azure alter ego has the Application Administrator role.
Assuming an attacker compromises John device and gets a hold of his credentials, he could use his Azure Identity to add secrets to existing permissive applications and use their permissions as he pleases, you can read a detailed explanation about this azure service principal abuse scenario in this detailed blog post by Andy Robins.
The on-prem connection: AWS
AWS admins are even less likely to have an on-prem admin role and thus have a better chance of falling between the cracks.
AWS admin identities could be pivoted in several ways:
- Saved credentials to high value Cloud assets
- AWS CLI credentials
- Password reuse
- Using ADFS for authentication
Mike[@]acme.com is a regular domain user in the ACME on-prem domain.
Mike is part of ACME’s DevOps group, and he has permission to access every EC2 instance in the AWS account.
Mike uses AWS CLI a lot and he has an Access key and a matching Secret saved in the local AWS CLI config file.
An attacker compromising Mike’s Identity could get a foothold on his device and find the AWS keys.
Once he gets the keys, he can use them to move to any EC2 Instance in the account, where he could potentially find other means to spread within the account.
While designing our identity security strategy we must not forget we are in a hybrid world, and it has consequences we must face. A side effect of cloud migration is that attacks can move vertically to the cloud.
Hybrid Identities connect the different platforms we circle around, and the on-prem is what connects them all together.
Protecting the cloud is important, but don’t forget identities are usually hybrid.