Backdooring and hijacking Azure AD accounts by abusing
external identities
Dirk-jan Mollema / @_dirkjan
#BHUSA @BlackHatEvents
whoami
- Dirk-jan Mollema
- Lives in The Netherlands
- Hacker / Researcher / Founder @ Outsider Security
- Author of several (Azure) Active Directory tools
- mitm6
- ldapdomaindump
- BloodHound.py
- aclpwn.py
- Co-author of ntlmrelayx
- ROADtools
- Blogs on dirkjanm.io
- Tweets stuff on @_dirkjan
#BHUSA @BlackHatEvents
Information Classification: General
Terminology
• Azure AD
• Identity platform for Office 365, Azure Resource Manager, and other
Azure things
• Also identity platform for any first/third party app you want to integrate
with it
• This is not about Azure infrastructure/VMs/etc
#BHUSA @BlackHatEvents
Information Classification: General
Terminology
• Tenant
• A separate instance of Azure AD for an organization.
• Most organizations have one primary tenant.
• Important security boundary in Azure AD.
• Identified by a GUID
• Identified by at least a tenantname.onmicrosoft.com domain
• Usually also identified by custom domains
#BHUSA @BlackHatEvents
Information Classification: General
Terminology
• External identity
• Any identity that is not managed by your tenant
• Can be another Azure AD tenant, Microsoft account, Google account or
even just an email address.
#BHUSA @BlackHatEvents
Information Classification: General
External collaboration
Tenant A Tenant B
#BHUSA @BlackHatEvents
Information Classification: General
External collaboration
Guest account Linked Home tenant account
Tenant A Tenant B
Resource tenant Home tenant
#BHUSA @BlackHatEvents
Information Classification: General
Research questions
• How does the invite flow work?
• How are accounts linked to a different tenant?
• What possibilities are there to abuse this?
#BHUSA @BlackHatEvents
Information Classification: General
Test setup
• 2 tenants:
• Primary: Iminyour.cloud (iminyourcloud.onmicrosoft.com)
• External: Crosstenantdev (crosstenantdev.onmicrosoft.com)
• No specific B2B trust configured
• All Azure AD defaults
#BHUSA @BlackHatEvents
Information Classification: General
#BHUSA @BlackHatEvents
Information Classification: General
#BHUSA @BlackHatEvents
Information Classification: General
#BHUSA @BlackHatEvents
Information Classification: General
#BHUSA @BlackHatEvents
Information Classification: General
Azure AD information resources
• Microsoft Graph
• Official API for everything Microsoft 365 (including Azure AD)
• Not always all information
• Azure AD graph
• Azure AD only
• Lower-level API than MS Graph
• Possibility to use internal versions to gather more information
• Azure AD portal
• May use MS Graph or AAD Graph, including internal versions
#BHUSA @BlackHatEvents
Information Classification: General
In this talk
• Mix of AAD Graph and MS Graph
• Use of ROADrecon (part of ROADtools) as front-end for AAD
Graph
#BHUSA @BlackHatEvents
Information Classification: General
Invite acceptance, audit log
#BHUSA @BlackHatEvents
Information Classification: General
Guest account – after acceptance
#BHUSA @BlackHatEvents
Information Classification: General
Link is based on “netid” property in home tenant
#BHUSA @BlackHatEvents
Information Classification: General
Linking guest accounts between tenants
Guest account Home tenant account
alternativeSecurityIds netid
Tenant A Tenant B
Resource tenant Home tenant
#BHUSA @BlackHatEvents
Information Classification: General
Inviting users using the AAD Graph
https://github.com/projectKudu/ARMClient/wiki/AAD-Invite-User-Apis
#BHUSA @BlackHatEvents
Information Classification: General
Redeem invite via AAD Graph
• Needs external users netid
• Can be queried using AAD Graph
• Can be extracted from access token (puid claim)
• Need invite ticket
• Can be queried using AAD Graph / ROADrecon ☺
#BHUSA @BlackHatEvents
Information Classification: General
Redeem invite via API
#BHUSA @BlackHatEvents
Information Classification: General
Redeeming invites: some issues
• You would think some privileged role is needed to redeem
invites, this is not true, any user in the tenant can do it.
• None of the information is verified:
• Could use any “accepted as” email
• Could link it to any external account in any directory
• Invite tickets can be queried by any user in the tenant
#BHUSA @BlackHatEvents
Information Classification: General
Hijacking invites
• Query using AAD Graph:
https://graph.windows.net/myorganization/users?api-version=1.61-internal&$filter=userState eq
'PendingAcceptance'&$select=userPrincipalName,inviteTicket,userType,invitedAsMail
#BHUSA @BlackHatEvents
Information Classification: General
Query netid from rogue account
https://graph.windows.net/myorganization/users/[email protected]/?api-version=1.61-
internal&$select=userPrincipalName,netId
#BHUSA @BlackHatEvents
Information Classification: General
Redeem invite POST response
#BHUSA @BlackHatEvents
Information Classification: General
#BHUSA @BlackHatEvents
Information Classification: General
No way to determine actual account link
#BHUSA @BlackHatEvents
Information Classification: General
TL;DR
• Every user could query for non-redeemed invites.
• Could redeem invite without any validation, link to arbitrary
external account.
• No way for admins to find out which account it was actually
linked to.
#BHUSA @BlackHatEvents
Information Classification: General
Impact scenarios
• External identities often used for managing Azure subscriptions
in other tenants.
• Used for external suppliers/MSP accounts.
• Leaving employee could add guest account to retain access.
• UI flow exists to directly assign role to invited account, could be
a privilege escalation.
• Bypasses allowlist of external collaboration domains.
#BHUSA @BlackHatEvents
Information Classification: General
Hunting for abuse
#BHUSA @BlackHatEvents
Information Classification: General
AuditLogs
| where OperationName =~ "Update user"
| where Result =~ "success" Hunting query
| mv-expand target = TargetResources
| where tostring(InitiatedBy.user.userPrincipalName) has "@" or
tostring(InitiatedBy.app.displayName) has "@"
| extend targetUPN = tostring(TargetResources[0].userPrincipalName)
| extend targetId = tostring(TargetResources[0].id)
| extend targetType = tostring(TargetResources[0].type)
| extend modifiedProps = TargetResources[0].modifiedProperties
| extend initiatedUser = tostring(InitiatedBy.user.userPrincipalName)
| mv-expand modifiedProps
| where modifiedProps.displayName =~ "UserState"
| mv-expand AdditionalDetails
| where AdditionalDetails.key =~ "UserType" and AdditionalDetails.value =~ "Guest"
| extend new_value_set = parse_json(tostring(modifiedProps.newValue))
| extend old_value_set = parse_json(tostring(modifiedProps.oldValue))
| where new_value_set[0] =~ "Accepted" and old_value_set[0] =~ "PendingAcceptance"
| project-away old_value_set, new_value_set, modifiedProps
Copy/paste version: https://gist.github.com/dirkjanm/
#BHUSA @BlackHatEvents
Information Classification: General
External identities in MS Graph
• MS Graph shows less information than AAD Graph
• “identities” property can actually be modified with correct privs
https://graph.microsoft.com/beta/users/cd3a4c74-64ca-42b4-9448-601cabad969a/identities
#BHUSA @BlackHatEvents
Information Classification: General
Other identity providers
#BHUSA @BlackHatEvents
Information Classification: General
Email OTP in MS Graph and AAD Graph
AAD Graph
MS Graph
#BHUSA @BlackHatEvents
Information Classification: General
Who can modify the identities attribute?
• Global Admins
• User Administrators
• Apps with User.ManageIdentities.All privileges
• Users can modify their own identities
#BHUSA @BlackHatEvents
Information Classification: General
Azure AD “Users” Role Definition
#BHUSA @BlackHatEvents
Information Classification: General
Users modify their own identities
Given a time-limited or scope-limited access token with the
correct MS Graph permissions, attackers can backdoor an
account and link it to an external account.
#BHUSA @BlackHatEvents
Information Classification: General
Attack scenario’s
• Temporary account access
• Limited scope access, for example through device code
phishing
• Application takeover or URL hijack with the appropriate scope
#BHUSA @BlackHatEvents
Information Classification: General
Account identities: original
#BHUSA @BlackHatEvents
Information Classification: General
#BHUSA @BlackHatEvents
Information Classification: General
Add new identity (backdoor)
#BHUSA @BlackHatEvents
Information Classification: General
Account identities after change
#BHUSA @BlackHatEvents
Information Classification: General
Switching tenants
#BHUSA @BlackHatEvents
Information Classification: General
Signed in as victim user
#BHUSA @BlackHatEvents
Information Classification: General
Returning the account to the original state
#BHUSA @BlackHatEvents
Information Classification: General
Extra technique: elevation of privilege
• User Administrators cannot reset passwords of Global
Administrators
• They can however modify the identity of a Global Admin (or any
other user)
• This way they can take over the account of a higher privileged
user.
#BHUSA @BlackHatEvents
Information Classification: General
User Admin to Global Admin with a few clicks
• Convert existing user to B2B account (Guest)
#BHUSA @BlackHatEvents
Information Classification: General
Victim user
#BHUSA @BlackHatEvents
Information Classification: General
#BHUSA @BlackHatEvents
Information Classification: General
#BHUSA @BlackHatEvents
Information Classification: General
#BHUSA @BlackHatEvents
Information Classification: General
User Administrator privesc TL;DR
• A User Administrator can convert any account to B2B, including
higher privileged accounts.
• Can be done in GUI or with 2 simple POST requests to MS
Graph.
• No need to redeem the invite with a real account if we combine
this with the guest account hijack technique, making it fully
invisible which account it was linked to.
• For some reason does not work for accounts with a mailbox, in
which case changing the “identities” property works.
#BHUSA @BlackHatEvents
Information Classification: General
The caveat: MFA
• Converting a user to B2B or changing their identities will
compromise their primary authentication method only.
• MFA will still kick in for the original account.
#BHUSA @BlackHatEvents
Information Classification: General
Guest tenants and MFA
Victim account Attacker account
MFA methods MFA methods
Tenant A Tenant B
Resource tenant Home tenant
(attacker controlled)
#BHUSA @BlackHatEvents
Information Classification: General
MFA methods remain those of victim account
Linked
Guest account Attacker account
Victim MFA methods MFA methods
Tenant A Tenant B
Resource tenant Home tenant
(attacker controlled)
#BHUSA @BlackHatEvents
Information Classification: General
Observations
• In a fresh sign-in session where MFA was performed, we are not
prompted for MFA every time we switch apps. Suggests caching
in login session.
• This holds for activity in tenants where we are a guest too.
• Conclusion: MFA information is cached somehow in our session,
and keeps track of which tenants we performed MFA in.
#BHUSA @BlackHatEvents
Information Classification: General
Introducing account rebinding
Victim account Attacker account
Victim MFA methods MFA methods
Tenant A Tenant B
Resource tenant Home tenant
(attacker controlled)
#BHUSA @BlackHatEvents
Information Classification: General
Invite attacker as guest
Attacker guest account
Attacker MFA methods
Linked
Attacker account
Victim account MFA methods
Victim MFA methods
Tenant A Tenant B
Resource tenant Home tenant
(attacker controlled)
#BHUSA @BlackHatEvents
Information Classification: General
Delete guest account
Attacker guest account
Attacker MFA methods
Attacker account
Victim account MFA methods
Victim MFA methods
Tenant A Tenant B
Resource tenant Home tenant
(attacker controlled)
#BHUSA @BlackHatEvents
Information Classification: General
Rebind victim account to attacker identity
Attacker guest account
Attacker MFA methods
Linked Attacker account
Victim account MFA methods
Victim MFA methods
Tenant A Tenant B
Resource tenant Home tenant
(attacker controlled)
#BHUSA @BlackHatEvents
Information Classification: General
Video demo
#BHUSA @BlackHatEvents
Information Classification: General
Add own MFA method to make bypass
permanent
#BHUSA @BlackHatEvents
Information Classification: General
Attack summary
• MFA information seems cached in the session based on home
tenant identity + target tenant combination.
• No link to the actual account, makes it possible to:
• Invite a guest account on attacker's email address.
• Register MFA information (will be cached in session)
• Delete the guest account by leaving the organization.
• Link the victim account to the attackers account (either B2B link or via
Email OTP).
• Attacker can now log in as victim, including MFA claim, and add their
own MFA app.
#BHUSA @BlackHatEvents
Information Classification: General
Attack scenarios and impact
• With limited account access (such as access token):
• Convert into full persistent access, including MFA
• With only access to the account password:
• Bypass MFA and Conditional Access if MFA is not required for all
apps/locations.
• With a user administrator:
• Elevate privileges to Global Admin, including MFA bypass.
• Bypass MFA for any other account in the tenant.
#BHUSA @BlackHatEvents
Information Classification: General
Fix status
• TBD
#BHUSA @BlackHatEvents
Information Classification: General
Actions for defenders
• Remove guest accounts with unredeemed invites regularly.
• Lock down guest invite rights and guest access settings in Azure
AD.
• Hunt in your Audit logs for possible abuse of guest accounts.
• Ask yourself how you could know which account a guest
account is actually linked to with the information visible in Azure.
• Enforce MFA across all apps instead of selectively.
Hunting query at https://gist.github.com/dirkjanm/
#BHUSA @BlackHatEvents
Information Classification: General
Backdooring and hijacking Azure AD accounts by abusing
external identities
Dirk-jan Mollema / @_dirkjan
Questions:
[email protected] #BHUSA @BlackHatEvents
