GenericAll, Shadow Credentials, and a Service Account DA

Choice: shadow credentials (write msDS-KeyCredentialLink on j.reid), then authenticate with PKINIT.

Reasoning:

• GenericAll on the user object gives you the rights to write msDS-KeyCredentialLink. No ADCS is required because you generate a self-signed certificate and the DC accepts PKINIT; strong certificate mapping is not enforced, so the certificate will authenticate.
• ForceChangePassword is loud and disruptive: it resets a privileged user's password, likely creates a helpdesk ticket, and is exactly what the blue team monitors.
• Targeted Kerberoasting requires setting an SPN on j.reid, which is explicitly monitored, and then relies on cracking a privileged user's password. Even if the password is weak, the SPN write is an immediate alert and the crack time is uncertain within 24 hours.
• Shadow credentials avoids both monitored events: no password reset and no SPN change. It creates a key credential that is less commonly alerted on, and it gives you a TGT as j.reid.

The tradeoff is that PKINIT authentication itself is logged and some environments alert on certificate-based logons for accounts that normally use passwords. That is still a lower-probability detection than a password reset or SPN creation.

Use j.reid's Tier1-Admin membership to authenticate to FS01 as a local administrator, then target the backup service identity rather than waiting for a DA session.

Steps and reasoning:

1. Request a TGT for j.reid using the shadow-credential certificate, then access FS01 over SMB/WinRM. Verify local admin with a benign command.
2. Enumerate services and scheduled tasks to confirm how svc-backup runs. The service's logon account is the credential you want; a Domain Admin service account is more valuable than a stale DA desktop session.
3. Because FS01 has no EDR, save the registry hives (HKLM\SECURITY and HKLM\SYSTEM) and parse LSA secrets offline. This recovers the service account password without opening LSASS on a monitored host and without relying on a DA being logged in.
4. Authenticate as svc-backup and confirm Domain Admin rights, then proceed to the objective.

Why not wait for the DA session: the BloodHound data is three days old, and the DA may never log on to FS01 during your window. The service account is a deterministic path. The tradeoff is that registry hive access and service enumeration are visible to host logging, but FS01 lacks EDR and the actions are less likely to trigger the privileged-password-reset and SPN alerts the blue team is watching.

The highest-signal events are:

• PKINIT logon for j.reid from a host that user does not normally use, and a certificate mapped to the account. Reduce by using a workstation j.reid plausibly uses and by keeping the ticket lifetime short; do not request a PKINIT ticket repeatedly.
• Registry hive saves on FS01 and service enumeration. Reduce by using built-in tools already present on the host, writing the hive copies to a path consistent with backup activity, and deleting them after parsing. Avoid running a known credential-dumping binary on disk.
• svc-backup authentication to a DC or server from FS01, which may be normal for a backup service but abnormal at your hour. Use the service account from a host where that service account would plausibly authenticate, and avoid interactive logons.

Do not attempt to clear logs or disable auditing; that is more likely to cause an incident than the access itself. The judgement is to keep each step within the normal pattern of the account and host, and to avoid the two events the blue team explicitly monitors: privileged password resets and new SPNs.