Campanha observada em 2019 usava ThinkPHP como vetor inicial, persistência via cron, comunicação HTTP com C2 e propagação por vulnerabilidades em JBoss, WebLogic, Hadoop YARN e ActiveMQ.
| Componente | Backdoor SpeakUp, servidores Linux expostos à internet, instâncias em AWS, aplicações ThinkPHP, JBoss, WebLogic, Hadoop YARN e ActiveMQ vulneráveis. |
| Vetor | Exploração remota de CVE-2018-20062 no ThinkPHP para acionar injeção de comandos, criar um shell PHP temporário e carregar um backdoor Perl chamado ibus. |
| Impacto | Execução arbitrária de código no host infectado, registro em C2 HTTP, persistência via cron, varredura de sub-redes internas e externas, propagação para novos servidores e implantação de mineradores XMRig. |
| Prioridade | Remover exposição de serviços vulneráveis, corrigir aplicações citadas, investigar criação anômala de shells PHP, tarefas cron suspeitas, execução de Perl em /tmp e comunicação HTTP com domínios C2 defangados. |
| Versões e artefatos | A amostra observada informava versão interna 1.0.4, usava codificação salted base64 na segunda etapa e no tráfego de comando e controle, e se comunicava com speakupomaha[.]com como C2 principal. |
| IoCs | Foram associados múltiplos hashes, domínios, IPs e carteiras Monero; para publicação defensiva, os indicadores devem ser tratados como classes de telemetria, com exemplos defangados como 67[.]209[.]177[.]163 e speakupomaha[.]com. |
SpeakUp foi observado como um trojan de backdoor voltado a servidores Linux, com capacidade de instalação remota, comunicação com infraestrutura de comando e controle, persistência local e propagação automatizada. A cadeia descrita começava em aplicações ThinkPHP vulneráveis, especialmente quando o serviço ficava exposto à internet e aceitava requisições capazes de atingir a falha CVE-2018-20062. A exploração não dependia de credenciais válidas no fluxo apresentado: o operador abusava de execução remota de comandos para posicionar um shell PHP e, a partir dele, carregar um script Perl identificado como ibus. O nome tenta se misturar a um componente legítimo de entrada multilíngue usado em sistemas Linux e Unix, mas o conteúdo do arquivo não correspondia à função do projeto legítimo.
A campanha mirava servidores no Leste Asiático e na América Latina, incluindo máquinas hospedadas em AWS. Depois do comprometimento inicial, o malware registrava o host no C2, coletava informações de identificação, mantinha um intervalo fixo de consulta por novas tarefas e recebia instruções para executar código, baixar arquivos, remover componentes ou atualizar dados de fingerprint. No momento descrito, a carga adicional observada incluía mineradores XMRig, com carteiras relacionadas contendo aproximadamente 107 Monero. O desenho do malware, entretanto, não se limitava à mineração: a presença de módulos de varredura, propagação e execução arbitrária indicava uma plataforma capaz de receber cargas diferentes se o operador decidisse alterar o objetivo da campanha.
A atribuição permaneceu limitada. Foram observadas relações técnicas entre strings, convenções de nomenclatura e um desenvolvedor associado ao nome Zettabit ou zettabithf, inclusive semelhanças conceituais com o bot liteHTTP. Essa correlação não transforma a identidade do operador em fato confirmado. Para defesa, o ponto central é a combinação de falhas antigas em middleware exposto, execução de scripts em diretórios temporários, persistência por agendamento e tráfego HTTP codificado para C2.
O primeiro estágio explorava ThinkPHP por meio de uma requisição HTTP GET capaz de acionar execução remota de comandos no servidor. A requisição criava um shell PHP simples no ambiente vulnerável, e esse shell passava a aceitar comandos por um parâmetro de consulta. Em seguida, o operador instruía o host a buscar a carga ibus de uma infraestrutura remota defangada como 67[.]209[.]177[.]163, salvar o conteúdo em /tmp, executar o script Perl e remover o arquivo logo depois. O efeito defensivamente relevante é a sequência de escrita temporária, execução por intérprete e apagamento, que reduz artefatos triviais no disco, mas ainda deixa rastros em logs HTTP, auditoria de processo, metadados de cron, histórico de rede e telemetria de endpoint.
A segunda etapa foi ofuscada com salted base64, mecanismo também usado no tráfego de comando e controle. O malware fazia comunicação HTTP por métodos GET e POST com o C2 principal defangado speakupomaha[.]com. No primeiro contato, enviava um identificador da vítima e dados introdutórios, incluindo a versão interna do script, observada como 1.0.4. Quando o servidor classificava a vítima como nova, a resposta indicava a necessidade de registro. Depois disso, o trojan coletava informações completas do sistema por comandos locais do Linux, sem que seja necessário reproduzir comandos operacionais para fins defensivos. A partir do registro, a vítima passava a consultar o C2 em um intervalo fixo para receber tarefas.
As tarefas documentadas incluíam execução arbitrária no host, download e execução de arquivos vindos de servidores remotos, encerramento do programa, desinstalação e atualização de dados de fingerprint. A persistência era mantida com cron, e um mutex interno reduzia a chance de múltiplas instâncias concorrentes rodarem no mesmo host. O tráfego HTTP também usava User-Agents específicos, incluindo dois aparentando ambientes Mac OS X e uma string hash associada à palavra liteHTTP. Esses valores são úteis para hunting quando correlacionados com outros sinais, mas não devem ser usados isoladamente como prova de infecção, porque User-Agent é um campo fácil de falsificar.
Após estabelecer presença, SpeakUp implantava um script Python de propagação capaz de varrer sub-redes internas e faixas externas. O módulo tentava explorar vulnerabilidades conhecidas em JBoss Enterprise Application Platform, JBoss Seam, JBoss AS, Oracle WebLogic, Hadoop YARN ResourceManager e Apache ActiveMQ. Entre as falhas citadas estavam CVE-2012-0874, CVE-2010-1871, CVE-2017-10271, CVE-2018-2894 e CVE-2016-3088, além de caminhos de execução remota conhecidos para JBoss AS e Hadoop YARN. Quando uma exploração era bem-sucedida, a cadeia reutilizava a implantação do script ibus no novo servidor, ampliando a presença dentro da rede ou para novos endereços alcançáveis.
A superfície mais crítica era formada por servidores Linux com aplicações ou middleware expostos à internet e sem correções para falhas já conhecidas. O vetor inicial explicitamente documentado dependia de ThinkPHP vulnerável a CVE-2018-20062, mas a fase de propagação ampliava o risco para ambientes com JBoss, WebLogic, Hadoop YARN e ActiveMQ acessíveis a partir do host comprometido. Isso muda a prioridade de resposta: não basta corrigir o ponto inicial se o servidor já foi usado como pivô de varredura. A investigação precisa cobrir serviços adjacentes, rotas internas alcançáveis, instâncias em nuvem, imagens antigas e sistemas de teste deixados com portas administrativas expostas.
Instâncias em AWS aparecem no escopo observado, mas o problema descrito não depende de um recurso exclusivo de nuvem. O risco surge quando aplicações vulneráveis ficam acessíveis por rede, quando grupos de segurança permitem entrada ampla, quando serviços legados permanecem sem atualização e quando a telemetria de processo não cobre intérpretes como PHP, Perl e Python em diretórios temporários. Em ambientes híbridos, o host infectado pode atuar como origem de varreduras contra blocos internos, sistemas de desenvolvimento e serviços de middleware que não deveriam receber tráfego direto de aplicações públicas.
- Servidores Linux com ThinkPHP vulnerável a
CVE-2018-20062e rotas expostas para execução remota de comandos. - Hosts capazes de executar PHP, Perl e Python a partir de diretórios temporários, especialmente
/tmp, sem controles de execução ou monitoramento de processo. - Ambientes com JBoss, WebLogic, Hadoop YARN ResourceManager ou ActiveMQ desatualizados e acessíveis a partir de redes comprometidas.
- Instâncias em nuvem com regras de entrada amplas, ausência de segmentação entre aplicações e serviços administrativos, ou logs de rede insuficientes.
- Sistemas nos quais tarefas cron podem ser criadas por usuários de serviço comprometidos sem alerta de integridade.
A caça deve começar pelo encadeamento temporal entre requisições HTTP anômalas, criação de arquivo PHP inesperado, execução de Perl em /tmp, remoção rápida de artefatos e saída HTTP para infraestrutura externa. Em servidores web, logs de acesso podem revelar parâmetros usados para acionar módulos não previstos, tentativas de invocar funções internas e padrões de requisição incompatíveis com o comportamento normal da aplicação. O conteúdo exato de payloads não precisa ser reproduzido: o sinal está na tentativa de transformar uma aplicação PHP em lançador de comandos e no posterior uso de intérpretes de sistema para carregar uma carga remota.
No endpoint, os sinais mais úteis incluem processos filhos incomuns do servidor web, execução de perl com origem em diretório temporário, criação ou alteração de entradas cron, conexões periódicas HTTP com User-Agents atípicos e downloads vindos de endereços IP diretamente referenciados em vez de repositórios aprovados. A comunicação com C2 era codificada, então inspeção de conteúdo pode não revelar comandos legíveis; por isso, metadados de tráfego, periodicidade, destino, método HTTP, tamanho de requisições e relação com eventos de processo são mais importantes. O domínio C2 speakupomaha[.]com e o IP defangado 67[.]209[.]177[.]163 podem orientar pesquisa histórica, mas devem ser enriquecidos com data, resolução DNS, proxy, NetFlow e evidência local antes de qualquer conclusão.
Também é necessário procurar atividade de mineração. A implantação de XMRig pode aparecer como uso persistente de CPU, processos com nomes mascarados, conexões para pools de mineração, arquivos temporários fora do padrão e queda de desempenho em servidores sem carga compatível. A existência de carteiras Monero associadas à campanha indica monetização por mineração, mas não limita o risco. Como SpeakUp aceitava tarefas para execução e download de arquivos, um ambiente infectado deve ser tratado como host com execução remota sob controle externo até que análise de integridade e contenção confirmem o contrário.
- Requisições HTTP para aplicações ThinkPHP com parâmetros que acionam execução de funções e escrita de arquivos PHP fora do fluxo normal.
- Processos
php,perloupythoniniciados pelo usuário do servidor web, principalmente com artefatos temporários em/tmp. - Criação, alteração ou remoção de entradas cron próximas ao horário de requisições suspeitas ou downloads externos.
- Comunicação HTTP periódica com destinos defangados associados à campanha, User-Agents incomuns e dados codificados sem perfil de aplicação legítima.
- Varreduras originadas do servidor comprometido contra JBoss, WebLogic, Hadoop YARN e ActiveMQ em sub-redes internas ou faixas externas.
- Indícios de XMRig, incluindo consumo anormal de CPU, processos persistentes sem justificativa operacional e tráfego para serviços de mineração.
A resposta deve tratar o caso como comprometimento ativo quando houver evidência de execução do backdoor. A primeira medida é isolar o servidor afetado da comunicação de saída e da conectividade lateral, preservando logs, disco e memória sempre que possível. Em seguida, é necessário validar se houve exploração inicial por ThinkPHP, remover shells PHP não autorizados, revisar diretórios temporários, entradas cron, processos persistentes e contas de serviço. Como a carga remove arquivos após a execução, a ausência do artefato ibus no disco não elimina a hipótese de infecção; correlação entre logs web, eventos de processo e tráfego de rede é essencial.
A correção envolve atualizar ou desativar componentes vulneráveis, começando por ThinkPHP quando presente, e depois avaliando JBoss, WebLogic, Hadoop YARN e ActiveMQ acessíveis pela rede. Sistemas que não podem ser corrigidos imediatamente devem sair da exposição direta, receber filtragem por origem confiável e ficar atrás de controles de aplicação ou segmentação. Em nuvem, a revisão deve incluir grupos de segurança, listas de controle de rede, balanceadores, regras de saída e inventário de instâncias antigas. A contenção também precisa impedir que o host comprometido alcance serviços internos que não fazem parte do fluxo de aplicação.
Depois da remoção, equipes devem rotacionar credenciais que possam ter sido acessíveis ao host, revisar chaves de implantação, tokens de automação, variáveis de ambiente e permissões de contas usadas pelo servidor web. O material analisado não confirma roubo de dados ou credenciais, portanto a rotação é uma medida de redução de risco para qualquer host com execução arbitrária de código, não uma afirmação de exfiltração. A validação final deve incluir varredura autenticada de vulnerabilidades, comparação de integridade de arquivos, análise de persistência, revisão de telemetria histórica e bloqueio de indicadores defangados em controles de rede quando compatível com a política interna.
- Isolar hosts com evidência de exploração, preservando logs HTTP, eventos de processo, cron, DNS, proxy e NetFlow.
- Corrigir ThinkPHP afetado por
CVE-2018-20062e revisar exposição de JBoss, WebLogic, Hadoop YARN e ActiveMQ citados na cadeia de propagação. - Remover shells PHP não autorizados, scripts Perl ou Python suspeitos, entradas cron persistentes e binários de mineração sem origem aprovada.
- Bloquear ou monitorar comunicação com domínios e IPs defangados associados, usando correlação temporal em vez de bloqueio isolado como prova de incidente.
- Revisar regras de entrada e saída em nuvem, segmentar sub-redes e limitar a capacidade de servidores web iniciarem conexões arbitrárias para a internet.
- Rotacionar segredos acessíveis ao host comprometido e validar que não restaram tarefas agendadas, processos de mineração ou mecanismos de reinstalação.
0 Comentários