Break-Glass Credential Rotation: KRBTGT, Built-in Administrator and Cross-Tier Exposure

Overview

Many failing checks on Exposure > Security Posture come with a fix you can run: open Select Fire from the check, review the change, and apply it. Four checks are different. Their flyout shows No automated fix with the reason, in the place the Select Fire button would be.

Each of their fixes needs a step GraphnAI doesn't take on its own: a timed wait between two resets, a safe place to deliver a new secret, or a change in how people work. This guide is the manual procedure for each of the four. Where the flyout also reads "An automated fix is planned.", a direct action for that check is planned.

---

Prerequisites

• Administrative rights in the directory where the check failed.
• A secure way to hand a new secret to whatever depends on it: a password manager, a sealed ticket, or your existing break-glass process.
• For the KRBTGT rotation, a maintenance window that holds the full wait described below. Don't shorten it.

---

Check 1: The KRBTGT Password Is Old

This is the check KRBTGT password older than 180 days. The flyout reads "Every ticket in the domain depends on this key, so the two rotations run as a planned procedure."

Why it isn't automated

Every Kerberos ticket-granting ticket (TGT) in the domain is encrypted with the KRBTGT account's key. A forged Golden Ticket stays valid until the password is rotated twice. One reset doesn't replace the key cleanly, because the domain keeps the previous password. The safe procedure is two resets at least 10 hours apart, so the tickets issued before the first reset expire in between. Getting the timing wrong can break authentication across the domain, so the rotation runs with a person watching it.

Manual procedure

1. Schedule a window that allows at least 10 hours between the two resets.
2. Reset the KRBTGT password once, to a strong random value.
3. Wait at least 10 hours. Authentication and existing tickets keep working during the wait.
4. Reset the password a second time, to a new random value.
5. Confirm tickets are being issued normally (see below).

Don't reset twice in quick succession. The wait between the resets makes the rotation safe.

How to confirm it worked

• Both resets appear in the domain controller's Security log as event 4724 (an attempt was made to reset an account's password), at least 10 hours apart.
• After the second reset, log on with a test account and confirm it gets a ticket without error.
• The check passes after the next successful sync reads the new password date.

The check reads only the password date. It passes after the first reset, so it can't tell you whether the second reset ran. Complete both.

---

Check 2: The Built-in Administrator Password Is Old

This is the check Built-in Administrator password older than 180 days. The flyout reads "Rotating the break-glass password needs a safe place to keep the new one, so it runs as a guided procedure."

Why it isn't automated

The reset is one write. The problem is where the new password goes: a person has to be able to retrieve it in an emergency. GraphnAI doesn't hold a vault or a delivery path for that secret. A new password with nowhere to go would trade an old-password finding for a lockout.

Manual procedure

1. Generate a strong random password with your organization's approved method.
2. Reset the built-in Administrator password to the new value.
3. Store the new password in your break-glass credential vault, following your existing break-glass process.
4. Record the rotation date where your team can find it.

How to confirm it worked

• Have a second person retrieve the new password through your break-glass process before you close the change.
• The check passes after the next successful sync reads the new password date.

---

Check 3: The Built-in Administrator Was Used Recently

This is the check Built-in Administrator used in the last 14 days. The flyout reads "The built-in Administrator is on GraphnAI's deny list, so no automated action changes it."

Why it isn't automated

This check records that the built-in Administrator (RID 500, even if renamed) logged on recently, which is MITRE technique T1078.001 (Default Accounts). It isn't a directory setting to change. No write stops a person from choosing to use this account, so the fix is a change in practice: give every administrator a named account, and keep the built-in account for emergencies.

Manual procedure

1. Find out who used the built-in Administrator account, and whether it was a planned emergency or routine use.
2. Give every administrator who needs regular elevated access a named account, with only the access they need.
3. Move any scheduled task, service or script that runs as the built-in Administrator onto a named service account.
4. Tell your administrators the built-in account is for break-glass use only, and document when it may be used.

How to confirm it worked

• Watch for logons (event 4624) on the built-in Administrator account over the following weeks. Once named accounts replace routine use, the check stops failing.
• Confirm the tasks and scripts you moved in step 3 run successfully under their new account.

---

Check 4: A Credential Is Exposed Across Tiers

This is the check Cross-tier credential exposure. A Tier 0 credential was seen on a computer where a lower-tier account holds a privilege, such as SeDebugPrivilege, that can dump it from LSASS (credential dumping, T1003). The flyout reads "The holder's rights on this computer come from group policy or local user rights, which GraphnAI doesn't change."

Why it isn't automated

Two parts of the fix aren't directory writes. The lower-tier account's rights on the computer come from Group Policy or the computer's local security policy. The exposed credential also needs rotating, with the new value delivered to everything that uses it. That needs a secret delivery path GraphnAI doesn't have.

Manual procedure

1. List every place the exposed credential is used: services, scheduled tasks, applications and interactive logons.
2. Remove the lower-tier account's right on the computer. If a GPO grants it, keep the user rights setting and remove the account from it. If local security policy grants it, remove it there.
3. If the Tier 0 account shouldn't log on to that computer, deny it with the Deny log on locally and Deny log on through Remote Desktop Services user rights. If it has to, make it connect with Remote Desktop in Restricted Admin Mode.
4. Rotate the exposed credential to a new strong password or secret.
5. Deliver the new secret to every system you listed in step 1 before you move on.
6. Confirm no service or scheduled task still uses the old credential.

How to confirm it worked

• Every system from step 1 runs successfully with the new credential.
• The finding closes when GraphnAI sees evidence the right is gone. A GPO change shows after the next full sync. A local policy change shows within seconds, when the computer logs event 4705. Logging the Tier 0 account off, or letting time pass, doesn't close it. See How an exposure clears.

---

Troubleshooting

A check still fails after the rotation

Checks 1 to 3 update when a sync runs. Confirm a sync has completed for the domain after your change, then look at Security Posture again. If the check still fails, confirm the new password is in place. A rotation that stopped partway, for example a skipped KRBTGT reset, looks the same to GraphnAI as no rotation.

For check 4, see A finding stays open after the fix.

The maintenance window is shorter than 10 hours

Don't shorten the wait to fit the window. A shorter wait can invalidate tickets that are still in use, which is a wider outage than the finding. Move the second reset to a window that allows the full 10 hours.

The cross-tier finding names an unfamiliar host

Confirm the host is still part of your environment before you rotate anything. A decommissioned host whose record was never removed can appear here. If so, remove the stale record instead of rotating a credential for a host that no longer exists.