Reconhecer cronjobs escondidos como porta dos fundos

Em resumo: Um cronjob escondido é uma das portas dos fundos mais frequentes em servidores Linux: carrega código malicioso regularmente ou reinicia processos, mesmo depois de uma atualização do PHP. Verifique todos os locais de tarefas agendadas, não só o crontab -l: crontabs de todos os utilizadores, /etc/crontab, /etc/cron.d, as pastas cron, temporizadores systemd e trabalhos at. Guarde os achados antes de os remover.

Porque é que os cronjobs são tão apreciados como porta dos fundos

Depois de uma intrusão bem-sucedida, um atacante tem um problema: o seu acesso é frágil. Uma atualização fecha a vulnerabilidade, um administrador apaga a webshell, um reinício termina o processo. Um cronjob resolve este problema. Inicia comandos a horas fixas, sem que ninguém intervenha, e restabelece assim acessos perdidos.

Para o PHP2Shell não existem Indicators of Compromise confirmados. Os novos cronjobs estão, porém, segundo os relatos de que dispomos, entre os sinais de alerta gerais após intrusões através de aplicações web. Quem já procurou webshells deve verificar logo também as tarefas agendadas. Os restantes passos de um pós-tratamento são indicados pela lista de controlo após uma intrusão.

Onde se podem esconder tarefas agendadas

O Linux conhece vários mecanismos para tarefas agendadas. Muitas verificações falham porque só se olha para um deles.

Importante para servidores web: o utilizador do servidor web pode em regra criar o seu próprio crontab, sem direitos de root. Um atacante com os direitos de www-data não precisa por isso de nenhuma outra vulnerabilidade para isso. Entradas em /etc/cron.d ou unidades systemd indicam, em contrapartida, que obteve direitos de root.

Os painéis de alojamento como o Plesk ou o cPanel oferecem uma interface própria para tarefas agendadas. Por trás estão, em regra, também crontabs dos respetivos utilizadores do sistema. Quem só olha para a interface não reconhece por isso todas as entradas que foram criadas diretamente no servidor. Em caso de dúvida, verifique ambos.

Como verificar todos os locais por completo

Os comandos seguintes só leem. Execute-os como root e guarde os resultados com data.

# Mostrar os crontabs de todos os utilizadores
for u in $(cut -d: -f1 /etc/passwd); do
  out=$(crontab -l -u "$u" 2>/dev/null) && printf '### %s\n%s\n' "$u" "$out"
done

# Entradas de todo o sistema e horas de alteração
cat /etc/crontab
ls -la --time-style=full-iso /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/cron.weekly /etc/cron.monthly

# Temporizadores systemd e trabalhos at
systemctl list-timers --all
atq 2>/dev/null

# Procurar padrões típicos em todos os ficheiros cron
grep -rnE "curl|wget|base64|/tmp/|/dev/shm|\| *(ba)?sh" /etc/crontab /etc/cron.* /var/spool/cron 2>/dev/null

Dois truques merecem especial atenção. Algumas entradas escondem comandos atrás de muitos espaços, de modo que saem do ecrã à direita no editor. Outras usam carateres de controlo que, na apresentação, sobrescrevem texto. Com cat -A esses carateres tornam-se visíveis:

cat -A /var/spool/cron/crontabs/www-data 2>/dev/null | less

Uma segunda perspetiva são os registos do serviço cron. Em muitos sistemas, o cron regista cada execução com utilizador e comando. Assim vê também entradas que um atacante entretanto removeu e reconhece desde quando corre um comando suspeito:

# Comandos cron executados pelo utilizador do servidor web (Debian/Ubuntu ou journal do systemd)
grep -h "CRON" /var/log/syslog* 2>/dev/null | grep -E "\((www-data|apache|nginx)\) CMD"
journalctl -u cron -u crond --since "2026-10-17" --no-pager 2>/dev/null | grep CMD | head -100

Como reconhece uma porta dos fundos em cronjob

1. Carregar da Internet: um download cujo resultado é entregue diretamente a uma shell.
2. Conteúdos codificados: cadeias de caracteres longas que só são descodificadas em tempo de execução.
3. Caminhos invulgares: programas em /tmp, /dev/shm, pastas escondidas ou diretórios de upload.
4. Utilizador errado: tarefas sob o utilizador do servidor web, embora a aplicação não precise de nenhuma.
5. Cadência invulgar: execução a cada minuto ou em cada reinício através de @reboot.
6. Carimbos de data/hora desajustados: ficheiro alterado num período em que ninguém trabalhou no servidor, por exemplo depois de 17 de outubro.

Não esqueça: também as aplicações têm calendários próprios. O WordPress, por exemplo, gere tarefas agendadas na base de dados. Como verificar aí descreve-o Encontrar backdoors no WordPress.

Guardar o achado, compreendê-lo, depois removê-lo

Um cronjob malicioso é uma peça de prova valiosa. Mostra o endereço de download, o momento da sua criação e muitas vezes o utilizador através do qual o atacante entrou. Guarde o ficheiro com soma de verificação e carimbos de data/hora antes de o remover. O carimbo ajuda mais tarde a reconstituir o decorrer; como se faz mostra-o Elaborar a cronologia de um incidente. Também para uma eventual notificação à autoridade de proteção de dados ou para a seguradora, o achado é uma prova importante de desde quando um atacante teve acesso.

Remover não basta. Se ainda correr um processo que reescreve a entrada, ela está de volta ao minuto seguinte. E enquanto a vulnerabilidade original estiver aberta, o atacante pode recomeçar a qualquer momento. A ordem é por isso: guardar, fechar a causa, remover todos os componentes, mudar os acessos, vigiar.

Proteger os cronjobs preventivamente

Para que uma porta dos fundos em cronjob nem sequer possa surgir ou salte logo à vista, ajudam três medidas. Primeiro, pode definir-se que utilizadores podem sequer criar um crontab. Se existir o ficheiro /etc/cron.allow, só os utilizadores aí indicados podem usar o crontab. Se a sua aplicação não precisar de cronjob sob o utilizador do servidor web, esse utilizador não pertence à lista. Verifique antes que tarefas a aplicação realmente precisa e crie-as deliberadamente sob um utilizador próprio.

Em segundo lugar, vale a pena vigiar os ficheiros. Uma ferramenta de verificação de integridade avisa assim que um ficheiro nos diretórios cron ou em /var/spool/cron se altera. Em terceiro lugar, as tarefas agendadas pertencem à documentação do servidor: quem sabe que entradas devem existir reconhece logo uma estranha.

Como ajuda concretamente a PHP SOS?

• Verificar por completo: examinamos todos os mecanismos de tarefas agendadas, incluindo temporizadores systemd, trabalhos at e calendários de aplicações.
• Enquadrar achados: avaliamos entradas suspeitas sem as executar e derivamos outros vestígios.
• Limpar de forma limpa: com a remoção de malware, removemos todos os componentes e fechamos a causa.
• Reconhecer o regresso: configuramos uma vigilância que assinala tarefas agendadas novas ou alteradas.

Perguntas frequentes

Fontes

• BSI: Agência Federal Alemã para a Segurança da Informação
• BSI IT-Grundschutz
• OWASP Cheat Sheet Series