Encontrar contas de administrador estranhas no CMS e no servidor

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?.

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:

O nível SSH é suficientemente autónomo para um artigo próprio: Encontrar e remover chaves SSH desconhecidas.

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:

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:

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:

# 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:

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. 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.

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, 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

Fontes

• WordPress
• php.net: avisos de segurança
• BSI: indicações sobre incidentes de segurança informática