Ryan Sacatani

Skills · learning

Kerberos - Service Name Substitution

Table of Contents

Kerberos - Service Name Substitution

Quick references: task-first command sheet · detailed command reference · exam navigator

Quick answer

Service-name substitution is useful when constrained delegation permits a service ticket to a backend SPN that is not useful for the objective, while another service on that same backend accepts the same account key. The lab example delegates to TIME on a file server, then changes the ticket's service name to CIFS so it can be presented to SMB.

The short reasoning chain is:

LON-WS-1$ is allowed to delegate to time/lon-fs-1
    → S4U obtains an impersonated-user service ticket for that allowed SPN
    → /altservice:cifs changes the service name to cifs/lon-fs-1
    → present the ticket to SMB on lon-fs-1
    → the target still checks whether the impersonated user may access the requested share

This does not make the ticket a TGT, grant local administrator rights on the target, or guarantee that the share will allow access.

Why TIME to CIFS can help

The KDC's constrained-delegation list limits which backend SPN the front-end account may request. In the observed substitution example, the allowed backend is a TIME SPN. TIME is associated with Windows time synchronization; it does not provide the file-share operation needed for the lab objective.

CIFS is the Kerberos service class used for SMB/CIFS file and printer sharing. Windows clients commonly request a ticket for a server SPN such as cifs/lon-fs-1 when authenticating to an SMB share. The path \lon-fs-1\C$ is the server's hidden administrative C: share, which requires the user to have the corresponding administrative rights on that target. It is a useful test target because it exercises SMB authentication and share authorization.

The goal is therefore not “use the TIME service.” TIME is the SPN permitted by the delegation configuration. The useful service is SMB/CIFS on the same backend host, if it accepts a ticket encrypted with the same account key.

Memory cue: TIME is the permitted route; CIFS is the service we want to reach.

What changes in the ticket

A Kerberos service ticket has an outer structure with a realm, a server name (sname), and an encrypted part. The sname identifies the service principal. The encrypted EncTicketPart contains the client principal, session key, ticket flags, time limits, and authorization data.

Ticket
├── realm
├── sname: time/lon-fs-1                  [outer service name]
└── enc-part: encrypted EncTicketPart
    ├── client: Administrator
    ├── session key
    ├── authorization data
    └── flags and validity times

The course Rubeus /altservice option changes the outer service name in the returned ticket. It does not rewrite the encrypted client identity or authorization data. The backend service must still be able to decrypt and accept the ticket.

The real cryptographic requirement is that TIME and CIFS on the target resolve to the same service-account key. In the common computer-account case, both are associated with that host's machine account, such as LON-FS-1$. “Same host” is a useful clue; the account key is the actual condition. If the target uses a different account/key, relabelling the service name does not re-encrypt the ticket for that key and the service cannot decrypt it.

Service-name-substitution flow showing delegation, user impersonation, and the alternate service name.
Fig. 1. Service-name-substitution flow showing delegation, user impersonation, and the alternate service name.

When this is useful

Use this branch only when the evidence and objective line up:

  1. Constrained delegation is present. The delegating account has an msDS-AllowedToDelegateTo value for the exact backend SPN.
  2. You have the right delegator ticket. For this lab, that is the TGT for LON-WS-1$. Verify the ticket's client principal rather than relying on a previous PID, LUID, or copied ticket.
  3. The S4U branch is supported. The lab example uses protocol transition so S4U2Self can represent Administrator. The TRUSTED_TO_AUTH_FOR_DELEGATION userAccountControl bit is a protocol-transition indicator; it does not itself identify the permitted backend.
  4. The target has a useful alternate service under the same key. For the lab, TIME and CIFS must map to the same account key on lon-fs-1.
  5. The impersonated user is authorized for the requested resource. A CIFS ticket authenticates to SMB as that user; it does not bypass share or NTFS permissions.
  6. The route is reachable. The machine where the ticket is used must be able to resolve and reach the exact target service.

If the delegation list already includes cifs/, use the direct-CIFS constrained-delegation branch in 15b. Kerberos - Constrained Delegation. Service-name substitution is for the case where a different allowed SPN such as TIME must be converted to a useful same-key service.

This is a constrained-delegation S4U technique. Unconstrained delegation is a separate workflow; a TRUSTED_FOR_DELEGATION flag alone does not establish the conditions described here.

Account attributes showing the computer's configured msDS-AllowedToDelegateTo service names.
Fig. 2. Account attributes showing the computer's configured msDS-AllowedToDelegateTo service names.

Read the lab evidence

The latest screenshot shows the result of this LDAP query:

ldapsearch (&(samAccountType=805306369)(msDS-AllowedToDelegateTo=*)) --attributes samAccountName,msDS-AllowedToDelegateTo,userAccountControl

Relevant result:

userAccountControl: 16781312
sAMAccountName: LON-WS-1$
msDS-AllowedToDelegateTo: time/lon-fs-1.contoso.com, time/lon-fs-1

Interpret it this way:

  • Delegating account: LON-WS-1$

  • Allowed SPN in this lesson: time/lon-fs-1 (the output also lists its FQDN form)

  • Intended alternate service: cifs/lon-fs-1

  • Resource check: \lon-fs-1\C$

  • UAC value: 16781312; the lab notes identify the TRUSTED_TO_AUTH_FOR_DELEGATION bit as set. To test that bit explicitly:

      [Convert]::ToBoolean(16781312 -band 16777216)

The allow-list and the UAC flag answer different questions. msDS-AllowedToDelegateTo tells you which backend SPNs are permitted; the UAC bit indicates whether protocol transition is configured. Neither alone proves that a ticket can be obtained or that a resource will grant access.

The older written example uses time/lon-dc-1. Treat that as a separate example/environment. Do not take the TIME SPN from one host and test CIFS or C$ on another host. For the screenshot and current lab, follow time/lon-fs-1 through to cifs/lon-fs-1 and \lon-fs-1\C$.

CRTO lab procedure

1. Confirm the delegation target and account

Use the authorized lab Beacon and record the exact delegating account, allowed SPN, and UAC value from LDAP. The screenshot's result is LON-WS-1$ → time/lon-fs-1.

2. Obtain and verify the delegator TGT

Use the ticket-dumping procedure from the preceding authorized lab notes. The ticket supplied to S4U must be the TGT for LON-WS-1$, not the TGT for the impersonated user. Keep its complete encoded contents out of shared notes.

3. Request S4U and substitute CIFS

The lab's Kerbeus BOF alias uses:

krb_s4u /ticket:<LON-WS-1-TGT> /service:time/lon-fs-1 /altservice:cifs /impersonateuser:Administrator

Read the arguments as:

  • /ticket: TGT for the delegation-enabled account LON-WS-1$
  • /service: the exact allowed SPN from msDS-AllowedToDelegateTo
  • /altservice: the service class to use on the final ticket, CIFS
  • /impersonateuser: the identity represented by the delegated service ticket

The equivalent Rubeus form from the course notes is:

execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe s4u /user:LON-WS-1$ /msdsspn:time/lon-fs-1 /altservice:cifs /ticket:<LON-WS-1-TGT> /impersonateuser:Administrator /nowrap

These command forms assume the lab's protocol-transition branch. Rubeus performs S4U2Self to obtain a suitable ticket representing the user to the delegating service, then S4U2Proxy to request a ticket to the allowed backend. The final service name is substituted to CIFS. The KDC's S4U2Proxy policy still limits the delegated backend; /altservice does not change that policy.

4. Read the returned ticket

The expected final ticket represents Administrator and targets cifs/lon-fs-1. It is a service ticket, not an Administrator TGT. The lab output may display the KRB_CRED ticket as Base64 text. Base64 is only an encoding; treat the value as a live credential and do not paste it into durable notes.

Use and validate the ticket

Use the course ticket-passing method for the selected tool. The Rubeus sample in the notes creates a separate net-only logon session and imports the final service ticket into that session:

execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe createnetonly /program:C:\Windows\System32\cmd.exe /domain:CONTOSO.COM /username:Administrator /password:FakePass /ticket:<FINAL-CIFS-TICKET>

steal_token <NEW-PROCESS-PID>
ls \\lon-fs-1\C$

FakePass is a placeholder password for the net-only logon context in this course example. The supplied ticket is the authentication material used for the remote service access. Follow the lab's own ticket-import workflow when using the Kerbeus BOF output.

Validation order:

  1. The S4U output says the final service is cifs/lon-fs-1.
  2. The ticket cache contains a ticket for cifs/lon-fs-1 with client Administrator.
  3. The SMB request names the same host, \lon-fs-1\C$.
  4. A successful directory listing confirms resource access in this lab.

A successful ticket request alone is not evidence of SMB authorization. A failed share check can mean the ticket target/name is wrong, SMB is unreachable, the server rejects the service name, or Administrator lacks the needed share or NTFS rights.

Limits and common mistakes

  • Do not mix the hostnames. The latest LDAP evidence is time/lon-fs-1. The older note says time/lon-dc-1. The final CIFS SPN and UNC path must refer to the backend used for the active lab.
  • The account key matters. Same machine is not sufficient if the services use different accounts; the receiving service must have the key needed to decrypt the ticket.
  • Do not assume any alternate SPN works. The alternate service must exist, be accepted by the server, and be useful for the objective.
  • A ticket is not authorization. Kerberos authentication and target resource permissions are separate checks.
  • A service ticket is not a TGT. The final ticket is for Administrator → cifs/lon-fs-1; it cannot be used as Administrator's general-purpose TGT.
  • Don't conflate the direct-CIFS and substitution labs. Direct delegation lists cifs/lon-fs-1 in the allow-list. This lesson's substitution evidence lists time/lon-fs-1 and then asks for cifs/lon-fs-1.
  • Don't infer this path from unconstrained delegation. Check the correct technique and ticket flow for the delegation type in the current challenge.

OPSEC and ticket handling

High-sensitivity lab actions Ticket dumping, S4U requests, passing an impersonated Administrator service ticket, and probing the remote C$ share are high-impact actions. They generate authentication and resource-access activity that can be visible to defenders. Use these steps only in the authorized CRTO lab and follow its OPSEC rules. Never store a real TGT, service ticket, or Base64 ticket output in Obsidian.

For exam use, pause before the S4U request and verify the delegator, exact allow-listed SPN, target host, protocol-transition evidence, alternate service, and intended access. After the lab check, follow the course cleanup procedure for the ticket context.

Sources

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

Ryan Sacatani

Simply curious about the world, constantly building and breaking things for fun.

sacataniryan1@gmail.com ↗

BrowseBrowse topics

Browse

RSS ↗ · Brain