The November 2025 Danish election attacks: what our own network data shows

A transparency statement from MIRhosting. Every figure below comes from our own preserved, hash-verified monitoring data. The full dataset is held securely and is available to the relevant authorities on request.

In recent reporting, MIRhosting's network has been named in connection with the wave of distributed denial-of-service (DDoS) attacks that struck Danish municipal, government, party, bank and media websites around the 18 November 2025 elections. We take that seriously. Rather than respond with adjectives, we have gone back to the one thing that can actually answer the question - the traffic records from our own network - preserved them, and are now publishing what they show.

The short version is this: during the period in question, our network and the customers we connect to the internet were on the receiving end of these attacks. Our monitoring shows attack traffic arriving inbound, toward addresses we carry, and we defended against it. It does not show attacks leaving our network toward anyone else.

First, what MIRhosting actually is

MIRhosting operates an internet network - autonomous system AS52000 - that provides connectivity and transit to hosting and colocation customers. In plain terms, we are closer to a road or a telecoms carrier than to a driver. Traffic from many different customers passes across our network on its way to and from the wider internet.

That distinction matters for understanding what a DDoS attack is and where it comes from. A modern DDoS campaign of the kind reported in Denmark is a distributed attack: traffic converges on a victim from many thousands of unrelated machines all over the world, all firing at once to overwhelm the target. The flood does not originate from a single hosting network and pour out of it. It arrives at the victim from everywhere.

This is the key to reading the data correctly. If MIRhosting's network had been the source of attacks, the signature would be unmistakable: abnormal volumes of traffic leaving AS52000. If our network was instead carrying customers who were being attacked, the signature would be floods arriving inbound, toward those customers. Our records show the second pattern, clearly and consistently.

What the data shows

We preserved monitoring data across our two relevant locations (Netherlands and Germany) for the window 1 October – 30 November 2025, with the Danish election week (13–19 November) sitting inside it. Four findings stand out.

1. Every attack was inbound. None was outbound.
Our edge detection systems recorded 4,468 DDoS anomalies across the full window. Every single one was inbound - aimed at addresses we transit. Zero were attacks leaving our network toward an outside victim. Narrowing to the election week itself, the picture is identical: 620 anomalies, all inbound, none outbound. The asymmetry is not a quirk of the wider window; it holds in the election week in isolation.

The corresponding chart is shown in the image above under number 1.- 4,468 inbound, 0 outbound

2. The attacks were aimed at customers we connect, not launched from us.
The largest single concentration of inbound attack traffic in our data was directed at the address space of one customer network, WorkTitans (AS209847) - 4,237 of the inbound anomalies, totalling roughly 52 TB of inbound traffic across the full two-month window. (Spread across more than four thousand separate events, that is a small amount per event - the signature of a campaign made up of many modest floods rather than a few record-breaking ones, which is exactly what this kind of distributed attack typically looks like.) A further 229 inbound anomalies were aimed at other, smaller customers whose identities we keep confidential. In our network data, these appear as destinations of attack traffic, not sources. Whatever separate questions exist about any individual customer are matters for the authorities, not something our traffic data speaks to; what our data does establish is the direction - traffic arriving toward these addresses, not leaving our network toward others.

The corresponding chart is shown in the image above under number 2 — who the attacks were aimed at

3. Our own network was not attacked during the election week — and showed no attack signature.
Addresses belonging to MIRhosting's own space (AS52000) saw zero anomalies during the election week. (Two trivial events appear earlier, on 9 and 13 October, both under 1 Gbps and requiring no mitigation  well outside the window.)

4. There was no traffic surge on our network during the election week.
Total traffic leaving our network during the election week ran at about 1.12× our early-October baseline by daily average (1.13× by daily peak) - ordinary week-to-week growth, nothing more. The single busiest day of the entire two-month period was 27 October at 1.24× baseline - outside the election week entirely. There is no surge consistent with our network sourcing a large attack.

The corresponding chart is shown in the image above under number 3- no spike during the election week

What we did about it

Throughout the period, MIRhosting acted defensively. Every one of the 4,468 inbound anomalies was detected and handled at our edge, and the heaviest floods were escalated to BGP-blackhole mitigation (68 across the full window, 6 during the election week) to protect the targeted customers. That is the behaviour of a network defending the people being attacked.

The corresponding chart is shown in the image above under number 4. - every anomaly handled; the heaviest blackholed

Being honest about what this data can and cannot prove

We would rather state our own limits than have them pointed out. So, plainly:

The election-week traffic record survives at one reading per day (daily average and daily peak). That is enough to rule out a sustained surge, and we show both the average and the peak - but at that resolution it cannot, by itself, exclude a brief sub-hour micro-burst. Our finding of "zero outbound attacks" reflects what our edge detection recorded; it is corroborated by, but does not rest solely on, the flat traffic baseline. And mapping an address to a network proves who owns that address - which is what our target counts rely on — rather than tracing an individual packet's origin.

We make these caveats openly because they are the difference between a statistic and a slogan. None of them changes the central, measured finding: in our data, the attacks came toward the customers we protect, and nothing anomalous left our network.

Why "nothing came from us" is the expected result, not a lucky one

It is worth being clear that our finding is not a surprise we are relieved by — it is the technically correct outcome for a network in our position. In a distributed attack, the flood comes from thousands of scattered machines, not from the hosting or transit provider. For an internet-transit network like ours, the expected and honest result is exactly what we observe: attacks arriving toward the customers we carry, and no anomalous traffic leaving our own network. We present that as a positive, measured fact - not as "we looked and found nothing."

What reached us - and what didn't

It is relevant to the record to be precise about what we have, and have not, been given in connection with these specific attacks.

We have received no abuse reports, no complaints, and no requests for assistance or information about the Danish election DDoS attacks - not from the targeted parties, not from the other networks involved, and not through the abuse channels that exist for exactly this situation. When a network is identified as a source of attack traffic, the established and routine response is an abuse notification asking the operator to act. In connection with these attacks, none reached us.

Nor have we been shown any technical specifics we could examine. The public attribution naming our network rested on an unnamed source and on material that has not been published. At no point were we provided with the IP addresses, timestamps, or network-level data the claim is said to rest on - the very details that would let us check it against our own records and respond to something concrete rather than to a characterization.

We set this out not to criticise anyone's reporting, but to explain our approach. A claim that cannot be examined cannot be answered on its own terms. So rather than wait for specifics that were never shared, we did the examinable thing: we preserved our own data and published it, in full, for anyone - including the authorities - to check.

Where this goes from here

We have preserved the complete forensic record - the raw per-event data, a full chain-of-custody manifest, and SHA-256 hashes of every artifact - and we will make it available to the relevant legal and regulatory authorities on request. The aggregate figures behind every chart above are published alongside this statement so that anyone can check them.

MIRhosting operates lawfully, cooperates with the authorities, and takes abuse of its network seriously. On the specific technical question that has been raised - whether these attacks originated from or were launched through our network - our own data gives a clear answer, and we are putting that data on the table.