A segurança no WordPress voltou ao centro das atenções após uma descoberta inusitada: um simples erro operacional cometido por uma quadrilha de cibercriminosos acabou expondo uma infraestrutura inteira utilizada para comprometer milhares de sites na internet. Durante aproximadamente três semanas, um servidor administrativo permaneceu acessível sem autenticação, permitindo que pesquisadores analisassem em detalhes uma campanha de larga escala voltada principalmente contra WordPress e Joomla.
O incidente, batizado de WP-SHELLSTORM, oferece uma rara oportunidade de entender como funciona uma operação criminosa moderna. Em vez de depender de sofisticados ataques de zero-day, os invasores apostavam em algo muito mais eficiente: a exploração automatizada de vulnerabilidades já conhecidas, especialmente em plugins desatualizados.
Mais do que revelar o funcionamento interno da campanha, a investigação também ajuda a desmistificar números alarmantes divulgados inicialmente e reforça uma velha lição da segurança digital: manter sistemas atualizados continua sendo a defesa mais eficaz contra ataques automatizados.
O que é a operação WP-SHELLSTORM
A operação WP-SHELLSTORM é um exemplo clássico do chamado mercado de corretagem de acesso por webshells. Em vez de realizar ataques personalizados contra um alvo específico, os criminosos buscavam comprometer o maior número possível de servidores vulneráveis para posteriormente vender ou utilizar esse acesso em outras atividades criminosas.
A descoberta ocorreu graças aos pesquisadores da SOCRadar e da Ctrl-Alt-Intel, que encontraram um servidor administrativo completamente exposto na internet. O motivo do vazamento chega a ser irônico: um script Python utilizado pelos próprios operadores permaneceu acessível sem qualquer proteção, permitindo visualizar logs, listas de alvos, ferramentas e parte da infraestrutura utilizada pelo grupo.
É o tipo de erro que dificilmente se espera de uma organização criminosa capaz de operar campanhas internacionais. No entanto, mostra que até mesmo hackers experientes podem cometer falhas básicas de configuração.
Os registros revelaram scanners automatizados procurando vulnerabilidades conhecidas em milhares de instalações de WordPress, Joomla e outros sistemas web amplamente utilizados.
Alvos versus infecções reais: desmistificando os números
Um dos aspectos mais importantes da investigação foi esclarecer um dado que rapidamente ganhou manchetes: a existência de aproximadamente 1,4 milhão de sites na lista da operação.
À primeira vista, o número parece indicar uma invasão sem precedentes. Mas a realidade é diferente.
A lista encontrada continha potenciais alvos, muitos deles extraídos de mecanismos especializados de busca de ativos na internet, como o FOFA, utilizado para localizar servidores com determinadas características.
Em outras palavras, estar nessa lista significava apenas que um servidor possivelmente executava WordPress, Joomla ou outro software de interesse dos criminosos.
As análises posteriores indicam que o número de comprometimentos efetivamente confirmados ficou entre aproximadamente 5.700 e 25.000 sites, dependendo da metodologia utilizada pelos pesquisadores.
Essa diferença é extremamente importante.
Em campanhas automatizadas, milhões de servidores podem ser escaneados diariamente, mas apenas uma pequena parcela apresenta vulnerabilidades exploráveis. Isso significa que estar na mira dos scanners não é o mesmo que ter sido invadido.
Mesmo assim, o volume de infecções continua sendo expressivo e demonstra o impacto que falhas conhecidas ainda possuem quando administradores deixam atualizações pendentes.
Como a segurança no WordPress foi comprometida pela automação
O sucesso da operação não estava em ferramentas revolucionárias, mas na automação.
Os atacantes utilizavam scanners capazes de identificar rapidamente versões vulneráveis de plugins e componentes populares. Assim que encontravam uma brecha conhecida, iniciavam automaticamente a instalação de webshells, que funcionam como portas de entrada permanentes para controle remoto do servidor.
Essa estratégia reduz custos, aumenta a escala dos ataques e praticamente elimina a necessidade de interação manual durante a invasão.
Para os administradores, a principal conclusão é clara: a maioria dessas infecções poderia ter sido evitada apenas mantendo plugins, temas e o CMS atualizados.
As ferramentas utilizadas e a conexão chinesa
A infraestrutura analisada revelou um conjunto relativamente sofisticado de ferramentas.
Entre elas estava o down.php, um webshell baseado no conhecido projeto BestShell, capaz de fornecer acesso remoto persistente aos servidores comprometidos.
Os pesquisadores também identificaram o uso do SNOWLIGHT, responsável por atuar como dropper, ou seja, baixar e instalar cargas maliciosas adicionais após a invasão inicial.
Outro componente chamou atenção pela técnica de camuflagem utilizada.
O malware VShell procurava ocultar sua execução assumindo nomes semelhantes aos processos kworker, legítimos do kernel Linux. Essa prática dificulta a identificação durante análises rápidas, já que muitos administradores podem interpretar o processo como parte normal do sistema operacional.
Embora essa técnica não seja inédita, ela continua sendo bastante eficaz quando administradores não realizam inspeções detalhadas dos processos ativos.
O histórico e as campanhas corporativas anteriores
A investigação também mostrou que o grupo não surgiu focado exclusivamente em WordPress.
Antes da operação atual, os criminosos já haviam conduzido campanhas contra aplicações corporativas baseadas em Java, explorando plataformas como Nacos, XXL-Job e Spring Boot.
O objetivo dessas campanhas era obter acesso a ambientes empresariais e roubar credenciais de provedores de nuvem, incluindo chaves da AWS e da DigitalOcean.
Posteriormente, o foco mudou para plataformas de gerenciamento de conteúdo, provavelmente devido ao enorme número de instalações vulneráveis disponíveis na internet.
Essa evolução mostra uma tendência preocupante: grupos especializados estão migrando entre diferentes ecossistemas conforme surgem oportunidades mais rentáveis.
Como proteger a segurança no WordPress e limpar um site comprometido
A boa notícia é que os métodos utilizados pela operação WP-SHELLSTORM dependiam principalmente da exploração de vulnerabilidades já conhecidas.
Isso significa que existem medidas práticas capazes de reduzir drasticamente o risco.
Atualize imediatamente plugins e componentes
O primeiro passo é instalar todas as atualizações disponíveis.
Os pesquisadores destacam especialmente componentes como:
- Plugin Breeze, quando vulnerável;
- Editor JCE do Joomla;
- Outros plugins e extensões com falhas públicas conhecidas.
Adiar atualizações continua sendo um dos principais fatores responsáveis por invasões automatizadas.
Procure webshells e arquivos PHP suspeitos
Realize uma varredura completa em busca de arquivos .php desconhecidos, principalmente aqueles criados recentemente ou armazenados em diretórios incomuns.
Arquivos com nomes aleatórios ou localizados em pastas de upload merecem atenção especial.
Também vale comparar os arquivos do site com versões originais obtidas diretamente dos desenvolvedores.
Analise processos em execução
Nos servidores Linux, verifique cuidadosamente processos que tentam se passar por kworker.
Embora existam processos legítimos com esse nome, versões maliciosas costumam apresentar comportamentos incomuns, consumir recursos inesperadamente ou executar comandos incompatíveis com o funcionamento normal do kernel.
Ferramentas de monitoramento e soluções de EDR podem facilitar essa identificação.
Bloqueie indicadores de comprometimento
Caso sua equipe disponha dos IPs, domínios e demais Indicadores de Comprometimento (IoCs) divulgados pelos pesquisadores, inclua essas informações em:
- Firewall;
- WAF;
- IDS/IPS;
- Soluções de monitoramento de rede.
Essa medida ajuda a impedir novas tentativas de comunicação com a infraestrutura criminosa.
Revise credenciais e acessos administrativos
Mesmo após remover um webshell, considere todas as credenciais potencialmente comprometidas.
Altere:
- Senhas administrativas;
- Credenciais FTP e SSH;
- Chaves de acesso;
- Tokens de API.
Também é recomendável revisar usuários administrativos criados recentemente.
Implemente monitoramento contínuo
A segurança no WordPress não termina após a limpeza.
Configure:
- Atualizações automáticas sempre que possível;
- Monitoramento de integridade de arquivos;
- Backups frequentes;
- Autenticação multifator para administradores;
- Plugins de segurança confiáveis.
Essas medidas reduzem significativamente o impacto de futuras campanhas automatizadas.
Conclusão
A operação WP-SHELLSTORM demonstra que muitas das maiores campanhas de comprometimento da internet não dependem de técnicas extraordinárias nem de vulnerabilidades inéditas.
O verdadeiro combustível desses ataques continua sendo a combinação entre automação, falhas conhecidas e sistemas desatualizados.
Talvez a maior ironia desse caso seja justamente o fato de uma operação criminosa altamente organizada ter sido parcialmente desmascarada por um simples servidor administrativo deixado aberto pelos próprios hackers. Um descuido básico permitiu que pesquisadores revelassem boa parte da infraestrutura utilizada para comprometer milhares de sites.
Para administradores de WordPress e Joomla, a principal lição permanece a mesma: atualizar plugins, revisar periodicamente os arquivos do servidor e monitorar indicadores de comprometimento continua sendo muito mais eficiente do que reagir após uma invasão.
Afinal, quando os ataques são totalmente automatizados, basta uma única vulnerabilidade esquecida para transformar um site comum em mais um alvo da próxima campanha.