Recebi a mensagem em um fim de semana. Um cliente com uma loja virtual em WordPress estava desesperado: ele mesmo tinha desativado o gateway de pagamento após perceber que algo estava errado. Centenas de transações suspeitas em poucas horas — compras anônimas, em sequência, com cartões diferentes, todas no mesmo produto. O gateway continuava aceitando os pedidos normalmente, sem levantar nenhum alerta. Foi o próprio cliente que notou o padrão e tomou a decisão de cortar o serviço para conter o estrago.
Era um ataque de carding — e ele tinha funcionado.
Neste post vou contar como investiguei o que aconteceu, o que encontrei, e o que fizemos para resolver. Sem nome de cliente, sem domínio exposto. Mas com todos os detalhes técnicos relevantes para quem tem ou gerencia uma loja virtual.
O que é um ataque de carding?
Antes de entrar no caso, vale explicar rapidamente o que é carding para quem nunca ouviu falar.
Carding é quando criminosos usam cartões de crédito roubados para testar se eles ainda estão válidos — e o método favorito é fazer compras em lojas virtuais. O bot faz centenas de tentativas automatizadas: cada uma com um cartão diferente, dados de entrega variados, mas sempre seguindo o mesmo padrão mecânico. Quando uma transação é aprovada, o criminoso sabe que aquele cartão funciona e pode usá-lo para compras maiores em outros lugares.
O prejuízo para a loja é indireto mas real: chargebacks, bloqueio do gateway, dano à reputação junto ao processador de pagamentos, e em casos graves, suspensão da conta.
O que eu encontrei quando comecei a investigar
Com autorização do cliente, iniciei uma auditoria completa. A primeira etapa foi entender como o ataque tinha chegado até ali — quais portas estavam abertas, o que o site estava expondo sem necessidade.
A resposta foi: muita coisa.
O checkout estava completamente aberto
O endpoint que processa pedidos no WooCommerce respondia normalmente para qualquer requisição, sem nenhuma barreira antes do gateway. Não havia CAPTCHA, não havia limite de tentativas por IP, não havia verificação se quem estava comprando era humano ou máquina.
Fiz um teste simples: tentei simular uma compra via PIX sem nem criar uma conta. Funcionou. Qualquer pessoa — ou bot — conseguia iniciar um pedido sem nenhum tipo de autenticação.
O bot que atacou o cliente não era simples. Ele sabia imitar o comportamento de um usuário real: primeiro visitava a página do produto, depois coletava um token de segurança do site, e só então enviava o pedido com os dados do cartão. Esse nível de sofisticação explica por que as defesas padrão não detectaram nada de errado.
Um arquivo exposto que nunca deveria ser público
Durante a varredura, encontrei o arquivo de log de erros do WordPress acessível publicamente na internet. Qualquer um que soubesse o endereço correto conseguia abrir esse arquivo no navegador e ver mensagens internas do servidor: caminhos de pastas, erros de banco de dados, comportamento interno da aplicação.
Para um atacante, isso é ouro. É como deixar o manual de instruções do cofre na frente da loja.
Plugins com vulnerabilidades conhecidas
Rodei uma varredura nos plugins instalados e o resultado foi preocupante. Vários deles tinham vulnerabilidades de segurança documentadas publicamente — alguns com notas altas de gravidade, incluindo falhas que permitiriam a um atacante executar código no servidor.
Entre os achados mais graves estava um plugin de construção de páginas amplamente usado, um plugin de filtros de produtos, e um plugin de formulários. Nenhum deles estava na versão mais recente que corrigia os problemas.
O elefante na sala: o plugin nulled
O Wordfence — plugin de segurança do WordPress — acendeu um alerta vermelho durante a varredura: detectou uma URL suspeita embutida dentro do arquivo principal de um plugin de construção de páginas premium. O endereço apontava para um site conhecido por distribuir versões piratas de plugins WordPress.
Isso é o que chamamos de plugin nulled: uma versão "crackeada" de um software pago, distribuída gratuitamente em sites não oficiais. O problema é que essas versões quase sempre vêm com um presente não solicitado — um trecho de código malicioso escondido que pode criar uma porta dos fundos no servidor, roubar dados, ou simplesmente ficar dormindo até o momento certo para agir.
Não tenho como afirmar com certeza que o plugin nulled foi a causa direta do ataque. Mas posso dizer que ele estava lá, e que um arquivo do servidor com aquele comportamento representa um risco grave e inaceitável para qualquer loja em produção.
Por que plugins nulled são um problema sério
Eu entendo a lógica de quem instala um plugin nulled. Os plugins premium custam caro, muitas vezes em dólar, e para uma loja pequena que está começando parece um gasto desnecessário. "É o mesmo plugin, só que de graça."
Não é.
Quando você instala um plugin nulled, você está instalando um arquivo de origem desconhecida, modificado por pessoas que você não conhece, em um servidor que processa os dados dos seus clientes — incluindo endereços, CPFs e dados de pagamento.
Você está essencialmente contratando um técnico desconhecido da internet para trabalhar dentro da sua loja, sem supervisão, com acesso a tudo.
Além disso, plugins nulled não recebem atualizações. Quando uma vulnerabilidade de segurança é descoberta e o desenvolvedor lança uma correção, a versão pirata fica para trás. Com o tempo, ela vira uma porta aberta conhecida por atacantes.
O custo de um plugin legítimo é muito menor do que o custo de um ataque: chargebacks, horas de trabalho para remediar, possível suspensão do gateway, dano à reputação da loja.
O que fizemos para resolver
Com o diagnóstico completo em mãos, partimos para a correção. Organizei o trabalho em camadas — cada camada adicionando uma barreira a mais entre o bot e o checkout.
Primeira camada: fechar a porta principal
A mudança mais imediata foi desativar as compras sem cadastro. Parece simples, mas é extremamente eficaz: agora qualquer pessoa que queira comprar precisa criar uma conta com e-mail válido. Para um bot que precisa fazer centenas de tentativas por hora, criar uma conta para cada tentativa torna o ataque economicamente inviável.
Segunda camada: Cloudflare como guardião
Ativamos e configuramos corretamente o Cloudflare como barreira antes do site. Isso incluiu:
Bot Fight Mode: detecta e bloqueia automaticamente tráfego com comportamento de bot
Rate Limiting: limita quantas vezes um mesmo IP pode tentar fazer um pedido em determinado período
Regras de firewall personalizadas: bloqueio de requisições com padrões suspeitos, como navegadores sem identificação ou origens geográficas sem relação com o negócio
Terceira camada: CAPTCHA no checkout e no login
Implementamos o Cloudflare Turnstile — o sistema de verificação da Cloudflare que distingue humanos de máquinas — em todos os pontos críticos do site: checkout, login, cadastro e painel administrativo.
Após a implementação, rodei um teste simulando exatamente o que o bot fazia: enviei uma requisição para o endpoint de checkout com todos os dados preenchidos corretamente, mas sem o token de verificação do Turnstile. A resposta foi imediata:
"Por favor, confirme que você não é um robô."
O pedido não passou. O bot teria sido bloqueado antes mesmo de chegar ao gateway de pagamento.
Quarta camada: endurecimento do Wordfence
As configurações padrão do Wordfence são razoáveis, mas longe do ideal. Ajustamos os limites de tentativas de login (de 20 para 5 tentativas antes do bloqueio), reduzimos a janela de tempo de contagem de falhas, e aumentamos o período de bloqueio de IPs suspeitos de 4 horas para 24 horas.
Também ativamos o bloqueio imediato de tentativas usando nomes de usuário inválidos — uma técnica comum em ataques automatizados de força bruta.
Quinta camada: limpeza e visibilidade
Removemos o arquivo de log exposto e desativamos completamente o modo de debug do WordPress. Também ocultamos a versão do WordPress nos cabeçalhos do site — uma informação que atacantes usam para identificar alvos com versões desatualizadas.
O que ainda precisa ser feito
A mitigação imediata está concluída, mas a segurança é um processo contínuo, não um evento único.
Ainda estão pendentes as atualizações dos plugins com vulnerabilidades conhecidas — trabalho que precisa ser feito com cuidado e em ambiente de testes, porque atualizações de plugins às vezes afetam o visual e o comportamento do site.
E, claro, a questão do plugin nulled precisa ser resolvida definitivamente: substituição por uma licença legítima e verificação completa de que não restou nenhum código malicioso no servidor.
O que você pode aprender com isso
Se você tem uma loja virtual em WordPress — ou gerencia sites para clientes — aqui estão as lições práticas deste caso:
1. Nunca use plugins ou temas nulled. O risco não vale a economia. Procure alternativas gratuitas legítimas ou invista na licença oficial.
2. Ative o Cloudflare e configure-o corretamente. Simplesmente ativar não é suficiente. Bot Fight Mode desligado, zero regras de WAF e rate limiting — era exatamente o que encontrei aqui.
3. CAPTCHA no checkout é obrigatório. Especialmente se você aceita compras sem cadastro.
4. Mantenha plugins atualizados. Vulnerabilidades são descobertas constantemente. Plugin desatualizado é porta aberta.
5. Desative o debug em produção. WP_DEBUG ativo em um site ao vivo é uma falta grave de higiene de segurança.
6. Faça uma auditoria periódica. Não espere um ataque acontecer para descobrir o que está exposto.
A segurança de uma loja virtual não é responsabilidade só do desenvolvedor nem só do dono. É uma parceria. O dono precisa investir em licenças legítimas e manter o site atualizado. O desenvolvedor precisa configurar as ferramentas corretamente e comunicar os riscos com clareza.
Quando essa parceria funciona, os bots encontram portas fechadas.
Estúdio especializado em desenvolvimento de software sob medida, UI/UX, infraestrutura e segurança de aplicações. Pratica pentest autorizado e hardening de servidores como parte do processo de entrega de qualquer projeto. Atua como parceiro técnico de longo prazo para marcas que levam seu produto digital a sério — empresas que não podem se dar ao luxo de tratar segurança como item secundário.