The DDoS Was Coming From Inside the ISP Network

The DDoS Was Coming From Inside the Network

What we saw when ISPs across India called us about congested uplinks - and how flow data revealed a massive outbound botnet attack hiding in plain sight

Published: April 2026 | Reading time: ~7 min | Part 1 of 2

Executive Summary

Fig. 1 — An upstream transit link at one of our ISP customers during the incident. Upload (light blue) suddenly exceeding download, spiking to 6 Gbps. Their NOC's first reaction: peering problem. They were wrong.

The Calls Started Coming

Late March 2026. A Tuesday. The first call came from an ISP customer in North India - one of the larger FTTH providers we work with. Their upstream monitoring had flagged two transit links approaching 90% utilization on the outbound direction and this keeps on going up and down frequently. That alone was odd - this is a consumer broadband network. Traffic is overwhelmingly download. Upload rarely exceeds 30-40% of download on any link.

Within the hour, two more ISPs called with the same symptom. Different cities, different upstreams, same pattern: outbound traffic spiking without explanation. Their NOC teams were chasing infrastructure hypotheses - peering shifts, CDN fills, looping interfaces and even HTTP caching issues. None of them had looked at the traffic composition yet.

We pulled up their NetSense Flow dashboards remotely. It took about 3 minutes to see what was actually happening.

The pattern we now tell every ISP to watch for: When upload exceeds download in a consumer broadband network, stop troubleshooting infrastructure. Look at the flows data from your border routers. It is almost certainly a DDoS event manifesting as a capacity problem.

What the flows revealed

The flow data made the picture immediately clear. Massive outbound UDP: on ports 80, 443, and even port 0 - concentrated toward a small cluster of destination ASNs: China Telecom, Alibaba Cloud, Hubei Faxun Network, NINGBO ZHEJIANG. Not a handful of subscribers. Thousands, across multiple ISP networks, all doing the same thing, at the same time.

Fig. 2 — NetSense Flow: outbound traffic by destination ASN at one affected ISP. China Mobile, China Telecom, and Alibaba dominate, peaking above 1.4 Gbps. None of these are normal top destinations for Indian broadband traffic.

Fig. 3 — The ramp: zero to nearly 4 Gbps of outbound traffic to suspicious destinations in under an hour. CHINANET Sichuan Telecom and China Telecom dominate.

The same pattern appeared across every ISP that called us. This was not a single-network event. It was industry-wide. And to make things even more complicated some ISPs were having BNGs that totally melted under load, as they could not survive the extra load and this made it a lot more difficult to isolate the root cause of all this.

Separating what we saw from what we concluded

The Incident Timeline (One ISP, Representative)

Here is roughly how it played out at one of our larger ISP customers. The pattern was similar across all affected networks. Times are approximate - reconstructed from chat logs and dashboards.

Total time from first alert to containment: ~110 minutes. About 16 of those minutes were spent before they called us, chasing wrong hypotheses. The lesson we now drill into every ISP NOC we work with: upload exceeding download in consumer broadband = look at flows immediately. Do not troubleshoot infrastructure first.

Why This Breaks Most ISP Playbooks

Most DDoS mitigation is built for a simple model: bad traffic comes in, you scrub or absorb it. When the attack originates from inside the subscriber network, that model fails. This is what we had to explain to every ISP that called us that week.

The real problem is that modern botnets produce distributed, bursty attacks. Not one massive spike — thousands of small, synchronized bursts. Attack, idle, attack, idle. Each subscriber looks borderline in isolation. Together they saturate everything.

The ISP Operator's Playbook for Outbound DDoS

Based on what we saw across multiple ISP networks during March 2026, here is the generic playbook we now recommend to every ISP operator dealing with outbound DDoS. The tools matter, but the workflow matters more.

Step 1: Detect the anomaly. Upload exceeding download. Upstream links saturating outbound. Sudden egress spikes. This is the trigger — stop troubleshooting infrastructure and look at traffic composition.

Step 2: Break the traffic down. By protocol, port, destination ASN, destination IP, source IP. You need flow data (NetFlow, sFlow, IPFIX) — SNMP interface counters are not enough. You need to see what the traffic is, not just how much.

Step 3: Confirm it is distributed. One subscriber with odd traffic is a misconfiguration. Thousands with identical patterns is a botnet. Check source distribution.

Step 4: Block at the border. Identify the destination IPs/ASNs receiving the flood. Push blocking rules (FlowSpec, ACLs) to stop outbound traffic to confirmed attack targets.

Step 5: Trace to the source BNG. Map public NAT pool IPs back to specific BNG devices. You need IPAM data for this — which NAT pool lives on which BNG.

Step 6: Identify individual subscribers. On the BNG, check NAT tables, run packet captures, inspect per-subscriber traffic counters. Find the specific users generating flood traffic.

Step 7: Contain. Rate-limit or quarantine compromised subscribers. Apply per-subscriber firewall rules. Notify affected users.

How our tools fit in: NetSense Flow provides step 1-3. SensyAI (our playbook automation layer) handles steps 4-6 by chaining flow analysis, Netbox IPAM lookups, and BNG SSH sessions. NetSense Pulse provides CPE-level confirmation. But the playbook itself is tool-agnostic — any ISP can follow it with whatever stack they have.

Flow Visibility: The Foundation

Without flow data from border routers, ISP NOCs are flying blind. SNMP tells them a link is congested. Flow data tells them why. That distinction is the difference between 20 minutes of wrong hypotheses and an immediate understanding of what is happening.

We build NetSense Flow for exactly this use case — real-time NetFlow/sFlow collection and analysis. But the principle applies regardless of tool: ISPs need per-flow visibility into source/destination ASN, IP, port, and protocol — in real-time, across all border devices, with the ability to filter and pivot quickly.

Fig. 4 — NetSense Flow: outbound traffic by destination ASN. Hubei Faxun, NINGBO ZHEJIANG, Alibaba Cloud — none of these are normal top destinations for Indian broadband traffic.

Fig. 5 — Drilldown: top destination IPs by packets. China Telecom, NINGBO ZHEJIANG, Xiamen, Hubei Faxun. The Zscaler IPs at bottom are legitimate security traffic — useful baseline.

The critical capability during investigation is progressive drilldown. You start with aggregate anomaly, break down by port, then ASN, then IP, then source distribution. Good tooling lets analysts pivot between these views without friction. In our experience working with ISP NOCs, they rarely know the right query upfront — they discover it iteratively.

What comes next

Detection is one thing. But knowing you have a problem is not the same as solving it. In Part 2, we cover the hard part — what we helped our ISP customers deploy:

• How we automated the tracing chain from border IP to individual subscriber in under 10 minutes
• Why the BNG platform determines whether an ISP can fight this or just watch
• The actual nftables rules we helped deploy — and the tuning mistakes we learned from (QUIC broke on day one)
• The Quarantine BNG architecture that lets ISPs contain infected users without punishing everyone else
• An honest accounting of what is still not solved

"Now the real question: how do you stop this without breaking your users?"

Read Part 2: How to Stop Outbound DDoS in ISP Networks (Without Breaking Users) — netsense-nms.com/blog

References

• Nokia Deepfield, "Katana Botnet: Technical Analysis," March 2026
• FastNetMon, "Unusual Large-Scale Outbound DDoS Activity Observed Across Indian Networks," March 2026
• Made4It, "Botnet Kimwolf: Internal DDoS Attacks and How to Mitigate Now," 2026
• Cloudflare, "What is the Aisuru-Kimwolf Botnet?"
• U.S. DOJ, "Authorities Disrupt Four IoT Botnets Behind Record DDoS Attacks," March 2026