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 won’t 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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.