Nova variante adiciona comunicação ponto a ponto, mapeamento de portas via UPnP e troca de endereços de carteiras na área de transferência para manter fraudes mesmo sem C2 ativo.
| Componente | Botnet Phorpiex e nova variante Twizt, sucessora operacional associada ao ecossistema Tldr. |
| Vetor | Hosts já infectados monitoram a área de transferência para substituir endereços de carteiras e usam TCP ou UDP com comunicação ponto a ponto quando o C2 não está disponível. |
| Impacto | Entre novembro de 2020 e novembro de 2021, foram observadas 969 transações desviadas, somando 3,64 BTC, 55,87 ETH e US$ 55 mil em tokens ERC20. |
| Prioridade | Identificar endpoints infectados, conter comunicação P2P, revisar UPnP em roteadores expostos e validar manualmente endereços de carteiras antes de transações. |
| Artefatos | Amostras recentes incluem MD5 ec96bcc50ca8fa91821e820fdfe30915; infraestrutura citada inclui 185[.]215[.]113[.]66 e 185[.]215[.]113[.]84. |
| Carteiras | O recurso de clipping suporta mais de 30 tipos de carteiras, com menções a Bitcoin, Ethereum, Dogecoin, Dash, Monero, Zilliqa e outros serviços de ativos digitais. |
A botnet Phorpiex, conhecida desde 2016, voltou a apresentar atividade relevante após um período de queda abrupta nos servidores de comando e controle durante 2021. O ecossistema havia passado por mudanças anteriores: o bot inicial associado ao protocolo IRC, também chamado Trik, foi substituído em 2018 e 2019 por uma arquitetura modular em que o loader Tldr passou a operar por HTTP. Em 2019, a base infectada estimada para Tldr ultrapassava um milhão de computadores, o que explica por que a botnet continuou representando risco mesmo quando sua infraestrutura central ficou instável.
A nova peça observada, chamada Twizt, altera a resiliência operacional da Phorpiex. Em vez de depender exclusivamente de servidores C2 ativos, a variante pode operar em modo ponto a ponto, permitindo que máquinas infectadas encaminhem comandos a outros bots. Esse desenho reduz o efeito de derrubadas pontuais de infraestrutura, porque parte da rede maliciosa continua funcional mesmo quando os servidores centrais ficam indisponíveis. Para defensores, isso muda a prioridade de resposta: bloquear apenas endereços de C2 conhecidos não basta quando os próprios hosts comprometidos podem participar da distribuição de comandos.
A monetização principal permanece ligada ao roubo de transações de criptomoedas por crypto-clipping. O malware observa a área de transferência e troca endereços de carteiras copiados pelo usuário por endereços controlados pelos operadores. Como endereços de blockchains populares são longos e frequentemente copiados e colados, a vítima pode concluir a transação sem perceber que o destino foi alterado. Uma vez confirmada na blockchain, a transferência não pode ser revertida sem controle das chaves privadas da carteira de destino, o que torna a prevenção e a detecção local mais importantes do que a recuperação posterior.
O Twizt mantém características de persistência e inicialização próximas às do Tldr, mas adiciona recursos específicos para comunicação distribuída e clipping. A variante usa um protocolo binário próprio sobre TCP ou UDP, com camadas de criptografia RC4 para proteger dados trafegados entre nós. A integridade das mensagens é verificada com RSA e função de hash RC6-256. Esse conjunto não deve ser interpretado como proteção legítima: no contexto da botnet, ele dificulta inspeção, classificação de tráfego e análise de conteúdo por controles de rede que dependem de padrões claros.
Para receber conexões de outros bots mesmo atrás de roteadores residenciais com NAT, o Twizt usa SSDP para descobrir dispositivos de gateway na rede local. A busca ocorre por UDP, no grupo multicast 239[.]255[.]255[.]250 e porta 1900, procurando dispositivos que exponham serviços UPnP. Quando o roteador responde e fornece informações de controle, o malware consulta o serviço e tenta configurar mapeamento de portas TCP e UDP para a porta usada pela amostra. Foram observadas portas como 48755, 40555 e 40500. O resultado esperado para o operador é transformar um endpoint residencial comprometido em nó alcançável por outros bots.
O mecanismo de crypto-clipping é implementado pela criação de uma janela de mensagem com classe aleatória, usando HWND_MESSAGE como janela pai. A função responsável pela substituição de conteúdo da área de transferência é registrada como procedimento dessa janela. Na prática, quando o usuário copia um endereço de carteira e o cola em uma aplicação, o malware tenta trocar o destino legítimo por uma carteira do operador. O recurso suporta 35 tipos de carteiras na variante nova, ampliando a cobertura para diferentes blockchains e serviços de ativos digitais.
A comunicação ponto a ponto também inclui atualização de lista de nós. Versões iniciais continham apenas um endereço IP de C2 embutido, enquanto versões posteriores passaram a carregar uma configuração com 512 endereços de nós. A lista também pode ser atualizada por outro nó infectado ou pelo C2. As mensagens trocadas carregam identificadores dos nós e uma lista de entradas com endereços e um campo de ranqueamento associado ao tempo desde que o nó esteve online. Esse desenho ajuda a priorizar peers ativos e a manter a botnet conectada mesmo com rotação parcial da infraestrutura.
A superfície afetada é composta principalmente por endpoints Windows já infectados pela Phorpiex ou por sua nova variante Twizt, especialmente quando usuários realizam transações com criptomoedas nesses sistemas. O risco é maior quando o usuário depende de copiar e colar endereços de carteira, porque o fluxo de ataque se aproveita de um comportamento normal em transações com endereços longos. A ameaça não exige que a vítima interaja com um servidor C2 no momento da transação: se o componente de clipping estiver instalado e ativo, a substituição pode ocorrer localmente.
A botnet foi observada em 96 países em 2021, com maior concentração de vítimas na Etiópia, Nigéria e Índia. Mesmo durante períodos de inatividade dos servidores C2, a quantidade de vítimas permaneceu quase constante e voltou a crescer nos dois meses anteriores à análise. Esse comportamento é compatível com uma botnet persistente em que máquinas comprometidas continuam executando funções de monetização mesmo quando a infraestrutura de comando não está totalmente disponível.
Algumas amostras recentes verificam a localidade padrão do usuário e deixam de executar quando a abreviação é UKR, associada à Ucrânia. Esse detalhe não confirma autoria, mas é um indício operacional comum em famílias de malware que evitam execução em determinadas regiões. A atribuição deve permanecer limitada ao que é observável: há uma condição de execução baseada em localidade, mas o contexto não permite transformar isso em identificação conclusiva dos operadores.
- Endpoints infectados por Phorpiex/Twizt com acesso a carteiras, exchanges ou aplicações usadas para transferências de criptomoedas.
- Redes com roteadores que mantêm UPnP habilitado e aceitam mapeamento de portas a partir de hosts internos.
- Ambientes em que usuários copiam endereços de carteiras para a área de transferência antes de concluir transações.
- Controles baseados apenas em bloqueio de C2 central, sem visibilidade sobre comunicação P2P entre hosts infectados.
A caça deve combinar sinais de endpoint, rede local e comportamento de usuário. No endpoint, a defesa deve procurar processos desconhecidos que interajam de forma incomum com a área de transferência, criem janelas de mensagem sem interface visível ou mantenham persistência semelhante à observada no ecossistema Tldr. A presença do MD5 ec96bcc50ca8fa91821e820fdfe30915 pode ajudar em triagens pontuais, mas não deve ser o único critério de detecção, porque variantes recompiladas podem alterar hashes sem mudar a lógica operacional.
Na rede, um sinal relevante é a descoberta SSDP e a tentativa de manipular UPnP a partir de estáções de trabalho que não deveriam configurar roteadores. Consultas para 239[.]255[.]255[.]250 na porta 1900 podem ser legítimas em alguns ambientes, por isso a análise precisa considerar origem, frequência e sequência de eventos. A combinação de descoberta SSDP, consulta a descrições XML de gateway e criação de mapeamento de portas TCP ou UDP é mais forte do que qualquer evento isolado.
Também é importante inspecionar conexões TCP ou UDP para pares externos em portas incomuns associadas ao malware, incluindo 48755, 40555 e 40500 quando aparecerem fora de padrões esperados. Como a variante usa protocolo próprio e criptografia, o conteúdo pode não ser legível em inspeção comum, mas metadados de fluxo, fan-out para múltiplos pares, conexões persistentes e tráfego para IPs relacionados à infraestrutura observada podem sustentar uma investigação. Endereços como 185[.]215[.]113[.]66 e 185[.]215[.]113[.]84 devem ser tratados como indicadores defangados para correlação histórica, não como lista completa de infraestrutura.
Em transações de criptomoedas, sinais de usuário também ajudam. Casos em que a carteira colada diverge da carteira copiada, tentativas repetidas de envio para o mesmo destino inesperado e histórico local de área de transferência alterada antes da confirmação podem indicar clipping. Organizações que lidam com ativos digitais devem registrar validações de destino, exigir conferência fora do endpoint comprometível e comparar endereços em telas independentes antes de autorizar transferências.
- Processos desconhecidos monitorando ou alterando a área de transferência em hosts usados para transações.
- Tráfego SSDP para 239[.]255[.]255[.]250:1900 seguido de consultas UPnP e criação de mapeamentos de portas.
- Conexões TCP ou UDP para múltiplos peers em portas como 48755, 40555 ou 40500 sem justificativa operacional.
- Carteiras coladas em aplicações que não correspondem ao endereço originalmente copiado pelo usuário.
- Comunicação com infraestrutura histórica defangada 185[.]215[.]113[.]66 ou 185[.]215[.]113[.]84 em contexto de host suspeito.
A resposta deve começar pela contenção dos endpoints suspeitos, porque a função de clipping opera localmente e pode continuar mesmo sem C2 disponível. Máquinas usadas para transferências de criptomoedas devem ser isoladas quando houver indício de alteração de área de transferência, comunicação P2P suspeita ou configuração UPnP inesperada. A limpeza precisa validar persistência, processos carregados, artefatos no perfil do usuário e comunicação de rede após reinicialização. Apenas encerrar uma conexão externa não elimina a capacidade local de substituir endereços.
Em redes domésticas, pequenas empresas e ambientes híbridos, UPnP deve ser revisto com prioridade. Roteadores que aceitam mapeamento automático de portas por qualquer host interno aumentam a utilidade da máquina infectada dentro da botnet. Quando a função não for necessária, a recomendação defensiva é desabilitar UPnP e remover mapeamentos de portas desconhecidos. Em ambientes corporativos, a criação de regras de encaminhamento em gateways deve depender de processo administrativo explícito, não de solicitação automática de estáções de trabalho.
Para reduzir perdas financeiras, fluxos de transferência de criptomoedas precisam incluir validação independente do endereço de destino. A conferência deve ocorrer antes da assinatura ou confirmação da transação, porque a reversão posterior é inviável na maioria dos cenários. Usuários e equipes responsáveis por tesouraria digital devem comparar início, meio e fim do endereço, usar listas de destino aprovadas quando possível e evitar confirmar operações sensíveis em sistemas que também sejam usados para navegação comum, e-mail ou execução de software não controlado.
Bloqueios de rede devem ser tratados como camada complementar. A botnet já demonstrou capacidade de voltar a operar após troca de endereços de infraestrutura e pode receber listas atualizadas de nós. Por isso, controles de EDR, inventário de persistência, política de roteadores, monitoramento de clipboard em contexto sensível e validação de transações devem atuar em conjunto. A prioridade operacional é remover hosts infectados da rede, impedir que atuem como peers e cortar a oportunidade de substituição de carteiras no momento da transferência.
- Isolar endpoints suspeitos antes de realizar novas transações de ativos digitais.
- Desabilitar UPnP quando não houver necessidade operacional e remover mapeamentos de portas desconhecidos.
- Validar endereços de carteiras por canal independente antes de confirmar transferências.
- Correlacionar eventos de clipboard, persistência local, SSDP, UPnP e tráfego P2P para confirmar comprometimento.
- Atualizar controles de endpoint para detectar variantes por comportamento, não apenas por hashes específicos.
0 Comentários