Clustered Points of Failure: Attacking Windows Server Failover Clusters

Clustered Points of Failure: Attacking Windows Server Failover Clusters

Speaker: Garrett Foster, Security Researcher, SpecterOps

Conference: Black Hat USA 2025 — August 6-7, 2025, Mandalay Bay, Las Vegas

YouTube: https://www.youtube.com/watch?v=FSRmPwfMYs0

Reading Time: ~9 minutes

Type: Briefing

TL;DR

Windows Server Failover Clustering (WSFC) introduces hidden Active Directory machine accounts — Cluster Name Objects (CNOs) and Virtual Cluster Objects (VCOs) — that share password material across every node in the cluster via LSASS, making node compromise equivalent to full cluster compromise. Misconfigured CNO permissions have created real-world paths from clustered service accounts to full domain compromise in enterprise environments, and the recently disclosed "Bad Successor" vulnerability dramatically raises the stakes.

Introduction

Windows Server Failover Clustering has been a cornerstone of enterprise high availability since 1997 — predating Active Directory itself. Used to protect file servers, databases (including SQL Server, Exchange, and SCCM), and other critical services, WSFC quietly creates AD computer accounts that most defenders have never thought about. SpecterOps researcher Garrett Foster set out to understand exactly how Kerberos authentication works across clustered nodes and discovered an attack surface that, in real enterprise environments, has connected clustered virtual accounts directly to Domain Controller sync and full domain takeover.

This talk bridges a gap between red team enablement and blue team awareness, delivering an LDAP filter, new BloodHound enumeration capabilities, and concrete remediations — while revealing that misconfigured cluster permissions in the wild are far more common than the industry assumed.

What Windows Failover Clustering Actually Creates in Active Directory

▶ Watch: Cluster components in AD (08:00)

When an administrator deploys a failover cluster using the Failover Cluster Manager MMC snap-in, two AD machine accounts are silently created:

• Cluster Name Object (CNO): The computer account representing the cluster's administrative access point. It carries the cluster's DNS name and reserved IP address.
• Virtual Cluster Object (VCO): A separate computer account for each clustered role (file share, SQL Server instance, etc.).

These objects are not standard computer accounts tied to physical hosts. They are virtual identities that float across whichever node currently owns the resource. At any point in time, any of the cluster's physical nodes might be acting as the active owner of the CNO or VCO — and that has profound implications for authentication.

The cluster uses a heartbeat protocol over UDP port 3343, with packets fired every second to detect node failure. When a node fails, the CNO and VCO migrate to the next healthy node. The critical question Foster investigated: how does Kerberos authentication still work if a service ticket was issued to one node's IP, but a completely different node is now responding?

The Shared Secret: Passwords in LSASS on Every Node

▶ Watch: Kerberos authentication explained (14:00)

The answer reveals a fundamental design decision that attackers can exploit. Foster discovered that when the cluster service starts, every node performs a logon for both the CNO and VCO accounts and loads their credentials into LSASS — the Windows process that manages authentication secrets. This means all three nodes in a three-node cluster simultaneously hold the password material for the CNO and VCO.

Reverse engineering the cluster service binary was required to fully understand how passwords are stored. The cluster database — a series of registry entries replicated to every node — stores an encrypted blob containing the current and previous passwords for these accounts. Foster, with help from coworker Evan McBroom (author of the LSA Whisperer project), reverse-engineered the blob structure using Ghidra and found that it uses a CSP (Cryptographic Service Provider) private key stored in a certificate pair, not DPAPI as initially suspected.

The resulting proof-of-concept decrypts the machine account passwords for both the CNO and VCO from any node with admin access, then derives the RC4-NTLM hash for use in pass-the-hash attacks.

The practical consequence: if you own any one node in the cluster, you own the entire cluster. A single Kerberos service ticket can be used to authenticate to all nodes by triggering a role move — no ticket modification required — enabling code execution across the full cluster with a single credential.

From Cluster Compromise to Domain Takeover

▶ Watch: CNO attack graphs (28:01)

The more alarming finding involves the permissions Microsoft's own documentation recommends for CNOs. Microsoft's setup guidance for WSFC has historically instructed administrators to grant the CNO the ability to create computer objects in a specified OU. In practice, administrators following troubleshooting guides have frequently granted far more: Generic Write, Create All Child Objects, Delete All Child Objects, or even Full Control on OUs or the domain object.

Foster pulled real-world attack graphs from enterprise environments across multiple verticals:

• Graph 1: CNO with Generic Write to an OU — permissions inherited down to a DC, enabling a DCSync (full domain compromise).
• Graph 2: CNO as a member of a security group with Full Control of the domain object — direct path to DCSync.
• Graph 3: CNO with rights over an Exchange server computer object, which is a member of Exchange Trusted Subsystem, providing a path to organization-level mail access.
• Graph 4: CNO with Create Computer Objects in an OU.

This last case — which on its own seemed low-risk — changed completely in May 2025 when Yuval Gordon of Akamai published the "Bad Successor" blog. The post detailed how the Windows Server 2025 Delegated Managed Service Account (DMSA) feature can be abused: if an attacker can create a DMSA object in an OU, they can leverage it to impersonate privileged accounts and compromise the domain. Since CNOs with Create Computer Objects permissions in an OU satisfy that precondition, what was once a "medium-severity" misconfiguration became a direct domain compromise path.

The Kerberos S4U2Self extension (Service for User to Self) further enables an attacker controlling a cluster account to forge service tickets for arbitrary users against services on the cluster — including domain administrators — using only the CNO or VCO credential material.

Scope of the Problem

▶ Watch: Attack surface data (34:01)

WSFC is not a niche technology. Foster presented telemetry from enterprise engagements showing:

• Nearly every large Active Directory environment contains at least one clustered role.
• The average enterprise had 141 unique clusters.
• The largest environment sampled had nearly 2,700 unique clusters.

Beyond SQL Server and file servers, clusters appear under ADFS (Always On Availability Groups), Exchange (Database Availability Groups), Microsoft Configuration Manager (SCCM), and even some Azure Stack configurations. The attack path documented in the talk's opening anecdote originated from a CNO in an Exchange DAG.

The LDAP filter Foster displayed at the start of the talk — (objectClass=msCluster-ClusterNode) — enumerates every clustered resource in a domain from any domain-joined machine.

Remediation and Detection

▶ Watch: Defenses (34:01)

For defenders:

• Audit CNO permissions immediately. The only Active Directory permission a CNO requires is "Create Computer Objects" in the specific OU where cluster VCOs will be created. Generic Write, Full Control, or permissions on OUs with broad inheritance are excessive and should be revoked.
• Monitor CNO authentication sources. Since the cluster registers a fixed IP for the CNO, any Kerberos authentication or NTLM login from a source address other than the expected cluster nodes is a high-fidelity indicator of compromise.
• Watch for CNO-initiated LDAP operations. CNOs do not need to perform LDAP queries outside of cluster maintenance operations; anomalous LDAP binds from cluster accounts warrant investigation.
• Treat CNOs and VCOs as Tier 0 assets. These accounts have access to credential material for services that, if disrupted, would cause significant business impact. Apply the same access controls and monitoring as domain controllers.
• Use the LDAP filter to enumerate your attack surface and add BloodHound queries for cluster objects to your regular AD review cadence.

For attackers (red team enablement): BloodHound support for cluster enumeration and attack path visualization is actively under development by the SpecterOps team.

Notable Quotes

"If you own the node, you own the cluster. It does not matter how you've gained control of it in any type of way." — Garrett Foster ▶ 36:02

"Cluster misconfigurations can lead to compromise — not just the domain, but those clustered services which are frequently Tier 0, the things that would keep you up at night if they were to fall over." — Garrett Foster ▶ 36:02

"Clustering is older than Active Directory itself, and we're creating these virtual identities — AD accounts that aren't mapped to a host. Treat them the same as active accounts, and give them the same type of respect." — Garrett Foster ▶ 36:02

Key Takeaways

• Windows Server Failover Clustering creates hidden AD machine accounts (CNO, VCO) that share password material across all cluster nodes via LSASS — owning one node means owning the entire cluster.
• A proof-of-concept tool can extract and decrypt CNO/VCO machine account passwords from the cluster registry database on any admin-access node, returning usable RC4-NTLM hashes.
• The "Bad Successor" DMSA vulnerability (May 2025) converted previously low-risk "Create Computer Objects" CNO permissions into a direct path to full domain compromise.
• Real enterprise environments average 141 clusters; one environment had nearly 2,700, representing a massive and largely unaudited attack surface.
• Defenders should immediately audit CNO/VCO AD permissions, monitor authentication source addresses for cluster accounts, and treat these virtual identities as Tier 0 assets.

Slides for this talk were not listed as available in the session bundle.