From a phone call to Domain Admin

00The shape of the breach

No zero-day broke this environment. The organisation had done a lot right: a segmented, multi-domain forest, and a deliberate three-tier administration model designed so that compromising a standard account should never reach the keys to the kingdom. The breach came from the seams between those controls, a human process that trusted the wrong evidence, a service account that could write everywhere, a convenience that skipped a second factor, and one certificate template that gave away the forest.

The engagement ran in two parts: an external, full-scope start from open-source reconnaissance and social engineering, and then an assumed-breach phase from a low-privilege foothold. Both ended in the same place. This write-up follows the chain end to end, then pulls out why each step worked and what would have stopped it. Everything is sanitised: no organisation, person, host, domain or credential is named, and placeholders stand in for anything identifying.

01The chain at a glance

02Act one: the way in

1.1Social engineering to remote access

The external phase started where most real intrusions do: people. Context-aware pretexting, built on open-source reconnaissance of the organisation and its staff, secured valid access to the remote access environment, a Citrix-published workspace, as an ordinary employee. At this point there was no exploit, just a working session as a standard user.

1.2Quiet enumeration over collaboration tooling

From inside that session, the collaboration platform (Teams) was a goldmine. Without touching anything that looked like an attack, it was possible to enumerate internal structure, team membership, naming conventions and a large amount of personal and organisational detail. In a mature environment the chat and collaboration layer is often the least-monitored, richest source of exactly the information an attacker needs next.

1.3The helpdesk process failure

The pivot from "a standard session" to "control of an identity" came through a process, not a vulnerability. The service desk verified a caller's identity using personal information alone, the same data already harvested in the previous step. That was enough to drive an account and token reset in our favour. The technical controls behind the account were sound; the human process in front of them trusted evidence an attacker could trivially obtain.

The identity plane was only ever as strong as the question the helpdesk asked, and the answer was public.

03Act two: inside a tiered forest

The engagement then moved into its assumed-breach phase, starting from a low-privilege foothold inside the estate: a forest of 17 domains with a deliberate, well-designed tiering model.

The important design choice: the tiers were separated by distinct credentials. Holding an administrator's standard (Tier 3) account did not grant their Tier 2 or Tier 1 access; each tier required its own set of credentials. On paper, a compromised standard account is a dead end. The rest of this story is about how the gaps between the tiers were bridged anyway.

2.1A service account with generic write everywhere

Enumeration of accessible file shares surfaced a service account credential stored in SharePoint. That account held generic write over every user laptop in the estate, a single identity with a write primitive across all workstations. That is the kind of over-provisioning that quietly converts "read a document" into "influence any endpoint".

2.2A foothold, but only Tier 3

Using that write primitive, we targeted the laptop of a high-value user, someone who held accounts in all three tiers. The catch: the laptop session, and the credentials recoverable from it, were only Tier 3. The tiering held. So rather than force it, we established persistence, dug patiently through shares, and waited for the environment to escalate for us.

04Act three: patience and privilege

3.1Tier 2 from a test script

Patience paid. The user ran a test script for routine IT tasks that carried Tier 2 credentials in it, credentials now within reach from the foothold. Hard-coded credentials in operational scripts are a recurring theme: the automation that makes an admin's life easier becomes the ladder between tiers.

3.2What Tier 2 unlocked

Those Tier 2 credentials carried real weight:

• Local administrator access to shared servers.
• Password-reset rights over three Tier 3 accounts.

One of those three accounts belonged to a user who, like the earlier target, held all three tiers. The password reset was only possible against their Tier 3 account, so again, nominally, a dead end at the bottom tier. Except the environment had one more convenience waiting.

3.3The internal MFA gap

A configuration choice undid the separation: when connecting to internal systems over RDP, M365 did not enforce multi-factor authentication over SSO from inside the network. Internal origin was treated as trust. That single assumption turned a recovered low-tier credential into interactive access to internal systems without the second factor that would otherwise have stopped it.

3.4The password-manager pivot

We used the reset Tier 3 account to RDP into the Tier 1 user's system. There, a password manager was configured with SSO for that account. Logging into the vault with the Tier 3 credential exposed what it was protecting: the user's Tier 1 credential. The vault meant to safeguard the highest-tier secret handed it over to the lowest-tier identity, because access to the vault rode on the single-sign-on session rather than on a tier-appropriate check.

Every tier boundary held on its own. The conveniences bridging them, a cached script, an internal MFA exception, an SSO-linked vault, did not.

05Act four: from Tier 1 to Domain Admin

The Tier 1 account was not a Domain Admin, by design. But Tier 1 access changed what we could see and reach, and revisiting the configuration from that vantage point exposed the final flaw: a vulnerable certificate template in Active Directory Certificate Services, the class of misconfiguration tracked as ESC4. Abusing it allowed enrolment of a certificate that authenticated as a privileged principal, escalating to Domain Admin across the forest. Game over.

AD CS escalation (ESC4 here, where weak template permissions let an attacker rewrite a template into a vulnerable state) is a well-documented family of issues. The lesson is not the specific template; it is that certificate services is a privilege-granting system that is frequently left outside the tiering model entirely.

06Why each step worked

07What would have broken the chain

A chain breaks at any link. Several of these controls, in isolation, would have stopped the whole path.

• Proof identity on more than PII. The service desk is part of the identity plane. Verify with something an attacker cannot harvest, and treat password and token resets as privileged actions.
• Enforce MFA everywhere, internal included. Internal network origin is not identity. The single most pivotal gap in this chain was treating "inside" as "trusted".
• Keep service accounts least-privilege. One account with generic write over every laptop is a forest-wide primitive. Scope delegation to what the service actually needs.
• Get credentials out of scripts. Use a secrets manager and short-lived credentials; never let an operational script carry a higher-tier secret.
• Apply the tier model to vaults and PKI too. A password manager protecting Tier 1 secrets must not open on a Tier 3 SSO session, and certificate services must be inside the tiering model, with templates reviewed for the ESC families.
• Watch the collaboration layer. Teams, chat and shares are where recon happens quietly. Least-privilege and monitoring there pay off early in the chain.

The organisation's intent was good, and its architecture was better than most. The breach is a reminder that tiering only works if everything that can cross a tier, people, automation, authentication exceptions, vaults and PKI, is held to the same boundary as the accounts themselves.