Tag Archives: ransom ddos attack what to do

Law Firm Cyber Attack Protection: Beyond Phishing

Law Firm Cyber Attack Protection: Beyond Phishing

Law firm cyber attack protection, as it is sold and as it is bought, nearly always means email: a filtering gateway, phishing simulations twice a year, a mandate fraud warning on the completion statement, and a cyber policy with a conveyancing fraud sub-limit. That half of the problem has had a decade of attention, and most UK firms have genuinely improved. The other half has had almost none. Nobody at renewal asks what happens when the client portal, the document exchange and the firm’s authoritative DNS all stop answering at three o’clock on a Friday afternoon.

That is the gap this piece is about: availability, how it fails, and how to buy and verify protection for it without taking a vendor’s word for anything.

What attackers actually target in a law firm, and the half nobody covers

The confidentiality attacks are familiar. Business email compromise, invoice and mandate redirection on completion funds, credential theft against Microsoft 365, ransomware that encrypts a file share and the backups sitting on the same domain. Firms have bought tooling and training against all of it, and insurers have pushed hard in the same direction.

Availability attacks sit outside that conversation entirely. They include volumetric floods against the public website; request-level attacks aimed at the login flow and search function of a client portal or document exchange; attacks on the authoritative nameservers that publish every hostname the firm uses; and extortion emails demanding payment in cryptocurrency to stop, sometimes preceded by a short demonstration burst against the marketing site.

Legal is an attractive target for both motives, and for different reasons. Work is deadline-bound, so an outage has a hard commercial edge that an attacker can time. Clients in litigation and corporate transactions are acutely sensitive to any sign that the firm is unstable. And high-value matters are often publicly visible, from planning objections to M&A announcements, which gives an aggrieved party a clear target and a clear window. One UK practice found its systems disrupted badly enough by a flood of inbound mail that it rebuilt its web security afterwards, which is a reminder that the trigger is not always sophisticated and rarely announces itself in advance.

Mapping your own exposure in an afternoon

Before anyone looks at a quote, build four columns. Every client-facing hostname the firm owns, including the ones marketing created and forgot; who hosts each one; who runs the DNS for the zone; and the name and mobile number of the person you would ring about it at two in the morning. Most firms cannot complete column four for at least one row. That blank is the finding.

The three surfaces law firm cyber attack protection has to cover

Network and transport floods

These are the attacks discussed in gigabits per second, occasionally terabits. A decent hosting provider or ISP absorbs the small end without telling you. What they will not do is carry a sustained attack aimed at your single public IP address, because at a certain point the economically rational move is to null-route you to protect everyone else on that segment. Blackholing is not mitigation. It is the provider agreeing with the attacker.

Application-layer attacks

This is where portals actually fall over. A few thousand well-chosen requests per second against a document search, a login endpoint that does a bcrypt hash on every attempt, or a matter-lookup page that runs an unindexed query, will exhaust the database long before anything registers on a bandwidth graph. Protection sized purely on gigabits of clean traffic will sail through a volumetric flood and still let the conveyancing portal die quietly. Understanding the gaps in application-layer defences matters more for a law firm than headline scrubbing capacity, because the valuable systems are all request-driven.

Authoritative DNS, the layer nobody has reviewed

Ask who controls the firm’s nameservers. In a worrying number of practices the answer is a web agency’s registrar account, sometimes a former IT supplier’s, on a single DNS provider, with no secondary nameservers and no monitoring. Lose that and nothing else in the stack matters: the portal, webmail, the marketing site and any MX-dependent mail flow all stop resolving at the same moment, and the shiny proxy in front of the website never sees a packet. Redundancy here is cheap and badly under-bought; a second authoritative DNS provider is usually the highest-value hour of work available to a firm this week.

Third-party dependencies you do not control

Practice management SaaS, e-signature platforms, hosted document portals and card payment pages all inherit someone else’s protection posture. Your Lexcel file says you have business continuity; your supplier’s contract may say they will use reasonable endeavours. Those are not the same sentence. Put the question in writing to each supplier at renewal and keep the answer.

Why the proxy gets bypassed: origin IP leakage, not attack size

When a protected site goes down, the cause is far more often that the attacker found the origin than that they out-muscled the scrubbing network. The firm’s real server address leaks through routes nobody audits: the MX record, SPF entries listing the mail server, historical DNS records archived by passive DNS services, TLS certificate transparency logs that publish every hostname you have ever certificated, a webmail or VPN endpoint sitting on the same /24 as the web server, or a staging site at new.firmname.co.uk that resolves straight to the origin and has done since 2021.

The test is one question, and it is a yes or no. Does the origin accept TCP connections on 80 and 443 from anything other than the protection provider’s published IP ranges? If yes, the protection in front of the site is decorative. Three fixes, in order: allow-list the provider’s ranges at the host firewall or security group and drop everything else; validate the host header and a shared secret header at the web server so direct hits are rejected; and rotate the origin IP address after onboarding, because the old one is already in a passive DNS database somewhere.

Attack volume is the part vendors like to talk about. Reachability is the part that decides the outcome.

Extortion and the first hour

Triage before escalation

Not every Friday outage is an attack. A bad deployment, an expired certificate, a hosting provider’s own incident and a legitimate traffic spike from a press mention all look identical from reception. Check from outside the network, not from a machine on the office LAN; compare the web server’s request logs against the load balancer’s; look at whether the source addresses are geographically scattered and hitting one expensive URL repeatedly. Having a short, written routine to tell a DDoS from an ordinary outage saves the twenty minutes that usually get burned arguing.

If a ransom demand arrives

Paying achieves nothing reliable. Payment marks the firm as responsive to pressure, and the group that sent the email may not be the group capable of stopping the traffic. Preserve instead: the email with full headers, the exact timestamps of the first and peak traffic, sample requests and source data from the logs, and the provider’s post-attack report with its vector breakdown. That evidence is what makes any later legal or law enforcement route viable rather than theoretical.

Reporting duties

Four obligations sit in different places and a firm should know which apply before the day arrives:

  • The SRA Standards and Regulations require prompt reporting of serious breaches of the regulatory arrangements, which can include an incident that materially affects the firm’s ability to act for clients;
  • UK GDPR requires notification to the Information Commissioner’s Office within 72 hours of becoming aware of a personal data breach where there is a risk to people’s rights and freedoms, and the ICO is explicit that a loss of availability counts as a breach, not just unauthorised disclosure;
  • Clients on live matters need telling, in plain terms, where a deadline or completion is affected, and that message is better coming from the partner than from an estate agent;
  • Action Fraud takes the crime report, and the National Cyber Security Centre should be notified where the incident is significant.

Denial of service is a criminal offence in the UK under section 3 of the Computer Misuse Act 1990, which covers unauthorised acts intended to impair the operation of a computer. Useful to know, and worth stating to staff who assume this is a grey area. Realistically it does not shorten your outage by a second, and attribution is slow, so treat the criminal route as evidence preservation rather than recovery.

Buying protection: deployment models, managed meaning, and the cost case

Three models, and the choice is mostly determined by what the firm owns. Reverse proxy suits the common case: one marketing site, a client portal, a document exchange, all behind DNS you can repoint, with no IP space of your own. BGP scrubbing is for firms announcing their own prefix, typically those running an on-premises data room or legacy case system, and it protects everything in the range including mail and VPN. Hosting-level filtering is the cheapest and the weakest; it tends to stop at the volumetric tier and leaves the application layer to you.

On always-on versus on-demand: on-demand diversion is cheaper and adds a detection window plus a BGP announcement and propagation window before mitigation begins. For a firm whose work turns on 16:00 filing cut-offs and completion days, those minutes are a commercial decision, not a technical footnote. Decide now who is authorised to trigger a diversion at 23:00 on a Sunday without a partner’s sign-off, and write the name in the runbook.

What “managed”has to mean in the contract

Managed is a word, not a service level. The dividing line is simple. If a human on the provider’s side is not empowered to change a rate limit or a WAF rule at 16:40 on a Friday while the conveyancing portal is being hammered, without waiting for someone at the firm to raise a ticket, you have bought monitoring, not management. Get four things in writing: the onboarding and rule tuning done before the first attack rather than during it; named escalation contacts on both sides with out-of-hours numbers; explicit authority to change policy mid-incident; and a written post-attack report with timestamps, vectors and actions taken.

The business case, built from downtime rather than fear

Do the arithmetic openly. Take the fee earners who would be unable to work for an afternoon, multiply by the hours lost and by your own charge-out rates, and you have the cost of that single incident in lost recoverable time, before you count a missed completion, an abortive lender drawdown or the partner hours spent on client calls. Compare that number to an annual managed protection quote. Do not compare quotes to each other, which is how firms end up buying the cheapest version of the wrong thing. The structure of UK pricing varies by model, so check current figures with providers directly rather than relying on anything published months ago.

Judging providers on evidence rather than sales decks

Much of what is marketed in the UK as DDoS-protected hosting resells someone else’s scrubbing network. That is not disqualifying, but you need to know it. Ask whose capacity you are buying, which points of presence serve UK traffic (London is not a complete answer if the only nodes are in Frankfurt and Amsterdam), and who physically answers the phone at three in the morning, because that determines both the real capacity and who is accountable mid-incident.

Then press on the SLA. What does it pay out, what triggers it, how is time-to-mitigate measured, and who measures it? A service credit worth one month of fees against a lost afternoon of fee earner time is a gesture, not a remedy. And ask for a redacted report from a real incident. Report quality tells you more about the operations team than any capacity figure on a slide: whether they identified vectors, when a human intervened, and what they changed.

Run this short list alongside Cyber Essentials, Lexcel and the insurer’s questionnaire. Note that Cyber Essentials and Cyber Essentials Plus, for all their value, assess firewalls, secure configuration, access control, malware protection and update management. None of those five controls test whether your site stays reachable under attack. Availability is the box nobody ticks because nobody asks, which is precisely why it is still the weak point in most firms’ answers. Effective law firm cyber attack protection closes it by naming the surfaces, locking the origin, and putting a human with authority on the other end of the phone before the first demand email arrives. Background reading on how these attacks are structured and resourced is collected across DDoSInfo, and the case of the firm that hardened its web security after an attack is a reasonable place to start with partners who need convincing.

Frequently Asked Questions

What does law firm cyber attack protection need to cover beyond email security?

Availability of every client-facing system: the public website, client login portals, document exchange, and the authoritative DNS that publishes all of them. Email controls address confidentiality and fraud; they do nothing if the portal is unreachable on a completion day. Treat network floods, application-layer request attacks and DNS as three separate surfaces with separate owners.

Can a small law firm’s website really be taken offline by a DDoS attack?

Yes, and it rarely takes a large attack. A booter service costs very little and a few thousand requests per second aimed at a login page or document search can exhaust the database behind it. Smaller firms are often more exposed because their site and portal share one modest origin server with no filtering in front of it.

What should a firm do if it receives a ransom demand threatening to take its site down?

Do not pay and do not reply. Preserve the email with full headers, confirm whether an attack is actually in progress, notify your protection provider and hosting supplier, and report to Action Fraud and, if the incident is significant, the NCSC. Payment marks the firm as responsive to pressure and offers no reliable guarantee the traffic stops.

Does a law firm have to report a denial of service attack to the SRA or the ICO?

It depends on effect, not on the label. The SRA Standards and Regulations require prompt reporting of serious breaches, which can include an incident that materially affects the firm’s ability to act for clients. Separately, the ICO treats loss of availability of personal data as a personal data breach, so a 72-hour notification may be required where there is a risk to individuals. Take advice from the COLP rather than deciding on the day.

Is always-on or on-demand mitigation better for a firm with court filing deadlines?

Always-on, in most cases. On-demand diversion is cheaper but adds detection, announcement and propagation time before mitigation starts, and those minutes land badly against a filing cut-off or a lender’s close of business. If budget forces on-demand, agree the out-of-hours authorisation route in advance and name the person who can trigger it without a partner’s approval.

How much should a UK firm expect to spend on managed DDoS protection?

Pricing varies by model: reverse proxy plans are usually billed per protected hostname or per volume of clean traffic, while BGP scrubbing is priced against committed capacity and the size of the prefix. Get current quotes directly, since published figures date quickly. The useful comparison is not quote against quote but quote against your own downtime cost, calculated from fee earner hours lost in a single three-hour outage.



Hacktivist DDOS Attack Motives: What They Predict

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:

  1. Authoritative DNS. Query your nameservers directly from multiple regions. If resolution failed, nothing downstream matters, and the web tier logs will look misleadingly quiet.
  2. 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.
  3. 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.

Legal Action After a DDOS Attack: A UK Playbook

Legal Action After a DDOS Attack: A UK Playbook

When a flood of junk traffic takes a UK company offline for six hours on a trading day, the questions arrive in a familiar order: what is happening, when does it stop, who did this, and can we do anything about it afterwards. Legal action after a DDoS attack is usually the last of those to be asked and the first to be quietly dropped. Not because the attack was lawful. It plainly was not. The problem is that by the time anyone asks the question properly, the flow records that would have supported a claim have already rotated out of a buffer, and the only surviving artefact is a screenshot of a dashboard with no timezone on it.

This piece is written from the target’s side of the incident. It covers what UK law actually offers a victim, what to preserve in the first day, who to notify, how ransom demands change the calculation, and why the contract you signed with your mitigation provider usually determines your legal position far more than the Computer Misuse Act does.

What UK law says about a distributed denial-of-service (DDoS) attack on your business

Three provisions matter. Section 3 of the Computer Misuse Act 1990 covers unauthorised acts with intent to impair the operation of a computer, which is the standard charge for knocking a service offline; it carries up to 10 years’ imprisonment on indictment. Section 3A covers making, supplying or obtaining articles for use in such offences, and it is the provision that catches booter and stresser services and the people who buy them, with a maximum of two years. Section 3ZA, inserted by the Serious Crime Act 2015, covers unauthorised acts causing or creating a significant risk of serious damage, and carries up to 14 years, rising to life where the damage touches human welfare or national security.

So the sentencing range is real. What it is not is a remedy. A conviction, when one happens, arrives months or years later, usually against a teenager who bought 30 minutes of attack traffic for the price of a takeaway, and it returns nothing to your balance sheet. UK courts can make compensation orders, but they are limited by what the defendant can actually pay, and booter customers are rarely solvent.

Criminal offence, civil wrong, contract breach: pick your fight

These are three separate tracks and they behave differently. A criminal prosecution is brought by the state, needs a suspect, and is not yours to control. A civil claim is yours to bring, but you must identify a defendant, serve them and enforce against assets. A contract claim is against a party you already know, usually your hosting, content delivery or scrubbing provider, and it is governed entirely by the words in the agreement you signed. Most organisations that talk about “taking legal action”are describing track one and end up, if anything happens at all, on track three.

Attribution, not illegality, is the obstacle

Nobody disputes that flooding a UK business is unlawful. The difficulty is naming who did it to the civil standard. Reflection and amplification attacks arrive from thousands of innocent third-party servers whose owners have no idea they are participating. Source addresses are routinely spoofed. Attack capacity is rented from a marketplace that takes cryptocurrency and hides behind its own proxy layer. As we have noted before, websites have long struggled to find meaningful legal recourse for denial of service attacks, and the reason is almost always evidential rather than doctrinal.

The first 24 hours: the evidence that keeps your options open

Everything below needs preserving before the next log rotation, not after the post-mortem meeting.

  • NetFlow, sFlow or IPFIX records from your edge routers, exported and copied off the collector;
  • Edge and origin web server access logs, plus firewall, load balancer and WAF counters for the attack window and for a comparable quiet period;
  • Monitoring and synthetic check alerts, status page updates, and the timestamps on each;
  • A full packet capture sample if one was taken, even a few seconds of it;
  • Internal records of who was notified, at what time, on which channel, and what decisions they took.

Log everything in UTC from NTP-synchronised systems. Mismatched clocks are the first thing an opponent challenges, and a two-minute drift between your load balancer and your provider’s scrubbing centre is enough to muddy a time-to-mitigate argument permanently.

Ask for the written attack report, not a screenshot

The single most useful document you will ever hold after an incident is your provider’s post-incident attack report: named vectors, peak bit rate and peak packet rate, source distribution by geography and autonomous system, and precise start and stop timestamps. If your traffic passes through a third-party proxy or scrubbing centre, that provider holds the only complete record of the flood. Your own logs show the hole, not the thing that made it.

Yet a great many contracts never promise that report. Make it a named deliverable with a delivery deadline before you sign, not a favour you request in week three while the account manager is on leave. The same applies to raw evidence requests: ask during procurement whose scrubbing capacity you are actually buying, because plenty of UK offerings are resold capacity on another operator’s network. Where that is the case, your SLA counterparty may have to go and ask an upstream party that has no contract with you at all. That chain is worth mapping alongside the rest of your vendor claim checks.

Ransom notes are exhibits

Keep the original email with full headers. Keep the chat transcript, the wallet address, the sample attack timing and any subsequent messages. Do not forward the note around the business and delete the original, which is what happens roughly every time, because a forwarded copy strips the headers that make it worth anything.

Who to report a DDoS attack to in the UK, and in what order

Start with Action Fraud, the reporting centre for fraud and cybercrime in England, Wales and Northern Ireland; in Scotland, report to Police Scotland on 101. What you get back is a crime reference number, and its value is administrative rather than investigative: insurers ask for it, regulators expect it, and customers asking awkward questions are reassured by it. Feeding into the National Crime Agency’s picture matters too, even when nobody investigates your individual case, because the pattern data is what supports booter takedowns.

The NCSC’s denial of service guidance is the sensible reference point for building a defensible response plan, and pointing to it in a board paper is more persuasive than an internal opinion.

Then work through the duties that carry deadlines:

  • NIS Regulations 2018: operators of essential services and relevant digital service providers have incident notification duties to their competent authority, and availability incidents count;
  • FCA operational resilience expectations: financial firms are expected to report operational incidents and to be able to show whether an important business service breached its impact tolerance;
  • UK GDPR: Article 32 treats availability as part of security, so loss of access to personal data can be a personal data breach, and Article 33 gives you 72 hours from becoming aware to assess and, where there is a risk to individuals, notify the ICO. Document the assessment even when you conclude no notification is needed;
  • Contractual notice clauses: customer and partner agreements often require notification within a small number of days, and those clauses bite long before any regulator does.

Ransom DDoS attack: what to do before anyone discusses paying

The reflex payment is the worst available option. It buys no guarantee the traffic stops, it marks you as a payer, and extortion groups have a documented habit of returning to previously compliant targets with a larger number. Before any of that, there are UK legal problems sitting behind the transaction.

Payments to a sanctioned person or entity breach financial sanctions, which carry strict civil liability and can attract monetary penalties from the Office of Financial Sanctions Implementation. Any payment also needs assessing against the money laundering offences in the Proceeds of Crime Act 2002. Screening the recipient is not optional diligence; it is the thing that determines whether the payment is lawful. Note also that in July 2022 the NCSC and the Information Commissioner wrote jointly to the Law Society making clear that paying does not reduce the risk to individuals, is not required by data protection law, and will not be treated by the ICO as a mitigating factor. Separately, the Home Office consulted in early 2025 on restricting ransom payments by public sector and critical national infrastructure bodies; check the current legal position before relying on anything written here.

Practical sequence: notify your insurer and broker before acting, because most cyber policies condition cover on prior consent and on using panel responders. Then follow a decision chain you wrote in advance, naming a director who owns the call, the lawyer who signs it off and the law enforcement contact who is told. Writing that chain during an attack, at 02:00, with the phones ringing, is how organisations make decisions they later cannot defend.

Suing the attacker versus claiming against your provider

Civil claims against attackers work in a narrow band of cases: identifiable commercial booter operations with reachable assets, domains or payment processors. Ubisoft’s 2021 action against a stresser operation is the usual illustration, reported as producing an award of just over $153,000 alongside site takedowns. The useful lesson is not the sum. It is that the defendant was a business with a website and a payment flow, not an anonymous customer. Against individual botnet users overseas, the cost of identification, service and enforcement will exceed anything you recover.

Claims against your hosting, CDN or scrubbing provider look more promising and usually deliver less than expected. SLA credits are typically a percentage of one month’s fee, claimable only inside a notice window of around 30 days, and sit beneath a liability cap tied to annual charges, with consequential loss excluded outright. Downtime, lost sales and reputational harm are exactly what those exclusions remove. Credits and damages are different animals; treating a credit as compensation is a category error that has cost boards a lot of wasted legal spend.

Which leaves insurance doing most of the real work. Business interruption and cyber policies commonly apply a waiting period measured in hours, so a four-hour outage may recover nothing while an eleven-hour one recovers a great deal. Loss adjusters want a defensible figure: hourly revenue derived from comparable trading periods, staff time at loaded cost, recovery and third-party response fees, and contractual penalties triggered by the outage.

Why the contract you signed decides how strong your position is

Four clauses do most of the damage, and they are all checkable before you buy.

What “managed”actually includes. Managed should mean onboarding and rule tuning records, a named escalation path, an engineer empowered to change policy during an attack without waiting for your sign-off, and a committed written attack report. Absent those, you have bought monitoring, not management.

When the clock starts. On-demand cover almost always measures time-to-mitigate from your notification, which turns your own out-of-band notification trail into evidence: timestamped emails from a mailbox that is not on the affected domain, call logs, ticket IDs. Teams forget this while firefighting. If you are weighing always-on against on-demand cover, understand that the difference is partly evidential, and read the small print on what those SLA seconds measure.

Three surfaces, not one. Network and transport, application layer, and authoritative DNS. The third is frequently outside the DDoS contract entirely, which means an outage at that layer can fall into nobody’s SLA while still being the reason customers saw an error page. Establish who covers authoritative DNS, under what commitment, and what report you receive if it fails.

Origin IP leakage. This is the claim-killer. A stale A record on an old subdomain, a mail host sharing the origin address, a staging environment nobody decommissioned: any of these lets the flood reach your origin directly, outside the protected path. When that happens the provider will say so in writing, correctly, and the SLA never applied. Origin leakage, rather than raw attack volume, is the most common reason a proxy gets bypassed and the most common reason a claim against the vendor collapses. Audit your DNS zone for it while things are calm.

Frequently Asked Questions

Is a DDoS attack a criminal offence in the UK?

Yes. Section 3 of the Computer Misuse Act 1990 covers unauthorised acts intended to impair the operation of a computer, with a maximum of 10 years on indictment. Buying or supplying a booter or stresser service falls under section 3A, and section 3ZA covers attacks causing serious damage, carrying up to 14 years or life in the most severe cases.

Can you sue someone for a DDoS attack?

You can, provided you can identify and serve a defendant with assets worth pursuing. Civil action has succeeded against commercial booter operators, as in Ubisoft’s 2021 case reported at just over $153,000 plus takedowns. Against anonymous or overseas individuals, the cost of attribution and enforcement generally outweighs anything recoverable.

Who should you report a DDoS attack to in the UK?

Report to Action Fraud for a crime reference number, or to Police Scotland on 101 if you are in Scotland. Then work through sector duties: NIS Regulations notification if you are an operator of essential services or a relevant digital service provider, FCA reporting for financial firms, and an Article 33 assessment for the ICO where personal data availability was affected.

Does a DDoS attack have to be reported to the ICO?

Not automatically, but it can be reportable. UK GDPR Article 32 treats availability as part of security, so if people lost access to personal data and there is a risk to their rights and freedoms, Article 33 requires notification within 72 hours of becoming aware. Record the assessment and its reasoning even where you decide notification is not required.

Should you pay a ransom DDoS demand?

Paying is the weakest option and carries its own legal exposure, including financial sanctions liability and the money laundering offences in the Proceeds of Crime Act 2002. It guarantees nothing and marks you as a payer. Notify your insurer and law enforcement first, and make the decision through a chain you agreed in writing before the attack rather than during it.



Ecommerce Site DDOS Attack: A Playbook for the First 60 Minutes (and the Weeks Before)

An ecommerce site DDoS attack rarely announces itself the way retailers expect: no bandwidth graph pinned to the ceiling, no dramatic outage banner, just a checkout that takes eleven seconds to respond on the busiest Friday of the quarter, a scatter of 504s at the load balancer, and a support inbox filling with “payment failed”while the CDN dashboard reports a perfectly ordinary day. Bandwidth looks fine. That is usually the point.

Distributed denial-of-service (DDoS) attacks against online shops have shifted away from raw volume towards the handful of endpoints that cannot be cached and cannot be skipped: search, faceted filtering, cart, login, coupon validation and the payment callback. Those are the parts of the stack that hit the database on every request. This piece is a runbook for the hour an attack starts, and for the fortnight before it, when the decisions that determine how that hour goes are actually made.

What an ecommerce DDoS attack actually targets on your shop

Three surfaces belong to the retailer, and they fail in different ways.

The first is the network pipe: the transit into your hosting, saturated by volumetric floods (UDP reflection, amplified DNS or NTP responses, carpet-bombing across a /24). The second is the application layer, where HTTP requests are cheap for the attacker and expensive for you. The third is authoritative DNS, which is the layer most retailers leave sitting with a domain registrar on a free plan while paying four figures a month for web protection. Take DNS down and the shop is gone regardless of how well the HTTP layer is defended. Nobody reaches your beautifully scrubbed origin if the name never resolves.

Why a small Layer 7 flood hurts more than a big volumetric one

Consider a mid-sized Adobe Commerce (Magento) install behind a CDN. A few thousand requests per second aimed at /search?q= with randomised terms, each one stacking two or three facet filters, will bypass the page cache entirely because every URL is unique. Each request opens a database connection. Connection pool exhausts, PHP-FPM workers queue, the load balancer starts returning 502s and 504s, and the bandwidth graph stays flat enough that the first hour is spent looking at the wrong dashboard.

The same logic applies to add-to-cart, coupon code validation, account login and the postcode lookup on the delivery step. Anything that writes to session state, queries stock or calls a third-party API is a lever. Attackers who bother to browse the site first find these in about ten minutes.

Payment and fulfilment callbacks: the failure nobody plans for

Checkout is not a single request. It is a conversation between your site, a payment service provider (PSP), a 3-D Secure step at the card issuer, and a webhook coming back the other way to confirm the transaction. Under load, that conversation breaks in ugly ways: the shopper is charged but the order never lands in the ERP; the webhook retries against a timed-out endpoint and eventually gives up; the fulfilment feed to your 3PL falls behind. Reconciliation the next morning is often more expensive than the lost trading hours, and it is the part that finance remembers.

Who attacks shops, and why

Motive matters because it predicts timing. Ransom DDoS operators send a short demonstration burst of a few minutes, then an email demanding cryptocurrency with a deadline and a threat of something longer, and they time it for peak trading because that is when a retailer’s patience is thinnest. Competitor sabotage is harder to attribute and should be treated as an open question rather than an assumption, though the pattern of short attacks during flash sales is familiar to anyone who has run mitigation for consumer brands. Hacktivist targeting follows the news cycle and picks brands for what they represent. Retail has been in the firing line for years; the DDoS attack that took CafePress offline is an early example of the pattern that later became routine.

Attack, flash sale or bad crawler? Ten minutes to a working diagnosis

Genuine traffic converts. That single fact separates most incidents from most spikes.

If sessions triple while conversion rate collapses towards zero, and requests per session climb far above your normal browsing pattern, you are not looking at a successful email campaign. Check the source spread next: real UK retail traffic arrives from a wide mix of consumer ISPs and mobile carriers. Attack traffic tends to concentrate in a handful of autonomous system numbers (ASNs), often hosting providers or VPN ranges, and frequently in geographies you barely trade with.

Then read the machine evidence:

  • Origin CPU and database connections high while inbound bandwidth is unremarkable points to a Layer 7 flood, not a volumetric one.
  • Cache hit ratio falling off a cliff means requests are being crafted to miss cache, which is deliberate.
  • 502/504 patterns clustered on a small set of paths tell you which endpoints to protect first.

Misdiagnosis is common and costly. A scraper hammering product pages for price comparison looks like an attack until you notice it respects a single user agent and crawls in order. A runaway marketplace feed integration can generate the same load profile. So can an expired intermediate certificate, or a database lock from a bulk product import that someone kicked off at 09:00 without telling anyone. Rule those out before you escalate, because a provider who receives three false alarms will treat the fourth accordingly.

Whatever the verdict, capture evidence while it is still in the buffer: precise timestamps with time zone, sample log lines showing the offending requests, the target URLs, request rates per minute, and the spread of source IPs and ASNs. Weak attack reporting is how retailers end up unable to prove anything to a PSP, an insurer or a board committee six weeks later.

The first 60 minutes: a runbook for a shop that is down

Print this. Put it somewhere that does not depend on the website being up.

Minutes 0 to 10: confirm scope from outside your own network

  1. Test the site from a mobile connection off the office network, and from a second geography if you have a colleague or a VPS available.
  2. Test DNS resolution separately from HTTP. Query your authoritative nameservers directly. A shop that fails to resolve is a different incident from a shop that resolves and times out, and the two go to different teams.
  3. Open the ticket with severity wording your contract recognises. “Site slow”gets queued. “Production checkout unavailable, suspected volumetric or Layer 7 DDoS, revenue impacting, requesting mitigation engineer”does not.

Minutes 10 to 30: establish who is authorised to act

This is the moment retailers discover what they actually bought. A self-service plan gives you a dashboard, a rules engine and a support queue. If nobody on the provider’s side is empowered to change a mitigation profile at 03:00 without your written sign-off, you have bought monitoring, not management. Define this in the contract long before you need it: onboarding, tuning of Layer 7 rules against your specific checkout and search paths, named escalation numbers with out-of-hours cover, and explicitly who may apply mitigation on your behalf. Our guide to managed DDoS protection in the UK goes into the contractual detail; the short version is that “managed”is a marketing word until somebody writes down what it obliges them to do. Before locking in those clauses, it is worth understanding what a terabit DDoS attack actually breaks on the ground, which our companion piece explores in detail.

Minutes 30 to 60: tactical controls that buy time

In rough order of how much collateral damage they cause:

  • JavaScript or managed challenges on non-cacheable paths only (search, filters, login, cart), leaving product and category pages untouched.
  • Rate limits per IP and per session on the endpoints identified in your diagnosis. Set them against your real 95th percentile, not a guess.
  • A checkout queue, if your platform supports one. Slow is survivable. Broken is not.
  • Geo or ASN blocking as a blunt last resort, and only for ranges you genuinely do not sell to. Blocking a whole country during an incident is a trading decision, not a technical one.

In parallel, someone commercial needs to pause paid media (every pound spent driving traffic to a dead checkout is burned), update the status page and brief customer service with a line that does not invite speculation, and start logging downtime minute by minute for the loss calculation later.

Origin IP leakage: why the proxy quietly stops protecting your checkout

When a proxied site gets flattened, the cause is more often a leaked origin address than an attack too big to absorb. The attacker simply goes around the front door.

The usual leak paths on retail stacks are depressingly consistent: an old A record still pointing at the previous host; transactional email (order confirmations, dispatch notices) sent directly from the web server, exposing the origin in the mail headers; a staging or dev subdomain on the same box; cPanel, webmail and FTP hostnames; historic certificates recorded in public certificate transparency logs; and direct-to-origin API endpoints built for a mobile app, an EPOS integration or a marketplace channel because someone found the proxy inconvenient.

Closing it is unglamorous work:

  • Rotate the origin IP after going behind a proxy. If the old address is still live, the migration achieved nothing.
  • Allow-list only the provider’s published IP ranges at the host firewall, and drop everything else on ports 80 and 443.
  • Move outbound mail to a separate service or IP entirely.
  • Audit every subdomain, including the ones marketing created for a campaign in 2019.

Authoritative DNS deserves its own budget line

Treat DNS as a project, not a checkbox on the registrar’s control panel. Anycast delivery, redundancy across two independent providers, and a rehearsed time-to-live (TTL) plan so an emergency reroute propagates in minutes rather than a day. Drop TTLs to 300 seconds a week before peak trading and put them back afterwards. Rehearse the failover once, with the person who would actually be awake at 02:00 doing the typing.

Choosing protection that fits an online shop, and what it costs

Three deployment models are realistic for retailers. A reverse proxy or CDN in front of the shop is the default for anyone on Shopify Plus, WooCommerce or a hosted Magento, and it handles Layer 7 properly. BGP scrubbing suits retailers who own their address space and run their own infrastructure. Hosting-level filtering, bundled by the platform or by a DDoS protected hosting provider, is the cheapest option and usually the least tunable; it protects the shared estate first and your checkout second. The trade-offs are set out further in this comparison of how the main mitigation providers differ.

Always-on versus on-demand is a different sum for a shop than for a corporate website. An on-demand BGP diversion that takes several minutes to complete can span an entire checkout window at peak, and those are minutes of failed payments, not a slightly late intranet. Always-on proxying removes that delay, at the cost of making every payment redirect and PSP webhook dependent on that provider’s own availability. Neither answer is universally right. Pick deliberately, and know which one you chose.

Ask who owns the network behind the badge

A large share of UK ecommerce protection is resold. The terabits-per-second figure on the datasheet may belong to an upstream scrubbing network three companies away, and your escalation path may run through a reseller’s support desk before it reaches anyone who can change a mitigation profile. Ask directly: whose network, what capacity is contracted to you specifically, and how many hops sit between your phone call and the engineer.

Then ask for evidence rather than a deck. Request a redacted sample attack report and check whether it lists attack vectors, packet and request rates, target URLs and mitigation timestamps. A report you can hand to your PSP, your insurer or your board is part of what you are paying for. Testing vendor claims properly is a discipline of its own, covered in more depth in this piece on judging protection claims against real attacks.

Build the case on downtime cost, not gigabits

Finance directors do not fund gigabits. Take annual online revenue, divide by trading hours to get a baseline hourly figure, then apply a peak multiple for Black Friday week, when checkout volume runs at several times a normal day for most consumer brands. Add the paid media spend that would burn during the outage window and an honest estimate of the carts that never come back. That number, not the attack size, sets your budget.

UK managed deals typically price as a monthly commit tied to clean bandwidth or request volume, with overage charges above it, sometimes a per-attack or emergency onboarding fee, plus one-off setup and rule tuning. Annual contracts with a peak-season uplift clause are common. Check current pricing directly with providers; the shape is stable, the numbers are not.

A pre-peak checklist you can run in a week

Contract evidence. SLA definitions expressed in seconds to mitigate rather than “rapid response”; a redacted sample attack report; a named escalation path with out-of-hours cover and a phone number that reaches a human; a documented change freeze covering the trading peak.

Proof of value. Run a controlled load test through the proxy with the provider’s knowledge and written permission. Rehearse a DNS failover. Dry-run your rate limits on search and login against real traffic in log-only mode first, because a mistuned limit will block your own customers faster than any botnet.

Application hardening. Cache product and category pages aggressively. Put challenges in front of login, coupon and account-creation endpoints. Offload search to a dedicated service so a flood cannot reach the primary database. Decide in advance what a degraded-but-trading site looks like: static product pages, no faceted filtering, checkout still live.

Legal and reporting. Unauthorised denial of service falls under the Computer Misuse Act 1990, as amended by the Police and Justice Act 2006. Report attacks and any extortion attempt to Action Fraud and, for significant incidents, to the National Cyber Security Centre. Tell your PSP and your insurer early. A pure DDoS does not usually touch personal data, but if the flood turns out to be cover for an intrusion, UK GDPR breach notification timelines to the Information Commissioner’s Office start running.

And on the ransom question, the guidance from UK law enforcement and the NCSC has not changed: do not pay. Payment funds the next campaign, marks you as compliant to other groups, and buys no enforceable guarantee. Preserve the email headers and the attack logs instead.

Frequently Asked Questions

How can I tell if my ecommerce site is under a DDoS attack or just having a traffic spike?

Look at conversion rate against session volume. Genuine spikes convert at roughly normal rates; attack traffic sends sessions up while conversions fall towards zero, with abnormally high requests per session. Concentration in a few ASNs or hosting ranges, a collapsing cache hit ratio and errors clustered on non-cacheable paths such as search and cart confirm the picture.

What should I do in the first hour of an ecommerce site DDoS attack?

Confirm the outage from outside your network, test DNS resolution separately from HTTP, then open a ticket using severity wording your contract recognises. Apply challenges and rate limits to the affected non-cacheable endpoints, pause paid media, and capture timestamps, sample logs and source data while they are still available. Escalate to a named contact rather than a generic support address.

Can a DDoS attack steal customer or payment card data?

A denial of service attack floods capacity; on its own it does not exfiltrate data. The risk is that a flood is used as cover while an intruder works elsewhere, or that emergency changes such as disabling a firewall rule create an opening. Review authentication logs and any configuration changes made during the incident before you close it out.

Does Shopify, Magento or WooCommerce hosting already include DDoS protection?

Most platforms and hosts include some baseline network filtering, and fully hosted platforms carry more of it than self-managed stacks. Baseline filtering is aimed at volumetric floods across shared infrastructure, not at application-layer attacks tuned to your search and checkout paths. Ask your host what it actually mitigates, how quickly, and whether anyone will tune rules for your site specifically.

Should we ever pay a ransom demand attached to a DDoS attack?

No. UK guidance from law enforcement and the NCSC is consistently against payment; it funds further attacks, identifies you as a paying target and secures no enforceable promise that the attack stops. Preserve the demand with full email headers, report it to Action Fraud, and put your effort into mitigation and evidence.

How much does managed DDoS protection cost for a UK online retailer?

Pricing is usually structured as a monthly commit tied to clean bandwidth or request volume, with overage above that level, plus one-off onboarding and rule tuning; per-attack or emergency onboarding fees appear in some contracts, and annual deals often carry a peak-season uplift clause. Quotes vary widely by traffic profile and by how much human response is included, so compare on defined response times and named escalation, not headline capacity. Justify the spend against revenue per trading hour at peak rather than against attack size, because that is the number that decides whether an ecommerce site DDoS attack costs you an hour or a quarter.

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

  1. Search historical and passive DNS records, certificate transparency logs and mail records for anything that exposes an origin IP address; retire what you find.
  2. Confirm the origin firewall accepts traffic only from your mitigation provider’s ranges, and prove it by connecting from outside them.
  3. 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.
  4. Enumerate every hostname the mobile app and the kiosks resolve, and confirm which are behind the edge.
  5. 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.