# Agência: sites de clientes hackeados? Ligue-nos. Nós ajudamos.

> Vários sites de clientes da sua agência afetados? Ligue ou escreva-nos por WhatsApp. Preservamos, limpamos e documentamos tudo remotamente.

Fonte: https://phpsos.de/pt/soforthilfe/agentur-kundenseiten-gehackt/  
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:** se vários sites de clientes da sua agência estão afetados, raramente é acaso; trata-se, na maioria das vezes, de um servidor partilhado, de um acesso partilhado ou da mesma versão do PHP. Se está afetado, contacte-nos de imediato. Damos-lhe uma panorâmica, contemos o incidente remotamente, limpamos os sistemas e entregamos-lhe relatórios para os seus clientes.

> **Agir de imediato:**
> **Não apague nada nem reinstale nada agora.** Mesmo que a pressão dos clientes seja grande: sem registos e ficheiros preservados, não se consegue esclarecer a causa nem provar o que não foi afetado. [Comunicar uma emergência](https://phpsos.de/pt/notfall/), e assumimos o caso desde a primeira mensagem.

## Está afetado? Sinais quando sites de clientes foram hackeados

Enquanto agência, vê padrões que os operadores individuais nunca notam. Apontam para um incidente comum:

- Vários sites de clientes mostram ao mesmo tempo os mesmos sintomas: redirecionamentos, conteúdos de spam, avisos no navegador.
- A mesma conta de administrador desconhecida ou o mesmo ficheiro suspeito aparece em clientes diferentes.
- O fornecedor de alojamento comunica abuso ou carga invulgar numa conta em que estão muitos projetos.
- Clientes telefonam porque o seu site é alvo de aviso na Google, e, numa verificação cruzada, encontra outros sites no mesmo estado.
- Um programador ou ex-colaborador tinha acesso a muitos projetos, e um acesso foi extraviado.
- Trabalhos de manutenção através de uma ferramenta central, por exemplo deployment, cópias de segurança ou um serviço de atualização, alteraram um site em que não tocou.
- Gere muitos sites em versões do PHP cujo nível de patch não consegue comprovar para cada uma.

Desde o PHP2Shell, acresce que a vulnerabilidade está no próprio interpretador PHP. Uma atualização do CMS, por exemplo do WordPress, não a fecha; o decisivo é o ambiente de execução PHP que realmente serve os sites.

## O que fazer já

1. **Listar os sites afetados:** domínio, servidor, conta de alojamento, versão do PHP, CMS, responsáveis. Os casos suspeitos também entram.
2. **Procurar pontos em comum:** mesmo servidor? Mesmos acessos? Mesmo plugin? Mesmo caminho de deployment?
3. **Isolar os sites em risco:** pôr em modo de manutenção os sites que entregam ativamente código malicioso. Não apagar.
4. **Mandar preservar registos e estado:** pedir ao fornecedor de alojamento que conserve os registos; preservar os registos de deployment próprios.
5. **Verificar os acessos centrais:** quem tem acesso ao painel de alojamento, ao SSH, ao Git, ao gestor de palavras-passe e ao deployment? Alterações só depois de acordo.
6. **Informar os clientes com contenção:** primeiro apenas o que está comprovado. Não indicar uma causa antes de ela estar apurada.
7. **Contactar-nos:** ligue ou escreva-nos por WhatsApp.

## Como ajuda concretamente a PHP SOS?

1. **Levantar a situação:** fazemos consigo uma panorâmica de todos os sites e servidores e ordenamo-los por urgência: código malicioso entregue ativamente, suspeita de fuga de dados, provavelmente apenas sem patch.
2. **Preservar e fechar:** preservamos cada sistema afetado antes de alterar o que quer que seja e fechamos a porta de entrada comum: acessos, nível do PHP, reinício de todos os processos.
3. **Verificar e limpar:** procuramos sistematicamente em todos os sites os mesmos vestígios, removemos webshells e backdoors e restauramos de forma limpa. Pormenores em [Remoção de malware e webshells](https://phpsos.de/pt/leistungen/malware-entfernung/).
4. **Reforçar e relatar:** separamos os sites uns dos outros onde fizer sentido e entregamos, por cliente, um breve relatório que pode transmitir, bem como um relatório global para si.

Trabalhamos remotamente, sem deslocações, em toda a Alemanha e na Europa. Se desejar, em segundo plano para a sua agência, como descrito na página [Agências e white label](https://phpsos.de/pt/branchen/agenturen-white-label/).

## Porque é que nas agências caem muitas vezes vários sites ao mesmo tempo

Quem gere muitos projetos num servidor poupa custos, mas troca isolamento por comodidade. Se tudo corre sob o mesmo utilizador e o mesmo pool de processos PHP, o código de um site hackeado pode ler e alterar os ficheiros dos vizinhos. Não é um caso exótico, mas o padrão em muitas configurações. Como separar corretamente os pools, descreve-o [Isolar pools PHP-FPM](https://phpsos.de/pt/blog/php-fpm-pools-isolieren/).

A isto juntam-se os acessos partilhados: uma chave SSH para todos os projetos, uma conta de alojamento com todos os domínios, as mesmas palavras-passe para staging e produção. Aqui vale o princípio dos privilégios mínimos. Mais sobre isto em [Direitos do utilizador do servidor web](https://phpsos.de/pt/blog/rechte-des-webserver-benutzers/).

Também conta a cadeia de fornecimento: plugins, temas e bibliotecas vêm de terceiros, o fornecedor de alojamento responde pela plataforma, a agência pela operação. Onde passam esses limites e onde surgem lacunas, trata-o [Cadeia de fornecimento: agência e fornecedor de alojamento](https://phpsos.de/pt/blog/lieferkette-agentur-hoster/).

## Inventário, versões do PHP e comunicação com os clientes

O problema mais frequente nestas situações é a falta de panorâmica: que site corre em que servidor com que versão do PHP, e quem é responsável? Sem esta lista, não se consegue dizer quem é afetado pelo patch e quem não é. Como construir um tal registo, mostra-o [Inventário de sites e servidores](https://phpsos.de/pt/blog/inventar-websites-server/). Se várias versões do PHP correm em paralelo, ajuda ainda [Várias versões do PHP num servidor](https://phpsos.de/pt/blog/mehrere-php-versionen-server/).

Perante os clientes conta a clareza. Não tem de saber tudo, mas não deve embelezar nada: o que está comprovado, o que ainda está a ser verificado, o que faz a seguir? Encontra ajuda para a redação em [Informar os clientes após um incidente](https://phpsos.de/pt/blog/kunden-nach-vorfall-informieren/). Se dados pessoais estiverem afetados, podem ser relevantes deveres de notificação nos termos do Art. 33 do RGPD. Trata-se de uma informação geral; a avaliação cabe aos encarregados da proteção de dados e ao advogado. Se o incidente se alargar para além de sites individuais, passamos a uma [resposta a incidentes](https://phpsos.de/pt/leistungen/incident-response/) estruturada.

## O que nos deve enviar

- uma lista dos domínios afetados e dos presumivelmente afetados
- informações sobre o servidor e o alojamento por projeto, na medida do conhecido
- versões do PHP e CMS ou lojas em uso
- os acessos que nos pode conceder e as funções na equipa
- indicações sobre o que foi alterado ou publicado por último
- nome do interlocutor para decisões e para a comunicação com os clientes

## Porquê a PHP SOS

Trabalhamos com qualidade Made in Germany e, há mais de 25 anos, estamos especializados em segurança informática com a nossa rede de parceiros de profissionais de cibersegurança. Tem um interlocutor para todos os projetos afetados, trabalhamos remotamente e documentamos, por sistema, o que foi encontrado e feito. Não prometemos milagres. O que não se consegue comprovar, designamo-lo como desconhecido, para que perante os seus clientes não diga mais do que sabe.

## Está afetado? Ligue-nos. Nós ajudamos.

Se vários dos sites dos seus clientes apresentam anomalias, a pressão do tempo é dupla: técnica e na relação com os seus clientes. Contacte-nos agora: ligue ou escreva-nos por WhatsApp. Assumimos o caso desde a primeira mensagem e ficamos até o incidente estar encerrado e documentado. [Comunicar já uma emergência](https://phpsos.de/pt/notfall/)


## Perguntas frequentes

**Porque é que muitas vezes vários sites de clientes são afetados ao mesmo tempo?**  
Com frequência, os sites partilham um servidor, uma conta de alojamento, o mesmo processo PHP ou as mesmas credenciais. Se um atacante entra num ponto, pode mover-se lateralmente. Um PHP vulnerável afeta, além disso, todos os sites que o utilizam.

**Devo informar os clientes de imediato?**  
Depende da situação e do contrato. Esclareça primeiro que sites estão realmente afetados, para não informar com suposições. Havendo dados pessoais, são possíveis deveres de notificação; o enquadramento cabe aos encarregados da proteção de dados ou ao advogado.

**Quem responde se o site de um cliente foi hackeado?**  
Depende dos seus contratos, do âmbito do acompanhamento e do que se passou. Não prestamos aconselhamento jurídico sobre isso. Um relatório rigoroso sobre a causa e as medidas ajuda nesse esclarecimento.

**Podem trabalhar em nome da nossa agência, sem que o cliente final nos veja?**  
Se desejar, trabalhamos em segundo plano para a sua agência e entregamos relatórios que pode transmitir aos seus clientes. Os pormenores discutimo-los antecipadamente.

**Basta limpar os sites dos clientes um a um?**  
Na maioria das vezes, não. Se a causa estiver no servidor partilhado, num acesso partilhado ou numa versão do PHP sem patch, os problemas reaparecem depois da limpeza individual. A causa tem de ser resolvida também.

## Fontes

- [BSI: Gabinete Federal Alemão para a Segurança da Informação](https://www.bsi.bund.de/)
- [RGPD Art. 33: notificação à autoridade de controlo](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [php.net: avisos e atualizações de segurança](https://www.php.net/)
