Análise técnica do UPAS Kit mostra downloader furtivo com persistência, injeção e propagação por USB

O malware combina resolução dinâmica de funções, evasão de ambientes de análise, chaves de inicialização no Windows, injeção em processos, hooks em ntdll.dll e comunicação HTTP com C2 para baixar, atualizar ou executar módulos adicionais.

Componente	UPAS Kit, comparado tecnicamente ao trojan bancário Kronos em rotinas de carregamento, mutex, persistência, privilégio, hooking e funções de rootkit.
Vetor	Execução local do binário em Windows, seguida por cópia para diretórios de usuário, persistência por chaves Run, injeção em processos e propagação por mídia USB quando novos dispositivos são detectados.
Impacto	Execução furtiva como downloader infeccioso, ocultação de artefatos por hooks em funções de ntdll.dll, comunicação HTTP recorrente com C2 e capacidade de receber comandos de desinstalação, atualização, download e execução.
Prioridade	Investigar endpoints Windows com criação anômala de arquivos em %APPDATA% e %TEMP%, alterações em chaves Run, injeção em explorer.exe ou iexplore.exe, hooks em ntdll.dll e beacons HTTP repetitivos sem domínio conhecido no contexto.
Artefatos	Mutex derivado de MD5 do serial do volume com valor alternativo codificado em caso de falha; nomes de arquivo e chaves de registro derivados dos primeiros caracteres do mutex.
Persistência	Cópia para pasta Microsoft sob %APPDATA%, cópias adicionais em %TEMP% com sufixos específicos e gravação em Software\Microsoft\Windows\CurrentVersion\Run sob HKLM e HKCU.

Resumo técnico

O UPAS Kit é descrito como um malware Windows com papel central de downloader furtivo e infeccioso. A amostra analisada executa uma sequência de preparação antes da comunicação principal com o servidor de comando e controle: resolve funções de baixo nível em tempo de execução, verifica ambientes de análise, cria identificadores persistentes, copia o próprio binário para locais de usuário, registra inicialização automática, injeta código em processos do sistema ou do navegador e instala hooks destinados a esconder artefatos. O comportamento observado não depende de um único recurso avançado isolado; a efetividade vem da combinação de técnicas comuns em uma cadeia operacional coerente.

A comparação com Kronos é relevante porque algumas rotinas apresentam semelhanças estruturais, enquanto outras diferem bastante. Ambos resolvem funções dinamicamente e usam convenções de nomes baseadas em MD5 do serial do volume para gerar artefatos como mutex, arquivos e chaves. Também há sobreposição em funções de hook e em uma rotina de elevação de token para SeDebugPrivilege. Ao mesmo tempo, Kronos usa hashing de nomes de funções e uma implementação de hooking mais robusta, enquanto o UPAS Kit mantém nomes em texto claro e usa escrita menos segura no prólogo das funções. Essas diferenças limitam qualquer conclusão de autoria e mantêm a análise no campo técnico de reutilização, convergência ou compartilhamento parcial de componentes.

O impacto operacional confirmado é a instalação de um componente capaz de permanecer no sistema, ocultar sinais locais, propagar-se por mídia removível e manter comunicação HTTP com C2 para receber instruções. O servidor pode responder com comandos de remoção, download, atualização ou execução, com múltiplas ordens em uma mesma resposta. Não há domínio, endereço IP, hash de amostra ou versão de campanha no material analisado; portanto, a resposta defensiva deve se concentrar em comportamento, telemetria de endpoint, modificações de persistência, anomalias de injeção e padrões de rede compatíveis com beaconing HTTP.

Fluxo técnico

A primeira camada técnica do UPAS Kit envolve a resolução de funções em tempo de execução. O malware percorre uma tabela interna de entradas e usa GetProcAddress para obter endereços de funções, incluindo chamadas de baixo nível de ntdll.dll. Essa abordagem reduz dependências explícitas visíveis na tabela de importação e pode dificultar análise estática simples, embora, isoladamente, não seja uma técnica sofisticada. Kronos implementa uma estratégia parecida com uma diferença importante: os nomes das funções não ficam em texto claro, mas representados por hashes, e parte das funções resolvidas é usada como chamadas de sistema, o que tende a complicar a observação por sandboxes, emuladores e análise manual.

Antes de avançar, o UPAS Kit tenta detectar ambientes de análise. Uma verificação consulta o serial do volume por meio de GetVolumeInformationW e compara o resultado com um valor associado ao ThreatExpert. Outra consulta artefatos de VMware por uma porta virtual de entrada e saída usada na comunicação entre convidado e host. Quando identifica um ambiente indesejado, o malware responde exibindo uma caixa de erro em vez de continuar normalmente. O Kronos, por outro lado, procura processos e módulos carregados que indiquem análise ou virtualização, cobrindo um conjunto mais amplo de cenários. Para defesa, a diferença importa porque assinaturas muito presas a um único artefato de sandbox podem perder variantes ou famílias que escolhem outra lógica de evasão.

Na persistência, o UPAS Kit cria um mutex a partir do serial do volume e de um material interno, usando MD5; se a geração falha, utiliza um valor alternativo codificado. Em seguida, copia o binário para uma pasta Microsoft dentro de %APPDATA% e também para %TEMP%, usando nomes derivados dos primeiros caracteres do mutex e sufixos adicionais nas cópias temporárias. O malware compara o caminho atual com o caminho esperado em %APPDATA%; quando ainda não está rodando do local persistente, inicia a nova cópia. Na execução seguinte, grava o caminho do arquivo em chaves Run sob HKLM e HKCU, com o nome da chave alinhado ao nome do arquivo. Esse fluxo produz uma trilha defensiva clara: criação de diretório com nome legítimo genérico em perfil de usuário, nomes derivados de identificador local e persistência duplicada em escopos de máquina e usuário.

A etapa de injeção depende da arquitetura. Em sistemas de 32 bits, o malware cria explorer.exe e injeta sua própria imagem nesse processo. Em sistemas de 64 bits, mira a versão de 32 bits de iexplore.exe no diretório de programas x86. A função de injeção recebe o identificador do processo, o handle da thread principal e o endereço da função a ser executada após a injeção. O método copia a imagem virtual atual para um buffer, aloca memória remota, realoca a imagem para a base obtida e grava o conteúdo no processo alvo. Depois prepara um stub interno para chamar a função pós-injeção, altera o contexto da thread com NtSetContextThread e retoma a execução; se isso falha, tenta acionar a função diretamente com CreateRemoteThread. O uso de SeDebugPrivilege aparece como tentativa de ampliar permissões do processo, embora não seja obrigatório para todo caso de injeção.

Após a injeção, há diferença entre cargas de 32 e 64 bits. No fluxo de 32 bits, o código injetado configura variáveis globais, verifica indicador de desinstalação, cria uma thread para injetar o malware em outros processos e define funções de hook. No fluxo de 64 bits, a lógica é semelhante, mas não verifica o indicador de desinstalação e não injeta em todos os demais processos, o que limita a utilidade do componente de rootkit nesse cenário. Essa distinção deve orientar análise forense: a ausência de uma etapa em 64 bits não descarta infecção; ela pode refletir limitação da própria implementação.

Superfície afetada

A superfície principal são endpoints Windows capazes de executar o binário e permitir escrita em diretórios de usuário, criação de processos, modificação de chaves Run e interação com mídia removível. O malware não é descrito como exploração remota de vulnerabilidade; a pré-condição técnica é a execução local inicial. A partir daí, a cadeia amplia a persistência e a distribuição por mecanismos do próprio sistema operacional. Ambientes em que usuários têm permissão para gravar em %APPDATA% e %TEMP%, usar dispositivos USB e iniciar processos filhos oferecem o terreno necessário para o comportamento observado.

O componente de propagação por USB registra uma classe de janela com nome relacionado ao mutex e entra em um loop de mensagens para detectar inserção de nova mídia. Quando identifica um novo dispositivo, copia o malware para a unidade e cria um arquivo de inicialização automática. Também procura atalhos .lnk e altera seus destinos para que o acesso ao atalho resulte na execução do arquivo original e do malware. A técnica é relevante para redes com estáções legadas, quiosques, ambientes industriais ou fluxos operacionais que ainda dependem de mídia removível, especialmente quando controles de execução automática e inspeção de atalhos não estão maduros.

• Endpoints Windows com execução local do binário e permissão de escrita em %APPDATA% e %TEMP%.
• Sistemas em que chaves Run sob HKLM ou HKCU podem ser criadas ou modificadas pelo contexto comprometido.
• Processos explorer.exe e iexplore.exe usados como alvos de injeção conforme a arquitetura do sistema.
• Mídias USB em ambientes onde arquivos de inicialização automática e atalhos .lnk podem ser manipulados.
• Sessões com possibilidade de tentativa de elevação de token para SeDebugPrivilege.

Hunting e telemetria

A caça deve começar por eventos de criação de arquivo, persistência e processo. Procure cópias recentes de executáveis em uma pasta Microsoft sob %APPDATA%, especialmente quando o nome do arquivo parece derivado de sequência curta e não corresponde a software instalado de forma legítima. Em %TEMP%, observe executáveis com sufixos semelhantes a variantes de instalação e propagação. Em registro, correlacione novas entradas em Software\Microsoft\Windows\CurrentVersion\Run sob HKLM e HKCU com caminhos de perfil de usuário ou diretório temporário. A presença de entrada nos dois escopos, associada a um binário sem assinatura confiável ou sem origem administrativa, aumenta a prioridade.

No endpoint, a telemetria de processo deve destacar criação suspensa ou anômala de explorer.exe e iexplore.exe, abertura de handles remotos, alteração de contexto de thread, escrita em memória de outro processo e uso de CreateRemoteThread como alternativa. A tentativa de habilitar SeDebugPrivilege é um sinal útil quando correlacionada com cópia de binário, persistência e injeção. Hooks inline em ntdll.dll podem ser investigados por comparação de prólogos de funções contra cópias limpas em disco ou memória conhecida, com atenção para funções cujos primeiros bytes foram substituídos por salto. Como o método do UPAS Kit usa escrita não atômica com WriteProcessMemory, crashes inesperados em processos alvo durante o período de instalação dos hooks também podem ser indício indireto, embora não suficiente isoladamente.

Na rede, o malware usa HTTP para comunicação com C2 após concluir injeção, hooking e propagação. Sem domínio ou IP confirmado, a detecção deve priorizar comportamento: beacons recorrentes de um processo injetado, requisições sem perfil compatível com navegação humana, respostas contendo estrutura de comando e tráfego iniciado por processos que normalmente não deveriam falar diretamente com destinos externos naquele padrão. O contexto também indica mensagens enviadas quando uma unidade USB é infectada; portanto, eventos de inserção de mídia removível seguidos por tráfego HTTP do processo comprometido merecem correlação.

• Criação de executáveis em %APPDATA% dentro de pasta Microsoft recém-criada e cópias correlatas em %TEMP%.
• Novas entradas em HKLM e HKCU para Software\Microsoft\Windows\CurrentVersion\Run apontando para diretórios de usuário ou temporários.
• Criação ou manipulação de explorer.exe em 32 bits e iexplore.exe de 32 bits em sistemas de 64 bits, seguida por escrita em memória remota.
• Chamadas ou eventos compatíveis com NtSetContextThread, CreateRemoteThread, alteração de contexto de thread e tentativa de SeDebugPrivilege.
• Modificação de atalhos .lnk, criação de arquivo de inicialização automática em USB e cópia de executável para mídia removível.
• Beacons HTTP repetitivos originados de processos injetados após eventos de persistência ou inserção de USB.

Mitigação

A resposta deve tratar o caso como infecção por downloader com capacidade de persistência e movimentação por mídia removível, não como simples arquivo isolado. O primeiro passo é conter o endpoint afetado, preservar evidências de memória e disco, coletar chaves de persistência, processos ativos, módulos carregados e conexões HTTP recentes. A remoção precisa cobrir a cópia em %APPDATA%, artefatos em %TEMP%, entradas Run em HKLM e HKCU, processos injetados e arquivos adicionados a dispositivos USB conectados. Encerrar apenas o processo visível pode deixar persistência ativa ou cópias prontas para nova execução.

Em hardening, restrinja execução a partir de diretórios temporários e de perfil de usuário quando o modelo operacional permitir, aplique controle de aplicações, monitore criação de chaves Run e desabilite mecanismos de execução automática em mídia removível. Bloqueie ou audite alterações em atalhos .lnk em unidades USB, principalmente quando o destino passa a executar um binário oculto ou recém-criado. Para estáções com uso legítimo de USB, implemente varredura automática, registro de inserção de dispositivos e política de montagem que reduza execução de conteúdo não confiável.

A validação pós-incidente deve confirmar que não há hooks remanescentes em processos críticos, que os processos alvo foram reiniciados de forma limpa e que não há beacons HTTP residuais. Como o UPAS Kit pode receber módulos adicionais por C2, a investigação não deve se limitar aos artefatos do downloader: é necessário revisar criação de arquivos após a primeira execução, novas tarefas, alterações de navegador, módulos carregados em processos de usuário e qualquer tráfego subsequente que indique atualização ou execução de componente baixado. A ausência de IoCs de infraestrutura no contexto reforça a necessidade de detecção comportamental e de baseline local.

• Isolar hosts suspeitos e coletar memória, lista de processos, conexões, chaves Run e cópias em %APPDATA% e %TEMP% antes da limpeza.
• Remover entradas persistentes em HKLM e HKCU, validar caminhos apontados por elas e reiniciar processos que possam ter recebido injeção.
• Inspecionar mídias USB conectadas, remover executáveis adicionados pelo malware e revisar atalhos .lnk modificados.
• Aplicar controle de execução para bloquear binários não autorizados em diretórios temporários e de perfil de usuário.
• Monitorar SeDebugPrivilege, escrita em memória remota, alteração de contexto de thread e criação de threads remotas como sinais de injeção.
• Usar detecção comportamental para HTTP recorrente de processos injetados, já que o contexto não fornece domínio, IP ou hash confiável para bloqueio direto.