Backdoor Office 365 and Active Directory

Backdoor Office 365 and Active Directory - Golden SAML

September 02, 2021

Backdoors can bypass all MFA requirements put in place by an organisation. Earlier this year, I worked an engagement with an APT group that had a keen interest on the client’s Office 365 environment, where this group found a way to bypass authentication controls to access the environment. Given that most clients either have a hybrid authentication model set-up or are fully in the cloud – I think it’s important that most blue teams / defenders / hunters are aware of the various techniques threat actors are using against Azure AD.

Compromise of the AD FS server token-signing certificate could result in access to the Azure/Office365 environment by the attacker. By default, this certificate is valid for a year and will allow an attacker to log into Azure/Office365 as any user within AD regardless of any password resets and MFA. The implication of this, is that the attacker maintains persistence and has a means to re-enter into the environment, escaping detection.

This blog post will cover the Golden SAML attack which is used by attackers to move from on-premise to Office 365/Azure. In a following blog post, I will break down the detection of malicious / backdoored applications in Azure AD as another backdoor mechanism.

How the Attack Flow Works

In short, this attack was witnessed being utilised by APT groups – one notable example was during the SolarWinds attack. The attack works by an attacker hijacking, or gaining access to the AD FS server, extracting the secret (SAML token) and using this to access the Office365 Azure AD environment.

Keep in mind variations may occur with different attackers, but the principle is the same – that the attacker wants to hijack AD FS and gather the SAML token. The SAML token will grant the attacker access to:

Azure / Azure AD
Office 365
Azure Applications (which they can further backdoor)
Defender Security Center

Step 1: Attacker compromises the on-premise domain

In order for this attack to work, the attacker has already gotten access to credentials and is on a server / workstation within the domain. This can occur many different ways.

Step 2: Enumeration

During this step, the attacker will use enumeration tools to enumerate the AD FS server administrators and process owner usernames. This detail is critical as this "process owner" account has the permissions to "gather" the SAML token. The SAML token is a token that's used to authenticate users into the Office365/Azure environment.

Step 3: Gather the credentials for AD FS process owner account

Once the AD FS process owner account is known, a credential dumping tool can be used to gather the NTLM hashed password of the account. This can be achieved through the use of Mimikatz or any other equivalent tool.

Step 4: Laterally move to AD FS server

With the harvested credentials of the AD FS process owner account, the next step is to log onto the AD FS server. This is typically done using pass-the-hash, but can be done using other techniques. This will vary between actors.

Step 5: Attain the token-signing certificate from the AD FS server

AD FS servers use SAML tokens to perform authentication of users. When users authenticate to Office 365, Microsoft validates the SAML tokens by verifying that the token isn't expired, that the token ImmutableID matches a user present in Azure AD and that the signature of the token is valid.

The purpose of this attack is to attain the token-signing certificate and private key that AD FS uses to sign SAML tokens issued by AD FS for authentication. Once an attacker attains this, they can essentially log into, authenticate and access Azure AD and Office 365 as any AD user. This will allow authentication regardless if a user resets their AD password. To logon as any user, the attacker simply needs to access the ImmutableID of each user - which is a unique identifier associated with each user in Azure AD. This ImmutableID can be fetched and viewed by any user regardless of permissions, granted that the user is a part of Azure AD or on-premises AD.

There are multiple different ways to fetch this certificate that have been utilised by threat actors listed below:

Step 6: Attain the DKM

The token-signing certificate is encrypted by default and requires a "DKM" which is a Distributed Key Manager in order to decrypt. In order for an attacker to use this, they need to attain the DKM to decrypt the certificate. At this stage of the attack, it is not difficult for the attacker to gain access to the DKM. This can be done by using Powershell to query the DKM certificate container, and then passing these details over to a generic tool like Adfind.exe to extract the DKM.

Step 7: Decrypt the token-signing certificate

There are multiple tools online that allow an attacker to decrypt the token-signing certificate with the DKM.

Step 8: Generate a SAML token

Given that the attacker now has the key/certificate pair, they can produce a signed security token that can allow the attacker to log onto Office365 as a user. This can be done by passing the SAML token into Burpsuite as a POST request.