Falso ou falso: conheça os métodos usados pelo OceanLotus

Investigadores da ESET detalham truques e técnicas usados nos últimos tempos pelo OceanLotus para distribuir backdoors e mantê-las no radar.

Este artigo vai descreve em primeiro lugar como o grupo OceanLotus (também conhecido como APT32 e APT-C-00) utilizou recentemente um dos exploits disponíveis de forma pública para explorar a CVE-2017-11882, uma vulnerabilidade de corrupção de memória presente no Microsoft Office, e como o malware do OceanLotus consegue manter a persistência nos sistemas comprometidos sem deixar rasto. Logo, o artigo descreve como é que desde o início de 2019 o grupo tem conseguido aproveitar-se de arquivos de extração automática para executar código.

Contexto

Acompanhar as atividades do OceanLotus é sinónimo de realizar uma tour pelo mundo da deceção. Este grupo é conhecido por manipular as suas vítimas com falsos e atrativos documentos com o objetivo de atrair potenciais vítimas para que executem o backdoor do grupo, e continua a desenvolver novas ideias para diversificar as suas ferramentas. As técnicas utilizadas para criar chamariz vão desde os arquivos com dupla extensão, arquivos de extração automática e documentos com macros capazes para reutilizar exploits conhecidos. Para além disso, são muito ativos e continuam a atacar de forma incansável as suas vítimas favoritas: os países do sudeste asiático.

Resumo do exploit do Equation Editor

Em meados de 2018, o OceanLotus avançou com uma campanha onde utilizava documentos que abusavam da vulnerabilidade CVE-2017-11882, a qual reside no componente responsável por renderizar e editar equações matemáticas. De facto, várias Provas de Conceito começaram a circular. Um dos documentos maliciosos utilizados pelo OceanLotus foi analisado pelo 360 Threat Intelligence Center e inclui detalhes sobre o exploit. Mas olhámos também para um outro documento.

Primeira fase

O documento “FW Report on demonstration of former CNRP in Republic of Korea.doc” (SHA-1: D1357B284C951470066AAA7A8228190B88A5C7C3) é semelhante ao mencionado no ponto anterior, e também é interessante porque aponta especificamente para pessoas interessadas na política cambojana (Partido Nacional de Resgate do Camboja – é um partido político que se dissolveu no final de 2017). Apesar da sua extensão .doc, o documento está na realidade no formato RTF (consulte a Figura 1), com informação que não interessa e com um formato errado.

Figura 1 – Campos lixo do RTF

Apesar da presença de elementos com formato errado, o Word abre com sucesso este arquivo RTF. Como se pode verificar na imagem (ver Figura 2), no deslocamento 0xC00 existe uma estrutura EQNOLEFILEHDR, seguida pelo cabeçalho MTEF e logo de seguida um registo MTEF (Figura 3) para uma fonte.

Figura 2 – Valores de registo FONT
Figura 3 – Formatos de registo FONT

Um overflow no campo “nome” é possível devido ao facto do seu tamanho não ser verificado antes de ser copiado. Um nome que é demasiado grande ativa a vulnerabilidade. Como se viu no conteúdo do arquivo RTF (deslocamento 0xC26 na Figura 2), o buffer completa-se com um shellcode seguido de uma instrução NOP sled (0x90) e a direção de retorno 0x402114. Essa direção faz parte do EQNEDT32.exe apontando a uma instrução RET. Isto resulta no EIP a apontar para o início do campo do nome que contém um shellcode.

Figura 4 – Início do shellcode exploit

A direção 0x45BD3C armazena uma varável sem referência até alcançar um ponteiro para a estrutura MTEFData atualmente carregada. É aqui que fica armazenado o que resta do shellcode.

O propósito deste trecho de código é executar a segunda parte do shellcode embebida no documento aberto. Primeiro, o shellcode inicial tenta encontrar o handler do documento aberto, repetindo-o através de todos os identificadores ativos do sistema (NtQuerySystemInformation com o argumento SystemExtendedHandleIn formation) verificando se o PID dos processos coincide com o PID de um processo WinWord, e se o documento foi aberto com a seguinte máscara de acesso: 0x12019F. Para confirmar que encontrou o handle correto, o conteúdo do arquivo é mapeado com a função CreateFileMapping e o shellcode reforça se os últimos quatro bytes do documento são “yyyy”, esta técnica é denominada por “Egg Hunting”. Uma vez que encontra uma coincidência, o documento é copiado para uma pasta temporal (GetTempPath) como o ole.dll. Assim, os últimos 12 bytes do documento são lidos.

Figura 5 – Marcadores no final do documento

O valor de 32-bit entre os marcadores AABBCCDD e yyyy representa o deslocamento até à parte seguinte do shellcode. É invocado utilizando a função CreatThread. O shellcode extraído é o mesmo que o grupo OceanLotus esteve a utilizar faz algum tempo. O script emulator da Phyton continua a funcionar para dumpear a fase seguinte.

Segunda fase

Extraindo os componentes

Os nomes de arquivo e os diretórios são escolhidos de forma dinâmica. O código aleatoriamente seleciona o nome do arquivo de um executável ou arquivo DLL localizado no C:\Windows\system32. Nesse momento vai consultar os seus recursos e extrair o campo FileDescription para utilizar como nome da pasta. Se isto não funcionar, o código escolhe aleatoriamente um nome para a pasta a partir dos diretórios %ProgramFiles% ou C:\Windows (a partir do GetWindowsDirectoryW). Evita um nome que possa entrar em conflito com os arquivos existentes ao assegurar-se de que não contenha: Windows, Microsoft, desktop, system, system32 ou syswow64. Se o diretório já existir, ao nome do diretório é acrescentado “NLS_{6 dígitos}”.

O recurso 0x102 da fase é analisado e os arquivos são descartados para uma pasta escolhida de forma aleatória, seja no %ProgramFiles% ou no %AppData%. Os tempos de criação modificam-se para que tenham os mesmos valores que o kernel32.dll.

Por exemplo, se existe uma pasta e lista de arquivos criados a partir de uma seleção dos executáveis C:\Windows\system32\TCPSVCS.exe como fonte de dados.

Figura 6 – Extração dos diferentes componentes

A estrutura do recurso 0x102 no dropper é bastante complexa.

Inclui:

  • Nomes de arquivos
  • Dimensão e conteúdo dos arquivos
  • Formato de compressão (COMPRESSION_FORMAT_LZNT1 utilizado pelo RtIDecompressBuffer function)

O primeiro arquivo é descartado como TCPSVCS.exe, que é de facto o legítimo AcroTranscoder.exe da Adobe (segundo o seu FileDescription, SHA-1: 2896738693A8F36CC7AD83EF1FA46F82F32BE5A3).

Provavelmente, já reparou que a dimensão de alguns arquivos DLL excede os 11MB. Isto porque um grande e contíguo buffer de dados aleatórios é colocado dentro do executável. Possivelmente esta será uma forma de evadir a deteção de algumas soluções de segurança.

Alcançando a persistência

O recurso do 0x101 do dropper contém dois inteiros de 32 bits que determinam como será implementada a persistência. O valor do primeiro especifica como o malware conseguirá a persistência num sistema sem privilégios de administração.

O valor do segundo inteiro especifica de que forma o malware deverá tentar ganhar a persistência se corre com privilégios elevados.

O nome do serviço é o nome do arquivo sem a extensão; o nome que se mostra é o nome da pasta, mas se já existe, então a string “Revision 1” é adicionada (o número é incrementado até encontrar um nome que não tenha sido usado). Os operadores certificam-se de que a persistência através do serviço seja resiliente: em caso de falhas do serviço, o mesmo deve ser reiniciado após 1 segundo. De seguida, o valor de registo WOW64 da nova chave de serviço é definido como 4, o que indica que é um serviço de 32 bits.

A tarefa programada é criada através de várias interfaces COM: ITaskScheduler, ITask, ITaskTrigger, IPersistFile e ITaskScheduler. Essencialmente, o malware cria uma tarefa oculta, estabelece a informação da conta com o utilizador atual ou o administrador da informação e estabelece a ativação

Esta é uma tarefa diária com uma duração de 24 horas e um intervalo entre as duas execuções estabelecido em 10 minutos, o que significa que será executado de forma permanente.

O bit malicioso

Em nosso exemplo, o executável TCPSVCS.exe (AcroTranscoder.exe) é um software legítimo que carrega em modo lateral as DLLs que foram eliminadas com ele. Neste caso, o interessante é o Flash Video Extension.dll.

A sua função DLLMain irá chamar uma única função. Algumas variantes são ofuscadas:

Figura 7 – Variáveis escondidas

Depois destas revisões enganosas, o código obtém a secção .text do TCPSVCS.exe, altera sua proteção para PAGE_EXECUTE_READWRITE e sobrescreve com instruções para não fazer nada que não tenha efeitos colaterais:

Figura 8 – Sequência de instruções sem efeitos secundários

No final, uma instrução CALL é adicionada ao endereço da função FLVCore :: Uninitialize (void) e exportada pelo Flash Video Extension.dll. Isso significa que, depois de carregar a DLL maliciosa, quando se executa o runtime chame o WinMain no TCPSVCS.exe, o ponteiro das instruções apontará para o “NOP” sled, que eventualmente chamará a próxima fase FLVCore :: Uninitialize (void).

Esta função simplesmente cria um mutex que começa com {181C8480-A975-411C-AB0A-630DB8B0A221} seguido pelo nome do utilizador atual. Em seguida, lê o arquivo descartado com a extensão .db3, que contém código independente da posição, e usa o CreateThread para executar seu conteúdo

O conteúdo do arquivo .db3 é um shellcode normalmente utilizado pelo OceanLotus. Mais uma vez, descompactamos com êxito o seu payload usando o script de emulador que publicamos no GitHub.

O script extrai a fase final. Ele é reconhecido pelo GUID {A96B020F-0000-466F-A96D-A91BBF8EAC96} que está presente no binário. A configuração do malware mantém-se encriptada num recurso PE. Contém praticamente a mesma configuração, mas os servidores C&C são diferentes daqueles que até agora tinham sido publicados:

  • andreagahuvrauvin[.]com
  • byronorenstein[.]com
  • stienollmache[.]xyz

Mais uma vez, o OceanLotus demonstra uma grande combinação de técnicas para permanecer fora do alcance das análises. Regressaram com uma versão melhorada do processo de infeção. Ao escolher nomes aleatórios e preencher executáveis com dados aleatórios reduz o número de IoCs fiáveis (baseados no hash e no nome do arquivo). Além disso, desde que estão a usar a técnica de carregamento lateral de DLL, os atacantes só devem conseguir descartar o binário legítimo do AcroTranscoder como está.

Arquivos de extração automática

Depois de usar arquivos RTF, o grupo começou a utilizar arquivos de extração automática (SFX) que utilizam ícones de documentos comuns numa tentativa de enganar suas vítimas. Quando são executados, estes arquivos RAR de extração automática são descartados e executados arquivos DLL (com uma extensão .ocx), com o payload final sendo anteriormente documentado {A96B020F-0000-466F-A96D-A91BBF8EAC96}.dll. Desde meados de janeiro de 2019, o OceanLotus começou a reutilizar a técnica, mas com o tempo mudaram parte da configuração. Esta seção descreverá a técnica e o que alteram para atingir seu objetivo.

Caindo na armadilha

O documento THICH-THONG-LAC-HANH-THAP-THIEN-VIET-NAM (1).EXE (que significa “RELAÇÃO FAVORITA DO DESEMPENHO VIETNAMITA”, de acordo com o Google Translate, SHA-1: AC10F5B1D5ECAB22B7B418D6E98FA18E32BBDEAB) foi visto pela primeira vez em 2018. Este arquivo SFX foi inteligentemente concebido, já que a descrição (Versão Info) indica que é uma “Imagem JPEG”. O script do SFX é o seguinte:

Figura 9 – Comandos SFX

O malware cai {9ec60ada-a200-4159-b310-8071892ed0c3}.ocx (SHA-1: EFAC23B0E6395B1178BCF7086F72344B24C04DCC) assim como a imagem 2018 thich thong lac.jpg.

A imagem chamariz é a seguinte:

Figura 10 – Imagem chamariz

Provavelmente já reparou que as primeiras duas linhas do script SFX invocam o arquivo OCX duas vezes, mas isto não é um erro…

{9ec60ada-a200-4159-b310-8071892ed0c3}.ocx (ShLd.dll)

O controlo do fluxo de arquivos OCX é muito similar a outros componentes do OceanLotus: existem muitas sequências de instruções JZ/JNZ e PUSH/RET intercalados com código lixo.

Figura 11 – Código escondido

Depois de filtrar o código que não interessa, a exportação DllRegisterServer denominada regsvr32.exe vê-se da seguinte forma:

Figura 12 – Código principal do instalador

Basicamente, a primeira vez que é chamado o DllRegisterServer, estabelece o valor de registo HKCU\SOFTWARE\Classes\CLSID\{E08A0F4B-1F65-4D4D-9A09-BD4625B9C5A1}\Model um deslocamento codificado no DLL (0x10001DE0). A segunda vez que a função é chamada o que faz é ler este mesmo valor e executa a função na direção. A partir daí, o recurso é lido e executado e muitas operações em memória são executadas.

O shellcode é o mesmo loader PE utilizado em campanhas antecipadas de OceanLotus. Pode ser emulado o nosso script de emulação miasm. Por último, cai db293b825dcc419ba7dc2c49fa2757ee.dll, carrega na memória e executa DllEntry.

Esta DLL recupera o conteúdo dos seus recursos, decifra (AES-256-CBC) e descomprime-o (LZMA). O recurso tem um formato específico ao qual é bastante simples aplicar engenharia inversa.

Figura 13 – Estrutura do instalador

A configuração é explícita: dependendo do nível de privilégios, os dados do binário serão ambos escritos %appdata%\Intel\logs\BackgroundUploadTask.cpl ou windir%\System32\BackgroundUploadTask.cpl (ou SysWOW64 para sistemas 64-bit). Assim, a persistência é obtida mediante a criação de uma tarefa chamada BackgroundUploadTask[junk].job na qual [junk] é uma coleção de 0x9D e 0xA0 bytes.

O nome da aplicação da tarefa é %windir%\System32\control.exe e o valor do parâmetro corresponde à rota do binário dumpeado. A tarefa é programada para correr diariamente.

Estruturalmente, o arquivo CPL é um DLL cujo nome interno é ac8e06de0a6c4483af9837d96504127e.dll que exporta uma função CPlApplet. Este arquivo decifra o seu único recurso {A96B020F-0000-466F-A96D-A91BBF8EAC96}.dll, e assim carrega a DLL e chama a sua única exportação, DllEntry.

Arquivo de configuração do backdoor

O backdoor apresenta uma configuração encriptada incorporada nos seus recursos. A estrutura do arquivo de configuração é bastante semelhante à anterior.

Figura 14 – Estrutura da configuração do backdoor (KaitaiStruct Visualizer)

Apesar da semelhança no que respeita á estrutura, em muitos destes campos os valores foram atualizados em comparação com o nosso white paper de março de 2018. O primeiro elemento da matriz binária contém uma DLL (HttpProv.dll MD5: 2559738D1BD4A999126F900C7357B759) identificado por Tencent mas como o nome da exportação foi removido do binário, os hashes não coincidem.

Indo mais além

Durante a pesquisa por amostras, algumas características destacaram-se. A amostra recentemente analisada apareceu por volta de julho de 2018 e outras semelhantes foram recentemente descobertas entre meados de janeiro e finais de fevereiro de 2019. O vetor de infeção usado foi um arquivo SFX que descartou um documento legítimo como um chamariz e um arquivo OCX malicioso.

Embora o OceanLotus utilize falsos timestamps, foi possível observar que o timestamp dos arquivos SFX e OCX é sempre o mesmo (0x57B0C36A (08/14/2016 @ 7:15 pm UTC) e 0x498BE80F (06/02/2009 @ 7:34 am UTC) respetivamente). Isto provavelmente significa que eles têm uma espécie de “builder” que reutiliza os mesmos templates e altera apenas algumas características.

Entre os documentos que analisámos desde o início de 2018, vimos diferentes nomes de documentos sugerirem uma relação com diferentes países como alvos de ataque.

  • The New Contact Information Of Cambodia Media(New).xls.exe
  • 李建香 (个人简历).exe (fake pdf document of a CV)
  • feedback, Rally in USA from July 28-29, 2018.exe

Desde a descoberta do backdoor {A96B020F-0000-466F-A96D-A91BBF8EAC96} .dll e a publicação de análises por parte de vários investigadores, observamos algumas mudanças na configuração dos dados dos malware. Primeiro, os autores começaram a remover os nomes das DLLs helper (DNSprov.dll, e as duas versões do HttpProv.dll). De seguida, os operadores pararam de empacotar a terceira DLL (segunda versão do HttpProv.dll) e decidiram embeber apenas uma.

Em segundo lugar, muitos dos campos na configuração dos backdoor foram modificados, talvez para evitar a deteção, uma vez que muitos IoCs foram tornados públicos.

Os campos importantes que foram modificados são os seguintes:

  • a chave de registo de “AppX” foi modificada (ver IoCs)
  • a codificação do string do mutex (“def”, “abc”, “ghi”)
  • o número da Porta

Finalmente, todas as variantes novas que analisámos apresentam novos servidores C&C, os quais estão listados na secção IoCs.

Conclusão

O OceanLotus está muito ativo e continua a evoluir. O grupo realmente concentra-se em fazer mudanças no seu set de ferramentas e tipo de chamariz. Inteligentemente escondem os seus payloads em documentos atrativos baseados em eventos atuais que devem ser de interesse para as vítimas que eles escolhem. Continuam a aparecer com diferentes técnicas e reutilizam mesmo e readaptam códigos de exploits disponíveis publicamente como fizeram com o exploit do Equation Editor. Para além disso, continuam a melhorar as suas técnicas para reduzir o número de artefactos que deixam nos computadores das suas vítimas, numa tentativa de reduzir as possibilidades de deteção de produtos de segurança. Outro ponto interessante é que alguns nomes de domínio parecem ter sido levar adiante as suas campanhas, mas não entrem em pânico…

Indicadores de Compromisso (IoCs)

Os IoCs neste post, assim como os atributos de MITRE ATT&CK, estão também disponíveis no nosso repositório no GitHub.

Chaves/valores de registo

Mutexes:

Arquivos:

Técnicas MITRE ATT&CK

DEIXE UMA RESPOSTA

Please enter your comment!
Please enter your name here

seventeen + twelve =