A threat actor has been targeting Internet service providers in the United States with ransom demands backed by large-scale distributed denial-of-service attacks. Link Technologies, Inc. has recently assisted two consulting clients that received nearly identical threats.

In both incidents, the ISP received an email demanding a payment of less than $3,000 in Bitcoin. The message warned that a DDoS attack would begin within approximately one hour if the payment was not made. In both cases, the attack followed on schedule.

What Happened During the Attacks

One of the most significant incidents we responded to involved a carpet bombing DDoS attack, a technique specifically designed to disrupt an Internet Service Provider rather than a single customer or service. Unlike traditional DDoS attacks that concentrate traffic on one IP address, server, or application, a carpet bombing attack distributes malicious traffic across thousands of IP addresses simultaneously, making conventional mitigation strategies far less effective.

In this case, the attack originated from more than 10,000 unique source IP addresses and simultaneously targeted over 4,500 public IP addresses assigned to the ISP. Rather than overwhelming an individual subscriber, the attackers attempted to exhaust the provider's transit capacity and impact the network as a whole.

Traditional mitigation techniques, such as Remote Triggered Black Hole (RTBH) routing, are effective when only a small number of destinations are under attack. However, blackholing thousands of customer IP addresses would have effectively disconnected a significant portion of the ISP's subscribers, allowing the attackers to achieve their objective without sending another packet. This illustrates why carpet bombing attacks represent a unique challenge for service providers.

The complexity of this incident was further increased by the ISP's network architecture. The provider operated multiple geographically diverse networks that were not interconnected through a common backend infrastructure. Connectivity was delivered through four independent transit circuits, including two 10 Gbps upstream connections at one location and additional 2.5 Gbps and 3.5 Gbps transit circuits at two other facilities. The attack was distributed across all of these Internet connections simultaneously, requiring our engineers to coordinate mitigation efforts with multiple upstream providers at the same time.

The scale of the attack extended beyond the ISP itself. One of the transit providers supplying a 10 Gbps circuit reported that its 100 Gbps aggregation link feeding the local edge router was operating at 100% utilization during the attack. This demonstrates an important characteristic of large-scale carpet bombing attacks: the objective is not merely to saturate the victim's Internet circuit, but to generate enough distributed traffic to congest upstream provider infrastructure as well. By forcing congestion higher within the carrier's network, the attackers increase collateral damage and make mitigation substantially more challenging for everyone involved.The attack continued for more than five hours, requiring constant monitoring and coordination between our engineering team and the upstream carriers. As an emergency measure, several transit providers implemented broad UDP filtering by blocking traffic to commonly abused destination ports. While this action reduced enough of the malicious traffic to keep portions of the network operational, it also introduced collateral damage. Customers using third-party DNS resolvers, VoIP services, and UDP-based VPN or tunneling protocols experienced service disruptions because the filtering was necessarily broad rather than application-aware.

Traffic analysis showed that each targeted IP address received approximately 400 to 500 Mbps of malicious UDP traffic. Instead of relying on a handful of high-bandwidth attack systems, the attackers leveraged thousands of distributed hosts, with many individual source IP addresses contributing approximately 20 to 30 Mbps each. Although the per-source bandwidth appeared relatively modest, the aggregate traffic generated by thousands of attacking systems was sufficient to threaten the ISP's available transit capacity.

The attack itself was a large-scale UDP flood. Destination ports appeared largely randomized, although ports 22, 23, 161, and 443 were frequently observed alongside numerous high-numbered UDP ports. By distributing traffic across a broad range of ports, the attackers significantly reduced the effectiveness of simple access control lists (ACLs) and static firewall rules, reinforcing the need for behavioral traffic analysis, automated anomaly detection, and upstream DDoS mitigation.

Once an attack has saturated available transit bandwidth and no mitigation strategy has been deployed beforehand, an ISP's response options become extremely limited. Emergency coordination with upstream providers, selective RTBH announcements, temporary protocol filtering, and the rapid deployment of a cloud-based scrubbing service may help reduce the impact, but none of these measures is as effective—or as cost-efficient—as having a well-tested DDoS response plan already in place before an attack occurs.

The affected organizations preserved the extortion emails, packet captures, attack timelines, screenshots, source IP addresses, and targeted destination addresses. This evidence was submitted to the U.S. Department of Homeland Security to support an ongoing investigation into the attacks.

Three Practical Levels of DDoS Defense

For operational planning, Link Technologies groups DDoS incidents into three general levels. The appropriate response depends primarily on attack volume, available transit capacity, traffic distribution, and whether upstream or cloud-based mitigation is already available.

Level 1: The ISP Has Enough Bandwidth to Absorb the Attack

A Level 1 incident is an attack that remains within the capacity of the ISP's transit connections and edge infrastructure. Depending on the network, this may mean an attack below 1 Gbps, below 10 Gbps, or another threshold determined by available bandwidth and normal utilization.

At this level, effective mitigation starts with traffic baselining. The ISP must know what normal traffic looks like for protocols, destinations, subscribers, and aggregate links. For example, if a destination IP address normally receives no more than 150 UDP packets per second, a sudden and sustained increase far above that baseline may indicate an attack.

Detection systems can use these baselines to trigger firewall filters, rate limits, alerts, or routing actions. The objective is not to block all UDP or impose arbitrary limits across the network. The objective is to identify abnormal traffic patterns and apply a proportional response to the affected destination or flow.

FastNetMon is one of the strongest options for this type of deployment. It can analyze traffic telemetry, detect attacks within seconds, notify the operations team, integrate with filtering systems, and trigger Remote Triggered Black Hole routes when required.

Level 2: The Attack Is Approaching Transit Capacity

A Level 2 incident occurs when malicious traffic approaches the capacity of an ISP's transit connection. For example, an ISP with a 10 Gbps transit link and 6 Gbps of normal utilization has very little room to absorb a 5 Gbps attack. Even if the edge router can identify and discard the malicious packets, the inbound circuit may already be saturated before the packets reach the firewall.

This is where Remote Triggered Black Hole routing, commonly abbreviated as RTBH, becomes important. FastNetMon or Link Technologies' FlowCutter platform can monitor NetFlow, sFlow, IPFIX, or other telemetry, establish normal traffic patterns, and identify a destination under attack.

The detection platform establishes a BGP session with the ISP's routing infrastructure. When an attack exceeds defined thresholds, the system advertises the targeted IP address with the community or next-hop behavior required by the upstream carrier's blackhole service. Many providers use a BGP blackhole community—often based on the well-known BLACKHOLE community or a provider-specific community—while others require a dedicated blackhole session or portal.

RTBH prevents attack traffic from entering the ISP's transit circuit, but it is intentionally non-discriminating. All traffic to the blackholed destination is discarded, including legitimate traffic. The targeted customer, server, or service remains unavailable until the route is withdrawn.

This is an operational tradeoff: take one destination offline to preserve service for the rest of the network. It is not a perfect solution, but when the alternative is saturation of the entire transit link, blackholing one affected address may protect thousands of other customers.

Level 3: The Attack Exceeds Available Capacity or Targets the Entire ISP

A Level 3 incident is one that the ISP cannot reasonably absorb with its existing transit capacity. This includes attacks that exceed circuit capacity, attacks distributed across many prefixes, or campaigns targeting a large percentage of the ISP's customer address space.

Traditional DDoS attacks often focus on one public IP address, such as a game server, customer website, VoIP platform, or other high-value service. The recent extortion incidents were different: traffic was spread across thousands of addresses specifically to disrupt the provider itself.

At this level, the ISP generally has three choices:

• Blackhole targeted addresses or prefixes. This may preserve part of the network, but it deliberately takes the affected destinations offline.
• Request emergency mitigation from upstream carriers. Transit providers may apply filters or mitigation, but capabilities and response times vary significantly.
• Divert traffic through a DDoS scrubbing provider. This is the most comprehensive option, but it also carries the greatest cost and requires advance engineering.

How a DDoS Scrubbing Service Works

A scrubbing service provides Internet-scale capacity and specialized filtering outside the ISP's constrained transit links. The provider typically establishes GRE, WireGuard, or another supported tunnel back to the ISP's network. Routing policy is prepared so that traffic can be diverted to the scrubbing network when an attack is detected.

Consider an ISP advertising a /22 through two 10 Gbps upstream connections. During normal operation, the ISP announces its prefixes directly. When an attack begins, the scrubbing provider may announce more-specific /24 routes from its own globally connected mitigation network. Because those routes are more specific, Internet traffic is drawn toward the scrubbing infrastructure.

The scrubbing provider separates legitimate traffic from attack traffic using filtering, behavioral analysis, protocol validation, rate controls, and large-scale mitigation systems. Clean traffic is then delivered to the ISP across the preconfigured tunnels.

This approach allows the attack to be absorbed by infrastructure with hundreds of gigabits—or potentially terabits—of capacity instead of consuming the ISP's local transit connections. However, routing, tunnel capacity, MTU, return-path behavior, monitoring, and failover procedures must be engineered and tested before they are needed.

How Large Are Modern DDoS Attacks?

Cloudflare's DDoS reporting has consistently shown that most attacks are relatively small and short-lived. The source material referenced for this article reports that approximately 94 percent of attacks were below 500 Mbps and 99 percent were below 1 Gbps. Many attacks lasted less than ten minutes.

Those statistics do not make DDoS attacks harmless. They demonstrate why automated mitigation is essential. A short attack may be over before a human operator has diagnosed the traffic, contacted an upstream carrier, and implemented a manual response.

At the other end of the spectrum, hyper-volumetric attacks exceeding 1 Tbps are becoming increasingly visible. Cloudflare has reported attacks in the multi-terabit range, including an event reported at approximately 7.3 Tbps. An ISP cannot assume that the size of its own transit links limits the potential size of the attack directed toward it.

Reference: Cloudflare Radar Quarterly DDoS Reports

How DDoS Extortion Differs from Other Criminal Schemes

DDoS extortion is a form of cyber extortion, but it differs from ransomware, data theft, and conventional fraud in several important ways.

The Weapon Is Service Disruption

Unlike ransomware, which encrypts data or steals sensitive information, DDoS extortion attacks availability. The attacker is not necessarily trying to access internal systems or steal intellectual property. The threat is to make Internet-facing services unreachable.

For an ISP, this may mean saturated transit links, overloaded edge infrastructure, degraded routing performance, unreachable VoIP systems, or widespread service disruption across an entire customer base.

No Security Breach Is Required

Many cyberattacks begin with credential theft, exploitation, privilege escalation, and lateral movement. A DDoS extortionist may require none of those steps. A public IP address or domain name is enough to begin sending attack traffic from a distributed botnet or reflection infrastructure.

Victims May Be Selected Opportunistically

Ransomware groups often target organizations that appear able to pay large demands or that depend heavily on critical data. DDoS extortion campaigns can be much less selective. Potential victims include ISPs, hosting companies, financial institutions, online retailers, healthcare organizations, government agencies, gaming platforms, and any organization that relies on continuous Internet availability.

The Damage Is Immediate but Often Temporary

Ransomware recovery may require system rebuilding, backup restoration, credential rotation, forensic investigation, and weeks of operational work. A DDoS attack usually causes disruption while the malicious traffic continues. Once effective filtering, scrubbing, rate limiting, or upstream mitigation is applied, service can often be restored without rebuilding systems.

The Attack Relies on Psychological Pressure

DDoS extortion depends on urgency and fear. Attackers know that even a short outage can cause significant revenue loss, customer dissatisfaction, contractual penalties, and reputational damage. Their messages commonly include:

• Very short payment deadlines
• Threats of escalating attack volume
• Claims of controlling a large botnet
• Brief proof-of-capability attacks
• Warnings that the ransom will increase after the deadline

The objective is to make payment appear less expensive than continued downtime.

Payment Does Not Eliminate the Risk

There is no enforceable agreement between the victim and the attacker. Paying a ransom does not guarantee that the attack will stop, that it will not resume, or that the victim will not be targeted again. A paying organization may also be identified as willing to pay and targeted by the same actor or another criminal group.

DDoS Extortion and the Traditional Protection Racket

DDoS extortion closely resembles the protection rackets historically associated with organized crime. In a traditional protection scheme, criminals demand payment in exchange for preventing damage that they themselves threaten to cause. If the business refuses, the organization may respond with vandalism, theft, arson, or violence.

The economic model is the same in a DDoS extortion campaign, but the weapon is digital. Instead of threatening a storefront or warehouse, the attacker threatens to overwhelm the victim's network with malicious traffic. Websites, customer portals, applications, VoIP services, and Internet connectivity may all become unavailable.

For an ISP, the consequences extend far beyond a single organization. Saturated transit links or overloaded edge systems can affect thousands of subscribers. The criminal objective remains unchanged: create a credible threat of financial harm that appears more costly than the demanded payment.

The appropriate response is not to purchase “protection” from the attacker. It is to invest in legitimate resilience: redundant connectivity, traffic visibility, automated detection, upstream coordination, blackhole routing, filtering, scrubbing services, and a rehearsed incident-response plan. An organization that can withstand or rapidly mitigate the attack removes much of the leverage on which extortion depends.

How an ISP Can Survive a Large-Scale DDoS Attack

1. Maintain Sufficient Capacity and Diversity

The first requirement is sufficient and diverse transit capacity. No firewall rule can recover bandwidth that has already been consumed. An edge router may discard every malicious packet, but customers will still experience severe degradation if the upstream circuit is saturated.

Capacity planning should account for normal peak utilization, growth, equipment forwarding limits, upstream diversity, and the attack volumes the organization reasonably expects to handle locally.

2. Establish a Response Plan Before an Incident

Document the people, systems, carrier contacts, routing policies, thresholds, and decision points involved in a DDoS response. The plan should identify who can authorize blackholing, who contacts upstream providers, how affected customers are notified, and when traffic should be diverted to a scrubbing service.

3. Collect Traffic Telemetry and Build Baselines

Without ongoing traffic visibility, the ISP cannot reliably distinguish a DDoS attack from legitimate demand. Export NetFlow, sFlow, IPFIX, or equivalent telemetry from appropriate network points. Retain enough history to understand normal patterns by protocol, destination, customer, and time of day.

4. Automate Detection and Mitigation

Most DDoS incidents are too short for a fully manual response. FastNetMon and FlowCutter can detect abnormal flows, notify operations staff, and initiate predefined routing or filtering actions. Automation should include safeguards, thresholds, audit logs, and a clear process for withdrawing mitigation after the event.

5. Coordinate with Every Transit Provider

Document each carrier's blackhole communities, minimum prefix lengths, supported signaling methods, emergency contacts, and scrubbing capabilities. Test RTBH in a controlled maintenance window. Do not discover during an outage that a carrier requires a different BGP community, a separate session, or a manual ticket.

6. Preserve Evidence and Report Extortion Attempts

Retain complete copies of threat messages, email headers, cryptocurrency addresses, timestamps, packet captures, telemetry records, source and destination lists, carrier tickets, and mitigation logs. Report the incident to appropriate law-enforcement and cybersecurity authorities. Do not alter or destroy evidence during the response.

Final Assessment

DDoS extortion is not merely a nuisance attack. For an ISP, it can become a network-wide operational emergency that affects customers, support teams, upstream providers, and business continuity at the same time.

The central lesson from these incidents is straightforward: preparation determines the available options. An ISP with established baselines, automated detection, tested RTBH, documented carrier procedures, sufficient capacity, and a prearranged scrubbing service can respond quickly and deliberately. An ISP without those controls is left improvising during an active outage.

The attackers are counting on urgency, uncertainty, and the absence of a plan. Engineering resilience before the demand arrives is the most effective way to reduce their leverage.