In the first part of this series about how to bypass MFA in Azure and O365, we discussed how SSO works and how an attacker can abuse this. Read our previous blog post about how to bypass MFA here. In this second part, we elaborate on a more complex attack technique based on MFA in Azure and O365. With the help of Mimikatz, PRT data is extracted from the LSAAS memory. In the third and final part of this short blog series, we will explain how you can protect yourself and your organization against these types of attacks.
The attack we will describe in this article, is more complex than the pass-the-cookie attacks described in part one. Let’s start with some context. We got two important parts: the PRT which has cached in de LSASS memory and the session key, which is normally protected by the TPM. What if there’s a way to export these important parts and reuse them to create a new PRT cookie to obtain new tokens on another device than the victim’s device?
This is where Mimikatz steps in. Benjamin Deply, the creator of Mimikatz, along with Dirk-jan created a new release of the tool to extract the PRT data from the LSAAS memory. They also found a way to export the session key if it isn’t protected by the TPM. But here comes the most interesting part. During reverse engineering they discovered that the actual signing of the PRT cookie isn’t done by the session key but by a derived key of the session key and a context value. The context value is a random byte array and is added to the JWT header. Guess what? This derived key is cached in the memory. So, if you can export the derived key, the session key will become useless. Benjamin Deply made all this possible with Mimikatz.
Remark: A lot of security engineers will say that Mimikatz is detectable by their standard Anti-virus solutions. Because Mimikatz is an open source tool and relatively easy to obfuscate, it will bypass standard AntiVirus software.
This is the setup for this specific scenario: We’ve got a corporate device which is Azure AD joined and logged on with the Azure AD tenant identity.
The attacker already gained access to the device and did a privilege escalation by using a software vulnerability.
The first step is starting up Mimikatz.
Now we will use Mimikatz to export the CLOUDAP data from the LSAAS memory. Reminder: The CLOUDAP caches the PRT in the LSAAS memory.
The output is a long list of users, but we are only interested in the Azure AD account. In this case: the ‘Capt’ account. In the figure below, you can see the PRT output and proof of possession key (the session key) named KeyValue. This value is still encrypted with the DPAPI master keys from the device.
We will have to elevate our privileges in the SYSTEM context to be able to obtain the DPAPI master key from the device so we can decrypt the session key. This can be done with the following command. See figure 5.
Now we will try to decrypt the session key with DPAPI master key. We will try to do this with the following command. See figure 6.
As you will see, this decrypting was unsuccesful. This is because the session key is protected by the TPM and it is not possible to decrypt it in this manner. This process, however, exported the Derived key from the memory which we can use to sign the PRT cookie.
Now we received a newly signed PRT cookie which we can use to authenticate to Azure AD.
Keep an eye out for the third and final part of this blog series, in which we explain how you can protect yourself from these malicious attacks.