Campanha associou mineradores Windows, páginas falsas de atualização do Flash, domínios de comando e controle e carteiras de Monero com atividade estimada em milhares de máquinas.
| Componente | Mineradores de Monero para Windows, incluindo amostras que baixavam Claymore CryptoNote Windows CPU Miner e, em fases posteriores, XMRig.exe. |
| Vetor | Redirecionamento para páginas falsas de atualização do Flash, uso de CoinHive no navegador e download de executáveis após interação com a página enganosa. |
| Impacto | Uso não autorizado de CPU para mineração, comunicação com domínios de comando e controle e instalação de programas adicionais por instaladores potencialmente indesejados. |
| Prioridade | Bloquear a infraestrutura defangada observada, procurar processos de mineração, revisar downloads vindos de páginas falsas de atualização e remover instaladores persistentes ou associados a pay-per-install. |
| Artefatos | A operação utilizava 17 carteiras com o mesmo pool nanopool[.]org, nomes de workers sobrepostos e taxa agregada máxima estimada em 592.000 hashes por segundo. |
| IoCs | Exemplos defangados incluem osdsoft[.]com, ztracker[.]club, xtracker[.]club, flash2update[.]xyz, flashdownload[.]club, flashplayers[.]club e IP 34.211.137[.]44. |
| Telemetria | A atividade máxima diária ocorreu entre 2h e 15h UTC, com tráfego observado principalmente a partir da Índia. |
| Infraestrutura | A distribuição usava buckets S3, domínios de rastreamento com nomes semelhantes, cabeçalho HTTP com user-agent qwert e painel Binom exposto em domínio de C&C. |
A operação analisada combinou mineração ilícita de Monero, distribuição por páginas enganosas e infraestrutura de rastreamento de tráfego para monetizar máquinas Windows comprometidas. O núcleo da atividade era composto por amostras de mineradores que se conectavam a carteiras específicas, usavam o pool nanopool[.]org e apresentavam padrões consistentes de nomes de workers. A correlação entre 17 carteiras, o mesmo pool e identificadores curtos sobrepostos indica coordenação operacional, não uso isolado de ferramentas de mineração. A estimativa técnica baseada na taxa máxima agregada aponta para 592.000 hashes por segundo, valor que foi comparado a uma capacidade aproximada de 100 hashes por segundo por computador comum, sugerindo uma ordem de grandeza próxima de 6.000 máquinas infectadas.
A campanha não se limitava ao minerador em si. A cadeia envolvia redirecionamentos para páginas falsas de atualização do Flash, mineração via navegador usando CoinHive e download de executáveis quando a vítima interagia com a página. Em paralelo, instaladores potencialmente indesejados já associados ao mesmo ecossistema executavam checagens de ambiente, fingerprinting do sistema e geolocalização antes de baixar componentes adicionais. Esse conjunto mostra uma operação orientada a monetização múltipla: mineração local por CPU, mineração no navegador e provável distribuição pay-per-install de programas adicionais conforme o país da máquina.
As primeiras amostras associadas à campanha baixavam o Claymore CryptoNote Windows CPU Miner a partir de um bucket S3 defangado em s3-us-west-2.amazonaws[.]com/zminer/. Em uma fase posterior, o fluxo passou a obter XMRig.exe de outro caminho S3, s3-us-west-2.amazonaws[.]com/upperservice/. Essa mudança sugere maturação operacional: a campanha iniciou com componentes mais experimentais, inclusive com caminhos PDB deixados nos binários, e depois adotou nomeação mais estável, incluindo referências ao projeto xmrig_console_explorer. Para defesa, esses nomes e caminhos PDB não devem ser tratados como prova única de infecção, mas são artefatos úteis para enriquecimento de amostras e agrupamento retrospectivo em repositórios de malware.
Após a execução, amostras antigas faziam contato com endpoint HTTP em osdsoft[.]com, enquanto versões posteriores usavam domínios com padrões semelhantes, como ztracker e xtracker, resolvendo para o IP defangado 34.211.137[.]44. O cabeçalho HTTP observado mantinha o user-agent qwert, mesmo quando os domínios variavam. Esse detalhe é relevante porque o operador pode trocar domínios com facilidade, mas padrões de cliente, URI, user-agent e resolução compartilhada ajudam a criar detecções comportamentais menos frágeis. A presença de painel Binom em um dos domínios também conecta a operação a um sistema de distribuição e rastreamento de campanhas, com identificadores de campanha usados em URLs de páginas falsas de Flash e em requisições de conversão.
A cadeia de redirecionamento levava usuários a sites que prometiam atualização de Flash Player. Essas páginas eram enganosas em dois níveis: acionavam mineração por navegador por meio de CoinHive e também entregavam o minerador quando havia interação com a página. O padrão de URL incluía parâmetros de campanha e chave, o que permite ao operador medir cliques, conversões e variantes de tráfego. Em telemetria defensiva, esse desenho aparece como sequência de navegação para domínio recém-relacionado a atualização falsa, carregamento de minerador web ou script de mineração, download de executável e posterior comunicação do binário com C&C ou pool de mineração.
A superfície principal é composta por estáções Windows expostas a downloads de instaladores enganosos, páginas falsas de atualização e pacotes potencialmente indesejados. O impacto técnico confirmado é o consumo indevido de CPU para mineração de Monero e a instalação de programas adicionais. O contexto não sustenta afirmar roubo de dados ou movimentação lateral; a análise deve permanecer no escopo observado: execução de mineradores, comunicação com infraestrutura de controle, geolocalização da vítima, checagens antiambiente e instalação baseada em configuração remota. Em ambientes corporativos, ainda assim, o risco operacional é concreto porque mineração não autorizada degrada endpoints, aumenta ruído de rede, pode mascarar outros adwares e indica falha de controle sobre execução de binários baixados da web.
Os instaladores associados ao ecossistema apresentavam nomes que simulavam legitimidade, como serviços de atualização ou limpeza de PC. Eles realizavam verificações contra máquinas virtuais, ferramentas de análise e mecanismos antivírus antes de continuar, além de coletarem características do sistema e consultarem geolocalização por ip-api[.]com. A decisão sobre quais programas baixar era guiada por um arquivo bundles.xml, obtido de infraestrutura própria ou de bucket S3. Esse arquivo continha mapeamento de países para programas, além de um conjunto padrão independente da localização. Em um exemplo observado, uma máquina localizada na Rússia recebia uma combinação de softwares como Mailru, YoutubeAdblockE, Zcash, Monero e PCCleanPlus.
A atividade das carteiras apresentou picos diários entre 2h e 15h UTC, período compatível com horário comercial em fusos UTC+5. A mesma análise indicou que a maior parte do tráfego para os sites de Flash falso vinha da Índia. Para equipes de defesa, esse dado não deve ser usado para atribuição rígida do operador, mas ajuda a entender onde a campanha possivelmente tinha maior massa de vítimas ou melhor conversão de tráfego. A infraestrutura era dinâmica, com domínios relacionados a atualização de Flash, rastreamento e C&C, mas mantinha padrões suficientes para correlação.
- Endpoints Windows com downloads recentes de instaladores apresentados como atualização, player, utilitário de sistema ou limpeza de PC.
- Navegadores que acessaram páginas falsas de Flash e geraram requisições para scripts de mineração ou URLs com parâmetros de campanha.
- Máquinas com processos de mineração de Monero, conexões para pools públicos ou comunicação HTTP com user-agent
qwert. - Ambientes em que executáveis de buckets S3 foram baixados fora de fluxo corporativo aprovado.
A investigação defensiva deve começar pela união de telemetria de endpoint, proxy, DNS e EDR. No endpoint, procure processos com comportamento de mineração por CPU, execução de binários com nomes relacionados a XMRig.exe, componentes CryptoNote e amostras que tenham caminhos PDB associados ao projeto xmrig_console_explorer. O objetivo não é caçar apenas nomes estáticos, pois o operador pode renomear binários; o sinal mais forte é a combinação de uso anormal de CPU, conexão recorrente com pool de mineração, execução a partir de diretórios temporários ou de perfil de usuário e origem do arquivo em download recente de navegador.
Na rede, a telemetria deve cobrir resoluções DNS e HTTP para domínios defangados como osdsoft[.]com, ztracker[.]club, xtracker[.]club, flash2update[.]xyz, flashdownload[.]club e flashplayers[.]club. O IP defangado 34.211.137[.]44 é um indicador útil para investigação histórica, mas deve ser tratado com cuidado por possível reutilização ou mudança de hospedagem. O user-agent qwert em requisições HTTP para domínios de rastreamento é um indicador comportamental mais específico. Também é importante procurar acesso a caminhos de conversão como click.php, especialmente quando aparecem logo após navegação para páginas de atualização falsa.
Em proxies e logs de navegador, a sequência mais valiosa é composta por redirecionamento para página de Flash, interação do usuário, download de executável e execução subsequente no host. Em ambientes com inspeção de conteúdo, a presença de CoinHive ou mineração web associada à página enganosa pode indicar que o usuário foi monetizado no navegador antes mesmo da instalação local. Em EDR, os eventos de processo devem ser correlacionados com downloads de arquivos de buckets S3 e com qualquer consulta de geolocalização a ip-api[.]com, especialmente quando essa consulta parte de executável recém-baixado e não de navegador comum.
- Processos com consumo persistente de CPU e conexões para
nanopool[.]orgou outros pools de mineração de Monero. - Requisições HTTP com user-agent
qwertpara domínios de rastreamento ou C&C relacionados à campanha. - Downloads de
XMRig.exeou mineradores CryptoNote a partir de caminhos S3 não aprovados. - Acesso a páginas falsas de atualização do Flash seguido por download de executável no mesmo intervalo de sessão.
- Consulta a
ip-api[.]comfeita por instalador ou downloader, seguida de obtenção debundles.xml.
A resposta deve priorizar contenção de endpoints com sinais de mineração ativa, remoção dos binários e validação de que não há instaladores auxiliares mantendo a reinfecção. Como a cadeia também envolve PUPs e distribuição por país, limpar apenas o processo de mineração pode deixar componentes de download capazes de instalar novos programas. A contenção deve incluir isolamento temporário do host, coleta de amostras para análise interna, revisão de persistência, verificação de tarefas agendadas, serviços com nomes enganosos e artefatos em diretórios de usuário ou temporários. O consumo de CPU deve voltar ao padrão esperado após a remoção; caso contrário, procure processos renomeados ou componentes adicionais.
No perímetro, bloqueie os domínios defangados observados e crie detecções para famílias de padrões, não apenas para indicadores literais. Regras que combinem páginas de atualização de Flash, caminhos click.php, parâmetros de campanha, downloads de executáveis e user-agent incomum reduzem a dependência de uma lista fixa de domínios. Para buckets S3, a mitigação não deve bloquear indiscriminadamente o serviço legítimo, mas controlar downloads executáveis vindos de caminhos não aprovados e registrar origem, hash interno e usuário responsável pela sessão. Em ambientes com controle de aplicações, mineradores conhecidos e executáveis baixados de áreas temporárias devem ser bloqueados por política.
A prevenção de recorrência exige reduzir a chance de execução de instaladores enganosos. Remova Flash e componentes obsoletos quando não forem necessários, bloqueie páginas de atualização não oficiais, aplique filtragem de reputação em DNS e proxy, e eduque usuários sem depender exclusivamente de treinamento. Para times de segurança, a validação deve incluir caça retrospectiva desde os meses finais de 2017, porque amostras relacionadas começaram a circular nesse período e continuavam aparecendo em repositórios de análise diariamente no contexto observado. Quando um host for confirmado, revise a navegação anterior, downloads correlatos e qualquer outro software instalado no mesmo intervalo, pois o modelo de distribuição indicava múltiplos programas por geolocalização.
- Isolar endpoints com mineração ativa, coletar artefatos e remover minerador, downloader e programas instalados no mesmo fluxo.
- Bloquear domínios defangados relacionados a Flash falso, rastreamento e C&C, mantendo detecção para user-agent
qwerte caminhosclick.php. - Controlar execução de binários baixados de buckets S3 não aprovados, diretórios temporários e perfis de usuário.
- Procurar e remover componentes associados a
bundles.xml, serviços com nomes enganosos e instaladores potencialmente indesejados. - Validar a limpeza por queda de consumo de CPU, ausência de conexões para pools de mineração e inexistência de novos downloads correlatos.
0 Comentários