Azure Advanced Threat Protection: CredSSP Exploit Analysis

This post is authored by Tal Maor, Security Researcher, Azure ATP.

After announcing the release of Azure Advanced Threat Protection (Azure ATP) just a few weeks ago, we are excited to provide details on how Azure ATP has been updated to better protect customers against a new exploit by including the identity theft technique used in the Credential Security Support Provider (CredSSP) Protocol exploit as a flavor of the Pass-The-Ticket detection.

In March, Microsoft released a patch for CVE-2018-0886, which protects against a vulnerability discovered by Preempt. The vulnerability allows attackers to perform authenticated remote code executions by taking advantage of the way CredSSP validates requests during the authentication process.

In this blog, we provide network behavior analysis of the CredSSP exploitation of this vulnerability and the techniques it uses to propagate in the network. Additionally, we highlight how you can use Azure ATP to detect and investigate a variety of advanced cyberattack attempts.

CredSSP exploitation analysis

The CredSSP enables an application to securely delegate a user’s credentials from a client to a target server; any application that depends on CredSSP for authentication may be vulnerable to this type of attack.

The CredSSP remote code execution vulnerability is also known as Kerberos relay attack using CredsSSP because it uses Kerberos to authenticate against the target and sign malicious payload.

As an example of how an attacker would exploit this vulnerability against Remote Desktop Protocol, the attacker would need to run a specially crafted application and perform a man-in-the-middle attack against a Remote Desktop Protocol session.

Main steps of standard CredSSPs Kerberos U2U

  1. SSL negotiation – the RDP server returns its public certificate.
  2. The client requests from the Ticket Granting Service (TGS) for TERMSRV on the RDP server this TGS wont be used although it is retrieved.
  3. The client requests the Ticket Granting Ticket (TGT) which should be used as an additional ticket for granting TGS to the RDP server – this step is unique for the U2U mechanism.
  4. The client requests the Key Distribution Center (KDC) for U2U TGS for the RDP server (using the RDP client TGT from its initial AS request) and additional TGT of the RDP server (retrieved in step 3).

    • The KDC first validates the authenticity of the requester using the RDP client TGT.
    • Then it opens the RDP server TGT with the krbtgt long term key and uses the TGT session key for encrypting the requested TGS.
    • The client receives the U2U TGS encrypted with the RDP server TGT session key, and TGS enc-part response encrypted with the RDP client TGT session key, both encrypted parts contain a new session key generated by the KDC for the new RDP connection.
    • The client opens the TGS enc-part response and finds the session key with the RDP server.

  5. The client creates an AP request using the received TGS for the RDP connection and relevant session key (both retrieved in step c). This AP request also contains the RDP server public key (received in the SSL negotiation) encrypted with the negotiated session key, as Channel Binding of CredSSP to validate client authenticity.

At this point, the authentication phase is over, and the encrypted RDP session was established.

Main steps of the malicious CredSSPs Kerberos U2U

In this flow, the target is the Domain Controller that also runs RDP and RPC servers by default.

Setting up the malicious RDP server

  1. RPC bind to the TaskSchedulerService interface with U2U Kerberos KERB-TGT-REQUEST. This will retrieve the relevant TGT for TERMSRVdc1.domain1.test.local service.

Waiting for the victim to connect via RDP

2. The RDP client initiates a secured TLS connection with the malicious RDP server and requests its public certificate. This time the malicious RDP server returns a malicious public certificate in clear text.

The client uses the public key from the certificate to initiate an encrypted SSL connection and later signs the public key using the Kerberos session key (aka Channel Binding) as part of the last step of CredSSP in the Kerberos AP request.

3. The client requests TGS for TERMSRV on the malicious RDP server – this TGS wont be used although it is retrieved.

4. The client requests the TGT which should be used as an additional ticket for granting TGS to the malicious RDP server – this step is unique for the U2U mechanism.

5. The client requests the KDC for U2U TGS (using the RDP client TGT from its normal AS) and additional TGT of the RDP server (retrieved in step 3).

6. The client creates an AP request, which includes the TGS for the RDP connection. This AP request also contains the malicious RDP server public key encrypted with the negotiated session key, that was meant to be the Channel Binding and is used by the malicious RDP server in the next steps.

The malicious RDP server tries to authenticate the RPC session (initiated in step 0) by performing AP request with TGS and authenticator extracted from the original AP request of the victim. The DC will get this AP request as part of the RPC session and validated the received TGS and authenticator.

7. The malicious server sends the signed task scheduler request, which was sent to the victim as a public key (in step 0) and was returned signed by the victim (in step 6), over the authenticated RPC session to create malicious task successfully.

Detection with Azure ATP

This type of identity theft can be detected by Azure ATP as an identity theft using Pass-The-Ticket attack. Given that the Kerberos AP request from the attacker using the original clients TGS, Azure ATP will detect this malicious behavior and will create the following security alert:

In addition, Azure ATP detects several Remote Code Execution techniques performed against the Domain Controller. Given that the RPC makes a call to create a task scheduler on the domain controller, the following security alert is created:

When the two security alerts started concurrently and point to the same machine, this can point to the conclusion that this machine performed a remote malicious operation by using the theft identity like as the operation performed by the CredSSP exploit.

We strongly recommend that customers who have not yet set the security update for CredSSP to do so as soon as possible. For more information on how to apply the patch please visit CredSSP updates for CVE-2018-0886.

You can learn more about Azure ATP here, and when you are ready, start a trial!

Additional Resources

Source: EM+S Blog Feed

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.