🔍 Miner Hunter

أداة كشف وإزالة وتحصين خوادم لينكس ضد عمالات التعدين الرقمية.

بُنيت من استجابة حوادث حقيقية — تكتشف المنقبين الذين يختبئون من ps و top و htop و btop باستخدام تقنيات الروتكيت.

📦 التثبيت

git clone https://gitlab.com/abdom.seada/security-checks.git
cd security-checks
sudo bash setup.sh

🔀 الفرع: master — هذه المجموعة موجودة على الفرع master. قد تُضاف نصوص أمنية أخرى على فروع منفصلة في المستقبل.

⚙️ الإعداد

⚠️ قم بتشغيل setup.sh مرة واحدة فور الاستنساخ — تخطي هذه الخطوة هو السبب الرئيسي للأخطاء.

sudo bash setup.sh

setup.sh يتولى كل شيء تلقائياً:

المخرجات المتوقعة عند نجاح الإعداد:

✅ Setup complete — all checks passed!

  Next steps:
    sudo ./miner-hunter scan        # Safe read-only scan
    sudo ./miner-hunter full        # Scan → Kill → Harden

💡 لماذا هذا ضروري؟ لن ينفذ لينكس ملفاً ما لم يكن لديه العلم +x. ينقل Git و SCP هذه الخاصية. يقوم setup.sh بإصلاح جميع الملفات دفعة واحدة — بما في ذلك وحدات lib/ التي يعتمد عليها النص الرئيسي.

🚀 البداية السريعة

sudo ./miner-hunter scan            # ✅ Safe — read-only, zero changes
sudo ./miner-hunter full            # ⚠️  Full pipeline: Scan → Kill → Harden
sudo ./miner-hunter scan --dry-run  # 👁️  Preview mode — shows what would happen

📋 الأوامر والخيارات

الأوامر

الخيارات

🎭 سيناريوهات الحالات

مواقف من الحياة الواقعية وما يجب تشغيله بالضبط في كل منها.

🔴 السيناريو 1 — "وحدة المعالجة المركزية لخادمي عند 100% لكن top لا يظهر شيئاً"

هذا هو العرض الكلاسيكي للروتكيت. المنقب يختبئ من أدوات مساحة المستخدم لكنه لا يستطيع الاختباء من عدادات أداء الأجهزة.

# Step 1: Run a safe scan first — confirm what's there before touching anything
sudo ./miner-hunter scan

ما ستراه إذا كان المنقب موجوداً:

🚨 [CRITICAL]  CPU anomaly: 97% user CPU but top shows max 2% per process
🚨 [CRITICAL]  perf detected 4 hidden threads consuming ~94% total CPU
🚨 [CRITICAL]  Active connection to 185.x.x.x:9200 (known mining port)
🚨 [CRITICAL]  Fake kernel thread PID=3421 NAME=[kworker/0:1] EXE=/tmp/.x/miner

# Step 2: Kill the miner and block its pool
sudo ./miner-hunter kill

# Step 3: Harden the server so it can't come back
sudo ./miner-hunter harden

🟡 السيناريو 2 — "أعتقد أنني تعرضت للاختراق لكنني لست متأكداً"

لاحظت شيئاً مريباً — حركة مرور صادرة غير معتادة، مهمة cron لم تنشئها، عملية باسم غريب — لكنك لست متأكداً.

# Run a full scan — completely safe, read-only, zero changes
sudo ./miner-hunter scan

# Then read the structured report
sudo ./miner-hunter report

التقرير في /root/miner_evidence_*/report.txt يُصنف كل اكتشاف حسب الخطورة:

• [CRITICAL] إدخالات → تابع إلى kill فوراً
• [WARNING] إدخالات → راجع يدوياً قبل التصرف
• تقرير فارغ → الخادم يبدو نظيفاً

🟠 السيناريو 3 — "قتلت المنقب يدوياً لكنه يعود باستمرار"

لدى المنقب آلية استمرارية — مهمة cron، خدمة systemd، إدخال PM2، أو باب خلفي في ملف تعريف الصدفة يعيد إحياءه بعد قتله.

sudo ./miner-hunter scan

ابحث عن هذه في المخرجات:

⚠️  [WARN]     Suspicious cron entry: * * * * * /tmp/.x/update
🚨 [CRITICAL]  Malicious systemd service: /etc/systemd/system/update-check.service
🚨 [CRITICAL]  PM2 process 'app-worker' has 8432 restarts — likely miner respawn loop
🚨 [CRITICAL]  Shell profile backdoor detected in /root/.bashrc

# kill removes ALL persistence artifacts — not just the running process
sudo ./miner-hunter kill

# Then harden to install the watchdog so you're alerted if anything respawns
sudo ./miner-hunter harden

💡 بعد kill، يقوم المراقب (watchdog cron) بالتشغيل كل 5 دقائق ويسجل في /var/log/miner_hunter/watchdog_alerts.log — ستعرف فوراً إذا عاد شيء.

🔵 السيناريو 4 — "أريد تحصين خادم جديد قبل حدوث أي شيء"

تحصين استباقي قبل النشر — لا منقب، لا حادث، فقط تأمين الأمور.

# Run harden standalone — no scan or kill needed
sudo ./miner-hunter harden

هذا سيقوم بـ:

• تدقيق إعداد SSH الخاص بك وطباعة الإعدادات الموصى بها
• التحقق من أن fail2ban نشط مع سجن sshd
• إنشاء خط أساس للتكامل لـ /usr/bin (مجموع اختباري MD5 — بحيث يمكنك اكتشاف الملفات الثنائية المعدلة لاحقاً)
• تثبيت مراقب cron يتحقق كل 5 دقائق من مؤشرات المنقبين
• حفظ أي قواعد iptables موجودة عبر عمليات إعادة التشغيل عبر خدمة systemd

⚫ السيناريو 5 — "المنقب نجا من القتل — وحدة المعالجة لا تزال مرتفعة"

بعد kill، خطوة التحقق تبلغ أن المنقب قد لا يزال قيد التشغيل:

⚠️  MINER MAY HAVE RESPAWNED
CPU: 89% | Mining conns: 1
Firewall blocks are in place — miner can't reach pool
Consider a REBOOT or OS REINSTALL

# 1. Firewall blocks are already in place — miner CANNOT reach its pool
#    Confirm blocks are active:
iptables -L OUTPUT -n | grep DROP

# 2. Run a second scan to see what survived
sudo ./miner-hunter scan

# 3. Check for a kernel module rootkit hiding the process
lsmod | grep -iE 'diamorphine|reptile|kovid|rootkit'

# 4. Non-zero taint = out-of-tree kernel modules loaded (rootkit indicator)
cat /proc/sys/kernel/tainted

إذا كانت قيمة تلوث النواة غير صفرية أو ظهرت وحدة روتكيت معروفة — فإن المنقب لديه تحكم على مستوى النواة. المسار الأكثر أماناً في هذه المرحلة هو إعادة تثبيت نظام التشغيل بالكامل من لقطة نظيفة معروفة.

🟣 السيناريو 6 — "أريد مراقبة مستمرة دون تشغيل الفحص يدوياً"

بعد harden، يكون مراقب cron مثبتاً بالفعل. إليك كيفية التعامل معه:

# Watch the alert log in real time
tail -f /var/log/miner_hunter/watchdog_alerts.log

# Confirm the watchdog cron job is registered
cat /etc/cron.d/miner-watchdog

# Check for /usr/bin binary changes since your baseline was taken
md5sum --check /var/lib/miner_hunter/usrbin_baseline.md5 --quiet

أي مخرجات من الأمر الأخير تعني أن ملفاً ثنائياً للنظام قد تم تعديله بعد خط الأساس الخاص بك — تحقق فوراً.

🔬 ما يكتشفه

كشف العمليات المخفية

تحليل وحدة المعالجة المركزية

تحليل الشبكة

آليات الاستمرارية

⚔️ عملية القتل — خطوة بخطوة

عند تشغيل sudo ./miner-hunter kill، هذا هو التسلسل بالضبط:

1. 🔥 حظر عناوين IP لمجمعات التعدين في جدار الحماية — تطبيق قواعد iptables DROP قبل القتل، حتى لا يتمكن المنقب من إعادة الاتصال حتى لو عاد
2. 💀 قتل قائد مجموعة الخيوط — استهداف TGID (معرف قائد مجموعة الخيوط) أولاً بـ SIGKILL
3. 🧹 مسح جميع خيوط العمل — قتل كل PID في نفس مجموعة الخيوط عبر نطاق PID الكامل
4. 🗑️ إزالة الآثار — إعدادات المنقب، الملفات الثنائية، الويبشيلات، وملفات الاستمرارية
5. 🔄 تنظيف PM2 — إزالة إدخالات المنقب من مدير عمليات Node.js وحفظ القائمة
6. ✅ التحقق — إعادة تشغيل perf وفحص /proc/net/tcp لتأكيد انخفاض وحدة المعالجة واختفاء الاتصالات

🛡️ التحصين بعد الحادث — ما يتم تطبيقه

📁 هيكل المشروع

security-checks/               ← repo root (master branch)
├── miner-hunter               # نقطة الدخول — هذا ما تقوم بتشغيله
├── setup.sh                   # ⚙️ الإعداد الأولي — شغّله مرة بعد الاستنساخ
├── lib/
│   ├── common.sh              # أدوات مشتركة: تسجيل، ألوان، مساعدات
│   ├── detect_hidden.sh       # كشف العمليات المخفية والروتكيت
│   ├── detect_cpu.sh          # تحليل وحدة المعالجة عبر perf و /proc
│   ├── detect_network.sh      # كشف اتصالات مجمعات التعدين
│   ├── detect_persistence.sh  # كشف آليات الاستمرارية
│   ├── kill_miner.sh          # قتل العمليات وإزالة الآثار
│   └── harden.sh              # التحصين بعد الحادث
├── README.md
└── LICENSE

📋 المتطلبات

📤 ملفات المخرجات

كل تشغيل يُنتج:

🌍 الأصل من العالم الحقيقي

بُنيت هذه الأداة أثناء استجابة حادثة نشطة ضد منقب عملات رقمية قام بـ:

• إعادة تسمية نفسه إلى next للاندماج مع عمليات Next.js على خادم Node.js
• استخدام قائد مجموعة خيوط أعيد تسميته إلى kthreadd — اسم خيط نواة فعلي
• حذف ملفه الثنائي من القرص أثناء بقائه قيد التشغيل في الذاكرة (/proc/PID/exe → (deleted))
• كونه غير مرئي تماماً لـ ps و top و htop و btop
• عدم اكتشافه إلا عبر تحليل عداد وحدة المعالجة المركزية للأجهزة في perf

📄 الرخصة

MIT