ISP hit by 2-day DDoS used FLOWCUTTER to pinpoint and neutralize attack vectors.

ISP in the UK was targeted by a series of DDoS attacks – to be exact, 20 times within two days.

Each attack resulted in overloaded edge routers. During the ~1h+ attacks, all the providers’ customers were experiencing internet outages.

On the morning of the third day, a technician contacted and installed FLOWCUTTER to see if it can help.

Most attacks are short and can be waited out until it’s over. This series of attacks rendered ISP operation impossible. Hot line ringing with angry customers the whole two days.

After trying painfully to find relevant information in SNMP monitoring, the administrator decided to be prepared for the next time – to understand the attack: 

• What method was used to attack
• Who is an attacker
• What exactly is the target

This is exactly where netflow data comes in handy. FLOWCUTTER netflow analysis is a perfect fit for such a situation.

ISP set up netflow export from edge routers to FLOWCUTTER were able to analyse the attack and consequently  mitigate it.

See the finding of this particular instance of a distributed DoS attack.

The operator was able to observe an anomaly within incoming connections (flows per second). It raised 25 times when compared to normal behavior before an attack.

When the operator zoomed in on the attack, he was able to clearly see the vector. Unfortunately, this was no easy situation – the attack was fully distributed. It means it didn’t come from a few IPs or ASN. It came from dozens of thousands of hosts all around the world.

Moreover, the incoming packets used UDP protocol, and didn’t originate or target any specific ports.

However for the given attack it targeted few IP addresses.

The whole bandwidth was saturated, so the operator couldn’t simply solve the situation by dropping packets to four IPs above on the firewall / edge router.

Instead, ISP mitigated the attacks by using BGP communities of upstream providers so that traffic to target IPs won’t even be routed to the ISP’s network.

• Netflow analysis in Grafana
• Flow-based (D)DoS detection
• Mitigation using BGP

What? Helping BitTorrent users, while saving ISP network’s resources.

During regular traffic analysis, a rather small regional operator found out there are irregularities in the number of active connections in one of his regions.

During those anomalies, the internet worked for the majority of households. However in the target town, radio connection didn’t hold well, leading to small interruptions, delays in domain resolving, and in general, the internet experience worsened.

Technical support often doesn’t have tooling in their disposal to effectively troubleshoot those anomalies that have root cause in their customers behaviour on the internet.

Without user friendly root cause analysis, it is easier to leave a problem intact. In this case, the problem was a few customers who passionately used BitTorrent.

Sooner or later problems such as these pile up and cause something serious. Definitely, customer experience could have been better.

The solution was two fold: finding root cause and then mitigate it

a) The first goal was to get network visibility fast, especially about customer traffic. 

• With FLOWCUTTER, an ISP’s technician is provided with user-friendly analysis dashboards. 

He found the perpetrator’s IP. 

Next this customer’s behavior was revealed as heavy torrent usage.

• See the majority of connections on port 6881 using UDP protocol on.

b) The second step is to mitigate the issue.

Upon calling the customer using BitTorrent, the ISP support didn’t yell or discourage him. They agreed on limiting the number of active connections (~20).

Here comes the surprise.

This not only solved the problem, but it also led to better download speeds for the customer, since freed connections led to better utilization of bandwidth for the whole town.

• After calling the customer and limiting connections, we can see that download was faster.

• User friendly traffic flow analysis in FLOWCUTTER

Proving public IP to customers is related to a serious risk. If a DNS port is opened to internet, a reflection type of DDoS starts flowing through an ISP, eventually.

It’s a rainy Sunday evening, and most households are watching TV or Netflix. That’s when internet connection starts to drop from time to, and eventually, all households lose it completely. 

The support line desk at the regional ISP was busy that evening, hundreds of customers were angry enough to call the operator and demand that the outage be resolved immediately.

ISP’s network administrator left the dinner table at home and went working to resolve the situation.

However, after careful analysis of SNMP telemetry in Zabbix, he wasn’t able to find out the root cause of an issue.

The operator thought that if this happens next weekend, we are going to lose customers for sure.

What to do now?

Network administrator looked into netflow data – traffic telemetry (link).

• ISP had netflow export in place on all CORE routers
• Netflow data streams were continually sent to the central collector with FLOWCUTTER software.

Among other anomalies, FLOWCUTTER focuses on clear analysis of outgoing attacks. One of those is a DNS reflection attack passing through the network.

The administrator was able to find the root cause of an issue – a customer with a public IP address provided to him. At the household, a customer by accident did factory reset of router/modem w/ RouterOS, ending up with no password setup and open service port to the internet.

Later analysis revealed that the attacker took control of the router and included it in the botnet using it for DNS reflection type of DDoS.

The operator blocked the attacking IP, getting rid of the attack. Later called the customer for cleaning up.

Moreover, the network administrator setup daily open ports scan detection in order to be alerted early, when something like this happens again. Next time he will be ready.

Let’s walk us through the netflow analysis of the issue at the time of the incident.

Outgoing attack was clearly visible when filtering out outgoing connections from source port 53. This particular port is reserved for DNS resolving and only resolvers should give DNS responses.

It’s also important to note that the volume of this attack was just 25.Mb/s which is completely invisible in aggregate traffic of an ISP. Hence other tools weren’t able to detect it, moreover find an attacking vector.

On the attacking IP, spoofed DNS requests could be observed from foreign countries.

Drill-down analysis revealed that the anomaly is DNS related.

In addition to netflow data, periodical scan of open ports was set up in FLOWCUTTER. That helps the operator to be pro-active and expose the anomaly next time. 

Upcoming feature will among other things allow the detection of outgoing DNS reflection attack detection without any involvement of technical staff of an ISP.

• Netflow analysis in FLOWCUTTER
• Open ports scan
• SNMP vs Flow telemetry
• Outgoing DNS reflection attack detection

Carpet bombing of many ISPs revealed differences between reactive and proactive approaches.

In May 2025, there were a series of DoS (Denial of Service) attacks targeted at hundreds of European ISPs. Attacks were in the form of TCP SYN Flood and targeted the whole IP range of an operator, not just one IP or just one service. Length of the incident varied between 2 and 40 minutes. However it happened repeatedly, several times a day and for a few days in a row.

During the attack CORE routers were overwhelmed by the number of incoming connection attempts. It resulted in internet outages for the whole operator’s customer base.

Most of the ISPs decided to wait it out until the attack was over hoping their customers won’t complain much.

Some decided to understand the attack and be prepared for the next time.

The issue is that common NOC monitoring tools are based on SNMP tools such as Zabbix. Unfortunately these tools don’t contain necessary signals to uncover: 

• Who is an attacker
• What method was used to attack

And consequently the ammunition that is needed for attack mitigation is missing.

What to do?

This is exactly where netflow data comes in handy. FLOWCUTTER netflow analysis and anomaly detection is a perfect fit for such a problem.

Customers that exported netflow from their CORE routers to FLOWCUTTER were able to analyse the attack and mitigate it easily.

See the finding of this particular instance of a DoS attack.

The operator was able to observe an anomaly in connection attempts (flows per second). It raised 10 times when compared to normal behavior before an attack.

When operator zoomed in the time interval of the anomaly, he was able to clearly see attack vector. 

It came from AS 202425 headquartered in the Netherlands with 4 IP addresses being responsible for the flood. Also an attack method was revealed: SYN Flood from a few source ports.

ISP mitigated the next attack either by refusing traffic from this AS or just denied connections from particular IP addresses.

Note that even though in this case source port information wasn’t necessary for mitigation, if this was a distributed DDoS attack, then source port would be the key to mitigate it using BGP Flowspec.

• Netflow analysis in Grafana
• County and ASN enrichment
• Flow-based (D)DoS detection

This case study highlights a real-world cybersecurity incident that could occur in contemporary enterprise networks.

A company experienced network outages and performance degradation, which significantly impacted its Operational Technology (OT) manufacturing network. The attack vector originated from an ISP’s infrastructure, allowing the adversary to progressively move closer to industrial control systems and the organization’s central database.

• Reconnaissance Phase: The attacker employed a “spray and pray” tactic, scanning multiple targets indiscriminately in search of vulnerabilities. Using automated scanning tools, the attacker probed exposed services on public IP ranges. High-interest targets included remote management interfaces (SSH, Winbox, and Telnet), outdated web applications, and network infrastructure devices.

Picture: MITRE ATT&CK® Matrix: visualization of attack phases

• ‘’Initial Access: The ISP operated RouterOS-based devices, one of which was compromised due to an outdated firmware vulnerability. The attacker exploited CVE-2022-45315, a vulnerability allowing unauthorized execution of code via specially crafted SNMP packets. The exploit provided a foothold into the ISP’s core network, allowing the attacker to execute commands remotely and establish persistence.

• Privilege Escalation & Establishing Persistence: Once inside, the attacker elevated privileges by exploiting weak credentials and misconfigured access control rules. They also deployed custom scripts to maintain access even after system reboots.

• Lateral Movement: The compromised ISP router began brute-force attacks on Telnet, SSH, and Winbox services on other network devices. The attacker attempted to map the ISP’s internal network structure, identifying routers, firewalls, and enterprise edge devices that could be leveraged for further exploitation.

Picture: MITRE ATT&CK® Matrix: visualization of attack phases

• Enterprise Network Compromise: The attacker successfully took control of the enterprise’s perimeter router, establishing communication with Command & Control (C2) servers. They used DNS tunneling and encrypted HTTP requests to mask malicious activity and avoid detection by standard firewall monitoring.

• OT Network Intrusion: The attacker attempted to compromise the perimeter of the OT network, initiating brute-force attacks on the enterprise’s database servers and performing slow, targeted scans against OT network segments, probing for vulnerable** devices**. However, the attack was detected at this stage due to volumetric NetFlow analysis, and mitigation efforts were implemented before a full breach occurred. The intrusion detection systems (IDS) regerated abnormal amount of logs and this triggered alert, allowing network administrators to block the attack and temporarily isolate the attacked network before incident was revealed and attack mitigated.

Challenges cover detection of such incidents

• Firewall monitoring failed to detect the attack since the adversary leveraged a trusted ISP infrastructure to move laterally.
• Absence of Endpoint Detection and Response (EDR) across all systems limited forensic reconstruction of the attack sequence.
• Attack on OT network activity remained nearly undetectable, as it was performed gradually and from trusted devices.

• Deployment of NetFlow analysis at the ISP level helped reveal abnormal traffic patterns.

• Correlation of multiple data sources is the key for early detection: NetFlow data, Vulnerability scan, Intrusion Detection System (IDS) logs, usage of IP reputation and threat feeds, and DNS telemetry.

• NetFlow data helped to reconstruct the incident and decide on how to improve security posture.

• Cleanup mainly consisted of a) better isolation (segmentation) of network devices, and **b) updating ** all infected devices.

• Monitoring of both ISP and enterprise infrastructure, namely regular vulnerability scans and update status of all key devices.

By leveraging advanced network analysis, data correlation, and proactive monitoring, security teams were able to detect the attack before critical OT assets were compromised. This case study underscores the importance of collaboration between ISPs and enterprises in fortifying cybersecurity defenses.

• Netflow analysis in Grafana
• Anomaly detection
• Flow enrichment with IP reputation
• Vulnerability scan
• Integration of DNS security solution data feed
• Integration of IDS logs in Grafana

✅ Firewall monitoring alone is insufficient—NetFlow data provides deeper insights into traffic flows.

✅ Proactive security measures at the ISP level can prevent attack propagation.

✅ Network segmentation and multi-source log correlation enhance detection capabilities.

✅ Attacks often exploit the weakest link—in this case, vulnerabilities within ISP infrastructure.