Variante do malware bancário reconstrói o IP do servidor C2 a partir de valores de transações associadas a uma carteira Bitcoin codificada no binário, dificultando bloqueios baseados apenas em infraestrutura estática.
| Componente | Redaman, malware bancário anteriormente reportado como RTM banking Trojan, com rotina para localizar servidores C2 por meio da blockchain do Bitcoin. |
| Vetor | Campanhas de phishing voltadas principalmente a falantes de russo distribuem o malware; após a execução, o binário consulta transações recentes de uma carteira Bitcoin codificada. |
| Impacto | O endereço IP do C2 é reconstruído a partir de valores de transações, permitindo troca dinâmica de infraestrutura sem depender de IPs fixos embutidos no malware. |
| Prioridade | Procurar endpoints que consultem APIs públicas de blockchain logo após infecção por phishing, correlacionar a carteira 1BkeGqpo8M5KNVYXW3obmQt1R58zXAqLBQ e bloquear comunicação com o C2 defangado 185[.]203[.]116[.]47 quando observado. |
| Artefatos | Carteira Bitcoin 1BkeGqpo8M5KNVYXW3obmQt1R58zXAqLBQ, valores de transação 0.00052153 BTC e 0.00012148 BTC, e consulta HTTP a serviço público de blockchain. |
| IoCs | IP C2 citado no contexto: 185[.]203[.]116[.]47; carteira Bitcoin associada à técnica: 1BkeGqpo8M5KNVYXW3obmQt1R58zXAqLBQ. |
Uma variante do Redaman, malware bancário observado desde 2015 e também associado ao nome RTM banking Trojan, passou a usar a blockchain do Bitcoin como mecanismo de descoberta de comando e controle. O ponto central da técnica não é minerar criptomoeda nem movimentar grandes valores, mas transformar transações públicas em um canal indireto de configuração. Em vez de carregar somente um endereço IP fixo dentro do binário, a amostra consulta uma carteira Bitcoin previamente codificada e interpreta valores de pagamentos recentes como material para recompor o endereço do servidor C2. Essa abordagem desloca parte da infraestrutura de configuração para um registro público, distribuído e resistente a remoções simples.
O fluxo documentado envolve a carteira 1BkeGqpo8M5KNVYXW3obmQt1R58zXAqLBQ e a recuperação das últimas dez transações associadas a ela. A partir das duas últimas transações de pagamento relevantes, o malware extrai valores decimais, converte esses números para hexadecimal, rearranja bytes e reconstrói quatro octetos que formam o endereço IP final. O exemplo citado no contexto resulta no C2 185[.]203[.]116[.]47, derivado dos valores 52153 e 12148, representados nas transações como 0.00052153 BTC e 0.00012148 BTC. Para defesa, isso cria um sinal misto: há tráfego aparentemente legítimo para uma API de blockchain, mas a finalidade real é obter infraestrutura de controle.
A técnica é relevante porque reduz a eficácia de controles que dependem apenas de IPs codificados no malware ou de indicadores estáticos extraídos de uma amostra isolada. Se o operador alterar os valores publicados em transações futuras, uma mesma lógica no endpoint infectado pode apontar para outro servidor sem que o binário precise ser recompilado. Ao mesmo tempo, a cadeia deixa rastros próprios: carteira específica, padrão de consulta a transações recentes, conversões numéricas incomuns dentro do processo e comunicação subsequente com o IP reconstruído. Esses elementos permitem construir detecção comportamental, principalmente quando combinados com evidência de phishing, execução de malware bancário e conexões HTTP para serviços de blockchain.
A cadeia começa com distribuição por phishing, com alvo predominante em usuários falantes de russo. Após a execução no sistema comprometido, o Redaman não depende apenas de um endereço de comando e controle literal embutido no arquivo. O binário contém a referência à carteira Bitcoin e realiza uma requisição do tipo GET para obter um conjunto limitado de transações recentes. A consulta citada usa uma API pública de blockchain para recuperar os últimos registros da carteira, o que pode parecer tráfego comum de consulta financeira ou de software legítimo que interage com criptomoedas. O uso defensivo desse detalhe exige correlação com processo, linha do tempo, origem da execução e ausência de justificativa de negócio no endpoint.
O mecanismo de codificação usa valores de transação como portadores de informação. No exemplo, o operador parte do IP 185[.]203[.]116[.]47 e converte seus octetos para hexadecimal, obtendo os bytes B9, CB, 74 e 2F. Os dois primeiros octetos são agrupados com inversão de ordem para produzir CBB9, que em decimal corresponde a 52153. Os dois últimos passam pelo mesmo raciocínio e geram 2F74, equivalente a 12148. Esses números aparecem como valores fracionários de Bitcoin em pagamentos ligados à carteira, permitindo que o malware recupere o conteúdo sem que o endereço IP apareça diretamente na transação como texto.
Na etapa de decodificação, o Redaman lê os valores das duas transações de pagamento, remove a escala usada no valor em Bitcoin, converte os números decimais de volta para hexadecimal e separa os bytes. Depois, inverte a ordem dos pares para reconstruir os quatro octetos do IP. O resultado é usado como destino de comando e controle. O contexto também indica que a carteira não era reconhecida como maliciosa em bases de blockchain mencionadas, o que mostra uma limitação comum de reputação isolada: uma carteira pode não ter histórico suficiente para ser classificada, mas ainda assim servir como mecanismo de configuração para malware.
A técnica chamada de encadeamento se apoia em uma propriedade operacional importante: o atacante consegue atualizar a infraestrutura publicando novas transações de baixo valor, enquanto o malware precisa apenas consultar registros recentes e aplicar a mesma lógica de transformação. Diferentemente de domínios DGA, que costumam deixar padrões em DNS, esse método desloca a resolução para uma API de terceiros e para dados financeiros públicos. O defensor deve tratar a consulta à blockchain como parte da cadeia de controle quando ela ocorrer em processos sem relação legítima com carteiras, exchanges, nós de criptomoeda ou softwares de contabilidade.
A exposição principal recai sobre estáções de trabalho e ambientes de usuário final atingidos por phishing, especialmente onde anexos, documentos ou links maliciosos conseguem iniciar a execução do Redaman. Como o malware é bancário, a superfície de risco inclui navegadores, sessões autenticadas, sistemas usados para operações financeiras e máquinas de usuários que acessam serviços bancários ou administrativos. O contexto não confirma roubo de dados específico nesta variante, portanto o impacto técnico sustentado é a capacidade de estabelecer ou localizar infraestrutura C2 por meio de transações Bitcoin e manter comunicação dinâmica após a infecção.
Sistemas de segurança que bloqueiam somente IPs conhecidos podem perder visibilidade quando o binário não carrega um destino estático final ou quando esse destino é atualizado fora do malware. Proxies corporativos e ferramentas EDR podem observar uma sequência útil: execução originada de vetor de phishing, acesso a serviço público de blockchain, interpretação de valores de transação e conexão posterior com o endereço reconstruído. Ambientes que permitem acesso irrestrito a APIs externas reduzem a chance de distinguir tráfego legítimo de consulta de criptomoedas de tráfego usado como configuração maliciosa.
A carteira 1BkeGqpo8M5KNVYXW3obmQt1R58zXAqLBQ é um artefato relevante para busca histórica, mas não deve ser tratada como único ponto de controle. O comportamento é mais importante que o indicador isolado: uma amostra pode carregar outra carteira, outro serviço de consulta ou outro esquema de escala numérica, mantendo o mesmo princípio. A superfície também inclui logs de proxy, DNS, firewall, endpoint, memória de processo e telemetria de rede capaz de correlacionar o acesso à API com o C2 resultante.
- Endpoints de usuários expostos a phishing e execução de malware bancário Redaman.
- Processos sem função legítima de criptomoeda realizando requisições HTTP para APIs públicas de blockchain.
- Controles baseados apenas em IP fixo ou reputação de carteira, sem correlação comportamental.
- Ambientes em que tráfego para serviços de blockchain não é categorizado, revisado ou associado ao processo de origem.
A investigação deve partir da cadeia temporal. Um caso suspeito combina recebimento ou abertura de conteúdo de phishing, criação de processo anômalo, consulta a serviço de blockchain e conexão posterior com infraestrutura externa que não aparece de forma clara em configuração local. Em logs de proxy, a consulta à carteira 1BkeGqpo8M5KNVYXW3obmQt1R58zXAqLBQ é um pivô direto para busca histórica. Quando o ambiente armazena corpo de resposta ou metadados de URL, a presença de parâmetros de limite para poucas transações recentes pode reforçar a hipótese de recuperação automatizada de configuração.
No endpoint, a defesa deve procurar processos que façam chamadas de rede para serviços de blockchain sem relação com navegadores, carteiras autorizadas ou aplicações conhecidas. A sequência de conversões decimal-hexadecimal e manipulação de bytes é mais difícil de observar diretamente sem análise de memória ou engenharia reversa, mas pode aparecer como constantes, rotinas aritméticas ou buffers contendo os valores B9, CB, 74 e 2F próximos da rotina de rede. O IP 185[.]203[.]116[.]47, quando presente em conexões subsequentes, deve ser correlacionado com a consulta anterior à carteira, não analisado como evento isolado.
A telemetria de rede pode identificar o padrão em duas camadas. A primeira é o acesso à API de blockchain a partir de hosts que não têm justificativa para esse tipo de tráfego. A segunda é a conexão de saída para o IP reconstruído após a resposta da API. Em ambientes com inspeção TLS limitada, ainda é possível usar metadados como processo de origem, domínio de destino da API, volume pequeno de dados, intervalo curto entre consulta e conexão C2 e repetição em múltiplos hosts. Em EDR, a busca deve incluir artefatos do Redaman e do antigo nome RTM banking Trojan quando essa nomenclatura estiver indexada.
A carteira citada também permite uma verificação de escopo: hosts que consultaram dados relacionados a ela podem ser priorizados para triagem. No entanto, a ausência desse artefato não elimina a técnica, porque o operador pode trocar a carteira ou alterar a forma de consulta. Detecções robustas devem combinar indicador, categoria de tráfego, processo, sequência de eventos e comportamento pós-consulta. Para reduzir falso positivo, diferencie máquinas de usuários comuns de sistemas que realmente executam clientes, integrações ou auditorias relacionadas a Bitcoin.
- Requisições de processos incomuns para APIs de blockchain, especialmente logo após execução originada por phishing.
- Consulta associada à carteira 1BkeGqpo8M5KNVYXW3obmQt1R58zXAqLBQ em logs de proxy, DNS ou firewall.
- Conexões de saída para 185[.]203[.]116[.]47 após consulta a transações Bitcoin.
- Valores 0.00052153 BTC e 0.00012148 BTC aparecendo em análise de resposta, memória, sandbox ou relatório de execução.
- Processos com baixa reputação realizando conversões numéricas e tráfego HTTP antes de comunicação C2.
A resposta deve começar pela contenção dos endpoints com evidência de execução do Redaman ou de comunicação com o C2 reconstruído. Isolar a máquina, preservar memória quando viável e coletar logs de proxy, DNS, EDR e firewall ajuda a confirmar se a consulta à blockchain foi usada como etapa de configuração. Como o vetor de distribuição é phishing, a investigação também deve recuperar mensagens, anexos, URLs e usuários impactados, sem transformar a análise em execução de amostras fora de ambiente controlado. O bloqueio do IP 185[.]203[.]116[.]47 é adequado quando observado, mas não substitui a detecção da técnica de resolução via blockchain.
Em controles preventivos, restrinja ou monitore o acesso a APIs públicas de blockchain a partir de estáções que não precisam desse tipo de serviço. Quando o bloqueio amplo não for aceitável, use política por grupo, processo e destino, com alerta para executáveis recém-criados, diretórios temporários ou processos derivados de documentos e clientes de e-mail. A carteira citada pode ser usada como indicador em ferramentas de análise de URL e proxy, desde que acompanhada por lógica comportamental para identificar variações. Em EDR, crie consultas que correlacionem execução suspeita, conexão com serviço de blockchain e comunicação externa subsequente.
A mitigação também passa por reduzir a chance de execução inicial. Fortaleça filtragem de phishing, análise de anexos, bloqueio de macros quando aplicável, verificação de reputação de arquivos e treinamento focado em mensagens que simulam contexto financeiro ou operacional. Para equipes de resposta, mantenha um procedimento específico para malware que resolve C2 por fontes públicas: capturar o primeiro tráfego de rede, preservar URLs consultadas, registrar valores retornados e comparar o destino final com conexões posteriores. Essa abordagem evita depender exclusivamente de uma lista de IPs que pode mudar com novas transações.
Após a contenção, valide se houve comunicação C2 efetiva e se o host executou outras cargas. O material analisado confirma a técnica de descoberta de C2, não uma lista completa de ações pós-comprometimento; portanto a investigação deve permanecer baseada em evidência local. Revise credenciais usadas no endpoint afetado, sessões bancárias ou administrativas acessadas durante a janela de infecção e alertas de autenticação anômalos. Quando a infecção for confirmada, reimagem ou limpeza controlada, rotação de senhas expostas no host e revisão de regras de saída reduzem o risco de persistência e recorrência.
- Isolar endpoints que consultaram a carteira citada e depois se conectaram ao C2 defangado 185[.]203[.]116[.]47.
- Bloquear ou monitorar APIs de blockchain em estáções sem necessidade operacional, com exceções documentadas.
- Correlacionar phishing, execução de processo, consulta à blockchain e comunicação externa em EDR, proxy e firewall.
- Usar a carteira 1BkeGqpo8M5KNVYXW3obmQt1R58zXAqLBQ como pivô de hunting, sem tratá-la como único indicador.
- Revisar credenciais e sessões usadas no host infectado durante a janela de atividade confirmada.
0 Comentários