I got hacked: My Hetzner server started mining Monero

A developer's server got hacked, turning it into a Monero mining operation via a Next.js RCE vulnerability. This incident served as a potent, real-world lesson: while the attacker used sophisticated methods, the developer's diligent container configuration, running non-root and unprivileged, proved that Docker can be a formidable security boundary when used correctly. The story offers a detailed post-mortem and practical takeaways on defense-in-depth, resonating deeply with HN's focus on operational security and learning from real-world failures.

148

Score

136

Comments

Highest Rank

23h

on Front Page

First Seen

Dec 17, 9:00 PM

Last Seen

Dec 18, 7:00 PM

Rank Over Time

The Lowdown

Jake, the author, woke up to a concerning email from Hetzner: his server was scanning other networks, indicating a compromise. A quick check revealed his server's load average was through the roof, consumed by cryptocurrency mining software (xmrig) running from his Umami analytics container.

The Compromise: The attack was traced to a Remote Code Execution (RCE) vulnerability (CVE-2025-66478) in Next.js's React Server Components deserialization, specifically the 'Flight' protocol. Jake, mistakenly believing he didn't use Next.js, had overlooked that Umami was built on it.
The Investigation: The malware had been mining Monero for ten days. Initial panic about a host-level compromise turned to relief upon discovering the mining processes were contained within the Umami Docker container. This was due to the container running as a non-root user (nextjs), being unprivileged, and having no volume mounts to the host filesystem.
Container Isolation Triumph: Unlike other reported cases where compromised root-run containers led to full server rebuilds, Jake's setup ensured the malware could not escape to the host, install persistence, or access sensitive data. The ps aux output showed container processes as if they were on the host, but they were isolated to their namespace.
Lessons Learned: Key takeaways included the importance of understanding all dependencies (even indirect ones), validating that container isolation works when configured correctly (non-root, non-privileged, no unnecessary mounts), and the need for defense-in-depth strategies like firewalls and proper monitoring.
The Fix & Future: Jake stopped and removed the compromised container, bringing his server's CPU usage back to normal. He also immediately enabled a firewall. He plans to replace Umami, audit all third-party containers, harden SSH, implement better monitoring, and prioritize regular security updates.

Ultimately, what could have been a catastrophic breach became a valuable, albeit stressful, incident response exercise that validated the efficacy of properly configured container security measures.

The Gossip

Container Conundrums: Isolation or Illusion?

Commenters engaged in a lively debate about Docker's role as a security boundary. Many affirmed the author's experience, noting that proper container configuration (non-root, unprivileged, no volume mounts) indeed provides a robust layer of isolation, preventing host compromise. However, a significant counter-argument stressed that Docker is fundamentally *not* a security boundary, as it shares the kernel and still relies on Docker/kernel vulnerabilities for true host protection. Suggestions for enhanced isolation included using Podman (especially rootless mode), VMs like KVM/QEMU, or specialized runtimes like gVisor or Firecracker for multi-tenancy. Others highlighted the ease with which Docker containers are often misconfigured or over-privileged, undermining any potential security benefits.

Firewall Follies and Filtering Fundamentals

The author's admission of not having a firewall enabled initially sparked discussion. Commenters emphasized firewalls as a crucial layer of defense, with some recommending `firewalld` over `ufw` for better maintainability and Docker integration. A key point raised was that Docker's default networking can bypass host firewall rules, making careful configuration (e.g., `StrictForwardPorts=yes` in `firewalld`) essential. There was also a strong push for egress filtering—blocking all outbound connections unless explicitly whitelisted—to prevent malware from downloading itself or phoning home to command-and-control servers, which might have averted the entire incident.

Monero Mining Mayhem: The Next.js Nuisance

The discussion delved into the specifics of the Monero cryptomining operation. Many confirmed encountering similar attacks, specifically targeting the Next.js/React RCE vulnerability (CVE-2025-66478), indicating its widespread exploitation. A common question was whether CPU mining Monero is still profitable. The consensus was a resounding 'yes' for attackers, as they incur no hardware or electricity costs. While individual machines might generate only small amounts, aggregating thousands of compromised systems makes it highly lucrative. Monero's ASIC-resistant RandomX algorithm makes general-purpose CPUs a viable, albeit inefficient, mining option for attackers leveraging free computing resources.

Literary Lapses: The LLM Lookalikes

A significant meta-discussion emerged around the author's writing style, with several commenters identifying it as 'LLM-generated' or 'AI-like.' The author transparently admitted to using Claude to help draft the post, explaining it was due to personal writing difficulties and the stress of the incident. This sparked a debate on the desirability of AI-assisted writing, with many expressing a strong preference for 'bad human writing' over polished, but generic, LLM output. The community appreciated the author's honesty and encouraged him to continue writing in his own voice, even if less formally structured.