O grupo habilitou Hyper-V em hosts Windows 10 comprometidos para executar uma VM Alpine Linux mínima com CurlyShell e CurlCat, isolando a operação maliciosa do monitoramento tradicional no endpoint.
| Componente | Hosts Windows 10 comprometidos com o papel Hyper-V habilitado para hospedar uma VM Alpine Linux mínima usada como ambiente remoto oculto. |
| Vetor | Após obter acesso ao sistema Windows, o operador ativa virtualização local e implanta uma VM leve para executar CurlyShell, CurlCat e recursos de proxy reverso fora do ambiente principal do endpoint. |
| Impacto | A técnica reduz a visibilidade de controles EDR baseados no host Windows, preserva capacidade de shell reverso e mantém túneis de comunicação para controle remoto. |
| Prioridade | Auditar habilitação inesperada de Hyper-V, criação de VMs pequenas em estáções Windows 10 e presença de ferramentas de proxy, túnel e acesso remoto persistente. |
| Artefatos | CurlyShell, CurlCat, RuRat, Mimikatz, MucorAgent, Resocks, Rsockstun, Ligolo-ng, CCProxy, Stunnel e métodos baseados em SSH. |
| Comunicação | CurlyShell opera como daemon em segundo plano, consulta C2 por HTTP GET e devolve resultados por HTTP POST, com execução de comandos criptografados. |
A atividade atribuída ao grupo Curly COMrades mostra o uso de virtualização local como camada de evasão em hosts Windows já comprometidos. O operador habilitou o papel Hyper-V em sistemas Windows 10 selecionados e implantou uma máquina virtual baseada em Alpine Linux, com aproximadamente 120 MB de disco e 256 MB de memória. O objetivo técnico era criar um ambiente remoto discreto para hospedar ferramentas próprias, principalmente CurlyShell e CurlCat, sem depender somente de processos executados diretamente no sistema operacional Windows visível ao EDR.
A técnica não transforma Hyper-V em vulnerabilidade por si só. O risco está no abuso de um recurso legítimo de virtualização para deslocar parte da execução maliciosa para uma VM controlada pelo invasor. Ao isolar binários, proxy reverso e shell reverso dentro de um convidado Linux, o operador reduz a exposição de artefatos no host Windows e dificulta detecções centradas apenas em criação de processo, árvore de execução e telemetria local do sistema principal.
O cluster é descrito como ativo desde o fim de 2023, com interesses alinhados à Rússia e ataques direcionados a Geórgia e Moldova. Em iterações anteriores e recentes, o conjunto de ferramentas incluiu CurlCat para transferência bidirecional de dados, RuRat para acesso remoto persistente, Mimikatz para coleta de credenciais e o implante modular.NET MucorAgent. A nova observação amplia esse conjunto com o uso operacional de uma VM Linux oculta para manter controle e capacidade de tunelamento.
O fluxo depende de acesso prévio ao host Windows. Depois da presença inicial, o operador habilita Hyper-V e prepara uma máquina virtual Alpine Linux mínima. Essa escolha reduz consumo de recursos e torna a VM menos chamativa em inspeções superficiais de disco e memória. Dentro desse ambiente, são executados componentes voltados a shell reverso e proxy, separando a execução maliciosa do espaço monitorado com maior intensidade pelo EDR instalado no host.
CurlyShell é um binário ELF em C++ executado como daemon sem interface gráfica. Sua função é estabelecer conexão com servidor de comando e controle e permitir execução remota de comandos. A comunicação observada usa requisições HTTP GET para consultar novas instruções e HTTP POST para enviar resultados de execução. O contexto informa que os comandos são criptografados, o que limita a leitura direta do conteúdo em inspeções de tráfego que não consigam descriptografar ou correlacionar a sessão.
CurlCat compartilha grande parte da base de código com CurlyShell, mas seu tratamento dos dados recebidos é diferente. Enquanto CurlyShell executa comandos diretamente, CurlCat encaminha tráfego por SSH, funcionando como peça de tunelamento e controle flexível. O mesmo operador também recorreu a ferramentas como Resocks, Rsockstun, Ligolo-ng, CCProxy, Stunnel e métodos baseados em SSH, indicando insistência em manter proxy reverso e canais alternativos mesmo quando uma ferramenta específica é bloqueada ou removida.
A combinação de VM Linux, shell reverso e túneis amplia a dificuldade de resposta porque parte dos artefatos fica fora das trilhas Windows mais comuns. Um EDR pode continuar observando sinais no host, como ativação de recurso, criação de adaptadores virtuais, processos de gerenciamento do Hyper-V e movimentação de arquivos de VM, mas a execução interna do convidado exige telemetria adicional, inventário de VMs e inspeção de configuração de virtualização.
A superfície principal envolve estáções ou servidores Windows 10 onde um invasor já possui permissões suficientes para habilitar ou operar Hyper-V. O contexto não descreve exploração de falha específica, CVE ou zero-day para ativar a virtualização. Portanto, a condição defensiva mais importante é tratar a presença inesperada de Hyper-V em endpoints de usuário como evento de alto sinal, especialmente quando não há necessidade operacional legítima para máquinas virtuais locais.
Ambientes com EDR focado apenas no host Windows ficam mais expostos a essa técnica quando não correlacionam inventário de recursos opcionais, objetos de VM, arquivos de disco virtual, redes virtuais e processos de gerenciamento. A VM Alpine Linux mínima foi usada justamente para manter baixo consumo e hospedar ferramentas que fornecem controle remoto persistente, proxy reverso e encaminhamento de tráfego.
- Hosts Windows 10 com
Hyper-Vhabilitado sem justificativa administrativa ou de desenvolvimento. - Máquinas virtuais Linux pequenas, recém-criadas ou sem registro em inventário corporativo.
- Ambientes onde adaptadores virtuais, discos de VM e mudanças de papel do Windows não entram em correlação de segurança.
- Sistemas com histórico de ferramentas como
RuRat,Mimikatz,MucorAgent,CurlyShellouCurlCat.
A investigação deve começar no host Windows, porque a técnica exige mudanças visíveis na camada de virtualização. Registros de habilitação do papel Hyper-V, criação de VM, criação de redes virtuais, anexação de disco virtual e execução de processos administrativos relacionados à plataforma são pontos de partida. A presença de uma VM Alpine Linux com tamanho reduzido, sem dono operacional claro, deve ser tratada como anomalia quando aparecer em estáções comuns.
No endpoint, equipes devem correlacionar alterações de virtualização com sinais de acesso remoto e coleta de credenciais. O contexto associa a atividade a RuRat, Mimikatz e MucorAgent, além de scripts PowerShell voltados à execução remota de comandos. A defesa não deve considerar a VM como evidência isolada: o valor está em ligar a ativação de Hyper-V a autenticações incomuns, transferência de arquivos, novos serviços, persistência e tráfego HTTP ou SSH fora do padrão.
Na rede, a telemetria deve procurar padrões de beaconing HTTP compatíveis com consulta periódica por GET e envio de resultados por POST, além de fluxos SSH ou túneis que partem de hosts que não deveriam operar como pivôs. Como o conteúdo pode estar criptografado, tamanho, frequência, destino, processo de origem e associação com adaptadores virtuais tornam-se mais importantes que inspeção textual de payload.
- Ativação recente ou não aprovada do papel
Hyper-Vem endpoint Windows 10. - Criação de VM Linux mínima, disco virtual pequeno e consumo de memória compatível com ambiente oculto.
- Tráfego HTTP recorrente com padrão de consulta e retorno de resultados, especialmente quando associado a processos ou interfaces de virtualização.
- Uso de ferramentas de proxy e túnel como
Resocks,Rsockstun,Ligolo-ng,CCProxy,Stunnelou conexões SSH inesperadas. - Presença ou histórico de
CurlyShell,CurlCat,RuRat,MimikatzeMucorAgentem hosts relacionados.
A resposta deve priorizar confirmação de escopo antes de remover artefatos. Quando Hyper-V aparecer em host sem justificativa, preserve evidências de configuração da VM, discos virtuais, redes virtuais, horários de criação e contas envolvidas. A VM deve ser tratada como sistema potencialmente comprometido, com coleta forense própria, porque os binários Linux e a comunicação C2 podem estar dentro do convidado e não apenas no Windows.
A contenção deve bloquear canais de proxy e shell reverso, retirar permissões indevidas para habilitação de recursos opcionais do Windows e revisar contas administrativas locais. Como a atividade inclui ferramentas de coleta de credenciais, a rotação de credenciais deve ser considerada para contas usadas no host e para credenciais que possam ter sido acessadas durante a janela de comprometimento. A mitigação também exige revisar políticas que permitem virtualização em endpoints sem necessidade explícita.
A validação final precisa confirmar que não restaram VMs não inventariadas, túneis persistentes, serviços de acesso remoto e implantes associados. Detecções devem ser ajustadas para cobrir tanto processos Windows ligados ao Hyper-V quanto telemetria de rede originada de interfaces virtuais. Em ambientes com uso legítimo de virtualização, a separação entre uso autorizado e abuso deve ser feita por inventário, proprietário, finalidade, horário de criação e compatibilidade com padrões normais de tráfego.
- Inventariar hosts com
Hyper-Vativo e validar justificativa operacional para cada endpoint. - Bloquear ou restringir habilitação de virtualização local por usuários e contas que não precisam desse recurso.
- Coletar e analisar VMs, discos virtuais e configurações de rede antes de apagar artefatos.
- Procurar e remover ferramentas de shell reverso, proxy, túnel e acesso remoto persistente associadas ao cluster.
- Rotacionar credenciais potencialmente expostas quando houver evidência de uso de
Mimikatzou acesso a material sensível. - Adicionar alertas para criação de VM pequena, adaptadores virtuais inesperados e tráfego HTTP ou SSH incompatível com a função do host.
0 Comentários