Microsoft updated Microsoft Defender for Identity to detect the ADFSDump tool’s use, which was the initial tool used in the Solorigate campaign. This blog post will describe what the attack does, including mitigations for the attack. I created a tool to perform the attack for educational purposes.
Active Directory Federation Services Authentication
To understand the attack, we first need to look at how Active Directory Federation Services (AD FS) works. Here is an oversimplified overview of the authentication using AD FS.
- The user goes to https://portal.office.com and signs in with the username firstname.lastname@example.org;
- Microsoft recognises the federation and sends a 302 HTTP response code, redirecting the user to the federated AD FS server ;
- The user identifies itself using a password on the Web Application Proxy used by AD FS;
- The Web Application Proxy sends the request to AD FS;
- AD FS authenticates the user by checking Active Directory if the user entered the correct credentials;
- AD DS sends the response of the authentication back to the AD FS server;
- AD FS signs a token using a token-signing certificate and sends it to the Web Application proxy;
- The Web Authentication Proxy sends the signed token to the user;
- The user presents the signed token to Microsoft 365 and can log in to the service.
Suppose there is a way to sign your tokens using a private key and token-signing certificate used by AD FS. In that case, you could impersonate the AD FS server and authenticate to federated services by presenting the signed token. Step 1 to 8 is not needed, and you can submit the forged token directly to the federated service. The federated service checks the token with the public key, and with the correct signed private key, the federated service authenticates the user.
The impersonation of an AD FS server is precisely what Doug Bienstock did. Doug Bienstock created a tool to obtain the token-signing certificate and private key to generate forged security tokens. The tool to obtain the token-signing certificate and private key is called ADFSDump. Since release 2.135 of Microsoft Defender for Identity, ADFSDump gets detected.
For educational purposes, I created a tool to dump the private key and certificate and get undetected by Microsoft Defender for Identity. Some key features of my tool are:
- The date creation of the private key helps identify which key to use;
- The private keys are in the correct format;
- Microsoft Defender for Identity does not detect the attack.
Once you have obtained the private key and token-signing certificate, use ADFSSpoof to create the forged token.
The service account used by AD FS contains Service Principal Names. That means the account is vulnerable to Kerberoasting. Be sure the service account includes a strong and generated password, so it is less likely an attacker can brute-force the password.
Looking at the Administrative Tier Model, consider placing AD FS in the tier 0 scope.
An obvious but important one is monitoring. As I mentioned in my top 5, monitoring is crucial in any organization. An attacker needs to go through many steps in the kill chain before the attacker can extract the details. Monitoring should detect an attacker by then.
In my previous blog post, I mentioned that attackers could hop from on-premises to the cloud. The attack described in this blog post is another way for an attacker to jump from on-premises to the cloud. Once the on-premises environment is compromised, the attacker has many possibilities to hop to the cloud. Even though a lot of companies are focussing on the cloud, do not forget the on-premises environment.