Skip to content

Cross-Tier Credential Exposure ​

Find the computers where a Tier 0 credential sits in memory and a lower-tier identity holds the privileges to take it. It's a Critical check on the Security Posture page.

Requires role: Operator or Admin

Related: Account Security & Credential Hygiene Checks, Exposure Risk Factor, Risk Posture Dashboard, Telemetry Pipeline, Telemetry Enrichment, Asset Criticality, Graph Explorer, Identity Investigation Timeline


Overview ​

A Domain Admin signs in 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 evidence 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. Windows event 4624 (successful sign-in) creates the session connection and says how the account signed in. Event 4672 (special privileges assigned) records the privileges a sign-in 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:

ResultMeaning
FailingAt least one of this connector's Tier 0 identities was observed signing in, in a way that left its credential, on a computer where a lower-tier identity holds credential theft privileges. One finding per exposed identity.
PassingSession telemetry is arriving on this connector and none of its Tier 0 identities is exposed.
Not assessedNo session has been observed on this connector's computers in the last 90 days. The check didn't look, so it makes no claim either way.

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 sign-ins 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 sign-in 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 signed in to a computer in a way that left its credential there. See Which sign-ins 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 connection is part of a simulation.

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

SourceEvidence
Group PolicyA GPO that applies to the computer assigns the right in its user rights settings. Read on every full sync.
Local assignmentEvent 4704: the computer's local security policy assigned the right to the account.
Observed at sign-inEvent 4672: the account received the right when it signed in to the computer.

Which sign-ins leave a credential ​

Not every sign-in leaves the computer something it can reuse. The check counts a Tier 0 sign-in only when it does:

Sign-inLeaves the credential on the computer
At the console, over Remote Desktop, or with cached credentialsYes, in memory
As a service or a scheduled taskYes, stored on the computer
A cleartext network sign-in (basic authentication, CredSSP)Yes, the computer receives the password
A network sign-in (a file share, remote management, most service-to-service calls)No, it proves the credential without handing it over
Remote Desktop in Restricted Admin ModeNo, the credential isn't sent

Any other kind of sign-in counts, including one whose event doesn't say what kind 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 signing out. People sign in where they signed in before. While the Tier 0 identity may sign in 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 sign-in. Two things have to happen. The account signs in 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 sign-in 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 connection 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 signs in there in a way that leaves its credential. A network sign-in 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 sign-in 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:

Risk tierPrivilegesWhy it matters
CriticalSeDebugPrivilege, SeImpersonatePrivilege, SeAssignPrimaryTokenPrivilege, SeTcbPrivilege, SeCreateTokenPrivilegeDirect credential extraction (LSASS memory read, token theft) or creation of arbitrary security tokens
HighSeBackupPrivilege, SeRestorePrivilege, SeTakeOwnershipPrivilege, SeLoadDriverPrivilege, SeEnableDelegationPrivilege, SeManageVolumePrivilegePrivilege escalation, indirect credential access (SAM or NTDS.dit extraction), or kernel driver loading
MediumSeSecurityPrivilege, SeAuditPrivilege, SeSystemEnvironmentPrivilege, SeTrustedCredManAccessPrivilege, SeSyncAgentPrivilegeEvidence destruction or stored credential harvesting. Visible in the graph, no exposure.
LowAll other privilegesMinimal attack surface on their own

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 sign in there. A Domain Admin using a privileged account on a standard workstation is the classic case. Sign out 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 sign-in. The finding updates once the account signs in there again without it.
  • The Tier 0 identity stopped signing in there. That alone doesn't close the finding. The identity may still sign in, 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 connections.
  3. After collection starts, the first sign-in 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 sign-ins left no credential on those computers (network sign-ins, 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 sign-ins 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 connections appear but privilege connections 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 connections 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 sign-in.
  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 sign-in: the finding updates after the account signs in 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 signing in 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 signed in again without special privileges and the computer kept reporting them for other accounts, which clears an observed privilege. Or neither connection 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 sign-in 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.