Grupo plaNETWORK é vinculado a webshell PHP usada contra Drupalgeddon

Investigação técnica conecta um webshell PHP com strings em indonésio, referências ao grupo plaNETWORK e atividade pública de desfiguração de sites ligada a operadores na Indonésia.

Componente	Webshell PHP associado ao grupo plaNETWORK e usado em tentativas de exploração de uma vulnerabilidade conhecida em Drupal chamada Drupalgeddon.
Vetor	Ataques observados no início de janeiro de 2019 tentavam explorar Drupalgeddon para implantar ou acionar um webshell PHP em servidores vulneráveis.
Impacto	Um comprometimento bem-sucedido daria ao operador controle amplo sobre o sistema afetado, limitado ao que o servidor vulnerável e a webshell permitissem executar.
Prioridade	Identificar servidores Drupal expostos, validar correções contra Drupalgeddon, procurar artefatos de webshell PHP e revisar evidências de desfiguração ou acesso não autorizado.
Artefatos	O código analisado continha palavras em indonésio, links para repositórios de código, referências ao time plaNETWORK e a frase recorrente We Are Not Hacker.
Infraestrutura	A investigação conectou o material técnico a presença pública em site, redes sociais, vídeos e páginas de desfiguração associadas ao nome plaNETWORK.

Resumo técnico

A atividade analisada envolve um grupo indonésio identificado como plaNETWORK, descrito como uma organização que combina aparência de consultoria de TI com produção e uso de ferramentas de ataque. O ponto inicial da investigação foi uma onda de ataques observada no início de janeiro de 2019, na qual operadores tentavam explorar uma vulnerabilidade conhecida do Drupal, chamada Drupalgeddon, usando um webshell PHP. O webshell não foi descrito como tecnicamente incomum por si só, mas o conteúdo do código trouxe artefatos de atribuição operacional: palavras em indonésio, referências a repositórios, menções ao time plaNETWORK e a frase We Are Not Hacker, repetida em outros espaços públicos relacionados ao grupo.

O caso é relevante para equipes de defesa porque mostra como um artefato aparentemente comum, como um webshell PHP, pode conter pistas suficientes para conectar exploração técnica, identidade pública e histórico de desfiguração de sites. O material analisado indica que plaNETWORK estaria ativo havia cerca de sete anos, desenvolvendo ferramentas de hacking e participando de diversos incidentes. Também há sinais de autopromoção: integrantes e perfis associados publicavam ou exibiam referências a desfigurações, backdoors, brute force, back connect e bind, termos apresentados no material como parte da própria narrativa pública do grupo. A atribuição a indivíduos reais não é necessária para a defesa; o valor operacional está em reconhecer os artefatos, entender o vetor e reduzir a superfície exposta.

Fluxo técnico

O fluxo começa com servidores Drupal vulneráveis a Drupalgeddon. O contexto não fornece CVE, versão afetada, payload ou procedimento de exploração, portanto a defesa deve tratar o vetor no nível de classe: aplicação web exposta, falha conhecida em Drupal e tentativa de implantação ou uso de webshell PHP após a exploração. Uma webshell desse tipo normalmente é um artefato de pós-exploração em aplicação web: ela permanece no sistema de arquivos do servidor e permite ao operador interagir com o ambiente comprometido por meio de requisições HTTP. Neste caso, o texto recebido afirma apenas que suas capacidades permitiriam ao atacante fazer praticamente qualquer coisa no sistema da vítima em caso de sucesso, sem enumerar comandos ou módulos específicos.

O aspecto mais forte da investigação está na correlação de artefatos. O código continha strings em indonésio, incluindo nomes de funções e mensagens relacionadas a usuário e senha, além de referências ao termo plaNETWORK team. A frase We Are Not Hacker, encontrada no webshell, reapareceu em perfis e páginas públicas associadas ao mesmo nome. A mesma trilha também levou a um site de consultoria de TI com domínio defangado www[.]planetwork[.]co[.]id, perfis sociais, vídeos e páginas de desfiguração. Essa repetição de marca, slogan e apelidos cria um conjunto de sinais úteis para inteligência de ameaças, ainda que cada elemento isolado pudesse ser fraco.

A investigação também descreve uma presença pública incomum para operadores maliciosos. Vídeos associados ao grupo exibiam integrantes, apelidos e termos ligados a técnicas ofensivas, enquanto páginas em sites de registro de desfiguração exibiam reivindicações de comprometimento. O material cita apelidos como Conficker, Calvin, eNda, bandila e outros nomes vistos em vídeos ou páginas de desfiguração. Para uso defensivo, esses nomes devem ser tratados como pivôs de pesquisa e não como prova isolada de autoria. A informação mais acionável continua sendo a combinação entre exploração de Drupalgeddon, webshell PHP, desfiguração de sites e artefatos linguísticos em indonésio.

Superfície afetada

A superfície primária é composta por instâncias Drupal expostas à internet e ainda vulneráveis a Drupalgeddon no período observado. Como o contexto não informa versões, ramos suportados, CVEs ou estado de correção específico, não é adequado inferir quais edições do CMS estão afetadas. A leitura defensiva correta é mapear todos os sites Drupal sob responsabilidade da organização, confirmar o histórico de aplicação de correções para a vulnerabilidade conhecida e revisar servidores que ficaram expostos durante a janela de ataques do início de 2019.

A segunda camada de exposição envolve servidores web que aceitam escrita em diretórios usados pela aplicação, permissões excessivas no processo do servidor, credenciais administrativas fracas ou ambientes sem controle de integridade de arquivos. Mesmo quando a exploração inicial depende de uma falha de aplicação, a persistência e o impacto costumam aumentar quando o servidor permite criação de arquivos PHP em caminhos acessíveis pela web. O contexto também menciona desfigurações, o que indica interesse em alterar conteúdo público de sites comprometidos. Isso não deve ser automaticamente interpretado como vazamento de dados, movimentação lateral ou exfiltração, pois esses efeitos não aparecem confirmados no material recebido.

• Instâncias Drupal acessíveis pela internet e sem validação documentada de correção contra Drupalgeddon.
• Servidores web com arquivos PHP criados ou modificados fora do fluxo normal de publicação da aplicação.
• Sites com histórico de desfiguração, alteração indevida de páginas, inserção de mensagens não autorizadas ou referências a slogans usados pelo grupo.
• Ambientes em que logs de aplicação, servidor web e sistema operacional não foram preservados por tempo suficiente para reconstruir a sequência de exploração.

Hunting e telemetria

A caça deve partir de três eixos: exploração de Drupal, presença de webshell PHP e sinais de desfiguração. Nos logs HTTP, procure requisições incomuns para rotas do Drupal durante a janela de exposição, respostas anômalas após requisições que deveriam ser administrativas e acessos repetidos a arquivos PHP recém-criados. Como o contexto não fornece payloads, caminhos exatos ou hashes, a detecção não deve depender de assinaturas rígidas. O caminho mais confiável é comparar o sistema de arquivos com uma base conhecida, revisar arquivos modificados fora de janelas de implantação e identificar PHP com padrões de autenticação própria, parâmetros opacos ou texto em idioma inesperado para o projeto.

No endpoint e no servidor, a telemetria útil inclui criação de arquivos por usuário do processo web, alterações em permissões, execução de processos filhos a partir do serviço HTTP e conexões de saída iniciadas por scripts PHP. A investigação menciona termos como backdoor, back connect e bind em material público do grupo, mas não fornece implementação específica. Assim, a defesa deve procurar classes de comportamento: shells persistentes, conexões reversas, listeners não documentados e artefatos que permitam controle remoto. Qualquer indicador de rede deve ser defangado em documentação interna quando apontar para infraestrutura suspeita; no material recebido, exemplos citados incluem indonesiandefacer[.]org, zone-h[.]org, defacer[.]id e goverment[.]or[.]id, usados como pivôs de contexto, não como lista completa de IoCs maliciosos.

Também vale correlacionar conteúdo de páginas alteradas. Mensagens com a frase We Are Not Hacker, menções ao time plaNETWORK, apelidos associados e referências a fóruns ou páginas de desfiguração podem indicar que um site foi usado para autopromoção do grupo. Esse tipo de evidência deve ser preservado com captura forense, horário, URL defangada, hash do arquivo alterado e cópia dos logs correspondentes. A prioridade é reconstruir a sequência: primeira requisição suspeita, criação ou alteração de arquivo PHP, execução subsequente, mudança de conteúdo público e eventuais conexões de rede.

• Arquivos PHP recentes, com strings em indonésio, referências a plaNETWORK ou frase We Are Not Hacker.
• Requisições HTTP para arquivos PHP não presentes no repositório ou no pacote oficial da aplicação.
• Processos filhos anômalos iniciados pelo serviço web após requisições a rotas do Drupal.
• Alterações não autorizadas em páginas públicas, títulos, banners, rodapés ou mensagens de desfiguração.
• Conexões de saída ou escuta local iniciadas por scripts PHP, especialmente após criação de arquivos suspeitos.

Mitigação

A resposta deve começar por inventário e correção. Todos os ambientes Drupal expostos devem ser identificados, comparados com o histórico de atualização e validados contra Drupalgeddon. Onde houver suspeita de exploração, aplicar correção sem remover evidências antes da coleta. Preservar logs de servidor web, aplicação, sistema operacional, snapshots do sistema de arquivos e cópias dos arquivos suspeitos permite confirmar se houve apenas tentativa, alteração de conteúdo ou controle persistente. Como o contexto não confirma exfiltração, a comunicação interna deve limitar o impacto ao que for comprovado pela telemetria local.

Depois da contenção, remova webshells e restaure o site a partir de fontes confiáveis, preferencialmente reconstruindo a aplicação a partir de repositório limpo e artefatos de implantação verificados. Alterar apenas a página desfigurada pode deixar persistência ativa. Revise permissões do processo web, desabilite escrita em diretórios que não precisam receber upload, separe diretórios de mídia de diretórios executáveis e monitore mudanças em arquivos PHP. Credenciais administrativas e chaves relacionadas ao CMS devem ser rotacionadas quando houver evidência de acesso não autorizado ao painel, ao banco de dados ou ao sistema de arquivos.

A prevenção também depende de governança de telemetria. Equipes que operam CMS expostos devem manter baseline de integridade, retenção adequada de logs e alertas para criação de scripts executáveis. Para inteligência de ameaças, os artefatos plaNETWORK, We Are Not Hacker, strings em indonésio no webshell e domínios defangados ligados a páginas de desfiguração podem ser usados como pivôs de investigação, com validação manual antes de qualquer bloqueio amplo. A atribuição pública do grupo foi encaminhada a autoridades regionais; no ambiente corporativo, o foco deve permanecer em reduzir exposição, confirmar comprometimento e impedir persistência.

• Aplicar correções de segurança do Drupal relacionadas a Drupalgeddon e documentar a versão efetivamente implantada.
• Comparar o sistema de arquivos com uma fonte confiável e remover webshells somente após preservação das evidências necessárias.
• Revisar permissões de escrita e execução em diretórios acessíveis pela web, reduzindo a capacidade de persistência por PHP.
• Rotacionar credenciais administrativas do CMS, banco de dados e hospedagem quando houver indício de acesso não autorizado.
• Criar alertas para arquivos PHP novos, alterações em páginas públicas e execução de processos pelo usuário do servidor web.