GrimResource - Microsoft Management Console für Erstzugriff und Umgehung

Overview

Nachdem Microsoft Office-Makros standardmäßig für Dokumente aus dem Internet deaktiviert hat, haben andere Infektionsvektoren wie JavaScript, MSI-Dateien, LNK-Objekte und ISOs an Popularität gewonnen. Diese anderen Techniken werden jedoch von Verteidigern genau unter die Lupe genommen und haben eine hohe Wahrscheinlichkeit, entdeckt zu werden. Ausgereifte Angreifer versuchen, neue und unbekannte Infektionsvektoren zu nutzen, um sich Zugang zu verschaffen und gleichzeitig die Abwehrmaßnahmen zu umgehen. Ein aktuelles Beispiel betraf nordkoreanische Akteure, die eine neue Befehlsausführungstechnik in MSC-Dateien verwendeten.

Elastic-Forscher haben eine neue Infektionstechnik entdeckt, die ebenfalls MSC-Dateien nutzt und die wir als GrimResource bezeichnen. Es ermöglicht Angreifern, die vollständige Codeausführung im Kontext von mmc.exe zu erlangen, nachdem ein Benutzer auf eine speziell gestaltete MSC-Datei geklickt hat. Ein Beispiel , das GrimResource nutzt, wurde erstmals am 6. Juni auf VirusTotal hochgeladen.

Wichtigste Erkenntnisse

• Forscher von Elastic Security entdeckten eine neuartige In-the-Wild-Codeausführungstechnik, die speziell gestaltete MSC-Dateien nutzt, die als GrimResource bezeichnet werden
• GrimResource ermöglicht es Angreifern, beliebigen Code in der Microsoft Management Console (mmc.exe) mit minimalen Sicherheitswarnungen auszuführen, ideal für den ersten Zugriff und die Umgehung von Abwehrmaßnahmen
• Elastic stellt eine Analyse der Technik und Erkennungsanleitungen bereit, damit sich die Community schützen kann

Analyse

Der Schlüssel zur GrimResource-Technik ist die Verwendung eines alten XSS-Fehlers , der in der apds.dll -Bibliothek vorhanden ist. Durch Hinzufügen eines Verweises auf die anfällige APDS-Ressource im entsprechenden StringTable-Abschnitt einer präparierten MSC-Datei können Angreifer beliebiges Javascript im Kontext von mmc.exeausführen. Angreifer können diese Technik mit DotNetToJScript kombinieren, um die Ausführung beliebigen Codes zu erreichen.

Zum Zeitpunkt der Erstellung dieses Artikels wies die in freier Wildbahn identifizierte Stichprobe 0 statische Erkennungen in VirusTotal auf.

Das Beispiel beginnt mit einer transformNode-Verschleierungstechnik, die in neueren, aber nicht verwandten Makrobeispielen beobachtet wurde. Dies hilft bei der Umgehung von ActiveX-Sicherheitswarnungen.

Dies führt zu einem verschleierten eingebetteten VBScript, wie im Folgenden rekonstruiert:

VBScript legt die Zielnutzlast in einer Reihe von Umgebungsvariablen fest und nutzt dann die DotNetToJs-Technik , um ein eingebettetes .NET-Ladeprogramm auszuführen. Wir haben diese Komponente PASTALOADER genannt und werden in Zukunft möglicherweise weitere Analysen zu diesem speziellen Tool veröffentlichen.

PASTALOADER ruft die Nutzlast aus Umgebungsvariablen ab, die im vorherigen Schritt vom VBScript festgelegt wurden:

Schließlich spawnt PASTALOADER eine neue Instanz von dllhost.exe und injiziert die Nutzlast in diese. Dies geschieht auf absichtlich unauffällige Weise unter Verwendung der DirtyCLR-Technik , des Abkoppelns von Funktionen und indirekter Systemaufrufe. In diesem Beispiel ist die letzte Nutzlast Cobalt Strike.

Entdeckungen

In diesem Abschnitt untersuchen wir die aktuellen Verhaltenserkennungen für dieses Beispiel und stellen neue, präzisere Erkennungen vor, die auf die Technikprimitive abzielen.

Verdächtige Ausführung über die Microsoft Common Console

Diese Erkennung wurde bereits vor der Entdeckung dieser neuen Ausführungstechnik etabliert. Es wurde ursprünglich entwickelt, um eine andere Methode zu identifizieren (bei der der Benutzer nach dem Öffnen der MSC-Datei auf das Taskpad klicken muss), die denselben MSC-Dateityp ausnutzt, um Befehle über das Befehlszeilenattribut der Console Taskpads auszuführen:

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

Es wird hier ausgelöst, weil dieses Beispiel sich dafür entschieden hat, eine Opferinstanz von dllhost.exe zu erzeugen und zu injizieren:

.NET COM-Objekt, das in einem nicht standardmäßigen Windows-Skriptinterpreter erstellt wurde

Im Beispiel wird die DotNetToJScript-Technik verwendet, die eine weitere Erkennung auslöst, bei der im Auftrag eines Windows Script Host (WSH)-Skriptmoduls (Jscript oder Vbscript) von .NET nach RWX-Speicherbelegung gesucht wird:

Die folgende EQL-Regel erkennt die Ausführung über den .NET-Loader:

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

Die folgende Warnung zeigt mmc.exe Zuweisung von RWX-Speicher an, und die process.thread.Ext.call_stack_summary erfasst den Ursprung der Zuweisung von vbscript.dll zu clr.dll :

Skriptausführung über MMC-Konsolendatei

Die beiden vorherigen Erkennungen wurden durch bestimmte Implementierungsentscheidungen ausgelöst, um die GrimResource-Methode als Waffe einzusetzen (DotNetToJS und Erzeugen eines untergeordneten Prozesses). Diese Erkennungen können umgangen werden, indem OPSEC-sicherere Alternativen verwendet werden.

Andere Verhaltensweisen, die auf den ersten Blick verdächtig erscheinen mögen – wie z. B. mmc.exe Laden von jscript.dll, vbscript.dllund msxml3.dll – können im Vergleich zu gutartigen Daten geklärt werden. Wir können sehen, dass diese WSH-Motoren, mit Ausnahme von vbscript.dll, typischerweise von mmc.exebelastet werden:

Der Kernaspekt dieser Methode besteht darin , apds.dll zu verwenden, um Jscript über XSS auszuführen. Dieses Verhalten zeigt sich in der mmc.exe Procmon-Ausgabe als CreateFile Operation (apds.dll wird nicht als Bibliothek geladen):

Wir haben die folgende Erkennung mithilfe von Elastic Defend-Dateiöffnungsereignissen hinzugefügt, bei denen die Zieldatei apds.dll und die process.name mmc.exeist:

Die folgende EQL-Regel erkennt die Ausführung eines Skripts über die MMC-Konsole:

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

Ausführung von Windows-Skripts über MMC-Konsolendatei

Ein weiteres Erkennungs- und forensisches Artefakt ist die Erstellung einer temporären HTML-Datei im INetCache-Ordner, die als Ergebnis der APDS-XSS-Umleitung den Namen redirect[*] trägt:

Die folgende EQL-Korrelation kann verwendet werden, um dieses Verhalten zu erkennen und gleichzeitig den msc-Dateipfad zu erfassen:

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[?]"]

Neben den bereitgestellten Verhaltensregeln kann die folgende YARA-Regel verwendet werden, um ähnliche Dateien zu erkennen:

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

Fazit

Angreifer haben eine neue Technik entwickelt, um beliebigen Code in der Microsoft Management Console mithilfe von präparierten MSC-Dateien auszuführen. Die bestehende Out-of-the-Box-Abdeckung von Elastic zeigt, dass unser Defense-in-Depth-Ansatz auch gegen neuartige Bedrohungen wie diese wirksam ist. Verteidiger sollten unsere Erkennungsleitfäden nutzen, um sich und ihre Kunden vor dieser Technik zu schützen, bevor sie sich zu Standard-Bedrohungsgruppen ausbreitet.

Observables

Alle Observables stehen auch im ECS- und STIX-Format zum Download zur Verfügung .

Die folgenden Observablen wurden in dieser Studie diskutiert.