A DDoS attack map live in a browser tab, with its arcs of light sweeping from one continent to another and a counter ticking over in the corner, is one of the few pieces of security telemetry that a chief executive will happily watch for ten minutes, which is exactly why it ends up on the screen in the operations room and in the slide deck on the way to the board. As an instrument for working out whether your own site is under attack, it is close to useless. Not because the data is fake, but because the thing it measures is not the thing you are worried about.
This piece is the explanation that almost none of those dashboards ship with: what the major maps actually count, where their pictures of the world are distorted, and what to look at instead when your site is slow and nobody can tell you why.
What a live DDoS attack map is actually plotting
Nearly every public map draws on one of three telemetry sources, and the source decides what the map can see.
The first is anonymised flow data from internet service providers and network operators, usually NetFlow, sFlow or IPFIX records shared under a research agreement. That is the foundation of NETSCOUT’s ATLAS platform and the maps built on it. The second is a global deception network: honeypots and sensors advertised on public address space, logging whatever scans, probes and reflection traffic arrive. Radware’s Live Threat Map works this way. The third is endpoint, gateway or appliance telemetry reporting back to a vendor cloud, which is what powers the Kaspersky, Check Point and Fortinet visualisations.
Each sees a different slice. Flow telemetry sees large volumetric events crossing transit links. A deception network sees scanning, reflection sources and botnet chatter aimed at addresses nobody is actually using. Endpoint telemetry sees malware detections on machines running that vendor’s software, which is a population, not the internet.
“Live”nearly always means “near real time”
Flow records are sampled, often at 1-in-1000 packets or thereabouts, then aggregated, classified and published on a delay that is usually measured in minutes rather than seconds. Attack duration has to be inferred from when a signature starts and stops. So when a map animates a bolt landing in Frankfurt, it is replaying a statistical reconstruction of something that began a few minutes ago, assembled from a sample. Useful for trend. Not useful for timing an incident.
A DDoS map and a cyber threat map are not the same product
This is the confusion that does the most damage in board papers. Check Point’s ThreatCloud map counts malware, phishing and exploit events alongside other detection categories, and the headline “attacks today”figure is a total across all of them. Quote it as a DDoS count and you have misled your own board. Kaspersky’s real-time map is explicit about its categories too, listing on-access scans, web and mail anti-virus hits, intrusion detection and botnet activity as separate feeds. Read the legend before you screenshot anything.
What is hidden on purpose
No public map names a victim. Target IP ranges, customer identities and the specific prefixes under attack are stripped out, because the operators feeding the data are under contract not to expose the people paying them. That omission is reasonable and permanent. It also means the map structurally cannot answer the question most readers arrive with.
The best-known maps and what each is actually good for
NETSCOUT Cyber Threat Horizon and Digital Attack Map
Both are built on service provider flow telemetry. Cyber Threat Horizon is the current, richer view, with filtering by country, attack vector, bandwidth and duration. The older Digital Attack Map, produced with Google Jigsaw, is the one most people stumble onto first, and it states plainly on its own pages that it displays only the largest reported attacks. That single disclosure explains most of the misreadings in this article. Use these for vector breakdowns and for seeing whether a campaign wave is broad or narrow.
Radware Live Threat Map
Drawn from a global deception network, which makes it good for spotting scanning surges and reflection source activity, and poor as a measure of who is being hit. Honeypots are not customers. They have no checkout page to protect, so nothing they record tells you what a real application was doing under load.
Kaspersky, Check Point, Fortinet and the reseller rebuilds
Treat these as broad threat visualisations with a DDoS or botnet layer, not as DDoS instrumentation. You will also find the same feeds embedded, rebranded, on hosting and reseller sites. The data underneath is someone else’s, usually with less context attached than the original.
How to choose? Match the data source to the question. If you want vector mix, use flow-based maps. If you want reflection and scanning signals, use a deception-based one. Bookmark two and compare them, because a single map’s quiet day is often just a quiet sensor.
How to read the map without being misled
Source-country shading is the least reliable element on any of these dashboards, and it is the element everyone looks at first. Volumetric reflection and amplification forge the source address: the attacker sends a small spoofed request to an open resolver or service, and the much larger answer goes to the victim. The arc on the map so traces the reflector, not the buyer. Memcached reflection on UDP 11211 and NTP monlist amplification both appear to originate wherever those misconfigured servers happen to live. A country can light up red while hosting no attacker at all, only poorly maintained infrastructure. Source address validation at the network edge, set out in BCP 38, is what would reduce this, and adoption has been incomplete for over two decades.
Size filters hide the long tail. A map showing only the top slice of reported attacks by bandwidth will never display a 2 Gbps HTTP flood aimed at a single search or checkout path, the kind that quietly costs a retailer a trading afternoon. Flow telemetry is biased towards big, noisy, network-layer events because those are what cross transit links visibly. The attacks that actually take sites down are often modest application-layer request floods arriving at a few thousand requests per second against the most expensive endpoint on the site.
Attack type labels compress wildly different problems. “UDP”on a map covers amplification families with very different mitigation needs, and a single “application”category may lump slow-read attacks in with high-rate HTTP floods. Check the time zone handling and the window length too: most maps run a rolling 24 hours in UTC, and some continue to animate pleasantly when live data is thin.
Why the map cannot tell you your own site is down
Your target prefix is not on any public map. No spike near your city means nothing about your availability, and a spike near your city means nothing about your incident either. During the first ten minutes, the map is a distraction from the evidence that matters, which lives in your own edge.
Look at these, in roughly this order: requests per second grouped by ASN, user agent and URI path; origin netflow compared with your normal baseline; CDN or proxy cache hit ratio, because a request flood against uncacheable paths drives it through the floor; 5xx and upstream timeout rates; and authoritative DNS query volume, which is often where the first anomaly shows up. If your logs cannot be grouped by ASN quickly, fix that before the next incident rather than during it.
Proxy bypass deserves its own paragraph, because it is misdiagnosed constantly. When traffic lands directly on an origin that is supposedly behind a proxy, the cause is far more often origin IP leakage than any scrubbing centre being overwhelmed: outbound mail headers, a forgotten A record on a subdomain, historical DNS records in public datasets, certificate transparency logs, or a staging host that was never moved. Resolve every record on your domain and test what the origin answers when the proxy is bypassed. The answer should be nothing at all from the public internet.
Before you escalate, separate an attack from an outage. A provider incident, a BGP problem upstream or an expired DNSSEC signature all look like “the site is down”from a desk. Check status pages, check from a second network, check whether your authoritative nameservers are answering, then call your transit or mitigation provider with specifics. Knowing in advance whether your ISP’s DDoS protection covers your circuit or only their core saves the first and worst ten minutes of that call.
From watching maps to measurable readiness
The readiness view no public dashboard can give you covers three surfaces, and most organisations have bought cover for two.
- Network and transport: volumetric and protocol floods, handled by capacity and filtering upstream of your circuit.
- Application layer: request floods against login, search, basket and API endpoints, handled by rate limiting, bot management and rules tuned to your traffic.
- Authoritative DNS: the layer most often left unmanaged. A fully proxied site is still unreachable if nobody can resolve its name, and no attack map will ever warn you about that.
A check you can do this afternoon, which no map can do for you: resolve your own domain’s authoritative nameservers, confirm how many separate networks and providers they sit across, and establish who is responsible for keeping them up at 03:00.
Then settle the always-on versus on-demand question honestly. On-demand mitigation requires detection, a decision and a BGP announcement or DNS change before clean traffic flows, and those minutes are real. Ask what a time-to-mitigate service level agreement measures from: detection, or your phone call? For short, sharp hacktivist floods of the kind the NCSC has warned UK organisations about, a diversion window can outlast the attack entirely. The NCSC’s denial of service guidance collection is a reasonable baseline to hold your own plan against.
Find out whose network and scrubbing capacity you have actually bought, including any resale chain sitting behind your supplier, and what “managed”means in your contract: onboarding and rule tuning, baselining, named escalation contacts, and whether a human on their side can change policy overnight without waiting for your sign-off. If not, you have bought monitoring, not management. The mechanics of how cloud scrubbing really works are worth understanding before you sign anything.
Where attack maps genuinely earn their place
They are good landscape evidence and poor incident evidence. A visible campaign wave or a shift in vector mix is a legitimate way to open a board conversation, provided you describe it as sector trend rather than measurement of your own risk. Pair it with your own downtime cost per hour, which is the number that actually moves a budget, and you have the beginnings of a defensible business case for always-on protection.
Judge providers on their attack reports and post-incident evidence, not on the map embedded in their marketing site. Anyone can render arcs. Far fewer will show you a vector breakdown, a time-to-mitigate figure and a root cause note from a real event on your own estate.
A workable routine: glance at two maps weekly for vector and campaign trend; monthly, log your own peak requests per second, cache hit ratio and DNS query volume so you have a baseline worth alerting on; and review your origin exposure and nameserver spread every quarter. For the next read, the ongoing reporting on DDoS attacks, botnets and mitigation vendors will tell you more about your actual exposure than any DDoS attack map live on the wall.
Frequently Asked Questions
Is a live DDoS attack map real time?
Near real time, not real time. Flow-based maps work from sampled records that are aggregated and classified before publication, typically introducing a delay of minutes, and attack duration is inferred rather than observed directly. Some maps also keep animating during quiet periods, so continuous movement is not proof of continuous data.
Can a DDoS attack map tell me if my own website is under attack?
No. Public maps deliberately strip out victim identities and target IP ranges because the operators supplying the telemetry are contractually required to protect their customers. Your prefix will never appear, so neither a spike nor a quiet map says anything about your availability.
Why do attack maps show so many attacks coming from the same few countries?
Mostly because that is where spoofable reflectors and compromised devices sit. Reflection and amplification forge the source address, so traffic from an open DNS resolver, an NTP server responding to monlist, a CLDAP service or an exposed memcached instance on UDP 11211 appears to come from the reflector’s location, not the attacker’s. Countries with large hosting estates and weak source address validation dominate the picture.
Which live DDoS attack map is the most accurate?
Accuracy depends on the question. For vector mix and large volumetric events, flow-based views such as NETSCOUT Cyber Threat Horizon rest on the broadest provider telemetry. For scanning and reflection source activity, a deception-network map such as Radware’s is closer to the signal. None of them is accurate about who is being attacked, because that data is withheld by design.
My site is slow but the map shows nothing. What should I check first?
Your own edge. Group requests per second by ASN, user agent and URI path to see whether one endpoint is being hammered, compare origin netflow against baseline, check cache hit ratio and 5xx rates, and look at authoritative DNS query volume. Then confirm whether your origin IP is answering directly despite the proxy, since leaked origin addresses cause more bypass incidents than sheer attack volume does.