Critical Dependencies Outside the DC: Hypervisors, Backups, PKI, and Management Agents.

1. Core mechanism

During a domain compromise or outage, the first question is not only who is a member of a group on the DC. It is also which identity paths the external systems that manage and restore the DC depend on.

Interfaces and specifications

• Hypervisor management plane: a separate management domain that can provide console, snapshot, and disk access to a DC VM; guest AD ACLs do not by themselves constrain this plane.
• Backup control plane: backup server, repository, and restore-operator roles. Access to a backup copy is a recovery authority distinct from ordinary file permissions inside AD-managed systems.
• PKI: the Enterprise CA, certificate templates, and enrollment-agent chain. A misconfigured template or weak private-key protection can produce identity material independently of a password.
• Management agent: RMM, monitoring, or patch-agent accounts and service channels. Track permissions separately between the host running the agent and the targets it manages.

Four planes, four boundaries

Hypervisor, backup, PKI, and management agents do different jobs. What they share is that each can represent a management or recovery path outside AD. An admin role in one plane does not automatically grant an admin role in another.

At minimum, an inventory row should record the owner, authentication path, delegated role, protected asset, and independent evidence source. This is a model for making boundaries visible, not a claim about any particular deployment.

Separate recovery authority from daily access

Hypervisor console, snapshot, or disk access may use a management path separate from the guest operating system's access checks; a sound file ACL therefore does not prove that VM storage is protected from access outside the guest. Backup repository and restore permissions may also be enforced in a recovery control plane separate from daily guest file ACLs. The exact authorization point in a restore flow depends on the backup product and repository configuration; do not assume every restore acts before the OS access check.

For PKI, certificate issuance and private-key protection are separate questions. For a management agent, its credential must not be treated as identical to a human administrator's account.

State and data flow

1. List AD identities and target assets.
2. For the hypervisor, backup, PKI, and agent, record the owner, authentication path, and delegated role.
3. Identify independent log, role-assignment, template, or repository evidence for each row.
4. If a control fails, describe its effect only within that boundary; do not infer a lab result or automatic containment.

2. Exploitation

Broken trust assumption

An attacker need not log on directly to a DC. Reaching a high-impact role in an external management or recovery plane can open a path around guest-level AD controls.

Technical prerequisites

• The external plane authenticates with an AD identity or a credential/certificate derived from AD.
• A role assignment, repository, or template grants excessive permissions or relies on a shared account.
• The boundary is not logged independently, or an owner cannot verify console or restore activity.

Exploitation mechanism

Red analysis does not merge four dependencies under one 'domain admin' label. It traces the identity path, control plane, and recovery effect separately. Hypervisor snapshot/disk access, backup restore, PKI issuance, and agent command execution are different mechanisms; bound each claim unless evidence shows that the mechanism exists in the environment.

A path from outside to inside

Becoming a guest administrator with a management credential, reaching a guest disk through a hypervisor console, and restoring from a backup repository are not the same attack. A common mistake is to measure all of them only through AD group membership.

Separate assumptions for PKI and agents

Enrollment rights on a certificate template cannot be assessed independently from the template's subject/SAN and private-key policy. For an agent account, the label 'service account' alone does not explain which commands can run on which targets.

3. Defense & Detection

Telemetry scope

• Monitor hypervisor console, snapshot, and disk access in the platform audit source, separately from AD events.
• Correlate backup role assignments, repository access, and restore/delete operations with their own owner and timeline.
• Verify CA template changes, enrollment, and private-key use in PKI records; verify agent policy and command execution in the agent platform logs.
• Constrain external management accounts with applicable controls such as tiering, phishing-resistant MFA, or short-lived access; verify product and version support before assuming a feature is required.

Events and relevant fields

• In the1102 fixture, the Subject fields identifying the log-clearing account are under UserData/LogFileCleared. A Security-log clear does not establish which action occurred in a hypervisor, backup, PKI or agent system.
• AD events do not replace evidence of external console, restore, certificate-issuance, or agent-command activity.

Look for evidence in the right system

An AD event such as 1102 does not prove activity in an external control plane. Platform audit, backup audit, CA records, and agent telemetry are separate sources; correlate them only when shared time and identity fields support it.

Order the controls

Start with the access inventory and owners, then strengthen authentication, then review role/restore/template boundaries, and finally correlate alerts. This order makes hidden dependencies visible first.

Detection logic · KQL

// Selects AD-side log-clear candidates; not run. No external-platform correlation is performed here.
SecurityEvent
| where EventID == 1102
| project TimeGenerated, Computer, SubjectUserName, SubjectLogonId

Query assumptions

• This example assumes the SecurityEvent table has EventID, TimeGenerated, Computer, SubjectUserName, and SubjectLogonId fields; verify the actual workspace schema.
• It selects AD Security events only. External-platform correlation requires a separately verified organization-specific table/schema and shared identity and time fields.
• Event 1102 alone is not evidence of an external dependency, hypervisor/backup/PKI/agent activity, or compromise.

False positives

• Authorized Security log maintenance can also produce Event 1102.
• If correlation is added separately, records may be misleading unless platform clocks and identity fields are verified.

Hardening

• Operate hypervisor and backup management with separate admin tiers and MFA; do not reuse one domain-admin account as a shared management account.
• Design repository and restore roles around least privilege, dual control, and immutable/offline-copy targets; verify product support.
• Review CA template/enrollment and private-key protection separately; restrict changes with owner approval and auditing.
• Separate management-agent credentials by host and role, limit command scope, and store agent logs separately from AD logs.
• During a recovery tabletop, do not conclude that a DC can be restored from backup until the AD identity dependencies and independent evidence for console, restore, CA, and agent paths are established.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Microsoft-Windows-Eventlog" Guid="{fc65ddd8-d6ef-4962-83d5-6e5cfe9ce148}"/><EventID>1102</EventID><Version>0</Version><Level>4</Level><Task>104</Task><Opcode>0</Opcode><Keywords>0x4020000000000000</Keywords><TimeCreated SystemTime="2026-10-01T10:00:00.0000000Z"/><EventRecordID>12001</EventRecordID><Channel>Security</Channel><Computer>DC01.outreason.example</Computer><Security/></System><UserData><LogFileCleared xmlns="http://manifests.microsoft.com/win/2004/08/windows/eventlog"><SubjectUserSid>S-1-5-21-111-222-333-500</SubjectUserSid><SubjectUserName>backup-admin</SubjectUserName><SubjectDomainName>OUTREASON</SubjectDomainName><SubjectLogonId>0x4a21</SubjectLogonId></LogFileCleared></UserData></Event>

Two reality checks

Assumption: Managing hypervisor and backup administrators by checking only the DC security groups is enough to protect the DC.

In fact: These planes are privilege boundaries separate from guest access checks. Do not infer their scope until the owner, authentication path, delegated role, and independent audit evidence have been reviewed.

Assumption: An Enterprise CA or management agent automatically creates a persistent backdoor into AD.

In fact: Risk depends on concrete configuration such as template/enrollment/private-key settings or agent command and credential scope. Do not claim a persistent backdoor without evidence that supports it.

Sources

• Microsoft Learn · Hyper-V security best practices
  Hyper-V management and host security; evaluate the host/guest boundary separately.
• Microsoft Learn · Windows Server Backup Feature Overview (Windows Server 2012 / 2012 R2)
  Feature description / Practical applications: full-server, volume, system-state and file/folder backup and recovery scope. Historical feature overview, not a deployment role assignment or a current-version test.
• Microsoft Learn · Securing Public Key Infrastructure (PKI) (Windows Server 2008–2012 R2)
  CA hierarchy, technical controls, CA keys/critical artifacts, monitoring and compromise-response sections. Historical PKI guidance; not evidence of a specific template misconfiguration in this lesson.
• Microsoft Learn · Windows event 1102
  Event XML Version0: Microsoft-Windows-Eventlog, Level4/Task104/Keywords0x4020000000000000; UserData/LogFileCleared eventlog namespace and Subject fields; no external-platform attribution.