Why e-banking is a DDoS target
E-banking is a critical service used by millions of clients 24/7. A DDoS attack paralyzing banking systems immediately generates financial losses, client complaints, and regulatory attention. Criminals use DDoS as a ransom tool (RDDoS), a distraction from intrusion, or for geopolitical purposes.
In 2025, the financial sector was the second most targeted sector for DDoS attacks. Average attack duration on financial institutions increased to 4.2 hours, with peak bandwidth exceeding 1 Tbps.
Types of DDoS attacks targeting banks
Volumetric attacks (Layer 3/4)
Flooding the bank’s network infrastructure with massive traffic — UDP flood, SYN flood, amplification attacks. The goal is to exhaust bandwidth and firewall resources.
Application attacks (Layer 7)
Targeting specific e-banking functions: login, transfers, balance checks. HTTP flood and Slowloris attacks generate seemingly legitimate traffic that’s difficult to filter without advanced analysis.
Banking API attacks
Exploiting Open Banking API endpoints and mobile banking applications. API rate limiting and authentication are critical for defense.
Carpet bombing
Distributed attack across multiple bank IP addresses simultaneously, making detection and filtering difficult. Each address receives traffic below detection threshold, but the aggregate paralyzes infrastructure.
E-banking downtime costs
Lost transactions: Every hour of unavailability means hundreds of thousands of unrealized transfers, card payments, and account operations.
Regulatory fines: DORA requires business continuity assurance. Repeated outages can result in sanctions and remediation orders.
Compensation: Corporate clients with SLAs can claim damages for service availability agreement breaches.
Reputational costs: Media immediately reports e-banking unavailability, undermining client trust and driving deposit outflows.
Multi-layered DDoS protection
Layer 1: Network edge protection
Partnership with anti-DDoS provider (scrubbing center) capable of absorbing attacks >1 Tbps. Automatic traffic rerouting during attacks.
Layer 2: WAF and rate limiting
Web Application Firewall with banking-specific rules: login form protection, transaction APIs, authentication processes. Session and IP-level rate limiting.
Layer 3: Attack-resilient architecture
Geographic redundancy, CDN for static resources, cloud infrastructure autoscaling, separation of critical systems from public interfaces.
Layer 4: Monitoring and SOC
SOC as a Service with real-time network traffic monitoring. Automatic anomaly detection, escalation, and mitigation procedure activation. Correlation of DDoS alerts with other attack indicators.
DDoS attack response plan
- Detection (< 2 min) — automatic network traffic anomaly detection by monitoring systems
- Classification (< 5 min) — identify attack type and vector, assess service impact
- Mitigation (< 15 min) — activate protection: reroute to scrubbing center, filter traffic, block vectors
- Communication — notify clients, regulators (per DORA), management, and IT teams
- Escalation — if mitigation ineffective: switch to backup infrastructure, activate BCP
- Post-mortem — attack analysis, filtering rule updates, report for regulators and auditors
DORA requirements for DDoS resilience
DORA requires financial institutions to regularly test operational resilience, including DDoS defense capabilities. Mandatory elements: DDoS test scenarios, business continuity plans, backup infrastructure failover mechanisms, and test reports.
Penetration testing including DDoS attack simulation allows assessing protection effectiveness and regulatory compliance. A security audit identifies gaps in anti-DDoS architecture.
Cybersecurity for Your Industry
Learn more about cybersecurity in your industry:
