Cross-Tier Credential Exposure: Tier 0 Credentials at Risk of OS Credential Dumping (T1003)

Overview

A Domain Admin logs on to a workstation. On that same workstation, a help desk account holds SeDebugPrivilege. The help desk account doesn't need to attack the Domain Admin. It reads LSASS memory on a machine it already controls and leaves with a Tier 0 credential.

Directory-only tools can't see this, because nothing about the help desk account's group memberships looks wrong. The risk comes from two things observed on the same machine: a Tier 0 session, and a lower-tier account with credential theft privileges.

The Cross-tier credential exposure check reports that. Its evidence is observed telemetry, so its findings carry the highest fidelity level, Validated. Every finding is Critical.

The Security Posture page shows everything about an exposure: the exposed identity, the computer, and the identities that can take the credential.

Prerequisites

• Session telemetry collected. Event 4624 ("An account was successfully logged on") creates the session edge, and its Logon Type says how the account logged on. Event 4672 ("Special privileges assigned to new logon") records the privileges a logon received. You need both. See Telemetry Pipeline.
• User rights changes collected (recommended). Events 4704 and 4705 record a user right assigned to, or removed from, an account in a computer's local security policy. They show GraphnAI a right granted outside Group Policy, and one taken away. They need Policy Change > Audit Authorization Policy Change enabled for Success.
• Tier 0 identities classified. The check asks its question of Tier 0 identities. See Asset Criticality.
• A completed sync. The check first runs with the analytics after a sync. From then on, telemetry updates it directly. See When findings update.

How results read

The check is evaluated per connector. Each connector's result is one of:

A connector counts as having session telemetry when at least one of its enabled computers or devices had a session observed in the last 90 days. Privilege assignments alone don't count, because GraphnAI also reads privileges from Group Policy with no collector involved. An Entra ID tenant with no collector reads Not assessed, because nothing is collecting logon events on those devices.

A connector whose collector stops goes back to Not assessed once its newest session is more than 90 days old. It never drifts to Passing because nothing new arrived.

A Tier 0 identity can still be exposed on a computer in a connector you don't collect from. The check can't see those sessions, and its description on the Security Posture page says so.

When findings update

This check doesn't wait for a sync. Its evidence is telemetry, so telemetry updates it.

When a logon or a privilege event arrives, GraphnAI checks the computers it touched again within seconds. If a Tier 0 identity's exposure changed, it updates the finding, the connector's Security Posture score, the identity's risk score and the dashboard. Any open Security Posture, Identity Inventory or dashboard page refreshes. Nothing else in the connector is recomputed.

Every hour by default, GraphnAI also compares all exposures with what it last recorded. That catches changes no event announces, such as evidence passing the 90-day backstop. See How an exposure clears.

A few changes need a full analytics run for the connector, and GraphnAI starts one itself:

• The Tier 0 population changed. An identity became Tier 0, or left Tier 0, since the last run. The check's score depends on how many Tier 0 identities the connector has, and only a full run recounts them.
• Session telemetry started on a connector that had none. Whether a connector is covered is decided by the full run.
• An update couldn't finish. The full run rebuilds everything the update touched.

These runs take minutes on a large directory. GraphnAI starts at most one per connector every 15 minutes, and none while a sync is already processing that connector. Telemetry updates pause while the license is read-only, the same as a manual re-run.

The backstop and the hourly comparison are deployment settings. The defaults are 90 days and one hour.

Finding an exposure

1. Select Exposure > Security Posture in the sidebar.
2. Select the Cross-tier exposure category card. The findings table filters to this check.
3. Find the exposed identity. The line under its name says where it was seen, such as Exposed on 2022CA01.
4. Select the row. The detail panel opens with the identity, its blast radius graph and the check.

To find every Tier 0 identity exposed on one computer, search for the computer's name.

The Posture tab in the identity's flyout lists the same finding, so you can reach it from the Graph Explorer, the Identity Inventory or any analysis page.

Reading the detail panel

The Where it's exposed section lists each computer the identity was observed on. Under each computer are the non-Tier-0 identities that hold credential theft privileges there. Select a privilege holder to open it in the Graph Explorer and see how it got the privilege.

The panel shows up to 10 computers, and up to 10 privilege holders per computer. When there are more, it states the totals, such as "Showing 10 of 14 computers."

The panel also has Why this matters, How to fix it, the ATT&CK mappings (T1003 OS Credential Dumping, T1078 Valid Accounts) and when the finding was first seen.

What creates an exposure

A finding appears when all three conditions hold:

1. A Tier 0 identity logged on to a computer in a way that left its credential there. See Which logons leave a credential.
2. A different, non-Tier-0 identity holds at least one Critical or High Windows privilege on the same computer.
3. Neither edge (the session or the privilege) is part of a simulation.

GraphnAI learns of a privilege from three sources, and any one of them is enough:

Which logons leave a credential

Not every logon leaves the computer something it can reuse. The check reads the event's Logon Type and counts a Tier 0 logon only when it leaves a credential:

Any other Logon Type counts, including a logon whose event doesn't say which type it was. A Tier 0 identity that only reaches a computer over the network isn't exposed there, however often it does.

How an exposure clears

An exposure clears only on evidence that the risk is gone. Time passing isn't that evidence, and neither is logging off. People log on where they logged on before. While the Tier 0 identity may log on to that computer and the other account holds the privilege there, the credential can be taken again.

Each source clears on its own evidence:

• Group Policy. A GPO that applies to the computer still configures the right and no longer lists the account. The next full sync removes it. Removing the setting from the GPO, unlinking or deleting the GPO, or moving the computer out of its scope doesn't clear it, because Windows keeps the last assignment it applied on the computer.
  • GraphnAI counts a GPO as applying when it's linked to the computer's OU or one above it, inheritance reaches the computer (or the link is enforced), and the GPO has no WMI filter. It doesn't read security filtering yet, so it treats the GPO as applying to every computer under the link.
  • If any other GPO that could apply to the computer still lists the account, the right stays. A GPO with a WMI filter can keep a right this way, but it never removes one.
• Local assignment. Event 4705 removes the right. A 4705 also clears a Group Policy grant of the same right, because it's the computer's own statement. If a GPO still grants the right, the computer applies it again and the next full sync restores it.
• Observed at logon. Two things have to happen. The account logs on to the computer again the same way (interactively, as a service, and so on) and receives no special privileges. Then another account's event 4672 from the same computer arrives. The second shows the computer was still reporting event 4672, so the missing one means something. An observation GraphnAI couldn't match to its logon never clears this way.

A computer drops out of the finding when no source leaves a privilege holder there. The finding closes when no computer is left, or when the tiers change: the privilege holder becomes Tier 0, or the exposed identity leaves Tier 0.

One backstop sits behind all of this. Evidence that neither edge has seen in 90 days stops counting, so a decommissioned computer's old sessions don't hold a finding open forever. A session is seen again every time the identity logs on there in a way that leaves its credential. A network logon doesn't renew it. A Group Policy grant is seen again on every full sync for as long as the policy grants it.

Restricted Admin Mode

A Tier 0 identity that connects with Restricted Admin Mode (mstsc /restrictedadmin) doesn't leave its credentials on the target, so the session creates no exposure. The session is still recorded, and the identity's timeline marks it with a Restricted Admin badge. One ordinary logon from the same identity to the same machine inside the 90-day backstop does create an exposure.

Privilege risk classification

Only Critical and High privileges create an exposure:

Fixing an exposure

GraphnAI can't fix this one for you. In place of a Select Fire button, the detail panel shows No automated fix and the reason: "The holder's rights on this computer come from group policy or local user rights, which GraphnAI doesn't change." For the full procedure, including rotating the credential, see Break-Glass Credential Rotation.

Pick the fix that matches the cause:

• The Tier 0 identity shouldn't log on there. A Domain Admin using a privileged account on a standard workstation is the classic case. Log off the session, rotate the credential, and use a lower-tier account for that machine.
• The privilege holder shouldn't hold that privilege. SeDebugPrivilege granted through local security policy with no business reason is common. Remove it from the policy on that computer.
• The Tier 0 identity needs to reach that machine. Enforce Restricted Admin Mode for those connections so the credential never lands in memory.

In every case, rotate the exposed credential. It may already have been taken.

The finding closes when GraphnAI sees the fix. See How an exposure clears.

• You removed the privilege through Group Policy. Keep the setting and take the account out of it. The finding updates after the next full sync. Deleting the setting leaves the right on the computer.
• You removed the privilege from local security policy. The computer logs event 4705, and the finding updates within seconds if Audit Authorization Policy Change is enabled.
• The privilege was only ever observed at logon. The finding updates once the account logs on there again without it.
• The Tier 0 identity stopped logging on there. That alone doesn't close the finding. The identity may still log on, and the other account still holds the privilege. Fix one of those.

How it scores

Each open finding feeds the identity's Exposure risk factor and the dashboard's Exposure card, on the same worst-finding basis as every other posture check. A connector where this check reads Not assessed reports partial Exposure coverage instead of a clean score. See Exposure Risk Factor.

Troubleshooting

The Cross-tier exposure card says "Not assessed"

Cause: None of that connector's enabled computers or devices has had a session observed on it in the last 90 days. Either collection never started there, or it stopped.

Solution:

1. Confirm the telemetry collector forwards events from machines in that domain. See Telemetry Pipeline.
2. Open a computer you expect to be covered in the Graph Explorer, and check for incoming session edges.
3. After collection starts, the first logon on one of the connector's computers starts an analytics run for it, and the check is assessed when that run finishes.

The Cross-tier exposure card went from Passing to "Not assessed"

Cause: Sessions stopped arriving from that connector. Once the newest one is more than 90 days old, GraphnAI can no longer say the connector is covered, so it stops reporting the check as passing.

Solution: Treat it as a collection outage. Check the collector for that domain. See Telemetry Pipeline. The dashboard's Telemetry coverage gauge drops at the same time, because it measures coverage over the same window.

No findings despite active Tier 0 sessions

Cause: The Tier 0 logons left no credential on those computers (network logons, or Remote Desktop in Restricted Admin Mode), or no lower-tier identity holds a Critical or High privilege on the same computers.

Solution:

1. Open a known Tier 0 identity's timeline and look at its sessions on the computer. Each one shows its Logon type and whether Restricted Admin mode was used.
2. Network logons (type 3) and Restricted Admin sessions correctly produce no exposure. Restricted Admin is the secure configuration for a Tier 0 account that has to reach a lower-tier machine.
3. Confirm event 4672 is collected. Without it, GraphnAI sees only the privileges Group Policy and local assignments grant. On a domain controller, run auditpol /get /category:"Logon/Logoff" and check that Audit Special Logon is enabled for Success.

Session edges appear but privilege edges are missing

Cause: Event 4672 isn't collected, or the identities in those events don't match directory objects in GraphnAI.

Solution:

1. Enable Logon/Logoff > Audit Special Logon with Success.
2. Privilege edges are created only for identities that match a directory object. Local accounts outside your directory don't match.
3. Confirm the domain in the telemetry event matches the identity's domain (FQDN form).

A finding stays open after the fix

Cause: GraphnAI hasn't seen evidence of the fix yet. It never closes a finding because time passed.

Solution:

1. Confirm the fix on the computer itself.
2. Match the fix to the source of the privilege. See How an exposure clears. On the computer, gpresult /h report.html lists each user rights setting a GPO applied and which GPO set it. A right with no GPO behind it came from local security policy, or was only observed at logon.
3. Group Policy: keep the user rights setting and remove the account from it. Deleting the setting, unlinking the GPO, or moving the computer to another OU leaves the right on the computer, and the finding correctly stays open. The update lands after the next full sync.
4. Local assignment: confirm Policy Change > Audit Authorization Policy Change is enabled for Success, so the removal logs Event 4705.
5. Observed at logon: the finding updates after the account logs on to that computer again without the privilege, once another account's special-privileges event from the same computer follows it.
6. If you stopped the Tier 0 identity from logging on there, the finding stays. It's still allowed to, and the privilege holder can still take the credential when it does.

A finding closed but nothing changed on the computer

Cause: One of two things. The privilege holder logged on again without special privileges and the computer kept reporting them for other accounts, which clears an observed privilege. Or neither edge had been seen for 90 days, which is the backstop for decommissioned computers.

Solution: Nothing to do if the account lost the privilege. If it still holds it, for example through a group, its next logon with it brings the finding back within seconds.

A new exposure doesn't show yet

Cause: The telemetry hasn't arrived, or the exposure needs a full analytics run. For example, the identity only became Tier 0 since the last run.

Solution: Confirm both events arrived: event 4624 for the session and event 4672 for the privilege. The finding appears within seconds of the second one. If the identity's tier changed recently, wait for the analytics run GraphnAI starts, or re-run analytics for the domain now.