Another day, another dollar. And if not that, at least some mischief.

I found an open door on Johnny's desktop. Local admin on a Tier 2 workstation. That's the kind of foothold that takes five minutes to turn into something useful.

I load PowerShell. Native Microsoft modules. Get-ADUser, Get-ADGroup, Get-ADComputer. If you know the queries, AD is an open book. Most places don't alert on native cmdlets because everyone uses them for legitimate administration. I'm just one more admin with a PowerShell console.

I'm looking for credentials. Specifically, credentials that bridge tiers. Most Tier 2 workstations are locked down enough that moving directly to Tier 1 is hard. But admins are lazy. Some of them store a runas credential for a higher-tier account on the workstation they use most frequently. It's against every policy. It's also everywhere.

I find one. Johnny_t1. Tier 1 account.

I use it. Move over to the Tier 1 network segment. Johnny_t1 is admin on something. Let me check what.

SCCM.

Configuration Manager. The infrastructure that manages patches, deployments, configurations, policies. Johnny_t1 is admin on the SCCM server itself.

Let me think about what SCCM can do.

I enumerate the collections. I look at what SCCM is actually managing.

Certification Authorities. Domain Controllers. The entire Tier 0 infrastructure sits in SCCM's management scope.

SCCM can push packages. SCCM can modify configurations. SCCM can deploy policies that open enrollment on certificate templates. SCCM can install software on DCs and CAs. SCCM can modify startup services. SCCM can deploy a backdoor to every system it manages.

I don't need to pick ten attacks. I only need one.

I create a package. The package runs a single command on all domain controllers: net localgroup Administrators Hiro /add. SCCM deploys it. Twenty minutes later, I'm a local admin on every DC in the forest. I add myself to the Domain Admins group. I'm permanent. I'm everywhere. I own the entire environment.

The tiering model says SCCM is Tier 1 infrastructure. SCCM's admin access to Tier 0 is just part of how SCCM works. The access is expected, controlled, monitored.

Except it's not, because nobody treats SCCM like it's Tier 0. Because the guidance calls it Tier 1.

The tiering model is wrong.

How this actually happens

The tiering model defines three tiers:

  • Tier 0: Domain Controllers, CAs, identity infrastructure, anything that can modify the directory or issue credentials.
  • Tier 1: Servers and services that support Tier 0. Management servers, backup infrastructure, hypervisors, anything that can administer Tier 0 systems.
  • Tier 2: User workstations, anything that doesn't directly administer Tier 0 or 1.

SCCM, by definition, administers Tier 0 systems. Microsoft's guidance is explicit: have a separate SCCM instance for each tier. One SCCM managing Tier 0 systems. One managing Tier 1. One managing Tier 2. Each isolated. Each with its own admins. No crossover.

Very few organizations do this.

The reason is operational overhead. A separate SCCM instance per tier means separate servers, separate infrastructure, separate admin teams, separate patch schedules, separate policies. It doubles or triples your SCCM footprint. The cost is substantial. Most organizations classify SCCM as Tier 1 infrastructure, run a single unified instance managing everything, and accept the risk.

Then they get breached the way Hiro breached this environment, and realize the operational overhead would have been cheaper than the incident response.

The tiering guidance has an answer. Most organizations decided not to implement it.

The same problem applies to:

  • Intune and Endpoint Manager. Manage every device. Can push policies that modify enrollment, issue certificates, open access controls. Tier 1? No. Tier 0 equivalent.
  • Entra Connect (formerly Azure AD Connect). Synchronizes identity between on-premises AD and Entra ID. Has credentials with directory replication rights. Tier 1? No. Tier 0 equivalent.
  • Backup infrastructure. Can bare-metal restore any system, including domain controllers. Tier 1? No. Tier 0 equivalent.
  • Hypervisors. Can provision, snapshot, restore, and modify Tier 0 systems at will. Tier 1? No. Tier 0 equivalent.

All of these are classified as Tier 1 or "managed infrastructure" because you can't operationally silo them per tier. All of them have unrestricted administrative access to Tier 0 systems. The tiering guidance calls them Tier 1 and then has no answer for the access control contradiction.

Most organizations know SCCM is important. They restrict SCCM admin access more carefully than they restrict most other Tier 1 roles. But they don't restrict it as if it's Tier 0, because the guidance calls it Tier 1.

And then someone finds a Tier 1 account with credentials on a Tier 2 workstation, and the game is over.

What you're probably missing

Look at your SCCM admins right now. How many are there? How many have permanent standing admin access versus break-glass emergency access? How many of those accounts authenticate with the same workstations, browsers, and practices as regular Tier 1 admins?

Now look at your hypervisor admins. Your backup infrastructure admins. Your Entra Connect service accounts. Your Intune admins.

Most organizations have five to ten people with credentials that grant unrestricted administrative access to Tier 0 systems through these Tier 1-classified tools. And most of those credentials are sitting on workstations where a single compromise gets them to an attacker.

The tiering model says that's fine because the credentials are Tier 1, the workstations are Tier 2, and they're in different segments.

It's not fine. It's how this article starts.

Closing

The tiering model is useful. The model of separating systems by their criticality and applying access controls accordingly is sound.

The guidance on SCCM is also sound: have a separate SCCM instance for each tier.

The problem is what happens after that. Most organizations read that guidance, recognize the operational overhead, and decide to run a single unified SCCM instance instead. The cost of separate SCCM infrastructure seems high. The risk of a breach seems abstract.

Hiro's attack turns that calculation inside out.

SCCM, Intune, Entra Connect, backup infrastructure, hypervisors. All of them can do anything an actual domain controller can do. All of them have guidance for being treated as Tier 0 equivalent. Most organizations read that guidance and compromise anyway, because the operational cost is real and the breach feels unlikely.

Hiro doesn't need the guidance to know what tools matter. He just needs to find a path to one of them, and the path exists because you decided the operational overhead wasn't worth it.

The tiering model has an answer. You chose not to implement it.