Clustered Points of Failure - Attacking Windows Server Failover Clusters

## Overview

In this presentation, Garrett Foster, a security researcher at SpecterOps, examines the architecture and attack surface of Windows Server Failover Clustering (WSFC). Originally introduced in 1997 with Windows NT 4.0 Enterprise Edition as Microsoft Cluster Server, WSFC provides high availability for critical enterprise infrastructure—most commonly file servers and databases.

The investigation was sparked during an internal SpecterOps meeting when red team operators encountered unexpected behavior while executing an attack path. They had compromised a domain computer account that possessed the `WriteAccountRestrictions` permission (identified by Dirk-jan Mollema when computer account prestaging permissions are delegated) over a target machine object. The operators abused this permission to configure Resource-Based Constrained Delegation (RBCD) to impersonate an administrator and steal tier-0 credentials. However, execution failed across standard Impacket tools and exhibited anomalous routing: scheduled tasks executed on a completely different host than the cluster name targeted.

---

## Technical Analysis & Failover Cluster Internals

To investigate these anomalies, Foster deployed a three-node lab cluster hosting a clustered file share using the Failover Cluster Manager MMC snap-in. Setting up and running the cluster highlighted several key architectural and networking behaviors:

* **Logical Objects in Active Directory**: * **CNO (Cluster Name Object)**: An Active Directory computer account representing the cluster itself and its administrative namespace. * **VCO (Virtual Computer Object)**: A computer account created in Active Directory to represent the specific clustered service/role (e.g., a clustered file share or client access point). * **Member Nodes**: Physical or virtual servers participating in the cluster. Only one node can own or host a specific CNO or VCO resource at any given time. * **Cluster Inter-Node Networking**: * **NetFT (Network Fault Tolerant Virtual Adapter)**: A virtual adapter installed on each cluster node through which internal cluster communication flows. * **Heartbeats (UDP Port 3343)**: Nodes send sequential 50–70 byte packets every second to monitor node health. On Windows Server 2019, if a node registers up to 20 consecutive missed heartbeats (pings without pongs), it is flagged as unhealthy and removed from active clustering. * **Management RPC (TCP Port 135 & Dynamic Ports)**: The cluster API binds to RPC port 135 for Endpoint Mapper (EPM) resolution, which redirects traffic to a dynamic high port (e.g., 55602) to handle cluster management calls.

---

## Tooling Discrepancies and Findings

Foster answered the initial operational question regarding why native Windows tools succeeded while Impacket scripts initially failed:

* **Host Resolution & File Writing**: Standard Impacket command execution scripts (such as `wmiexec.py` or `smbexec.py`) typically write files to disk and attempt to retrieve output over SMB. When binding to a virtual cluster namespace (the CNO or VCO), the virtual file paths could not be located on the underlying node, causing errors such as "bad network name" and resolution failures. * **Native Snap-ins**: The native Windows Scheduled Tasks snap-in properly handles RPC string bindings and endpoint resolution to the node currently hosting the resource. * **Impacket Resolution**: Foster noted that Impacket tools succeed against cluster endpoints when configured to run commands silently without expecting redirected file output.