हैक होने के बाद मेरे Hetzner सर्वर ने Monero माइनिंग शुरू कर दी

• एक व्यक्ति द्वारा संचालित Hetzner सर्वर पर असामान्य CPU उपयोग दिखा, और जांच करने पर पाया गया कि क्रिप्टोकरेंसी Monero माइनिंग प्रोग्राम (xmrig) चल रहा था
• कारण यह था कि Umami analytics tool container, जिसमें Next.js की remote code execution vulnerability (CVE-2025-66478) मौजूद थी, उस पर हमला किया गया
• सौभाग्य से वह container non-root user के रूप में चल रहा था और उसमें host mount या privilege escalation नहीं था, इसलिए घुसपैठ container के भीतर ही सीमित रही
• हमलावर ने Next.js server components की unsafe deserialization का दुरुपयोग करके malicious payload चलाया और miner इंस्टॉल किया
• यह मामला dependency management और container security settings के महत्व को दिखाता है, और लेखक ने firewall enable करना, SSH hardening, और नियमित updates जैसी सुरक्षा व्यवस्थाएं मजबूत कीं

---

हैक की घटना और शुरुआती प्रतिक्रिया

• Hetzner से यह चेतावनी ईमेल मिला कि सर्वर बाहरी नेटवर्क को scan कर रहा था
  • इसमें यह सूचना भी थी कि 4 घंटे के भीतर कार्रवाई न होने पर सर्वर को block किया जा सकता है
• SSH से लॉग इन करके जांचने पर /tmp/.XIN-unix/javae पथ पर 819% CPU उपयोग करने वाली process और कई xmrig processes मिलीं
• पुष्टि हुई कि लगभग 10 दिनों तक क्रिप्टोकरेंसी माइनिंग चलती रही

घुसपैठ के रास्ते की जांच

• सभी malicious processes UID 1001 user के रूप में चल रही थीं, जो Umami container से मेल खाती थीं
• /app/node_modules/next/dist/server/lib/xmrig-6.24.0/ directory में miner executable मिला
• run command में auto.c3pool.org:443 mining pool address और user key शामिल थी

Next.js vulnerability और हमले का तरीका

• मूल कारण Next.js की React Server Components deserialization vulnerability (CVE-2025-66478) था
  • यदि हमलावर crafted HTTP request भेजे, तो सर्वर पर arbitrary code execute हो सकता है
  • नतीजतन क्रिप्टोकरेंसी miner को install और run करना संभव हो गया
• लेखक को लगा था कि “वह Next.js का सीधे उपयोग नहीं करता,” लेकिन बाद में पता चला कि Umami, Next.js आधारित है

container isolation की पुष्टि

• पुष्टि हुई कि /tmp/.XIN-unix/javae host filesystem पर मौजूद नहीं था
  • Docker के ps output में container process दिखने का यह केवल एक प्रभाव था; वास्तव में isolation बरकरार था
• docker inspect के नतीजे
  • user: nextjs
  • Privileged: false
  • Mounts: नहीं
• इसलिए malicious code host access, cron registration, system service creation, rootkit installation जैसी गतिविधियां नहीं कर सका

recovery और security hardening

• संक्रमित Umami container को stop और delete करने के बाद CPU उपयोग सामान्य हो गया
• UFW firewall enable करके केवल SSH·HTTP·HTTPS की अनुमति दी गई
• Hetzner को जांच के नतीजे भेजने के बाद ticket 1 घंटे के भीतर बंद हो गया

सबक और सुधार के बिंदु

• “मैं X का उपयोग नहीं करता” का अर्थ उसकी dependencies तक नहीं पहुंचता
  • जिन tools का उपयोग हो रहा है, वे किस technology stack पर बने हैं, यह जांचना जरूरी है
• container isolation की प्रभावशीलता साबित हुई
  • non-root user, non-privileged mode, और अनावश्यक volumes का उपयोग न करने से नुकसान फैलने से रुका
• security की layered defense (Defense in Depth) की आवश्यकता
  • firewall, fail2ban, monitoring, और नियमित updates आवश्यक हैं
• खुद Dockerfile लिखने और container permissions को न्यूनतम रखने के महत्व पर जोर

घटना के बाद उठाए गए कदम

• Umami को नवीनतम version पर redeploy किया गया और सभी third-party containers का audit किया गया
  • run user, mounts, update timing, और आवश्यकता की जांच की गई
• SSH key-based authentication पर स्विच, password login disable, और fail2ban configuration
• Grafana और Node Exporter के जरिए monitoring मजबूत, और security updates तुरंत लागू किए गए

निष्कर्ष

• Umami की Next.js vulnerability के कारण 10 दिनों तक Monero माइनिंग के लिए दुरुपयोग हुआ,
  लेकिन container isolation और non-root execution settings की वजह से नुकसान सीमित रहा
• इस अनुभव से लेखक ने dependencies की समझ, security settings, और update management के महत्व को गहराई से महसूस किया
• घटना लगभग 2 घंटे में संभाल ली गई, और यह container security के वास्तविक प्रभाव को साबित करने वाला मामला बन गया