GrimResource - Console de gerenciamento Microsoft para acesso inicial e evasão

Overview

Depois que a Microsoft desabilitou as macros do Office por padrão para documentos originados na Internet, outros vetores de infecção, como JavaScript, arquivos MSI, objetos LNK e ISOs, ganharam popularidade. No entanto, essas outras técnicas são examinadas pelos defensores e têm alta probabilidade de detecção. Atacantes experientes buscam aproveitar vetores de infecção novos e não divulgados para obter acesso e, ao mesmo tempo, escapar das defesas. Um exemplo recente envolveu atores da RPDC usando uma nova técnica de execução de comando em arquivos MSC.

Pesquisadores da Elastic descobriram uma nova técnica de infecção que também aproveita arquivos MSC, que chamamos de GrimResource. Ele permite que invasores obtenham execução completa de código no contexto de mmc.exe depois que um usuário clica em um arquivo MSC especialmente criado. Uma amostra utilizando o GrimResource foi carregada pela primeira vez no VirusTotal em 6 de junho.

Principais conclusões

• Pesquisadores da Elastic Security descobriram uma nova técnica de execução de código em campo, aproveitando arquivos MSC especialmente criados, chamados GrimResource
• O GrimResource permite que invasores executem código arbitrário no Microsoft Management Console (mmc.exe) com avisos de segurança mínimos, ideal para obter acesso inicial e evitar defesas
• A Elastic está fornecendo análise da técnica e orientação de detecção para que a comunidade possa se proteger

Análise

A chave para a técnica GrimResource é usar uma falha XSS antiga presente na biblioteca apds.dll . Ao adicionar uma referência ao recurso APDS vulnerável na seção StringTable apropriada de um arquivo MSC criado, os invasores podem executar javascript arbitrário no contexto de mmc.exe. Os invasores podem combinar essa técnica com DotNetToJScript para obter execução de código arbitrário.

No momento da redação deste artigo, a amostra identificada na natureza tinha 0 detecções estáticas no VirusTotal.

O exemplo começa com uma técnica de ofuscação transformNode, que foi observada em amostras de macro recentes, mas não relacionadas. Isso ajuda a evitar avisos de segurança do ActiveX.

Isso leva a um VBScript incorporado ofuscado, conforme reconstruído abaixo:

O VBScript define a carga útil de destino em uma série de variáveis de ambiente e, em seguida, aproveita a técnica DotNetToJs para executar um carregador .NET incorporado. Chamamos esse componente de PASTALOADER e podemos lançar análises adicionais sobre essa ferramenta específica no futuro.

PASTALOADER recupera a carga útil das variáveis de ambiente definidas pelo VBScript na etapa anterior:

Por fim, PASTALOADER gera uma nova instância de dllhost.exe e injeta a carga útil nela. Isso é feito de maneira deliberadamente furtiva usando a técnica DirtyCLR , desconexão de funções e chamadas de sistema indiretas. Neste exemplo, a carga útil final é o Cobalt Strike.

Detecções

Nesta seção, examinaremos as detecções de comportamento atuais para esta amostra e apresentaremos outras novas e mais precisas voltadas para as primitivas da técnica.

Execução suspeita via Microsoft Common Console

Essa detecção foi estabelecida antes da descoberta dessa nova técnica de execução. Ele foi originalmente projetado para identificar um método diferente (que exige que o usuário clique no Taskpad após abrir o arquivo MSC) que explora o mesmo tipo de arquivo MSC para executar comandos por meio do atributo de linha de comando do Console Taskpads:

process where event.action == "start" and
 process.parent.executable : "?:\\Windows\\System32\\mmc.exe" and  process.parent.args : "*.msc" and
 not process.parent.args : ("?:\\Windows\\System32\\*.msc", "?:\\Windows\\SysWOW64\\*.msc", "?:\\Program files\\*.msc", "?:\\Program Files (x86)\\*.msc") and
 not process.executable :
              ("?:\\Windows\\System32\\mmc.exe",
               "?:\\Windows\\System32\\wermgr.exe",
               "?:\\Windows\\System32\\WerFault.exe",
               "?:\\Windows\\SysWOW64\\mmc.exe",
               "?:\\Program Files\\*.exe",
               "?:\\Program Files (x86)\\*.exe",
               "?:\\Windows\\System32\\spool\\drivers\\x64\\3\\*.EXE",
               "?:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe")

Ele é acionado aqui porque este exemplo optou por gerar e injetar uma instância de sacrifício de dllhost.exe:

Objeto .NET COM criado no interpretador de scripts não padrão do Windows

O exemplo está usando a técnica DotNetToJScript , que aciona outra detecção procurando por alocação de memória RWX do .NET em nome de um mecanismo de script do Windows Script Host (WSH) (Jscript ou Vbscript):

A seguinte regra EQL detectará a execução por meio do carregador .NET:

api where
  not process.name : ("cscript.exe", "wscript.exe") and
  process.code_signature.trusted == true and
  process.code_signature.subject_name : "Microsoft*" and
  process.Ext.api.name == "VirtualAlloc" and
  process.Ext.api.parameters.allocation_type == "RESERVE" and 
  process.Ext.api.parameters.protection == "RWX" and
  process.thread.Ext.call_stack_summary : (
    /* .NET is allocating executable memory on behalf of a WSH script engine
     * Note - this covers both .NET 2 and .NET 4 framework variants */
    "*|mscoree.dll|combase.dll|jscript.dll|*",
    "*|mscoree.dll|combase.dll|vbscript.dll|*",
    "*|mscoree.dll|combase.dll|jscript9.dll|*",
    "*|mscoree.dll|combase.dll|chakra.dll|*"
)

O alerta a seguir mostra mmc.exe alocando memória RWX e process.thread.Ext.call_stack_summary captura a origem da alocação de vbscript.dll para clr.dll :

Execução de script via arquivo de console MMC

As duas detecções anteriores foram acionadas por escolhas específicas de implementação para transformar o método GrimResource em uma arma (DotNetToJS e geração de um processo filho). Essas detecções podem ser contornadas usando alternativas mais seguras para OPSEC.

Outros comportamentos que podem parecer inicialmente suspeitos — como mmc.exe carregamento jscript.dll, vbscript.dll e msxml3.dll — podem ser esclarecidos em comparação com dados benignos. Podemos ver que, exceto por vbscript.dll, esses mecanismos WSH são normalmente carregados por mmc.exe:

O aspecto central desse método envolve o uso de apds.dll para executar Jscript via XSS. Esse comportamento é evidente na saída do Procmon mmc.exe como uma operação CreateFile (apds.dll não é carregado como uma biblioteca):

Adicionamos a seguinte detecção usando eventos de abertura de arquivo do Elastic Defend onde o arquivo de destino é apds.dll e o process.name é mmc.exe:

A seguinte regra EQL detectará a execução de um script no console do MMC:

sequence by process.entity_id with maxspan=1m
 [process where event.action == "start" and
  process.executable : "?:\\Windows\\System32\\mmc.exe" and process.args : "*.msc"]
 [file where event.action == "open" and file.path : "?:\\Windows\\System32\\apds.dll"]

Execução de script do Windows via arquivo de console MMC

Outro artefato de detecção e forense é a criação de um arquivo HTML temporário na pasta INetCache, chamado redirect[*] como resultado do redirecionamento XSS do APDS:

A seguinte correlação EQL pode ser usada para detectar esse comportamento e também capturar o caminho do arquivo msc:

sequence by process.entity_id with maxspan=1m
 [process where event.action == "start" and
  process.executable : "?:\\Windows\\System32\\mmc.exe" and process.args : "*.msc"]
 [file where event.action in ("creation", "overwrite") and
  process.executable :  "?:\\Windows\\System32\\mmc.exe" and file.name : "redirect[?]" and 
  file.path : "?:\\Users\\*\\AppData\\Local\\Microsoft\\Windows\\INetCache\\IE\\*\\redirect[?]"]

Além das regras de comportamento fornecidas, a seguinte regra YARA pode ser usada para detectar arquivos semelhantes:

rule Windows_GrimResource_MMC {
    meta:
        author = "Elastic Security"
        reference = "https://www.elastic.co/security-labs/GrimResource"
        reference_sample = "14bcb7196143fd2b800385e9b32cfacd837007b0face71a73b546b53310258bb"
        arch_context = "x86"
        scan_context = "file, memory"
        license = "Elastic License v2"
        os = "windows"
    strings:
        $xml = "<?xml"
        $a = "MMC_ConsoleFile" 
        $b1 = "apds.dll" 
        $b2 = "res://"
        $b3 = "javascript:eval("
        $b4 = ".loadXML("
    condition:
       $xml at 0 and $a and 2 of ($b*)
}

Conclusão

Os invasores desenvolveram uma nova técnica para executar código arbitrário no Microsoft Management Console usando arquivos MSC criados. A cobertura pronta para uso da Elastic mostra que nossa abordagem de defesa em profundidade é eficaz até mesmo contra novas ameaças como essa. Os defensores devem aproveitar nossa orientação de detecção para proteger a si mesmos e seus clientes dessa técnica antes que ela se prolifere em grupos de ameaças de commodities.

Observables

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.