# Encontrar processos suspeitos em servidores Linux

> Encontrar processos suspeitos no Linux: reconhecer ficheiros apagados, nomes de camuflagem e locais de arranque, associar ao pacote e guardar vestígios.

Fonte: https://phpsos.de/pt/blog/verdaechtige-prozesse-linux/  
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:** 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](https://phpsos.de/pt/blog/webserver-startet-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.

```bash
# 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](https://phpsos.de/pt/blog/kryptominer-auf-dem-server/).

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

```bash
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](https://phpsos.de/pt/blog/beweise-sichern-vor-neuinstallation/).

> **Importante:**
> 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.

```bash
# 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](https://phpsos.de/pt/blog/cronjobs-als-hintertuer/).

Seguem-se depois os passos seguintes, por esta ordem:

1. Guardar resultados e somas de verificação com hora.
2. Procurar persistência: tarefas cron, serviços e temporizadores systemd, chaves SSH.
3. Esclarecer a origem: registos a partir de 20 de outubro, novos ficheiros no diretório web.
4. 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?](https://phpsos.de/pt/php2shell/bin-ich-gehackt-anzeichen/).

## 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](https://phpsos.de/pt/leistungen/it-forensik/), 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.

## Fontes

- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI: Agência Federal Alemã para a Segurança da Informação](https://www.bsi.bund.de/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)