🔍 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 :

Étape	Ce qu'elle fait
✅ Permissions	chmod +x sur miner-hunter et tous les scripts lib/*.sh
✅ Répertoires	Crée /var/log/miner_hunter/ et /var/lib/miner_hunter/ (root uniquement, 700)
✅ Dépendances	Vérie perf, mpstat, iptables, fail2ban, bc, strings — installe automatiquement les manquants
✅ Auto-test	Exécute ./miner-hunter --version pour confirmer que tout est bien câblé

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

Commande	Description	Modifie le système ?
scan	Analyse de détection complète — processus cachés, CPU, réseau, persistance	❌ Non
kill	Tue les mineurs identifiés, bloque les IPs des pools, supprime les artefacts	⚠️ Oui
harden	Durcissement post-incident — SSH, pare-feu, watchdog, baseline d'intégrité	⚠️ Oui
full	Exécute scan → kill → harden avec des invites de confirmation entre les phases	⚠️ Oui
report	Affiche le dernier rapport d'analyse	❌ Non

Options

Option	Description
-d, --dry-run	Prévisualise toutes les actions sans appliquer de changements
-e, --evidence DIR	Sauvegarde les preuves dans un répertoire personnalisé au lieu de /root/miner_evidence_*
-h, --help	Affiche l'aide
-v, --version	Affiche la version

---

🎭 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 »