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

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

Opzioni

🎭 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

# Controlla le modifiche ai binari di /usr/bin dalla baseline
md5sum --check /var/lib/miner_hunter/usrbin_baseline.md5 --quiet

Qualsiasi output dall'ultimo comando significa che un binario di sistema è stato modificato dopo la baseline — indaga immediatamente.

🔬 Cosa Rileva

Rilevamento Processi Nascosti

Profilo CPU

Analisi di Rete

Meccanismi di Persistenza

⚔️ Processo di Uccisione — Passo per Passo

Quando esegui sudo ./miner-hunter kill, questa è la sequenza esatta:

1. 🔥 Blocca gli IP del pool miner al firewall — regole iptables DROP applicate prima di uccidere, così il miner non può riconnettersi anche se riappare
2. 💀 Uccidi il leader del gruppo di thread — miri prima al TGID (PID leader del gruppo di thread) con SIGKILL
3. 🧹 Spazza tutti i thread worker — uccide ogni PID nello stesso gruppo di thread nell'intero range PID
4. 🗑️ Rimuovi artefatti — config miner, binari, webshell e file di persistenza
5. 🔄 Pulisci PM2 — rimuove voci miner dal process manager Node.js e salva la lista
6. ✅ Verifica — riesegue perf e controlla /proc/net/tcp per confermare che la CPU sia calata e le connessioni sparite

🛡️ Hardening Post-Incidente — Cosa Viene Applicato

📁 Struttura del Progetto

security-checks/               ← radice del repo (branch master)
├── miner-hunter               # Punto di ingresso — questo è ciò che esegui
├── setup.sh                   # ⚙️ Setup iniziale — eseguire una volta dopo il clone
├── lib/
│   ├── common.sh              # Utility condivise: logging, colori, helper
│   ├── detect_hidden.sh       # Rilevamento processi nascosti e rootkit
│   ├── detect_cpu.sh          # Profilo CPU tramite perf & /proc
│   ├── detect_network.sh      # Rilevamento connessioni pool miner
│   ├── detect_persistence.sh  # Rilevamento meccanismi di persistenza
│   ├── kill_miner.sh          # Uccisione processi e rimozione artefatti
│   └── harden.sh              # Hardening post-incidente
├── README.md
└── LICENSE

📋 Requisiti

📤 File di Output

Ogni esecuzione produce:

🌍 Origine Reale

Questo strumento è stato costruito durante una risposta a incidenti attivi contro un crypto miner che:

• Si era rinominato next per mimetizzarsi con i processi Next.js su un server Node.js
• Utilizzava un leader del gruppo di thread rinominato kthreadd — un nome di thread kernel reale
• Cancellava il suo binario dal disco mentre rimaneva in esecuzione in memoria (/proc/PID/exe → (deleted))
• Era completamente invisibile a ps, top, htop e btop
• Poteva solo essere rilevato tramite profilazione hardware CPU perf

📄 Licenza

MIT