# Encontrar contas de administrador estranhas no CMS e no servidor

> Encontrar contas de administrador estranhas: verificar CMS, painel de alojamento, servidor Linux e base de dados quanto a acessos desconhecidos.

Fonte: https://phpsos.de/pt/blog/fremde-admin-konten-finden/  
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:** Só encontra contas de administrador estranhas se verificar todos os níveis: o CMS ou a loja, o painel de alojamento, os utilizadores do sistema do servidor, os acessos SSH e os utilizadores da base de dados. Não confie na lista de utilizadores do backend, porque código introduzido pode esconder aí contas. Primeiro documentar e bloquear os achados, depois esclarecer a causa, só então apagar.

## Porque é que um administrador desconhecido é tão perigoso

Uma conta de administrador adicional é a porta dos fundos mais cómoda para os atacantes. Não precisa de código malicioso, não dá nas vistas nas análises de ficheiros e sobrevive a qualquer atualização. Quem mais tarde se autentica com essa conta aparece no registo como um redator normal.

Depois do PHP2Shell, esta verificação ganha peso. As vulnerabilidades CVE-2026-109618 e CVE-2026-109619 permitem a execução de código malicioso sem autenticação. Quem consegue executar código no servidor também consegue escrever na base de dados e assim criar contas. Uma atualização do PHP fecha a vulnerabilidade, mas não remove nenhuma conta que tenha surgido antes.

Para o PHP2Shell não existem Indicators of Compromise publicados e confirmados, ou seja, nenhuma lista de vestígios típicos. Uma conta desconhecida não é por isso prova do PHP2Shell, mas é um indício claro de acesso não autorizado, seja por que caminho for. Uma visão geral de outros indícios está em [Já fui comprometido?](https://phpsos.de/pt/php2shell/bin-ich-gehackt-anzeichen/).

## Onde podem estar contas de administrador estranhas

Muitos operadores olham apenas para o CMS. Os atacantes pensam em níveis, e cada nível tem contas próprias:

| Nível | Onde procurar | A que prestar atenção |
|---|---|---|
| CMS ou loja | gestão de utilizadores e tabela de utilizadores da base de dados | função de administrador, data de criação, endereço de correio estranho |
| Painel de alojamento | utilizadores, contas adicionais, contas FTP | contas que ninguém da equipa criou |
| Servidor Linux | `/etc/passwd`, grupos `sudo` ou `wheel`, sudoers | outras contas com UID 0, novas shells de login |
| SSH | `authorized_keys` de todos os utilizadores | chaves sem proprietário conhecido |
| Base de dados | tabela de utilizadores do servidor de base de dados | utilizadores com direitos globais ou host `%` |
| Serviços externos | domínio, DNS, Search Console, CDN | proprietários ou autorizados adicionais |

O nível SSH é suficientemente autónomo para um artigo próprio: [Encontrar e remover chaves SSH desconhecidas](https://phpsos.de/pt/blog/ssh-schluessel-pruefen/).

## Encontrar contas de administrador estranhas no CMS, também as escondidas

A lista de utilizadores no backend é gerada pela própria aplicação. Se código introduzido estiver a correr, pode filtrar entradas individuais. Mais fiáveis são por isso ferramentas que olham diretamente para os dados guardados. Para o WordPress, o WP-CLI lista todos os administradores com a data de criação:

```bash
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
```

Um nível mais fundo vai uma consulta de leitura à base de dados. Mostra cada conta a que está atribuída a função de administrador, independentemente do que a interface apresente. O prefixo de tabela `wp_` adapte-o à sua instalação:

```sql
SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%administrator%'
ORDER BY u.user_registered DESC;
```

Compare os resultados do backend, do WP-CLI e da base de dados. Se uma conta só aparecer na base de dados, é um forte sinal de alerta, porque então há também código a esconder-se. Para outros sistemas como Shopware, TYPO3 ou Joomla vale o mesmo princípio: consultar diretamente a tabela de utilizadores e comparar com a apresentação no backend. Que tabelas são, consta da documentação do fabricante.

## Verificar utilizadores do sistema e da base de dados

No próprio servidor interessam sobretudo contas com direitos de root e contas que se podem autenticar. Os comandos seguintes só leem:

```bash
# Contas com UID 0 (normalmente apenas root)
awk -F: '$3 == 0 {print $1}' /etc/passwd

# Contas com uma shell de login verdadeira
grep -vE '(nologin|false)$' /etc/passwd

# Membros dos grupos de administração
getent group sudo wheel

# Regras sudo adicionais
sudo ls -la /etc/sudoers.d/
sudo grep -rvE '^\s*(#|$)' /etc/sudoers /etc/sudoers.d/

# Últimas autenticações com data completa
last -F | head -30
```

No servidor de base de dados, verifique que utilizadores existem e que direitos têm:

```sql
SELECT user, host FROM mysql.user ORDER BY user;
SHOW GRANTS FOR 'anwendung'@'localhost';
```

Uma aplicação precisa em regra de um utilizador com direitos sobre exatamente uma base de dados. Um utilizador adicional com direitos globais, que possa aceder a partir de quaisquer hosts (`%`), tem de ser esclarecido.

Não se esqueça das contas fora do servidor. Quem tem acesso ao contrato do domínio ou à gestão de DNS pode redirecionar visitantes ou mandar emitir certificados para servidores estranhos. Um proprietário adicional no Google Search Console pode submeter sitemaps e alterar definições. Por isso, percorra no registador, no fornecedor de DNS, na CDN e no Search Console a lista dos autorizados e compare-a com o que a sua equipa conhece.

## Como lidar bem com um achado

O primeiro impulso é apagar logo a conta estranha. Mas com ela desaparece também um vestígio importante: a data de criação delimita muitas vezes quando o atacante esteve no sistema. É melhor esta ordem:

1. **Documentar:** registar nome de utilizador, ID, e-mail, data de criação, função e última atividade com hora, de preferência como captura de ecrã e exportação.
2. **Bloquear em vez de apagar:** retirar a função, substituir a palavra-passe por um valor aleatório ou desativar a conta.
3. **Delimitar o período:** verificar os registos em torno da data de criação. Que pedidos houve pouco antes, que ficheiros mudaram?
4. **Verificar outros níveis:** quem cria uma conta raramente deixa só uma. Examine também ficheiros, cronjobs, chaves SSH e base de dados.
5. **Limpar e renovar os acessos:** só depois da limpeza e da atualização do PHP renovar todas as palavras-passe, chaves e sessões.

Uma nota de cautela: nem toda a conta desconhecida é maliciosa. Agências, prestadores anteriores ou plugins de manutenção criam por vezes contas próprias. Esclareça isso antes de dar o alarme, mas esclareça-o em tempo útil.

## Evitar o regresso

Depois da limpeza, as contas de administrador devem ser a exceção, não a regra. Resultaram bem contas pessoais em vez de acessos partilhados, o menor número possível de administradores e uma [autenticação de dois fatores para acessos de administração](https://phpsos.de/pt/ratgeber/zwei-faktor-admin/). Defina além disso quem pode criar novas contas de administrador e onde isso fica documentado.

Uma consulta regular como as acima, por exemplo semanal e com comparação com a semana anterior, torna rapidamente visíveis contas novas. No WordPress ajuda ainda o guia [Encontrar backdoors no WordPress](https://phpsos.de/pt/ratgeber/backdoor-wordpress-finden/).

## Como ajuda concretamente a PHP SOS?

- Verificamos todos os níveis de contas, do CMS ao servidor e à base de dados, e comparamos a apresentação do backend com os dados guardados.
- Guardamos os achados com carimbos de data/hora antes de as contas serem bloqueadas ou removidas.
- No âmbito da [resposta a incidentes](https://phpsos.de/pt/leistungen/incident-response/), esclarecemos como a conta surgiu e se existem outras portas dos fundos.
- Renovamos os acessos pela ordem certa e configuramos um controlo contínuo de novas contas de administrador.


## Perguntas frequentes

**Devo apagar logo uma conta de administrador desconhecida?**  
É melhor não apagar logo. Documente primeiro nome de utilizador, data de criação, endereço de e-mail e última atividade e bloqueie a conta. Só se apaga depois de os vestígios estarem guardados, porque a data de criação é muitas vezes uma indicação importante do momento da intrusão.

**Uma conta de administrador pode estar invisível no backend?**  
Sim. Código introduzido pode ocultar contas individuais da lista de utilizadores da interface. Uma consulta direta à base de dados ou uma ferramenta de linha de comandos mostra, em contrapartida, todas as contas guardadas. Por isso não deve olhar apenas no backend.

**Que níveis tenho de verificar além do CMS?**  
Painel de alojamento, acessos FTP e SFTP, utilizadores do sistema do servidor incluindo direitos sudo, chaves SSH, utilizadores da base de dados e contas junto do domínio, DNS e Search Console. Um atacante só precisa de uma destas portas para regressar.

**Basta mudar todas as palavras-passe depois do achado?**  
Não. Uma conta estranha mostra que alguém teve acesso. Então é preciso esclarecer também o ponto de entrada, outras portas dos fundos e possíveis fugas de dados. Altere as palavras-passe só depois da limpeza e a partir de um dispositivo limpo.

## Fontes

- [WordPress](https://wordpress.org/)
- [php.net: avisos de segurança](https://www.php.net/)
- [BSI: indicações sobre incidentes de segurança informática](https://www.bsi.bund.de/)