In Ukraine’s bank DDoS, the rumor outran the outage

The week

On February 15, 2022, distributed denial-of-service attacks disrupted the websites of Ukraine’s Ministry of Defense and armed forces and the online services of two large state-owned banks, PrivatBank and Oschadbank. Customers reported problems with online banking and mobile apps for several hours. Ukrainian officials described the attacks as the largest of their kind the country had seen. At the same time, text messages circulated falsely claiming that ATMs had stopped working, and Ukrainian authorities publicly denied them. On February 18, the White House and the UK government attributed the attacks to Russia’s military intelligence service, the GRU. Russia launched its full-scale invasion of Ukraine six days later.

Denial-of-service attacks are old and blunt. They flood a service with traffic rather than breaking in, and banks in many countries have contracted protection against them for a decade. Technically, the February attacks on Ukrainian banks were unremarkable, and service came back within hours. What made them instructive was the pairing. A visible outage arrived alongside false messages telling people that cash machines had failed, during a period of acute public fear. The apparent aim was a loss of confidence, with the outage as a prop. For a bank, that means availability has to be judged by what customers can do and what they believe they can do. We look at three parts of the response: keeping critical services up, keeping customers informed, and keeping other channels open.

Keeping critical services up

The defenses are well understood: enough capacity to absorb traffic, upstream filtering by carriers or specialist mitigation services, and architecture that separates critical functions from exposed public pages. The open question for most banks is coverage. Mitigation contracts often protect the main website and online banking front end but leave other dependencies outside.

Those dependencies are where outages hide. The mobile app’s back-end services may be hosted elsewhere. Authentication may run through a separate identity service. Payment and open banking interfaces may sit at a different address. DNS may be served by a provider without mitigation. Third-party components, such as a digital banking platform or a status page, may be hosted by vendors with their own protections. A map of every customer-facing dependency, with its mitigation status and owner, usually finds gaps. Periodic tests with simulated attack traffic, coordinated with providers, show whether the protection works under load.

Priority also matters. During an attack, a bank may need to shed less important traffic to protect login and payments. Rules for that triage, such as rate limits, geographic filters and challenge pages, are easier to agree in advance than during an incident, when every business line wants its page kept up. The rules should name who can switch them on, out of hours, and how long they may run before a senior review. Without that, a mitigation that blocks legitimate customers abroad can outlast the attack itself.

Keeping customers informed

When a service fails, customers look for an explanation. If the bank provides none quickly, they find one elsewhere, and in a crisis that may be rumor or deliberate falsehood. The false ATM messages in Ukraine filled exactly that gap.

Effective outage communication is fast, plain and consistent across channels. It says what is affected, what still works, what customers should do and when the next update will come. It must be published through channels that do not depend on the affected systems, such as a status page hosted separately, the bank’s social media accounts, and text messages from a registered sender. It works best when drafted in advance, with templates already approved by legal and communications staff, so that the first message goes out in minutes.

Speed is a trade-off. Early messages may later prove incomplete. A bank that waits for certainty, however, leaves the field to others. A short first statement that names the problem and promises the next update by a stated time is safer than silence. Executives should agree that rule before an incident, because the instinct during one is to wait.

Customers also need a way to tell the bank’s messages from fakes. That depends on habits set long before a crisis: a small number of official channels, a known sender identity, and a stated rule that the bank will never ask for passwords or codes. A bank that has taught those habits can point to them when fakes appear. One that communicates through a shifting mix of vendors and formats cannot.

Keeping other channels open

If online banking is degraded, customers need other ways to reach their money: cards, ATMs, branches and phone banking. These often run on different infrastructure. Card authorization and ATM networks frequently keep working when a bank’s web and app front ends are under attack. Saying so, clearly and quickly, answers the question that the false messages raised.

That requires the bank to know, for each disruption scenario, which channels stay up. A matrix linking scenarios such as a DDoS on online banking, a core processor outage or a regional telecommunications failure to each channel’s status is a short document with large value. It tells the communications team what to say and the operations team where to send staff.

It also bears on branch and contact center strategy. Banks closing branches and shifting service online have fewer fallback channels when digital ones fail. The answer is not to stop digital migration. Each closure plan should state how customers in that area will reach cash and service during a prolonged digital outage, and contact center capacity should be sized for the surge that follows any visible disruption.

With hindsight

The Ukrainian banks recovered quickly, and the February attacks were modest beside what followed the invasion. Over the next two years, pro-Russian hacktivist groups ran denial-of-service campaigns against banks, airports, hospitals and government websites in the United States and Europe. These mostly caused short outages and headlines rather than lasting harm. Attack volumes set new records as botnets of compromised devices grew. Regulators increasingly framed resilience as the ability to keep important services within set tolerances. The UK’s operational resilience rules took full effect in March 2025, and the EU’s Digital Operational Resilience Act applied from January 2025. Both direct firms to plan for disruption from the customer’s side. By this point in 2026, the banks that handle disruptive events best treat communication, fallback channels and contact center surge as part of resilience design. Mitigation contracts alone do not reassure a frightened customer.