# Varrimentos em massa à procura de PHP sem patch: como decorrem os ataques automatizados

> Ataques automatizados a servidores web: como decorrem os varrimentos em massa à procura de PHP sem patch, porque as PME são alvo e o que fazer.

Fonte: https://phpsos.de/pt/blog/automatisierte-massenscans/  
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 ataques automatizados a servidores web decorrem em vagas: programas varrem a Internet à procura de servidores acessíveis, classificam-nos com base em características externas e experimentam em massa vulnerabilidades conhecidas como o PHP2Shell. O tamanho da empresa não desempenha qualquer papel. Oferecem proteção um PHP com patch, uma superfície de ataque pequena e uma monitorização que note depressa os acertos bem-sucedidos.

## O ponto de partida: “Quem se interessaria pelo nosso site?”

Esta pergunta ouvimo-la muitas vezes depois do PHP2Shell, sobretudo de empresas mais pequenas. A resposta honesta: provavelmente ninguém pessoalmente. Mas, em vulnerabilidades deste tipo, isso também não é necessário. Os ataques são executados por programas que não procuram nomes, mas oportunidades.

O BSI (Gabinete Federal Alemão para a Segurança da Informação) contava, no PHP2Shell, com uma exploração rápida e em larga escala. A Cloudflare relatou tentativas de ataque e que os atacantes alteravam os seus padrões para contornar regras de proteção. Ambas as coisas condizem com o que acontece regularmente em vulnerabilidades críticas em software muito difundido.

## Como decorrem os ataques automatizados a servidores web

As campanhas automatizadas seguem em geral um padrão semelhante. O resumo seguinte descreve as fases em termos gerais, sem pormenores de ataque:

| Fase | O que acontece | O que ajuda contra isso |
|---|---|---|
| Procurar | Programas verificam grandes intervalos de endereços ou diretórios públicos, como registos de certificados, à procura de servidores web acessíveis | poucos sistemas acessíveis ao público, inventário de todos os endereços |
| Classificar | As respostas são analisadas: servidor web, versão do PHP, CMS, caminhos típicos | ocultar indicações de versão, remover ficheiros desnecessários |
| Experimentar | Vulnerabilidades conhecidas são testadas em massa, muitas vezes sem classificação prévia | PHP atualizado, reinício, WAF como camada adicional |
| Fixar-se | Em caso de sucesso, é deixada uma porta traseira, por exemplo uma webshell ou uma tarefa cron | permissões de escrita restritas, sem execução de PHP em pastas de uploads |
| Aproveitar | O servidor é usado, por exemplo, para spam, criptomineração, redirecionamentos ou roubo de dados | monitorização de processos, ficheiros e ligações de saída |

Importante é a terceira linha. Muitas campanhas nem sequer se dão ao trabalho de classificar os servidores com precisão antes. Experimentam simplesmente tudo o que é acessível. Por isso, a discrição por si só não protege.

### Porque é que os ataques vêm em vagas

As campanhas automatizadas raramente decorrem uma vez e nunca mais. É típico um padrão em vagas. A primeira vaga segue-se logo após a divulgação de uma vulnerabilidade, muitas vezes ainda com ferramentas pouco maduras. Vêm mais vagas quando os atacantes melhoram as suas ferramentas ou as adaptam às regras de proteção. A Cloudflare observou exatamente isso no PHP2Shell: padrões de ataque alterados para contornar as regras.

Para si, isto significa: um servidor que atravessou a primeira vaga sem danos não está seguro de forma duradoura enquanto não tiver o patch. E um servidor acabado de montar passa a ser alvo a partir do momento em que está acessível. Quem, por exemplo, manda emitir um novo certificado TLS torna o nome visível em registos públicos de certificados, que também os scanners analisam. Um sistema novo só deve, por isso, ir para a rede quando já estiver atualizado.

## Porque é que as pequenas empresas são igualmente afetadas

Para os ataques automatizados não conta o valor de um alvo individual, mas a quantidade. O servidor de uma pequena empresa oferece capacidade de cálculo, um domínio com boa reputação, um envio de correio e, por vezes, dados de clientes. Para os atacantes, isso é suficiente.

Acresce: as empresas mais pequenas não têm muitas vezes uma TI própria que aplique as atualizações de imediato. Os seus servidores permanecem vulneráveis durante mais tempo e acabam por isso com mais frequência nas listas de resultados dos scanners. Quem aplica o patch primeiro sai dessas listas.

Outro ponto é a cadeia de fornecimento. Muitos sites pequenos estão em servidores de agências ou de pequenos fornecedores de alojamento, nos quais correm dezenas de projetos de clientes lado a lado. Para os atacantes, um servidor destes é particularmente compensador, porque um único acerto afeta muitos sites em simultâneo. O seu risco depende então não só da sua própria diligência, mas também da do seu prestador de serviços.

> **Importante:**
> Varrimentos nos seus registos são normais e não são prova de uma intrusão. Um ataque bem-sucedido revela-se por outros vestígios: novos ficheiros, processos estranhos, contas desconhecidas, ligações de saída invulgares.

## O que pode verificar por si próprio

Uma olhadela aos registos mostra com que intensidade o seu servidor é varrido. Os comandos seguintes apenas leem e não alteram nada:

```bash
# Os dez endereços com mais pedidos no registo de acessos atual
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10

# Pedidos respondidos com "não encontrado", por frequência
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

# O servidor revela a sua versão do PHP no cabeçalho?
curl -sI https://www.example.de/ | grep -i "x-powered-by"
```

Muitos pedidos a caminhos inexistentes são o típico ruído de varrimentos. Deve ficar mais atento se, a esses pedidos, se seguirem de repente respostas bem-sucedidas, se em pastas de uploads forem chamados ficheiros que não conhece ou se o utilizador do servidor web iniciar processos que de outro modo nunca inicia. Indicadores de deteção confirmados especificamente para o PHP2Shell não existem até agora; a avaliação assenta, por isso, nestes comportamentos invulgares. Como analisar os registos com mais profundidade é descrito no guia [Analisar registos do servidor web](https://phpsos.de/pt/ratgeber/logfiles-auswerten/). Se a terceira consulta mostrar uma versão do PHP, vale a pena a definição `expose_php = Off`; os antecedentes encontram-se em [Ocultar indicações de versão](https://phpsos.de/pt/blog/expose-php-versionsangaben/).

## As camadas de proteção pela ordem certa

1. **Atualizar o PHP e reiniciar:** Sem este passo, todas as outras medidas ficam remendos.
2. **Reduzir a superfície de ataque:** desligar sites não utilizados, sistemas de teste e microsites antigos ou colocá-los atrás de uma autenticação.
3. **Regras na periferia:** Uma Web Application Firewall com um conjunto de regras mantido, por exemplo o [OWASP Core Rule Set com ModSecurity](https://phpsos.de/pt/blog/modsecurity-owasp-crs/), trava uma parte das tentativas.
4. **Travar tentativas repetidas:** Ferramentas como o [Fail2ban](https://phpsos.de/pt/blog/fail2ban-fuer-webserver/) bloqueiam endereços que geram um número invulgar de erros. Contra varrimentos distribuídos, isto ajuda apenas de forma limitada.
5. **Monitorizar:** Manter debaixo de olho os processos do utilizador do servidor web, os novos ficheiros PHP e as ligações de saída, para que um acerto bem-sucedido não passe semanas despercebido.

## Como ajuda concretamente a PHP SOS?

- **Levantar a superfície de ataque:** Apuramos quais dos seus sistemas são acessíveis do exterior e o que revelam sobre si.
- **Aplicar patches e reforçar:** Atualizamos o PHP, reiniciamos e reduzimos indicações de versão, permissões de escrita e serviços desnecessários.
- **Regras e bloqueios:** Configuramos regras WAF e mecanismos de bloqueio adequados à sua aplicação.
- **Monitorização contínua:** Comunicamos processos, ficheiros e ligações invulgares antes de um acerto se tornar um incidente.

Como é isso em funcionamento contínuo é descrito em [Monitorização de segurança para servidores web](https://phpsos.de/pt/leistungen/security-monitoring/).

## Conclusão

Os ataques automatizados não perguntam a quem pertence um servidor. Perguntam apenas se é vulnerável. A melhor resposta a isso é pouco espetacular: aplicar o patch depressa, oferecer pouco, olhar com atenção. Quem o faz continua a ser varrido, mas deixa de ser encontrado.


## Perguntas frequentes

**As pequenas empresas são alvo de ataques automatizados?**  
Sim. Os varrimentos automatizados verificam servidores acessíveis sem olhar a quem os opera. Se por trás está um grupo empresarial ou uma oficina, é indiferente para o software. O decisivo é se o servidor parece vulnerável.

**Como reconheço varrimentos nos meus registos?**  
Típicos são muitos pedidos a caminhos que nem existem no seu site, muitas vezes de endereços variáveis e com identificações invulgares. Tais entradas são normais e não são ainda prova de um ataque bem-sucedido, mas mostram que o seu servidor está a ser verificado.

**Ajuda ocultar a versão do PHP?**  
Torna um pouco mais difícil aos scanners classificar o seu servidor de forma direcionada e é uma boa definição de base. Não protege, porém, de ataques que experimentam simplesmente todos os servidores. A atualização continua a ser obrigatória.

**Posso impedir completamente os varrimentos?**  
Não. Todo o servidor acessível ao público é varrido regularmente. O objetivo não é impedir varrimentos, mas garantir que não encontram nada: software atualizado, pouca superfície de ataque e uma monitorização que comunique anomalias.

## Fontes

- [Cloudflare-Blog: Cloudflare deploys protections against php2shell vulnerability](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/)
- [Manual do PHP](https://www.php.net/manual/de/)
- [OWASP ModSecurity Core Rule Set](https://coreruleset.org/)
- [BSI: Gabinete Federal Alemão para a Segurança da Informação](https://www.bsi.bund.de/)