GoBruteforcer usa servidores Linux comprometidos para força bruta contra FTP, bancos de dados e phpMyAdmin

Variante observada em 2025 combina bot IRC em Go, listas rotativas de credenciais fracas, persistência, mascaramento de processo e foco em serviços expostos na internet.

Componente	Botnet GoBruteforcer, composta por bot IRC em Go e módulo de força bruta baixado separadamente em servidores Linux comprometidos.
Vetor	Tentativas de autenticação contra FTP, MySQL, PostgreSQL e painéis phpMyAdmin expostos à internet, usando nomes de usuário operacionais e senhas fracas ou padrão.
Impacto	Comprometimento de servidores, execução remota de comandos, upload de web shell, roubo de dados, criação de contas de backdoor, revenda de acesso e expansão da botnet.
Prioridade	Remover exposição pública desnecessária, trocar credenciais fracas, auditar XAMPP e phpMyAdmin, bloquear escrita no webroot por FTP e procurar artefatos como init_start, /tmp/init_stop e o web shell conhecido.
Artefatos	Web shell PHP associado ao SHA256 de7994277a81cf48f575f7245ec782c82452bb928a55c7fae11c2702cc308b8b; nomes de arquivos init_start e init_stop; uso de test2.php, uname -m, wget, curl e /tmp.
Superfície	Instalações Linux com FTP, MySQL, PostgreSQL ou phpMyAdmin acessíveis pela internet; ambientes XAMPP em /opt/lampp com webroot em /opt/lampp/htdocs são um caso de risco quando mantêm credenciais padrão.

Resumo técnico

GoBruteforcer é uma botnet voltada a servidores Linux expostos que transforma máquinas comprometidas em nós de varredura, autenticação por força bruta e controle remoto. A operação não depende de vulnerabilidade de dia zero para iniciar o acesso: o ponto central é a combinação de serviços publicados na internet, contas previsíveis e senhas fracas. Os alvos operacionais incluem FTP, MySQL, PostgreSQL e painéis phpMyAdmin, com campanhas que alternam nomes de usuário e listas de senhas para testar grandes blocos de endereços públicos. Quando uma autenticação tem sucesso, o acesso pode ser usado para extrair dados, plantar uma web shell, criar novas contas, revender credenciais ou incorporar o servidor ao próprio ecossistema de ataque.

A variante observada em 2025 apresenta evolução em relação à descrição pública inicial de 2023. O conjunto malicioso passou a incluir um bot IRC reescrito em Go e fortemente ofuscado, mecanismos de persistência mais elaborados, técnicas de mascaramento de processo e listas dinâmicas de credenciais fornecidas pelo servidor de comando e controle. A arquitetura é modular: um componente mantém o canal de controle e recebe comandos, enquanto outro módulo executa a força bruta e pode ser baixado, atualizado ou interrompido de forma independente. Essa separação permite que operadores troquem infraestrutura, atualizem binários por arquitetura e redistribuam tarefas sem reinstalar toda a cadeia de infecção.

Fluxo técnico

A cadeia começa com a localização de serviços acessíveis em portas padrão ou rotas administrativas conhecidas. Para MySQL, PostgreSQL e phpMyAdmin, o servidor de comando e controle define a campanha e entrega ao bot uma lista com cerca de 200 combinações para a tarefa de força bruta. Essas listas são derivadas de um conjunto menor, normalmente entre 375 e 600 senhas fracas, e são refeitas ao longo da semana com variações de nomes de usuário. Em campanhas amplas, aparecem contas operacionais comuns como php, operator, appuser, john, api, newuser, dbo, service, web, guest e myuser. Em execuções mais focadas, a botnet usa nomes relacionados a criptomoedas, como cryptouser, appcrypto, crypto_app e crypto, combinados com senhas temáticas simples. Para phpMyAdmin, os nomes observados incluem root, wordpress e wpuser, com variações de senha associadas a WordPress.

O módulo de FTP se diferencia porque usa um conjunto pequeno de credenciais embutidas no próprio binário, em vez de depender exclusivamente de listas enviadas pelo comando e controle. Esse comportamento aponta para pilhas de hospedagem e ambientes de desenvolvimento publicados indevidamente, em especial instalações XAMPP que incluem Apache, MySQL ou MariaDB, PHP ou Perl, ProFTPD e phpMyAdmin. Em configurações típicas, o XAMPP fica em /opt/lampp, enquanto o conteúdo web reside em /opt/lampp/htdocs. Quando o FTP concede escrita nesse diretório, uma autenticação com conta padrão ou senha fraca permite gravar uma web shell diretamente no caminho servido pelo HTTP. Depois disso, o atacante passa de credencial válida para execução de comandos no servidor web.

Após obter execução por web shell ou por outro vetor de implantação, a botnet baixa componentes adicionais. O artefato PHP associado ao hash SHA256 de7994277a81cf48f575f7245ec782c82452bb928a55c7fae11c2702cc308b8b foi observado com o mesmo mecanismo de autenticação usado anteriormente pela operação. A web shell invoca um script de atualização leve que tenta gravar e executar no diretório corrente; se não conseguir, muda para /tmp ou encerra. O script verifica o MD5 local de init_start, remove cópias divergentes, usa wget ou curl para buscar uma versão nova, ajusta permissão de execução e inicia o payload. O servidor remoto seleciona o binário conforme o parâmetro de arquitetura, com uso observado de uname -m e exemplo para x86_64.

Com o bot IRC ativo, os operadores passam a emitir comandos em canal compartilhado, permitindo que muitos hosts executem a mesma ação quase simultaneamente. Um comando recorrente baixa ou atualiza o bruteforcer por meio de test2.php; o script resultante obtém a arquitetura, compara checksum e salva o módulo como /tmp/init_stop. O binário é acionado periodicamente, com execução observada a cada 400 segundos, enquanto comandos de limpeza procuram processos contendo init_stop na linha de comando e aplicam kill -9 sob o mesmo usuário. Esse padrão encerra instâncias antigas do bruteforcer e também pode derrubar ferramentas de análise iniciadas com esse nome na linha de comando, como um depurador apontado para o arquivo.

Superfície afetada

A exposição relevante não se limita a servidores corporativos tradicionais. Qualquer VPS, instância em nuvem, laboratório esquecido, hospedagem compartilhada, ambiente de desenvolvimento publicado por engano ou servidor de aplicação com banco de dados acessível remotamente pode entrar no escopo se aceitar autenticação externa. A campanha ganha escala porque milhões de serviços FTP, MySQL e PostgreSQL continuam alcançáveis pela internet em portas padrão, e porque painéis phpMyAdmin permanecem associados a implantações web sem segmentação adequada. A exploração depende de acerto simultâneo de usuário válido, senha fraca e política de acesso que permita conexão remota; controles como bind local, allowlist de origem e autenticação forte reduzem a chance de sucesso mesmo quando uma senha aparece em lista de ataque.

O risco é maior em ambientes onde exemplos de documentação, tutoriais ou respostas de fórum foram promovidos a configuração real. Contas como appuser e myuser aparecem com frequência em instruções de implantação e também podem ser reproduzidas por assistentes de IA ao gerar arquivos Docker ou comandos de criação de banco. Isso não significa que a botnet identifique explicitamente servidores criados com IA, mas amplia a relevância defensiva de revisar configurações aceitas sem adaptação. Um serviço criado rapidamente com credenciais previsíveis, porta publicada e ausência de restrição por origem oferece exatamente as pré-condições que esse tipo de força bruta busca explorar.

• Servidores Linux com FTP exposto e permissão de escrita em diretórios servidos pelo web server.
• Instalações XAMPP em /opt/lampp que mantêm ProFTPD, phpMyAdmin ou contas padrão sem endurecimento posterior.
• MySQL e PostgreSQL aceitando login remoto com usuários operacionais previsíveis e senhas presentes em listas fracas.
• Painéis phpMyAdmin acessíveis pela internet, especialmente quando associados a WordPress e contas como root, wordpress ou wpuser.
• Hosts em provedores de nuvem ou VPS que não aplicam allowlist de origem, firewall local ou segmentação entre aplicação, banco e administração.

Hunting e telemetria

A busca deve combinar sinais de autenticação, criação de arquivo, execução de processo e comunicação de rede. Em FTP, procure logins bem-sucedidos para contas de serviço incomuns, especialmente daemon, nobody, apache, www, entradas relacionadas a WordPress e usuários que não deveriam ter acesso interativo. Em servidores XAMPP, qualquer escrita recente em /opt/lampp/htdocs seguida de requisição HTTP ao arquivo criado deve ser tratada como caminho de execução potencial. Em bancos de dados, revise falhas repetidas de autenticação distribuídas por várias origens e, em seguida, eventos de login bem-sucedido para usuários com nomes genéricos. O padrão de spray pode não gerar volume alto por origem única, já que a botnet distribui tarefas entre nós comprometidos.

No endpoint Linux, a presença de init_start fora do fluxo normal de implantação, de /tmp/init_stop com permissão executável ou de processos que iniciam scripts baixados por wget ou curl deve ser investigada. Também são relevantes comandos que consultam ipinfo.io para identificar organização do endereço público, porque operadores usaram esse serviço para distinguir provedores, procurar ambientes como DigitalOcean e OVH e filtrar possíveis honeypots, VPNs, proxies ou Tor. A telemetria deve registrar linha de comando completa, árvore de processo, usuário efetivo, diretório de trabalho e conexões de saída para IRC ou endpoints de atualização. A ausência de uma web shell conhecida não descarta comprometimento, pois foram observados hosts da botnet sem esse artefato instalado.

• Requisições HTTP para arquivos PHP recém-criados no webroot, especialmente após login FTP bem-sucedido.
• Arquivos executáveis chamados init_start ou init_stop, principalmente em /tmp ou em diretórios graváveis pelo usuário do serviço web.
• Execuções de wget ou curl originadas por processo do servidor web, interpretador PHP, conta de FTP ou usuário sem função administrativa.
• Comandos com uname -m usados para selecionar payload por arquitetura e chamadas para test2.php.
• Consultas de saída para ipinfo.io partindo de servidores que não deveriam executar validação manual de provedor.
• Processos encerrados por comandos com kill -9 associados a buscas por init_stop na linha de comando.
• Falhas de login em MySQL, PostgreSQL, FTP ou phpMyAdmin seguidas por sucesso para nomes como appuser, myuser, root, wordpress ou wpuser.

Mitigação

A resposta deve começar pela redução da superfície publicada. FTP, MySQL, PostgreSQL e phpMyAdmin não devem ficar diretamente expostos à internet sem necessidade operacional clara, restrição por origem e autenticação resistente a adivinhação. Bancos de dados devem escutar apenas em interfaces internas quando possível; quando o acesso remoto for obrigatório, aplique firewall, VPN, bastion, TLS quando aplicável e políticas de senha incompatíveis com listas comuns. Remova contas de demonstração, contas herdadas e usuários copiados de exemplos. Para ambientes criados a partir de assistentes de IA, trate o resultado como rascunho operacional: revise usuários, senhas, bind de rede, volumes, portas publicadas e variáveis de ambiente antes de levar a configuração para produção.

Em XAMPP, a medida correta é não usar a pilha como servidor de produção sem endurecimento explícito. Caso exista exposição real, execute a rotina de segurança do produto quando aplicável, remova ou desabilite FTP, altere credenciais padrão, restrinja phpMyAdmin a origem administrativa e impeça escrita no webroot por contas de serviço. Revise /opt/lampp/htdocs em busca de web shells, compare arquivos recentes com o controle de versão ou baseline de implantação e investigue qualquer arquivo PHP não reconhecido. Se houver indício de execução, contenha o host, preserve logs, colete árvore de processo, conexões de rede e artefatos em /tmp, depois reinstale componentes comprometidos a partir de imagem confiável.

Para hosts com sinais de GoBruteforcer, a rotação de credenciais precisa incluir bancos, FTP, painel administrativo, contas de aplicação e segredos que o servidor conseguia acessar. O comprometimento de um banco exposto pode revelar dados sensíveis e também credenciais armazenadas em tabelas, backups, arquivos .env ou diretórios de aplicação. Revogue acessos criados após a provável data de invasão, procure contas de backdoor, revise privilégios excessivos e valide se o host tentou autenticar contra terceiros. Como a máquina comprometida pode ter atuado como nó de força bruta, é necessário analisar tráfego de saída para FTP, MySQL, PostgreSQL e HTTP administrativo, não apenas indicadores locais de persistência.

• Remover exposição pública de FTP, MySQL, PostgreSQL e phpMyAdmin quando não houver requisito explícito de negócio.
• Aplicar allowlist de IP, firewall local e regras de segurança de nuvem para qualquer serviço administrativo que permaneça acessível remotamente.
• Substituir contas como appuser, myuser, root, wordpress e wpuser quando forem desnecessárias ou previsíveis, e impor senhas fortes ou autenticação alternativa suportada.
• Auditar XAMPP, ProFTPD e /opt/lampp/htdocs para credenciais padrão, escrita indevida e arquivos PHP não autorizados.
• Procurar e remover init_start, /tmp/init_stop e web shells somente após coleta forense suficiente para preservar evidência de origem, tempo de execução e comando recebido.
• Bloquear downloads não autorizados por wget e curl a partir de contas de serviço sempre que o modelo operacional permitir.
• Rotacionar credenciais e segredos acessíveis pelo host comprometido, incluindo senhas de banco, chaves de aplicação, variáveis de ambiente e contas usadas por pipelines.
• Monitorar novas tentativas distribuídas de login após a contenção, porque a mesma credencial pode ter sido compartilhada, vendida ou reutilizada em outras campanhas.