Hacktivist DDoS Campaigns: What Their Structure Means for Defenders

Most published analysis of politically motivated denial-of-service activity is organised around actors: who claimed what, which banner appeared on which channel, which groups appear to be cooperating this month. For a journalist or an intelligence analyst that is the right organising principle. For the person responsible for keeping a national payments portal, a regional ISP or a ministry’s public services reachable, it is close to useless.

The names change constantly. Groups that operate through public channels split, rebrand, absorb each other and claim work that was done by someone else, and because participation is self-selected and claims are self-reported, there is no reliable way for an outside observer to verify who did what. Meanwhile the thing that would actually inform a defensive decision — how these campaigns are shaped — barely changes at all.

This guide therefore deliberately names nobody. It treats politically motivated, volunteer-driven denial-of-service activity as a class with a recognisable structure, sets out what that structure is, and then works through what it implies for how a defence should be built. The argument is that the implications are architectural rather than tactical: the structure of these campaigns rewards a particular posture, and no amount of preparedness in the wrong posture substitutes for it.

The structural signature of a volunteer-driven campaign

Five characteristics recur often enough across this class of activity to be treated as defining. None of them is a technique. All of them are properties of how the effort is organised.

Targets are announced before they are attacked. Publication is not an operational mistake; it is part of the method. A campaign that depends on voluntary participation has to tell participants where to point their tooling, and a campaign whose objective is visibility benefits from an audience that knows in advance what to look for. Lists circulate on public or semi-public channels, usually organised by country or by sector, and frequently include organisations that are symbolically rather than operationally significant.

Participation is distributed across ordinary people running simple tooling. Rather than a botnet of compromised hosts under one operator’s control, the traffic source is a population of supporters who have chosen to run something — a small application, a script, a web page left open in a browser tab — that generates requests against a coordinated target list. The tooling is deliberately undemanding: it has to work on a laptop, without technical knowledge, without configuration.

Activity comes in bursts timed to political events. Summits, votes, anniversaries, state visits, contentious decisions, high-profile announcements. The timing is the message. This produces a characteristic pattern of concentrated activity in short windows separated by quiet periods, rather than a steady background level.

Breadth is preferred to depth. Effort is spread across many targets in one window rather than concentrated on one until it fails. A campaign that lists forty organisations and briefly disrupts eight of them has, by its own measure, done well. This is the opposite of the economics of an extortion-driven attack, where sustained pressure on one victim is the entire point.

The objective is publicity, not damage. This is the characteristic from which most of the defensive consequences flow, and it deserves stating precisely. The campaign is not trying to destroy your service; it is trying to produce evidence that your service was unavailable. A screenshot from a public availability checker, a short period of failed requests visible to third parties, a local news item — these satisfy the objective. Whether your business lost meaningful revenue is irrelevant to the attacker’s success condition.

Appliance	Volunteer-driven political campaign	Extortion-driven flood	Targeted attack on one service
How targets are chosen	Announced in advance, often as a public list tied to a country or sector	Selected for ability to pay and sensitivity to downtime	Selected for a specific operational reason, rarely disclosed
Typical breadth	Many organisations in one window	One organisation at a time	One organisation, sometimes one endpoint
Typical duration per target	Short — minutes to a few hours, then the effort moves on	Sustained, with escalation between demands	As long as the objective requires
Predominant layer	Application layer and connection exhaustion, with volumetric bursts	Volumetric, chosen for demonstrable scale	Whatever the target's weakest point is
What counts as success for the attacker	A screenshot of an unreachable site, published	Payment	The operational effect, whether or not anyone notices
What the defence must optimise for	Time to mitigation measured in seconds, always in path	Absorbing sustained volume without paying	Depth of inspection on the specific service

These are generalisations across classes of activity, not a taxonomy any single incident will fit cleanly. A campaign can be volunteer-driven in appearance and something else in substance, and the same target can be attacked by more than one class of actor in the same week. The value of the table is in the last two rows: different objectives reward different defensive properties.

Two consequences of an unusual success condition

Read the last characteristic carefully and two uncomfortable conclusions follow.

The first is that the attacker’s threshold for success is far lower than yours for failure. An organisation with a mature availability programme thinks in terms of service level objectives measured over months. An attacker in this class needs a few minutes. Those two clocks are not merely different in magnitude; they measure different things. Your monthly availability figure can remain immaculate through an event that produced a screenshot which is still circulating a year later.

The second is that response time is the whole game. In a threat model where the attacker needs sustained saturation, a defence that takes several minutes to engage is imperfect but adequate — the attack continues, the defence arrives, the attack is absorbed. In a threat model where the attacker needs a brief visible outage, a defence that takes several minutes to engage has already lost by the time it works. It converts a potential non-event into a successfully claimed one.

This is why the on-demand posture, which is a perfectly reasonable answer to a volumetric threat model, is a structurally poor answer to this one.

The point of that diagram in this context is not that cloud capacity is unhelpful. It is that the engagement model matters more than the capacity when the attack is short. An always-on tier — whether an inline appliance or a permanently engaged upstream service — has nothing to converge, because it is already carrying the traffic when the burst begins. An on-demand tier has to be summoned, and summoning takes exactly the kind of time this class of attacker is counting on. Our comparison of cloud, on-premise and hybrid architectures works through the general trade-off between those engagement models; the observation specific to politically motivated campaigns is narrower. Against a threat whose success condition is measured in minutes, the on-demand model’s defining economy — paying only when attacked — is paid for in exactly the currency that decides the outcome.

Why volumetric readiness alone leaves the gap open

The second architectural consequence follows from breadth over depth, and from the nature of the tooling.

Distributing effort across many targets means that the traffic arriving at any one of them is frequently moderate. Simple tooling run from consumer connections does not, in aggregate, reliably produce the kind of volume that saturates a well-provisioned access circuit — and it does not need to. Requests aimed at a search endpoint, a login form, a report generator, a document download or any other path where one request causes disproportionate server-side work can exhaust an application long before they trouble the network.

This is the failure mode that catches organisations who believe they are protected. The defence is sized, tested and monitored against bandwidth. The attack never approaches the bandwidth threshold. The service is nonetheless unavailable, because the exhausted resource was a connection table, a thread pool, a database connection limit or a rate-limited downstream dependency.

The consequence for readiness testing is direct. A proof of concept built around synthetic volumetric floods measures the part of the problem this class of campaign is least likely to present. What needs testing is behaviour under connection exhaustion while the circuit is healthy; under slow-request patterns that hold sessions open without sending much data; under request floods that are individually well-formed and collectively ruinous; and under traffic whose source addresses are geographically diverse, residential and not obviously distinguishable from your real users.

That last property deserves emphasis because it is where crude defences fail hardest. When the traffic originates from a population of volunteers on ordinary consumer connections, it comes from residential address space in many countries, from real browsers with plausible headers, over properly completed TCP and TLS handshakes. Blocking by source geography, by autonomous system, or by any coarse reputation signal will remove legitimate users at a rate that makes the cure indistinguishable from the disease. Distinguishing this traffic requires behavioural analysis against a baseline of what your own application normally does — which is a property of where the mitigation sits and what it has learned, not of how much capacity stands behind it.

A related pattern worth knowing is traffic spread thinly across an entire address block so that no single destination crosses a per-host threshold while the aggregate does real damage; we treat that specific detection problem separately in carpet-bombing detection and mitigation. The general lesson is the same: thresholds set at the wrong granularity produce a defence that is technically operating and practically absent.

The published list is an intelligence asset, if you use it correctly

Because target selection is announced, defenders have something they almost never get in other threat classes: advance visibility of the selection logic. It is worth being precise about what this is and is not worth.

It is a poor predictor of events. Inclusion on a list does not imply that an attack will follow, that it will follow soon, or that whoever published the list has the participation to act on it. Publication is itself a low-cost act, and treating every list as an alert produces alert fatigue and nothing else.

It is a good description of criteria. Lists reveal which sectors, which countries and which kinds of organisation are considered symbolically valuable in a given period. Read across several of them and the selection logic becomes legible: public-facing services associated with government, transport, finance, energy and media recur, as do organisations whose names carry national association regardless of their actual criticality.

The correct use is therefore to compare the criteria against your own exposure, not to monitor for your own name. Three questions do most of the work:

1. Which of our services would a stranger describe as symbolically significant? Not business-critical — symbolic. A rarely used public information portal carrying a national coat of arms is a more attractive target than an internal system that would cost far more to lose.
2. Which of those are reachable, and what is the minimum surface required? Administrative interfaces, staging environments, legacy endpoints and forgotten subdomains routinely remain publicly reachable long after anyone needs them to be. Removing them is the cheapest defensive act available and it is almost never done during a campaign period, because during a campaign period nobody has time.
3. Which of them share a dependency? A single reverse proxy, a single authoritative DNS arrangement, a single upstream circuit or a single authentication service in front of several symbolic targets converts a campaign of breadth into a campaign of depth without the attacker having to intend it.

The reputational dimension, treated as an engineering input

There is a natural temptation to regard the publicity objective as a communications problem and hand it to the communications team. That is half right, and the wrong half to act on first.

Publicity is the objective function, which means it belongs in the engineering requirements. Concretely: it changes what your monitoring has to detect, because an outage nobody internally noticed can still have been observed and recorded externally; it changes your measurement point, because what matters is reachability as a third party experiences it, not as your internal probes do; and it changes the value of very fast mitigation relative to very large capacity, because a burst absorbed within seconds produces no evidence at all.

It also has a genuine communications component, which is best prepared for in the same way as any other part of the response. A pre-agreed holding statement. A named spokesperson with a named deputy. A decision rule about whether an absorbed event is acknowledged publicly at all — there are defensible answers in both directions, and the wrong time to reason about it is during the event. And an out-of-band channel to reach the communications function when the corporate website is the thing that is unavailable.

One further point about internal communication. Campaign periods generate a high volume of low-impact events, which places a specific strain on the process that decides whether something is significant. Under NIS2 that decision has regulatory weight, and the translation of NIS2’s duties into DDoS architecture sets out why the significance threshold has to be written down, approved at management level and expressed in service metrics rather than in regulatory language. The reason it matters especially here is volume: an unwritten threshold survives one incident a year and collapses under twenty in a fortnight.

What this means for the three audiences most exposed

The structural properties land differently depending on what you operate.

For ISPs and telecommunications operators, the campaign class is mostly a customer problem that becomes an operator problem through shared infrastructure. Traffic aimed at one hosted customer transits your edge, your peering and your aggregation, and an attack too small to matter to your backbone can still exhaust a shared stateful device or degrade neighbours in the same block. The relevant capability is per-customer and per-prefix visibility with the ability to act at that granularity, rather than aggregate capacity — a theme developed in our buyer’s guide for ISPs and telecoms. The second requirement is a mitigation request path your customers can actually use during an event, which means it must not depend on the connectivity that is currently saturated.

For government bodies, the exposure is concentrated in exactly the services this class of campaign selects for: public-facing portals, information sites, service delivery platforms, and anything whose name carries national association. Two structural weaknesses recur. Consolidation of many public services behind shared hosting or a shared front end — a deliberate design choice in several national digital programmes — means one successful burst produces many simultaneous unavailable services and therefore a much larger publicity return. And procurement timelines mean the gap between recognising the need and having a capability in place is measured in months, which is the strongest possible argument for treating this as an architectural matter to be settled in advance rather than a contingency to be arranged when a campaign begins.

For enterprises, the difficulty is usually that the exposure is not proportional to anything the risk register tracks. An organisation may be selected because of its country, its sector, its ownership, a contract it holds or a statement its leadership made, none of which appear in a conventional threat assessment. The practical implication is that the question “are we likely to be targeted?” is less useful than “if we are, how long would a burst against our public services remain visible?” — because the second question has an engineering answer that is worth having regardless of how the first is answered.

Why the correct response is architectural rather than reactive

Bring the pieces together and the conclusion is fairly tight.

The attacks are short, so mitigation must already be in the path. The attacks are frequently application-layer and moderate in volume, so the mitigation must understand the application rather than only the bandwidth. The attacks come in clusters during event-driven windows, so the defence cannot depend on human decisions made quickly at unpredictable hours. The traffic resembles legitimate users, so classification must rest on behavioural baselines rather than coarse origin filters. And the objective is publicity, so the value of a defence is concentrated in the first seconds rather than distributed across the duration.

Every one of those properties is settled at design time. None of them can be improvised during a campaign window. This is what makes the response architectural: the decisions that determine the outcome — where inspection happens, whether it is always in the path, whether it holds enough application context to distinguish a plausible-looking flood from a genuine traffic spike, whether escalation to upstream capacity has been rehearsed — are all made before anyone publishes a list with your name on it.

The practical shape that follows is an always-on layer handling everything below the access circuit, with full application-layer coverage and detection built from a baseline of your own traffic, paired with an upstream tier reserved for volumetric events that exceed the circuit. Appliances designed around always-on inline operation with L3–L7 coverage in a single device and locally trained detection occupy the first position by design. The criteria matter more than the product name, and they should go into a requirements document in that form: always in path, application-layer capable without a separate device, and able to build its behavioural baseline from your traffic rather than from a general model.

A readiness checklist for a campaign period

The following is deliberately short and consists only of things that can be verified rather than asserted.

1. A measured detection-to-mitigation figure, obtained from your own environment, for an application-layer attack — not a vendor’s volumetric demonstration.
2. External reachability monitoring from outside your network and outside your provider, because that is the vantage point from which the attacker’s evidence is produced.
3. An inventory of publicly reachable services, with an owner for each and a decision recorded about whether it needs to be reachable at all.
4. A shared-dependency map showing which symbolic targets sit behind the same proxy, circuit, DNS arrangement or authentication service.
5. A written significance threshold, approved in advance, that can be applied to twenty low-impact events in a fortnight without twenty separate judgement calls.
6. An out-of-band escalation path to both your upstream provider and your communications function, tested, with the date of the last test recorded.
7. A pre-drafted holding statement and a named spokesperson with a deputy.
8. Retained attack telemetry you hold yourself, with a known retention window and a known export mechanism, because the reporting deadlines are yours regardless of who operated the mitigation.

An organisation that can produce those eight things has done the substantive work for this threat class. One that has bought capacity and not tested engagement has bought a defence sized for a different problem.

Sources and further reading

European threat context. The annual ENISA Threat Landscape published by the European Union Agency for Cybersecurity is the standard open reference for the European picture, and denial of service is one of its tracked threat categories; it discusses politically motivated activity as a phenomenon and is written at the level of pattern rather than attribution, which is the right altitude for defensive planning. ENISA also publishes sectoral analysis across the NIS2 sectors that is useful for understanding where availability exposure concentrates.

Public quarterly DDoS reporting. Cloudflare and Akamai each publish regular public reports on attack volumes, vector mix and sector distribution, and these are the most widely cited open sources for trend data. Read them with one structural caveat firmly in mind: each is compiled from the vendor’s own customer base and reflects what that vendor’s customers experienced and what its platform measures. They describe a large sample, not a census, and distributions differ between them for exactly that reason.

National guidance. Your national CSIRT or cybersecurity authority is usually the most operationally useful source during a campaign period, because national bodies publish sector-specific advisories with a currency that no annual report can match. In the United States, the joint guidance on understanding and responding to distributed denial-of-service attacks published by CISA with the FBI and MS-ISAC is a well-structured open reference whose technical content applies regardless of jurisdiction.

Incident handling. NIST SP 800-61, Computer Security Incident Handling Guide, remains the standard external reference for the incident lifecycle that reporting obligations assume. NIST SP 800-34 covers contingency planning, and the NIST Cybersecurity Framework 2.0 is a reasonable organising structure for the evidence set above.

Technical standards. RFC 4732, Internet Denial-of-Service Considerations, is still the clearest statement of the problem class. BCP 38 (RFC 2827) and BCP 84 (RFC 3704) cover ingress filtering, which is what prevents your own network from contributing to someone else’s incident. RFC 5635 covers remotely triggered black hole filtering; RFC 8955 and RFC 8956 define BGP FlowSpec; RFC 9132, RFC 8783 and RFC 8811 define DOTS, the standards-based signalling interface for requesting mitigation from an upstream party — the relevant standard when you want the handover between your own layer and an upstream one to be open rather than proprietary. RFC 7011 (IPFIX) is the standard underlying the flow telemetry your post-incident reporting will draw on.

On the application layer specifically. CVE-2023-44487, the HTTP/2 Rapid Reset issue, remains the clearest public illustration of the general point made above: a protocol-level weakness that allowed a modest number of connections to consume disproportionate server resources, and which no amount of bandwidth provisioning could have isolated. It is worth reading as a reminder that application-layer exposure is a property of protocols and implementations, not only of attacker capacity.

Regulatory. Directive (EU) 2022/2555 (NIS2) and, more importantly, your own member state’s transposing legislation, which is the text that actually binds you. For entities in accession and neighbourhood states, the same requirements typically arrive by contract — through the supply-chain expectations of in-scope customers — well before they arrive by statute.

A closing caution on attribution. Public claims of responsibility in this space are self-reported, unverifiable from outside, and frequently contested between groups that claim the same event. Nothing in a defensive programme should depend on believing them. The structure described in this guide is observable in the traffic and in the timing; the identity behind it is not, and treating the two with the same confidence is how threat intelligence becomes theatre.