Table of Contents
Overview
SafeBreach Labs dropped a bombshell earlier this month at DEF CON 33, uncovering a set of previously unknown Windows vulnerabilities capable of turning ordinary domain controllers (DCs) into high-powered DDoS cannons. Dubbed the Win-DoS Epidemic, these flaws allow for the abuse of legitimate Windows RPC and LDAP functionality to crash critical services or weaponize them for massive DDoS attacks without needing credentials, malware, or even direct compromise. The newly revealed Win-DDoS technique can hijack publicly accessible domain controllers around the world, creating a stealthy, decentralized botnet that’s almost impossible to trace.
By abusing how Windows handles LDAP referrals, attackers are able to conscript legitimate, uninfected domain controllers into flooding a target with traffic. This means there’s no need to breach endpoints, drop malware, or maintain persistent access. The attacker simply sends carefully crafted requests, and Windows does the rest.
Because many organizations still expose DCs to the internet for remote authentication or misconfigured services, the global attack surface is vast. Publicly accessible DCs owned by corporations, ISPs, and government agencies could be weaponized without their knowledge. Unlike traditional botnets, which leave behind clear forensic evidence, Win-DDoS attacks are nearly invisible, with the malicious traffic appearing to come from trusted infrastructure.
No Win-DDoS attacks have been observed in the wild at the time of this writing. However, through lab-based reproduction, we have been able to observe and analyze the attack’s characteristics and behaviors. This article focuses exclusively on these findings, with the goal of helping organizations better understand how Win-DDoS operates and improve their ability to successfully mitigate its attack vectors.
How Win-DDoS Works
(based on SafeBreach’s research)
- Domain Setup – The attacker registers a domain and creates malicious SRV records pointing to their own IP address, hosting attacker-controlled LDAP servers.
- Triggering the DC – The attacker sends a specially crafted RPC requests to a target DC, forcing it to act as an LDAP client.
- SRV Record Resolution – The DC resolves the malicious SRV record provided by the attacker’s tool. The resolved IP belongs to the attacker’s LDAP server.
- Initial CLDAP Query – The DC sends an LDAP query over UDP (CLDAP) to the attacker’s CLDAP server IP.
- CLDAP Redirection – The attacker’s CLDAP server responds with a referral that directs the DC to the attacker’s TCP LDAP server.
- TCP LDAP Query – The DC initiates a standard LDAP query over TCP to the attacker’s TCP LDAP server.
- Mass Referral Injection – The attacker responds with an LDAP referral containing a huge list of LDAP referral URLs, all pointing to the same victim IP address and port. This is achieved using a wildcard domain so every hostname in the list resolves to the victim’s IP.
- Outbound Queries to Victim – The DC sends LDAP queries to the victim’s IP and port for each URL in the referral list.
- TCP Handshake Attempt – For each query, the DC commences the TCP 3-way handshake by sending a SYN packet to the victim.
- If the TCP Port is Open on the Victim: The TCP 3-way handshake completes, and the DC sends a PSH, ACK packet containing the LDAP query to the victim.
- If the TCP Port is Closed on the Victim: The DC repeatedly sends SYN packets, generating a large number of attempts toward the victim.
- The number of flood requests equates to the number of entries in the huge referral list that was sent by the attacker to DC
DDoS Attack Flow" srcset="https://www.corero.com/wp-content/uploads/2025/08/Win-DDoS-Attack-Flow.png 624w, https://www.corero.com/wp-content/uploads/2025/08/Win-DDoS-Attack-Flow-300x261.png 300w" sizes="(max-width: 624px) 100vw, 624px" /> Figure 1: Win-DDoS attack flow
DDoS Attack Characteristics
We observed the traffic coming from the DC to the victim in our lab reproduction. Our reproduction was using one attacker, one DC, and one victim. There were 100 URLs in the referral list, all pointing to the same victim IP and destination port.
The DDoS attack characteristics are different depending on whether the targeted port on the victim is open for connection.
Targeted Port is Closed on Victim
With 100 URLs in the referral list, the DC attempted 100 separate connections to the victim. Because LDAP runs over TCP, each attempt required completing a 3-way handshake before sending the LDAP query. Since the victim’s target port was closed, the handshake was never completed and the connections failed. Due to TCP retransmission behavior, the DC in our lab tried to retrieve each connection twice, sending two SYN packets before abandoning it and moving on to the next URL.
Pictures below show the number of packets sent from attacker to victim on Wireshark.
Figure 2: Wireshark – Statistic IPv4 Conversations
Figure 3: Wireshark – Statistic TCP Conversations
Our testing revealed that the DC does not send 100 LDAP requests in parallel to the list of 100 URLs. Instead, it processes them sequentially. This means that while an attacker could cause DCs to send a large volume of traffic to a victim, the attacker cannot directly control the traffic rate from DCs. As a result, attack traffic from each DC ramps up gradually but when multiple DCs target the same victim, the combined load can still be significant.
A closer look at the SYN packets shows that the first SYN packet in each connection attempt consistently has the ECE and CWR flags set. Our tests across several Windows versions showed the same pattern in most cases, though this behavior may still vary in other environments.
Figure 4: Wireshark – TCP Flags set
Targeted Port is Open on Victim
We repeated the test with 100 URLs in the referral list, but this time targeting an open HTTP port running an Apache web server on the victim. Since the port was open, the 3-way handshake was completed successfully, and the DC sent a TCP data packet containing the LDAP query. However, because the victim’s service was HTTP and not LDAP, it did not recognize the query and returned no response. After a timeout, the victim sent a FIN packet to gracefully terminate the connection, and the DC responded with its own FIN to close it. The DC then proceeded to the next URL in the list. This pattern continued until all URLs were processed in the list.
Figure 5: TCP Flows
In total, each DC sent five packets per connection to the victim, so with 100 URLs in the referral list, the DCs generated 500 packets overall. We also observed that, as in previous tests, the DC did not send these queries in parallel. Each connection was completed sequentially before moving to the next URL, continuing this pattern until the end of the list.
Mitigation
An attacker might be able to generate a large volume of traffic toward the victim, but they are unlikely to directly control the traffic rate, as the connections are sent sequentially. From our perspective, it is unlikely that this attack could produce an extremely high-rate flood. However, it could still sustain a long-duration attack with relatively little effort.
Understanding the characteristics and behavior of Win-DDoS attacks is crucial for making informed decisions when it comes to blocking these threats. By studying how Win-DDoS operates, organizations can increase their chances of successfully mitigating attack vectors.
Our lab results suggest that, while Win-DDoS is unlikely to produce extremely high-rate floods, the technique still poses a persistent threat. Defenders should consider solutions that inspect traffic in real time and identify anomalous behaviors directly in the data path before damage is done. Inline protection platforms with adaptive detection can help neutralize this kind of low-volume, sustained attack without relying on cloud scrubbing or complex workarounds.
Corero customers who subscribe to our DDoS Intelligence Service will automatically receive updates designed to detect and mitigate tactics associated with this type of abuse. These updates help ensure early visibility into evolving threats and enable defenses to be applied before attacks can affect service availability.
