It’s been common knowledge for years that local Windows Active Directory networks are vulnerable to NTLM relay and pass-the-hash attacks that can allow attackers to move laterally through networks and access additional machines and resources. Since some of these attacks exploit design decisions in the authentication protocols used inside Windows networks, they cannot be simply patched by Microsoft with changes in software. Organizations need to take defense-in-depth measures that involve stricter configurations and additional controls to protect themselves.
With the adoption of hybrid networks, where parts of the networks are local and parts are in the cloud, enterprises now rely on services such as Azure Active Directory (Azure AD) to allow its various machines to authenticate to each other. But Azure AD is quite different from local AD as it uses different protocols and has new features that expand the networking possibilities of organizations. However, according to presentations last month at the Black Hat USA security conference, it also offers new possibilities for attackers.
From pass-the-hash to pass-the-certificate
Pass-the-hash is an attack that involves hackers extracting hashed versions of locally stored credentials from a compromised machine and using them to authenticate to other machines. NTLM relay is a method that involves intercepting authentication requests between a client and a server and relaying the challenges and responses between the two so that the attacker gets authenticated instead of the client. These attack methods are commonly used by sophisticated hacker groups in targeted attacks.
In Azure AD, however, traditional pass-the-hash and relay attacks don’t work because Azure AD doesn’t use NTLM or Kerberos, which are the standard authentication protocols on Windows networks. Instead, it uses OAuth, SAML, OpenID and a new protocol called NegoEx, which is an extension of the standardized Generic Security Services Application Program Interface (GSSAPI) that Kerberos is based on.
According to Microsoft researcher Mor Rubin, NegoEx will be enabled on any device that is joined to Azure AD and is the mechanism through which different Azure AD joined devices will authenticate to each other. The NegoEx authentication handshake relies on a client certificate that is unique for each user and is issued by Azure AD with a validity of one hour.
At Black Hat, Rubin demonstrated how a relay attack can be performed successfully on the NegoEx handshake, in a similar way in which it can be performed against NTLM. He then showed how an attacker can obtain the peer-to-peer client certificate using a similar method and then use that certificate to authenticate to other machines. In other words, these are equivalents of NTML relay and pass-the-hash, but in the context of Azure AD joined devices despite the difference in protocols used.
He also suggested that companies monitor their logs on Azure AD machines for authentication requests coming from client names with IP addresses that don’t match or for authentication requests via certificates issued to users that are not associated with the machines the requests are coming for. Rubin’s presentation was the culmination of research he started last year and also included the release of an open-source NegoEx relay tool called Negoexrelayx.
Abusing external identities in Azure Active Directory
In a separate Black Hat presentation that highlighted Azure AD-only threats that don’t exist in local Active Directory deployment, Dutch researcher Dirk-jan Mollema of Outsider Security demonstrated how he found a way to abuse the external identities feature to backdoor Azure AD accounts.
External identities are a feature of Azure AD where organizations can give external users access to certain resources. These users can be part of a different Azure AD tenant or can be authenticated through an external identity provider and identified only through an email address. This functionality is popular for organizations that work with external contractors, as well as for granting access to managed services providers that manage subscriptions.
External users can be invited by someone with admin privileges through the Azure AD interface and this will cause an invite link to be generated that will be sent by email to the external user. The problem, Mollema found, is that invites could also be generated and accepted programmatically through the Azure AD’s API called the AAD Graph.
Moreover, it turned out that when interacting with this feature through the API, not many checks were performed. First, any user inside the Azure AD tenant could query the API and see the invites that hadn’t yet been claimed. Second, any invite could be redeemed through the API without any validation and could be linked to a different external account than the one intended for. Third, admins had no way to tell that an invite was hijacked through the interface.
The attack would also bypass the list of domain names allowed for external collaboration in the Azure AD tenant because the invite could be generated for an email address on one domain, but then be hijacked and linked to an account in a non-whitelisted domain. Furthermore, there can be automated rules in place to give an account that redeems a certain invite automated privileges, leading to privilege escalation.
Mollema took the attack even further. By analyzing how the external identities looked in Microsoft Graph, a Microsoft API for developers, instead of the AAD Graph, he realized that some of the properties associated with an identity could be modified via the MS Graph given the correct privileges. One of these attributes is the issuer property that defines the identity provider and one of the options available is simply “mail.” This is used for external users that are only identified by email and don’t yet have a Microsoft or Azure AD account.
He then looked at who can modify these attributes and found that in addition to administrators, applications that users sign into and have the right privileges can also modify identities and users can modify their own identity through the MS graph. This opened the door to interesting attacks such as backdooring existing accounts if an attacker gains temporary access to them by stealing an access token or gaining temporary control over a computer where they have an active session.
Furthermore, if the account happens to be a users administrator, they could backdoor all accounts by adding external identities to them and linking them to email addresses under the attackers’ control. They could also do this for global administrators since they have the permission to modify their identities through the MS Graph.
The issue with this is that modifying an identity in this way only changes their primary authentication method, from a username and password to authentication via an external email. However, if the account also has multi-factor authentication (MFA) configured, the attacker still wouldn’t be able to log in.
Mollema found a bypass for this, too. First, he used the temporarily compromised victim account to generate an invite for the attacker’s external account. The attacker then accepted the invite, which resulted in a guest account being created for him in the victim’s tenant. The attacker then logged into the guest account and set up MFA for it.
Then using the victim account, he deleted the guest account. While this deletes the guest account that’s associated with the attacker’s external account, it doesn’t clear the MFA token, which is cached. So, the attacker’s external account continues to have an active MFA token in the victim’s Azure AD tenant even though the associated guest account is now gone. The attacker can then backdoor the victim’s account and add his external account as an identity and then he will no longer be prompted for MFA authentication. This bypasses the victim’s MFA protection.
Mitigating Azure AD and other cloud authentication vulnerabilities
Microsoft already fixed most of the issues that Mollema discovered, so the attacks he described no longer work. However, his findings show how complex authentication can be in the new cloud environments. The introduction of new features like allowing email OTP as an identity provider or external identities can always result in logic flaws that could enable bypasses.
Mollema advises organizations to remove all guest accounts with unredeemed invites regularly, lock down guest invite rights and guest access settings, restrict the tenants allowed for external collaboration, enforce MFA across all apps, and hunt access logs for signs of possible abuse of guest accounts.
Copyright © 2022 IDG Communications, Inc.
