GrimResource - 초기 액세스 및 회피를 위한 Microsoft 관리 콘솔

Overview

Microsoft가 인터넷에서 가져온 문서에 대해 기본적으로 Office 매크로를 비활성화한 후 JavaScript, MSI 파일, LNK 개체 및 ISO와 같은 다른 감염 경로의 인기가 급증했습니다. 그러나 이러한 다른 기법들은 방어자들이 면밀히 조사하기 때문에 탐지될 가능성이 높습니다. 숙련된 공격자들은 새로운 미공개 감염 경로를 활용하여 방어를 회피하면서 접근을 시도합니다. 최근의 사례는 북한 공격자들이 MSC 파일에서 새로운 명령 실행 기법을 사용하는 것과 관련이 있습니다.

Elastic 연구원들은 MSC 파일을 활용하는 새로운 감염 기법을 발견했으며, 이를 GrimResource라고 부릅니다. 공격자는 사용자가 특수하게 조작된 MSC 파일을 클릭한 후 mmc.exe 컨텍스트에서 전체 코드 실행 권한을 얻을 수 있습니다. GrimResource를 활용한 샘플은 6월 6일에 VirusTotal에 처음 업로드되었습니다.

핵심 사항

• Elastic Security 연구원들은 GrimResource라고 하는 특수하게 제작된 MSC 파일을 활용하는 새로운 코드 실행 기법을 발견했습니다.
• 공격자는 최소한의 보안 경고와 함께 Microsoft 관리 콘솔(mmc.exe)에서 임의의 코드를 실행할 수 있으므로 초기 액세스 권한을 얻고 방어를 회피하는 데 이상적입니다.
• Elastic은 커뮤니티가 스스로를 보호할 수 있도록 기술에 대한 분석과 탐지 지침을 제공하고 있습니다.

분석

GrimResource 기법의 핵심은 apds.dll 라이브러리에 존재하는 오래된 XSS 결함을 사용하는 것입니다. 공격자는 변조된 MSC 파일의 적절한 StringTable 섹션에 취약한 APDS 리소스에 대한 참조를 추가함으로써 mmc.exe 의 컨텍스트에서 임의의 자바스크립트를 실행할 수 있습니다. 공격자는 이 기법을 DotNetToJScript와 결합하여 임의의 코드를 실행할 수 있습니다.

이 글을 작성하는 시점에 야생에서 확인된 샘플은 VirusTotal에서 0 정적 탐지를 받았습니다.

이 샘플은 최근의 관련 없는 매크로 샘플에서 관찰된 transformNode 난독화 기법으로 시작됩니다. 이는 ActiveX 보안 경고를 회피하는 데 도움이 됩니다.

이렇게 하면 아래에 재구성된 것처럼 난독화된 임베디드 VBScript가 생성됩니다:

VBScript는 일련의 환경 변수에 대상 페이로드를 설정한 다음 DotNetToJs 기술을 활용하여 임베디드 .NET 로더를 실행합니다. 이 구성 요소의 이름은 PASTALOADER이며, 향후 이 특정 도구에 대한 추가 분석 결과를 공개할 수 있습니다.

페이로더는 이전 단계에서 VBScript로 설정한 환경 변수에서 페이로드를 검색합니다:

마지막으로 페이로더는 dllhost.exe 의 새 인스턴스를 생성하고 페이로드를 삽입합니다. 이는 DirtyCLR 기법, 함수 언훅, 간접 시스템 호출을 사용하여 의도적으로 은밀한 방식으로 이루어집니다. 이 샘플에서 최종 페이로드는 코발트 스트라이크입니다.

탐지

이 섹션에서는 이 샘플에 대한 현재 동작 탐지 기능을 살펴보고 기술 기본 요소를 겨냥한 새롭고 더 정밀한 동작 탐지 기능을 소개합니다.

Microsoft 공통 콘솔을 통한 의심스러운 실행

이 탐지 기능은 이 새로운 실행 기법을 발견하기 전에 확립되었습니다. 원래는 콘솔 태스크패드 명령줄 속성을 통해 명령을 실행하기 위해 동일한 MSC 파일 유형을 악용하는 다른 방법 (사용자가 MSC 파일을 연 후 태스크패드를 클릭해야 함)을 식별하기 위해 고안되었습니다:

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

이 샘플은 dllhost.exe의 희생 인스턴스를 스폰하고 주입하도록 선택했기 때문에 여기서 트리거됩니다:

비표준 Windows 스크립트 인터프리터에서 만든 .NET COM 개체

이 샘플은 WSH(Windows 스크립트 호스트) 스크립트 엔진(Jscript 또는 Vbscript)을 대신하여 .NET에서 RWX 메모리 할당을 찾는 또 다른 탐지를 트리거하는 DotNetToJScript 기법을 사용하고 있습니다:

다음 EQL 규칙은 .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|*"
)

다음 알림은 mmc.exe 이 RWX 메모리를 할당하는 것을 보여주고 process.thread.Ext.call_stack_summary 은 vbscript.dll 에서 clr.dll 로의 할당 출처를 캡처합니다:

MMC 콘솔 파일을 통한 스크립트 실행

앞서 두 번의 탐지 사례는 GrimResource 메서드를 무기화하기 위한 특정 구현 선택(DotNetToJS 및 하위 프로세스 생성)에 의해 트리거되었습니다. 이러한 탐지 기능은 OPSEC에 안전한 대안을 사용하여 우회할 수 있습니다.

mmc.exe 로딩 jscript.dll, vbscript.dll, msxml3.dll 과 같이 처음에는 의심스러워 보일 수 있는 다른 동작은 정상 데이터와 비교하여 명확히 확인할 수 있습니다. vbscript.dll 를 제외하고 이러한 WSH 엔진은 일반적으로 mmc.exe 에 의해 로드되는 것을 볼 수 있습니다:

이 방법의 핵심은 apds.dll을 사용하여 XSS를 통해 Jscript를 실행하는 것입니다. 이 동작은 mmc.exe Procmon 출력에서 CreateFile 작업으로 나타납니다(apds.dll 은 라이브러리로 로드되지 않음):

대상 파일이 apds.dll 이고 process.name 이 mmc.exe 인 경우 Elastic Defend 파일 열기 이벤트를 사용하여 다음 탐지를 추가했습니다 :

다음 EQL 규칙은 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"]

MMC 콘솔 파일을 통한 Windows 스크립트 실행

또 다른 탐지 및 포렌식 아티팩트는 APDS XSS 리디렉션의 결과로 redirect[*] 이라는 이름의 임시 HTML 파일이 INetCache 폴더에 생성되는 것입니다:

다음 EQL 상관관계를 사용하여 이 동작을 감지하는 동시에 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[?]"]

제공된 동작 규칙과 함께 다음 YARA 규칙을 사용하여 유사한 파일을 탐지할 수 있습니다:

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

결론

공격자는 변조된 MSC 파일을 사용하여 Microsoft 관리 콘솔에서 임의의 코드를 실행하는 새로운 기술을 개발했습니다. Elastic의 기존 즉시 적용 범위는 심층 방어 접근 방식이 이와 같은 새로운 위협에 대해서도 효과적이라는 것을 보여줍니다. 방어자는 이러한 기법이 상품 위협 그룹으로 확산되기 전에 저희의 탐지 지침을 활용하여 자신과 고객을 보호해야 합니다.

Observables

모든 관측값은 ECS 및 STIX 형식으로도 다운로드할 수 있습니다.

이 연구에서는 다음과 같은 관찰 가능성에 대해 논의했습니다.