Em resumo: Os processos suspeitos em servidores Linux reconhecem-se por poucas características: ficheiro de programa apagado ou em /tmp, /dev/shm ou num diretório web, nome que imita um processo do sistema, utilizador invulgar, ligações de rede permanentes ou carga elevada sem motivo. Verifique com comandos de leitura se o ficheiro de programa pertence a um pacote instalado e guarde os achados antes de terminar o que quer que seja.
O que significa “suspeito” num processo
Num servidor web correm centenas de processos. A maioria pertence ao sistema operativo, ao servidor web, à base de dados ou ao PHP. Um atacante que conseguiu executar código através de uma vulnerabilidade como o PHP2Shell tenta não dar nas vistas entre eles. Escolhe nomes discretos e guarda programas onde o utilizador do servidor web pode escrever.
Para a verificação, ajuda conhecer o estado normal. Quem sabe que serviços devem correr num servidor, sob que utilizadores e com que carga reconhece os desvios muito mais depressa. Se faltar esse conhecimento, vale a pena usar para comparação a lista de processos de um servidor semelhante e não suspeito.
Uma característica isolada ainda não é prova. Decisivo é o conjunto. Um processo com o nome de uma thread do kernel, que corre sob www-data, foi iniciado a partir de /dev/shm e mantém uma ligação ao estrangeiro, é um caso claro. Como verificar o caso especial de uma shell sob o servidor web descreve-o Sinal de alerta: o servidor web inicia uma shell.
Primeira visão geral em cinco comandos
Todos os comandos só leem. Execute-os como root, para ver todos os processos, e guarde os resultados num ficheiro fora do diretório web.
# 1. Todos os processos com utilizador, PID do pai, hora de arranque, CPU e linha de comandos
ps -eo user,pid,ppid,lstart,%cpu,%mem,cmd --sort=-%cpu | head -40
# 2. Processos cujo ficheiro de programa foi apagado
ls -l /proc/[0-9]*/exe 2>/dev/null | grep "(deleted)"
# 3. Processos que correm a partir de diretórios temporários ou web
ls -l /proc/[0-9]*/exe 2>/dev/null | grep -E " -> (/tmp|/var/tmp|/dev/shm|/var/www)"
# 4. Processos com ligações de rede
ss -tunap
# 5. Visão geral dos processos dos utilizadores do servidor web
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx) "
Os nomes de utilizador variam consoante a distribuição e o painel; o Plesk e outros painéis executam muitas vezes o PHP sob o utilizador do respetivo cliente. Adapte a lista ao seu ambiente.
Leia os resultados com atenção à hora de arranque. Os processos que correm desde o último reinício do servidor pertencem em regra ao sistema. Os processos iniciados a meio da noite ou nos dias a seguir a 17 de outubro e que não correspondem a nenhum serviço merecem atenção. Compare também o número de processos PHP com o que a configuração dos seus pools permite; um número claramente maior de processos sob um utilizador do servidor web é um indício.
Processos suspeitos no Linux: características típicas
| Característica | Porque chama a atenção | Explicação inofensiva possível? |
|---|---|---|
| Ficheiro de programa “(deleted)” | os atacantes apagam ficheiros depois do arranque | sim, após atualizações de pacotes até ao reinício |
Local de arranque /tmp, /dev/shm, pasta de upload |
aí qualquer um ou o servidor web pode escrever | raramente |
Nome entre parênteses retos como [kworker] |
imita threads do kernel | não, se por trás houver um ficheiro de programa |
| Carga de CPU permanentemente elevada sem motivo | típica de criptomineiros | sim, em tarefas em lote ou indexação |
| Processo pai 1 e utilizador do servidor web | desligado do servidor web, continua a correr por conta própria | raramente |
| Ligação a destino desconhecido | controlo ou fuga de dados | sim, em atualizações e APIs |
As verdadeiras threads do kernel não têm ficheiro de programa; ls -l /proc/PID/exe não devolve nelas nenhum caminho. Se um processo com nome de kernel aponta para um ficheiro, está camuflado. Perante carga elevada sem motivo reconhecível, ajuda o artigo Criptomineiros no servidor web.
Contraprova: o ficheiro de programa pertence a um pacote?
Quase todos os programas legítimos num servidor provêm do gestor de pacotes. Um ficheiro de programa que não pertence a nenhum pacote não é automaticamente malicioso, mas merece uma análise atenta.
PID=12345
EXE=$(readlink /proc/$PID/exe); echo "$EXE"
dpkg -S "$EXE" # Debian/Ubuntu: a que pacote pertence o ficheiro?
rpm -qf "$EXE" # família RHEL
sha256sum /proc/$PID/exe # soma de verificação, funciona também com ficheiro apagado
tr '\0' ' ' < /proc/$PID/environ | head -c 600; echo # variáveis de ambiente
Se o ficheiro de programa estiver apagado, o sha256sum /proc/$PID/exe lê-o mesmo assim a partir do processo em execução. Esta soma de verificação pertence à documentação. Uma cópia do ficheiro só deve ser feita por alguém que saiba como a guardar em segurança.
Limites da verificação no sistema em execução
Todos os comandos acima confiam no sistema que está a verificar. Numa intrusão comum através do site, com os direitos do utilizador do servidor web, isso é aceitável. Se um atacante obteve direitos de root, pode esconder processos e falsificar resultados. Nesse caso, o servidor mostra apenas o que o atacante permite.
Os indícios disso são contradições: carga sem processo visível, ligações que a firewall vê mas o ss não, ou programas do sistema alterados. Nesses casos, a verificação pertence a uma imagem protegida. Em sistemas em execução junta-se muitas vezes uma cópia da memória principal, porque alguns programas maliciosos existem só aí e deixam quase nenhuns vestígios no disco. Esta cópia tem de ser feita antes de um reinício e exige ferramentas adequadas e experiência. Porque deve criar isto antes de uma reinstalação explica-o Preservar provas antes de reinstalar.
Não termine processos suspeitos como primeiro passo. Muitas vezes uma tarefa cron ou um serviço volta a iniciá-los e, com o processo, desaparecem da memória a linha de comandos, as ligações e o ficheiro de programa apagado.
Verificar arranques automáticos e passos seguintes
Um processo malicioso que desaparecesse após um reinício seria inútil para os atacantes. Por isso, a cada achado de processo pertence a pergunta sobre o que o inicia. Além das tarefas cron, entram sobretudo em questão serviços systemd, que um atacante com direitos de root pode criar. Chamam a atenção serviços com nomes genéricos cujo ficheiro de programa está num diretório invulgar, e ficheiros de unidade criados depois de 17 de outubro.
# Serviços em execução e ficheiros de unidade alterados recentemente
systemctl list-units --type=service --state=running --no-pager
find /etc/systemd /usr/lib/systemd /lib/systemd -type f -newerct "2026-10-17" -ls 2>/dev/null
# Está a ser injetada uma biblioteca em cada processo? O ficheiro normalmente não existe.
ls -l /etc/ld.so.preload 2>/dev/null && cat /etc/ld.so.preload
Uma entrada em /etc/ld.so.preload é rara em servidores web normais e um forte indício de manipulação com direitos de root. Como verificar por completo as tarefas agendadas descreve-o Reconhecer cronjobs escondidos como porta dos fundos.
Seguem-se depois os passos seguintes, por esta ordem:
- Guardar resultados e somas de verificação com hora.
- Procurar persistência: tarefas cron, serviços e temporizadores systemd, chaves SSH.
- Esclarecer a origem: registos a partir de 20 de outubro, novos ficheiros no diretório web.
- Isolar o servidor e planear a limpeza ou a reconstrução.
Uma visão geral de todos os indícios típicos após o PHP2Shell dá-a Já fui comprometido?.
Como ajuda concretamente a PHP SOS?
- Avaliar processos: verificamos a lista de processos, os ficheiros de programa e as ligações e enquadramos cada achado.
- Preservar com validade forense: com a perícia forense informática, guardamos memória principal e suportes de dados antes de alterar o que quer que seja.
- Encontrar persistência: procuramos mecanismos que voltam a iniciar processos maliciosos.
- Concluir: limpamos ou reconstruímos e documentamos o incidente até à conclusão.
Perguntas frequentes
Como reconheço um processo suspeito no Linux?
Características típicas são um ficheiro de programa apagado, um local de arranque em /tmp ou /dev/shm, um nome que imita um processo do sistema, um utilizador invulgar e ligações de rede permanentes. Características isoladas são indícios, várias em conjunto são uma suspeita séria.
O que significa “(deleted)” em /proc/PID/exe?
O ficheiro de programa do processo foi apagado depois do arranque. Isso acontece de forma legítima após atualizações de pacotes, até o serviço reiniciar. Em processos de pastas temporárias ou sob o utilizador do servidor web, é um comportamento típico de camuflagem.
Posso confiar no resultado do ps?
Numa intrusão comum, em geral sim. Mas se um atacante obteve direitos de root, pode manipular ferramentas e resultados. Nesse caso, uma verificação a partir do exterior, por exemplo numa imagem protegida, é mais fiável.
Devo terminar um processo suspeito com kill?
Não em primeiro lugar. Guarde primeiro a linha de comandos, o ficheiro de programa, as ligações e a hora de arranque. Um processo terminado já não revela nada, e muitas vezes uma tarefa cron ou um serviço volta a iniciá-lo de qualquer modo.