GrimResource - Consola de administración de Microsoft para acceso inicial y evasión

Overview

Después de que Microsoft deshabilitara las macros de Office de forma predeterminada para los documentos de Internet, otros vectores de infección como JavaScript, archivos MSI, objetos LNK e ISO aumentaron en popularidad. Sin embargo, estas otras técnicas son examinadas por los defensores y tienen una alta probabilidad de detección. Los atacantes maduros buscan aprovechar vectores de infección nuevos y no revelados para obtener acceso mientras evaden las defensas. Un ejemplo reciente involucró a actores de la RPDC que emplearon una nueva técnica de ejecución de comandos en archivos MSC.

Los investigadores de Elastic descubrieron una nueva técnica de infección que también aprovecha los archivos MSC, a los que nos referimos como GrimResource. Permite a los atacantes obtener la ejecución completa del código en el contexto de mmc.exe después de que un usuario haga clic en un archivo MSC especialmente diseñado. Una muestra que aprovecha GrimResource se subió por primera vez a VirusTotal el 6 de junio.

Conclusiones clave

• Los investigadores de Elastic Security descubrieron una novedosa técnica de ejecución de código que aprovecha los archivos MSC especialmente diseñados y conocidos como GrimResource
• GrimResource permite a los atacantes ejecutar código arbitrario en Microsoft Management Console (mmc.exe) con advertencias de seguridad mínimas, ideal para obtener acceso inicial y evadir las defensas
• Elastic proporciona análisis de la técnica y orientación de detección para que la comunidad pueda proteger

Análisis

La clave de la técnica GrimResource es usar un viejo defecto de XSS presente en la biblioteca apds.dll . Al agregar una referencia al recurso APDS vulnerable en la sección StringTable apropiada de un archivo MSC diseñado, los atacantes pueden ejecutar javascript arbitrario en el contexto de mmc.exe. Los atacantes pueden combinar esta técnica con DotNetToJScript para obtener la ejecución de código arbitrario.

En el momento de escribir este artículo, la muestra identificada en la naturaleza tenía 0 detecciones estáticas en VirusTotal.

La muestra comienza con una técnica de ofuscación transformNode, que se observó en macromuestras recientes pero no relacionadas. Esto ayuda a evadir las advertencias de seguridad de ActiveX.

Esto conduce a un VBScript incrustado ofuscado, como se reconstruye a continuación:

VBScript establece la carga de destino en un serial de variables de entorno y, a continuación, aprovecha la técnica DotNetToJs para ejecutar un cargador de .NET incrustado. Llamamos a este componente PASTALOADER y es posible que publiquemos análisis adicionales sobre esta herramienta específica en el futuro.

PASTALOADER recupera la carga útil de las variables de entorno establecidas por VBScript en el paso anterior:

Finalmente, PASTALOADER genera una nueva instancia de dllhost.exe e inyecta la carga útil en ella. Esto se hace de forma deliberadamente sigilosa mediante la técnica DirtyCLR , el desenlace de funciones y las llamadas indirectas al sistema. En este ejemplo, la carga útil final es Cobalt Strike.

Detecciones

En esta sección, examinaremos las detecciones de comportamiento actuales para esta muestra y presentaremos otras nuevas y más precisas dirigidas a las primitivas técnicas.

Ejecución sospechosa a través de Microsoft Common Console

Esta detección se estableció antes de que descubriéramos esta nueva técnica de ejecución. Originalmente se diseñó para identificar un método diferente (que requiere que el usuario haga clic en el panel de tareas luego de abrir el archivo MSC) que explota el mismo tipo de archivo MSC para ejecutar comandos a través del atributo de línea de comandos de 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")

Se desencadena aquí porque este ejemplo optó por generar e inyectar una instancia de sacrificio de dllhost.exe:

Objeto COM de .NET creado en un intérprete de scripts de Windows no estándar

En el ejemplo se usa la técnica DotNetToJScript , que desencadena otra detección que busca la asignación de memoria RWX de .NET en nombre de un motor de scripts de Windows Script Host (WSH) (Jscript o Vbscript):

La siguiente regla EQL detectará la ejecución a través del cargador de .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|*"
)

La siguiente alerta muestra mmc.exe asignación de memoria RWX y el process.thread.Ext.call_stack_summary captura el origen de la asignación de vbscript.dll a clr.dll :

Ejecución de scripts a través del archivo de consola MMC

Las dos detecciones anteriores se desencadenaron mediante opciones de implementación específicas para convertir el método GrimResource en un arma (DotNetToJS y generación de un proceso secundario). Estas detecciones se pueden omitir mediante el uso de alternativas más seguras para OPSEC.

Otros comportamientos que inicialmente pueden parecer sospechosos, como mmc.exe cargando jscript.dll, vbscript.dlly msxml3.dll , se pueden aclarar en comparación con los datos benignos. Podemos ver que, a excepción de vbscript.dll, estos motores WSH suelen estar cargados por mmc.exe:

El aspecto central de este método implica el uso de apds.dll para ejecutar Jscript a través de XSS. Este comportamiento es evidente en la salida de Procmon mmc.exe como una operación CreateFile (apds.dll no se carga como una biblioteca):

Agregamos la siguiente detección mediante eventos de apertura de archivos de Elastic Defend donde el archivo de destino es apds.dll y el process.name es mmc.exe:

La siguiente regla EQL detectará la ejecución de un script desde la consola 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"]

Ejecución de scripts de Windows a través del archivo de consola MMC

Otro artefacto forense y de detección es la creación de un archivo HTML temporal en la carpeta INetCache, llamado redirect[*] como resultado de la redirección XSS de APDS:

La siguiente correlación EQL se puede emplear para detectar este comportamiento y, al mismo tiempo, capturar la ruta del archivo 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[?]"]

Junto con las reglas de comportamiento proporcionadas, se puede usar la siguiente regla YARA para detectar archivos similares:

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*)
}

Conclusión

Los atacantes desarrollaron una nueva técnica para ejecutar código arbitrario en Microsoft Management Console empleando archivos MSC diseñados. La cobertura inmediata existente de Elastic muestra que nuestro enfoque de defensa en profundidad es efectivo incluso contra amenazas novedosas como esta. Los defensores deben aprovechar nuestra guía de detección para proteger a sí mismos y a sus clientes de esta técnica antes de que prolifere en grupos de amenazas de productos básicos.

Observables

Todos los observables también están disponibles para su descarga en formatos ECS y STIX.

En esta investigación se discutieron los siguientes observables.