Mein Hetzner-Server wurde gehackt und begann, Monero zu schürfen

• Auf einem privat betriebenen Hetzner-Server wurde eine ungewöhnliche CPU-Auslastung festgestellt; die Untersuchung ergab, dass ein Kryptowährungs-Miner für Monero (xmrig) lief
• Ursache war ein Angriff auf den Umami-Analytics-Container, der die Remote-Code-Execution-Schwachstelle in Next.js (CVE-2025-66478) enthielt
• Glücklicherweise lief der Container als Non-Root-Benutzer und ohne Host-Mounts oder Privilegienerweiterung, sodass der Einbruch auf den Container beschränkt blieb
• Die Angreifer nutzten unsichere Deserialisierung in Next.js Server Components, um eine schädliche Payload auszuführen und den Miner zu installieren
• Der Vorfall zeigt die Bedeutung von Dependency-Management und sicheren Container-Einstellungen; der Autor verschärfte daraufhin seine Sicherheitsmaßnahmen mit aktivierter Firewall, gehärtetem SSH und regelmäßigen Updates

---

Der Hack und die erste Reaktion

• Von Hetzner kam eine Warn-E-Mail, dass der Server externe Netzwerke gescannt habe
  • Einschließlich des Hinweises, dass der Server ohne Gegenmaßnahmen innerhalb von 4 Stunden gesperrt werden könnte
• Nach dem Login per SSH zeigte sich ein Prozess mit 819 % CPU-Auslastung unter /tmp/.XIN-unix/javae sowie mehrere xmrig-Prozesse
• Es stellte sich heraus, dass etwa 10 Tage lang Kryptowährungs-Mining betrieben worden war

Untersuchung des Angriffswegs

• Alle schädlichen Prozesse liefen unter dem Benutzer mit UID 1001, was zum Umami-Container passte
• Im Verzeichnis /app/node_modules/next/dist/server/lib/xmrig-6.24.0/ wurde die Miner-Binärdatei gefunden
• Der Ausführungsbefehl enthielt die Adresse des Mining-Pools auto.c3pool.org:443 sowie einen Benutzerschlüssel

Next.js-Schwachstelle und Angriffsmethode

• Ursache war die Deserialisierungs-Schwachstelle in React Server Components von Next.js (CVE-2025-66478)
  • Wenn Angreifer eine manipulierte HTTP-Anfrage senden, kann auf dem Server beliebiger Code ausgeführt werden
  • Dadurch wurde die Installation und Ausführung eines Kryptomining-Programms möglich
• Der Autor war davon ausgegangen, „Next.js nicht direkt zu verwenden“, erkannte jedoch erst später, dass Umami auf Next.js basiert

Bestätigung der Container-Isolation

• Es wurde bestätigt, dass /tmp/.XIN-unix/javae nicht im Host-Dateisystem existierte
  • Dass der Prozess in der Ausgabe von Docker-ps erschien, war lediglich ein Anzeigeeffekt; tatsächlich blieb die Isolation erhalten
• Ergebnis von docker inspect:
  • Benutzer: nextjs
  • Privileged: false
  • Mounts: keine
• Deshalb konnte die Schadsoftware nicht auf den Host zugreifen, keine Cronjobs eintragen, keine Systemdienste anlegen und kein Rootkit installieren

Wiederherstellung und Härtung der Sicherheit

• Nach dem Stoppen und Löschen des infizierten Umami-Containers normalisierte sich die CPU-Auslastung
• Durch das Aktivieren der UFW-Firewall wurden nur noch SSH, HTTP und HTTPS erlaubt
• Nach dem Bericht der Untersuchungsergebnisse an Hetzner wurde das Ticket innerhalb einer Stunde geschlossen

Lehren und Verbesserungen

• „Ich nutze X nicht“ gilt nicht automatisch für Abhängigkeiten
  • Man muss prüfen, aus welchem Technologie-Stack die verwendeten Tools bestehen
• Die Wirksamkeit von Container-Isolation wurde bestätigt
  • Non-Root-Benutzer, nicht privilegierter Modus und der Verzicht auf unnötige Volumes verhinderten eine Ausweitung des Schadens
• Notwendig ist eine mehrschichtige Sicherheitsstrategie (Defense in Depth)
  • Firewall, fail2ban, Monitoring und regelmäßige Updates sind essenziell
• Hervorgehoben wurde die Bedeutung eines selbst geschriebenen Dockerfiles und minimaler Container-Berechtigungen

Maßnahmen nach dem Vorfall

• Umami wurde auf die neueste Version aktualisiert und alle Third-Party-Container auditiert
  • Geprüft wurden Laufzeitbenutzer, Mounts, Update-Zeitpunkt und Notwendigkeit
• Umstellung auf SSH-Schlüssel-basierte Authentifizierung, Deaktivierung des Passwort-Logins und Einrichtung von fail2ban
• Ausbau des Monitorings mit Grafana und Node Exporter sowie sofortige Anwendung von Sicherheitsupdates

Fazit

• Durch die Next.js-Schwachstelle in Umami wurde der Server 10 Tage lang zum Monero-Mining missbraucht,
  doch dank Container-Isolation und Non-Root-Konfiguration blieb der Schaden begrenzt
• Durch diese Erfahrung erkannte der Autor die Wichtigkeit von Dependency-Transparenz, Sicherheitskonfiguration und Update-Management
• Der Vorfall war in etwa zwei Stunden behoben und bleibt ein Praxisbeispiel für die tatsächliche Wirksamkeit von Container-Sicherheit