Abusing FIDO2 passkeys to take over Global Administrators in Entra ID
FIDO2 passkeys are a step forward for securely managing identities. But they can also be abused. Senior security specialist Max Rozendaal explains how attackers do this, and what you can do to mitigate this issue.
... > Vulnerability Assessment / Penetration Testing (VAPT) > The keys to the kingdom: how attackers can use FIDO2 passkeys against you
The keys to the kingdom: how attackers can use FIDO2 passkeys against you
FIDO2 passkeys are a new form of passwordless authentication that use public-key cryptography to provide strong, phishing-resistant authentication. Instead of using a traditional password, users authenticate with a FIDO2 passkey, which is a cryptographic credential stored on a security device like a security key or a mobile phone.
While passwordless authentication and passkeys are certainly a step forward towards a more secure way of managing identities, their functionality can also be abused if they end up in the wrong hands. Microsoft has recently published a Graph API that allows administrators to pre-provision passkeys for users. From an offensive security point of view this raises the question whether this functionality can be abused to take over accounts.
In this article we will dive into a new technique for abusing the FIDO2 Passkey provisioning API and the associated required Graph permissions. This builds upon previous research into dangerous Graph API permissions granted to applications and the possibility to take over those applications.
After reading this article you will know:
1. How attackers can abuse service principal permissions to add FIDO2 passkeys as additional authentication method to compromise highly-privileged accounts.
2. How to detect and mitigate unauthorized FIDO2 provisioning and secure Global Administrator accounts in Microsoft Entra environments.
About the author
Max Rozendaal
Max Rozendaal is a senior security specialist in Secura's Public marketgroup. He specializes in performing Ransomware Resilience Assessments, simulating the entire kill chain ransomware operators typically execute. Max is an expert on hybrid Entra ID and Active Directory environments.
How attackers can abuse FIDO2 passkeys
Microsoft has released the Microsoft Entra ID FIDO2 provisioning APIs in public preview. The 'Create fido2AuthenticationMethod' can be used to pre-provision a FIDO2 passkey as an authentication method for a user. The API method submits a POST request to https://graph.microsoft.com/beta/users/{id}/authentication/fido2Methods.
According to the documentation at Create fido2AuthenticationMethod, programmatically provisioning FIDO2 passkeys requires the 'UserAuthenticationMethod.ReadWrite.All' permission in an app-only access scenario. This permission is described at Graph Permissions Reference and does not include a caution against possible escalation of privilege or account takeover.
The provisioning of a passkey on behalf of a user requires three steps:
Source: Microsoft
Microsoft has announced that vendors of FIDO2 security keys are actively working on creating Microsoft Entra ID applications to help organizations with (pre-)provisioning and adopting FIDO2 security keys. This means that in the future we will likely see an increase in the amount of Azure tenants which contain service principals with the 'UserAuthenticationMethod.ReadWrite.All' application permission and passkeys enabled as an authentication method.
From previous research we already know that the application permission 'UserAuthenticationMethod.ReadWrite.All' creates an attack path that can lead to compromise of accounts with the Global Administrator role. This attack path abuses Temporary Access Passes (TAP) and was detailed in the blog post I'd TAP that pass by SpecterOps. One of the requirements for this attack path is that TAPs are enabled in the tenant, which is not always the case.
The new FIDO2 provisioning API opens up an interesting attack path when an attacker is able to provision a new FIDO2 passkey for a user with the Global Administrator role. This requires FIDO2 passkeys to be enabled in the target tenant, which we will likely see more and more as stronger authentication methods are adopted.
If the attacker has control over a service principal with the 'UserAuthenticationMethod.ReadWrite.All' permission, they can bypass the requirement for the user's plaintext password by provisioning a FIDO2 security key for a Global Administrator. This effectively allows the attacker to escalate their privileges and take over the Global Administrator account, as the FIDO2 passkey can be used without knowledge of the plaintext password and satisfies the strongest MFA requirements.
To summarize, the new attack path is as following:
- An attacker with the Application Administrator role can add a new client secret or certificate to a service principal with the 'UserAuthenticationMethod.ReadWrite.All' permission.
- Using the new client secret or certificate, the attacker can authenticate as the application and invoke the 'Create fido2AuthenticationMethod' API to provision a FIDO2 Passkey for a user with the Global Administrator role.
- The attacker can then use the provisioned FIDO2 Passkey to sign in to Azure services, bypassing the need for the user's plaintext password and satisfying the strongest MFA requirements.
Proof of concept
This proof of concept assumes that an attacker has already compromised an application in the target tenant with the 'UserAuthenticationMethod.ReadWrite.All' application permission, for example through the Entra Connect Sync account (see Compromising Azure cloud through sensitive API permissions) or a compromised account with the Application Administrator role. It is assumed that the attacker can authenticate to the Microsoft Graph API with either a client secret or compromised access token.
Let's go through the steps.
1) First, the attacker needs to authenticate to the Microsoft Graph API as the application holding the 'UserAuthenticationMethod.ReadWrite.All' permission with the previously compromised client secret or access token, in this proof of concept the Microsoft Graph PowerShell SDK will be used:
2) Next, the attacker needs to request the FIDO2 security key creation options. This can be done with the DSInternals.Passkeys module. This will issue a GET request to the Graph endpoint https://graph.microsoft.com/beta/users/{user_object_id}/authentication/fido2Methods/creationOptions:
The returned creation options contain a challenge and other options which are required to create a credential on the security key.
3) The credential can be created on the security key through the WebAuthN API, which the DSInternals.Passkeys module conveniently provides us with a method for. Calling the 'New-PassKey' method with the received creation options kicks off the WebAuthN flow:
4) After confirming the prompts and entering the security key PIN a new credential has been created on the key:
5) This newly created credential can then be used to register the security key to the user account in Entra ID. Registering a new security key to a user can be done with a POST request to https://graph.microsoft.com/beta/users/{user_object_id}/authentication/fido2Methods. The DSInternals.Passkeys module provides the 'Register-PassKey' method to register the newly created credential:
6) With the FIDO2 passkey successfully provisioned for the Global Administrator user, the attacker can now authenticate as that user without needing the plaintext password, effectively escalating their privileges:
How to detect this attack
After provisioning the new FIDO2 security key, the Audit logs in the Microsoft Entra admin center at Users | Audit logs shows the following events:
Organizations can use the "User registered security info" and "Add Passkey (device-bound)" audit log events to monitor for unauthorized FIDO2 security keys being added to highly privileged accounts.
How to mitigate this attack path
Mitigating this attack path is not an easy task for organizations as they adopt FIDO2 security keys to provide users with an easier and more secure way for accessing (cloud) resources. Organizations should carefully review their Azure tenants for applications with application permissions that are known to provide attackers with opportunities for privilege escalation such as:
- 'UserAuthenticationMethod.ReadWrite.All'
- 'RoleManagement.ReadWrite.Directory'
- 'AppRoleAssignment.ReadWrite.All'
For organizations that are implementing applications to help with pre-provisioning FIDO2 security keys, delegated permissions should be considered over application permissions. In the delegated access scenario, the user who is signed into the application must also be authorized to perform the action on the target user:
Source: Microsoft
In the delegated access scenario, an attacker would need to compromise an identity that is allowed to provision a new FIDO2 security key for an user with the Global Administrator role. This is limited to other users with the Global Administrator role or the Privileged Authentication Administrator.
Lastly, organizations can restrict the type of security keys that can be registered to accounts. By selecting the option "Enforce key restrictions" under the "Passkey (FIDO2)" method in the Microsoft Entra admin center and entering specific FIDO2 Authenticator Attestation GUIDs (AAGUID), administrators can select the specific types of FIDO2 security key that can be registered. Every FIDO2 security key model has an AAGUID, and by restricting the allowed FIDO2 security keys an extra hurdle is put up for attacker, since they cannot just register any FIDO2 security to highly privileged accounts.
Organizations should also actively monitor the registered authentication methods for accounts with highly privileged roles such as the Global Administrator role or the Privileged Authentication Administrator role. This is especially true for break-glass accounts which are not often used.
Conclusion
We already knew that the application permission 'UserAuthenticationMethod.ReadWrite.All' allowed escalation of privileges to the Global Administrator role in Entra ID under certain conditions. This discovered attack path adds to the risk this application permission poses to tenants. As FIDO2 security key manufacturers are building applications to help organizations with the (pre-)provisioning and adoption of FIDO2 security keys, we are likely to see an increase in Azure tenants that have one or more application registrations with this application permission.
If one application in your Azure tenant has been granted this permission, your whole environment is at risk for compromise. This is something to really look out for when you are configuring FIDO2 passkeys for your environment.
Resources
Further information on attack paths and passkeys in Entra ID can be found in the following (non-limitative) list of resources:
Contact us
Want to know how we can help you strengthen your cloud security? Fill out the form and we will contact you within one business day.
Why choose Secura | Bureau Veritas
At Secura/Bureau Veritas, we are dedicated to being your trusted partner in cybersecurity. We go beyond quick fixes and isolated services. Our integrated approach makes sure that every aspect of your company or organization is cyber resilient, from your technology to your processes and your people.
Secura is the cybersecurity division of Bureau Veritas, specialized in testing, inspection and certification. Bureau Veritas was founded in 1828, has over 80.000 employees and is active in 140 countries.