KingMiner evolui como malware de mineração Monero contra servidores Windows

A campanha mira servidores Microsoft, principalmente ambientes IIS e SQL, tenta adivinhar senhas e implanta uma versão reduzida do XMRig com técnicas simples de evasão contra emulação e detecção.

Componente	KingMiner, malware de mineração Monero que implanta uma versão reduzida do XMRig em servidores Windows.
Vetor	Tentativa de adivinhação de senhas contra servidores Microsoft, principalmente IIS e SQL, seguida de download e execução de arquivo Windows Scriptlet .sct.
Impacto	Uso intensivo de CPU para mineração Monero, com observação de processo malicioso consumindo 100% da capacidade do processador.
Prioridade	Reforçar autenticação em servidores expostos, caçar artefatos do KingMiner e bloquear execução não autorizada de scriptlets, executáveis e DLLs associados.
Artefatos	powered.exe, fix.exe, sandbox.dll, active_desktop_render_x64.dll, soundbox.dll, md5.txt, x.txt, y.png, 32p.zip, 64p.zip e config.json.
IoCs	Carteira Monero observada: 49EHNacRauzgz8cGouhrVChcLyF3XrGLAdWiczJxY1qpX3oed4cGgMUUHHhyR7taGJ1MtvpfJiDf9gugAko4MzXM9DRYzZ1; domínios do pool privado não foram determinados.

Resumo técnico

KingMiner é uma família de malware voltada a criptojacking que tem como alvo servidores Windows e usa os recursos de CPU das máquinas comprometidas para mineração de Monero. A atividade foi observada inicialmente em meados de junho de 2018 e, nos seis meses seguintes, recebeu duas versões aprimoradas. A evolução não se concentrou apenas na substituição de arquivos: o fluxo passou a incorporar dependências entre componentes, manipulação de conteúdo e formatos de arquivo desenhados para reduzir a eficácia de emuladores e mecanismos de detecção.

A superfície inicial descrita envolve servidores Microsoft, com destaque para ambientes IIS e SQL, nos quais o operador tenta adivinhar senhas. Após obter condição suficiente para execução, a cadeia baixa e executa um arquivo Windows Scriptlet .sct na máquina vítima. A partir desse ponto, o malware prepara os componentes necessários para gerar e executar um minerador baseado em XMRig, removendo funções não essenciais e mantendo somente o núcleo necessário para mineração por CPU.

O impacto confirmado é consumo de processamento para mineração. Um dos artefatos principais, powered.exe, chamado de fix.exe em versões anteriores, foi observado consumindo 100% da CPU. Esse tipo de atividade pode degradar aplicações hospedadas, aumentar latência, elevar custos operacionais e mascarar outros eventos de segurança em servidores já expostos por autenticação fraca. O contexto não confirma roubo de dados, movimentação lateral ou exploração de vulnerabilidade específica; a prioridade defensiva deve permanecer na contenção do abuso de credenciais, na remoção dos artefatos e na validação de persistência.

Fluxo técnico

A cadeia começa com tentativa de acesso por adivinhação de senha contra servidores Microsoft. Uma vez que o operador consegue acionar código no host, um arquivo .sct é baixado e executado. Esse uso de Windows Scriptlet é relevante para a defesa porque desloca a detecção para telemetria de execução de script, criação de processo e escrita de arquivos em diretórios incomuns. Em vez de depender de um único binário autossuficiente, o KingMiner distribui funções entre executáveis, DLLs e blobs codificados, criando uma sequência em que a ausência de um componente reduz a visibilidade do comportamento malicioso em ambientes de análise.

O payload é selecionado de acordo com a arquitetura de CPU identificada, com nomes como 32p.zip e 64p.zip. Apesar da extensão, esses arquivos são descritos como XML, não como ZIP convencional. O XML contém um blob Base64 que, após decodificação, resulta no arquivo pretendido. Essa escolha permite que a amostra pareça incompatível com expectativas simples de análise estática e atrapalha emuladores que esperam um contêiner ZIP real. O efeito defensivo importante é que o nome do arquivo, sua extensão e seu tipo efetivo não devem ser tratados como equivalentes durante triagem.

Depois da extração, o conteúdo do arquivo md5.txt, descrito como zzz, é anexado à DLL relevante, incluindo sandbox.dll ou active_desktop_render_x64.dll. O comportamento observado não atribui função operacional clara a essa alteração, mas ela participa da manipulação dos arquivos exigidos pela cadeia. Em seguida, powered.exe ou fix.exe é executado e cria o arquivo minerador XMRig, além de registrar novas chaves no Registro do Windows com o valor Test. O minerador final é produzido a partir de blob binário armazenado em arquivos como x.txt ou y.png, decodificado por uma função exportada chamada King1.

A execução isolada do principal executável não revela toda a atividade, porque o arquivo depende de funções exportadas pelas DLLs. Essa dependência é um ponto central da evasão: amostras analisadas fora do conjunto completo podem parecer inertes ou incompletas. A DLL também contém funções adicionais que parecem reservadas para uso futuro, como ClearDesktopMonitorHook, que retorna o valor 1. A presença desses placeholders indica preparação para novas capacidades, embora o material analisado não confirme quais operações seriam ativadas em versões posteriores.

Superfície afetada

A exposição principal está em servidores Windows acessíveis por serviços Microsoft nos quais credenciais fracas, reutilizadas ou sem proteção adicional permitem tentativa de adivinhação de senha. O texto técnico cita sobretudo IIS e SQL, o que aponta para servidores de aplicação, bancos de dados ou hosts híbridos que acumulam função web e função de dados. A campanha foi descrita como amplamente distribuída, com tentativas observadas em países como México, Índia, Noruega e Israel, mas sem domínios públicos associados ao pool privado de mineração.

A mineração usa Monero e se comunica com pool privado. A API do pool estava desativada, e a carteira associada não era usada em pools públicos, o que limita a capacidade de monitoramento externo da receita ou da infraestrutura por meios abertos. Para defensores, essa característica aumenta a dependência de telemetria local: processo, consumo de CPU, escrita de arquivos, carregamento de DLL, criação de chaves de Registro e conexões de saída para infraestrutura não categorizada devem ser correlacionados no próprio ambiente.

• Servidores Windows com IIS ou SQL expostos e autenticação fraca são a superfície inicial descrita.
• Hosts em que arquivos .sct podem ser baixados e executados apresentam risco maior de progressão da cadeia.
• Ambientes que analisam artefatos isoladamente podem perder comportamento porque o executável principal depende de DLLs e blobs adicionais.
• Sistemas de detecção baseados apenas em extensão de arquivo podem interpretar incorretamente payloads nomeados como ZIP que, na prática, contêm XML.

Hunting e telemetria

A caça deve começar pela combinação de autenticação suspeita, criação de processo e consumo anormal de CPU em servidores IIS e SQL. Tentativas repetidas de autenticação, seguidas por execução de Windows Scriptlet, são um encadeamento mais forte do que qualquer sinal isolado. Em endpoint, a criação ou execução de powered.exe e fix.exe, o carregamento de sandbox.dll, active_desktop_render_x64.dll ou soundbox.dll, e a presença de arquivos como x.txt, y.png, md5.txt, 32p.zip, 64p.zip e config.json devem receber prioridade de triagem.

A telemetria de arquivo deve comparar extensão, tipo real e conteúdo. O uso de arquivos nomeados como ZIP que carregam XML com blob Base64 é um indicador comportamental útil, especialmente quando aparece próximo a DLLs recém-criadas e executáveis sem reputação. Em memória e processo, o sinal operacional mais direto é o uso sustentado de CPU por um processo desconhecido ou por binário recém-gravado em servidor. Como o minerador é uma versão reduzida do XMRig, a detecção pode se apoiar em padrões de mineração por CPU, mas deve evitar depender apenas de assinaturas genéricas.

No Registro do Windows, a criação de chaves com valor Test pelo executável principal é um sinal citado no fluxo. Esse indicador deve ser validado em conjunto com outros eventos, pois o valor isolado é genérico. Em rede, a atividade para pool privado pode não revelar domínios conhecidos, já que os domínios não foram determinados e a API do pool estava desativada. Por isso, conexões persistentes ou recorrentes para destinos incomuns a partir de servidores que não deveriam minerar criptomoeda devem ser analisadas com contexto de processo e horário.

• Falhas e sucessos de autenticação em sequência contra IIS, SQL ou serviços administrativos de servidores Windows.
• Execução de arquivo .sct seguida de gravação de executáveis, DLLs e arquivos com extensão inconsistente com o conteúdo real.
• Presença de powered.exe ou fix.exe em diretórios não esperados e consumo sustentado de CPU.
• Arquivos 32p.zip ou 64p.zip que contenham XML e blob Base64 em vez de estrutura ZIP comum.
• Criação de chaves de Registro com valor Test próxima à execução dos artefatos do KingMiner.
• Conexões de saída não justificadas de servidores para infraestrutura associada a mineração ou destinos externos sem finalidade de negócio.

Mitigação

A resposta deve priorizar a interrupção da execução e a eliminação da condição de entrada. Em servidores afetados, o processo minerador deve ser contido, os artefatos relacionados devem ser preservados para análise e removidos após coleta, e a origem da autenticação bem-sucedida precisa ser investigada. Como o vetor descrito envolve adivinhação de senhas, a troca de credenciais, revisão de contas com senha fraca, bloqueio de autenticação repetida e adoção de autenticação multifator onde aplicável são medidas centrais, não apenas complementares.

A mitigação técnica também deve restringir a execução de scriptlets e binários não autorizados em servidores. Controles de aplicação, políticas de execução, regras de EDR e monitoramento de criação de processo ajudam a reduzir a chance de progressão após uma credencial comprometida. O fluxo do KingMiner mostra que extensões podem ser enganosas; portanto, inspeção de tipo de arquivo, análise de conteúdo e bloqueio de cadeias de decodificação suspeitas são mais úteis do que confiar em nomes como ZIP, PNG ou TXT.

Após a contenção, é necessário validar se versões antigas dos arquivos de ataque foram removidas ou substituídas. O próprio fluxo do malware inclui lógica para encerrar processos e apagar arquivos de versões anteriores, o que pode deixar lacunas de evidência em hosts reinfectados. A revisão deve incluir tarefas agendadas, serviços, chaves de Registro, diretórios temporários, perfis de contas usadas pelo serviço afetado e histórico de conexões externas. O objetivo defensivo é confirmar que o host não mantém componentes dependentes capazes de recriar o minerador.

• Bloquear ou limitar tentativas repetidas de autenticação e revisar senhas de contas expostas em servidores IIS e SQL.
• Aplicar controles de execução para impedir .sct, executáveis e DLLs não autorizados em servidores de produção.
• Investigar e remover powered.exe, fix.exe, DLLs associadas, blobs auxiliares e arquivos de configuração relacionados.
• Correlacionar consumo de CPU com árvore de processos, usuário de execução e conexões de saída antes de encerrar a investigação.
• Revisar o Registro do Windows para alterações criadas no período da infecção, incluindo valores genéricos como Test quando acompanhados de outros sinais.
• Ajustar detecções para identificar divergência entre extensão e conteúdo real, especialmente arquivos nomeados como ZIP que carregam XML codificado.
• Rotacionar credenciais envolvidas, revisar contas privilegiadas e validar que a exposição inicial por senha fraca foi corrigida.