🔍 Miner Hunter

Toolkit per la rilevazione, rimozione e hardening dei crypto-miner per server Linux.

Costruito da esperienze reali di incident response — rileva i miner che si nascondono da ps, top, htop e btop usando tecniche rootkit.

---

📦 Installazione

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

🔀 Branch: master — Questo toolkit risiede sul branch master. Altri script di sicurezza potrebbero essere aggiunti in branch separati in futuro.

---

⚙️ Setup

⚠️ Esegui setup.sh una sola volta subito dopo il clone — saltare questo passaggio è la causa #1 di errori.

sudo bash setup.sh

setup.sh gestisce tutto automaticamente:

Passaggio	Cosa fa
✅ Permessi	chmod +x su miner-hunter e tutti gli script lib/*.sh
✅ Directory	Crea /var/log/miner_hunter/ e /var/lib/miner_hunter/ (solo root, 700)
✅ Dipendenze	Controlla perf, mpstat, iptables, fail2ban, bc, strings — installa automaticamente quelle mancanti
✅ Auto-test	Esegue ./miner-hunter --version per confermare che tutto sia configurato correttamente

Output atteso quando il setup ha successo:

✅ Setup completato — tutti i controlli superati!

  Passi successivi:
    sudo ./miner-hunter scan        # Scansione sicura in sola lettura
    sudo ./miner-hunter full        # Scansione → Uccisione → Hardening

💡 Perché è necessario? Linux non esegue un file a meno che non abbia il flag +x. Git e trasferimenti SCP lo rimuovono. setup.sh ripara tutti i file in un colpo solo — inclusi i moduli lib/ da cui lo script principale dipende.

---

🚀 Avvio Rapido

sudo ./miner-hunter scan            # ✅ Sicura — sola lettura, nessuna modifica
sudo ./miner-hunter full            # ⚠️  Pipeline completa: Scansione → Uccisione → Hardening
sudo ./miner-hunter scan --dry-run  # 👁️  Modalità anteprima — mostra cosa succederebbe

---

📋 Comandi e Opzioni

Comandi

Comando	Descrizione	Modifica il sistema?
scan	Scansione di rilevamento completa — processi nascosti, CPU, rete, persistenza	✅ No
kill	Uccide i miner identificati, blocca gli IP dei pool, rimuove artefatti	⚠️ Sì
harden	Hardening post-incidente — SSH, firewall, watchdog, baseline di integrità	⚠️ Sì
full	Esegue scan → kill → harden con richieste di conferma tra le fasi	⚠️ Sì
report	Mostra il report della scansione più recente	✅ No

Opzioni

Opzione	Descrizione
-d, --dry-run	Anteprima di tutte le azioni senza apportare modifiche
-e, --evidence DIR	Salva le prove in una directory personalizzata invece di /root/miner_evidence_*
-h, --help	Mostra l'aiuto
-v, --version	Mostra la versione

---

🎭 Scenari d'uso

Situazioni reali e cosa eseguire esattamente in ciascuna di esse.

---

🔴 Scenario 1 — "La CPU del mio server è al 100% ma top non mostra nulla"

Questo è il classico sintomo di un rootkit. Il miner si nasconde dagli strumenti userspace ma non può nascondersi dai contatori hardware delle prestazioni.

# Passo 1: Esegui prima una scansione sicura — conferma cosa c'è prima di toccare qualsiasi cosa
sudo ./miner-hunter scan

Cosa vedrai se è presente un miner:

🚨 [CRITICO]  Anomalia CPU: 97% CPU utente ma top mostra al massimo 2% per processo
🚨 [CRITICO]  perf ha rilevato 4 thread nascosti che consumano circa il 94% della CPU totale
🚨 [CRITICO]  Connessione attiva verso 185.x.x.x:9200 (porta miner conosciuta)
🚨 [CRITICO]  Thread kernel falso PID=3421 NOME=[kworker/0:1] EXE=/tmp/.x/miner

# Passo 2: Uccidi il miner e blocca il suo pool
sudo ./miner-hunter kill

# Passo 3: Applica l'hardening al server per evitare che ritorni
sudo ./miner-hunter harden

---

🟡 Scenario 2 — "Penso di essere stato hackerato ma non sono sicuro"

Hai notato qualcosa di sospetto — traffico in uscita insolito, un cron job che non hai creato, un processo con un nome strano — ma non sei certo.

# Esegui una scansione completa — completamente sicura, sola lettura, zero modifiche
sudo ./miner-hunter scan

# Poi leggi il report strutturato
sudo ./miner-hunter report

Il report in /root/miner_evidence_*/report.txt categorizza ogni rilevamento per gravità:

• Voci [CRITICO] → procedere immediatamente con kill
• Voci [AVVISO] → rivedere manualmente prima di agire
• Report vuoto → il server sembra pulito

---

🟠 Scenario 3 — "Ho ucciso il miner manualmente ma continua a ripresentarsi"

Il miner ha un meccanismo di persistenza — un cron job, un servizio systemd, un'entrata PM2 o un backdoor nei profili shell che lo riavvia dopo che lo uccidi.

sudo ./miner-hunter scan

Cerca queste cose nell'output:

⚠️  [AVVISO]   Voce cron sospetta: * * * * * /tmp/.x/update
🚨 [CRITICO]  Servizio systemd malevolo: /etc/systemd/system/update-check.service
🚨 [CRITICO]  Processo PM2 'app-worker' ha 8432 riavvii — probabile ciclo di riavvio del miner
🚨 [CRITICO]  Backdoor nel profilo shell rilevato in /root/.bashrc

# kill rimuove TUTTI gli artefatti di persistenza — non solo il processo in esecuzione
sudo ./miner-hunter kill

# Poi applica l'hardening per installare il watchdog in modo da essere avvisato se qualcosa si riavvia
sudo ./miner-hunter harden

💡 Dopo kill, il cron watchdog viene eseguito ogni 5 minuti e registra in /var/log/miner_hunter/watchdog_alerts.log — saprai immediatamente se qualcosa ritorna.

---

🔵 Scenario 4 — "Voglio applicare l'hardening a un server nuovo prima che succeda qualcosa"

Hardening proattivo prima del deploy — nessun miner, nessun incidente, solo blocco del sistema.

# Esegui harden standalone — nessuna scansione o uccisione necessaria
sudo ./miner-hunter harden

Questo farà:

• Verificare la tua configurazione SSH e stampare le impostazioni consigliate
• Controllare che fail2ban sia attivo con una jail sshd
• Creare una baseline di integrità per /usr/bin (checksum MD5 — così puoi rilevare in seguito binari manomessi)
• Installare un watchdog cron che controlla ogni 5 minuti gli indicatori di miner
• Persistere le regole iptables esistenti attraverso i riavvii tramite un servizio systemd

---

⚫ Scenario 5 — "Il miner è sopravvissuto all'uccisione — la CPU è ancora alta"

Dopo kill, il passo di verifica segnala che il miner potrebbe essere ancora in esecuzione:

⚠️  IL MINER POTREBBE ESSERE RIAPPARSO
CPU: 89% | Connessioni miner: 1
I blocchi firewall sono in atto — il miner non può raggiungere il pool
Considera un RIAVVIO o una REINSTALLAZIONE DEL SISTEMA OPERATIVO

# 1. I blocchi firewall sono già in atto — il miner NON PUÒ raggiungere il suo pool
#    Conferma che i blocchi siano attivi:
iptables -L OUTPUT -n | grep DROP

# 2. Esegui una seconda scansione per vedere cosa è sopravvissuto
sudo ./miner-hunter scan

# 3. Controlla un rootkit modulo kernel che nasconde il processo
lsmod | grep -iE 'diamorphine|reptile|kovid|rootkit'

# 4. Taint diverso da zero = moduli kernel fuori dagli alberi caricati (indicatore rootkit)
cat /proc/sys/kernel/tainted

Se il valore di taint del kernel è diverso da zero o appare un modulo rootkit conosciuto — il miner ha controllo a livello kernel. La via più sicura a questo punto è una reinstallazione completa del sistema operativo da uno snapshot noto come pulito.

---

🟣 Scenario 6 — "Voglio monitoraggio continuo senza eseguire scansioni manualmente"

Dopo harden, il watchdog cron è già installato. Ecco come lavorarci:

# Segui il log degli avvisi in tempo reale
tail -f /var/log/miner_hunter/watchdog_alerts.log

# Conferma che il cron job watchdog sia registrato
cat /etc/cron.d/miner-watchdog