# Criptomineiro no servidor web: sinais e como proceder

> Reconhecer um criptomineiro no servidor: verificar carga permanente, processos estranhos, ligações e mecanismos de reinício, guardar vestígios e fechar a causa.

Fonte: https://phpsos.de/pt/blog/kryptominer-auf-dem-server/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**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?](https://phpsos.de/pt/php2shell/bin-ich-gehackt-anzeichen/).

## 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](https://phpsos.de/pt/blog/webserver-startet-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:

```bash
# 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](https://phpsos.de/pt/blog/verdaechtige-prozesse-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:

1. **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.
2. **Serviços do sistema** com nomes discretos, que arrancam no boot.
3. **Uma webshell** no diretório web, através da qual o atacante reinicia o mineiro a qualquer momento.
4. **Scripts de arranque alterados** ou ficheiros de perfil de utilizadores.
5. **Chaves SSH estranhas**, com as quais o atacante volta a autenticar-se diretamente.

```bash
# 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.

> **Importante:**
> 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](https://phpsos.de/pt/leistungen/malware-entfernung/) 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.

## Fontes

- [BSI: indicações sobre incidentes de segurança informática](https://www.bsi.bund.de/)
- [php.net: avisos de segurança](https://www.php.net/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)