Tag Archives: hacktivist ddos attack motives

NCSC Hacktivist DDOS Warning: A 7-Step Response

The NCSC hacktivist DDoS warning has been read, filed and forwarded inside a lot of UK organisations over the past two years, usually with a covering note that says “for info”and a promise to raise it at the next security working group. Filing it is not a response. The warning describes a threat that is cheap to launch, picked by sector list and announced on Telegram before and after the fact, which means the organisations it names can be hit on a Thursday evening without anyone having placed a single order with a mitigation provider.

What follows is a seven-step plan to move from “we read the alert”to a position where your network, application and DNS surfaces are each covered, your origin address is not leaking, and somebody named can authorise mitigation at two in the morning.

What the NCSC hacktivist DDoS warning actually says, and who it applies to

In April 2023 the National Cyber Security Centre (NCSC) issued an alert about an emerging threat to UK critical national infrastructure from state-aligned groups sympathetic to Russia’s invasion of Ukraine. The substance was unambiguous: these actors are ideologically rather than financially motivated, less predictable than criminal crews because they are not negotiating for money, and most capable of distributed denial-of-service (DDoS) attacks, website defacement and the spread of misinformation. The NCSC has repeated versions of that assessment since, and its published denial-of-service guidance has been the practical counterpart to it.

Self-described pro-Russia groups, NoName057(16) and Killnet among the most publicised, have claimed large numbers of DDoS attacks against European government, transport and financial websites. Attribution and genuine command relationships remain an open question, and should be treated as one. The operational picture is clearer than the political one.

“Low sophistication”is not “low impact”

Most coverage repeats the phrase low sophistication and moves on, which leaves readers with the impression that the risk is cosmetic. It is not, because impact depends on when the service is unavailable rather than for how long. Take a council planning portal with a statutory consultation closing at 23:59. A twenty-minute application-layer burst starting at 23:40 does more damage in legal and reputational terms than a two-hour volumetric flood on a quiet Sunday afternoon. Same attacker, same toolkit, wildly different consequence.

Anywhere you have a published availability commitment, a regulatory reporting window, a payment cut-off or a same-day deadline, you have converted a nuisance into an exposure.

Who is in scope beyond the named sectors

The alert named critical national infrastructure, but the practical target list is wider: hosting providers, SaaS suppliers, payment partners, parcel and booking platforms, and anyone whose logo appears on a target organisation’s website. Groups chasing visible disruption frequently hit a supplier as a proxy for the body they actually want to embarrass, because the supplier is usually smaller, less defended and still produces a usable screenshot. If your customer is a government department, you are on the list whether or not you consider yourself part of the sector. That dynamic is one reason DDoS attacks on government websites keep succeeding even where the department itself is well protected.

Steps 1 and 2: map your three attack surfaces, then find the one nobody owns

Before anyone buys anything, write down three surfaces and the name of the person or supplier who manages each. In this order: network and transport (your IP ranges and transit), application layer (HTTPS endpoints, APIs, login flows), and authoritative DNS.

Step one is producing that one-page map. Step two is the uncomfortable part: finding the surface with no owner. In practice it is almost always DNS. An organisation reads an NCSC alert, buys a reverse proxy for the main website, ticks the box, and leaves the zone sitting on a registrar’s default nameservers with no secondary provider. Take out name resolution and the proxy becomes irrelevant, because nobody can resolve the hostname that points at it. If you are reviewing that surface for the first time, our buyer’s guide to authoritative DNS DDoS protection sets out what a second provider should actually give you.

On the application layer, list the endpoints where one request costs you far more than it costs the attacker: site search, postcode and address lookup, PDF or report generation, basket calculations, login and password reset. A hacktivist tool sending a few thousand requests per second at a search box can saturate a database tier that shrugs off ten times the traffic against static pages. That asymmetry, rather than raw bandwidth, is what the real gaps in application-layer protection tend to come down to.

Step 3: close origin IP leakage before you trust your proxy

When a proxy is bypassed during these campaigns, the cause is rarely attack volume exceeding scrubbing capacity. It is nearly always a leaked origin address. Attackers do not need a zero-day for this; they need a search engine and twenty minutes.

Audit the usual leak paths, which are predictable enough to work through as a checklist: historical DNS records for the domain and its subdomains; certificate transparency log entries that expose internal and staging hostnames; mail servers, VPN concentrators or FTP hosts sitting on the same /24 as the web origin; old dev, uat and test hostnames still resolving to the real server; and error or debug pages that print a backend IP address in a stack trace.

The fix is free and routinely skipped. Lock the origin firewall so it accepts HTTP and HTTPS only from your provider’s published IP ranges, rotate the origin address after onboarding so the pre-proxy history is worthless, and re-check the ranges quarterly because they change. Then verify it rather than assuming: from a host outside those ranges, attempt a direct connection to the origin address on 80 and 443 and confirm it is refused or dropped. An untested allow-list is a belief, not a control.

Steps 4 and 5: choose always-on or on-demand, then time the escalation path

Step four is the architectural decision. Hacktivist activity tends to arrive as short, repeated bursts timed for attention: fifteen minutes, a pause, another ten minutes, then again the following evening. That pattern punishes on-demand models badly. If diversion depends on somebody noticing, somebody else authorising, and a BGP announcement propagating, the burst can be over before traffic reaches a scrubbing centre, and you will have paid for mitigation that arrived after the screenshot.

Advertised capacity in terabits per second is the least useful number in most sales decks for this threat profile. Time-to-mitigate is the variable that decides the outcome. Read the service level agreement carefully and establish what starts the clock: detection by the provider’s own monitoring, or receipt of a notification from you? Those two wordings can differ by half an hour of real downtime. Capacity still matters for other scenarios, and the arithmetic behind a terabit-scale DDoS attack is worth understanding, but it is not the constraint that loses you a 23:59 deadline.

Step five is testing the human path, which costs nothing. At 21:00 on a weekday, ring the provider’s network operations centre number, authenticate as you would during a live incident, and request authorisation for a simulated diversion. Time every stage: ring to answer, answer to authentication complete, authentication to a named engineer confirming they can change policy. Write the total down. That figure, not the SLA, is your real time-to-mitigate, and it is the single most persuasive document you can take into a renewal negotiation. Run the same drill when key staff change.

Step 6: pressure-test what “managed”means in your contract

The word managed carries no fixed meaning in DDoS contracts. If a human on the provider’s side is not empowered to change policy at 03:00 without waiting for your sign-off, you have bought monitoring, not management.

Insist that four things appear in writing: onboarding and initial rule tuning; ongoing traffic baselining so anomalies are measured against your normal; a named escalation matrix with authority levels and out-of-hours contacts; and an explicit statement of who applies changes during an attack. Then ask the resale chain question, because it decides minutes on the mitigation clock. Whose network and scrubbing capacity are you actually buying, and how many organisations sit between your phone call and the engineer typing the rule? Three handoffs at 02:00 is not a hypothetical problem.

Before signing, ask to see a redacted report from a real mitigated attack. It is the cheapest competence signal available. A good one names the vectors with a breakdown by volume, shows source distribution, records mitigation timestamps against detection timestamps, and lists the rules applied and why. A traffic graph with a reassuring dip in the middle tells you nothing. Treat SLA credits with the same scepticism; a credit worth a month’s fee does not cover a missed statutory deadline, and the realistic view of what the different DDoS protection models cost in the UK is a better planning input than a credit table.

Step 7: write the first hour down, then rehearse the communications

Step seven is a one-page runbook, not a plan document nobody opens. Five lines will do: confirm it is an attack rather than a self-inflicted outage; capture evidence; notify the provider through the escalation path you timed in step five; publish a holding status message on infrastructure entirely separate from the affected site; brief internally. The first line matters more than people expect, because a failed deployment and a layer-seven flood look identical on a monitoring dashboard for the first few minutes, and the question of DDoS or ordinary outage changes who you call.

Evidence capture is the step skipped under pressure and regretted afterwards. Keep timestamped web and load balancer logs, netflow or sampled packet captures, and the provider’s attack report. Unauthorised acts that impair the operation of a computer fall under sections 3 and 3ZA of the Computer Misuse Act 1990, and that evidence is what makes a referral to the NCSC and a report to Action Fraud usable months later rather than an anecdote.

On communications, two rules. Claimed victories on Telegram routinely overstate impact, so check independently whether the service was actually unavailable, ideally from outside your own network, before accepting the attacker’s version. And do not respond publicly to the group. Visible disruption and a reaction are the point of the exercise; a quiet, factual status update starves the campaign of the thing it wants. Decide in advance who speaks to the press, the regulator and the board, and what they may say while the incident is live. Usually that is confirmation of a service issue, no speculation on attribution, and no capacity or architecture detail.

Budgeting your response to the NCSC hacktivist DDoS warning

Price the downtime before pricing the protection. Lost transactions per hour, staff hours burned, the cost of a missed statutory deadline, and the slower reputational drag of a service being seen to fall over. That number sets your sensible ceiling, and it is frequently lower than vendors hope and higher than finance assumes.

Where the money goes: an always-on proxy for web and API traffic; a BGP scrubbing retainer if you announce your own ranges; a secondary authoritative DNS provider; and engineering time for web application firewall tuning, which is the line most often underfunded. The forgotten items are clean traffic or egress charges during an attack, onboarding fees, change request charges once rules need adjusting, and out-of-hours escalation premiums. Ask for all four in writing before you compare quotes.

On a constrained budget, sequence by cost. Steps one, two, three and five are mostly attention rather than money: the surface map, the ownership gap, the origin lock-down and the out-of-hours drill. Do those this quarter. Secondary DNS is usually modest. The always-on versus on-demand decision and the contract renegotiation can wait for the next budget cycle, armed with the drill timings you recorded. Groups whose motives run to publicity rather than profit behave in fairly predictable ways once you understand what they are optimising for, which is what makes a staged response reasonable rather than reckless.

Frequently Asked Questions

What does the NCSC hacktivist DDoS warning actually advise organisations to do?

The NCSC’s April 2023 alert on state-aligned groups sympathetic to Russia’s invasion of Ukraine asked critical national infrastructure operators to act on its existing resilience guidance rather than wait for a specific threat. In DDoS terms, that means understanding your public-facing surfaces, having mitigation arranged in advance, and knowing your escalation path. The NCSC’s published denial-of-service guidance is the practical companion to the alert.

Does the NCSC hacktivist DDoS warning apply to private suppliers, not just government bodies?

In practice, yes. Groups seeking visible disruption often target a supplier, hosting provider or payment partner because it is easier to knock over than the organisation they want to embarrass, and the outage still generates the headline. If your name or logo appears on a target’s site, treat yourself as in scope.

How big are hacktivist DDoS attacks in practice, and does size matter most?

Typically they are short, repeated bursts rather than sustained terabit floods, and frequently application-layer rather than purely volumetric. Size is not the variable that decides the outcome; how quickly mitigation engages is. A modest attack that runs unmitigated for twenty minutes during a deadline window beats a large one that is scrubbed in sixty seconds.

Should we switch to always-on mitigation because of the warning?

If your exposure includes deadline-bound or transactional services, always-on protection for web and API traffic is the stronger fit, because on-demand diversion and BGP propagation delay can exceed the length of the burst. If your public services are informational and tolerate a short interruption, an on-demand retainer may be proportionate, provided you have timed the real escalation path rather than trusting the SLA wording.

Who should we report a hacktivist DDoS attack to in the UK?

Report cyber incidents to the NCSC, and report the crime to Action Fraud, or to Police Scotland on 101 in Scotland. Regulated organisations may also have sector reporting duties with timescales of their own. Keep timestamped logs, netflow samples and the provider’s attack report, since that evidence is what supports any later action under the Computer Misuse Act 1990.

Why DDOS Attacks on Government Websites Succeed

A Telegram channel posts a screenshot of a council homepage timing out, the local paper picks it up before lunch, and by mid-afternoon a service owner who has paid for protection for three years is explaining to a director why the site fell over at a traffic volume the provider’s own graph calls unremarkable. That is what most DDoS attacks on government websites look like from the inside. Not a terabit flood. A modest, short, well-aimed burst that found the one hostname nobody had checked.

The public explanations available to a UK public sector team are either definitional (“what is a DDoS attack”) or legal (“it is an offence”) or advisory (“raise your posture”). Useful, none of them answer the question a service owner actually has after an outage: we bought protection, so why did the site go down anyway? The answers are boringly consistent. Leaked origin addresses, unmanaged authoritative DNS, expensive dynamic endpoints, microsite sprawl, and a contract where nobody is contractually obliged to touch a mitigation policy at 02:00.

What an attack on a public sector site actually looks like

Since 2022, the dominant pattern against UK and European public bodies has been pro-Russia hacktivist activity claimed on Telegram: a target list posted in advance or shortly after, availability-only disruption, no attempt at intrusion, and a screenshot of a failed page load as the deliverable. The NCSC published guidance on 25 March 2024 following denial of service attacks against UK political party websites, and has continued to issue advisories about hacktivist groups targeting UK organisations. Treat the pattern as recurring background weather rather than a lightning bolt from the blue.

The screenshot is the payload

This changes the defence economics more than most vendors admit. If the objective is a claim of responsibility rather than sustained damage, the attacker needs five to twenty minutes of visible failure, not five hours. Attacks that fail get quietly dropped from the channel, which is why unsuccessful attempts on high-profile targets tend to vanish from the record; our write-up of hacktivists failing to take the Vatican’s site offline is the shape of an attack that never becomes a story.

Why modest volumes still make national news

A twenty minute outage on a corporate brochure site is a support ticket. The same outage on a council homepage, during a period of political sensitivity, becomes a story about resilience of public services. Journalists do not have your traffic graph. They have a screenshot and a “service unavailable”page.

Confirm it is an attack before anyone briefs communications

Hosting platform failures and DNS provider incidents produce almost identical symptoms to a layer 7 flood, and the first version of the story tends to stick. Establish the difference before you say anything: our walkthrough on telling a DDoS from an outage in ten minutes covers the mechanics. Over-claiming has a cost of its own, because an availability attack that a press office describes as a “cyber attack on resident data”creates a breach narrative you then have to unwind.

What these attacks do not do

A volumetric or application-layer flood does not read your database, exfiltrate records or authenticate to anything. It denies service. Conflating the two in a holding statement invites subject access requests, member questions and an ICO conversation you did not need to have.

Why council and department sites fall over at modest attack volume

Origin IP leakage, the usual culprit

When a proxied site goes down under a few gigabits, the attacker has almost always found the origin. Public sector estates leak origin addresses more than most, because nothing ever gets deleted from a zone file. An MX record pointing at the same server that hosts the site. A staging. Or www2. Host left behind by a supplier in 2019. A consultation subdomain from a 2016 local plan with a live A record on the same /29. Historical DNS datasets and certificate transparency logs make finding these trivial, and no reverse proxy protects an address the attacker can hit directly.

The fix is an audit rather than a product: enumerate every record in every zone you own, resolve each one, and confirm nothing outside the protected set resolves to the origin range. Then firewall the origin to the proxy’s published prefixes and your own management ranges. Most teams find at least one surprise.

Authoritative DNS, the layer outside the contract

Ask a public sector team whether their DNS is protected and a reasonable number will mention Protective DNS. PDNS is a good control and it is not the answer to this question: it protects outbound resolution from staff devices and networks, not the availability of the authoritative name servers citizens query to find you. If those name servers are two boxes in one data centre, or a single provider with a thin anycast footprint, an attack on the DNS layer takes the site off the internet without touching the web tier. The buyer’s questions are in our guide to authoritative DNS DDoS protection.

Endpoints that cost you far more than they cost the attacker

Static pages are cheap to serve and cheap to cache. Site search, planning application lookups, licensing registers, bin collection by postcode, form submissions and large PDFs are not. A few hundred requests per second against a planning search can take down an estate that shrugs off tens of thousands of requests for the homepage. Attack tooling finds these by crawling, and the asymmetry is the point: one request, one uncached database query, one PDF generated on the fly.

Microsite sprawl

This is the structural weakness of the sector. Campaign domains bought for a two-year programme, partnership sites shared with three other authorities, legacy portals from a predecessor body, all with different suppliers, different DNS and inconsistent protection. One unprotected hostname resolving to shared origin infrastructure undoes the protection on everything hosted alongside it. Inventory of hostnames is a security control, not administration.

Check the three surfaces in order: DNS, network, application

DNS

You want an anycast footprint with real geographic spread, a second independent provider (dual-primary, or secondary via zone transfer), and TTL discipline that reflects a trade-off people rarely state out loud: short TTLs give you agility to move records during an incident, while longer TTLs mean resolvers keep serving cached answers if your name servers become unreachable. If you run DNSSEC across two providers, you need a multi-signer arrangement (RFC 8901) or careful key sharing, which is precisely the detail that gets discovered during the incident rather than before it. Our rundown of staying reachable through a DNS provider outage covers the failure modes.

Network and transport

Three honest options. A reverse proxy or CDN suits HTTP services and is the default for most citizen-facing sites, but only works if the origin is genuinely hidden. BGP scrubbing protects whole address ranges including non-HTTP services, and requires that you hold your own IP space and can announce at least a /24, which rules it out for the many authorities sitting on supplier addresses. Hosting-level filtering is the cheapest and most often oversold: ask directly whether “mitigation”at your host means scrubbing or null-routing your IP, because a remotely triggered black hole completes the attacker’s objective on your behalf.

Application layer, and the accessibility decision nobody schedules

Rate shaping per client, per path and per token is where you defend expensive endpoints. Challenge policy is harder, and it is an accessibility decision as much as a security one. A blanket CAPTCHA on a housing benefit or planning objection form excludes the people least able to route around it, and UK public sector sites sit under the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018, with government guidance now pointing at WCAG 2.2 AA (check the current position before you write a policy). Plan graduated responses: cache aggressively, shape by path, use lightweight non-interactive checks, and keep one tested low-friction route (a phone line, an alternative host, a plain form) that you can publish when you do turn challenges up.

A ten minute check a duty engineer can actually run

Query each authoritative name server directly and non-recursively (dig +norecurse @ns1.example SOA yourdomain.gov.uk). No answer from any of them and the problem is DNS, not the web tier.
Resolve the public hostname from two networks, one of them off your corporate connection.
Curl -sS -o /dev/null -w “%{http_code} %{time_total}\n”against the public hostname, then the same request pinned to the origin with –resolve and the correct Host header. Origin healthy plus public hostname failing points at the edge; both failing points at origin or capacity.
Compare requests per second, bandwidth and 5xx rate on the protection portal’s traffic graph against the same hour last week.
Check the hosting and DNS provider status pages before you declare anything.

What “managed”has to mean in a public sector DDoS contract

The dividing line is simple. If nobody on the supplier side is empowered to change a mitigation policy at 03:00 without waiting for your sign-off, you have bought monitoring, not management. Write it down in the contract: onboarding and rule tuning, always-on baselining, named escalation contacts on both sides, the out-of-hours trigger, and the authority to act.

Trace the resale chain

Plenty of “managed DDoS protection”bought through a hosting partner is resold capacity from a platform two steps removed, and the escalation path runs through two service desks before it reaches an engineer with policy access. Ask whose network, whose scrubbing centres, which regions, and who answers the phone. Get the answer in writing, with names or at least role-based rotas.

Judge providers on evidence, not capacity slides

Aggregate terabits of global capacity tells you little about what is available in the London or Amsterdam scrubbing centre on the day. Press instead on: time-to-mitigate wording in the SLA and what the remedy actually is; whether the SLA covers detection, mitigation or both; the quality of post-attack reports, including vector breakdown, packets and requests per second, sources and mitigation timeline, because that document is what your auditors and any police report will rely on. Ask for a redacted real report before you sign.

Buying routes and the business case

Crown Commercial Service frameworks are the usual route (check which iteration is live when you buy), and multi-supplier estates need one owner of the protection standard across all hostnames rather than each supplier doing its own thing. Build the case from the cost of a day offline: staff time diverted to phones and reception, missed statutory deadlines, delayed payments, member and press handling. Headline capacity numbers make a weak business case; a statutory consultation closing at midnight makes a strong one.

Always-on or on-demand when your service has statutory deadlines

Detection-and-divert means an attack has to be spotted, a route or DNS change made, and traffic drawn into the scrubbing centre before mitigation begins. Against a fifteen minute hacktivist burst, that sequence can complete just as the attack stops. You mitigated nothing and the screenshot already exists. For the citizen-facing hostname, always-on cover is the pragmatic choice even on a tight budget; the wider trade-offs are set out in our comparison of always-on and on-demand protection.

Calendar risk usually settles the argument. The 31 January self-assessment deadline, pre-election periods, GCSE and A-level results days, grant application windows and consultation closing dates are all dates where a thirty minute outage carries legal and reputational weight rather than just annoyance. A hybrid is common and defensible: always-on for the portal and transactional hostnames, on-demand for wider address space and internal ranges where a few minutes of diversion time is tolerable.

Then verify the promise. Run an onboarding test with the provider, agree reporting cadence in peacetime, and ask for evidence of past mitigations at comparable size. A provider who cannot show you a real timeline from a real event is selling you a diagram.

The first hour

Run a fixed sequence rather than improvising: confirm scope (one hostname or the whole estate), check DNS resolution, check reachability to origin and edge, check application behaviour and error mix, then declare and escalate to the named contact. Publish your status update somewhere that does not depend on the failing infrastructure, because a holding page served from the same name servers or the same origin is no use at all. Social channels, a separately hosted status domain and the phone lines all need to be pre-agreed, not improvised while the homepage times out.

Capture evidence as you go: timestamps in UTC, packet or request samples, firewall and proxy logs, mitigation logs and the provider’s attack report. Denial of service is an offence under section 3 of the Computer Misuse Act 1990, with a statutory maximum of up to 10 years, and the National Crime Agency’s position is that using booter or stresser services is itself an offence. Report through Action Fraud, and via your NCSC reporting route as a public sector body; our UK playbook on legal action after an attack sets out what evidence keeps options open. For dated context on how the incident mix shifted, analysis of incidents reported to the ICO and the FCA put denial of service at around a quarter of reported hacking incidents in the first half of 2022, against 4% the year before; the figure is old now, but the direction of travel it showed has not reversed.

Finish with a review that changes something. Re-audit origin exposure, name the owner of every zone and every hostname, close the contract gaps you found at 02:00, and write the triage sequence into the runbook with the escalation numbers on the front page. DDoS attacks on government websites succeed because these small things stay undone between incidents, not because the attackers are formidable. Fix the leaked records, put a second name server provider in place, protect the expensive endpoints, and make sure someone is genuinely on the hook to act before the next target list appears.

Frequently Asked Questions

Why are government websites such frequent DDoS targets?

Because they are symbolic, easy to name and produce disproportionate publicity for a small amount of traffic. Hacktivist groups aligned with geopolitical causes pick targets that make a recognisable screenshot, and a council or department homepage does that better than an anonymous corporate site. The NCSC’s March 2024 guidance, issued after denial of service attacks on UK political party websites, reflects that pattern.

Are DDoS attacks on government websites a data breach?

A denial of service attack disrupts availability; it does not in itself give the attacker access to data. It can still be a reportable security incident, and availability is part of data protection obligations, so take advice on your specific circumstances. Describing an availability attack as a data breach in public creates problems you then have to correct.

Is a DDoS attack illegal in the UK, and who should it be reported to?

Yes. Section 3 of the Computer Misuse Act 1990 covers unauthorised acts that impair the operation of a computer, carrying a statutory maximum of up to 10 years, and the National Crime Agency treats the use of booter and stresser services as an offence in itself. Report to Action Fraud, and public sector bodies should also use their NCSC incident reporting route.

How much does protection for a public sector website cost?

There is no meaningful single figure, and anyone quoting one without asking questions is guessing. Price is driven by the number of protected hostnames, whether authoritative DNS is included, clean traffic volumes, overage rates per Gbps or per million requests, and above all whether managed escalation is real or nominal. Ask for the overage terms and the out-of-hours escalation commitment in writing, because those are where the surprises live.

Does a CDN or reverse proxy alone stop attacks on a council website?

Only if the origin is genuinely hidden and every hostname you own sits behind it. Legacy mail records, staging subdomains and old A records routinely expose the origin address, at which point the proxy is bypassed entirely. Pair the proxy with an origin firewall limited to the provider’s prefixes, and audit your zones for records that resolve straight to the server.

Should a government service use always-on or on-demand mitigation?

For citizen-facing and transactional hostnames, always-on is the safer choice, because hacktivist bursts of five to twenty minutes can finish before a detect-and-divert model has finished rerouting traffic. On-demand remains reasonable for wider address space and internal ranges. If you have statutory deadlines or election periods in your calendar, weight the decision towards always-on for the services that carry them.

Hacktivist DDOS Attack Motives: What They Predict

Hacktivist DDoS attack motives are listed in almost every security blog going: geopolitics, protest, revenge, clout within a channel. What almost none of them do is join the motive to the attack you actually receive at 09:00 on a Tuesday. That link matters, because motive is a forecasting tool. Once you accept that the attacker’s success metric is coverage rather than your revenue loss, the shape of the incident becomes predictable, and so does the list of surfaces that will fail first.

This piece is written for the people who sign the protection contract and run the incident bridge, not for policy analysts trying to map the ideology.

What actually drives hacktivist DDoS attack motives

Four drivers cover most of what UK organisations see. Political or geopolitical grievance, usually tied to a conflict, a sanctions decision or a government position. Protest against a named policy, planning decision or contract award. Retaliation for something a named executive or organisation said in public. And status, which is the one defenders underrate: in a coordinating channel with a few thousand subscribers, posting a screenshot of a downed council homepage earns reputation in a way that a quiet, damaging intrusion never will.

Attention is the objective. Not extortion, not competitive harm, not data. The campaign is built so that a claim can be posted, reposted and, ideally, picked up by a journalist who does not check it. That single fact explains the duration, the target list and the vectors.

Where the lines blur

Three complications are worth stating plainly. State-aligned groups adopt hacktivist branding because deniability is cheap and the aesthetic is established. Criminal crews borrow political language to muddy attribution or to recruit. And ransom demands now appear mid-campaign, sometimes days after a political claim, from the same or an adjacent account.

If you are working out what to do about a ransom DDoS attack, the technical response does not change: you mitigate, you do not pay, and you preserve evidence. The legal and reporting picture does change, because an extortion demand brings a different set of obligations and a different conversation with your insurer and your board. Treat every motive claim as unverified attribution, including the political ones. The group claiming your outage may not have caused it, and the group that caused it may not be the one you think.

Competitive sabotage and gaming disputes behave differently. Those attackers want an effect and do not want an audience, so they are quieter, more patient and more willing to run for hours. A hacktivist campaign that runs for six hours is unusual. A gaming grudge that runs for six hours is Tuesday.

How motive shapes the attack you actually see

Attention-driven campaigns are short and rhythmic. They cluster around a fixed point in time: a parliamentary vote, a court date, a contract announcement, a sanctions package, the anniversary of something. Waves of ten to thirty minutes, repeated, are far more common than sustained pressure, because a burst is enough to generate a screenshot from a public reachability checker and a burst costs less booter credit.

The toolkit is unglamorous. Rented booter and stresser capacity, reflection and amplification floods against the network edge, and plain HTTP GET floods pointed at whatever endpoint is most expensive to serve. Site search is the perennial favourite, followed by login pages and any URL with a query string that defeats the cache. The volunteer-tool era of Operation Payback, with participants running LOIC and HOIC from their own machines, has largely given way to rented botnet and stresser capacity coordinated through chat channels, which is why a handful of organisers can now generate more traffic than a few thousand volunteers once did.

Target selection follows the same logic as everything else. Homepages, public-facing portals, authoritative nameservers, anything with an address a reader will recognise. Not the claims processing system. Not the back-office integration that would genuinely hurt if it stopped.

Plenty of claimed campaigns sit well under 10 Gbps and well under an hour. That sounds survivable, and against a properly protected estate it is. The FBI’s Internet Crime Complaint Center made the point in a public notice on 4 November 2022, observing that hacktivist DDoS activity against critical infrastructure had produced limited operational impact while generating publicity out of proportion to the damage. The gap between impact and publicity is the thing to plan around. It is also why a modest flood still takes sites down: one unprotected surface is all the campaign needs, and modest is more than enough to saturate a registrar’s nameservers or a single origin VM.

Who gets picked, and why symbolism beats value

The recurring sectors will not surprise anyone: DDoS attacks on government websites and local council portals, NHS trusts and healthcare providers, airports and airlines, law firms acting on contested matters, broadcasters and news sites. High recognisability, public-facing, and easy to describe in a one-line post.

Collateral exposure is where organisations get caught out. Your payment page, your booking engine, your DNS provider and your CDN-hosted assets carry your brand and your reputation, but not necessarily your controls. When a third-party checkout goes dark, the screenshot still has your logo on it.

Supplier exposure works the same way. Organisations get targeted for a client they act for, a contract they won or a position their parent company took, rather than anything they did themselves. The attempted attacks on the Vatican’s website are a useful illustration of the pattern: a symbolic institution picked for what it represents, an attack claimed loudly, and an outcome rather less dramatic than the claim. Once a name appears on a circulated target list, unrelated participants join in simply because the list exists. Removal from the list is not a thing you can request.

Verifying a claim of responsibility against your own evidence

Here is the part no one else covers, and it is the defence that most often decides how the incident is reported. Hacktivist campaigns are optimised for narrative. If you cannot produce request rates, regional reachability and edge logs for the claimed window, a fifteen-minute partial slowdown gets written up as a day-long outage, and you are arguing from the back foot with your regulator, your insurer and the trade press.

Check three surfaces, in order:

Authoritative DNS. Query your nameservers directly from multiple regions. If resolution failed, nothing downstream matters, and the web tier logs will look misleadingly quiet.
Network and transport. Interface counters, upstream flow data, any scrubbing provider’s traffic graph for the window. Look for volume and for the vector mix.
Application layer. Requests per second per endpoint, cache hit ratio, origin response times, 5xx rates. A GET flood on search shows up as a single endpoint carrying a request rate it has never carried before.

Then separate real impact from a reposted screenshot. Public checker tools report from one vantage point and cache aggressively; a red tick on such a site is not evidence of an outage. Synthetic monitoring from several regions, plus your own edge logs, is. Our 10-minute triage for telling a DDoS from an ordinary outage covers the sequence in more detail, and it is worth rehearsing before you need it.

Capture the evidence in the first hours, not the following week: precise timestamps in UTC with your local offset, vector breakdown, source ASNs and country spread, packet and request rates, the mitigation actions taken and when, and screenshots of the claiming post with its own timestamp. Insurers ask for it. Regulators ask for it. Any realistic legal route depends on it.

Ask your provider for a post-attack report and check the contract says what it must contain. Per-vector and per-ASN detail, start and end times, peak and sustained rates, and which rules fired. Where a reseller sits between you and the scrubbing network, that report often arrives late and thin, because the reseller is asking someone else for it too.

The defences that hold against attention-driven attacks

Burst-shaped protest traffic and on-demand mitigation are a poor fit. Detection, human decision, BGP announcement and route convergence all stack up, and a campaign built around a twenty-minute window can finish, be claimed and be screenshotted before your traffic ever reaches a scrubbing centre. Always-on for the symbolic hostnames, on-demand for the rest, is usually the honest compromise; the trade-offs in cost and latency are set out in our comparison of always-on versus on-demand DDoS protection.

Volume is rarely the reason a symbolic target falls over. Origin IP leakage is. Stale A records on a decommissioned subdomain, a mail or staging host on the same range, an origin address sitting in certificate transparency history from a certificate issued three years ago. A 5 Gbps direct-to-origin flood beats a proxy that was never bypassed at all. Audit your own DNS zone and CT logs before an attacker does, and lock the origin to accept traffic only from your provider’s ranges.

Authoritative DNS is the layer most often left unmanaged on exactly the sites hacktivists pick. Councils, small agencies and campaign microsites routinely run registrar-bundled nameservers with no anycast spread and no mitigation, so the nameservers fall before the web tier is even touched. Closing that gap is cheap relative to everything else you will spend, and our guide to DNS DDoS attack protection and the gaps most estates leave open lists what to check.

At the application layer, three controls do most of the work against protest traffic: rate limits on search and login with a sensible response for exceeded limits, full-page caching of the homepage and other high-traffic public pages so the origin is not touched, and a static fallback page hosted somewhere completely separate from your main infrastructure.

Finally, the contract. Managed should mean pre-attack tuning against your real traffic baseline, named escalation contacts on both sides, explicit authority for the provider to change policy without waiting for your sign-off, and a defined report. If nobody on the provider’s side can act at 03:00 without waking your CTO, you have bought monitoring, not management.

Preparing before your organisation becomes a symbol

Motive is predictive, so watch the triggers. Contract awards, public statements by executives, sanctions news touching your sector, court dates, planning votes, and sector-wide campaigns announced days in advance in open channels. A contested planning vote at 09:00 is a scheduled risk event, the same as a product launch.

Picture that council: an amplification flood against the network edge, an HTTP GET flood on the site search endpoint, and authoritative DNS sitting on registrar-bundled nameservers with no protection. The web tier might hold. The nameservers will not, and the outage will be total, which is the screenshot the campaign wanted.

Your comms plan should not feed the objective. Factual status updates on a status page hosted off your main infrastructure; no engagement with the claiming channel, no quoting it, no naming it; one named person who signs off wording; and an agreed line that describes impact and restoration without confirming attribution you have not verified. Resist the temptation to say “we repelled a major attack”if it was 4 Gbps for eleven minutes. Someone will check.

On the legal side, unauthorised acts impairing the operation of a computer are an offence under section 3 of the Computer Misuse Act 1990, as amended by the Police and Justice Act 2006. Report through Action Fraud, and use the National Cyber Security Centre reporting route where the incident is significant or touches critical services. Be realistic about prosecution: attribution across borders is hard and cases are slow, and what makes any outcome possible is the evidence you preserved in the first 24 hours. Our UK playbook for legal action after a DDoS attack sets out the sequence.

Keep the pre-attack checklist short enough that people actually do it: tested failover, a cached status page off your main infrastructure, a provider contact tree with out-of-hours numbers that someone has rung this quarter, and a rehearsed ten-minute triage. Read against the grain of the loud claims, hacktivist DDoS attack motives tell you to expect something short, noisy, symbolically aimed and technically ordinary, and to spend your money on the surfaces that fail quietly while everyone is watching the homepage.

Frequently Asked Questions

What motivates hacktivist DDoS attacks compared with criminal ones?

Hacktivists want attention: coverage, screenshots and status within a coordinating channel, usually tied to a political grievance, a policy, a contract or something someone said in public. Criminal attackers want money or a commercial effect, so they are quieter, more persistent and less interested in being seen. That difference shows up in duration, target choice and whether a claim is posted at all.

Are hacktivist DDoS attacks usually large, or is the volume overstated?

Claims are frequently overstated. Many campaigns run well under 10 Gbps and under an hour, and the FBI’s IC3 notice of 4 November 2022 observed that hacktivist DDoS activity against critical infrastructure produced limited operational impact while attracting outsized publicity. Small is still enough to take down unprotected authoritative DNS or a leaked origin address.

How can we tell whether a claimed attack actually affected our site?

Check authoritative DNS resolution, then network and transport counters, then per-endpoint request rates and error codes for the claimed window. Compare against multi-region synthetic monitoring rather than a public reachability checker, which reports from one vantage point. If your own telemetry shows no deviation, the claim is unsupported and you should say so with data rather than assertion.

Should we say anything publicly when a group claims an attack on us?

Publish factual status and restoration updates on a status page hosted separately from your main infrastructure, and say nothing that engages the claiming channel or amplifies its name. Do not confirm attribution you cannot verify. One named person should sign off all wording, and the line should describe user impact and timings, not adjectives.

Is launching a hacktivist DDoS attack illegal in the UK?

Yes. Deliberately impairing the operation of a computer without authorisation is an offence under section 3 of the Computer Misuse Act 1990, as amended by the Police and Justice Act 2006, and political motivation is not a defence. Participation using a booter service counts, as does supplying or operating one.

Does always-on protection make sense if attacks only last minutes?

For the hostnames most likely to be targeted, yes, precisely because they last minutes. On-demand diversion has to detect, decide, announce and converge, which can consume most of a twenty-minute burst. Running always-on for the symbolic public hostnames and on-demand for the wider estate is normally the sensible balance of cost and coverage.

DDoS Attack on an Airline: How Aviation Systems Fail and What Actually Protects Them

A distributed denial-of-service (DDoS) attack on an airline almost never looks like the film version. There is no cockpit, no radar screen, no dramatic countdown: there is a booking domain that stops resolving at 06:00 on a Friday in half-term, a mobile app stuck on the boarding pass screen, and a bag drop queue growing faster than the ground handler can clear it. The statement that follows will say flight operations and air traffic control were unaffected. That is usually true. It is also close to useless to the passenger in the queue and to the duty manager paying for the welfare costs.

This piece takes the airline apart into the internet-facing surfaces that actually fail during an attack, explains what mitigation genuinely covers each one, and sets out how to test a provider’s claims before peak season rather than during it.

What actually goes down when an airline is hit

The marketing site is not the system that matters

A mid-sized carrier’s internet-facing estate is a longer list than most board packs assume: the marketing site; the booking engine and fare search; check-in and boarding-pass APIs; the mobile app back end; self-service kiosk endpoints in the terminal; ground-handler and crew portals; the loyalty programme; payment gateway callbacks; and authoritative DNS for the primary booking domain. Each has a different traffic profile, a different owner and, usually, a different level of protection.

Attackers do not need to touch reservation host connectivity or departure control to cause a bad morning. Flooding the check-in API is enough. The kiosks in the terminal are, in most estates, HTTPS clients talking to the same endpoints as the app, so when those endpoints saturate, the kiosks fail alongside the phones.

Why “no impact on flight operations”can be true and unhelpful

The dividing line is simple. Safety-critical avionics, air traffic management and the systems the regulator cares about most sit on separate networks with their own connectivity and their own assurance regime. The passenger-facing estate is ordinary internet infrastructure with ordinary internet weaknesses: public IP ranges, DNS, TLS, cloud load balancers, third-party JavaScript. A carrier can say with complete honesty that no aircraft was affected while every passenger channel is unusable.

Communications teams that lean too hard on the first half of that sentence tend to get punished for it later, because the queue is visible on social media within minutes.

The operational bill after the traffic stops

Manual check-in at the desk is slower than the kiosk by a wide margin, and staffing is set months in advance. A morning of degraded check-in produces missed slots, misconnects, rebooking backlogs, contact-centre queues that persist for days, and welfare costs for passengers stranded at the airport. Under retained UK air passenger rights rules (Regulation (EC) No 261/2004 as retained in UK law), duties of care and rebooking apply where flights are delayed or cancelled regardless of what caused the disruption; whether cash compensation is also payable turns on the contested question of whether a cyber attack counts as an extraordinary circumstance. That is a legal argument you would rather not be having.

Attackers pick the calendar, not just the target

Short, repeated bursts timed to a bank holiday getaway, a half-term Friday, a strike day or a political flashpoint do more damage per gigabit than a sustained flood on a quiet Tuesday. European carriers including Lufthansa and Scandinavian Airlines have had public-facing services disrupted by campaigns claimed by hacktivist groups on Telegram, typically announced alongside a political grievance and typically in bursts rather than one long wave. The pattern matters for defence: on-demand mitigation that takes several minutes to engage will keep missing an attack that only lasts fifteen.

Why airlines attract DDoS attacks in the first place

Hacktivist DDoS attack motives: the carrier as a stand-in for the state

Flag-of-convenience targeting is the dominant pattern. A group with a grievance against a government cannot reach the government’s hardened estate, so it hits the most recognisable commercial entity carrying the flag. National carriers, airports and rail operators are chosen because the outage is visible, photographable and reported within the hour. Attribution claims made on Telegram should be treated as claims, not facts; groups routinely take credit for outages they did not cause, and for outages that were never attacks at all. Airlines have been dealing with attention from this direction for years, and some carriers have publicly invested in defences specifically to blunt it.

Extortion, and why paying rarely ends the pressure

Ransom DDoS notes are usually timed to a peak booking window: a fare sale, the January holiday rush, the run-up to a bank holiday. The note arrives with a short demonstration attack and a deadline. If you are asking what to do when a ransom DDoS demand lands, the practical answer is a sequence, not a decision: do not reply; preserve the message headers and any demonstration attack telemetry; escalate to your mitigation provider immediately so posture can be raised before the deadline; inform your legal and communications leads; and report it. Payment funds the next campaign, marks you as a payer, and buys no enforceable commitment from an anonymous counterparty. Extortion crews are occasionally caught and prosecuted, as earlier cases against Russian DDoS blackmailers showed, but not on a timescale that helps you this week.

In the UK, section 3 of the Computer Misuse Act 1990 covers unauthorised acts intended to impair the operation of a computer, carrying a maximum sentence of ten years on indictment. Reporting routes run through Action Fraud (or Police Scotland in Scotland) and the National Cyber Security Centre. Air transport operators should also check their notification duties under the Network and Information Systems Regulations 2018, where the Civil Aviation Authority is the competent authority for the sector; confirm current thresholds and timescales with the CAA rather than relying on institutional memory.

Cheap capacity and cover noise

Booter and stresser services have made short bursts a commodity purchase, and reflected amplification plus large compromised device populations mean a low-budget attacker can still generate serious volume; the days when botnets of that scale were remarkable are behind us. The second use case is quieter: a loud layer 3 flood occupies the security operations centre and the network team while credential stuffing runs against the loyalty programme or a supplier account is abused elsewhere. Treat a volumetric event as a possible distraction and keep someone watching authentication logs.

The three surfaces an airline protects unevenly

Network and transport

Volumetric floods against the autonomous system, the data centre edge and any self-hosted range are the best-understood problem and generally the best-covered. Upstream scrubbing, BGP diversion and blackholing all exist for it. The gap is usually scope: subsidiaries, regional franchise partners and legacy ranges left in an old colocation facility often sit outside the contract.

Application layer

Layer 7 is where airlines are structurally exposed, because fare search is expensive. A single availability query can fan out to a pricing engine, cache lookups and, in some architectures, a live call to a global distribution system. A few thousand requests per second against fare search costs an attacker almost nothing and costs the origin a great deal. Seat maps, loyalty login and the booking basket behave the same way. Static content, by contrast, is nearly free to serve.

Airline traffic is also genuinely spiky. A fare sale, a snow day or a strike announcement produces surges that look exactly like a request flood. Thresholds tuned to average load will either throttle paying customers during a promotion or miss a slow, low-rate flood on fare search. Per-endpoint tuning is the answer: aggressive limits and bot challenges on the expensive endpoints, generous handling of static assets, and rules that account for the app’s normal burst behaviour after a disruption push notification.

Authoritative DNS

This is the layer most commonly left outside the managed scope, and the one that takes down every channel at once. If authoritative DNS for the booking domain stops answering, the website, the mobile app, the kiosks, the ground-handler portal and any partner integration resolving that hostname fail together, and no amount of edge bandwidth in front of the web tier helps. Serious DNS DDoS attack protection means anycast authoritative service across two independent providers on separate infrastructure, zone data kept in sync, TTLs agreed in advance (short enough to fail over usefully, long enough that resolvers keep serving during an outage), and a rehearsed procedure for changing delegation under pressure. For most carriers that buys more resilience than another tier of scrubbing capacity.

The third parties in the chain

Your booking flow depends on things you do not own: GDS connectivity, payment service providers, ancillary retail platforms, identity providers, and the airport operator’s own systems for kiosks and bag drop. Ask each of them the same questions you ask your own team, and record which of them can take your check-in flow down without anyone attacking you at all.

Why the proxy did not save the booking engine

Origin IP leakage, not attack volume

When a proxied booking engine falls over, the cause is more often exposure than size. The usual suspects: an old A record for a staging booking engine still pointing at production infrastructure; an SMTP or webmail host in the same /24 as the origin; a certificate transparency log entry publishing an internal hostname that resolves straight through; a historical DNS record archived by passive DNS services years ago. Fix the leak and enforce an origin firewall allowlist that accepts traffic only from your mitigation provider’s published ranges. Then test the allowlist from an arbitrary external host, because plenty of them are configured and never enforced.

APIs routed around the edge for latency

Mobile and API traffic is frequently taken off the proxy deliberately, to shave latency off check-in calls or because the SDK does not tolerate the edge’s TLS behaviour. That decision is often made by an app team, documented nowhere, and discovered during an attack when api.example.com is flooded directly while www.example.com stays comfortably up. Inventory every hostname the app resolves, including the ones used only for feature flags, crash reporting and payments.

Deployment models and mitigation timing across an airline estate

Three models cover most estates: reverse proxy for web and API surfaces, where layer 7 inspection and per-endpoint policy live; BGP-based scrubbing for whole prefixes, which protects everything in the range including non-HTTP services; and hosting-level filtering, which is often the realistic option for a smaller regional carrier or a subsidiary running one booking site.

Always-on versus on-demand

On-demand diversion is cheaper and keeps normal traffic off the scrubbing path, but the first minutes are exactly the ones that matter during a 06:00 check-in peak, and detection thresholds plus BGP convergence mean an on-demand posture will surrender the opening of every burst. The defensible split for an airline is always-on protection for the booking, check-in and DNS path, with on-demand diversion held in reserve for less critical prefixes. Get the SLA to state whether time-to-mitigate is measured from detection or from your phone call, because the two numbers can differ by half an hour.

Whose network have you actually bought?

Many buyers cannot name the network their traffic is scrubbed on, because the contract is with a reseller or an integrator. Ask for the underlying provider, the scrubbing locations that will serve your UK and European traffic specifically, and how advertised capacity is measured. The market has consolidated steadily since deals such as Akamai’s acquisition of Prolexic, and a cloud DDoS scrubbing service sold under three different brands may all terminate in the same handful of facilities. That is not automatically a problem. Not knowing is.

The 05:30 Friday runbook

Write the runbook for the worst realistic hour, not for office hours. Name the person authorised to trigger diversion or change DNS without waiting for a change advisory board. Record the provider’s out-of-hours escalation number and the account credentials needed to raise it. Decide in advance how ground operations is told, what the desk agents are instructed to say, and which fallback the airports switch to. Rehearse the DNS provider failure separately, because it is the scenario where your usual comms channels (the website, the app status page) may also be gone.

Buying and proving protection before peak season

What “managed”should buy

Managed should mean onboarding and per-endpoint rule tuning, always-on baselining of your traffic including its seasonal shape, named escalation contacts on both sides, and an engineer empowered to change policy at 03:00 without your sign-off. If every mitigation change waits on a ticket you have to raise, you have bought monitoring, not management. Our own guide to choosing a managed DDoS protection provider in the UK covers the contract mechanics and cost ranges in more detail; the aviation-specific addition is that your tuning must survive a fare sale.

Evidence over sales decks

Ask for a redacted post-attack report from a comparable customer and read it for vector breakdown, timestamps, mitigation actions taken and residual leakage, not for the headline peak figure. Ask how capacity is measured and where. Then, after your first real event, check the report against the SLA definitions you signed. Providers that write good reports tend to run good operations.

The business case, priced properly

Model downtime cost per hour against each surface rather than against “the website”: lost online bookings and ancillary revenue; contact-centre surge and overtime; desk staffing for manual check-in; welfare, rebooking and potential compensation exposure under the retained UK261 rules; and the cost of the recovery days that follow. Present the DNS single point of failure separately, because it is the cheapest of the risks to fix and the most expensive to ignore.

A pre-peak test checklist

Search historical and passive DNS records, certificate transparency logs and mail records for anything that exposes an origin IP address; retire what you find.
Confirm the origin firewall accepts traffic only from your mitigation provider’s ranges, and prove it by connecting from outside them.
Verify that both authoritative DNS providers answer for the zone, that records match, and that TTLs are set where your failover plan assumes they are.
Enumerate every hostname the mobile app and the kiosks resolve, and confirm which are behind the edge.
Run a tabletop where the attack lands at 05:30 on a Friday in half-term, with the DNS provider unreachable and the on-call network lead unavailable.

A DDoS attack on an airline is not an unforeseeable lightning bolt from the blue. It is a predictable consequence of running a highly visible, latency-sensitive, seasonally spiky passenger estate on the public internet, and the carriers that come through one well are the ones that mapped every surface, closed the origin leaks and tested the DNS failover in March rather than in August.

Frequently Asked Questions

Can a DDoS attack on an airline affect flight safety or air traffic control?

Safety-critical avionics and air traffic management run on separate, dedicated networks that are not exposed to public internet traffic in the way a booking site is, so a flood aimed at passenger channels does not reach them. What it does reach is check-in, bag drop, kiosks and rebooking, which can ground a schedule through operational congestion rather than through any safety system failure. Both statements can be true at the same time.

Why do hacktivist groups target airlines with DDoS attacks?

Visibility. A national carrier is a recognisable stand-in for the government whose flag it carries, and an outage during a getaway weekend produces photographs of queues within the hour. Campaigns claimed by hacktivist groups on Telegram against European carriers, including Lufthansa and Scandinavian Airlines, have followed political events. Claims of responsibility should be treated as unverified until the telemetry supports them.

How long does an airline website usually stay down during a DDoS attack?

There is no reliable average, and any vendor quoting one should be asked for the dataset. The pattern seen in hacktivist campaigns tends towards repeated short bursts over hours or a day rather than one continuous outage, which is why time-to-mitigate matters more than total capacity. Recovery of the passenger experience takes longer than recovery of the website, because the rebooking and contact-centre backlog persists after traffic normalises.

What should an airline do if it receives a ransom DDoS demand before a bank holiday?

Do not respond to the sender, preserve the note and any telemetry from the demonstration attack, and tell your mitigation provider immediately so posture can be raised before the stated deadline. Brief legal, communications and ground operations, and report through Action Fraud (or Police Scotland) and the NCSC, checking any sector notification duties with the CAA. Paying identifies you as a payer and secures nothing enforceable.

Does a reverse proxy protect an airline’s mobile app and booking APIs as well as its website?

Only if those hostnames actually route through it, and frequently they do not, because API traffic gets taken off the edge for latency or SDK compatibility reasons. Check every hostname the app and kiosks resolve, including payments, crash reporting and feature flags, and confirm the origin firewall rejects anything not arriving from the provider’s ranges. A proxy in front of www while api answers directly is a gap, not a defence.