Tempestade no horizonte: GIMMICK Malware ataca no macOS
No final de 2021, a Volexity descobriu uma intrusão em um ambiente monitorado como parte de seu serviço de monitoramento de segurança de rede.
O Volexity detectou um sistema executando frp , também conhecido como proxy reverso rápido e, posteriormente, detectou a verificação de porta interna logo depois. Esse tráfego foi determinado como não autorizado e o sistema, um MacBook Pro executando o macOS 11.6 (Big Sur), foi isolado para análise forense adicional. O Volexity foi capaz de executar o Surge Collect para adquirir memória do sistema (RAM) e selecionar arquivos de interesse da máquina para análise. Isso levou à descoberta de uma variante do macOS de um implante de malware que o Volexity chama de GIMMICK . O Volexity encontrou versões do Windows da família de malware em várias ocasiões anteriores.
O GIMMICK é usado em ataques direcionados pela Storm Cloud , um agente de ameaças de espionagem chinês conhecido por atacar organizações em toda a Ásia. É uma família de malware multiplataforma rica em recursos que usa serviços de hospedagem em nuvem pública (como o Google Drive) para canais de comando e controle (C2). A variante macOS recém-identificada é escrita principalmente em Objective C, com versões do Windows escritas em .NET e Delphi. Apesar das principais diferenças nas linguagens de programação usadas e nos sistemas operacionais visados, o Volexity rastreia o malware com o mesmo nome devido à arquitetura C2 compartilhada, caminhos de arquivos e padrões comportamentais usados por todas as variantes.
Figura 1. O fluxo de trabalho do GIMMICK
Esta postagem de blog fornece uma análise aprofundada da variante macOS do GIMMICK, mas também demonstra os recursos e as características da variante Windows. A Volexity descobriu esta amostra através da análise de memória do sistema comprometido e conseguiu recuperar o implante da memória e do disco. O nome do arquivo e o caminho de instalação eram exclusivos do sistema da vítima e foram configurados de uma maneira projetada para combinar com as funções de trabalho do usuário. Além disso, o GIMMICK foi configurado para se comunicar apenas com seu servidor C2 baseado no Google Drive em dias úteis, a fim de se misturar ainda mais com o tráfego de rede no ambiente de destino.
O hash SHA1 do arquivo que o Volexity conseguiu obter do disco foi “fe3a3e65b86d2b07654f9a6104c8cb392c88b7e8”.
A Volexity trabalhou em estreita colaboração com a Apple para adicionar proteções para o malware GIMMICK em sua base de usuários. Em 17 de março de 2022, a Apple empurrou novas assinaturas para XProtect e MRT para bloquear e remover o GIMMICK. Embora ativado por padrão, os usuários podem confirmar que estão protegidos automaticamente verificando se a caixa “Instalar arquivos de dados do sistema e atualizações de segurança” está marcada em suas configurações (instruções podem ser encontradas aqui ).
Inicialização e inicialização
No macOS, o GIMMICK suporta o lançamento como um daemon no sistema ou por um usuário. Caso o GIMMICK seja iniciado diretamente por um usuário, em vez de um daemon, ele se instalará como um agente de inicialização soltando um arquivo PLIST com conteúdo, semelhante ao mostrado abaixo, em /Users/<username>/Library/LaunchAgents . O nome do binário, PLIST e agente variam de acordo com a amostra. No caso observado pela Volexity, o implante foi customizado para imitar um aplicativo comumente lançado pelo usuário alvo. Vale a pena notar que as versões para Windows do GIMMICK Volexity observadas não têm o conceito de definir sua própria persistência.
<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=”1.0″>
<dict>
<key>Etiqueta</key>
<string>com. /[nome do aplicativo].va.plist</string>
<key>ProgramArguments</key>
<matriz>
<string>/Users/#####/Library/Preferences/[pathto/binary]>/</string>
</array>
<key>RunAtLoad</key>
<verdadeiro/>
<key>StartInterval</key>
<integer>30</integer>
<key>ThrottleInterval</key>
<integer>2</integer>
<key>WorkingDirectory</key>
<string>/Users/<removido>/Library/Preferences/[applicationname]string>
</dict>
</plist>
Da mesma forma, o implante fornece uma função de desinstalação acessível adicionando o argumento “desinstalar” na linha de comando. Isso remove o implante e todos os arquivos associados e, em seguida, encerra o processo.
Durante a inicialização, a amostra decodifica vários dados críticos para a operação do malware usando um algoritmo de adição rotativa.
O primeiro loop de decodificação resulta em um objeto JSON contendo credenciais OAuth2 para estabelecer uma sessão no Google Drive. Um exemplo de objeto JSON é mostrado na Figura 2:
Figura 2. Um exemplo de objeto JSON contendo credenciais necessárias para autenticação com o Google Drive
O segundo loop decodifica a string de 32 bytes “943c3743f72f06e58e60fa147481db83”. Essa string é executada por meio de um estágio de conversão adicional que converte dois caracteres por vez em uma representação numérica e grava o byte resultante em um buffer. Este buffer é usado como uma chave AES em várias chamadas para a função CCCrypt() .
Figura 3. Conversão de chave AES
A decodificação final é feita no local e seu resultado é um blob binário de 200 bytes de dados de configuração, com apenas alguns limites de dados aparentemente visíveis.
Figura 4: blob de configuração
Fora essa ofuscação de dados e o uso de AES para determinados arquivos externos, o malware faz poucas tentativas de ofuscar sua funcionalidade ou presença no sistema.
Protocolo C2
Após a inicialização, a operação do malware GIMMICK é altamente assíncrona. Variantes anteriores do malware escrito para Windows conseguiram isso usando técnicas de pool de threads internas ao programa, fornecidas pelo System.Threading.TThreadPool do Delphi e System.Thread e System.Action do .NET. A variante macOS, no entanto, gerencia o protocolo usando a tecnologia Grand Central Dispatch (GCD) da Apple . Esse recurso permite que os desenvolvedores distribuam tarefas para um pool de threads gerenciado pelo sistema para processamento posterior. Essas tarefas são encapsuladas em objetos autocontidos chamados blocosque são agendados nas filas de despacho para processamento. As estruturas precisas e os detalhes de implementação do GCD são bastante complicados e estão além do escopo deste documento; vários recursos são fornecidos no Apêndice.
Existem três classes personalizadas de ObjectiveC no malware que gerenciam aspectos críticos do protocolo C2: DriveManager, FileManager e GCDTimerManager.
O DriveManager tem várias responsabilidades:
- Gerencie o Google Drive e as sessões de proxy.
- Mantenha um mapa local da hierarquia de diretórios do Google Drive na memória.
- Gerencie bloqueios para sincronizar tarefas na sessão do Google Drive.
- Gerencie tarefas de download e upload de e para a sessão do Google Drive.
Com base na forma como os arquivos de comando são enumerados pelo malware, o Google Drive parece ser preenchido com um diretório para cada host infectado. O nome desse diretório difere ligeiramente por plataforma. Os implantes do Windows geram um GUID exclusivo para operar como seu ID, enquanto o implante do macOS usa o próprio UUID de hardware da Apple para a tarefa.
O FileManager gerencia uma hierarquia de diretório local contendo informações C2 e tarefas de comando em vários estágios de conclusão. As variantes mais antigas do GIMMICK usavam nomes ligeiramente diferentes para diretórios, mas permaneceram consistentes em várias variantes recentes. O implante do macOS armazena essa hierarquia no diretório raiz do pacote principal do aplicativo em um diretório chamado “MGD”. Cada pasta dentro da estrutura de diretórios é designada para conter um único tipo de arquivo conforme ele se move pelo processo C2. Um resumo de todos os diretórios e sua finalidade são fornecidos na tabela abaixo.
Nome | Significado interpretado | Conteúdo |
tmp | Temporário | Local seguro temporário para gravação de arquivos; nenhum código de despacho está verificando arquivos neste diretório |
c | Credenciais | Armazena as credenciais criptografadas por AES JSON decodificadas durante a inicialização |
e | Erros | Armazena logs de erros como arquivos individuais; erros são relatados como valores integrais opacos de geralmente quatro dígitos |
p | Proxies | Armazena arquivos de definição de proxy que consistem em um host e uma porta separados por um “:” |
você | Comando de upload | Resultados de comandos criptografados por AES armazenados com upload pendente |
d | Baixar comando | Armazena arquivos de comando de download pendentes, cada um contendo o caminho do Google Drive de um arquivo de comando a ser baixado |
para | Baixar Sucesso | Local de armazenamento para arquivos de comando criptografados por AES baixados aguardando processamento |
df | Falha no Download | Local temporário para o comando de download com falha até que eles possam ser repetidos ou apagados |
eu | Comando Listar | Armazena a lista pendente de arquivos de comando que indicam o diretório do Google Drive do qual baixar comandos |
ls | Listar sucesso | Armazena arquivos de listagem temporários contendo caminhos de arquivos remotos do Google Drive para download |
se | Falha na lista | Local temporário para comandos de lista com falha até que eles possam ser repetidos ou apagados |
Nem todas as variantes do GIMMICK usam todos os diretórios. Por exemplo, o implante macOS não usa o diretório “df” e cria, mas não acessa, os diretórios “lf” e “p”.
GCDTimerManager gerencia os vários objetos GCD que garantem o envio regular de trabalho para o implante e mantém coleções dos temporizadores de envio junto com seus blocos correspondentes. O malware cria várias filas de expedição nomeadas para gerenciar tarefas específicas relacionadas a C2:
Nome | Objetivo |
SendBaseinfoQueue | Gera e envia regularmente uma mensagem de pulsação de reconhecimento do sistema para o C2 contendo o seguinte:Hardware UUIDEndereço MAC da interface eth0Cadeia de modelo de CPUOS Version string |
list_request_queue | Gera um arquivo de solicitação de lista no diretório “l” contendo um caminho no formato “/<HardwareUUID>” |
ls_cmd_queue | Analisa os arquivos do diretório “ls” e, para cada linha, grava um arquivo de comando de download correspondente no diretório “d” |
ReadCmdQueue | Descriptografa e analisa arquivos do diretório “ds” e executa os comandos contidos nele, salvando os resultados no diretório “u” |
CredsCheck | Verifica o tempo limite da sessão do Google Drive e autentica novamente, se necessário |
DriveClearTrashQueue | Exclui regularmente o arquivo da lixeira do Google Drive |
DriveDownQueue | Analisa os arquivos armazenados em “d” e baixa os arquivos correspondentes do Google Drive para o diretório “ds” |
DriveUploadQueue | Carrega arquivos de feedback armazenados no diretório “u” |
DriveFailUploadQueue | Segunda tentativa de fazer upload de itens de upload com falha. A segunda tentativa é marcada como bem-sucedida, independentemente do resultado. |
fileListQueue | Analisa os arquivos armazenados no diretório “l” e, para cada um, atualiza o mapa de diretórios do DriveManager do Google Drive e gera uma lista de arquivos para download no diretório “ls” |
Além disso, o GCDTimerManager usa as informações de configuração estática decodificadas durante a inicialização para definir um período de trabalho para o implante, limitando as conexões fora do horário comercial que podem chamar a atenção do defensor. Ele analisa o período de trabalho da string no início dos dados de configuração. Essa string começa com um conjunto de números de um dígito separados por caracteres de hífen, seguidos por dois caracteres de dois pontos e dois números de dois dígitos separados novamente por um hífen. O primeiro conjunto de números indica o número do dia em que o malware estará ativo, com o dia 0 sendo domingo. O segundo conjunto de números de dois dígitos indica o intervalo de horas ativas. Tomando o valor inicial de “1-2-3-4-5::00-23”, o implante estará ativo das 12h às 23h nos dias de semana—esse é o primeiro dado visto no blob de configuração mostrado na Figura 4.
Vida útil do comando
Devido à natureza assíncrona da operação do malware, a execução do comando requer uma abordagem em etapas. Embora as etapas individuais ocorram de forma assíncrona, cada comando segue as mesmas etapas:
- Uma carga útil criptografada é enviada pelo invasor ao Google Drive.
- O temporizador de despacho em “list_request_queue” é acionado.
- Novo arquivo de solicitação a ser gravado no diretório “l”
- O temporizador de despacho nos gatilhos “fileListQueue”.
- Lê a solicitação de lista do diretório “l”
- Atualiza o estado do DriveManager da sessão do Google Drive
- Solta um arquivo de listagem no diretório “ls”
- O temporizador de despacho em “ls_cmd_queue” é acionado.
- Analisa os arquivos de listagem do diretório “ls”
- Descarta arquivos de comando de download para cada arquivo remoto no diretório “d”
- Exclui os arquivos de listagem do diretório “ls”
- O temporizador de despacho em “DriveDownloadQueue” é acionado.
- Enumera os arquivos no diretório “d”
- Enfileira o download de arquivos de comando para o diretório “ds”
- Exclusão de filas do arquivo remoto do Google Drive e do arquivo de comando de download local após a conclusão do download
- O temporizador de despacho em “ReadCmdQueue” é acionado.
- Lê e descriptografa arquivos de comando do diretório “ds”
- Lida com a execução do comando
- Exclui o arquivo de comando local
- Grava arquivos de “feedback” criptografados no diretório “u”
- O temporizador de despacho em “DriveUploadQueue” é acionado.
- Enumera os arquivos no diretório “u”
- Enfileira o upload dos arquivos de resultado
- Enfileira a exclusão de arquivos de resultados locais assim que o upload for concluído
Comandos e Feedback
Os comandos chegam ao sistema como arquivos criptografados no diretório “ds” que, uma vez descriptografados com a chave AES estática do implante, resultam em um objeto JSON. Existem apenas quatro campos JSON lidos pelo analisador de comandos.
Nome | Tipo |
Tipo de CMD | Número |
contente | Corda |
parâmetros | Corda |
caminho de salvamento | Corda |
Embora cada JSON de comando deva ter um campo CMDType, os campos obrigatórios variam de comando para comando. A tabela abaixo resume os comandos disponíveis e seus campos obrigatórios.
Enum | Descrição | Campos JSON adicionais obrigatórios |
0 | Transmitir informações do sistema básico | Nenhum |
1 | Carregar arquivo para C2 | parâmetros |
2 | Baixar arquivo para o cliente | conteúdo, caminho de salvamento |
3 | Execute um comando shell e grave a saída em C2 | parâmetros |
4 | Definir o intervalo do timer do Google Drive do cliente | parâmetros |
5 | Definir o intervalo do temporizador do cliente para a mensagem de pulsação de informações do cliente | parâmetros |
6 | Substituir as informações do período de trabalho do cliente | parâmetros |
O feedback para o C2 também é formatado como JSON, com campos bastante semelhantes aos comandos. No entanto, todos os objetos JSON de feedback têm um campo obrigatório adicional, “uuid”, que é preenchido com o UUID de hardware do dispositivo.
Conclusão
Storm Cloud é um agente de ameaças avançado e versátil, adaptando seu conjunto de ferramentas para corresponder a diferentes sistemas operacionais usados por seus alvos. Eles fazem uso de utilitários de sistema operacional integrados, ferramentas de código aberto e implantes de malware personalizados para atingir seus objetivos. Aproveitar as plataformas de nuvem para C2, como o uso do Google Drive, aumenta a probabilidade de operar sem ser detectado por soluções de monitoramento de rede. Isso é especialmente verdadeiro quando combinado com o fato de que o malware apenas sinaliza nos dias úteis das vítimas.
Independentemente da plataforma, as amostras da família de malware GIMMICK são bastante grandes e complexas, o que se deve em parte à complexidade de seu design assíncrono, como os mecanismos de encadeamento e bloqueio necessários. O trabalho envolvido na portabilidade desse malware e na adaptação de seus sistemas para um novo sistema operacional (macOS) não é uma tarefa fácil e sugere que o agente da ameaça por trás dele tem bons recursos, é adepto e versátil. Vale a pena notar que o Volexity só observou o GIMMICK (macOS e Windows) em uso pelo Storm Cloud. No entanto, não se sabe se este implante de malware é desenvolvido ou usado exclusivamente por eles.
Para evitar que ataques semelhantes sejam bem-sucedidos, a Volexity recomenda o seguinte:
- Audite e monitore regularmente os locais de persistência, como LaunchAgents e LaunchDaemons em dispositivos macOS de endpoint. Isso pode ser feito através de uma solução EDR e/ou com ferramentas gratuitas como BlockBlock e KnockKnock.
- Monitore o tráfego de rede para atividades anômalas de proxy e varredura interna.
- Certifique-se de que o XProtect e o MRT da Apple estejam ativados e em execução em sistemas macOS.
Para evitar que esses ataques específicos sejam bem-sucedidos, a Volexity recomenda o seguinte:
- Use as regras fornecidas para identificar atividades relacionadas, fornecidas aqui.
Os arquivos relacionados a este post são fornecidos aqui.
Essa atividade de ameaça foi detalhada para os clientes do Volexity Threat Intelligence em MAR-20220120.
Apêndice
Os seguintes recursos descrevem o Grand Central Dispatch da Apple:
- https://www.amazon.com/dp/099105556X/ref=cm_sw_em_r_mt_dp_RYJ6VS3327WSY7SE551Y?_encoding=UTF8&psc=1 -> ISDN-13: 978-0991055562
- https://www.amazon.com/dp/0321706250/ref=cm_sw_em_r_mt_dp_7J0VBS0DW5NWAZAFT5ZF -> ISDN-13: 978-0321706256
- https://www.galloway.me.uk/2012/10/a-look-inside-blocks-episode-1/
- https://opensource.apple.com/source/libclosure/libclosure-67/BlockImplementation.txt.auto.html
Fonte: https://www.volexity.com/