GrimResource - Microsoft Management Console pour l'accès initial et l'évasion

Overview

Après que Microsoft a désactivé les macros Office par défaut pour les documents provenant de l'internet, d'autres vecteurs d'infection tels que JavaScript, les fichiers MSI, les objets LNK et les ISO ont gagné en popularité. Toutefois, ces autres techniques sont examinées de près par les défenseurs et ont une forte probabilité d'être détectées. Les attaquants matures cherchent à exploiter des vecteurs d'infection nouveaux et non divulgués pour obtenir un accès tout en échappant aux défenses. Un exemple récent concerne des acteurs de la RPDC qui utilisent une nouvelle technique d'exécution des commandes dans les fichiers MSC.

Les chercheurs d'Elastic ont découvert une nouvelle technique d'infection exploitant également les fichiers MSC, que nous appelons GrimResource. Il permet aux attaquants d'obtenir une exécution complète du code dans le contexte de mmc.exe après qu'un utilisateur ait cliqué sur un fichier MSC spécialement conçu. Un échantillon exploitant GrimResource a été téléchargé pour la première fois sur VirusTotal le 6 juin.

Principaux points abordés dans cet article

• Les chercheurs d'Elastic Security ont découvert une nouvelle technique d'exécution de code qui exploite des fichiers MSC spécialement conçus sous le nom de GrimResource.
• GrimResource permet aux attaquants d'exécuter un code arbitraire dans Microsoft Management Console (mmc.exe) avec des avertissements de sécurité minimaux, ce qui est idéal pour obtenir un accès initial et échapper aux défenses.
• Elastic fournit une analyse de la technique et des conseils de détection afin que la communauté puisse se protéger.

Analyse

La clé de la technique GrimResource est l'utilisation d'une ancienne faille XSS présente dans la bibliothèque apds.dll. En ajoutant une référence à la ressource APDS vulnérable dans la section StringTable d'un fichier MSC, les attaquants peuvent exécuter du javascript arbitraire dans le contexte de mmc.exe. Les attaquants peuvent combiner cette technique avec DotNetToJScript pour obtenir une exécution de code arbitraire.

Au moment de la rédaction de cet article, l'échantillon identifié dans la nature comptait 0 détections statiques dans VirusTotal.

L'échantillon commence par une technique d'obscurcissement transformNode, qui a été observée dans des échantillons de macros récents mais sans rapport. Cela permet d'éviter les avertissements de sécurité ActiveX.

Cela conduit à un VBScript intégré obscurci, tel que reconstitué ci-dessous :

Le VBScript définit la charge utile cible dans une série de variables d'environnement, puis exploite la technique DotNetToJs pour exécuter un chargeur .NET intégré. Nous avons nommé ce composant PASTALOADER et nous pourrons publier à l'avenir d'autres analyses sur cet outil spécifique.

PASTALOADER récupère la charge utile à partir des variables d'environnement définies par le VBScript à l'étape précédente :

Enfin, PASTALOADER crée une nouvelle instance de dllhost.exe et y injecte la charge utile. Cela se fait de manière délibérément furtive en utilisant la technique DirtyCLR, le décrochage de fonction et les appels de service indirects. Dans cet exemple, la charge utile finale est Cobalt Strike.

Détections

Dans cette section, nous examinerons les détections de comportement actuelles pour cet échantillon et nous en présenterons de nouvelles, plus précises, visant les primitives techniques.

Exécution suspecte via Microsoft Common Console

Cette détection a été établie avant que nous ne découvrions cette nouvelle technique d'exécution. Il a été conçu à l'origine pour identifier une méthode différente (qui nécessite que l'utilisateur clique sur le Taskpad après avoir ouvert le fichier MSC) qui exploite le même type de fichier MSC pour exécuter des commandes par l'intermédiaire de l'attribut de ligne de commande des Taskpads de la console :

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")

Il se déclenche ici parce que cet échantillon a choisi d'engendrer et d'injecter une instance sacrificielle de dllhost.exe :

Objet COM .NET créé dans un interpréteur de script Windows non standard

L'exemple utilise la technique DotNetToJScript, qui déclenche une autre détection recherchant l'allocation de mémoire RWX à partir de .NET pour le compte d'un moteur de script Windows Script Host (WSH) (Jscript ou Vbscript) :

La règle EQL suivante détectera l'exécution via le chargeur .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|*"
)

L'alerte suivante montre que mmc.exe alloue de la mémoire RWX et que process.thread.Ext.call_stack_summary capture l'origine de l'allocation de vbscript.dll à clr.dll :

Exécution du script via le fichier de la console MMC

Les deux détections précédentes ont été déclenchées par des choix spécifiques de mise en œuvre de la méthode GrimResource (DotNetToJS et création d'un processus enfant). Ces détections peuvent être contournées en utilisant des solutions plus sûres pour l'OPSEC.

D'autres comportements qui peuvent sembler suspects au premier abord - tels que mmc.exe charger jscript.dll, vbscript.dll, et msxml3.dll - peuvent être clarifiés par rapport à des données bénignes. Nous pouvons constater que, à l'exception de vbscript.dll, ces moteurs WSH sont généralement chargés par mmc.exe:

L'aspect principal de cette méthode consiste à utiliser apds.dll pour exécuter Jscript via XSS. Ce comportement est évident dans la sortie de mmc.exe Procmon comme une opération CreateFile (apds.dll n'est pas chargé en tant que bibliothèque) :

Nous avons ajouté la détection suivante en utilisant les événements d'ouverture de fichiers d'Elastic Defend où le fichier cible est apds.dll et le process.name est mmc.exe:

La règle EQL suivante détecte l'exécution d'un script à partir de la console 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"]

Exécution d'un script Windows via un fichier de la console MMC

Un autre artefact de détection et de criminalistique est la création d'un fichier HTML temporaire dans le dossier INetCache, nommé redirect[*] , à la suite de la redirection XSS de l 'APDS :

La corrélation EQL suivante peut être utilisée pour détecter ce comportement tout en capturant le chemin d'accès au fichier 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[?]"]

Outre les règles de comportement fournies, la règle YARA suivante peut être utilisée pour détecter les fichiers similaires :

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

Conclusion

Des attaquants ont développé une nouvelle technique pour exécuter un code arbitraire dans Microsoft Management Console à l'aide de fichiers MSC élaborés. La couverture existante d'Elastic montre que notre approche de défense en profondeur est efficace, même contre des menaces inédites comme celle-ci. Les défenseurs devraient s'appuyer sur nos conseils en matière de détection pour se protéger et protéger leurs clients contre cette technique avant qu'elle ne se répande dans les groupes de menaces de produits de base.

Observables

Toutes les observables sont également disponibles au téléchargement dans les formats ECS et STIX.

Les observables suivants ont été examinés dans le cadre de cette recherche.