커널 ETW는 최고의 ETW입니다.

서문

보안 설계 소프트웨어의 중요한 기능은 권한이 있는 작업이 수행될 때 감사 로그를 생성하는 것입니다. 이러한 기본 감사 로그에는 타사 보안 공급업체가 사후에 추가하기에는 비현실적인 내부 소프트웨어 상태에 대한 세부 정보가 포함될 수 있습니다.

대부분의 Windows 구성 요소는 Windows용 이벤트 추적 (ETW)을 사용하여 로그를 생성합니다. 이러한 이벤트는 Windows의 내부 작업 일부를 노출하며, 엔드포인트 보안 제품이 이러한 이벤트를 구독함으로써 이점을 얻을 수 있는 시나리오가 있습니다. 하지만 보안을 위해 모든 ETW 제공업체가 동일하게 만들어지는 것은 아닙니다.

첫 번째 고려 사항은 일반적으로 이벤트 제공업체 자체의 신뢰성, 특히 로깅이 발생하는 곳의 신뢰성입니다. 클라이언트 프로세스 내에 있으며 ETW 변조에 사소하게 취약한가요? 아니면 RPC 서버 프로세스에서 조금 더 안전할까요? 하지만 원격 분석은 커널에서 제공하는 것이 가장 이상적입니다. 사용자 대 커널의 보안 경계를 고려할 때, 이는 프로세스 중 원격 분석에 대해 보다 강력한 변조 방지 기능을 제공합니다. 이것이 Microsoft에서 권장하는 접근 방식입니다. Elastic Endpoint와 마찬가지로, 엔드포인트용 Microsoft Defender도 취약한 사용자 모드 ntdll 후크 대신 커널 ETW를 사용합니다.

예를 들어 공격자는 ntdll!NtProtectVirtualMemory 에서 진행 중인 사용자 모드 훅을 쉽게 피할 수 있지만 커널 PROTECTVM ETW 이벤트를 우회하는 것은 훨씬 더 어렵습니다. 아니면 적어도 그래야 합니다.

보안 이벤트 로그는 사실상 Microsoft-Windows-Security-Auditing ETW 공급자의 이벤트에 대한 영구 저장소일 뿐입니다. 놀랍게도 프로세스 생성을 위한 보안 이벤트 4688은 커널 이벤트가 아닙니다. 커널은 데이터를 로컬 보안 기관(lsass.exe) 서비스로 전송하여 이벤트 로그가 사용할 수 있도록 ETW 이벤트를 방출합니다. 따라서 해당 서버 프로세스 내에서 데이터가 변조될 수 있습니다. 커널에 의해 직접 기록되며 간섭하려면 커널 수준 권한이 필요한 Microsoft-Windows-Kernel-Process 공급자의 ProcessStart 이벤트와 대조해 보세요.

두 번째로 고려해야 할 사항은 기록되는 정보의 신뢰성입니다. 이벤트 소스를 신뢰할 수 있지만, 기록 중인 이벤트와 무관한 클라이언트 제공 데이터를 맹목적으로 기록하는 것이라면 어떻게 해야 할까요?

이 글에서는 커널 ETW 이벤트에 초점을 맞추겠습니다. 이는 일반적으로 우회가 어렵고 클라이언트 스레드를 대신하여 수행되는 권한 있는 작업과 관련된 경우가 많기 때문에 보안과 가장 관련이 깊습니다.

Microsoft가 커널 패치 보호를 도입했을 때 보안 공급업체는 커널을 모니터링하는 데 상당한 제약을 받았습니다. Microsoft에서 제공하는 커널 확장 지점의 수가 제한되어 있기 때문에 멀웨어를 대신하여 수행되는 커널 동작의 사후 가시성을 확보하기 위해 비동기식 ETW 이벤트에 점점 더 의존할 수밖에 없었습니다.

이러한 종속성을 고려할 때 Windows 커널 원격 분석 소스에 대한 공개 문서는 안타깝게도 다소 드문 편입니다.

커널 ETW 이벤트

현재 고려해야 할 ETW 제공업체는 네 가지 유형이 있습니다.

첫째, '이벤트 공급자'에는 레거시 및 최신 변형이 있습니다:

• 레거시(MOF 기반)이벤트 공급자
• 최신(매니페스트 기반)이벤트 공급자

그리고 '추적 공급자'의 레거시 및 최신 변형이 있습니다:

• 레거시 Windows 소프트웨어 추적 전처리기(WPP) 추적 공급자
• 최신 트레이스 로깅 추적 공급자

'이벤트'와 '추적'의 구분은 대부분 의미론적인 것입니다. 이벤트 제공업체는 일반적으로 운영 체제에 미리 등록되어 있으며, 사용 가능한 원격 분석 메타데이터를 확인할 수 있습니다. 일반적으로 시스템 관리자가 문제 해결을 위해 사용하며 반 문서화되어 있는 경우가 많습니다. 하지만 무언가 정말, 정말 잘못되었을 때 (숨겨진) 추적 제공자가 있습니다. 이는 일반적으로 원래 소프트웨어 작성자가 고급 문제 해결을 위해서만 사용하며 문서화되어 있지 않습니다.

실제로는 각각 약간 다른 형식의 파일을 사용하여 이벤트를 설명하고 등록하기 때문에 이벤트가 기록되는 방식과 더 중요한 것은 잠재적인 이벤트를 열거하는 방식에 약간의 차이가 생깁니다.

최신 커널 이벤트 제공자

최신 커널 ETW 제공업체는 엄격하게 문서화되어 있지 않습니다. 그러나 등록된 이벤트 세부 정보는 추적 데이터 도우미 API를 통해 운영 체제에서 쿼리할 수 있습니다. Microsoft의 PerfView 도구는 이러한 API를 사용하여 공급자의 등록 매니페스트를 재구성하고, Pavel Yosifovich의 EtwExplorer는 이러한 매니페스트를 간단한 GUI로 래핑합니다. 이후 Windows 버전에서 등록된 매니페스트의 이러한 탭으로 구분된 값 파일을 사용할 수 있습니다. 이벤트당 한 줄은 그리핑에 매우 유용하지만, 다른 사람들은 이후 원시 XML 매니페스트를 게시했습니다.

그러나 이것이 가능한 모든 Windows ETW 이벤트가 아닙니다. 기본적으로 운영 체제에 등록된 것만 해당됩니다. 예를 들어, 많은 서버 역할에 대한 ETW 이벤트는 해당 기능을 사용 설정할 때까지 등록되지 않습니다.

레거시 커널 이벤트 제공자

레거시 커널 이벤트는 Microsoft에서 문서화합니다. 대부분.

레거시 공급자는 운영 체제 내에 WMI EventTrace 클래스로도 존재합니다. 공급자는 루트 클래스, 그룹은 하위 클래스, 이벤트는 손자 클래스에 해당합니다.

레거시 이벤트를 최신 이벤트와 동일한 방식으로 검색하기레거시 이벤트를 최신 이벤트와 동일한 방식으로 검색하기 위해 이러한 클래스를 파싱하고 원래 MOF를 (대부분) 재구성했습니다. 이 MOF 지원은 EtwExplorer에 추가되었으며, 레거시 이벤트의 탭으로 구분된 값 요약은 이러한 클래스가 파싱되고 원래 MOF가 (대부분) 재구성된 것입니다. 이 MOF 지원은 EtwExplorer와 게시된 레거시 이벤트의 탭으로 구분된 값 요약에 추가되었습니다.

완전히 재구성된 Windows 커널 추적 MOF는 여기 (또는 여기 표 형식)에서 확인할 수 있습니다.

등록된 레거시 이벤트( 340 ) 중 116 만 문서화되었습니다. 일반적으로 각 레거시 이벤트는 특정 플래그를 통해 활성화해야 하지만 이 역시 문서화되어 있지 않았습니다. 커널 오브젝트 관리자 추적 이벤트에 대한 단서가 문서에 있었습니다. 최신 SDK의 헤더에 정의되지 않은 상수 PERF_OB_HANDLE 를 언급했습니다. 다행히 제프 채펠과 Windows 10 1511 WDK가 구출해 주었습니다. 이 정보는 Microsoft의 KrabsETW 라이브러리에 PERFINFO_GROUPMASK 커널 추적 플래그에 대한 지원을 추가하는 데 사용되었습니다. 또한 객체 추적 문서가 잘못된 것으로 밝혀졌습니다. 이 비공개 상수는 문서화되지 않은 API 확장을 통해서만 사용할 수 있습니다. 다행히도 PerfView 같은 공개 Microsoft 프로젝트에서 문서화되지 않은 API를 사용하는 방법에 대한 예제를 제공하는 경우가 많습니다.

이제 깃허브에 매니페스트와 MOF가 모두 게시되었으므로 대부분의 커널 이벤트는 이 쿼리로 찾을 수 있습니다.

흥미롭게도 Microsoft는 보안 관련 이벤트의 이름을 난독화하기 때문에 task_ 같은 일반 이름 접두사가 붙은 이벤트를 검색하면 흥미로운 결과를 얻을 수 있습니다.

때로는 키워드가 이벤트의 목적을 암시하는 경우도 있습니다. 예를 들어 Microsoft-Windows-Kernel-General 에서 task_014 은 키워드로 활성화됩니다. KERNEL_GENERAL_SECURITY_ACCESSCHECK.

다행히도 매개변수는 거의 항상 이름이 잘 지정되어 있습니다. Microsoft-Windows-Kernel-Audit-API-Calls 의 task_05 는 TargetProcessId 및 DesiredAccess 라는 필드를 기록하므로 OpenProcess와 관련이 있다고 추측할 수 있습니다.

또 다른 유용한 쿼리는 명시적인 ProcessStartKey 필드가 있는 이벤트를 검색하는 것입니다. 로깅 프로세스에 대해 이 필드를 포함하도록 ETW 이벤트를 구성할 수 있으며, 다른 프로세스에 대해 이 정보를 포함하는 이벤트는 보안과 관련이 있는 경우가 많습니다.

특정 API를 염두에 두고 있다면 그 이름이나 매개 변수를 쿼리할 수 있습니다. 예를 들어, 네임드 파이프 이벤트를 원하는 경우 이 쿼리를 사용할 수 있습니다.

하지만 이 경우 Microsoft-Windows-SEC 은 엔드포인트용 Microsoft Defender(MDE)가 사용하는 기본 제공 Microsoft 보안 드라이버에 속합니다. 이 공급자는 공식적으로 MDE에서만 사용할 수 있지만, Sebastian Feldmann과 Philipp Schmied가 자동 로거를 사용하여 세션을 시작하고 해당 세션의 이벤트를 구독하는 방법을 시연했습니다. 그렇지 않으면 드라이버가 이벤트를 발생시키도록 구성되지 않으므로 현재로서는 MDE 사용자에게만 유용합니다.

그렇다면 추적 제공업체는 어떨까요?

최신 커널 추적 제공업체

TraceLogging 메타데이터는 로깅 바이너리 내에 불투명한 블롭으로 저장됩니다. 다행히도 이 형식은 매트 그레이버에 의해 반전되었습니다. Matt의 스크립트를 사용하여 ntoskrnl.exe 에 대한 모든 TraceLogging 메타데이터를 덤프할 수 있습니다. Windows 11 TraceLogging 메타데이터의 샘플 덤프는 여기에 있습니다.

안타깝게도 메타데이터 구조만으로는 제공업체와 이벤트 간의 상관관계를 파악할 수 없습니다. Microsoft.Windows.Kernel.Security 및 AttackSurfaceMonitor 과 같은 흥미로운 공급자 이름이 있지만, 메타데이터 덤프에서 어떤 이벤트가 이러한 공급자에 속하는지 아직 명확하지 않습니다.

레거시 커널 추적 제공업체

WPP 메타데이터는 심볼 파일(PDB) 내에 저장됩니다. Microsoft는 일부 드라이버의 공개 기호에 이 정보를 포함하지만 전부는 아닙니다. 그러나 커널 자체는 WPP 이벤트를 생성하지 않습니다. 대신, 레거시 Windows 커널 추적 이벤트 공급자에게 문서화되지 않은 플래그를 전달하여 일반적으로 Microsoft 커널 개발자에게만 제공되는 레거시 "추적" 이벤트를 활성화할 수 있습니다.

다음 단계

이제 네 가지 유형의 ETW 제공자 각각에 대한 커널 이벤트 메타데이터를 확보했지만, ETW 이벤트 목록은 시작에 불과합니다. 제공업체와 이벤트 키워드를 아는 것만으로는 기대하는 이벤트를 생성하는 데 충분하지 않을 수 있습니다. 때로는 추가 구성 레지스트리 키 또는 API 호출이 필요한 경우도 있습니다. 하지만 이벤트가 기록되는 정확한 조건을 이해해야 하는 경우가 더 많습니다.

원격 분석과 그 한계를 제대로 이해하려면 어디에 무엇이 기록되고 있는지 정확히 파악하는 것이 중요합니다. 그리고 디컴파일러를 쉽게 사용할 수 있게 된 덕분에 우리는 충분히 역으로 사용할 수 있는 옵션이 생겼습니다. IDA에서는 이를 "F5 누르기"라고 부릅니다. Ghidra는 오픈 소스 대안으로, 자바 스크립팅을 지원합니다.

커널 ETW의 경우 시스템 호출에서 연결할 수 있는 EtwWrite 호출에 특히 관심이 있습니다. 관련된 공개 심볼 정보를 포함하여 가능한 한 많은 호출 사이트 매개변수 정보가 필요합니다. 즉, 호출 그래프를 따라가면서 특정 매개변수에 대해 가능한 값을 해결해야 했습니다.

필요한 매개 변수는 RegHandle 와 EventDescriptor. 전자는 제공업체에 대한 불투명한 핸들이며, 후자는 이벤트 ID 및 관련 키워드와 같은 이벤트 관련 정보를 제공합니다. ETW 키워드는 일련의 이벤트를 활성화하는 데 사용되는 식별자입니다.

더 좋은 점은 이러한 이벤트 설명자가 일반적으로 공개 기호와 함께 전역 상수에 저장된다는 점입니다.

이벤트 메타데이터는 충분했지만 런타임에 할당된 불투명한 공급자 핸들을 공급자에 대한 메타데이터로 다시 해결해야 했습니다. 이를 위해 EtwRegister 호출도 필요했습니다.

커널 최신 이벤트 제공자의 일반적인 패턴은 상수 제공자 GUID와 런타임 핸들을 공용 심볼이 있는 전역에 저장하는 것이었습니다.

또 다른 패턴은 EtwRegister, EtwEwrite, EtwUnregister 로의 호출이 모두 동일한 함수에서 발생했습니다. 이 경우 로캘을 활용하여 이벤트의 공급자 GUID를 찾았습니다.

그러나 최신 추적 로깅 제공업체에는 각 제공업체의 목적에 대한 힌트를 제공하는 제공업체별 공용 심볼이 없습니다. 그러나 Matt Graeber는 TraceLogging 메타데이터 형식을 뒤집어 공급자 이름이 공급자 GUID에서 고정된 오프셋에 저장된다는 사실을 문서화했습니다. 정확한 제공자 이름이 있으면 최신 이벤트를 위해 복구한 공개 심볼보다 훨씬 더 좋습니다.

이로 인해 레거시 공급업체가 떠났습니다. 공개 심볼이나 메타데이터 블롭이 없는 것 같았습니다. 일부 상수는 최종 ETW 쓰기 호출을 래핑하는 EtwTraceKernelEvent 이라는 문서화되지 않은 함수에 전달됩니다.

이러한 상수는 Windows 10 1511 WDK 헤더(및 시스템 알림 헤더)에 있으므로 이러한 이벤트에 상수 이름으로 레이블을 지정할 수 있습니다.

이 스크립트는 최근 Ghidra 11용으로 업데이트되었으며, 트레이스 로깅 및 레거시 이벤트에 대한 지원도 개선되었습니다. 이제 GitHub( https://github.com/jdu2600/API-To-ETW)에서 찾을 수 있습니다.

Windows 11 커널의 샘플 출력은 여기에 있습니다.

이전에는 익명이었던 Microsoft-Windows-Kernel-Audit-API-Calls 이벤트는 이 스크립트를 통해 빠르게 마스크를 벗을 수 있습니다.

Microsoft-Windows-Kernel-Audit-API-Calls 이벤트에 대한 심볼 및 포함 함수

스크립트에서 복구한 호출 경로와 매개변수 정보를 통해 앞서의 SECURITY_ACCESSCHECK 이벤트가 SeAccessCheck 커널 API와 연결되어 있지만 SeLogAccessFailure 이라는 함수 내에서만 기록된다는 것도 확인할 수 있습니다. 실패 조건만 로깅하는 것은 ETW 이벤트에서 매우 흔하게 발생하는 현상입니다. 문제 해결 목적의 경우, 원래의 ETW 사용 사례는 일반적으로 가장 유용하며 대부분의 컴포넌트에서 구현이 이를 반영합니다. 안타깝게도 보안상으로는 그 반대의 경우가 많습니다. 성공적인 작업 로그는 일반적으로 악의적인 활동을 찾는 데 더 유용합니다. 따라서 이러한 레거시 이벤트 중 일부는 가치가 낮은 경우가 많습니다.

최신 보안 설계 관행은 보안 관련 활동에 대한 성공 및 실패 로그를 모두 감사하는 것이며, Microsoft는 이를 수행하는 새로운 보안 관련 ETW 이벤트를 계속 추가하고 있습니다. 예를 들어, Windows 11 24H2의 미리 보기 빌드에는 Microsoft-Windows-Threat-Intelligence 공급자에 몇 가지 흥미로운 새 ETW 이벤트가 포함되어 있습니다. 출시에 앞서 보안 공급업체를 위해 이러한 내용이 문서화되기를 바랍니다.

이 디컴파일러 스크립트를 흥미로운 Windows 드라이버 및 서비스 DLL에서 실행하는 것은 독자의 몫으로 남겨둡니다.