A few euros for the attacker, a disaster for the victim: anatomy of a server takeover

The essentials in 30 seconds

A company operated an older web application that had lain unused for a long time and was then put back into service without first bringing it up to date. This very outdated version contained a known security vulnerability.

An automated attack found the gap, took over the application and, because it ran with the highest privileges of the system, the entire server as well. The attackers installed a crypto miner, misused the server as a weapon for attacks on third parties, and stole sensitive credentials including payment keys.

The bitter core: the attacker probably earned only a few euros from the crypto mining. The damage to the victim, cleanup, replacement of all credentials, downtime, possible reporting obligations, was of an entirely different magnitude. And all of it was only discovered five days later, by pure chance.

How the attack unfolded

The decisive mistake was not a programming error in the company’s own code. It was a failure to keep things up to date: the application was based on a widely used web framework, but in an outdated, unpatched version. For exactly this version a serious vulnerability was known that allows attackers to execute their own commands on the server through a normal web request (a so-called remote code execution).

To this first mistake came a second that multiplied the damage: the application ran with full privileges (as root). Individually, both points would be unpleasant. Together they are fatal. Because if an application runs with full privileges, one successful attack on it immediately means control over the entire server. The intermediate step attackers normally have to climb laboriously (privilege escalation) is eliminated entirely.

The attackers first probed the gap automatically. The server logs contained over 26,000 attack attempts on exactly this point. As soon as entry succeeded, a persistent backdoor was set up within seconds, disguised as a harmless-looking system service, which would even have survived a reboot.

The technical core (for those who want to know exactly)

Specifically, this was an application on Next.js version 15.3.3, operated as root behind a reverse proxy. Via a so-called server action, the framework ultimately executed a call of the form

spawnSync('/bin/sh', ['-c', <attacker_input>])

The key point: this line was not in the company’s code; the own source code contained no such call. It came from the vulnerable framework version itself. This is the classic trap of outdated dependencies: you do not have to make a single mistake yourself, it is enough not to keep a third-party component up to date. The injected commands were base64-encoded to bypass simple filters, a standard pattern of automated attack kits.

The timeline: five days unnoticed

Point in time	Event
Day 1	First automated attack probes on the gap
Day 1, a few hours later	Break-in succeeds, persistent backdoor set up
Day 1 to 5	Server unnoticed under foreign control
Day 6, early morning	Crypto miner starts, CPU load over 1000 percent
Day 6	Discovery, purely by chance, because other services collapsed under the load

For five days the server was taken over without anyone noticing. In the end it was not noticed through protection software, nor through the miner itself, but by a detour. The enormous computing load of the miner brought other, completely uninvolved services on the server to a crash. Only while restarting these services did it become apparent that a foreign process was running along at full load.

The break-in was therefore not noticed because someone was looking for attackers, but by chance while investigating a completely different disruption. Without this coincidence the backdoor would have stood open for weeks more. That is not functioning security. That is luck, and no company should build on it. This quiet, often days-long stay inside a system is typical: if you want to understand how a cyber attack unfolds step by step and what to do in the first hours, our guide lays out the full plan.

What the attackers left behind

On the compromised server the attackers installed a typical crime package. The analysis showed that all tools came from the same attacker toolchain, that is, a coherent, commercially distributed attack kit, not an individual specialised attack.

Malicious component	Function	Damage to the victim
Crypto miner	Secretly mines digital currency	Full CPU load, high electricity costs, slow systems
Hidden backdoor	Permanent remote access	Attacker returns any time, even after a reboot
DDoS tool	Server attacks third parties on command	Civil co-liability, IP blocks, reputational damage
Disguised system tool	Conceals the presence	Hampers detection and cleanup

Particularly critical: it did not stop at mining. The injected programs deliberately searched the server for credentials and read, among other things:

Sought-after data	Risk if leaked
Configuration files with passwords	Direct access to databases and services
Database passwords	Theft or manipulation of all customer data
SSH keys	Access to further connected servers
Payment keys (live keys)	Financial misuse, access to transactions

Every one of these credentials must be regarded as compromised after such an incident and replaced, a laborious, expensive process that goes far beyond merely cleaning the server.

A victim and yet responsible

A point that surprises many: if your own server is misused for attacks on third parties (as here through the DDoS tool), you are first of all a victim of a crime yourself; the break-in was not intended. Under criminal law, as an operator you are usually not at fault because intent is missing.

The civil side, however, is trickier. Anyone harmed by the outbound attack can make claims, and then the question is no longer “were you the perpetrator?” but “did you operate your server negligently unsecured?”. An outdated, unpatched application with full privileges on the open network is a poor argument in that discussion. So you remain a victim and at the same time bear a possible share of responsibility, because with careful operation you could have prevented the misuse. It is precisely this dual role that makes such incidents so unpleasant.

(Note: this article does not replace legal advice. The specific liability always depends on the individual case.)

The bill no victim likes to look at

The truly absurd thing about such incidents is the disproportion between what the attacker gains and what the victim loses.

The crypto miner ran only a few hours until it was discovered. The value generated in that time, measured by computing power and period, was in the range of a few euros. That is how little a foreign server is worth to an attacker, because he does not buy it but simply takes it.

Against this stands the damage to the victim. The following orders of magnitude are typical ranges for such incidents (not exact figures of this case, but orientation):

Cost block for the victim	Typical order of magnitude
Forensics and incident response	mid four-figure amount upwards
Replacement of all compromised credentials	several person-days
Business downtime during cleanup	hours to days of standstill
Reporting obligations for data leaks (GDPR)	effort plus possible fine risk
Reputation and liability risk (DDoS misuse)	hard to quantify, potentially high

A few euros for the attacker, many times that for the victim. It is precisely this disproportion that makes automated attacks so attractive: they cost the perpetrator almost nothing and are run en masse. Whoever has the cheapest open door gets hit.

The actual cause

It would be too easy to name only the outdated component. Software ages, gaps become known, that is everyday life. How regularly a known IT security vulnerability turns into damage worth millions is shown by cases such as WannaCry. What is decisive is how much damage a single omission is allowed to cause.

Here three things worked together: a non-updated application that ran with full privileges and was reachable directly from the internet, without any monitoring noticing the break-in. Each point on its own is repairable. In combination they produce the total loss.

Security does not arise from never making a mistake (that is impossible), but from ensuring that a single mistake is not enough to lose everything.

How you prevent this in your company

The good news: the most effective countermeasures are known, proven and cheap, especially compared to the cost of a real incident.

Measure	What it achieves	Effort
Keep software and dependencies consistently up to date	Known gaps are closed before they are exploited	Low to medium
Run applications with minimal privileges (never as root)	An app bug no longer takes over the whole server	Low
Do not expose services directly to the internet, only via upstream protection	Attack surface drastically reduced	Low
Switch off or check old, unused applications before they go online again	Prevents exactly the scenario of this case	Low
Logging and monitoring of security-relevant events	An incident is detected in minutes, not days	Low
Regular security audits and penetration tests	Weaknesses are found before attackers find them	Medium

The incident went undetected for five days. With active monitoring it would have been noticed in minutes. The difference between “minutes” and “five days” is often the difference between a scare and an existence-threatening loss.

Conclusion

This attack was no masterpiece. It was automated mass-market goods that exploited a single, widespread weakness: an outdated application with too many privileges, reachable directly from the internet, without monitoring. This very constellation is found in countless companies, often without anyone knowing.

The lesson is uncomfortable but clear: it is not about avoiding every mistake, but about ensuring that one mistake is not enough.