T1078 — Valid Accounts — is the hinge around which most serious intrusions in Windows Active Directory environments turn. This article traces how credential abuse operates across the full attack lifecycle, explains what AD tiering actually prevents, maps specific controls to the techniques they disrupt, and sets out the detection signals that matter.
T1078 Is Not a Single Technique — It Is a Hinge
The MITRE ATT&CK framework describes T1078 — Valid Accounts — as adversary abuse of legitimate credentials to gain or maintain access while blending into normal authentication flows. That description is accurate but understates what T1078 represents in practice. In Windows Active Directory environments, it is rarely an isolated event. It is the mechanism that connects credential theft to lateral movement, and lateral movement to domain-wide impact. It is the reason that a single compromised workstation can, in a poorly architected estate, become a complete domain compromise within hours.
T1078 is effective because it requires no exploitation of a vulnerability in the target system. The attacker simply authenticates. The authentication succeeds because the credentials are valid. The resulting activity looks like normal administration. This is what makes the technique so persistent across incident response engagements and so central to human-operated ransomware playbooks: the authentication infrastructure that defenders rely on becomes the attacker's primary tool.
The Sub-Techniques: What T1078 Actually Covers
ATT&CK breaks T1078 into four sub-techniques that describe the type of account being abused.
T1078.001 covers default accounts — built-in or vendor-provided accounts such as the Windows local Administrator or Guest account, particularly when these are shared across systems or left in their default state. T1078.002 covers domain accounts — AD-managed users, domain admins and service identities — and is associated with Initial Access, Persistence, Privilege Escalation and Defense Evasion simultaneously, which illustrates why it sits at the centre of the attack lifecycle rather than at a single point in it. T1078.003 covers local accounts, where ATT&CK explicitly highlights password reuse as the mechanism that enables abuse at scale across multiple machines, and links local account abuse directly to OS credential dumping. T1078.004 covers cloud accounts, though that sub-technique is outside the scope of this analysis, which focuses on legacy on-premises AD environments.
In practice, T1078 becomes operationally meaningful only when paired with techniques that obtain credentials — particularly OS Credential Dumping via LSASS — and techniques that enable their use over remote management channels such as RDP, SMB and WinRM.
Why Credential Exposure Is the Foundational Problem
In a legacy Windows estate, privileged accounts authenticate onto many systems in the course of normal operations. Server administrators log into member servers to troubleshoot. Domain admin accounts are used from ordinary workstations because it is convenient. Service accounts run scheduled tasks across multiple systems with static, long-lived passwords. Each of these authentication events leaves traces — NTLM hashes, Kerberos tickets, and in some configurations plaintext credentials — in LSASS memory and in other OS credential stores.
This is the foundational problem. An attacker who gains local administrator or SYSTEM-level access to any system on which a privileged account has authenticated can extract those traces and replay them. They do not need another vulnerability. They need only the credentials that normal administrative practice has deposited on the system they have already compromised.
Human-operated ransomware operators understand this and exploit it methodically. The consistent pattern documented across incident response engagements is not a sophisticated exploit chain — it is patient credential harvesting, progressive privilege escalation and lateral movement that uses the organisation's own authentication infrastructure. The credential dumping flywheel looks like this: compromise a low-trust endpoint, gain local admin or SYSTEM, dump credentials from LSASS and other stores, replay those credentials via Pass-the-Hash or Pass-the-Ticket over remote services, expand reach, repeat until higher-privilege credentials are obtained. Microsoft's ransomware analysis describes this explicitly: operators continually steal credentials and progressively gain higher privileges until they control a domain administrator-level account.
T1078 Across the Attack Lifecycle
Initial Access. The most straightforward application of T1078 at initial access is the purchase or theft of credentials for externally reachable services. VPN portals, Remote Desktop services and cloud management interfaces all accept valid credentials without requiring any exploitation of the target host. The FBI/CISA/ACSC Play ransomware advisory describes initial access via valid accounts likely purchased on the dark web, combined with RDP and VPN for entry. The attacker authenticates normally. There is no anomalous process execution. There is a login that looks like any other.
Even when initial access is vulnerability-based, attackers pivot quickly to valid credentials because credentials enable stealthy expansion that is substantially harder to detect than continued exploitation. Microsoft's analysis of Volt Typhoon operations illustrates this: the transition from initial device compromise to extracting Active Directory credentials and then authenticating to other systems exactly as authorised users do, making subsequent activity almost indistinguishable from legitimate administration.
Persistence. Once valid credentials are obtained, persistence often requires no malware. Account creation and manipulation — adding accounts, modifying group memberships, adjusting credentials — preserves access in ways that are difficult to detect without active monitoring of privileged group membership changes. Credentialed persistence via built-in scheduling and services is equally effective: using an existing privileged or service account to run a payload through a scheduled task or Windows service is far less likely to trigger alerts than deploying a custom implant. Microsoft's ransomware analysis documents this pattern explicitly — credential dumping to obtain service account credentials, then using those credentials in scheduled tasks for persistent access and re-deployment.
Lateral Movement. Lateral movement with valid accounts uses remote administration channels that exist precisely because they accept credentials — RDP, SMB, WinRM, WMI and PsExec-equivalent tooling. An attacker with valid domain credentials can authenticate to any system those credentials are permitted to access. In flat estates with broad domain admin usage, that is frequently every system on the network.
Pass-the-Hash and Pass-the-Ticket remove even the requirement for plaintext credentials. Pass-the-Hash authenticates using stolen NTLM hashes without needing the underlying password. Pass-the-Ticket authenticates using stolen Kerberos tickets — service tickets or Ticket Granting Tickets — without the password entirely. Both are enabled primarily by LSASS memory dumping. The NotPetya incident illustrates the consequence at scale: credential theft combined with administrative share access and PsExec-style remote execution to propagate across entire networks without any further vulnerability exploitation.
Privilege Escalation. In Active Directory environments, privilege escalation is frequently credential escalation. Attackers harvest credentials at whatever privilege level their current access allows, then seek progressively higher-privilege accounts: workstation administrator to server administrator, server administrator to domain administrator, domain administrator to full control of the AD control plane. Each step uses the same mechanism — credential dumping and replay — applied to successively more valuable targets. The endpoint of this progression, when nothing interrupts it, is Domain Admin or equivalent control, at which point the attacker has the ability to modify Group Policy, manipulate or disable any account in the estate, and reach the backup infrastructure that represents the last line of recovery.
Defense Evasion. Valid credentials are intrinsically valuable for defense evasion because authenticated actions look like legitimate administration. An attacker operating under a domain admin account is functionally indistinguishable from a legitimate administrator unless behavioural baselines, privileged access monitoring and logon restrictions are in place. This is typically paired with explicit log manipulation — clearing Windows Event Logs to remove evidence of credential dumping, tool execution and lateral movement — and with disabling or degrading security tools. The Play ransomware advisory documents this combination precisely: disabling antivirus tools and removing logs as explicit steps in the intrusion sequence, executed under domain admin credentials obtained via Mimikatz.
Impact. With domain-level credential control, impact at enterprise scale becomes straightforward. Group Policy Modification is a particularly powerful path: GPO is designed for centralised, estate-wide control, and an attacker with the ability to modify Group Policy objects can distribute payloads, disable protections, or subvert controls across every managed system in the domain simultaneously. The Play ransomware advisory documents this explicitly — domain admin credentials obtained via credential dumping, executables distributed via GPOs, culminating in estate-wide encryption. Data recovery from this state requires bare-metal restore, and in healthcare environments the clinical consequences reach far beyond the IT estate.
What Active Directory Tiering Is Trying to Prevent
AD tiering exists to break the credential vertical movement that the attack lifecycle above depends on. The model enforces who can administer what, and from where, so that compromise of lower-trust systems cannot trivially escalate into control of the AD control plane. Microsoft's Tier 0 guidance states the core rule plainly: credentials from a higher-privileged tier must not be exposed to lower-tier systems. Any system or account that can manage a higher tier is effectively a member of that tier, regardless of how it is labelled.
This rule directly targets the attacker's flywheel. If Tier 0 credentials — Domain Admins, Enterprise Admins, accounts with control over Active Directory — never authenticate on Tier 1 servers or Tier 2 workstations, then compromising a workstation cannot yield Tier 0 credentials. The chain from workstation compromise to domain control is broken at the credential exposure point. The attacker can still dump LSASS on the compromised workstation, but the output is Tier 2 user material — still bad, but materially less likely to contain domain admin hashes or TGTs, and materially less likely to bridge into Tier 0.
The Three Tiers and the Transitivity of Trust
Tier 0 — the control plane encompasses assets and identities with direct or indirect administrative control over Active Directory and its identity management systems. This includes the obvious: Domain Controllers, Domain Admins, Enterprise Admins, Schema Admins. It also includes less visible indirect control points — virtualisation hosts that could extract a Domain Controller's memory or disk, backup systems with domain-level access, and any account or system capable of modifying Tier 0 assets. Microsoft is explicit on this point: if a system can administer a higher tier, it is that tier. The label on the system is irrelevant; the access path is what determines its tier classification.
Tier 1 — server and application administration covers member servers and enterprise applications. The objective is to prevent Tier 1 administrators from being able to affect Tier 0, and to minimise the scope of what is classified as Tier 0. Tier 1 admin accounts should be able to manage servers and applications within their scope, but logon restrictions must prevent them from authenticating to Domain Controllers or Tier 0 management infrastructure.
Tier 2 — workstation and user endpoint administration represents the highest-exposure tier — the systems most likely to be reached by phishing, commodity malware and opportunistic attackers. It is where most incidents begin. Tier 0 and Tier 1 credentials should never appear on Tier 2 systems. An administrator troubleshooting a workstation should authenticate with a Tier 2 administrative account, not a server admin or domain admin account.
The transitivity of trust is the structural implication that organisations most commonly underestimate. If a Tier 2 system can administer a Tier 1 server, it effectively becomes Tier 1. If it can administer Tier 0, it becomes Tier 0. Every access path that crosses tier boundaries is a potential escalation route, and attackers using AD attack graph tooling will identify those paths systematically. The number of exploitable edges in an AD environment is directly proportional to the degree of privilege overlap — and tiering, properly implemented, is the mechanism that removes those edges.
Account Separation, Domain Admins and Service Accounts
The administrative model that supports tiering requires distinct accounts for distinct purposes. In a well-tiered estate, an administrator has a standard user account for day-to-day productivity work, a Tier 2 admin account for workstation management, a Tier 1 admin account for server management, and a Tier 0 admin account for control plane operations. Each is used only from the appropriate administrative environment and never carries privileges beyond its tier.
A practical taxonomy for legacy on-premises estates looks like this: standard user accounts have no local admin rights and are the highest-exposure account class; Tier 2 admin accounts are restricted to workstation administration and blocked from authenticating to servers or Domain Controllers; Tier 1 admin accounts manage member servers and applications but are prevented from administering Tier 0 assets; Tier 0 admin accounts are tightly scoped, rarely used, and subject to the strongest logon restrictions in the estate.
The Domain Admins group warrants specific treatment. The policy target for membership should be set to zero. In legacy Active Directory environments, true zero membership is rarely achievable immediately — dependencies, historical accounts and accumulated process will need to be worked through. But the point of setting the target to zero is not the immediate achievement of it. It reverses the question: instead of asking why an account should be removed from Domain Admins, the organisation must now justify why any account should be in Domain Admins at all. Every occupant of the group becomes a documented exception requiring positive justification.
Break-glass accounts for genuine emergency access should exist — Microsoft's Tier 0 guidance calls these out explicitly for scenarios where normal administrative paths are unavailable. But they should be sealed in a dual-person access process, audited on every use, and emphatically not standing members of Domain Admins available for convenience.
Service accounts require equal rigour. Accounts running scheduled tasks, backup jobs or application services should carry the minimum rights needed for their function. Domain Admin rights assigned to a service account for convenience represent a significant and frequently overlooked exposure: service account credentials are long-lived, rarely rotated, present on multiple systems, and actively sought by attackers because a compromised service account with Domain Admin rights provides persistent, stealthy, domain-wide access. Microsoft is explicit on this — AD admin groups should contain people, not service accounts. Delegation should be used instead.
Merger Scenarios: Multi-Domain and Multi-Forest Environments
Cross-organisational mergers introduce a distinct category of identity risk that sits outside the standard single-domain tiering model. Two scenarios are particularly common and require different responses.
Scenario A — The Merger That Never Finished. In many organisations, a merger completed five years ago has left three domains and two or three forests still operating with bi-directional trust relationships throughout. The political rationale at the time was to keep things running — clinical services, operational systems, shared infrastructure — without the disruption of a domain consolidation project. That rationale was often correct. But the security consequence is a credential environment that makes tiering structurally very difficult.
Bi-directional forest trusts mean that a compromised account in one domain can be used to authenticate across trust boundaries into the others. If Domain A has weak tiering and poor credential hygiene, an attacker who achieves Domain Admin in Domain A can leverage that trust to move laterally into Domain B and Domain C without needing to compromise those domains independently. The SID history attack and Kerberoasting across trusts are well-documented techniques that exploit exactly this configuration. Golden Ticket attacks in one domain can be extended across trust boundaries if the trust is not Selective Authentication-enforced.
The persistent multi-domain state also multiplies the attack surface in other ways. Each domain has its own Domain Controllers, its own privileged group memberships, its own service accounts and its own legacy configurations. Maintaining consistent tiering governance across three separate domains with their own IT teams and operational histories is substantially harder than maintaining it in one. Drift accumulates. Exceptions proliferate. The attack graph grows with each domain that is not brought to the same security baseline.
For organisations in this state, the security posture question is not simply about improving tiering within each domain. It is about whether the bi-directional trust relationships are the right long-term architecture, and whether domain consolidation should be treated as a security programme rather than an IT rationalisation exercise.
Scenario B — Planning a Merger Where Neither Organisation Has Tiering. When two or more organisations are planning to merge and neither has meaningful tiering or strong domain security, the merger window is an opportunity that should not be missed. The worst outcome is connecting two poorly-secured domains via trust relationships and then attempting to harden both simultaneously — because each domain's weaknesses now become the other's exposure.
The question of whether to consolidate into a single domain or to maintain separate domains during the merger period is a genuine architectural decision, and the answer depends on several factors. Timeline is one. Technical debt is another. But the most important factor is the risk trajectory: a single well-secured domain is a substantially better security outcome than two separately-managed domains with trust relationships, even if consolidation takes longer to achieve.
If consolidation is the direction, the merger period should prioritise getting both organisations to a minimum security baseline before connecting them — not after. That means deploying LAPS, removing unnecessary Domain Admin accounts, separating service account rights, and establishing basic logon restrictions in both organisations before any trust relationships are created. Trust should be introduced last, not first.
If maintaining separate domains during a transition period is the operational decision, trust relationships should be restricted from the outset. Selective Authentication rather than domain-wide authentication, one-directional trust where possible rather than bi-directional, and explicit monitoring of cross-domain authentication events reduce the risk that one domain's compromise immediately translates into the other's.
The Decision Point: Consolidate or Keep Separate. The decision between consolidating to a single domain in a hybrid Entra configuration and keeping domains separate to expedite operations comes down to one honest question: which path results in a better security state faster?
Consolidation to a single Entra-connected domain is the architecturally correct outcome. A single hybrid domain with consistent tiering, cloud-native device management through Intune, and Conditional Access enforced through Entra ID is substantially more defensible than a multi-domain estate with trust relationships. It eliminates cross-trust attack paths, reduces the administrative complexity of maintaining consistent security policy, and positions the organisation for the cloud-native endpoint management north star described elsewhere in this article.
But consolidation takes time — typically twelve to eighteen months for organisations of meaningful size, longer in healthcare where clinical system dependencies on specific domain memberships need careful management. If the merger timeline requires operational connectivity before consolidation is complete, that interim period needs explicit security governance: defined trust scope, monitoring of cross-domain privilege use, and a committed consolidation timeline rather than an open-ended intention.
The worst outcome is treating the separate domain state as permanent because consolidation is hard. In a merged organisation with three domains and bi-directional trust, the attacker does not respect the administrative boundary between domains. The security architecture needs to reflect that reality, not the organisational history that created it.
The Clean Source Principle and Privileged Access Workstations
Microsoft's privileged access guidance is anchored in the clean source principle: all security dependencies must be as trustworthy as the object being secured. Applied to Tier 0 administration, this means that Domain Controllers and AD identity management systems should only ever be administered from devices and through paths whose trustworthiness is equivalent to Tier 0.
Privileged Access Workstations implement this principle in hardware. A Tier 0 PAW is a restricted device — no email, no web browsing, no general-purpose use — whose sole function is to provide a hardened, monitored administrative path to Tier 0 assets. It should not be reachable from lower-tier systems, should have a minimal software footprint, and should apply the strongest available endpoint hardening. Administering Domain Controllers from a standard productivity workstation violates the clean source principle regardless of any other controls in place: any malware or attacker that has access to that workstation has access to whatever credentials are used from it.
For Tier 1 administration, PAWs or comparably controlled admin workstations provide the same architectural benefit at a lower trust level. The overhead of maintaining dedicated administrative devices is real, but it should be weighed against the overhead of recovering from a domain compromise that PAWs would have prevented.
Credential Hygiene: Authentication Policies, Protected Users, LAPS and gMSA
Tiering defines where credentials should and should not appear. Several technical controls enforce those boundaries and reduce the value of credentials that are captured despite the controls.
Authentication Policies and Authentication Policy Silos, available from Windows Server 2012 R2 onwards, allow restricting where privileged accounts can request Ticket Granting Tickets. Even if a Tier 0 credential is stolen, an authentication policy can prevent that credential from being used from an unauthorised device — no TGT is issued. Microsoft explicitly notes that denied requests can be monitored and treated as alerts, providing a detection signal that is difficult for attackers to avoid.
Protected Users is a security group whose members receive a set of automatic credential protections: NTLM authentication is disabled, Kerberos delegation is blocked, credential caching is restricted, and ticket lifetimes are shortened. Placing privileged accounts in Protected Users reduces the material available to credential dumping tools and constrains the protocols through which those credentials can be replayed.
Credential Guard protects NTLM hashes and Kerberos TGTs by isolating the LSASS process in a virtualisation-based security container that cannot be accessed by the host OS. It is explicitly designed to prevent Pass-the-Hash and Pass-the-Ticket by removing the credential material those techniques rely on from accessible memory. Where Credential Guard is compatible with the estate, it should be deployed on systems used for privileged administration.
Windows LAPS eliminates shared local administrator credentials across the estate. Without LAPS, a single captured local admin hash can authenticate to every machine that shares the same password — a classic lateral movement multiplier. With LAPS, each machine has a unique, automatically rotated local admin password stored in Active Directory with controlled read permissions. LAPS also supports managing the DSRM password on Domain Controllers, which has relevance to Tier 0 recovery scenarios.
Group Managed Service Accounts eliminate static password exposure for services and scheduled tasks. A gMSA is a domain account usable across multiple servers without manual password management — the domain automatically rotates the password, and services retrieve it on demand. In a tiered design, gMSAs combined with logon restrictions and minimal-rights delegation prevent service account credentials from serving as durable, stealthy lateral movement paths across the estate.
Just Enough Administration and Just-in-Time Privilege
Even well-tiered organisations face a practical question: how do administrators get work done without constantly using broad admin credentials? Two controls address this directly.
Just Enough Administration restricts what an administrator can do in a given context by defining tightly scoped role capabilities — specific PowerShell cmdlets and programmes — exposed through controlled remote endpoints. Rather than granting full server admin rights to perform a routine task, JEA allows that task to be performed with no more privilege than is required. Audit transcripts of JEA sessions provide a record of what was done. If a JEA-scoped account is compromised, the attacker's capability within that session is limited to the commands the role definition permits.
Just-in-Time privilege access reduces the duration of standing group membership. Rather than leaving an account as a permanent member of a privileged group, JIT models activate group membership on demand and for a defined time period — after which membership expires automatically. Microsoft's time-limited Kerberos ticket approach, tied to role activations, means that even if a ticket is stolen after a JIT elevation, its useful window is constrained. Both JEA and JIT reduce the time and the places where high-value credential material is active and therefore dumpable.
Secondary Benefits Across the ATT&CK Framework
Tiering's primary effect is reducing the value of stolen credentials and the surface on which they can be captured. Its secondary effects reach across multiple ATT&CK tactic areas.
On lateral movement, tiering reduces attacker freedom to use credentialed admin channels toward Tier 0 assets. RDP, SMB, WinRM and WMI-based movement all require the right credentials on the right system — and tiering, logon restrictions and authentication policies together constrain what the right credentials are and where they can be used. Pass-the-Hash and Pass-the-Ticket are weakened because fewer high-value hashes and tickets exist on low-tier systems, and Credential Guard makes extracting what does exist substantially harder.
On persistence, tiering forces the removal of over-privileged service accounts and the review of scheduled task and service account configurations. Accounts that previously provided durable persistence because of accumulated Domain Admin rights become constrained to their actual operational scope. Monitoring of privileged group membership changes — a natural consequence of tiering governance — makes T1136 and T1098-style account manipulation harder to sustain undetected.
On defense evasion, tiering does not prevent an attacker from disabling tools or clearing logs on a compromised host. But it does prevent those actions from becoming domain-wide. Disabling security tooling broadly typically requires domain-wide privileged access — the kind that tiering, implemented properly, should prevent an attacker from reaching from a workstation compromise.
On discovery, attackers can still perform reconnaissance from a foothold, but tiering reduces the ability to convert that information into control. Account and permission group discovery identifies privileged targets, but tiering reduces privilege overlap — the degree to which a single group membership grants control across multiple tiers — and therefore shrinks the number of exploitable edges in the AD attack graph.
On impact, tiering most directly reduces the attacker's reach to the control levers used for mass deployment. Group Policy Modification requires the ability to modify GPOs, which tiering restricts to authenticated Tier 0 accounts from Tier 0 paths. Domain-wide ransomware deployment and inhibiting system recovery at enterprise scale both require the domain-level control that a well-tiered estate makes significantly harder to reach from a standard workstation compromise.
Detection: What to Monitor
Because T1078 uses legitimate authentication mechanisms, detection is primarily behavioural and contextual — what account, where, when, and from which device.
Authentication telemetry is the primary signal layer. Event ID 4624 — successful logon — on destination systems allows baselining of administrative logon patterns by account tier and host tier, making anomalous cross-tier authentications detectable. Event ID 4648 — explicit credentials — is relevant to lateral movement tooling, scheduled task operations and RUNAS-style behaviour. Kerberos ticket events on Domain Controllers — 4768 for TGT requests and 4769 for service ticket requests — allow identification of anomalous ticket issuance patterns, such as Tier 0 account tickets being requested from non-Tier 0 devices. Privileged group membership changes across the security group management event category detect account manipulation patterns around Domain Admins and other sensitive groups.
For credential replay detection, Pass-the-Hash and Pass-the-Ticket correlate with anomalous NTLM logons and Kerberos service tickets without the expected preceding logon chains. LSASS access monitoring — through ASR rules, Defender for Endpoint or Sysmon-based configuration — provides early warning of credential dumping attempts before the harvested material is used.
Where authentication policies and silos are deployed, denied privileged TGT requests — Tier 0 accounts attempting to authenticate from devices not covered by their authentication policy — are high-confidence signals of either credential misuse or active attack. Microsoft notes explicitly that these denials are easy to monitor and should be treated as urgent alerts.
GPO modification monitoring provides a domain-wide deployment warning. Changes to SYSVOL policy paths or Group Policy Object permissions should be treated as high-severity events given the distribution potential of GPO abuse.
Limitations: What Tiering Does Not Fix
Tiering reduces attacker options — it does not eliminate them. A direct compromise of a Tier 0 system, a supply chain compromise, or theft of Tier 0 credentials on a Tier 0 PAW can still be catastrophic. Tiering's primary contribution is reducing the probability that common Tier 2 compromises — the phished workstation, the exploited application server — escalate into Tier 0 domination. It changes the outcome of the most frequent type of incident, not the outcome of every possible attack.
Operational complexity in legacy estates is a genuine constraint. Tiering requires redesigning administrative workflows, replacing or restricting service accounts, auditing delegated rights accumulated over years, and managing the transition without breaking operational processes. The work involved in removing Domain Admin from a service account that has accumulated it for a decade is often non-trivial. This is why a phased, structured approach — starting with Tier 0 classification and enforcement, then progressively hardening account separation and logon restrictions — is more likely to succeed than attempting comprehensive tiering simultaneously.
Jump servers, used without the clean source principle, can introduce lower-trust dependencies into high-trust admin paths. A jump server is only as trustworthy as its management path. If the jump server is managed from a standard workstation, it has become a Tier 2 asset sitting in front of Tier 0 infrastructure — the opposite of what it was intended to achieve.
The objective of AD tiering is attack-path engineering: removing or degrading the credential exposure edges that attackers rely on most. It makes the journey from T1003 credential dumping through T1078 valid account abuse to domain-wide execution substantially longer, more detectable and in many cases impassable. In estates where tiering is well-implemented and complementary controls are in place, a compromised workstation is a contained incident. In estates where it is not, it is frequently the start of something much worse.
