Zhadnost DDoS attacks show how misconfigured routers scale disruption

At a glance

What this is: SecurityScorecard's analysis shows how a botnet of misconfigured routers and distributed traffic sources enabled repeated DDoS attacks against Ukrainian government and financial websites.

Why it matters: For IAM and security teams, this highlights how weak infrastructure hygiene and externally exposed services can create large-scale availability risk, even when the underlying issue is not a classic identity failure.

By the numbers:

• SecurityScorecard found more than 3,000 unique IP addresses involved in the DDoS attacks on Ukrainian websites.
• The first attack involved more than 200 unique IP addresses, while the later attacks used more than 1,800 IPs each.

👉 Read SecurityScorecard's analysis of the Zhadnost DDoS attacks on Ukraine

Context

DDoS attacks remain a governance problem as much as a technical one because availability often fails first at the edge, where exposed devices, weak defaults, and poor recursion settings turn ordinary infrastructure into attack fuel. In this case, the primary risk was not credential theft or account abuse but the abuse of globally distributed routers to overwhelm public services.

The article also has an identity-adjacent angle because the misconfigured devices acted as unmanaged internet-facing resources with no effective lifecycle control. For teams responsible for IAM, PAM, or broader security governance, the lesson is that unmanaged access paths and exposed services can create blast radius even when the incident does not begin with a human identity failure.

The pattern is not unusual for DDoS work: attackers look for scale, not sophistication, and they exploit whatever is already reachable. That makes the starting position broadly typical of internet-facing resilience failures.

Key questions

Q: What breaks when DNS recursion is left enabled on internet-facing routers?

A: When DNS recursion is left enabled on internet-facing routers, those devices can be used as reflection and amplification nodes in DDoS attacks. Attackers can spoof requests so that the router sends large responses toward the victim, multiplying traffic without needing full compromise of every device. The result is distributed abuse capacity created from ordinary misconfiguration.

Q: Why do exposed routers and proxies make DDoS campaigns harder to stop?

A: Exposed routers and proxies expand attack capacity because the traffic originates from many unrelated devices across many networks, which makes blocking single sources ineffective. They also blur attribution, since defenders may see traffic from the device itself, from hosts behind it, or from both. That dispersion forces teams to rely on upstream mitigation and hardening the exposed service.

Q: How do security teams know if their edge device exposure is becoming a resilience problem?

A: Security teams know edge device exposure is becoming a resilience problem when public-facing services are enabled without a documented business need, when recursion or similar amplifying functions are open to the internet, and when device inventories cannot quickly answer who owns the exposure. Those conditions indicate attack capacity can be formed from your own infrastructure.

Q: Who is accountable for reducing DDoS exposure on routers and edge services?

A: Accountability should sit with the asset owner, the network operations team, and the security function together, because DDoS exposure is both a configuration issue and a resilience issue. Governance frameworks should require ownership for public services, validation of recursion settings, and regular review of externally reachable devices so the same exposure does not recur.

Technical breakdown

How DNS recursion turns routers into amplification nodes

DNS amplification works when a resolver accepts recursion from untrusted sources and then sends a much larger response to a spoofed victim address. In this case, the routers were not necessarily deeply compromised. They were simply reachable, configured to recurse, and therefore usable as reflectors. That matters because amplification attacks scale with the number of exposed resolvers, not with the sophistication of any one compromised host. A botnet can be assembled from devices that were never intended to participate in malicious traffic, provided they expose the wrong service boundary.

Practical implication: Disable open recursion on internet-facing routers unless recursion is strictly required and tightly scoped.

Why HTTP floods and amplification overload different parts of the stack

HTTP floods exhaust application or reverse-proxy capacity by forcing the target to process a high volume of requests, while DNS amplification pushes large volumes of reflected traffic toward the victim from many sources. Both produce denial of service, but they stress different controls. HTTP floods are often handled with application-layer filtering, rate limiting, and scrubbing, whereas amplification attacks require upstream filtering and network-level resilience. The article shows both patterns in one campaign, which is why defenders need layered availability controls instead of a single mitigation.

Practical implication: Design DDoS protection for both application-layer floods and network-layer reflection traffic, not just one traffic pattern.

Why unmanaged router populations create persistent attack capacity

A large population of exposed routers becomes a standing pool of attack infrastructure when basic configuration hygiene is missing. SecurityScorecard's analysis suggests the threat actor did not need a custom implant on every device. It only needed devices that would answer spoofed requests in a useful way. That is a governance failure, not just an operations failure, because the exposure persists until the underlying configuration is changed. In practical terms, every unreviewed edge device becomes a reusable control gap.

Practical implication: Inventory internet-facing devices continuously and treat exposed recursion settings as a security misconfiguration requiring remediation.

Threat narrative

Attacker objective: The objective was to deny or degrade public access to government and banking services by flooding them with distributed traffic.

1. Entry occurred through internet-facing routers and other devices that exposed DNS recursion and related services, allowing them to be used as traffic amplifiers.
2. Escalation came from scaling the attack across more than 3,000 IP addresses, which converted ordinary misconfigurations into distributed attack capacity.
3. Impact was repeated denial-of-service pressure on Ukrainian government and financial websites, with temporary disruption but limited lasting service degradation.

NHI Mgmt Group analysis

Misconfigured edge infrastructure is a governance failure, not just a network problem. The Zhadnost campaign shows that availability attacks often begin with unmanaged services at the perimeter, not with malware inside the enterprise. When routers are left with recursion enabled, the security issue is not the attack itself but the persistent exposure that makes the attack possible. Practitioners should treat exposed recursion settings as a control failure with lifecycle ownership, not an isolated operational defect.

Distributed DDoS infrastructure is now assembled from internet-wide device sprawl. This matters because defenders can no longer assume that attack capacity must come from a clearly compromised host population. In practice, any environment with large numbers of unreviewed edge devices can be converted into attack infrastructure with very little friction. The named concept here is reflection-ready device sprawl: a population of reachable devices whose default services create reusable abuse paths. Teams should map that sprawl before an attacker does.

Identity governance still matters in a DDoS story when access paths are unmanaged. Although this incident was not credential-driven, it demonstrates the broader NHIMG position that control of exposed resources is part of access governance. Service interfaces, device management paths, and administrative reachability all create risk when they are not inventoried and constrained. In identity programmes, that should push teams to align access review with asset exposure review, because unmanaged access surfaces are where resilience failures start.

The attack pattern validates layered resilience over point mitigation. The article shows that filtering at one layer is not enough when the traffic source is globally distributed and built from many unrelated devices. This reinforces the need for upstream scrubbing, configuration hygiene, and continuous exposure reduction as a combined posture. Practitioners should plan for repeated exploitation of the same weak settings, not one-off events.

Botnet attribution becomes much harder when the source devices are ordinary infrastructure. Security teams should expect more ambiguity in attack origin, especially when the source pool includes routers, proxies, and other shared internet services. That ambiguity does not reduce operational urgency. It increases the need for stronger asset visibility, because the most useful defense is often knowing which exposed services you own before they become part of someone else's campaign.

What this signals

Reflection-ready device sprawl is the right lens for programmes that still treat edge appliances as low-frequency assets. When public services are left open, the organisation is carrying hidden attack capacity in plain sight, and that exposure belongs in the same governance cycle as other externally reachable systems.

Teams that already track privileged access should extend those control loops to internet-facing infrastructure. The same discipline that governs standing credentials also applies to standing exposure: review what is reachable, who owns it, and whether the service should exist at all. That is where resilience starts.

For practitioners aligning with broader controls, the issue maps cleanly to upstream resilience practices in the NIST Cybersecurity Framework 2.0 and attack-pattern mapping in the MITRE ATT&CK Enterprise Matrix. The practical signal is simple: if an exposed service can be abused at scale, it has already become part of someone else's attack supply chain.

For practitioners

• Audit router recursion settings across the internet edge Check every exposed router and resolver for recursive DNS enabled on public interfaces, then disable it unless recursion is required for a documented business case. Where recursion must remain on, restrict it to trusted hosts and monitored networks. This is the fastest way to reduce reflection potential and shrink the pool of reusable attack infrastructure.
• Inventory unmanaged devices that can amplify traffic Build a continuous inventory of internet-facing edge devices, including routers, proxies, and branch appliances, then flag any system with open recursion or other amplification-prone services. Use that inventory to prioritize remediation of the highest-exposure assets first.
• Add layered DDoS protection for both flood types Combine upstream scrubbing, CDN or cloud-based mitigation, and local rate controls so that HTTP floods and DNS amplification are handled at different layers. A firewall alone will not absorb high-volume distributed traffic, especially when the source is global and highly dispersed.
• Treat exposed services as lifecycle-owned security debt Assign ownership for public service exposure in the same way you assign ownership for credentials and privileged access. Remediation should include asset owners, change tracking, and recurring validation that recursion or similar risky settings have not been re-enabled.

Key takeaways

• This campaign showed that ordinary routers and exposed services can be turned into distributed attack infrastructure when recursion and similar settings are left open.
• SecurityScorecard observed more than 3,000 unique IP addresses across the DDoS activity, which is enough scale to overwhelm public services without a single high-value compromise.
• The control that matters most is exposure reduction at the edge: inventory public services, disable open recursion, and add layered DDoS protection.

Key terms

• DNS Amplification Attack: A DNS amplification attack is a reflection-based denial of service technique that uses small spoofed queries to trigger much larger DNS responses toward a victim. The attacker spends little bandwidth while the target absorbs the resulting traffic flood, often through open resolvers or misconfigured DNS infrastructure.
• Reflection Attack: An attack pattern that spoofs the victim's address so third-party systems send traffic to the target instead of the attacker. It is common in DDoS operations because it hides the attacker source and lets ordinary exposed services become force multipliers.
• Open Recursion: A DNS configuration where a resolver answers recursive queries from untrusted internet sources. If left exposed, it can be abused for amplification attacks and is therefore a security exposure that needs ownership, validation, and ongoing review.
• Attack Surface Intelligence: The practice of discovering externally reachable assets and evaluating which of them can be abused by attackers. In this context, it helps teams find exposed routers, resolvers, and services before those assets are used as part of a botnet or reflection chain.

What's in the full report

SecurityScorecard's full report covers the operational detail this post intentionally leaves for the source:

• Netflow-based attack reconstruction showing how the three campaigns differed in source population and traffic pattern
• The device-level indicators SecurityScorecard used to identify MikroTik and other recursion-enabled routers
• The comparative table of attack dates, IP counts, and observed DDoS techniques
• Mitigation guidance for recursion settings and upstream DDoS protection based on the observed traffic

👉 SecurityScorecard's full report covers the attack reconstruction, device signatures, and mitigation guidance in detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in practical terms. It is suitable for practitioners building tighter control over exposed identities and access paths across hybrid environments.