Em resumo: Um criptomineiro no servidor revela-se em regra por carga de CPU permanentemente elevada sem motivo reconhecível, por processos estranhos, muitas vezes sob o utilizador do servidor web, e por ligações de saída para destinos desconhecidos. Não termine o processo precipitadamente: guarde primeiro os vestígios, procure os mecanismos que o reiniciam e feche a porta de entrada. Um mineiro significa que alguém conseguiu executar código no seu servidor.
Quando a fatura do fornecedor cloud é o primeiro aviso
Muitas vezes, um criptomineiro não se nota por um alarme de segurança, mas por acaso. O site fica lento, o fornecedor de alojamento comunica um excesso de tempo de cálculo, a ventoinha do próprio centro de dados trabalha sem parar ou a faturação do fornecedor cloud sobe sem novos projetos. Para os atacantes, um mineiro é uma forma simples de ganhar dinheiro com um servidor comprometido.
Minerar significa usar a capacidade de cálculo de um sistema alheio para gerar criptomoeda. O dano parece contido, porque nenhum dado é cifrado. Isso engana: quem consegue iniciar um mineiro consegue também ler credenciais, copiar bases de dados e criar outras portas dos fundos.
Depois do PHP2Shell, a verificação compensa especialmente. As vulnerabilidades CVE-2026-109618 e CVE-2026-109619 permitem a execução de código malicioso sem autenticação. Não existem Indicators of Compromise confirmados, e um mineiro não é um sinal específico destas vulnerabilidades. Carga elevada por processos desconhecidos pertence, porém, aos indícios gerais descritos em Já fui comprometido?.
Interpretar corretamente os sinais de um criptomineiro
A carga elevada tem muitas causas inofensivas. A tabela ajuda no primeiro enquadramento:
| Observação | Explicação inofensiva possível | O que verificar |
|---|---|---|
| CPU permanentemente perto da carga total | cópia de segurança, tratamento de imagens, construção de índices | A carga é igualmente constante de noite e ao fim de semana? |
| Processo com nome de serviço do sistema | raramente | O ficheiro de programa está no caminho de sistema esperado? |
Processo sob www-data, apache ou nginx que não é PHP |
dificilmente | Quem o iniciou, a partir de que pasta? |
Programa em /tmp, /var/tmp ou /dev/shm |
dificilmente | Desde quando existe o ficheiro, a quem pertence? |
| Ligação de saída permanente para um destino desconhecido | monitorização, atualizações | O destino pertence a um serviço conhecido? |
| A carga desce assim que se autentica | raramente | Alguns programas maliciosos fazem pausa quando correm ferramentas de vigilância |
Quantas mais linhas se aplicarem, mais provável é um achado. O facto de o utilizador do servidor web sequer iniciar programas estranhos é, por si só, um forte sinal de alerta, como mostra o artigo O servidor web inicia uma shell.
Como verificar processos e ligações
Os comandos seguintes só leem. Anote o resultado e a hora antes de alterar o que quer que seja:
# Processos por consumo de CPU, com utilizador, hora de arranque e comando completo
ps -eo pid,ppid,user,lstart,%cpu,%mem,args --sort=-%cpu | head -20
# Ficheiro de programa e diretório de trabalho de um processo suspeito (inserir o PID)
sudo ls -l /proc/PID/exe /proc/PID/cwd
# Ligações de saída com processo
sudo ss -tnp state established
# Ficheiros executáveis em pastas temporárias
sudo find /tmp /var/tmp /dev/shm -type f -perm -u+x -ls 2>/dev/null
Se /proc/PID/exe apontar para um ficheiro com o aditamento (deleted), o programa foi apagado depois do arranque. É uma tentativa típica de camuflagem. O processo continua a correr e, enquanto correr, o ficheiro de programa ainda pode ser guardado através de /proc. Isso deve ser feito por alguém que saiba lidar com software malicioso; nunca execute o ficheiro.
Como percorrer sistematicamente os processos para além do mineiro descreve-o Encontrar processos suspeitos em servidores Linux.
Porque é que o mineiro volta sempre
Muitos operadores terminam o processo, alegram-se com a carga a descer e verificam no dia seguinte que tudo recomeça. Os mineiros são quase sempre instalados com um mecanismo de reinício. Locais típicos são:
- Cronjobs do utilizador do servidor web ou de todo o sistema, que verificam de poucos em poucos minutos se o mineiro está a correr e, caso contrário, o voltam a carregar.
- Serviços do sistema com nomes discretos, que arrancam no boot.
- Uma webshell no diretório web, através da qual o atacante reinicia o mineiro a qualquer momento.
- Scripts de arranque alterados ou ficheiros de perfil de utilizadores.
- Chaves SSH estranhas, com as quais o atacante volta a autenticar-se diretamente.
# Cronjobs do utilizador do servidor web e entradas de todo o sistema
sudo crontab -u www-data -l
ls -la /etc/cron.d /etc/cron.hourly /var/spool/cron 2>/dev/null
# Unidades systemd alteradas recentemente
sudo find /etc/systemd/system /lib/systemd/system -name '*.service' -newermt "2026-10-17" -ls
Só quando todos os mecanismos forem encontrados é que o servidor fica sossegado de forma duradoura. Se o atacante teve direitos de root, uma reconstrução num sistema novo é em regra mais fiável do que procurar cada esconderijo.
A ordem certa depois do achado
Um mineiro parece um aborrecimento técnico, mas é um incidente de segurança. Proceda por isso de forma ordenada:
- Guardar: copiar a lista de processos, ligações, ficheiros suspeitos e registos com soma de verificação, antes de terminar o que quer que seja.
- Conter: isolar o servidor ou bloquear ligações de saída, se for possível sem perda de dados.
- Fechar a causa: pôr o PHP num estado corrigido (8.5.12, 8.4.27, 8.3.36, 8.2.35 ou backport confirmado), reiniciar todos os workers, atualizar CMS e extensões.
- Limpar ou reconstruir: remover mineiro, mecanismos de reinício e portas dos fundos, em caso de dúvida reinstalar.
- Verificar as consequências: foi possível ler credenciais ou dados pessoais? Então esclarecer proteção de dados e, se for caso disso, obrigações de notificação.
Envolva cedo o seu fornecedor de alojamento ou cloud. Muitos fornecedores bloqueiam preventivamente servidores com carga ou tráfego de rede invulgares. Quem informa o próprio fornecedor e articula o procedimento mantém mais facilmente o controlo sobre o momento do desligamento. Pergunte nessa ocasião também pelos registos de rede e de acesso do fornecedor, porque estão fora do seu servidor e são difíceis de alterar por um atacante.
Para a administração, é importante um enquadramento breve e honesto: o próprio mineiro custa sobretudo tempo de cálculo e desempenho. A verdadeira questão é, porém, o que mais o atacante viu. Até isso estar esclarecido, o incidente não deve ser dado como resolvido, mesmo que a carga volte ao normal.
Um criptomineiro mostra que foi executado código no seu servidor. Trate todas as credenciais que estavam no servidor como possivelmente exfiltradas e renove-as depois da limpeza.
Como ajuda concretamente a PHP SOS?
- Enquadramos a carga e distinguimos entre causas inofensivas e processos estranhos.
- Guardamos processos, ficheiros e ligações antes de o mineiro ser terminado.
- Procuramos todos os mecanismos de reinício e portas dos fundos e limpamos o servidor no âmbito da remoção de malware ou reconstruímo-lo.
- Fechamos a porta de entrada, renovamos os acessos e configuramos uma vigilância de carga que assinala cedo padrões invulgares.
Perguntas frequentes
Como reconheço um criptomineiro no meu servidor?
É típica uma carga de CPU permanentemente elevada que não corresponde ao número de visitantes nem a tarefas agendadas. Acrescem processos com nomes desconhecidos ou de aparência inofensiva, muitas vezes sob o utilizador do servidor web, e ligações de saída para endereços estranhos. Uma característica isolada ainda não é prova.
Basta terminar o processo de mineração?
Não. Os mineiros são em regra reiniciados repetidamente por cronjobs, serviços do sistema ou uma webshell. Quem só termina o processo vê-o muitas vezes de volta pouco depois. Além disso, a porta de entrada por onde o mineiro chegou ao servidor continua aberta.
Um criptomineiro é inofensivo por só roubar capacidade de cálculo?
Não. Quem conseguiu instalar um mineiro conseguiu executar código no servidor. Em regra, isso significa que ficheiros de configuração, credenciais e bases de dados estavam acessíveis. O mineiro é o sintoma visível de uma intrusão.
Que causas inofensivas tem uma carga elevada do servidor?
Cópias de segurança, tratamento de imagens, construção de índices de pesquisa, crawlers agressivos ou uma extensão com defeito também podem consumir muito tempo de cálculo. Estas causas costumam poder associar-se a um processo e calendário conhecidos. Se a carga continuar sem explicação, deve verificar com mais rigor.