35,000 attacks eliminated. 28% faster. 24 hours.
A global B2B SaaS platform operating across Azure, DigitalOcean, and GCP deployed OneFirewall Alliance and eliminated all unauthorised traffic — including 35,000 daily attacks — while reducing latency by 28%.
- 22% of all traffic was malicious
- 35,000 attacks per day
- No SSH brute-force protection
- 0 daily attacks reaching the perimeter
- 28% latency reduction
- All SSH attacks mitigated automatically
The alliance context behind the attack
Every indicator hitting Member X's perimeter arrived with context already attached — how many alliance members had reported it, how long it had been active, and when it last struck. That's the difference between a raw IP and actionable intelligence.
What the client was facing
A B2B SaaS platform operating globally across three cloud providers (Azure, DigitalOcean, and GCP), with infrastructure distributed across Europe (two instances) and the US. Despite their scale, they lacked effective perimeter security — resulting in runaway attack volume threatening service availability and performance.
- 22% malicious traffic — nearly a quarter of all incoming requests were unauthorised operations: bots, scanners, and attack toolkits.
- 35,000 attacks per day targeting web services and management consoles, overwhelming operations teams.
- Cloudflare free plan only — no advanced DDoS protection, no intelligent threat blocking.
- Direct, unprotected console access — SSH brute-force attempts reaching management interfaces.
- 24-hour deadline — the board required a full resolution within one business day.
Three phases, one business day
Threat Analysis
OneFirewall mapped all active attack patterns — automated bot traffic, SSH brute-force campaigns, and application-layer attacks — across all three cloud environments. Full threat picture established in hours.
Intelligence Integration
Deployed OneFirewall Alliance threat intelligence using Crime Score-based blocking — all sources scoring above 120 were immediately blocked at the edge. Real-time cross-member intelligence covered attack IPs the platform had never seen before.
Preventive Controls
Deployed ACLs to block high-risk IPs, whitelisted approved remote access ranges, optimised CDN routing, and hardened all web ingress points across Azure, DigitalOcean, and GCP simultaneously.
The full attack picture mapped in Phase 1: traffic from dozens of external sources, arriving across both Check Point and Fortinet devices, converging on a single Allow decision before reaching internal hosts.
Phase 2 in practice: one indicator, traced device by device. The same source IP is allowed on one port and denied on three others — the kind of split decision a Crime Score threshold makes automatically, at the edge.
From 35,000 daily attacks to zero — in 24 hours
While contributing intelligence back to the alliance that now protects every other member.
35,000
Daily attacks eliminated through alliance IP blocking — no manual intervention required.
28%
Latency reduction — blocking malicious traffic at the edge freed bandwidth and processing for legitimate users.
0
SSH and web application attacks left unmitigated, with no manual firewall rule updates.
12,000+
Daily threat feeds contributed to the alliance — intelligence that now protects 290+ other members.
0.49%
Unique threats identified — indicators not previously seen by any other alliance member, expanding coverage for everyone.
≥120
Crime Score threshold used — a conservative starting point for a first deployment.
“Perimeter security is critical for blocking malicious traffic at network edges. Real-time intelligence enabled accurate threat blocking without impacting legitimate users.”
What this actually looks like, captured live
To show the kind of traffic a Crime Score threshold has to deal with, we pointed a OneFirewall deception sensor at the open internet and logged everything that touched it. In one 8.75-hour window, 586 distinct sources generated 31,745 logged events — probing SMB, Telnet, RDP, industrial protocols, IoT brokers, and database ports, alongside a single scripted sweep that ran a full exploitation chain in under three minutes.
Initial access dominates — but the tail tells the real story.
86% of events were direct initial-access attempts, driven by a flood of SMB connection probes. Reconnaissance accounted for 11% — scanners mapping the attack surface. The remaining 3% covered execution, credential access, collection, and denial-of-service attempts.
SMB drew three-quarters of all traffic — everything else came after.
Beyond the SMB flood, attackers systematically probed the web app (HTTPS), Telnet, Jenkins, Jupyter, Grafana, RDP, and MongoDB — every unprotected service drew unsolicited connection attempts from multiple sources.
| Technique attempted | Events | Share |
|---|---|---|
| File share / lateral movement attempt (SMB port 445) | 24,324 | 76.6% |
| High-frequency automated scanning | 1,765 | 5.6% |
| TLS client fingerprinted | 1,742 | 5.5% |
| Remote code execution attempt | 1,009 | 3.2% |
| Unauthorized remote shell access (Telnet) | 678 | 2.1% |
| Attempted command execution | 563 | 1.8% |
| Monitoring dashboard information disclosure | 459 | 1.4% |
| Remote desktop access attempt (RDP) | 182 | 0.6% |
| Database exploitation attempt (MongoDB) | 166 | 0.5% |
| Default / weak credential access | 97 | 0.3% |
Five things this data tells us about how automated attacks actually work
Raw telemetry from 31,745 events across 586 source IPs, condensed into five operational conclusions for defenders.
8 MITRE tactics in 157 seconds
The top-scoring source (147.135.x.x) traversed every tactic from Reconnaissance through Impact in under three minutes: vulnerability scanning → public-facing exploit → command scripting → credential brute-force → data collection → persistence → denial-of-service. This is not a human operator. It is an automated exploitation framework running a predetermined playbook. Human-speed detection and response cannot match it — only pre-computed, edge-applied intelligence can.
90% of traffic carries no HTTP user-agent
28,546 of 31,745 events (89.9%) arrived as raw TCP/UDP probes with no user-agent string. These are invisible to web application firewalls, HTTP-layer proxies, and signature-based IDS. They scan for open ports, probe service banners, and transmit raw protocol frames — activity that only network-layer enforcement, operating before the application stack, can intercept.
64 coordinated IPs targeting Telnet — Mirai-variant signature
64 distinct IPs generated 4,956 Telnet-targeting events, all with no user-agent, multiple sharing /16 subnet blocks (66.132.x.x/16: 3 IPs; 31.40.x.x/16: 2 IPs; 94.154.x.x/16: 2 IPs). This is consistent with Mirai-variant botnet infrastructure: distributed nodes attempting default credentials on exposed routers, cameras, and NAS devices to recruit them. A single-IP blocklist misses this entirely — it requires /16 subnet-level correlation.
Six industry verticals probed in one 8.75-hour window
The same capture window saw probes against: DICOM (healthcare imaging), Modbus FC43 / OPC UA / Siemens S7 (energy / ICS), MQTT (IoT telemetry), Docker Registry / Kubernetes node APIs (cloud/tech), container image stores, and AI chat service API endpoints. These are not opportunistic scans — they are systematic sweeps using purpose-built tools for each protocol class. A firewall rule set built for one sector leaves the rest open.
Attack volume never drops to zero; it peaks at night (UTC)
03:xx UTC delivered 5,218 events/hour; 06:xx UTC peaked at 5,685. Even 22:xx — late-evening European time — logged 1,691 events. Botnet infrastructure is distributed across time zones and operates continuously. A perimeter that enforces only during business hours, or requires on-call manual review, offers no protection against infrastructure that does not sleep.
The tool, not the IP, is the persistent identifier
JA3 hash 6d148f747f881eff499f36677cb94c24 appeared in 1,471 events from a single source. As source IPs rotate through cloud providers and VPS ranges, the TLS client fingerprint stays constant — it reflects the tool implementation, not the address. This means a hash-based block survives IP rotation. OneFirewall ingests JA3 correlation from alliance members to propagate tool-level blocks before your own infrastructure ever sees the connection.