Win-DoS shows how RPC blind spots can turn Windows DCs into botnets

At a glance

What this is: SafeBreach’s research shows how Windows RPC and LDAP blind spots can be abused to crash domain controllers and endpoints, including a new Win-DDoS technique that turns public DCs into a botnet-like flood source.

Why it matters: It matters because identity infrastructure is also availability infrastructure, and IAM, AD, and PAM teams need to treat control-plane resilience as part of access governance, not a separate ops concern.

By the numbers:

• Gcore’s Q3-Q4 2024 Radar report revealed a 56% year-over-year increase in DDoS attacks compared with the same timeframe in 2023.
• Check Point’s Perimeter 81 said DDoS attacks are costing organizations approximately $6,000 per minute in downtime.

👉 Read SafeBreach’s analysis of Win-DoS, Win-DDoS, and Windows RPC abuse

Context

Windows RPC and LDAP are part of the operating backbone that supports authentication, directory lookup, and domain controller communication. When those paths assume trusted clients, limited request volume, or benign referral behavior, attackers can turn ordinary platform logic into an availability weapon.

This article is really about how security blind spots in core Windows services create resilience risk for identity estates. The identity intersection is genuine: domain controllers, LSASS, and directory services sit at the center of IAM operations, so a denial of service against them can interrupt authentication, policy enforcement, and administrative control across the enterprise.

Key questions

Q: What breaks when domain controllers are exposed to RPC and LDAP abuse?

A: When domain controllers are exposed to abusive RPC or LDAP patterns, the failure is usually availability first. Resource exhaustion can crash LSASS, directory services, or related Windows components, interrupting authentication and administrative operations. In practice, that means login failures, policy delays, and cascading disruption across systems that depend on Active Directory for trust and access decisions.

Q: Why do directory services create outsized denial-of-service risk?

A: Directory services sit at the centre of authentication, authorization, and name resolution workflows, so a crash affects far more than one server. They also rely on protocol logic that can be forced into expensive work, especially when referrals, enumeration, or repeated requests are unbounded. That combination turns small defects into enterprise-wide outages.

Q: What do security teams get wrong about internal denial-of-service threats?

A: Teams often assume internal systems are safe unless an attacker has full compromise, but that assumption fails for protocol abuse. A reachable service can be driven into exhaustion by malformed or excessive requests without malware, credentials, or persistence. Internal trust does not remove the need for rate limits, input bounds, and resilience testing.

Q: Which controls should reduce the risk of Win-DDoS style abuse?

A: The main controls are exposure reduction, traffic filtering, protocol hardening, and availability monitoring. Security teams should restrict public access to directory services, test RPC and LDAP behaviour under abuse, and alert on crash patterns or referral anomalies. For identity programmes, resilience controls must sit alongside access controls.

Technical breakdown

How LDAP referral chasing becomes a denial-of-service path

Windows LDAP client code follows referrals when a server redirects the request elsewhere. SafeBreach shows that if an attacker can influence referral lists, the client may keep allocating memory while it chases those referrals, because releases do not occur until the list is exhausted or a referral succeeds. That creates a resource exhaustion condition in LSASS or related components, which can end in a crash or reboot. The weakness is not authentication bypass. It is that client-side trust and unbounded referral handling create an attack surface for memory pressure.

Practical implication: cap referral handling behavior and test directory client resilience under adversarial referral lists.

Why transport-agnostic RPC wrappers expose resource exhaustion risk

RPC servers often rely on framework code to handle transport details, which can make application logic appear safer than it is. SafeBreach’s research shows that if the underlying RPC function accepts inputs that trigger heavy memory use or repeated calls, an attacker can force the service to do expensive work at a high rate. The result is a classic availability failure, but one hidden inside a trusted enterprise protocol. The key lesson is that developer blind spots often begin where the protocol abstraction ends and the resource accounting begins.

Practical implication: review RPC interfaces for unbounded allocation, expensive enumeration, and insufficient throttling.

How a public domain controller can be abused as a DDoS source

Win-DDoS works because public DCs can be induced to make outbound LDAP and CLDAP requests to attacker-controlled infrastructure. By returning referral chains that ultimately point many DCs at the same victim, the attacker turns distributed identity infrastructure into a high-volume traffic source. The technique is unusual because the botnet is not built from compromised endpoints, but from coerced infrastructure behavior. That makes abuse detection harder, since the traffic originates from legitimate DCs performing protocol operations that look superficially valid.

Practical implication: restrict public exposure of DC services and monitor referral-driven outbound traffic patterns.

Threat narrative

Attacker objective: The attacker wants to disrupt authentication and directory services, or weaponise domain controllers as a distributed traffic source for denial of service.

1. Entry occurs when an attacker can trigger LDAP or RPC behavior from a publicly reachable or reachable-internal domain controller or Windows host.
2. Credential access is not the focus here; instead, the attacker abuses trusted protocol handling to drive referral chasing, enumeration, or expensive server-side processing.
3. Impact occurs when memory exhaustion or request amplification crashes LSASS, domain controllers, or Windows endpoints, or when public DCs are coerced into DDoS traffic generation.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Win-DDoS exposes a control-plane resilience gap, not just a network flooding problem. The research shows that domain controllers can be turned into part of the attack surface when protocol behavior is trusted too much. That matters because directory services are foundational to IAM operations, so availability failures in DCs can cascade into authentication, policy enforcement, and privileged access workflows. Practitioners should treat DC resilience as identity governance infrastructure, not only server uptime.

Identity infrastructure assumptions fail when client-side trust is unbounded. The LDAP referral path demonstrates a broader pattern in enterprise systems: once a trusted protocol can be induced to follow attacker-controlled instructions, the platform can become its own denial-of-service mechanism. This is a governance failure because the implicit assumption is that only malicious code or obvious flooding matters. In practice, protocol recursion and resource exhaustion are enough. Teams should review where trust is inherited from transport and where it should be explicitly constrained.

Publicly exposed directory services create an abuse multiplier. The novel DDoS angle is not that DCs were compromised, but that they could be manipulated into acting as high-volume participants. That shifts the risk model from endpoint defense to exposure management and service architecture. For identity teams, the lesson is that anything tied to domain infrastructure must be assessed for outbound abuse potential as well as inbound availability risk. The right question is whether the service can be coerced into scaling an attack.

Resource exhaustion is becoming a first-class identity risk. The article strengthens the case for naming a specific failure mode: identity-plane exhaustion. When directory, RPC, or authentication components are asked to perform unbounded work, the issue is not just correctness but survivability. That aligns with modern resilience thinking in NIST CSF and with control families in NIST SP 800-53 that cover availability, monitoring, and system integrity. Teams should map identity services to resilience controls, not only access controls.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks, with inadequate monitoring and logging and over-privileged accounts each cited by 37%.
• If you are mapping this risk into lifecycle governance, see NHI Lifecycle Management Guide for provisioning, rotation, offboarding, and visibility controls.

What this signals

Identity-plane exhaustion: organisations should now treat directory-service availability as part of access governance. Once domain controllers or RPC-backed services can be coerced into excessive work, the question shifts from who can log in to whether the trust fabric can stay online long enough to enforce policy. That is a resilience issue with direct IAM consequences, and it should be measured alongside authentication failure rates and privileged access service health.

The practical next step is to fold DC exposure, request amplification, and referral abuse into control design reviews. Teams can align that work with MITRE ATT&CK Enterprise Matrix for attack-chain mapping and NIST SP 800-53 Rev 5 Security and Privacy Controls for availability and monitoring controls. For identity architects, this is a reminder that the IAM plane is only as strong as the services that keep it alive.

For practitioners

• Harden domain controller exposure Remove unnecessary public reachability for LDAP, CLDAP, RPC, and related services. Where exposure is unavoidable, place strict network filtering and rate limiting in front of domain controllers and monitor for referral-heavy traffic patterns. This reduces the chance that a DC becomes an involuntary attack participant.
• Test protocol-level resource exhaustion Build abuse cases for LDAP referral chains, RPC enumeration calls, and repeated request patterns that force high memory consumption. Validate how lsass.exe, spoolsv.exe, and directory services behave under stress so you can identify crash conditions before attackers do.
• Instrument identity-plane availability controls Track DC crashes, abnormal referral behavior, and spikes in authentication-related service faults as security signals, not only infrastructure incidents. Tie those detections to incident response playbooks so identity, platform, and SOC teams can act together when directory services destabilise.
• Review trust boundaries in client-side directory logic Audit where Windows clients and service wrappers assume benign referrals, limited concurrency, or low-volume use. Replace those assumptions with explicit bounds, rejection logic, and failure testing for worst-case request volume, especially in environments that expose identity services beyond the internal perimeter.

Key takeaways

• SafeBreach’s research shows that Windows RPC and LDAP blind spots can be converted into denial-of-service paths against domain controllers and endpoints.
• The most important failure mode is identity-plane exhaustion, where trusted protocol behaviour creates crashes or traffic amplification without code execution or credential theft.
• Security teams should harden exposure, test resource exhaustion, and treat domain-controller resilience as part of IAM governance.

Key terms

• Domain controller availability: The ability of a domain controller to continue authenticating users, serving directory requests, and enforcing policy without interruption. In practice, this is a security control as much as an infrastructure concern because identity services failing can stop access decisions across the enterprise.
• Referral chasing: A directory client behaviour in which it follows server-provided pointers to other servers when resolving a request. That logic is useful in normal operations, but if referrals are attacker-influenced or unbounded, it can become a resource-exhaustion path that drives crashes or traffic amplification.
• Transport-agnostic wrapped server code: Application logic that relies on a framework to handle network transport details, which can hide classic availability risks from the developer. The code may look simple at the application layer, yet still be vulnerable to repeated calls, oversized inputs, and memory pressure.
• Identity-plane exhaustion: A failure mode where authentication, directory, or access-control services are forced to spend so much memory, CPU, or request capacity that they stop functioning reliably. It is a resilience problem with direct IAM impact because policy enforcement depends on the identity plane staying online.

What's in the full report

SafeBreach's full research covers the technical exploit chains and proof-of-concept detail this post intentionally leaves for the source:

• The LDAP referral handling sequence that enabled Win-DDoS and the memory-exhaustion conditions behind the crash
• The three RPC abuse paths used to trigger denial of service on Windows domain controllers and endpoints
• The proof-of-concept behaviour showing how public DCs were coerced into high-volume outbound traffic
• The vendor response and disclosure timeline, including Microsoft remediation details

👉 SafeBreach's full post covers the attack chain, proof-of-concept behaviour, and remediation context

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management. It helps practitioners connect identity controls to the wider security programme they are responsible for.