The same gap, twice
These two cases have almost nothing in common on paper: different companies, different attacks, different years. What they share is a blind spot. Each organisation had taken security seriously and spent on it; the money went to the front, the part customers and auditors see, while the backend was left reachable, misconfigured, or unwatched. Same mistake, made twice.
Key takeaways
- Even a top web application firewall (WAF) does nothing if the origin behind it stays directly reachable. Attackers just go around it.
- Neither case needed a clever exploit. Both came down to configuration and exposure, not a missing patch.
- The strongest defence is the simplest: never expose anything that doesn't need to be reachable.
Case 1: a game provider goes dark
A large online game provider had done the expensive, visible things. Its assets sat behind Cloudflare Enterprise, one of the strongest and most costly web application firewall (WAF) setups money can buy. On paper, a hard target, including against exactly the kind of flood that setup is built to absorb.
The weakness was behind it. The origin servers, the real machines serving the platform, were quietly reachable from the outside, not only through the proxy. So the attack never had to be application-level (layer 7) at all: a Mirai botnet aimed a high-bandwidth, layer-4 volumetric flood straight at the exposed origin, around Cloudflare entirely, and simply overran the provider's own filtering and bandwidth, which were never sized to absorb it.
Behind that sat one quiet assumption, and I met it again and again in the research: the origin cannot be found, so hardening it can wait. The proxy was doing the visible work, so the machines behind it were left as they were, directly reachable, and treated as though they were not.
A protection layer you can walk around is not really protection. It guards the front for polite traffic, and the attackers that matter are not polite.
Where it landed is the part worth remembering. The front nodes stayed up; the database servers behind them, the ones that actually feed the platform, buckled under the flood. They had built in redundancy, several database clusters rather than one, but it changed nothing here: the flood reached the different hosts at once, and they went down together. The pages still loaded, and behind them nothing worked: no login, no account, none of the live features. An empty shell for every customer, for as long as it lasted. The cost was a serious stretch of downtime, a heavy loss of revenue, and a real hit to their reputation.
Case 2: manipulated user balances
The second case was quieter, and in some ways worse. On a cluster somewhere in the estate, a piece of software was running with a known weakness, one that already has a working, public exploit, and it was reachable from outside. Attackers used it for remote code execution (RCE): running their own code on the machines, from the outside.
From there they did not knock anything offline. Instead, over a period of time, they quietly altered the money balances on multiple accounts across the provider's sites. No outage, no alarm, just numbers that were no longer correct. It went unnoticed for a long time, and that is the real damage. By the time it was found, it was hard to tell what was real and what had been changed. A site that goes down comes back up. Wrong data just sits there, quietly, and cleaning it up costs far more than the attack ever did.
What the two had in common
Neither needed a genius, and neither was about skimping on security. Both had spent real money on the parts you can see. One backend was reachable when it should not have been; the other ran a known weakness where it could be reached. It was rarely a simple missing patch. More often it was weak configuration and weak exposure management: not knowing what was running, and what could actually be reached from outside.
That is the finding. The front gets the budget and the attention; the backend gets forgotten. The best approach is simplest: never expose anything that does not need to be exposed. If a server, a service or a port has no reason to be reachable from the internet, it should not be, and then there is nothing to find in the first place. So look at your own backend the way an outsider would, take off the internet everything that does not need to be there, and patch what is left. That is most of the job.
Cases like these are not rare, and they are the reality today. Companies invest in protection, which is important and necessary, and then wonder how an incident still happened. Usually they never had a clear view of their own exposure. Protection matters, but it does not replace basic exposure management: you cannot defend what you did not know was reachable.
There are many more cases like these. The detail differs; the lesson does not.