Como encontrar backdoors ocultos no WordPress com WP-CLI e SQL
30 de julio de 2026
0
Internet TechnologyComments (0)
Log in to leave a comment
No posts yet
Log in to leave a comment
No posts yet
Clicar no botão de atualização do core de um site WordPress feito por terceiros pode dar um certo receio. Se você adia a atualização por medo de que o tema ou plugins customizados quebrem e a tela fique completamente em branco, o site acaba ficando cheio de vulnerabilidades. Quando surgir aquele pressentimento de que o site já pode ter sido invadido, este é o procedimento prático mais rápido para inspecionar o banco de dados e o servidor.
Atacantes geralmente entram sem chamar atenção. Eles costumam alterar diretamente a tabela wp_usermeta do banco de dados para conceder privilégios de administrador a contas existentes de forma discreta. Essas contas raramente aparecem na lista comum de usuários do painel, mas ficam visíveis imediatamente ao consultar o banco de dados.
`sql
SELECT
u.ID,
u.user_login,
u.user_email,
u.user_registered,
m.meta_value AS capabilities
FROM
wp_users u
INNER JOIN
wp_usermeta m ON u.ID = m.user_id
WHERE
m.meta_key = 'wp_capabilities'
AND (
m.meta_value LIKE '%"administrator"%'
OR m.meta_value LIKE '%"administrator":true%'
)
ORDER BY
u.user_registered DESC;
`
Em seguida, verifique o sistema de arquivos. Se houver arquivos PHP no diretório wp-content/uploads, onde deveriam estar apenas imagens e documentos, com certeza é um backdoor. Abra o terminal SSH e faça uma varredura em busca de arquivos perigosos.
`bash
find wp-content/uploads/ -type f -name "*.php" -ls
find . -type f -name "*.php" -exec grep -HnE "(eval(|base64_decode(|gzinflate(|passthru(|shell_exec()" {} ;
wp core verify-checksums --include-root
`
Os logs também precisam ser analisados. Ataques voltados para a REST API costumam disparar requisições POST em um curto intervalo de tempo, obtendo respostas 200 ou 201. Extraia as requisições com respostas suspeitas no access.log do Nginx.
`bash
grep -E "POST|PUT" /var/log/nginx/access.log | grep -E "/wp-json/|rest_route=" | awk '/ {print $1, $4, $6, $7, $9}' | sort | uniq -c | sort -nr | head -n 30
`
Aplicar correções diretamente no site em produção não é coragem, é imprudência. Crie primeiro um ambiente de staging duplicando integralmente o banco de dados e o sistema de arquivos.
`bash
wp db export production_backup.sql --add-drop-table
rsync -avz --exclude='wp-content/cache' /var/www/html/ staging:/var/www/staging/
wp db import production_backup.sql
wp search-replace 'https://example.com' 'https://staging.example.com' --skip-columns=guid
wp plugin list --update=available --fields=name,version,update_version,requires_php --format=table
`
Após concluir a duplicação, aplique as atualizações e dedique cerca de 5 minutos para testar as principais funcionalidades. Para garantir a estabilidade, teste manualmente o cadastro de usuários, login, adição de itens ao carrinho, chamada da tela de checkout e envio de formulários de contato.
Há situações frustrantes em que o desenvolvedor do plugin não lança atualizações, impedindo a atualização imediata do core. Nesses casos, ganhe tempo bloqueando o acesso a rotas específicas no nível do servidor ou através de um WAF. Se estiver utilizando o Nginx, bloqueie os endpoints de criação de usuários da REST API e de processamento em lote no nginx.conf, liberando apenas o seu IP.
`nginx
location ~* ^/wp-json/(batch/v1|wp/v2/users) {
limit_except GET {
allow 192.0.2.1;
deny all;
}
try_files $uri args;
}
`
Para se prevenir contra imprevistos, configure também um script de backup adicional para enviar o banco de dados e a pasta de uploads para o Amazon S3.
`bash
#!/bin/bash
WP_PATH="/var/www/html"
BACKUP_DIR="/tmp/wp_backups"
DATE=$(date +%Y%m%d_%H%M%S)
S3_BUCKET="s3://my-wordpress-secure-backups"
mkdir -p $BACKUP_DIR
wp db export BACKUP_DIR/db_DATE.sql --path=$WP_PATH --quiet
tar -czf BACKUP_DIR/files_DATE.tar.gz -C $WP_PATH wp-content/uploads/
aws s3 cp BACKUP_DIR/db_DATE.sql S3_BUCKET/db_DATE.sql
aws s3 cp BACKUP_DIR/files_DATE.tar.gz S3_BUCKET/files_DATE.tar.gz
find $BACKUP_DIR -type f -mtime +7 -delete
`
O trabalho não termina ao remover códigos maliciosos e aplicar as correções de segurança, pois o atacante ainda pode retornar utilizando cookies de sessão roubados. Encerre todas as sessões ativas e redefina completamente as chaves salt no arquivo wp-config.php.
`bash
wp user list --field=ID | xargs -n 1 wp user session destroy --all
wp config shuffle-salts
`
Desative também a funcionalidade de edição direta de arquivos de temas e plugins no painel administrativo. Essa é uma medida básica de proteção para evitar que o atacante injete código mesmo que obtenha acesso administrativo. Adicione as duas linhas abaixo ao arquivo wp-config.php.
`php
define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true );
`
Por fim, adicione um filtro personalizado no diretório mu-plugins para impedir que usuários não autenticados vejam a lista de usuários através da REST API.
`php
<?php
/**
`