A Estratégia Shelby

Principais conclusões

• A família de malware SHELBY abusa do GitHub para comando e controle, roubando dados e recuperando comandos
• O design C2 do invasor tem uma falha crítica: qualquer pessoa com o token PAT pode controlar máquinas infectadas, expondo uma vulnerabilidade de segurança significativa
• Código não utilizado e carregamento dinâmico de carga útil sugerem que o malware está em desenvolvimento ativo, indicando que atualizações futuras podem resolver quaisquer problemas com versões contemporâneas

Resumo

Como parte de nossa pesquisa contínua sobre ameaças emergentes, analisamos um possível e-mail de phishing enviado de um endereço de e-mail pertencente a uma empresa de telecomunicações iraquiana e enviado a outros funcionários da mesma empresa.

O e-mail de phishing depende da vítima abrir o arquivo Details.zip anexado e executar o binário contido, JPerf-3.0.0.exe. Este binário utiliza o sistema de instalação orientado por script, Inno setup, que contém o aplicativo malicioso:

• %AppData%\Local\Microsoft\HTTPApi:
  • HTTPApi.dll (SHELBYC2)
  • HTTPService.dll (CARREGADOR SHELBY)
  • Microsoft.Http.Api.exe
  • Microsoft.Http.Api.exe.config

O Microsoft.Http.Api.exe instalado é um executável .NET benigno. Seu objetivo principal é carregar lateralmente o malicioso HTTPService.dll. Uma vez carregado, HTTPService.dll atua como o carregador, iniciando a comunicação com o GitHub para seu comando e controle (C2).

O carregador recupera um valor específico do C2, que é usado para descriptografar a carga útil do backdoor, HTTPApi.dll. Após a descriptografia, o backdoor é carregado na memória como um assembly gerenciado usando reflexão, permitindo que ele seja executado sem gravar no disco e evitando mecanismos de detecção tradicionais.

No momento em que este artigo foi escrito, tanto o backdoor quanto o loader tinham uma baixa taxa de detecção no VirusTotal.

Análise de código SHELBYLOADER

Ofuscação

Tanto o carregador quanto o backdoor são ofuscados com a ferramenta de código aberto Obfuscar, que emprega criptografia de strings como um de seus recursos. Para contornar essa ofuscação, podemos aproveitar o de4dot com parâmetros personalizados. Obfuscar substitui strings por chamadas para uma função descriptografadora de strings, mas ao fornecer o token dessa função para de4dot, podemos efetivamente desofuscar o código. Usando os parâmetros --strtyp (o tipo de descriptografador de string, no nosso caso delegate) e --strtok (o token do método de descriptografia de string), podemos substituir essas chamadas de função pelos seus valores de texto simples correspondentes, revelando as strings originais no código.

Detecção de sandbox

O SHELBYLOADER utiliza técnicas de detecção de sandbox para identificar ambientes virtualizados ou monitorados. Uma vez executado, ele envia os resultados de volta para C2. Esses resultados são empacotados como arquivos de log, detalhando se cada método de detecção identificou com sucesso um ambiente sandbox, por exemplo:

Técnica 1: Consulta WMI para informações do sistema

O malware executa uma consulta WMI (Select * from Win32_ComputerSystem) para recuperar detalhes do sistema. Em seguida, ele verifica os campos Fabricante e Modelo em busca de indicadores de uma máquina virtual, como "VMware" ou "VirtualBox".

Técnica 2: Enumeração de Processos

O malware verifica os processos em execução em busca de serviços conhecidos relacionados à virtualização, incluindo:

• vmsrvc
• vmtools
• xenservice
• vboxservice
• vboxtray

A presença desses processos informa ao malware que ele pode estar sendo executado em um ambiente virtualizado.

Técnica 3: Verificações do sistema de arquivos

O malware procura a existência de arquivos de driver específicos comumente associados ao software de virtualização, como:

• C:\Windows\System32\drivers\VBoxMouse.sys
• C:\Windows\System32\drivers\VBoxGuest.sys
• C:\Windows\System32\drivers\vmhgfs.sys
• C:\Windows\System32\drivers\vmci.sys

Técnica 4: Análise do tamanho do disco

O malware verifica o tamanho do volume C: . Se o tamanho for menor que 50 GB, pode-se inferir que o ambiente faz parte de uma sandbox, pois muitas máquinas virtuais são configuradas com tamanhos de disco menores para fins de teste.

Técnica 5: Verificação do processo dos pais

O malware examina seu processo pai. Se o processo pai não for explorer.exe, isso pode indicar execução em um ambiente de análise automatizado em vez de um cenário típico controlado pelo usuário.

Técnica 6: Detecção de desvio do tempo de sono

O malware utiliza verificações de tempo para detectar se suas funções de suspensão ou atraso estão sendo aceleradas, uma técnica comum usada por sandboxes para acelerar a análise. Desvios significativos nos tempos de sono esperados podem revelar um ambiente isolado.

Técnica 7: Consulta WMI para controlador de vídeo

O malware executa uma consulta WMI (SELECT * FROM Win32_VideoController) para recuperar informações sobre o controlador de vídeo do sistema. Em seguida, ele compara o nome do controlador de vídeo com valores conhecidos associados às máquinas virtuais: virtual ou vmware ou vbox.

Funcionalidade principal

O código do carregador do malware começa inicializando diversas variáveis dentro de seu construtor de classe principal. Essas variáveis incluem:

• Um nome de conta GitHub
• Um nome de repositório privado
• Um Token de Acesso Pessoal (PAT) para autenticação e acesso ao repositório

Além disso, o malware configura dois temporizadores, que são usados para acionar ações específicas em intervalos predefinidos.

Um dos temporizadores está configurado para acionar um método específico 125 segundos após a execução. Quando invocado, esse método estabelece persistência no sistema infectado adicionando uma nova entrada à chave do Registro do Windows SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Depois que o método é acionado e o mecanismo de persistência é executado com sucesso, o temporizador é impedido de disparar novamente.

Este método usa uma variável inteira para indicar o resultado de sua operação. A tabela a seguir descreve cada valor possível e seu significado:

Esse valor inteiro é reportado ao C2 durante seu primeiro registro no C2, permitindo que os invasores monitorem o sucesso ou a falha do mecanismo de persistência no sistema infectado.

O segundo temporizador é configurado para acionar um método responsável por carregar o backdoor, que é executado 65 segundos após o malware iniciar. Primeiro, o malware gera um hash MD5 com base em uma combinação de informações específicas do sistema. Os dados usados para criar o hash são formatados da seguinte forma, com cada componente separado por uma barra ( / ):

• O número de processadores disponíveis no sistema.
• O nome da máquina (nome do host).
• O nome de domínio associado à conta de usuário.
• O nome de usuário do usuário conectado no momento.
• O número total de unidades lógicas presentes no sistema.

Um subconjunto desse hash é então extraído e usado como um identificador exclusivo para a máquina infectada. Esse identificador serve como uma forma para os invasores rastrearem e gerenciarem sistemas comprometidos dentro de sua infraestrutura.

Depois de gerar o identificador exclusivo, o malware envia um novo commit para o repositório myToken usando uma solicitação HTTPS. O commit inclui um diretório nomeado após o identificador exclusivo, que contém um arquivo chamado Info.txt. Este arquivo armazena as seguintes informações sobre o sistema infectado:

• O nome de domínio associado à conta de usuário.
• O nome de usuário do usuário conectado no momento.
• O log dos resultados da detecção de sandbox detalhando quais técnicas foram bem-sucedidas ou falharam.
• O sinalizador de persistência (conforme descrito na tabela acima) indica o resultado do mecanismo de persistência.
• A data e hora atuais do evento de sinalização

O malware primeiro tenta enviar um commit para o repositório sem usar um proxy. Se essa tentativa inicial falhar, ele retornará ao uso do proxy configurado pelo sistema para sua comunicação.

Após o primeiro beacon e o registro bem-sucedido da vítima, o malware tenta acessar o mesmo diretório do repositório GitHub criado anteriormente e baixar um arquivo chamado License.txt (não observamos nenhuma instabilidade no intervalo de verificação, mas o servidor conseguiu lidar com isso). Se presente, este arquivo contém um valor de 48 bytes, que é usado para gerar uma chave de descriptografia AES. Este arquivo é carregado pelo backend do invasor somente após validar que o malware não está sendo executado em um ambiente sandbox. Isso garante que apenas infecções validadas recebam a chave e escalem a cadeia de execução para o backdoor.

O malware gera uma chave AES e um vetor de inicialização (IV) a partir do conteúdo de License.txt. Primeiro, ele faz o hash do valor de 48 bytes usando SHA256 e, em seguida, usa o hash resultante como a chave e os primeiros 16 bytes como o IV.

Ele prossegue para descriptografar o arquivo HTTPApi.dll, que contém a carga útil do backdoor. Após a descriptografia, o malware usa o método Assembly.Load para carregar reflexivamente o backdoor na memória. Essa técnica permite que o malware execute o backdoor descriptografado diretamente, sem gravá-lo no disco.

Mecanismo de chaveamento baseado em DNS

Outra variante do SHELBYLOADER usa uma abordagem diferente para registro e recuperação da sequência de bytes usada para gerar a chave AES e IV.

Primeiro, o malware executa os mesmos métodos anti-sandboxing, criando uma sequência de 1 ou 0 dependendo se um sandbox é detectado para cada técnica.

Para seu registro C2, o malware cria um subdomínio em arthurshelby.click com três partes: o primeiro subdomínio é uma string estática (s), o segundo subdomínio é o identificador exclusivo codificado em Base32 e o terceiro subdomínio é uma string concatenada no formato DomainName\HostName >> Anti-Sandboxing Results >> Persistence Flag codificado em base32.

Por exemplo, um domínio completo pode parecer s.grldiyrsmvsggojzmi4wmyi.inevyrcfknfvit2qfvcvinjriffe6ib6hyqdambqgaydambahy7cama.arthurshelby.click

Depois disso, o malware executa várias consultas DNS para subdomínios de arthurshelby.click. Os endereços IP retornados dessas consultas são concatenados em uma sequência de bytes, que é então usada para gerar a chave AES para descriptografar o backdoor, seguindo o mesmo processo descrito anteriormente.

Os subdomínios seguem este formato:

• O primeiro subdomínio é l<index>, onde o índice corresponde à ordem das chamadas DNS (por exemplo, l1, l2, etc.), garantindo que a sequência de bytes seja montada corretamente.
• O segundo subdomínio é o identificador exclusivo codificado em Base32.

Análise de código SHELBYC2

O backdoor começa regenerando o mesmo identificador exclusivo criado pelo carregador. Ele faz isso calculando um hash MD5 da string específica do sistema usada anteriormente. O backdoor então cria um Mutex para garantir que apenas uma instância do malware seja executada na máquina infectada. O Mutex é nomeado acrescentando a string Global\GHS ao identificador exclusivo.

Após 65 segundos, o backdoor executa um método que coleta as seguintes informações do sistema:

• identidade do usuário atual
• versão do sistema operacional
• o ID do processo do malware
• nome da máquina
• diretório de trabalho atual

Curiosamente, essas informações coletadas não são usadas localmente nem filtradas para o servidor C2. Isso sugere que o código pode ser um código morto deixado para trás durante o desenvolvimento ou que o malware ainda está em desenvolvimento ativo, com possíveis planos para utilizar esses dados em versões futuras.

O malware então carrega o registro de data e hora atual em um arquivo chamado Vivante.txt no repositório myGit dentro de seu diretório exclusivo (nomeado usando o identificador exclusivo do sistema). Esse registro de data e hora serve como o último horário de sinalização, permitindo que os invasores monitorem a atividade do malware e confirmem se o sistema infectado ainda está ativo. A palavra "Vivante" significa "vivo" em francês, o que reflete o papel do arquivo como um indicador de pulsação da máquina comprometida.

Em seguida, o malware tenta baixar o arquivo Command.txt, que contém uma lista de comandos emitidos pelo operador para execução no sistema infectado.

Se Command.txt não contiver comandos, o malware verifica se há comandos em outro arquivo chamado Broadcast.txt. Ao contrário de Command.txt, este arquivo está localizado fora do diretório do malware e é usado para transmitir comandos para todos os sistemas infectados simultaneamente. Essa abordagem permite que o invasor execute operações simultaneamente em várias máquinas comprometidas, agilizando o controle em larga escala.

Tabela de manipulação de comandos:

Os comandos no arquivo Command.txt podem ser comandos manipulados ou comandos do sistema executados com o Powershell. A seguir está uma descrição de cada comando manipulado.

/download

Este comando baixa um arquivo de um repositório GitHub para a máquina infectada. Requer dois parâmetros:

• O nome do arquivo armazenado no repositório GitHub.
• O caminho onde o arquivo será salvo na máquina infectada.

/carregar

Este comando carrega um arquivo da máquina infectada para o repositório GitHub. Ele recebe um parâmetro: o caminho do arquivo a ser carregado.

/dlextrair

Este comando baixa um arquivo zip do repositório GitHub (semelhante ao /download), extrai seu conteúdo e o salva em um diretório especificado na máquina.

/evocar

Este comando é usado para carregar um binário .NET reflexivamente; ele usa dois parâmetros: o primeiro parâmetro é o caminho de um binário .NET criptografado com AES baixado anteriormente para a máquina infectada, o segundo parâmetro é um valor usado para derivar o AES e o IV, semelhante a como o carregador carrega o backdoor.

Este comando carrega reflexivamente um binário .NET semelhante a como o SHELBYLOADER carrega o backdoor. Requer dois parâmetros:

• O caminho para um binário .NET criptografado em AES baixado anteriormente para a máquina infectada.
• Um valor usado para derivar a chave AES e IV.

Comandos do sistema

Qualquer comando que não comece com um dos acima é tratado como um comando do PowerShell e executado adequadamente.

Comunicação

O malware não usa a ferramenta Git no backend para enviar commits. Em vez disso, ele cria solicitações HTTP para interagir com o GitHub. Ele envia um commit para o repositório usando um objeto JSON com a seguinte estrutura:

{
  "message": "Commit message",
  "content": "<base64 encoded content>",
  "sha": "<hash>"
}

O malware define cabeçalhos HTTP específicos para a solicitação, incluindo:

• Aceitar: application/vnd.github.v3+json
• Tipo de conteúdo: application/json
• Autorização: token <PAT_token>
• Agente do usuário: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36

A solicitação é enviada ao ponto de extremidade da API do GitHub, construído da seguinte maneira:

https://api.github.com/repos/<owner>/<repo>/contents/<unique identifier>/<file>

O Token de Acesso Pessoal (PAT) necessário para acessar o repositório privado está incorporado ao binário. Isso permite que o malware se autentique e execute ações no repositório sem usar a cadeia de ferramentas padrão do Git.

A maneira como o malware é configurado significa que qualquer pessoa com o PAT (Personal Access Token) pode teoricamente buscar comandos enviados pelo invasor e acessar saídas de comandos de qualquer máquina da vítima. Isso ocorre porque o token PAT está incorporado no binário e pode ser usado por qualquer pessoa que o obtenha.

Conclusão da família SHELBY

Embora a infraestrutura C2 tenha sido projetada de forma exótica, o invasor ignorou os riscos e implicações significativos dessa abordagem.

Acreditamos que o uso desse malware, seja por uma equipe vermelha autorizada ou por um agente malicioso, constituiria negligência. Ele permite que qualquer vítima transforme o PAT incorporado em uma arma e assuma o controle de todas as infecções ativas. Além disso, se uma vítima enviar amostras para plataformas como VirusTotal ou MalwareBazaar, qualquer terceiro poderá acessar dados relacionados à infecção ou assumir o controle total das infecções.

Análise de campanha REF8685

O Elastic Security Labs descobriu o REF8685 por meio da coleta e análise de rotina de fontes de dados de terceiros. Ao estudar a intrusão REF8685, identificamos um carregador e um implante C2 que consideramos novos, o que nos levou a divulgar esta análise detalhada de malware e intrusão.

As cargas maliciosas foram entregues a uma empresa de telecomunicações sediada no Iraque por meio de um e-mail de phishing altamente direcionado enviado de dentro da organização visada. O texto do e-mail é uma discussão entre engenheiros sobre as especificações técnicas do gerenciamento da rede. Com base no conteúdo e no contexto do e-mail, não é provável que essa isca tenha sido criada externamente, indicando o comprometimento de endpoints de engenheiros, servidores de e-mail ou ambos.

Dears,

We would appreciate it if you would check the following alarms on Core Network many (ASSOCIATION) have been flapped.

Problem Text
*** ALARM 620 A1/APT "ARHLRF2SPX1.9IP"U 250213 1406
M3UA DESTINATION INACCESSIBLE
DEST            SPID
2-1936          ARSMSC1
END

Problem Text
*** ALARM 974 A1/APT "ARHLRF1SPX1.9IP"U 250213 1406
M3UA DESTINATION INACCESSIBLE
DEST            SPID
2-1936          ARSMSC1
END
…

Este e-mail contém um apelo à ação para abordar alarmes de rede e um anexo compactado chamado details.zip. Dentro desse arquivo zip há um arquivo de texto contendo os logs endereçados no e-mail e um executável do Windows (JPerf-3.0.0.exe), que inicia a cadeia de execução, resultando na entrega do implante SHELBYC2, fornecendo acesso remoto ao ambiente.

Embora não tenha sido observado na intrusão REF8685, deve-se observar que o VirusTotal mostra que JPerf-3.0.0.exe (feb5d225fa38efe2a627ddfbe9654bf59c171ac0742cd565b7a5f22b45a4cc3a) foi incluído em um arquivo compactado separado (JPerf-3.0.0.zip) e também enviado do Iraque. Não está claro se é da mesma vítima ou de outra nesta campanha. Uma pesquisa de similaridade de arquivo também identifica um segundo implante chamado Setup.exe com um arquivo compactado adicional (5c384109d3e578a0107e8518bcb91cd63f6926f0c0d0e01525d34a734445685c).

A análise desses arquivos (JPerf-3.0.0.exe e Setup.exe) revelou o uso do GitHub para C2 e mecanismos de recuperação de chaves AES (mais sobre isso nas seções de análise de malware). As contas do Github (arthurshellby e johnshelllby) usadas para o malware REF8685 eram maliciosas e foram encerradas pelo Github.

Vale ressaltar que Arthur e John Shelby são personagens da série de televisão britânica de drama policial Peaky Blinders. O show esteve em produção de 2013 a 2022.

O domínio arthurshelby[.]click apontou para 2.56.126[.]151, um servidor hospedado pela Stark Industries (AS44477). Este provedor de hospedagem VPS foi usado para serviços de proxy em outros ataques cibernéticos de larga escala. Este servidor tem resoluções sobrepostas para:

• arthurshelby[.]click
• [REDACTED]telecom[.]digital
• speed-test[.]click
• [REDACTED]airport[.]cloud
• [REDACTED]airport[.]pro

O arquivo compactado e os domínios C2 de uma das amostras SHELBYLOADER têm o nome da [REDIGIDO] Telecom, uma empresa de telecomunicações sediada no Iraque. O mapa de cobertura do [REDIGIDO] se concentra na região do Curdistão iraquiano no norte e leste do país.

“Sharjaairport” indica uma provável terceira vítima visada. O Aeroporto Internacional [REMOVIDO] ([REMOVIDO]) é um aeroporto internacional especializado em carga aérea nos Emirados Árabes Unidos. Fica a 23,3 km do Aeroporto Internacional de Dubai (DXB).

[REDACTED]airport[.]cloud resolvido para um novo servidor, 2.56.126[.]157, por um dia em jan 21, 2025. Depois, ele apontou para o DNS do Google, o servidor legítimo [REDIGIDO] do aeroporto e, finalmente, um endereço de estacionamento Namecheap. O servidor 2.56.126[.]157 , Stark Industries (AS44477) hospedado, também hospeda [REDACTED]-connect[.]online, [REDIGIDO] é o código do aeroporto para o Aeroporto Internacional [REDIGIDO].

O domínio [REDACTED]airport[.]cloud tem um subdomínio portal.[REDACTED]airport[.]cloud que apontou brevemente para 2.56.126[.]188 de 23 de janeiro25, 2025. Em seguida, ele direcionou o tráfego para 172.86.68[.]55 até o momento da redação deste artigo.

Os pivôs de hash de banner revelam uma combinação adicional de servidor-domínio: 195.16.74[.]138, [REDACTED]-meeting[.]online.

O servidor 172.86.68[.].55 também hospeda mail.[REDACTED]tell[.]com, um aparente domínio de phishing direcionado à nossa vítima original.

Uma página de login da web foi hospedada em hxxps://portal.[REDACTED]airport[.]cloud/Login (VirusTotal).

Avaliamos que os invasores usaram esses dois subdomínios como armas para obter credenciais de login na nuvem. Depois que essas credenciais foram protegidas (no caso da [REDIGIDO] Telecom), os invasores acessaram o e-mail na nuvem da vítima e criaram um phishing altamente direcionado, transformando em armas os tópicos de e-mail internos em andamento.

Esse e-mail interno transformado em arma foi usado para tentar phishing novamente nos endpoints das vítimas.

Todos os domínios associados a esta campanha utilizaram certificações ZeroSSL e estavam na infraestrutura da Stark Industries.

O modelo Diamond de análise de intrusão

O Elastic Security Labs utiliza o Modelo Diamond para descrever relacionamentos de alto nível entre adversários, capacidades, infraestrutura e vítimas de intrusões. Embora o Modelo Diamante seja mais comumente usado com intrusões únicas e aproveitando o Activity Threading (seção 8) como uma forma de criar relacionamentos entre incidentes, um modelo centrado no adversário (seção 7.1.4) abordagem permite um único diamante, embora desordenado.

REF8685 e MITRE ATT&CK

A Elastic usa a estrutura MITRE ATT&CK para documentar táticas, técnicas e procedimentos comuns que ameaças persistentes avançadas usam contra redes corporativas.

Táticas

As táticas representam o porquê de uma técnica ou subtécnica. É o objetivo tático do adversário: a razão para executar uma ação.

• Command and Control (Comando e controle)
• Acesso inicial
• Defense Evasion
• Descoberta
• Execução
• Exfiltração

Técnicas

Técnicas representam como um adversário atinge um objetivo tático executando uma ação.

• Carregamento de código reflexivo
• Phishing
• Arquivos ou informações ofuscadas
• Interpretador de comandos e scripts
• Exfiltração sobre o canal C2

Regra YARA

O Elastic Security criou regras YARA para identificar essa atividade. Abaixo estão as regras do YARA para identificar os malwares SHELBYC2 e SHELBYLOADER:

rule Windows_Trojan_ShelbyLoader {
    meta:
        author = "Elastic Security"
        creation_date = "2025-03-11"
        last_modified = "2025-03-25"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "ShelbyLoader"
        threat_name = "Windows.Trojan.ShelbyLoader"
        license = "Elastic License v2"

    strings:
        $a0 = "[WARN] Unusual parent process detected: "
        $a1 = "[ERROR] Exception in CheckParentProcess:" fullword
        $a2 = "[INFO] Sandbox Not Detected by CheckParentProcess" fullword
        $b0 = { 22 63 6F 6E 74 65 6E 74 22 3A 20 22 2E 2B 3F 22 }
        $b1 = { 22 73 68 61 22 3A 20 22 2E 2B 3F 22 }
        $b2 = "Persist ID: " fullword
        $b3 = "https://api.github.com/repos/" fullword
    condition:
        all of ($a*) or all of ($b*)
}

rule Windows_Trojan_ShelbyC2 {
    meta:
        author = "Elastic Security"
        creation_date = "2025-03-11"
        last_modified = "2025-03-25"
        os = "Windows"
        arch = "x86"
        category_type = "Trojan"
        family = "ShelbyC2"
        threat_name = "Windows.Trojan.ShelbyC2"
        license = "Elastic License v2"

    strings:
        $a0 = "File Uploaded Successfully" fullword
        $a1 = "/dlextract" fullword
        $a2 = "/evoke" fullword
        $a4 = { 22 73 68 61 22 3A 20 22 2E 2B 3F 22 }
        $a5 = { 22 2C 22 73 68 61 22 3A 22 }
    condition:
        all of them
}

Observações

Todos os observáveis também estão disponíveis para download nos formatos ECS e STIX em um pacote zip combinado.

Os seguintes observáveis foram discutidos nesta pesquisa.