🔍 Miner Hunter

Kit de detecção, remoção e fortalecimento de criptomineradores para servidores Linux.

Construído a partir de resposta a incidentes reais — detecta mineradores que se escondem de ps, top, htop e btop usando técnicas de rootkit.

📦 Instalação

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

🔀 Branch: master — Este kit está na branch master. Outros scripts de segurança podem ser adicionados em branches separadas no futuro.

⚙️ Configuração

⚠️ Execute setup.sh uma vez logo após clonar — pular isso é a causa nº 1 de erros.

sudo bash setup.sh

setup.sh cuida de tudo automaticamente:

Saída esperada quando a configuração é bem-sucedida:

✅ Configuração concluída — todas as verificações passaram!

  Próximos passos:
    sudo ./miner-hunter scan        # Escaneamento seguro somente leitura
    sudo ./miner-hunter full        # Escaneamento → Matar → Fortalecer

💡 Por que isso é necessário? O Linux não executa um arquivo a menos que ele tenha a flag +x. Git e transferências SCP removem isso. setup.sh corrige todos os arquivos de uma só vez — incluindo os módulos lib/ dos quais o script principal depende.

🚀 Início Rápido

sudo ./miner-hunter scan            # ✅ Seguro — somente leitura, zero alterações
sudo ./miner-hunter full            # ⚠️  Pipeline completo: Escanear → Matar → Fortalecer
sudo ./miner-hunter scan --dry-run  # 👁️  Modo pré-visualização — mostra o que aconteceria

📋 Comandos e Opções

Comandos

Opções

🎭 Cenários de Caso

Situações do mundo real e exatamente o que executar em cada uma.

🔴 Cenário 1 — "A CPU do meu servidor está em 100% mas o top não mostra nada"

Este é o sintoma clássico de rootkit. O minerador está se escondendo das ferramentas do espaço do usuário, mas não pode se esconder dos contadores de desempenho do hardware.

# Passo 1: Execute um escaneamento seguro primeiro — confirme o que está lá antes de tocar em algo
sudo ./miner-hunter scan

O que você verá se um minerador estiver presente:

🚨 [CRÍTICO]  Anomalia de CPU: 97% de CPU de usuário, mas top mostra no máximo 2% por processo
🚨 [CRÍTICO]  perf detectou 4 threads ocultas consumindo ~94% do total da CPU
🚨 [CRÍTICO]  Conexão ativa para 185.x.x.x:9200 (porta de mineração conhecida)
🚨 [CRÍTICO]  Thread de kernel falsa PID=3421 NOME=[kworker/0:1] EXE=/tmp/.x/miner

# Passo 2: Mate o minerador e bloqueie seu pool
sudo ./miner-hunter kill

# Passo 3: Fortaleça o servidor para que ele não possa voltar
sudo ./miner-hunter harden

🟡 Cenário 2 — "Acho que fui hackeado, mas não tenho certeza"

Você notou algo suspeito — tráfego de saída incomum, um cron job que você não criou, um processo com nome estranho — mas não tem certeza.

# Execute um escaneamento completo — totalmente seguro, somente leitura, zero alterações
sudo ./miner-hunter scan

# Em seguida, leia o relatório estruturado
sudo ./miner-hunter report

O relatório em /root/miner_evidence_*/report.txt categoriza cada descoberta por gravidade:

• Entradas [CRÍTICO] → prossiga para kill imediatamente
• Entradas [AVISO] → revise manualmente antes de agir
• Relatório vazio → servidor parece limpo

🟠 Cenário 3 — "Matei o minerador manualmente, mas ele continua voltando"

O minerador possui um mecanismo de persistência — um cron job, serviço systemd, entrada PM2 ou backdoor no profile do shell que o reanima depois que você o mata.

sudo ./miner-hunter scan

Procure por estes na saída:

⚠️  [AVISO]    Entrada cron suspeita: * * * * * /tmp/.x/update
🚨 [CRÍTICO]  Serviço systemd malicioso: /etc/systemd/system/update-check.service
🚨 [CRÍTICO]  Processo PM2 'app-worker' tem 8432 reinicializações — provavelmente loop de reanimação do minerador
🚨 [CRÍTICO]  Backdoor no profile do shell detectado em /root/.bashrc

# kill remove TODOS os artefatos de persistência — não apenas o processo em execução
sudo ./miner-hunter kill

# Em seguida, fortaleça para instalar o watchdog e ser alertado se algo reanimar
sudo ./miner-hunter harden

💡 Após kill, o watchdog cron é executado a cada 5 minutos e registra em /var/log/miner_hunter/watchdog_alerts.log — você saberá imediatamente se algo voltar.

🔵 Cenário 4 — "Quero fortalecer um servidor novo antes que algo aconteça"

Fortalecimento proativo antes de implantar — sem minerador, sem incidente, apenas bloqueando tudo.

# Execute harden de forma independente — sem necessidade de scan ou kill
sudo ./miner-hunter harden

Isso irá:

• Auditar sua configuração SSH e exibir as configurações recomendadas
• Verificar se o fail2ban está ativo com uma jail sshd
• Criar uma linha de base de integridade no /usr/bin (checksums MD5 — para que você possa detectar binários adulterados posteriormente)
• Instalar um watchdog cron que verifica a cada 5 minutos por indicadores de minerador
• Persistir quaisquer regras iptables existentes entre reinicializações através de um serviço systemd

⚫ Cenário 5 — "O minerador sobreviveu ao kill — a CPU ainda está alta"

Após kill, a etapa de verificação relata que o minerador pode ainda estar em execução:

⚠️  MINERADOR PODE TER REANIMADO
CPU: 89% | Conns de mineração: 1
Bloqueios de firewall estão em vigor — minerador não consegue alcançar o pool
Considere uma REINICIALIZAÇÃO ou REINSTALAÇÃO DO SO

# 1. Os bloqueios de firewall já estão em vigor — o minerador NÃO PODE alcançar seu pool
#    Confirme que os bloqueios estão ativos:
iptables -L OUTPUT -n | grep DROP

# 2. Execute um segundo escaneamento para ver o que sobreviveu
sudo ./miner-hunter scan

# 3. Verifique a existência de um rootkit de módulo de kernel escondendo o processo
lsmod | grep -iE 'diamorphine|reptile|kovid|rootkit'

# 4. Taint diferente de zero = módulos de kernel fora da árvore carregados (indicador de rootkit)
cat /proc/sys/kernel/tainted

Se o valor de taint do kernel for diferente de zero ou um módulo rootkit conhecido aparecer — o minerador tem controle em nível de kernel. O caminho mais seguro neste ponto é uma reinstalação completa do SO a partir de um snapshot conhecidamente limpo.

🟣 Cenário 6 — "Quero monitoramento contínuo sem executar escaneamentos manualmente"

Após harden, o watchdog cron já está instalado. Veja como trabalhar com ele:

# Acompanhe o log de alertas em tempo real
tail -f /var/log/miner_hunter/watchdog_alerts.log

# Confirme que o cron job do watchdog está registrado
cat /etc/cron.d/miner-watchdog

# Verifique alterações em binários do /usr/bin desde que a linha de base foi criada
md5sum --check /var/lib/miner_hunter/usrbin_baseline.md5 --quiet

Qualquer saída do último comando significa que um binário do sistema foi modificado após sua linha de base — investigue imediatamente.

🔬 O Que Ele Detecta

Detecção de Processos Ocultos

Perfil de CPU

Análise de Rede

Mecanismos de Persistência

⚔️ Processo de Kill — Passo a Passo

Quando você executa sudo ./miner-hunter kill, esta é a sequência exata:

1. 🔥 Bloqueie IPs dos pools de mineração no firewall — regras iptables DROP aplicadas antes de matar, para que o minerador não possa se reconectar mesmo se reanimar
2. 💀 Mate o líder do grupo de threads — visa primeiro o TGID (PID do líder do grupo de threads) com SIGKILL
3. 🧹 Varra todas as threads de trabalho — mata todos os PIDs no mesmo grupo de threads em toda a faixa de PID
4. 🗑️ Remova artefatos — configurações do minerador, binários, webshells e arquivos de persistência
5. 🔄 Limpe o PM2 — remove entradas do minerador do gerenciador de processos Node.js e salva a lista
6. ✅ Verifique — reexecuta perf e verifica /proc/net/tcp para confirmar que a CPU caiu e as conexões sumiram

🛡️ Fortalecimento Pós-Incidente — O Que é Aplicado

📁 Estrutura do Projeto

security-checks/               ← raiz do repositório (branch master)
├── miner-hunter               # Ponto de entrada — é isso que você executa
├── setup.sh                   # ⚙️ Configuração inicial — execute uma vez após clonar
├── lib/
│   ├── common.sh              # Utilitários compartilhados: registro, cores, ajudantes
│   ├── detect_hidden.sh       # Detecção de processos ocultos e rootkits
│   ├── detect_cpu.sh          # Perfil de CPU via perf & /proc
│   ├── detect_network.sh      # Detecção de conexão com pool de mineração
│   ├── detect_persistence.sh  # Detecção de mecanismos de persistência
│   ├── kill_miner.sh          # Eliminação de processos e remoção de artefatos
│   └── harden.sh              # Fortalecimento pós-incidente
├── README.md
└── LICENSE

📋 Requisitos

📤 Arquivos de Saída

Cada execução produz:

🌍 Origem no Mundo Real

Esta ferramenta foi construída durante resposta a incidentes ativa contra um criptominerador que:

• Se renomeou para next para se misturar com processos Next.js em um servidor Node.js
• Usou um líder de grupo de threads renomeado para kthreadd — um nome real de thread de kernel
• Excluiu seu binário do disco enquanto permanecia em execução na memória (/proc/PID/exe → (deleted))
• Estava completamente invisível para ps, top, htop e btop
• Só pôde ser detectado via perfilamento de contador de CPU de hardware perf

📄 Licença

MIT