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.