Language:
A Microsoft Entra tenant can federate with an external domain to establish trust with another domain for authentication and authorization. Organizations use federation to delegate authentication for Active Directory users to their on-premises Active Directory Federation Services (AD FS). (Note: the external domain is not an Active Directory "domain".) But if malicious actors gain elevated privileges in Microsoft Entra ID, they can abuse this federation mechanism to create a backdoor by adding their own federated domain or editing an existing one to add a secondary configuration with their own settings. Such an attack would allow the following actions:
This Indicator of Exposure detects federated domain backdoors that the AADInternals hacking toolkit creates, in particular the ConvertTo-AADIntBackdoor
and New-AADIntBackdoor
cmdlets, based on certain characteristics of the backdoor domain it created or converted.
The federation protocol that carries the authentication proof from the malicious federated domain to the attacked Microsoft Entra ID can either be WS-Federation or SAML. With SAML, the attack resembles a "Golden SAML" attack, with these key differences:
The microsoft.directory/domains/federation/update
permission grants the ability to modify the federated domains. As of January 2023, the following built-in Microsoft Entra roles hold this permission in addition to potential custom roles:
The APT29 threat group abused this method in the infamous December 2020 attack against SolarWinds called "Solorigate", as documented by Microsoft and by Mandiant.
This finding indicates a potential backdoor from an attacker. Initiate an incident response procedure with a forensic analysis in order to confirm the alleged attack, identify the author and the time of attack, and the extent of the possible intrusion.
Microsoft considers that federation is a feature of Microsoft Entra ID, which is legitimate, and this attack abuses it. Microsoft emphasizes that an attacker must gain high privileges to create this backdoor. For this reason, you should restrict the number of administrators who have the ability to modify federation settings. For more information, see the specific permission and list of roles in the vulnerability description.
To check the list of federated domains in the Azure portal, open the "Custom domain names" blade and look for those with a checkmark in the "Federated" column. The name of the potentially malicious domain is the same one that you see in the finding. But unlike MS Graph API, the Azure portal does not show the federation technical details.
PowerShell cmdlets from MS Graph API allow you to list the domains with Get-MgDomain
and their federation configuration with Get-MgDomainFederationConfiguration
`:
Connect-MgGraph -Scopes "Domain.Read.All"
Get-MgDomain -All | Where-Object { $_.AuthenticationType -eq "Federated" } | ForEach-Object { $_ ; Get-MgDomainFederationConfiguration -DomainId $_.Id }
After you save evidence for an eventual forensic analysis:
Remove-MgDomain
.Remove-MgDomainFederationConfiguration
.Name: Known Federated Domain Backdoor
Codename: KNOWN-FEDERATED-DOMAIN-BACKDOOR
Severity: Critical
Techniques: T1484.002, T1606.002
More: Modify Trusted Domains [Mandiant], Security vulnerability in Azure AD & Office 365 identity federation, How to create a backdoor to Azure AD - part 1: Identity federation, Deep-dive to Azure Active Directory Identity Federation