🔍 Miner Hunter

Kit de détection, suppression et durcissement anti-mineur de cryptomonnaie pour serveurs Linux.

Conçu à partir d'une réponse à incident réelle — détecte les mineurs qui se cachent de ps, top, htop et btop en utilisant des techniques rootkit.

📦 Installation

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

🔀 Branche : master — Cet outil se trouve sur la branche master. D'autres scripts de sécurité pourront être ajoutés sur des branches séparées à l'avenir.

⚙️ Configuration

⚠️ Exécutez setup.sh une fois juste après le clonage — ne pas le faire est la cause n°1 d'erreurs.

sudo bash setup.sh

setup.sh gère tout automatiquement :

Sortie attendue en cas de succès :

✅ Configuration terminée — toutes les vérifications réussies !

  Prochaines étapes :
    sudo ./miner-hunter scan        # Analyse sécurisée en lecture seule
    sudo ./miner-hunter full        # Analyse → Tue → Durcit

💡 Pourquoi est-ce nécessaire ? Linux n'exécute pas un fichier sans le flag +x. Git et les transferts SCP suppriment ce flag. setup.sh corrige tous les fichiers en une seule fois — y compris les modules lib/ dont dépend le script principal.

🚀 Démarrage rapide

sudo ./miner-hunter scan            # ✅ Sécurisé — lecture seule, aucune modification
sudo ./miner-hunter full            # ⚠️  Pipeline complet : Analyse → Tue → Durcit
sudo ./miner-hunter scan --dry-run  # 👁️  Mode aperçu — montre ce qui serait fait

📋 Commandes et Options

Commandes

Options

🎭 Scénarios concrets

Situations réelles et exactement quoi exécuter dans chaque cas.

🔴 Scénario 1 — « Le CPU de mon serveur est à 100 % mais top n'affiche rien »

C'est le symptôme classique d'un rootkit. Le mineur se cache des outils espace utilisateur mais ne peut pas se cacher des compteurs de performance matériels.

# Étape 1 : Lancez d'abord une analyse sécurisée — confirmez ce qui est présent avant de toucher à quoi que ce soit
sudo ./miner-hunter scan

Ce que vous verrez si un mineur est présent :

🚨 [CRITIQUE]  Anomalie CPU : 97 % CPU utilisateur mais top montre au maximum 2 % par processus
🚨 [CRITIQUE]  perf a détecté 4 threads cachés consommant environ 94 % du CPU total
🚨 [CRITIQUE]  Connexion active vers 185.x.x.x:9200 (port minier connu)
🚨 [CRITIQUE]  Faux thread noyau PID=3421 NOM=[kworker/0:1] EXE=/tmp/.x/miner

# Étape 2 : Tuez le mineur et bloquez son pool
sudo ./miner-hunter kill

# Étape 3 : Durcissez le serveur pour qu'il ne puisse pas revenir
sudo ./miner-hunter harden

🟡 Scénario 2 — « Je pense avoir été piraté mais je n'en suis pas sûr »

Vous avez remarqué quelque chose de suspect — trafic sortant inhabituel, une tâche cron que vous n'avez pas créée, un processus avec un nom étrange — mais vous n'êtes pas certain.

# Lancez une analyse complète — totalement sécurisée, lecture seule, aucune modification
sudo ./miner-hunter scan

# Puis lisez le rapport structuré
sudo ./miner-hunter report

Le rapport dans /root/miner_evidence_*/report.txt classe chaque résultat par sévérité :

• Entrées [CRITIQUE] → passez immédiatement à kill
• Entrées [ATTENTION] → examinez manuellement avant d'agir
• Rapport vide → le serveur semble propre

🟠 Scénario 3 — « J'ai tué le mineur manuellement mais il revient sans cesse »

Le mineur possède un mécanisme de persistance — une tâche cron, un service systemd, une entrée PM2 ou une porte dérobée dans un profil shell qui le relance après l'avoir tué.

sudo ./miner-hunter scan

Recherchez ces éléments dans la sortie :

⚠️  [ATTENTION]  Entrée cron suspecte : * * * * * /tmp/.x/update
🚨 [CRITIQUE]   Service systemd malveillant : /etc/systemd/system/update-check.service
🚨 [CRITIQUE]   Processus PM2 'app-worker' a 8432 redémarrages — probable boucle de relance du mineur
🚨 [CRITIQUE]   Porte dérobée dans le profil shell détectée dans /root/.bashrc

# kill supprime TOUS les artefacts de persistance — pas seulement le processus en cours
sudo ./miner-hunter kill

# Puis durcissez pour installer le watchdog afin d'être alerté si quelque chose se relance
sudo ./miner-hunter harden

💡 Après kill, le watchdog cron s'exécute toutes les 5 minutes et journalise dans /var/log/miner_hunter/watchdog_alerts.log — vous saurez immédiatement si quelque chose revient.

🔵 Scénario 4 — « Je veux durcir un serveur frais avant que quoi que ce soit n'arrive »

Durcissement proactif avant le déploiement — pas de mineur, pas d'incident, juste verrouiller les choses.

# Exécutez harden seul — scan ou kill n'est pas nécessaire
sudo ./miner-hunter harden

Cela va :

• Auditer votre configuration SSH et afficher les paramètres recommandés
• Vérifier que fail2ban est actif avec une prison sshd
• Créer une baseline d'intégrité de /usr/bin (sommes MD5 — pour détecter plus tard les binaires falsifiés)
• Installer un watchdog cron qui vérifie toutes les 5 minutes des indicateurs de mineur
• Persister les règles iptables existantes lors des redémarrages via un service systemd

⚫ Scénario 5 — « Le mineur a survécu au kill — le CPU est toujours élevé »

Après kill, l'étape de vérification rapporte que le mineur est peut-être toujours actif :

⚠️  LE MINEUR A PEUT-ÊTRE RÉAPPARU
CPU : 89 % | Connexions minage : 1
Les blocages du pare-feu sont en place — le mineur ne peut pas atteindre le pool
Envisagez un REDÉMARRAGE ou une RÉINSTALLATION DU SYSTÈME

# 1. Les blocages du pare-feu sont déjà en place — le mineur NE PEUT PAS atteindre son pool
#    Confirmez que les blocages sont actifs :
iptables -L OUTPUT -n | grep DROP

# 2. Lancez une seconde analyse pour voir ce qui a survécu
sudo ./miner-hunter scan

# 3. Vérifiez la présence d'un rootkit sous forme de module noyau cachant le processus
lsmod | grep -iE 'diamorphine|reptile|kovid|rootkit'

# 4. Un taint non nul = des modules noyau hors arbre chargés (indicateur de rootkit)
cat /proc/sys/kernel/tainted

Si la valeur de taint du noyau est non nulle ou si un module rootkit connu apparaît — le mineur a un contrôle au niveau du noyau. La voie la plus sûre à ce stade est une réinstallation complète du système d'exploitation à partir d'un instantané connu comme propre.

🟣 Scénario 6 — « Je veux une surveillance continue sans lancer d'analyses manuellement »

Après harden, le watchdog cron est déjà installé. Voici comment l'utiliser :

# Surveillez le journal d'alerte en temps réel
tail -f /var/log/miner_hunter/watchdog_alerts.log

# Confirmez que la tâche cron watchdog est enregistrée
cat /etc/cron.d/miner-watchdog

# Vérifiez les modifications des binaires de /usr/bin depuis votre baseline
md5sum --check /var/lib/miner_hunter/usrbin_baseline.md5 --quiet

Toute sortie de la dernière commande signifie qu'un binaire système a été modifié après votre baseline — enquêtez immédiatement.

🔬 Ce qu'il détecte

Détection des processus cachés

Profilage CPU

Analyse réseau

Mécanismes de persistance

⚔️ Processus Kill — Étape par étape

Lorsque vous exécutez sudo ./miner-hunter kill, voici la séquence exacte :

1. 🔥 Bloquer les IPs des pools miniers au pare-feu — les règles iptables DROP sont appliquées avant de tuer, afin que le mineur ne puisse pas se reconnecter même s'il réapparaît
2. 💀 Tuer le chef de groupe de threads — cible d'abord le TGID (PID du chef de groupe de threads) avec SIGKILL
3. 🧹 Balayer tous les threads de travail — tue tous les PIDs du même groupe de threads sur toute la plage de PIDs
4. 🗑️ Supprimer les artefacts — configurations, binaires, webshells et fichiers de persistance du mineur
5. 🔄 Nettoyer PM2 — supprime les entrées du mineur du gestionnaire de processus Node.js et sauvegarde la liste
6. ✅ Vérifier — relance perf et vérifie /proc/net/tcp pour confirmer que le CPU a chuté et que les connexions ont disparu

🛡️ Durcissement post-incident — Ce qui est appliqué

📁 Structure du projet

security-checks/               ← racine du dépôt (branche master)
├── miner-hunter               # Point d'entrée — c'est ce que vous exécutez
├── setup.sh                   # ⚙️ Configuration initiale — exécutez une fois après le clonage
├── lib/
│   ├── common.sh              # Utilitaires partagés : journalisation, couleurs, aides
│   ├── detect_hidden.sh       # Détection de processus cachés et rootkits
│   ├── detect_cpu.sh          # Profilage CPU via perf & /proc
│   ├── detect_network.sh      # Détection de connexions à des pools miniers
│   ├── detect_persistence.sh  # Détection de mécanismes de persistance
│   ├── kill_miner.sh          # Suppression de processus et d'artefacts
│   └── harden.sh              # Durcissement post-incident
├── README.md
└── LICENSE

📋 Prérequis

📤 Fichiers de sortie

Chaque exécution génère :

🌍 Origine réelle

Cet outil a été construit lors d'une réponse à incident active contre un mineur de cryptomonnaie qui :

• S'est renommé next pour se fondre parmi les processus Next.js sur un serveur Node.js
• A utilisé un chef de groupe de threads renommé en kthreadd — un véritable nom de thread noyau
• A supprimé son binaire du disque tout en restant actif en mémoire (/proc/PID/exe → (deleted))
• Était complètement invisible pour ps, top, htop et btop
• Ne pouvait être détecté que via le profilage des compteurs CPU matériels perf

📄 Licence

MIT