verificações de segurança do Linux
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,htopebtopusando técnicas de rootkit.
git clone https://gitlab.com/abdom.seada/security-checks.git
cd security-checks
sudo bash setup.sh
🔀 Branch:
master— Este kit está na branchmaster. Outros scripts de segurança podem ser adicionados em branches separadas no futuro.
⚠️ Execute
setup.shuma vez logo após clonar — pular isso é a causa nº 1 de erros.
sudo bash setup.sh
setup.sh cuida de tudo automaticamente:
| Etapa | O que faz |
|---|---|
| ✅ Permissões | chmod +x no miner-hunter e em todos os scripts lib/*.sh |
| ✅ Diretórios | Cria /var/log/miner_hunter/ e /var/lib/miner_hunter/ (apenas root, 700) |
| ✅ Dependências | Verifica perf, mpstat, iptables, fail2ban, bc, strings — instala automaticamente os que faltam |
| ✅ Autoteste | Executa ./miner-hunter --version para confirmar que tudo está configurado corretamente |
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.shcorrige todos os arquivos de uma só vez — incluindo os móduloslib/dos quais o script principal depende.
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
| Comando | Descrição | Altera o sistema? |
|---|---|---|
scan | Escaneamento completo de detecção — processos ocultos, CPU, rede, persistência | ✅ Não |
kill | Mata mineradores identificados, bloqueia IPs dos pools, remove artefatos | ⚠️ Sim |
harden | Fortalecimento pós-incidente — SSH, firewall, watchdog, linha de base de integridade | ⚠️ Sim |
full | Executa escaneamento → matar → fortalecer com prompts de confirmação entre as fases | ⚠️ Sim |
report | Exibe o relatório de escaneamento mais recente | ✅ Não |
| Opção | Descrição |
|---|---|
-d, --dry-run | Pré-visualiza todas as ações sem fazer nenhuma alteração |
-e, --evidence DIR | Salva evidências em um diretório personalizado em vez de /root/miner_evidence_* |
-h, --help | Mostra ajuda |
-v, --version | Mostra versão |
Situações do mundo real e exatamente o que executar em cada uma.
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
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:
[CRÍTICO] → prossiga para kill imediatamente[AVISO] → revise manualmente antes de agirO 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.
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á:
sshd/usr/bin (checksums MD5 — para que você possa detectar binários adulterados posteriormente)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.
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.
| Técnica | O que captura |
|---|---|
Comparação /proc vs ps | Processos invisíveis para ferramentas do espaço do usuário |
| Sequestro LD_PRELOAD | Bibliotecas compartilhadas maliciosas que interceptam libc para esconder processos |
| Rootkits de módulo de kernel | Diamorphine, Reptile, Kovid e outros rootkits conhecidos |
| Threads de kernel falsas | Mineradores se passando por [kworker], [kthreadd], [kswapd] |
| Binários de sistema modificados | ps, top, ls, ss, netstat substituídos |
| Técnica | O que captura |
|---|---|
Perfilamento PMC de hardware perf | Consumidores de CPU ocultos — rootkits não podem falsificar contadores de hardware |
Amostragem delta /proc | Contabilidade de CPU em nível de kernel diretamente por PID |
| Detecção de anomalia de CPU | Alta CPU %user sem nenhum processo visível para explicá-la |
| Técnica | O que captura |
|---|---|
Leitura direta de /proc/net/tcp | Conexões ativas — ignora ss/netstat sequestrados |
| Detecção de portas de mineração | Portas 3333, 4444, 5555, 7777, 9200, 14433, 14444, 45560 |
| Resolução de domínios de mineração | Resolve domínios conhecidos de pools e cruza com conexões ativas |
| Mapeamento soquete-para-PID | Rastreia qual processo possui cada conexão de mineração |
| Localização | O que verifica |
|---|---|
| Cron | /etc/cron*, /var/spool/cron/, todos os crontabs de usuários |
| Systemd | Todos os arquivos de unidade e timers para entradas suspeitas |
| Regras Udev | Execução acionada por hardware em eventos de dispositivo |
| PM2 | Entradas do gerenciador de processos Node.js com contagens extremas de reinicialização |
| Profiles de shell | .bashrc, .bash_profile, /etc/profile, /etc/profile.d/* |
| SSH | Todos os arquivos authorized_keys em todos os usuários |
| Webshells | Arquivos PHP dentro de diretórios de projetos Node.js |
| Configs do XMRig | config.json em locais comuns de queda de mineradores |
Quando você executa sudo ./miner-hunter kill, esta é a sequência exata:
DROP aplicadas antes de matar, para que o minerador não possa se reconectar mesmo se reanimarSIGKILLperf e verifica /proc/net/tcp para confirmar que a CPU caiu e as conexões sumiram| Ação | Detalhe |
|---|---|
| Persistência de firewall | Serviço systemd para restaurar os bloqueios de mineração iptables a cada reinicialização |
| Auditoria SSH | Verifica PermitRootLogin, PasswordAuthentication, MaxAuthTries — imprime valores recomendados |
| Verificação Fail2ban | Verifica se a jail sshd está ativa e relata IPs atualmente banidos |
| Watchdog de minerador | Cron job a cada 5 min — verifica anomalia de CPU, LD_PRELOAD, portas de mineração, webshells PHP |
Linha de base /usr/bin | Checksums MD5 de todos os binários em /usr/bin para futura detecção de adulteração |
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
| Requisito | Detalhe |
|---|---|
| SO | Linux — testado no Ubuntu 24.04 LTS, Debian 13 |
| Privilégios | Deve ser executado como root (sudo) |
| Instalado automaticamente pelo setup.sh | perf, mpstat (sysstat), bc, strings (binutils) |
| Recomendado | fail2ban — sinalizado se ausente, não instalado automaticamente |
| Obrigatório (não instalado automaticamente) | iptables — deve estar presente para as fases de kill/harden |
Cada execução produz:
| Saída | Localização | Conteúdo |
|---|---|---|
| Diretório de evidências | /root/miner_evidence_YYYYMMDD_HHMMSS/ | Binários capturados, relatórios perf, configurações do minerador |
| Arquivo de log | /var/log/miner_hunter/run_YYYYMMDD_HHMMSS.log | Log completo com timestamp da execução |
| Relatório | evidence_dir/report.txt | Resumo estruturado das descobertas com gravidades |
| Alertas do watchdog | /var/log/miner_hunter/watchdog_alerts.log | Alertas contínuos após harden |
| Linha de base de integridade | /var/lib/miner_hunter/usrbin_baseline.md5 | Checksums do /usr/bin após harden |
Esta ferramenta foi construída durante resposta a incidentes ativa contra um criptominerador que:
next para se misturar com processos Next.js em um servidor Node.jskthreadd — um nome real de thread de kernel/proc/PID/exe → (deleted))ps, top, htop e btopperfMIT