Case Study 2: Anatomy of an Escalation to Domain Admin

"The ransomware was the last ten minutes. The breach was the four days before it, walking from a warehouse laptop to the domain — and every step was a privileged credential left somewhere it should never have been." — incident-response lead's debrief (constructed scenario)

Executive Summary

This case study is the mirror image of the first. Case Study 1 watched a bank build privileged-access controls before an incident. This one reconstructs an incident at an organization that did not — a mid-size manufacturer, "Tellaro Components," hit by ransomware that began with a single phished warehouse laptop and ended, four days later, with the attacker holding Domain Admin and encrypting the company's file servers, ERP system, and backups. No new sector-specific anchor is introduced; Tellaro is a one-off, constructed teaching scenario (Tier 3), chosen because manufacturing — with its mix of corporate IT, flat networks, and shared administrative accounts — is exactly where the §19.1 escalation ladder runs most freely.

This is an analysis-heavy study. We walk the attacker's path through Tellaro's environment from the defender's seat, reading the telemetry left behind, mapping each move to the escalation ladder and to MITRE ATT&CK, and — most importantly — naming, at every single rung, the specific PAM control from this chapter that would have broken the chain. The goal is not to admire the attack but to learn to read one, and to see concretely what privileged-access controls are worth by watching what their absence costs.

Skills applied: post-incident analysis; mapping an intrusion to the privilege-escalation ladder and ATT&CK; reading authentication, EDR, and AD telemetry for privileged abuse; identifying the absent control at each rung; translating a breach into a privileged-access remediation roadmap.

Background

Tellaro Components makes specialized industrial parts: ~1,400 employees, three plants, a corporate Windows Active Directory domain (tellaro.example), a flat network where the warehouse, the office, and the server room all share broad reachability, and an IT team of six who keep the lights on with limited budget and less time. Their privileged-access posture was the unremarkable default that most organizations live with — and that this chapter exists to fix:

• Every employee was a local administrator on their own machine ("it was easier than fielding install requests").
• The local Administrator password was identical on every machine, set once by the imaging process years ago.
• The IT team used their Domain Admin accounts for everyday work — including logging into user laptops to provide support, and reading email.
• There was no credential vault, no rotation, no JIT — Domain Admin was standing, 24/7.
• No tiering: Domain Admin credentials were used freely on Tier 2 workstations.
• No privileged-session recording, and no detection specific to privileged-account abuse.

None of this was negligence in the cartoon sense; it was the accumulation of small conveniences, each defensible in isolation, that together built a frictionless highway from any laptop to the domain. The attacker did not need to be sophisticated. They needed Tellaro to be normal.

Manufacturing is worth singling out because the sector is structurally prone to exactly this failure, and the reasons generalize. First, manufacturers often run flat networks that grew organically as plants and office systems were connected for convenience, with little segmentation between the shop floor, the warehouse, and the server room — so lateral movement meets few internal barriers. Second, IT teams are typically small and stretched, supporting a workforce that is mostly non-technical and frequently asks for software installs, which pushes teams toward the local-admin-for-everyone and shared-admin-account shortcuts that hand the attacker the early rungs. Third, uptime pressure is intense — a paused production line costs money by the minute — which historically discourages the friction that PAM imposes and makes "just give it admin so it works" a recurring temptation. The point is not that manufacturers are careless; it is that the same forces that make any resource-constrained, uptime-sensitive organization reach for administrative convenience are the forces PAM exists to counter. Tellaro's story is a manufacturer in its specifics and a warning to every organization in its structure.

🔗 Connection: The flat-network problem is a network-security failure (Chapters 6–7) and the local-admin-for-everyone problem is a host-hardening failure (Chapter 11) — but notice how both converge on privileged access. Segmentation would have slowed the lateral movement; removing local admin would have closed rung 2. PAM does not replace those controls; it is the layer that assumes they may be absent or may fail, and ensures that even a flat network full of local admins cannot be walked all the way to the domain — if the privileged credentials themselves are vaulted, tiered, and time-boxed. The disciplines reinforce one another; Tellaro had none of them.

🔗 Connection: Compare this list, point for point, to the controls Meridian built in Case Study 1. Tellaro is Meridian before the domain-admin lockdown. Reading the two studies together is the clearest argument this chapter can make: the same environment, with and without PAM, produces a contained incident or a company-ending breach from the identical initial mistake (a phished laptop).

The Reconstruction

The incident responders, brought in after the encryption, rebuilt the four-day timeline from what telemetry survived (the attacker disabled some logging late in the intrusion — itself a tell). We present it as the ladder from §19.1, annotated with the evidence and the missing control.

Day 1 — Rung 1: Initial foothold (ATT&CK: Phishing, T1566)

A warehouse supervisor received a convincing invoice-themed email and opened the attached document, which ran a loader. The supervisor's account had no special permissions — a normal user.

Day 1, 09:42  email: malicious attachment opened on host WS-WHSE-12 (user: t.okonkwo)
Day 1, 09:43  edr:   suspicious child process spawned from document; C2 beacon established

Missing control: phishing-resistant MFA (Chapter 16) would not have stopped the document execution, but it would have blunted the credential theft to come. The relevant point for this chapter: the foothold itself was survivable. A normal user on one laptop is not a disaster — unless that laptop is a launchpad to privilege.

Day 1 — Rung 2: Local privilege escalation (ATT&CK: T1078 / abuse of local admin)

The attacker did not need an exploit. The warehouse supervisor was a local administrator on WS-WHSE-12, so the loader inherited local-admin rights immediately.

Missing control: removing local-admin rights from ordinary users. Tellaro handed the attacker rung 2 for free. This is the single cheapest control absent here — and the one the chapter's §19.1 check-your- understanding singles out. Had the supervisor not been a local admin, the attacker would have had to find and run a privilege-escalation exploit, a noisier, more failure-prone step that buys defenders time and signal.

Day 2 — Rung 3: Credential harvesting (ATT&CK: OS Credential Dumping, T1003)

As local admin, the attacker dumped credentials from the machine's memory (the LSASS process). Here the flat conveniences compounded catastrophically. Two days earlier, an IT technician had remoted into WS-WHSE-12 using a Domain Admin account to fix a printer problem — and that account's credential material was still resident in memory.

Day 2, 11:18  edr:  LSASS memory access on WS-WHSE-12 by SYSTEM-level process
Day 2, 11:19  (recovered) credential material for TELLARO\da-mfg (Domain Admin) present on host

Missing controls, plural: (1) Tiering — a Domain Admin account should never have been used to log on to a Tier 2 warehouse laptop; with enforced logon restrictions there would have been nothing to harvest. (2) Credential vaulting with check-in rotation — even if a powerful credential had touched the machine, if it were vaulted and rotated after that printer-fix session, the harvested material would already be dead. (3) LAPS — the attacker also dumped the local Administrator hash, which, because it was identical on every machine, was about to become a master key.

🛡️ Defender's Lens: Rung 3 is where the incident was decided, and it was decided by a convenience from two days earlier — a technician using a Domain Admin account on a user laptop. This is the precise behavior tiering forbids and the precise reason it forbids it. The credential is only as protected as the least-protected place it is ever used; a Domain Admin credential typed into a warehouse laptop is a compromised Domain Admin credential the moment that laptop is compromised, no matter how strong the password. No amount of password strength or login MFA addresses this — only architecture (tiering) and credential lifecycle (vault + rotation) do.

Day 2–3 — Rung 4: Lateral movement (ATT&CK: Pass-the-Hash, T1550.002; Remote Services, T1021)

The attacker now moved sideways with two stolen keys. First, the shared local Administrator hash opened every other workstation via pass-the-hash — no cracking required, because the same credential worked everywhere. Second, the harvested Domain Admin credential let them authenticate to servers directly. They moved from the warehouse subnet to the office subnet to the server room, harvesting more credentials at each hop, because the flat network put nothing in their way.

Day 2, 14:05  auth: TELLARO\Administrator (local) -> WS-OFFICE-31  logon_type=3  SUCCESS  (pass-the-hash)
Day 2, 16:22  auth: TELLARO\Administrator (local) -> WS-OFFICE-58  logon_type=3  SUCCESS
Day 3, 08:50  auth: TELLARO\da-mfg -> SRV-FILE-02  logon_type=3  SUCCESS
Day 3, 10:14  auth: TELLARO\da-mfg -> SRV-ERP-01   logon_type=3  SUCCESS

Missing controls: (1) LAPS would have made the local Administrator password unique per machine, confining the harvested hash to the single warehouse laptop instead of unlocking 1,400 of them. (2) Network segmentation (Chapters 6–7) would have slowed the hop-by-hop spread. The privileged-access lesson stands on its own: the shared local-admin password turned one compromised laptop into the whole fleet, and a standing Domain Admin credential moved freely because nothing time-boxed or brokered it.

Day 3 — Rung 5: The attacker already held Domain Admin (ATT&CK: Valid Accounts, T1078.002)

There was no dramatic "escalation to Domain Admin" event, because the attacker had harvested a Domain Admin credential back on Day 2 (rung 3). By Day 3 they were simply using it. This is the quiet horror of the standing-privilege model: the most powerful account in the company was sitting on a warehouse laptop, and once stolen, no further escalation was needed.

Missing control: just-in-time access. Had da-mfg been merely eligible for Domain Admin rather than a standing member, the credential harvested on Day 2 would have belonged to an account that currently held no elevated rights — and the attacker would have had to defeat the JIT activation workflow (MFA at activation, approval, alerting) to become powerful, converting a silent win into a noisy, blockable, detectable event. JIT would not merely have slowed the attacker; it would have given Tellaro a signal at the exact moment that mattered.

Day 4 — Rung 6: Domain dominance and impact (ATT&CK: Inhibit Recovery T1490; Data Encrypted for Impact T1486)

With Domain Admin, the attacker did what ransomware crews do: they disabled endpoint protection via Group Policy, located and deleted the backups (which were reachable from the domain), and then pushed the ransomware payload to every endpoint and server at once. The encryption — "the last ten minutes" — was trivial once they owned the domain.

Day 4, 02:31  GPO change: security tooling disabled domain-wide (account: TELLARO\da-mfg)
Day 4, 02:48  backup catalog + repositories deleted (account: TELLARO\da-mfg)
Day 4, 03:10  ransomware deployment via GPO/scheduled task to all domain-joined hosts

Missing controls: session recording and real-time monitoring would have captured — and potentially interrupted — the credential-dumping, the GPO tampering, and the backup deletion as they happened. Detection of out-of-band privileged logons (a Domain Admin authenticating with no vault checkout, because there was no vault) and of new GPO changes disabling security tooling would have fired days earlier. And break-glass-protected, offline backups — backups not reachable by a domain-joined Domain Admin account — would have meant the company could recover without paying. Tellaro's backups were online and domain-reachable, so Domain Admin owned them too.

What the Telemetry Should Have Screamed

Read as a whole, the four-day timeline is a sequence of events that, in an environment with PAM, would each have been a high-fidelity alert. The tragedy is that the evidence existed — but there was no baseline of "legitimate privileged access" against which any of it stood out, and no detection tuned to privileged abuse. Mapped to the detections Meridian built in Case Study 1:

🚪 Threshold Concept (revisited): The same property that makes privileged accounts so dangerous — that they are powerful — is exactly what makes their abuse detectable, if you have first constrained legitimate privileged access to a narrow, instrumented path. Tellaro had powerful accounts used everywhere, all the time, by everyone on the team, so privileged activity was indistinguishable from background noise and the attacker's use of it blended right in. Meridian's lockdown did not just make privilege harder to steal; by funneling it through the vault, it made every illegitimate use stand out against a quiet baseline. Privilege you cannot see used is privilege you cannot detect being abused.

Detection Deep-Dive: The Three Alerts That Would Have Ended It Early

It is worth dwelling on exactly how the breach would have been caught, because "deploy detections" is useless advice without the specific rules. The responders modeled three detections against Tellaro's own recovered telemetry and identified, for each, the precise moment it would have fired and the time it would have bought. All three are detections that only become possible once privileged access is constrained — which is why Tellaro, with privilege used everywhere by everyone, had none of them.

Detection D2 — a Tier-0 credential on a Tier-2 host (would have fired Day 2, 11:19). The single earliest, cleanest catch. Under enforced tiering, a Domain Admin credential appearing on a warehouse laptop is impossible by design; observing it is therefore an unambiguous signal that either the control broke or an attack is underway. Expressed as a rule:

WHEN  an authentication or credential-material event references a Tier-0 account
 AND  the host is classified Tier 2 (a workstation, not a PAW or DC)
THEN  SEVERITY=CRITICAL "Tier-0 credential observed on Tier-2 host"
      enrich: account, host, time;  auto-action: isolate host, page IR

Tellaro reality: TELLARO\da-mfg credential material was resident on WS-WHSE-12 by Day 2 11:19.
This rule fires ~3 days before the encryption. But Tellaro had no tier classification on hosts,
so "a domain admin on a warehouse laptop" was indistinguishable from normal — it WAS normal there.

Detection D5 — credential-theft tradecraft on a privileged host (would have fired Day 2, 11:18). The LSASS memory read is the technical signature of rung 3 and is detectable at the endpoint (EDR) regardless of tiering. This one Tellaro could in principle have caught even without PAM — if anyone had been watching LSASS-access alerts and had a process to act on a privileged account dumping credentials. They were not, and they did not.

WHEN  a process reads the memory of LSASS  (OS Credential Dumping, ATT&CK T1003.001)
 AND  the acting context is SYSTEM/admin on a server or a host with privileged logons
THEN  SEVERITY=CRITICAL "Credential dumping on privileged host"
      auto-action: isolate host, suspend the implicated account's sessions, page IR

Detection D1 — out-of-band privileged logon (would have fired continuously, Day 2 onward). With a vault, every legitimate privileged logon has a matching checkout; a privileged logon without one is anomalous by construction. Tellaro had no vault, so every one of da-mfg's logons was, technically, "out of band" — which is precisely the point: the absence of a brokered path meant there was no way to tell a legitimate privileged logon from the attacker's. The detection cannot exist until the legitimate path is narrowed.

The responders' conclusion was blunt and is the lesson of the case: Tellaro did not lack the data; it lacked the constraint that turns the data into signal. Every event the attacker generated was sitting in a log. What was missing was a narrow, instrumented, enforced privileged-access path — vaulting, tiering, JIT — against which any deviation would have lit up. You cannot bolt detections onto an environment where the dangerous behavior is also the normal behavior; you must first make the dangerous behavior abnormal by constraining the legitimate path. Prevention and detection are not a menu to choose from — here, the preventive controls were the precondition for the detections to mean anything.

⚠️ Common Pitfall (the meta-lesson): Organizations frequently try to "buy detection" — a SIEM, a detection-engineering team — while leaving privileged access wide open, and then wonder why privileged-abuse alerts are drowned in noise or absent entirely. The Tellaro reconstruction shows why: detection of privileged abuse is downstream of constraining privileged access. Tighten the path first (vault, tier, JIT), and the detections become high-fidelity almost for free; skip that step, and no amount of SIEM tuning will separate the attacker's domain-admin logon from the ten legitimate ones that happen on random laptops every day.

The Cost of What Was Missing

The responders tallied the blast radius to make the abstract concrete for Tellaro's leadership — the same exercise that justifies PAM's friction to any board. With Domain Admin, the attacker reached: every file server (engineering designs, contracts, employee PII); the ERP system (the company's operational heart); the email system; and — decisively — the backups, which were online and domain-reachable and were therefore deleted before the encryption. Because the backups were gone, recovery options narrowed to rebuilding from whatever offline fragments existed or paying the ransom. Three plants paused production while systems were rebuilt. None of this required attacker sophistication; it required Tellaro to leave the keys to the kingdom standing, shared, un-tiered, and unwatched — and to leave the backups within Domain Admin's reach.

The contrast with Meridian (Case Study 1) is the whole argument of this chapter rendered as a balance sheet. Meridian spent a budget cycle and imposed real friction on its administrators to vault, tier, time-box, record, and detect privileged access — and bought the property that a phished laptop is a contained incident. Tellaro spent nothing and imposed no friction — and bought a company-ending breach from the same opening move. The friction was not the cost; the friction was the price of the insurance, and the breach was the cost of going uninsured.

The Remediation Roadmap

The responders' report did not end with the timeline. Because the absent control at each rung had been named explicitly, the remediation roadmap wrote itself — and it is, essentially, Meridian's Case Study 1 program, prioritized by which rung it closes:

1. Remove local-admin rights from ordinary users (closes rung 2) and deploy LAPS for unique, rotated local-admin passwords (closes the rung-4 shared-key highway). Cheapest, fastest, highest-impact.
2. Vault Domain Admin and other privileged credentials with check-in rotation (shrinks rung-3 exposure).
3. Implement JIT with approvals so no standing Domain Admin exists (turns rung 5 from silent to noisy).
4. Enforce tiered administration and PAWs so privileged credentials are never exposed on Tier 2 (severs rung 3 by architecture).
5. Record privileged sessions and build the D1–D6 detections (catches rungs 3–6 in flight).
6. Move backups offline / off-domain and protect them with break-glass-controlled access (denies rung 6 its recovery-inhibition win).

🔄 Check Your Understanding: The roadmap puts "remove local-admin rights + LAPS" first, ahead of the commercial PAM platform, vaulting, and tiering. Using the timeline above, justify that ordering: which two rungs does step 1 close, and why is closing them the highest-value first move even though it does not touch the Domain Admin accounts directly? (Hint: trace what the attacker could and could not have done on Day 2 if local admin had been removed and LAPS deployed.)

Discussion Questions

1. There was no single "escalation to Domain Admin" moment in this intrusion — the attacker harvested a Domain Admin credential rather than escalating to one. Explain how standing privilege made this possible, and how just-in-time access would have changed the Day 2 outcome even though the attacker still dumped the credential from memory.
2. The decisive event was a technician using a Domain Admin account on a warehouse laptop two days before the attacker arrived. PAM controls cannot un-type a password that was already typed. So which control actually addresses this — and is it a preventive control, a detective one, or both? Defend your answer.
3. Tellaro's backups were online and reachable by a domain-joined Domain Admin account, so Domain Admin owned them. Discuss why backup protection is, in part, a privileged-access problem and not only a backup problem. How does this connect to the break-glass and tiering ideas from this chapter?
4. Compare Tellaro to Meridian (Case Study 1) point by point. The two organizations had the same initial compromise (a phished laptop). Identify the three controls whose presence or absence most determined that one became a contained incident and the other a company-ending breach.
5. The responders argued the evidence "existed but did not scream." Explain, in terms of baselines and signal-to-noise, why the same telemetry is high-fidelity in a PAM environment and nearly invisible in a flat one. What does this imply about deploying detections before you have constrained the behavior you are trying to detect?

Your Turn

You are handed the Tellaro timeline as an incident responder before the Day-4 encryption — say, you catch the Day-2 LSASS alert. Write a one-page response plan: your first five containment actions (in order, with justification), which privileged accounts you would assume are compromised and what you would do about them immediately (think credential rotation and session termination), and how you would determine the attacker's current foothold and blast radius. Then write the post-incident privileged-access remediation memo to Tellaro's leadership: the three controls you would mandate first and the rung each one closes. (This deliberately bridges to the incident-response lifecycle you will study in depth in Chapter 24.)

Key Takeaways

• A real escalation to Domain Admin is rarely a dramatic exploit; it is land, harvest, move repeated until a privileged credential is found sitting somewhere it should not be. The attacker need not be sophisticated — only the environment need be ordinary.
• Local admin for every user hands the attacker rung 2 for free; a shared local-admin password turns one compromised machine into the whole fleet at rung 4. Removing local admin and deploying LAPS are the cheapest, highest-value controls in the chapter — and Tellaro lacked both.
• A privileged credential used on a low-trust machine is a compromised credential the moment that machine is. Only tiering (never expose it there) and vaulting + check-in rotation (make it dead if exposed) address this; password strength and login MFA do not.
• Standing privilege means the attacker who harvests a Domain Admin credential needs no further escalation. JIT converts that silent win into a noisy, blockable, detectable activation event.
• The evidence existed but did not scream. Without a constrained, instrumented privileged-access path, there is no baseline against which abuse stands out. PAM manufactures the visibility that makes privileged-abuse detection possible.
• The same initial mistake — one phished laptop — is a contained incident with PAM (Meridian) and a company-ending breach without it (Tellaro). That difference is the entire value proposition of this chapter.