How to Detect Azure Active Directory Backdoors: Identity Federation

During the Solarwinds breach performed by Russian threat actors, one of the techniques utilised by the threat actors to gain control of a victim's Azure Active Directory (AAD) was to create an AAD backdoor through identity federation. The implication of this attack was that the threat actors were able to log in and impersonate any Microsoft 365 (M365) user and bypass all requirements for MFA as well as bypass any need to enter a valid password. As you can imagine, if the correct detection controls are not in place – this can allow persistence for the threat actors to impersonate any user and maintain access and control of the victim’s AAD / M365 instance.

The technique of backdooring AAD is a technique that tends to be used post-compromise – whereby an attacker has already gained access to an account with Global Administrator or Hybrid Identity Administrator privileges. As such, it’s crucial organisations are monitoring for accounts that get given these two privileges.

There are many ways an attacker can gain Global Administrator privileges within AAD – one of those techniques is by performing privilege escalation on service principals with an owner who has Global Administrator privileges. I have written a previous blog post covering backdooring Azure applications and service principal abuse here. 

The intention of this blog post is to cover how to create an Azure AD backdoor utilising the AADInternals tool by @DrAzureAD, the AAD portal and the MSOnline PowerShell module.  As such, I’ve broken this blog post into two sections – the first one focusing on the detection and second part focusing on the attack flow.

Detection Methodology

To detect a malicious AzureAD backdoor, there are three key elements to consider in the analysis methodology:

• Review all federated domain names within AAD 
• Review audit logs and unified audit logs for any newly federated domains
• Review audit logs for ImmutableIds being added/created for an account
• Review all anomalous logons in the Azure Sign-in logs and the unified audit logs (UAL) 
  
  

Step 1: Reviewing Federated Domain Names

Within the AAD portal the “Custom Domain Names” section lists all domains that are relevant to the instance. In this particular section, I would advise reviewing all domains that have the “federated” tick next to it. 

Step 2: Detect any newly federated domains in AAD

Both the AAD audit logs and the unified audit logs will track activity pertaining to the creation of a newly federated domain. These events should not occur frequently, so setting up an alert on this should not be generating much noise. Since AAD stores audit log and sign-in log activity for 7-30 days based on the license, I’d also recommend setting up the same detection on the unified audit logs.

The detection should focus on looking at the following fields for a match:

• Activity: "Set domain authentication"
• IssuerURI: "http://any.sts/*"
• LiveType: "Federated"

The screenshot below shows how this is represented within the audit logs in the portal.  

Further review of the audit logs should show a sequence of activity pertaining to the verification of the malicious domain along with the federation activity. I would also hunt for the following activities:

• Verify domain: Success or Failure
• Add unverified domain: Success

Step 3: Detecting modifications to ImmutableIDs for accounts

For a backdoor to be set, the impersonated user with Global Admin / Hybrid Identity Admin credentials needs to have an ImmutableID set. This will create an event in AAD Audit Logs. I would write a detection that looks for:

• Activity: "Update User"
• Included Updated Properties: "SourceAnchor"

As you can see from the screenshot below – the ImmutableID I created was “happyegg”. By detecting the existence of “Included Updated Properties” mapping to “SourceAnchor”, you can detect the creation/modification of the ImmutableID. 

Step 4: Review anomalous sign-ins

It’s difficult to review the AAD sign-in logs to ascertain this behaviour as the attackers can basically impersonate any user and login. The premise of the backdoor is that the attackers can bypass MFA. When I performed this attack on my test instance, it generated the following events with these details which shouldn’t be too common for a user. However, based on this attack, these logon events can vary and can generate false positive. I would keep this in mind before turning this into a detection query. 

You can also focus on detecting general anomalous sign-ins that match other IoCs collected in terms of IPs, user-agent strings etc within the Unified Audit Logs (UAL).

Attack Methodology

This next section focuses on how to perform this attack, I relied heavily on the documentation written by @DrAzureAD in his blog here. I did this a little differently, but you can also do the entire thing using just AADInternals. 

Step 1: Set the ImmutableID string for the user you want to impersonate

In order for this attack to work, the user you are impersonating needs to have an ImmutableID set. I used MSOnline module to perform this section. I first ran a check to see if there were any existing ImmutableIDs set in my tenant:

The account I wanted to target is my global administrator account – so using MSOnline I set an ImmutableID for that account as “happyegg”. 

Step 2: Register a malicious domain

For this to work, you need to register / create a malicious domain that you can use as your backdoor. I followed @DrAzureAD recommendation and generated a free one using www.myo365.site called “evildomain.myo365.site”. 

I decided to add the domain to my tenant via the AAD portal. You can do this by clicking into “Custom domain names” and adding your custom domain name there. It will guide you through a verification check where you will need to ensure that the malicious domain you created has the same TXT field as the one issued by Microsoft. The Microsoft documentation for how to add a custom domain name is here. 

Step 3: Create the AAD backdoor

I used AADInternals to do this the same way @DrAzureAD detailed in his blog. This then provides you with an IssuerURI which you will then utilise to login. 

Step 4: Login through your AAD Backdoor

Using AADInternals again, I logged in – as you can see in the screenshot below it automatically opens a browser and shows the “Stay signed in?” page. By clicking “YES” you are automatically taken into the M365 logged in as that user. Attack complete! 

References

https://o365blog.com/post/aadbackdoor/

https://docs.microsoft.com/en-us/powershell/module/msonline/set-msoluser?view=azureadps-1.0

https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/add-custom-domain

https://docs.microsoft.com/en-us/powershell/module/msonline/?view=azureadps-1.0