This opens Azure Active Directory to new authentication risks

It has been widely known for years that local Windows Active Directory networks are vulnerable to so-called NTLM relay (New Technology Lan Manager) and hash pass attacks that can allow attackers to move laterally within networks and gain access to more devices and resources.

Because some of these attacks exploit design trade-offs in the protocols used in Windows networking, they simply cannot be safely fixed with updated software. To protect themselves, organizations need to implement deeper defense and measures that include tighter configurations and more controls.

With the adoption of hybrid networks, where parts of the network are on premises and other parts are in the cloud, companies need to rely on services such as Azure Active Directory (Azure AD) to enable different devices to authenticate with each other. However, Azure AD is quite different compared to on-premises AD because it uses different protocols and comes with new features that extend network capabilities for organizations. But according to several presentations at last year’s Black Hat USA security conference, this also opens up new opportunities for attackers.

From passing hash to passing certificate

Pass-the-hash is an attack where hackers extract hashed versions of locally stored credentials from compromised devices and use them to authenticate to other devices. NTLM relay is a method in which you relay authentication requests between a client and a server and forward messages between the two parties so that the attacker is authenticated instead of the client. Sophisticated hacker groups often use these attack methods in targeted attacks.

However, traditional hash and paging pass-through attacks will not work against Azure AD because Azure AD does not use NTLM or Kerberos – the default protocols used when authenticating on Windows networks – but Azure AD uses OAuth, SAML, OpenID and a new protocol called NegoEx which in turn is an extension of the protocol Unified Common Security Services Application Program Interface (GSSAPI) on which Kerberos relies.

According to Microsoft researcher Mor Rubin, NagoEx will be enabled on all Azure AD connected devices and is the mechanism by which different Azure AD connected devices authenticate each other. The authentication handshake in NegoEx is based on a client certificate that is unique to each user and is issued by Azure AD with a one-hour validity.

During the Black Hat conference, Rubin showed how a relay attack could be performed against a NegoEx handshake in a similar way as it could be done against NTLM. Then show how an attacker can obtain a peer-to-peer client certificate and then use that certificate to authenticate to other devices. In other words, these attacks are equivalent to NTLM, paging, and hash-pass attacks, but in the context of Azure AD-bound devices regardless of the differences in the protocols used.

Rubin suggests that companies check the logs on their Azure AD devices for authentication requests from clients whose names and IP addresses do not match, or for authentication requests via certificates issued to users not associated with the device making the request. Rubin’s presentation was the culmination of research he began last year and was also the first demonstration of the tool negoexrelayxwhich is a migration tool for NegoEx under an open source license.

Leverage external identities in Azure AD

In another presentation during a Black Hat conference focused on specific Azure AD attacks not found on on-premises AD facilities, Dutch researcher Dirk-Jan Mollema of Outsider Security explained how he I found a way to exploit the feature with external identities To create a backdoor for Azure AD accounts.

External identities are a feature of Azure AD that organizations can use to grant external users access to certain resources. These users may belong to a different part of Azure AD or they may be authenticated by an external provider and identified only by an email address. This feature is popular among organizations that work with third-party consultants but also provides access to IT service providers who manage subscriptions.

External users can be invited by someone with admin rights through the Azure AD interface and this creates an invite link that is emailed to the external user. Mollema found that the problem was that invitations could be created and accepted programmatically through the Azure AD API called AAD Graph.

It also appears that not many checks are made when interacting with this function through the API. First, any user within the Azure AD department can query the API and see which invitations have not yet been retrieved, and second, any invitation can be retrieved through the API without any validation and can be associated with a different external account than the intended one. Third, the administrators had no way of determining whether the invitation was compromised through the interface.

The attack was also able to circumvent the list of allowed domains for external collaboration in the Azure AD department because the invitation could be created for an email address within a domain, but then it was hijacked and associated with an account that wasn’t on the list. As an added bonus, there may be automatic rules that automatically award an account that redeems a higher privilege level invitation, resulting in privilege escalation.

Mollema then took the attack a step further. By analyzing how external identities appear in the Microsoft Graph – an API for developers – rather than the AAD Graph, Mollema realized that some properties associated with the identity could be modified through the MS Graph, given the correct privileges. One such attribute is a Publisher property that specifies the Identity Provider, and one of the options was simply “Email”. This is for external users who are identified only by their email address and do not have a Microsoft account or Azure AD.

Mollema then looked at who can modify these attributes and found that in addition to administrators, applications that users log in to, that have the appropriate privileges, can modify identities, and users can also modify their identities through MS Graph. This opened the door to interesting attacks, such as placing backdoors into existing accounts if the attacker gains temporary access to them by stealing an access token, or by gaining temporary control of a computer where the user has an active session.

In addition, if the account is the user’s administrator, attackers can create backdoors to all accounts by adding external identities to them and associating them with email addresses controlled by the attackers. They can also do this for global admins as they have rights to modify their identities through MS Graph.

The downside to modifying the identity this way is that it only changes the basic authentication method from username and password to authentication via an external email address. If the account is also secured with multi-factor authentication, the attacker still won’t be able to log in.

But Mollema found a way around this, too. First, use the victim’s temporarily compromised account to create an invitation to the attacker’s external account. The attacker then accepted the invitation, which created a guest account for the attacker in the victim section. Then the attacker logs in with the guest account and configures multi-factor authentication for that account.

The attacker then deleted the guest account using the victim’s account. Since this deletes the guest account associated with the attacker’s external account, it does not clear the account’s multi-factor token, but remains in the buffer. So the attacker’s external account continues to have an active token in the victim’s Azure AD partition even if the associated guest account disappears. The attacker can then create a backdoor to the victim’s account and add their account as an identity, after which the attacker will no longer need to authenticate using MFA. This completes the multifactorial protection of the victim.

How to mitigate cloud authentication vulnerabilities in Azure AD and more

Microsoft has already created updates against the vulnerabilities Mollema discovered, so the attacks he described no longer work. But his findings show the complexity of authentication in new cloud environments. Introducing new features, such as allowing one-time passwords for each email as an identity provider or external identities, can always lead to logical errors that can open shortcuts.

Mollema advises organizations to regularly delete all guest accounts with unrefunded invitations, to secure the right to create guest invitations and guest rights settings, restrict which sections of Azure AD can collaborate externally, implement multi-factor authentication for all applications, and inspect access logs for signs of possible use of guest accounts.