O rootkit PoisonedRefresh no F5 BIG IP APM está usando uma técnica capaz de complicar bastante a vida de quem ainda depende principalmente de arquivos para encontrar uma invasão.
Analisado pela Sophos X Ops em ambientes comprometidos, o malware consegue inserir uma web shell PHP diretamente na memória do processo Apache, sem precisar manter a versão final do código malicioso gravada no disco.
Na prática, o arquivo PHP analisado por uma ferramenta de segurança pode parecer perfeitamente legítimo enquanto o Apache e o PHP recebem, em memória, uma versão modificada contendo a web shell.
É uma diferença pequena na explicação, mas enorme durante uma investigação de incidente.
A Sophos afirma que o malware foi encontrado associado a ambientes BIG IP Access Policy Management, o APM, que utilizam componentes Apache e PHP. A F5 associa atividades relacionadas a sistemas BIG IP APM afetados pela CVE-2025-53521, vulnerabilidade de execução remota de código sem autenticação explorada quando uma política de acesso está configurada em um servidor virtual.
Os pesquisadores da ESET já haviam analisado o mesmo malware e deram a ele o nome PoisonedRefresh. A Sophos realizou sua própria análise e publicou detalhes adicionais sobre seu funcionamento.
PoisonedRefresh não funciona como uma web shell convencional
Normalmente, quando uma equipe de segurança procura uma web shell, uma das primeiras coisas a investigar são arquivos suspeitos dentro dos diretórios acessíveis pelo servidor web. Scripts PHP desconhecidos, alterações inesperadas e mudanças de integridade são alguns dos sinais mais óbvios.
O rootkit PoisonedRefresh no F5 BIG IP APM quebra justamente essa expectativa.
Segundo a análise da Sophos, o componente estudado corresponde ao segundo estágio da infecção. Durante uma investigação paralela de outra amostra, chamada umount, os pesquisadores encontraram um componente separado responsável por infectar o executável Apache localizado em /usr/sbin/httpd, modificar configurações do SELinux, implantar o segundo estágio e manter a persistência através dos processos de atualização do BIG IP.
Isso indica uma arquitetura de ataque dividida em estágios. Enquanto um componente cuida da implantação e persistência, o httpd infectado concentra as capacidades executadas durante o funcionamento do servidor.
É uma estrutura bem mais elaborada do que simplesmente jogar um PHP suspeito em algum diretório e torcer para ninguém perceber.
O rootkit assume o controle antes mesmo da aplicação começar
Uma das características mais interessantes do PoisonedRefresh está no momento em que ele começa a agir.
Em condições normais, programas Linux passam pelo processo de inicialização da libc antes de chegar à função main(). O malware intercepta a função __libc_start_main e coloca seu próprio código nesse caminho.
Com isso, consegue executar sua inicialização antes que a aplicação original comece efetivamente a trabalhar.
A Sophos também identificou um carregador ELF personalizado. O código abre sua própria imagem através de /proc/self/exe, localiza o executável original incorporado, carrega seus segmentos manualmente na memória e redireciona o fluxo de execução.
O resultado é que o código malicioso ganha uma posição privilegiada dentro de um processo que, externamente, continua sendo o Apache esperado naquele servidor.
O alvo é o Apache com PHP do BIG IP APM
Depois de conseguir executar antecipadamente, o PoisonedRefresh não começa a alterar tudo o que encontra. Ele espera pelo ambiente para o qual aparentemente foi construído.
O malware intercepta apr_dso_load, função do Apache Portable Runtime utilizada no carregamento de módulos. Quando identifica o carregamento da libphp, começa a modificar o comportamento do módulo PHP.
Essa seletividade é importante porque a pesquisa não sustenta a conclusão de que estamos diante de uma campanha genérica contra qualquer servidor Apache ou instalação PHP.
Pelo contrário. A Sophos afirma que as evidências observadas apontam para ambientes webtop do BIG IP APM. Os componentes utilizados, os arquivos escolhidos e até os fluxos de atualização do produto indicam um malware desenvolvido pensando nesse ambiente específico.
Também não existem evidências suficientes, até o momento, para atribuir o PoisonedRefresh a um grupo de ameaça específico.
A web shell aparece apenas na memória
Aqui está a parte que torna o rootkit PoisonedRefresh no F5 BIG IP APM particularmente interessante para equipes de segurança.
Depois que a libphp é carregada, o malware consulta /proc/self/maps para localizar exatamente onde o módulo está mapeado na memória. Em seguida, altera temporariamente permissões dessa região, modifica chamadas utilizadas pelo PHP e depois restaura as proteções.
Entre as operações interceptadas estão funções relacionadas à abertura, fechamento e mapeamento de arquivos na memória.
O PoisonedRefresh monitora especificamente três scripts PHP presentes no ambiente alvo: apm_css.php3, full_wt.php3 e webtop_popup_css.php3.
Quando o PHP abre um desses arquivos, o malware registra seu descritor. Quando o conteúdo é posteriormente mapeado, o implante cria uma representação diferente na memória, acrescentando a web shell ao conteúdo legítimo. O detalhe fundamental é que o arquivo armazenado no disco não precisa ser alterado.
Para uma ferramenta olhando apenas para o sistema de arquivos, existe um PHP legítimo. Para o processo comprometido, existe aquele mesmo PHP acompanhado de código malicioso.
É praticamente uma realidade paralela criada dentro do processo, e é justamente aí que algumas estratégias tradicionais de detecção começam a perder visibilidade.
Como a web shell do PoisonedRefresh recebe comandos
A carga PHP incorporada funciona de maneira semelhante a uma web shell tradicional, apesar da forma incomum utilizada para entregá la.
Segundo a Sophos, ela lê os dados brutos recebidos através de php://input, verifica um marcador específico no início da requisição, descriptografa o restante do conteúdo e executa o código recebido utilizando eval.
A resposta também tenta se misturar ao tráfego esperado.
O endpoint retorna o código HTTP 201 e informa Content-Type: text/css; charset=utf-8. Assim, uma operação envolvendo execução de código PHP pode aparentar estar relacionada ao carregamento de um recurso CSS.
A Sophos observou ainda que determinados valores da web shell são inseridos no código durante a execução, em vez de permanecerem armazenados em sua forma final dentro da amostra. Isso adiciona outra dificuldade para mecanismos que dependem exclusivamente de assinaturas estáticas.
PoisonedRefresh ainda oferece uma segunda porta de acesso
A web shell não é a única capacidade encontrada. O malware cria um socket Unix local em /run/bigtlog.pipe. Depois de uma pequena verificação de autenticação, a conexão pode ter entrada, saída e erros redirecionados para /bin/bash, oferecendo uma sessão interativa de shell.
Certamente a escolha de um socket Unix também tem uma consequência importante para a detecção.
Não existe a necessidade de abrir uma porta TCP para receber essas conexões. Portanto, uma ferramenta que procura exclusivamente portas de rede em estado de escuta pode simplesmente não enxergar esse mecanismo.
Os pesquisadores, porém, não encontraram no implante um componente capaz de acessar remotamente esse socket.
É possível imaginar que a web shell possa ser utilizada como caminho até ele, mas a própria Sophos deixa claro que não possui evidências para confirmar ou descartar essa hipótese. E onde a pesquisa termina, é melhor não preencher o espaço vazio com criatividade.
O que equipes de segurança podem procurar
A ausência da web shell no disco não significa que o PoisonedRefresh seja invisível. Significa que os sinais precisam ser procurados em outros lugares e, principalmente, correlacionados.
A Sophos destaca como relevantes requisições incomuns aos três arquivos .php3 envolvidos no ataque e respostas de endpoints PHP com HTTP 201 enquanto anunciam conteúdo CSS.
No servidor, processos worker do Apache acessando /proc/self/maps também merecem investigação, especialmente quando esse comportamento é seguido rapidamente por mudanças nas permissões das regiões de memória da libphp.
A criação do socket /run/bigtlog.pipe representa outro indicador. Processos relacionados ao Apache redirecionando seus fluxos padrão e executando /bin/bash também são comportamentos importantes durante uma investigação.
Nenhum desses sinais isoladamente comprova uma infecção. A recomendação da Sophos é tratá los como pontos de investigação e correlacioná los com evidências de integridade de arquivos, processos, memória e informações específicas do BIG IP.
Reiniciar o Apache pode não resolver o problema
Outro detalhe importante está na arquitetura em estágios identificada pelos pesquisadores.
Se o httpd foi infectado pelo componente responsável pela implantação e persistência, simplesmente reiniciar o serviço não deve ser encarado como garantia de remoção do comprometimento.
Em casos suspeitos, a Sophos recomenda preservar primeiro as evidências voláteis. Isso é especialmente relevante justamente porque uma parte fundamental da atividade maliciosa acontece na memória.
Para ambientes BIG IP APM potencialmente afetados, administradores também devem priorizar as orientações de remediação e avaliação de comprometimento fornecidas pela F5 antes de aplicar mudanças genéricas ao Apache ou PHP.
Bloquear a execução de arquivos .php3, por exemplo, pode fazer sentido em ambientes onde esse recurso não é necessário, mas a Sophos alerta explicitamente contra aplicar essa configuração indiscriminadamente em sistemas BIG IP APM sem considerar as recomendações da fabricante.
PoisonedRefresh mostra o limite da segurança baseada apenas em arquivos
E caros leitores(a) talvez essa seja a conclusão mais importante da análise. A web shell continua existindo e oferecendo uma capacidade bastante conhecida pelos atacantes: executar código no servidor através de requisições HTTP. O que mudou foi onde e como ela aparece.
O PoisonedRefresh combina carregamento ELF personalizado, interceptação precoce da inicialização do processo, monitoramento do Apache Portable Runtime, alterações na libphp e injeção da web shell exclusivamente na representação dos arquivos em memória.
Isso significa que aquilo que está gravado no armazenamento pode ser diferente daquilo que Apache e PHP efetivamente executam.
Para equipes responsáveis por infraestrutura crítica, a consequência é direta. Verificar apenas arquivos deixou de ser suficiente para determinados comprometimentos Linux. Telemetria de rede, comportamento de processos, integridade, análise de memória e correlação entre essas diferentes camadas passam a ter um peso ainda maior.
O PoisonedRefresh não torna a investigação impossível. Ele apenas explora uma suposição bastante conveniente que durante anos funcionou bem para defensores: se existe uma web shell sendo executada, em algum lugar deve existir um arquivo contendo aquela web shell. Neste caso, essa certeza simplesmente não existe.
