Most organizations are on a path to fully migrating to a cloud-based identity and access management (IAM) solution like Azure Active Directory (Azure AD). Platforms like Azure AD are more scalable, more secure, and support the latest methods of user authentication when accessing organizational resources and applications. However, transitioning from on-premises IAM solutions takes time - and while customers embark on that journey, Microsoft offers cloud-powered protections for those on-premises resources to ensure that they’re best protected against the latest identity-targeted threats.
Microsoft 365 Defender provides comprehensive protection for identities across the Microsoft identity stack. Within that, Defender for Identity supports hybrid identity configurations via an Active Directory Federation Services sensor, to protect the AD FS infrastructure and alert security teams to AD FS-based threats. This enables Microsoft to protect environments where AD FS is in use, as Defender for Identity goes beyond just relying on the authentication happening on the domain controller, and instead collects additional context and data directly from AD FS.
Thousands of organizations are already running the sensor across their AD FS environments, to protect users against attacks involving AD FS, while using the familiar end-to-end SecOps experience that Microsoft 365 Defender provides.
This blog uses “MagicWeb” as a recent example of an attack abusing hybrid identity environments, and provides important information on how to protect against these types of attacks.
Understanding authentication and authorization with AD FS
Active Directory Federation Services (ADFS) is designed to build federated identity management solutions that extend an organization's existing Active Directory deployment. This allows hybrid integration with cloud solutions like Azure Active Directory or various cloud applications such as ServiceNow, Salesforce, or Microsoft Office 365. To understand how AD FS federates access to external applications we’ll describe the steps involved when a user accesses a federated service, using the AD FS server and the SAML Authentication Protocol (AD FS also supports WS-Federation and OAuth 2.0):
- The user attempts to access the target application.
- The application requires a token that will prove the user’s identity.
- The user authenticates against the AD FS server and requests a SAML token.
- The AD FS server issues a SAML token containing the user claims (authorization data), which is signed by a certificate owned by the AD FS server.
- The user presents the token to the target application.
- The application verifies the SAML token using the AD FS public key and grants access according to the user’s authorization data.
For a more comprehensive look at AD FS, see our documentation.
The key parts in this process are steps 3 and 4 - where a conversion occurs between a proof of identity, which is valid within the domain realm (Kerberos ticket, NetNTLM hash, client certificate, etc., and a proof of identity, which is valid against an external application – a SAML token.
The authentication in the 3rd step can be carried out using several methods, including client certificates over TLS. Certificate authentication is unique in the context of AD FS, as the authentication and authorization steps occur over two different protocols, while involving two different servers. The diagram below depicts the process in more detail:
The client certificate validation on the AD FS side is performed against trusted certificates which are stored by Active Directory Domain Services (AD DS) in a dedicated container called NTAuthCertificates, which is fetched via LDAP by the AD FS server when it starts and locally stored at this registry path - HKLM\SOFTWARE\Microsoft\EnterpriseCertificates\NTAuth\Certificates.
If the validation is successful, the authentication part is done – the user is verified. However, as opposed to the IWA protocols mentioned above, TLS authentication doesn’t supply user authorization. Thus, the AD FS server is missing crucial authorization data (e.g., group memberships) that are necessary for generating the SAML token.
This authorization data is obtained using the S4U2Self Kerberos mechanism, which is used for performing transitions between different authentication protocols to Kerberos. This results in a valid Kerberos ticket, which has the authorization data as an extension in the ticket’s PAC. This is how the transition looks over the wire (steps #4 and #5 in the diagram above):
First, the AD FS server is sending an AS-REQ request to the DC, without pre-authentication data, to get an indication whether this is the realm of the subject user. Afterwards, we can observe both TGS-REQ and TGS-REP events, which are part of the S4U2Self process.
An example representation of TGS-REP response can be seen in the screenshot below – the DC returns a ticket for NewAdfs$ (the service account that runs AD FS) on behalf of user1, the user that is trying to access an external resource. This ticket contains the PAC structure, with all the necessary authorization data to issue the SAML token to user1.
Abuse of Client Certificate Authentication in hybrid identity attacks
The recent MagicWeb threat involved AD FS persistence & credential access techniques, which allowed the threat actor (Nobelium) to bypass authentication mechanisms and get access to trusted third-party applications, as any user within the organization.
The bypass takes place in the form of a malicious DLL file that is planted on the AD FS server and is configured to be loaded to the process of AD FS (Microsoft.IdentityServer.ServiceHost.exe). Upon loading, the malicious DLL register hooks to selected functions that implement the backdoor logic. Those hooks are triggered by specific requests, which eventually lead to authentication bypass and the successful issuing of a valid SAML token.
In the case of MagicWeb, the attack takes advantage of the fact that with certificate authentication, the AD FS service performs the authentication – instead of a Domain Controller. Therefore, the bypass can take place on the AD FS server alone. Thus, only the certificate authentication logic is tampered with, by looking for specific certificates’ EKU OID’s values during the certificate validation process.
EKU - Certificates have an “Extended Key Usages (EKUs)” field – it holds a set of Object identifiers (OIDs) that describe how the certificate can be used. Common examples of OID’s: Client Authentication (OID 1.3.6.1.5.5.7.3.2), Code Signing (OID 1.3.6.1.5.5.7.3.3), etc.,
If one of two specific OIDs (arbitrary ones with no special purpose, that are hardcoded into the malicious DLL) are found in the client certificate, the authentication will succeed, even if the certificate isn’t trusted. In this scenario, even if the user is enforced via Multi Factor Authentication (MFA), it will be bypassed by the backdoor.
This will enable the adversary to craft rogue certificates with the “magic” OIDs, holding any user as the subject. When using this certificate during the TLS authentication, the authentication bypass logic will identify the request and will return a successful result. This in turn will lead to the issuing of a valid SAML token, which can be used for legit user impersonation.
Detecting hybrid attacks with Microsoft Defender for Identity
Since version 2.191, Microsoft Defender for Identity can detect different variants of the above-mentioned authentication bypass technique. The detection is dependent on proper deployment of the AD FS sensor, as well as enabling AD FS auditing.
The detection logic will look for the abnormal behavior of an invalid certificate that led to a successful authentication. This correlation will be based on AD FS auditing logs, while searching for a correlation between several matching event parameters.
With a successful detection, Microsoft Defender for Identity will surface an alert, containing information on the actor who performed the activity, the device the actor was operating from, and the AD FS server that was potentially compromised.
If this alert type is triggered, you can reference this detailed guide on how to respond to an on-prem compromise.
Improve the security of your hybrid identity environments
With Microsoft Defender for identity installed on AD FS servers, you will get unique, end-to-end protection of your environment. You can find the complete list of capabilities here but key capabilities include:
- Protecting AD FS servers – Similar to how the Defender for Identity sensor protects domain controllers against attacks targeting the DC role (KrbRelayUP, DnsHostName Spoofing, DFSCoerce and more), when it’s installed on AD FS servers, it protects against running any malicious code against the server or other potential takeover threats. It’s not just account compromise that’s important, but also ensuring the integrity of the platform.
- Detecting AD FS related threats – the detections that are based on login activities can be enriched with AD FS data, providing additional context into brute force or password spray attempts coming from AD FS.
- Richer insights across sign-in activities - some authentication activities, such as failed logins, are visible only to the AD FS server. For other successful logins, Defender for Identity can now correlate login information from Active Directory with data from the AD FS server, including whether multi factor authentication occurred when the request was made, the user context, and more.
Next steps
Moving away from on-premises identity and authentication methods should be high on any organization’s priority list. Many of the most prevalent identity-based vulnerabilities include an interaction with Active Directory, or its supporting technologies. If you’re still reliant on AD FS or Active Directory, speak to your Microsoft representative or a Microsoft partner to learn about new features to help break that reliance on AD and AD FS, while ensuring a smoother, safer transition to the cloud.
We recognize that full adoption of Azure AD takes time. If you have AD FS in place in your organization, remember that like domain controllers, AD FS servers can authenticate users and should therefore be treated with the same high level of security. Customers can defend against hybrid identity threats by implementing a holistic security strategy including our AD FS hardening guidance. In addition, we encourage organizations already using Microsoft Defender for Identity to ensure that the sensor is deployed to all Domain Controllers and AD FS servers.
For more information, follow this deployment guide.
More information
We're always adding new capabilities to Defender for Identity, check back regularly on this blog to stay up to date.
- Start a free free trial of Microsoft Defender for Identity.
- Check out our response to recent threats
- Detecting DnsHostName Spoofing with Microsoft Defender for Identity
- Detecting and preventing privilege escalation attacks leveraging Kerberos relaying
- How Microsoft Defender for Identity protects against DFSCoerce
- Learn how to respond to on-premises identity compromise with Defender for Identity.
