Em resumo: Quando o servidor envia spam, costuma haver uma de três causas: um script PHP introduzido ou usado indevidamente, uma caixa de correio com palavra-passe roubada ou um servidor de correio mal configurado. Guarde alguns dos e-mails em espera, leia os seus cabeçalhos e o registo de correio e, na maioria dos casos, encontrará a origem. Depois parar o envio, fechar a causa e só então pedir a remoção das listas de bloqueio.
Quando os clientes encontram as suas faturas na pasta de spam
Raramente começa com um aviso de segurança. Normalmente são clientes que já não recebem as suas propostas, ou a caixa de correio enche-se de mensagens de devolução de e-mails que nunca ninguém escreveu. Por vezes, o fornecedor de alojamento bloqueia o envio e indica como motivo tráfego de correio invulgar.
Para a empresa, isto tem depressa consequências sentidas. Se o endereço do servidor estiver numa lista de bloqueio, outros servidores de correio rejeitam também os seus e-mails verdadeiros: faturas, confirmações de encomenda, ligações de palavra-passe da loja. A reputação do domínio sofre, e o dano cresce a cada hora em que o envio continua.
O envio de spam pertence às consequências conhecidas de um comprometimento. Depois do PHP2Shell, as vulnerabilidades CVE-2026-109618 e CVE-2026-109619 com execução de código sem autenticação, é mais uma razão para olhar com mais atenção. Spam não é, porém, uma indicação específica do PHP2Shell; não existem Indicators of Compromise confirmados. Outros indícios gerais descreve-os Já fui comprometido?.
Três causas típicas quando o servidor envia spam
| Causa | Imagem típica | Onde procurar |
|---|---|---|
| Script PHP introduzido | e-mails sem autenticação, entregues localmente através do sendmail |
cabeçalhos, registo de correio do PHP, novos ficheiros PHP |
| Formulário usado indevidamente | e-mails através de um formulário de contacto ou de recomendação para destinatários estranhos | registo de acessos do formulário, cabeçalhos |
| Caixa de correio sequestrada | envio com autenticação válida no servidor de correio | registo de correio com nome de autenticação, locais de autenticação |
| Servidor de correio aberto | remetentes estranhos usam o seu servidor como reencaminhamento | configuração do servidor de correio, verificação externa |
As duas primeiras causas dizem respeito ao site, a terceira às contas de correio, a quarta à configuração do servidor. A distinção é importante, porque as contramedidas são totalmente diferentes.
Ler a fila de correio
Em servidores com Postfix, a fila mostra o que está prestes a ser enviado. Os comandos seguintes só leem:
# Mostrar o conteúdo da fila (equivale ao mailq)
postqueue -p | tail -30
# Mostrar os cabeçalhos de um e-mail individual (inserir o ID da fila da lista)
sudo postcat -q -h QUEUE-ID
# Autenticações bem-sucedidas no servidor de correio com nome de utilizador
sudo grep 'sasl_username=' /var/log/mail.log | awk -F'sasl_username=' '{print $2}' | sort | uniq -c | sort -rn | head
Os cabeçalhos revelam muitas vezes logo a origem. Se o e-mail provém de uma caixa de correio autenticada, o nome de autenticação aparece no registo de correio. Se aí se acumular uma única conta com autenticações de países estranhos, a palavra-passe dessa caixa de correio tornou-se muito provavelmente conhecida. Se, em contrapartida, o e-mail foi entregue localmente, provém em regra de um script no servidor.
Se no seu servidor correr outro servidor de correio, como o Exim, os comandos têm outros nomes, mas o princípio mantém-se: ver a fila, ler os cabeçalhos, contar as autenticações no registo. No alojamento partilhado sem acesso à shell, peça ao fornecedor por escrito um extrato do registo de correio e alguns e-mails de exemplo com cabeçalhos completos. Muitos fornecedores fornecem estas indicações a pedido, porque eles próprios têm interesse em acabar com o envio.
Guarde alguns e-mails completos antes de suspender ou esvaziar a fila. São provas para a análise posterior e para conversas com o fornecedor ou os operadores das listas de bloqueio.
Encontrar o script PHP responsável
Se o envio é feito por PHP, ajuda a configuração de correio do PHP. Segundo o manual do PHP, o mail.log regista cada chamada da função mail() com caminho completo do script, número de linha, destinatário e cabeçalhos. O mail.add_x_header escreve além disso em cada e-mail um cabeçalho X-PHP-Originating-Script com o identificador de utilizador e o nome do ficheiro.
; No php.ini ou no pool FPM, depois reiniciar todos os workers
mail.add_x_header = On
mail.log = /var/log/php/mail.log
O ficheiro de registo tem de ser gravável pelo processo PHP. O cabeçalho revela aos destinatários um nome de ficheiro; desligue-o depois da análise, se não o quiser de forma permanente.
Se como remetente aparecer um ficheiro desconhecido, por exemplo na pasta de upload ou de cache, é um indício de webshell. Como enquadrar tais ficheiros descreve-o Reconhecer e remover webshells. Se, em contrapartida, for um formulário de contacto conhecido, foi provavelmente usado indevidamente, por exemplo porque destinatários ou cabeçalhos são tirados de entradas do formulário. É um erro no código, não uma intrusão, mas tem de ser igualmente corrigido depressa.
Nem todo o spam usa a função mail(). O código malicioso também pode estabelecer diretamente uma ligação a servidores de correio alheios. Nesse caso, o envio não aparece nem na fila nem no registo de correio do PHP, mas sim como ligações de saída na porta 25. Como as verificar está em Verificar as ligações de saída de um servidor.
Parar o envio e voltar a pô-lo a funcionar de forma limpa
Depois de encontrada a origem, segue-se a limpeza por esta ordem:
- Suspender o envio: bloquear o caminho afetado, ou seja, desativar o script, bloquear a caixa de correio ou suspender a fila. Guardar os e-mails em espera como prova.
- Fechar a causa: no caso de uma webshell, 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 e limpar o site. No caso de um formulário, corrigir o código. No caso de uma caixa de correio, alterar a palavra-passe e verificar o dispositivo do utilizador.
- Procurar outros vestígios: quem envia spam através de uma webshell criou muitas vezes outras portas dos fundos.
- Limitar a saída: permitir ligações de saída na porta 25 apenas para o servidor de correio, não para o utilizador do servidor web.
- Limpar as listas de bloqueio: só agora pedir a remoção junto dos operadores das listas de bloqueio e descrever brevemente o que foi corrigido.
Aproveite a ocasião para verificar o SPF, o DKIM e o DMARC do seu domínio. Estas entradas DNS definem que servidores podem enviar em nome do seu domínio e dificultam que estranhos abusem do seu endereço de remetente.
Como ajuda concretamente a PHP SOS?
- Analisamos fila, cabeçalhos e registos de correio e apuramos se a causa é um script, um formulário, uma caixa de correio ou a configuração.
- Paramos o envio de forma controlada e guardamos provas para o fornecedor de alojamento e as listas de bloqueio.
- Limpamos o site no âmbito da remoção de malware e fechamos a porta de entrada.
- Limitamos o tráfego de correio de saída ao nível do servidor e acompanhamos a remoção das listas de bloqueio.
Perguntas frequentes
Como noto que o meu servidor envia spam?
São típicas mensagens de devolução de e-mails que ninguém escreveu, avisos do fornecedor de alojamento, uma fila de correio cheia e clientes que de repente encontram os seus e-mails na pasta de spam. Também entradas do endereço do seu servidor em listas de bloqueio públicas são um sinal claro.
Como encontro o script PHP que envia spam?
O PHP pode registar cada chamada da função mail() com o caminho do script, se mail.log estiver definido. Com mail.add_x_header, o PHP escreve ainda o nome do script no cabeçalho de cada e-mail. Em e-mails já enviados ou em espera, ajuda olhar para os cabeçalhos.
Devo esvaziar logo a fila de correio?
Não antes de ter guardado alguns e-mails como prova. Os cabeçalhos mostram muitas vezes que script ou caixa de correio desencadeou o envio. Em regra, é melhor suspender do que apagar, até a origem ser conhecida.
Como saio de novo das listas de bloqueio?
Primeiro eliminar a causa, depois pedir a remoção junto dos respetivos operadores das listas de bloqueio. A maioria exige uma explicação do que foi corrigido. Quem pede cedo demais e continua a enviar spam volta a ser listado.