위에서 언급한 `OB_CALLBACK` 구조체는 문서화되지 않았으며, 다음과 같이 정의됩니다:```C
typedef struct OB_CALLBACK_t {
    USHORT Version;                           // usually 0x100
    USHORT OperationRegistrationCount;        // number of registered callbacks
    PVOID RegistrationContext;                // arbitrary data passed at registration time
    UNICODE_STRING AltitudeString;            // used to determine callbacks order
    struct OB_CALLBACK_ENTRY_t EntryItems[1]; // array of OperationRegistrationCount items
    WCHAR AltitudeBuffer[1];                  // is AltitudeString.MaximumLength bytes long, and pointed by AltitudeString.Buffer
} OB_CALLBACK;

`Flink` 및 `Blink` 포인터가 `CallbackList`의 `LIST_ENTRY`가 `LIST_ENTRY` 자체를 가리키도록 만들면 리스트가 사실상 비어 있게 됩니다. `_OBJECT_TYPE` 구조체는 커널 심볼에 공개되어 있으므로 이 기법은 하드코딩된 오프셋/구조체에 의존하지 않습니다. 그러나 몇 가지 단점이 있습니다.

첫째, EDR의 콜백만 비활성화할 수 있는 것이 아니라, "정상적인" 소프트웨어에 의해 등록되었을 수 있는 모든 객체 콜백에 영향을 미친다는 점입니다. 그럼에도 불구하고 Windows 10에서는 (현재 작성 시점 기준) 객체 콜백이 사전 설치된 어떤 구성 요소에서도 사용되지 않으므로, 이를 비활성화해도 시스템 안정성에 영향을 미치지 않아야 합니다(일시적으로만 비활성화하는 경우 더욱 그렇습니다).

두 번째 단점은 프로세스 또는 스레드 핸들 작업이 OS의 정상적인 기능에서 매우 빈번하다는 점(거의 지속적)입니다. 따라서 사용된 커널 쓰기 기본 연산이 "원자적으로" `QWORD` 쓰기를 수행할 수 없는 경우, `_OBJECT_TYPE.CallbackList.Flink` 포인터가 덮어쓰기 도중에 커널에 의해 접근될 가능성이 높습니다. 예를 들어, MSI 취약 드라이버 `RTCore64.sys`는 한 번에 `DWORD` 쓰기만 수행할 수 있으므로 포인터를 덮어쓰기 위해 두 개의 개별 IOCTL이 필요하며, 그 사이에 커널이 이를 사용할 확률이 높습니다(결과적으로 충돌). 반면, 취약한 DELL 드라이버 `DBUtil_2_3.sys`는 하나의 IOCTL에서 임의 크기의 쓰기를 수행할 수 있으므로 이 방법을 사용해도 충돌 위험이 없습니다.

#### 객체 콜백 완전 비활성화
우리가 발견한 마지막 기법 중 하나는 스레드 및 프로세스에 대한 객체 콜백 지원을 완전히 비활성화하는 것입니다. 프로세스 및 스레드 유형에 해당하는 `_OBJECT_TYPE` 구조체 내부에는 문서화된 `_OBJECT_TYPE_INITIALIZER` 구조체를 따르는 `TypeInfo` 필드가 있습니다. 후자에는 `ObjectTypeFlags` 비트 필드가 포함되어 있으며, 그 중 `SupportsObjectCallbacks` 플래그는 설명된 객체 유형(Process, Thread, Desktop, Token, File 등)이 객체 콜백 등록을 지원하는지 여부를 결정합니다. 앞서 언급했듯이, 현재 작성 시점의 Windows 설치에서는 Process, Thread 및 Desktop 객체 유형만 이러한 콜백을 지원합니다.

`SupportsObjectCallbacks` 비트는 `ObpCreateHandle` 또는 `ObDuplicateObject`가 `CallbackList`를 읽기 전(물론 콜백을 실행하기 전)에 검사하므로, 커널 런타임에 해당 비트를 플립하면 모든 객체 콜백 실행이 사실상 비활성화됩니다.

이 방법의 주요 단점은 *KPP*("*PatchGuard*")가 일부(전부?) `_OBJECT_TYPE` 구조체의 무결성을 모니터링하고, 매개변수 4가 `0x8`인 [`0x109 Bug Check`](https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x109---critical-structure-corruption)를 트리거한다는 것입니다. 이는 객체 유형 구조체가 변경되었음을 의미합니다.

그러나 비활성화/재활성화(및 그 사이의 "악의적인" 작업)를 충분히 빠르게 수행하면 *PatchGuard*를 "추월"할 수 있어야 합니다(주기적 검사가 잘못된 시점에 수행되는 불운이 없는 경우).

### 미니필터 콜백 연결 해제를 통한 EDR 우회
Windows 필터 관리자 시스템을 사용하면 EDR이 "미니필터" 드라이버를 로드하고 콜백을 등록하여 파일 열기, 읽기, 쓰기 등 I/O 작업에 대한 알림을 받을 수 있습니다.

필터 관리자에서 사용하는 다양한 내부 구조체에 대한 간단한 요약은 다음과 같습니다.
- 필터 관리자는 "프레임" (`_FLTP_FRAME`)을 루트 구조체로 설정합니다.
- 필터 관리자가 관리하는 각 "디스크"에 대해 "볼륨" 구조체 (`_FLT_VOLUME`)가 인스턴스화됩니다(파티션, 섀도 복사본, 또는 명명된 파이프나 원격 파일 시스템에 해당하는 특수 볼륨 포함).
- 등록된 각 미니필터 드라이버에는 지원되는 작업과 같은 다양한 속성을 설명하는 "필터" 구조체 (`_FLT_FILTER`)가 대응됩니다.
- 이러한 미니필터가 각 볼륨에 모두 연결되는 것은 아닙니다. 각각의 filter<->volume 연결을 표시하기 위해 "인스턴스" (`_FLT_INSTANCE`) 구조체가 생성됩니다.
- 미니필터는 특정 작업(파일 열기, 쓰기, 읽기 등) 전후에 실행될 콜백 함수를 등록합니다. 이러한 콜백은 `_CALLBACK_NODE` 구조체로 설명되며, 다양한 방법으로 접근할 수 있습니다.
  - 미니필터 인스턴스가 구현한 모든 `_CALLBACK_NODE`의 배열은 `_FLT_INSTANCE` 구조체에서 찾을 수 있습니다. 이 배열은 콜백이 처리하는 작업을 나타내는 상수인 IRP "주 함수" 코드(`IRP_MJ_CREATE`, `IRP_MJ_READ` 등)로 인덱싱됩니다.
  - 또한 특정 볼륨에 연결된 인스턴스가 구현한 모든 `_CALLBACK_NODE`는 IRP 주 함수 코드로 인덱싱된 `_FLT_VOLUME.Callbacks.OperationLists` 배열에 저장된 연결 리스트로 그룹화됩니다.

이러한 다양한 구조체는 `EDRSandblast`에 의해 탐색되어 EDR 관련 드라이버와 연결된 필터를 감지하고, 모니터링 기능을 포함하는 콜백 노드가 열거됩니다. 이들의 효과를 비활성화하기 위해 노드는 해당 리스트에서 연결 해제되어 필터 관리자에서 일시적으로 보이지 않게 됩니다.

이렇게 하면 지정된 기간 동안 EDR이 파일 작업을 완전히 인식하지 못할 수 있습니다. 기본적인 예로 lsass 메모리 덤프 파일을 디스크에 생성하는 경우 EDR의 분석을 전혀 트리거하지 않으므로 파일 자체에 기반한 탐지도 이루어지지 않습니다.

### ETW Microsoft-Windows-Threat-Intelligence 공급자 비활성화를 통한 EDR 우회

`ETW Microsoft-Windows-Threat-Intelligence` 공급자는 일반적으로 악의적으로 사용되는 일부 Windows API 사용에 대한 데이터를 기록합니다. 여기에는 `nt!NtReadVirtualMemory`(LSASS 메모리 덤프에 사용됨)에 의해 호출되는 `nt!MiReadWriteVirtualMemory` API가 포함되며, `nt!EtwTiLogReadWriteVm` 함수에 의해 모니터링됩니다.

EDR 제품은 각각 `SERVICE_LAUNCH_PROTECTED_ANTIMALWARE_LIGHT` 또는 `PS_PROTECTED_ANTIMALWARE_LIGHT`로 실행되는 서비스 또는 프로세스를 통해 `ETW TI` 공급자가 생성한 로그를 소비할 수 있으며, `Early Launch Anti Malware (ELAM)` 드라이버와 연결됩니다.

[`slaeryan`이 `CNO Development Labs` 블로그 게시물](https://public.cnotools.studio/bring-your-own-vulnerable-kernel-driver-byovkd/exploits/data-only-attack-neutralizing-etwti-provider)에서 공개한 바와 같이, `ETW TI` 공급자는 커널 메모리에서 해당 `ProviderEnableInfo` 속성을 `0x0`으로 패치하여 완전히 비활성화할 수 있습니다. 자세한 내용은 위의 훌륭한 블로그 게시물을 참조하십시오.

커널 콜백 제거와 유사하게, 필요한 `ntoskrnl.exe` 오프셋(`nt!EtwThreatIntProvRegHandleOffset`, `_ETW_REG_ENTRY`의 `GuidEntry`, `_ETW_GUID_ENTRY`의 `ProviderEnableInfo`)은 다양한 Windows 커널 버전에 대해 `NtoskrnlOffsets.csv` 파일에서 계산됩니다.

### 사용자 영역 후킹 우회를 통한 EDR 우회
#### 사용자 영역 후킹 작동 방식
프로세스에 의해 수행되는 작업을 쉽게 모니터링하기 위해 EDR 제품은 종종 *사용자 영역 후킹*이라는 메커니즘을 배포합니다. 먼저, EDR 제품은 각 프로세스 시작 시 알림을 받을 수 있는 커널 콜백(일반적으로 *이미지 로딩* 또는 *프로세스 생성* 콜백, 위 참조)을 등록합니다.

Windows가 프로세스를 로드하고 실제로 시작되기 전에 EDR은 모니터링 로직이 포함된 사용자 지정 DLL을 프로세스 주소 공간에 주입할 수 있습니다. 로드되는 동안 이 DLL은 EDR이 모니터링할 모든 함수의 시작 부분에 "*후크*"를 주입합니다. 런타임 시 감시 중인 프로세스에 의해 모니터링되는 함수가 호출되면 이러한 후크는 제어 흐름을 EDR DLL에 있는 일부 감독 코드로 리디렉션하여 호출의 인수와 반환 값을 검사할 수 있도록 합니다.

대부분의 경우 모니터링되는 함수는 `ntdll.dll`에 구현이 있는 시스템 호출(예: `NtReadVirtualMemory`, `NtOpenProcess` 등)입니다. `Nt*` 함수에 대한 호출을 가로채면 제품이 사용자 영역/커널 영역 경계에 최대한 가까이 접근할 수 있지만(사용자 영역에 머무르면서), 일부 상위 수준 DLL의 함수도 모니터링될 수 있습니다.

아래는 동일한 함수가 EDR 제품에 의해 후킹되기 전과 후의 예시입니다.```assembly
NtProtectVirtualMemory   proc near
	mov r10, rcx
	mov eax, 50h
	test byte ptr ds:7FFE0308h, 1
	jnz short loc_18009D1E5
	syscall
	retn
loc_18009D1E5:
	int 2Eh
	retn
NtProtectVirtualMemory   endp			

#### Hook 감지
사용자 공간 후크는 사용자 공간 메모리에 위치한다는 "약점"이 있습니다. 즉, 검사 대상 프로세스가 직접 관찰하고 수정할 수 있습니다. 프로세스 주소 공간에서 후크를 자동으로 감지하기 위한 주요 아이디어는 디스크의 원본 DLL과 메모리에 있는 (EDR에 의해 잠재적으로 변경된) 라이브러리 간의 차이점을 비교하는 것입니다. 이 비교를 수행하기 위해 EDRSandblast는 다음 단계를 따릅니다:
* 로드된 모든 DLL 목록은 `PEB` 내의 `InLoadOrderModuleList`를 통해 열거됩니다 (모니터링되거나 의심스러운 API 호출을 피하기 위해)
* 각 로드된 DLL에 대해, 디스크의 내용을 읽고 헤더를 구문 분석합니다. 메모리에 있는 해당 라이브러리도 구문 분석하여 섹션, 익스포트 등을 식별합니다.
* DLL의 재배치(relocations)를 구문 분석하고 적용하며, 해당 로드된 라이브러리의 기본 주소를 고려합니다. 이를 통해 메모리 내 라이브러리와 디스크에서 가져온 DLL의 내용이 (재배치가 적용된 섹션에서) 정확히 동일해지고, 따라서 비교가 신뢰할 수 있게 됩니다.
* 익스포트된 함수를 열거하고 "메모리 내" 버전과 "디스크 상" 버전의 첫 번째 바이트를 비교합니다. 차이가 있으면 DLL이 로드된 후에 변경이 발생했음을 나타내며, 이는 거의 확실히 EDR 후크입니다.

참고: 이 과정은 쓰기 불가능한 섹션의 아무 곳에서나 차이점을 찾도록 일반화할 수 있으며, 익스포트 함수의 시작 부분에만 국한되지 않습니다. 예를 들어 EDR 제품이 함수 중간에 후크를 적용하기 시작하는 경우에도 가능합니다 :) 따라서 도구에서 사용되지는 않지만, `findDiffsInNonWritableSections`에 구현되어 있습니다.


이러한 후크가 수행하는 모니터링을 우회하기 위해 여러 가지 기술이 가능하며, 각각 장단점이 있습니다.

#### 후크 우회: 언후킹(unhooking) 사용
후크 기반 모니터링을 우회하는 가장 직관적인 방법은 후크를 제거하는 것입니다. 후크는 프로세스 자체가 접근 가능한 메모리에 존재하므로, 후크를 제거하기 위해 프로세스는 다음을 수행할 수 있습니다:
* 후크가 위치한 페이지의 권한 변경 (RX -> RWX 또는 RW)
* 디스크 DLL 내용을 통해 알려진 원본 바이트 쓰기
* 권한을 다시 RX로 변경

이 접근 방식은 매우 간단하며, 감지된 모든 후크를 한 번에 제거하는 데 사용할 수 있습니다. 공격 도구가 시작 시 이를 수행하면, 나머지 코드는 후킹 메커니즘을 전혀 인식하지 못하고 모니터링 없이 정상적으로 작동할 수 있습니다.

그러나 두 가지 주요 단점이 있습니다. EDR은 아마도 `NtProtectVirtualMemory` 사용을 모니터링할 것이므로, 이를 사용하여 후크가 설치된 페이지의 권한을 변경하는 것은 (적어도 개념상) 좋지 않은 생각입니다. 또한, EDR이 스레드를 실행하여 주기적으로 후크의 무결성을 확인하는 경우, 이 또한 탐지를 유발할 수 있습니다.

구현 세부 사항은 `unhook_method`가 `UNHOOK_WITH_NTPROTECTVIRTUALMEMORY`일 때 `unhook()` 함수의 코드 경로를 확인하세요.

**중요 참고: 단순함을 위해 이 기술은 EDRSandblast에서 다른 우회 기술을 *시연*하는 기본 기술로 구현되었습니다; 각 기술은 모니터링되지 않는 버전의 `NtProtectVirtualMemory`를 획득하는 방법을 보여주지만, 이후에는 동일한 작업(특정 후크 언후킹)을 수행합니다.**

#### 사용자 정의 트램펄린을 사용한 후크 우회
특정 후크를 우회하려면 단순히 "뛰어넘어" 함수의 나머지 부분을 그대로 실행하는 것이 가능합니다. 먼저, EDR이 후크를 설치하기 위해 덮어쓴 모니터링 대상 함수의 원본 바이트를 DLL 파일에서 복구해야 합니다. 이전 코드 예제에서는 이는 다음 명령어에 해당하는 바이트가 될 것입니다:```assembly
mov r10, rcx
mov eax, 50h

마지막으로, 이러한 opcode들을 연결하여 (새로) 실행 가능한 메모리에 저장하고 포인터를 유지합니다. 이 객체는 "*trampoline*"이라고 불리며, 원래의 `NtProtectVirtualMemory` 함수와 완전히 동일한 함수 포인터로 사용될 수 있습니다.

이 기술의 주요 이점은 아래의 모든 기술과 마찬가지로, 훅이 절대 지워지지 않는다는 점입니다. 따라서 EDR이 수행하는 모든 무결성 검사를 통과해야 합니다. 그러나 쓰기 가능한 메모리를 할당한 후 실행 가능한 메모리로 만들어야 하며, 이는 일반적인 셸코드 할당 방식으로 EDR의 감시를 받게 됩니다.

구현 세부 사항은 `unhook()` 함수의 코드 경로에서 `unhook_method`가 `UNHOOK_WITH_INHOUSE_NTPROTECTVIRTUALMEMORY_TRAMPOLINE`인 경우를 확인하세요. 이 기술은 우리 구현에서만 시연되며, 결국 아래의 모든 기술과 마찬가지로 메모리에서 훅을 **제거**하는 데 사용됩니다.

#### EDR의 자체 트램펄린을 사용한 훅 우회
EDR 제품이 훅을 작동시키려면 제거한 opcode를 메모리 어딘가에 저장해야 합니다. 최악(*또는 "더 나은", 공격자 관점에서*), 원래 명령어를 효과적으로 사용하기 위해 EDR은 호출을 가로챈 후 원래 함수를 실행할 수 있도록 자체적으로 *trampoline*을 할당했을 가능성이 높습니다.

이 트램펄린을 검색하여 훅된 함수의 대체로 사용할 수 있으며, 실행 가능한 메모리를 할당하거나 `VirtualQuery` 외의 API를 호출할 필요가 없습니다. `VirtualQuery`는 무해한 함수이므로 모니터링되지 않을 가능성이 높습니다.

메모리에서 트램펄린을 찾기 위해 `VirtualQuery`를 사용하여 전체 주소 공간을 탐색하며, 커밋되고 실행 가능한 메모리를 찾습니다. 이러한 각 메모리 영역에 대해, 덮어쓰여진 명령어 다음 주소(이전 예제에서는 `NtProtectVirtualMemory+8`)를 대상으로 하는 점프 명령어를 찾기 위해 스캔합니다. 그런 다음 이 트램펄린을 사용하여 훅을 트리거하지 않고 훅된 함수를 호출할 수 있습니다.

이 기술은 테스트된 EDR에서 거의 모든 트램펄린을 복구할 수 있을 정도로 놀랍게 잘 작동합니다. 구현 세부 사항은 `unhook()` 함수의 코드 경로에서 `unhook_method`가 `UNHOOK_WITH_EDR_NTPROTECTVIRTUALMEMORY_TRAMPOLINE`인 경우를 확인하세요.

#### 중복 DLL을 사용한 훅 우회
`NtProtectVirtualMemory` 함수의 모니터링되지 않는 버전에 접근하는 또 다른 간단한 방법은 프로세스 주소 공간에 `ntdll.dll` 라이브러리의 중복 버전을 로드하는 것입니다. 이름이 다르면 두 개의 동일한 DLL을 동일한 프로세스에 로드할 수 있으므로, 합법적인 `ntdll.dll` 파일을 다른 위치에 복사하고 `LoadLibrary`를 사용하여 로드하거나 로드 프로세스를 재구현한 다음, 예를 들어 `GetProcAddress`를 사용하여 함수에 접근할 수 있습니다.

이 기술은 이해하고 구현하기가 매우 간단하며, 성공 가능성이 높습니다. 대부분의 EDR 제품은 프로세스가 실행 중일 때 새로 로드된 DLL에 훅을 다시 설치하지 않기 때문입니다. 그러나 주요 단점은 Microsoft 서명된 바이너리를 다른 이름으로 복사하는 것이 EDR 제품 자체에서 종종 의심스러운 행동으로 간주된다는 점입니다.

그러나 이 기술은 `EDRSandblast`에 구현되어 있습니다. 구현 세부 사항은 `unhook()` 함수의 코드 경로에서 `unhook_method`가 `UNHOOK_WITH_DUPLICATE_NTPROTECTVIRTUALMEMORY`인 경우를 확인하세요.

#### 직접 시스템 콜을 사용한 훅 우회
시스템 호출 관련 함수를 사용하기 위해, 프로그램은 시스템 콜을 (어셈블리로) 재구현하여 EDR에 의해 모니터링될 수 있는 `ntdll.dll`의 코드를 실제로 건드리지 않고 해당 OS 기능을 호출할 수 있습니다. 이는 `ntdll.dll` 내 시스템 콜 함수에 대해 수행된 모든 사용자 후킹을 완전히 우회합니다.

그러나 여기에는 몇 가지 단점이 있습니다. 첫째, 프로그램이 필요로 하는 함수들의 시스템 콜 번호 목록을 알아야 한다는 점인데, 이는 Windows의 각 버전마다 다릅니다. 그러나 이는 Windows NT의 모든 과거 버전에서 작동하는 것으로 알려진 여러 휴리스틱을 구현하고(예: `ntdll`의 `Zw*` 내보내기 정렬, 관련 `ntdll` 함수에서 `mov rax, #syscall_number` 명령어 검색 등), 모두 동일한 결과를 반환하는지 확인함으로써 완화됩니다(자세한 내용은 `Syscalls.c` 참조).

또한 기술적으로 시스템 콜이 아닌 함수(예: `LoadLibraryX`/`LdrLoadDLL`)도 모니터링될 수 있으며, 시스템 콜로 간단히 재구현할 수 없습니다.

직접 시스템 콜 기술은 EDRSandblast에 구현되어 있습니다. 앞서 언급했듯이, 이는 `NtProtectVirtualMemory`를 안전하게 실행하고 감지된 모든 훅을 제거하는 데만 사용됩니다.

구현 세부 사항은 `unhook()` 함수의 코드 경로에서 `unhook_method`가 `UNHOOK_WITH_DIRECT_SYSCALL`인 경우를 확인하세요.

### 취약한 드라이버 악용
앞서 언급했듯이, 커널 메모리 읽기나 쓰기가 필요한 모든 작업은 이 프리미티브를 제공하는 취약한 드라이버에 의존합니다. EDRSandblast에서는 읽기/쓰기 프리미티브를 제공하는 새 드라이버에 대한 지원을 "쉽게" 추가할 수 있으며, 세 가지 함수만 구현하면 됩니다:
* `ReadMemoryPrimitive_DRIVERNAME(SIZE_T Size, DWORD64 Address, PVOID Buffer)` 함수: `Size` 바이트를 커널 주소 `Address`에서 사용자 공간 버퍼 `Buffer`로 복사합니다.
* `WriteMemoryPrimitive_DRIVERNAME(SIZE_T Size, DWORD64 Address, PVOID Buffer)` 함수: `Size` 바이트를 사용자 공간 버퍼 `Buffer`에서 커널 주소 `Address`로 복사합니다.
* `CloseDriverHandle_DRIVERNAME()`: 드라이버에 대한 모든 핸들이 닫혔는지 확인합니다(드라이버 제거 작업 전에 필요하며, 현재 드라이버에 관계없이 수행됨).

예를 들어, 현재 EDRSandblast는 두 개의 드라이버를 지원합니다: `RTCore64.sys` (SHA256: `01AA278B07B58DC46C84BD0B1B5C8E9EE4E62EA0BF7A695862444AF32E87F1FD`) 및 `DBUtils_2_3.sys` (SHA256: `0296e2ce999e67c76352613a718e11516fe1b0efc3ffdb8918fc999dd76a73a5`). 사용 중인 취약한 드라이버를 변경하거나 새로운 드라이버를 구현해야 하는 경우 `KernelMemoryPrimitives.h`의 다음 코드를 업데이트해야 합니다.```C
#define RTCore 0
#define DBUtil 1
// Select the driver to use with the following #define
#define VULN_DRIVER RTCore

#if VULN_DRIVER == RTCore
#define DEFAULT_DRIVER_FILE TEXT("RTCore64.sys")
#define CloseDriverHandle CloseDriverHandle_RTCore
#define ReadMemoryPrimitive ReadMemoryPrimitive_RTCore
#define WriteMemoryPrimitive WriteMemoryPrimitive_RTCore
#elif VULN_DRIVER == DBUtil
#define DEFAULT_DRIVER_FILE TEXT("DBUtil_2_3.sys")
#define CloseDriverHandle CloseDriverHandle_DBUtil
#define ReadMemoryPrimitive ReadMemoryPrimitive_DBUtil
#define WriteMemoryPrimitive WriteMemoryPrimitive_DBUtil
#endif

### 옵션```
-h | --help             Show this help message and exit.
-v | --verbose          Enable a more verbose output.

Actions mode:

        audit                     Display the user-land hooks and / or Kernel callbacks without taking actions.
        dump                      Dump the process specified by --process-name (LSASS process by default), as '<process_name>' in the current directory or at the
                                  specified file using -o | --output <DUMP_FILE>.
        cmd                       Open a cmd.exe prompt.
        credguard                 Patch the LSASS process' memory to enable Wdigest cleartext passwords caching even if
                                  Credential Guard is enabled on the host. No kernel-land actions required.
        firewall                  Add Windows firewall rules to block network access for the EDR processes / services.
        load_unsigned_driver      Load the specified unsigned driver, bypassing Driver Signature Enforcement (DSE).
                                  WARNING: currently an experimental feature, only works if KDP is not present and enabled.

--usermode              Perform user-land operations (DLL unhooking).
--kernelmode            Perform kernel-land operations (Kernel callbacks removal and ETW TI disabling).


Hooking-related options:

--add-dll <dll name or path>            Loads arbitrary libraries into the process' address space, before starting
                                        anything.This can be useful to audit userland hooking for DLL that are not
                                        loaded by default by this program. Use this option multiple times to load
                                        multiple DLLs all at once.
                                        Example of interesting DLLs to look at: user32.dll, ole32.dll, crypt32.dll,
                                        samcli.dll, winhttp.dll, urlmon.dll, secur32.dll, shell32.dll...

--unhook-method <N>                     Choose the userland un-hooking technique, from the following:

        0                               Do not perform any unhooking (used for direct syscalls operations).
        1 (Default)                     Uses the (probably monitored) NtProtectVirtualMemory function in ntdll to remove all
                                        present userland hooks.
        2                               Constructs a 'unhooked' (i.e. unmonitored) version of NtProtectVirtualMemory, by                                        allocating an executable trampoline jumping over the hook, and remove all present
                                        userland hooks.
        3                               Searches for an existing trampoline allocated by the EDR itself, to get an 'unhooked'
                                        (i.e. unmonitored) version of NtProtectVirtualMemory, and remove all present userland
                                        hooks.
        4                               Loads an additional version of ntdll library into memory, and use the (hopefully                                        unmonitored) version of NtProtectVirtualMemory present in this library to remove all
                                        present userland hooks.
        5                               Allocates a shellcode that uses a direct syscall to call NtProtectVirtualMemory,                                        and uses it to remove all detected hooks

--direct-syscalls       Use direct syscalls to dump the selected process memory without unhooking unserland hooks.


BYOVD options:

--dont-unload-driver                    Keep the vulnerable driver installed on the host
                                        Default to automatically unsinstall the driver.
--no-restore                            Do not restore the EDR drivers' Kernel Callbacks that were removed.
                                        Default to restore the callbacks.
--vuln-driver <gdrv.sys>                Path to the vulnerable driver file.
                                        Default to 'gdrv.sys' in the current directory.
--vuln-service <SERVICE_NAME>           Name of the vulnerable service to intall / start.


Driver sideloading options:

--unsigned-driver <evil.sys>            Path to the unsigned driver file.
                                        Default to 'evil.sys' in the current directory.
--unsigned-service <SERVICE_NAME>       Name of the unsigned driver's service to intall / start.
--no-kdp                                Switch to g_CiOptions patching method for disabling DSE (default is callback swapping).


Offset-related options:

--nt-offsets <NtoskrnlOffsets.csv>      Path to the CSV file containing the required ntoskrnl.exe's offsets.
                                        Default to 'NtoskrnlOffsets.csv' in the current directory.
--fltmgr-offsets <FltmgrOffsets.csv>    Path to the CSV file containing the required fltmgr.sys's offsets
                                        Default to 'FltmgrOffsets.csv' in the current directory.
--wdigest-offsets <WdigestOffsets.csv>  Path to the CSV file containing the required wdigest.dll's offsets
                                        (only for the 'credguard' mode).
                                        Default to 'WdigestOffsets.csv' in the current directory.
--ci-offsets <CiOffsets.csv>            Path to the CSV file containing the required ci.dll's offsets
                                        (only for the 'load_unsigned_driver' mode).
                                        Default to 'WdigestOffsets.csv' in the current directory.
-i | --internet                         Enables automatic symbols download from Microsoft Symbol Server
                                        If a corresponding *Offsets.csv file exists, appends the downloaded offsets to the file for later use
                                        OpSec warning: downloads and drops on disk a PDB file for the corresponding image

Dump options:

-o | --dump-output <DUMP_FILE>          Output path to the dump file that will be generated by the 'dump' mode.
                                        Default to 'process_name' in the current directory.
--process-name <NAME>                   File name of the process to dump (defaults to 'lsass.exe')

## 탐지
방어자(EDR 벤더, Microsoft, EDR 텔레메트리를 분석하는 SOC 분석가 등)의 관점에서 이러한 유형의 기술을 탐지하거나 방지하는 데 사용할 수 있는 여러 지표가 있습니다.

### 드라이버 허용 목록
커널 모드 메모리에서 도구가 수행하는 모든 작업이 취약한 드라이버를 사용하여 임의의 내용을 읽고 쓰는 데 의존하므로, 드라이버 로딩 이벤트는 EDR 제품(또는 SOC 분석가)에 의해 철저히 조사되어야 하며, 일반적이지 않은 드라이버 로딩에 대해 경고를 발생시키거나 알려진 취약한 드라이버를 차단해야 합니다. 후자의 접근 방식은 [Microsoft 자체에서 권장](https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules)합니다. HVCI(*Hypervisor-protected code integrity*)가 활성화된 모든 Windows 장치에는 드라이버 차단 목록이 포함되어 있으며, 이는 점차 Windows의 기본 동작이 될 것입니다(Windows 11에서는 이미 기본입니다).

### 커널 메모리 무결성 검사
공격자가 알려지지 않은 취약한 드라이버를 사용하여 메모리에서 동일한 작업을 수행할 수 있기 때문에, EDR 드라이버는 주기적으로 커널 콜백이 여전히 등록되어 있는지 확인할 수 있습니다. 이 도구와 같이 커널 메모리를 직접 검사하거나, 단순히 이벤트(프로세스 생성, 스레드 생성, 이미지 로딩 등)를 트리거하여 콜백 함수가 실행 커널에 의해 실제로 호출되는지 확인할 수 있습니다.

참고로, 이러한 유형의 데이터 구조는 VBS(Virtual Based Security)에 의존하는 최근의 [KDP(Kernel Data Protection)](https://www.microsoft.com/security/blog/2020/07/08/introducing-kernel-data-protection-a-new-platform-security-technology-for-preventing-data-corruption/) 메커니즘을 통해 보호될 수 있으며, 올바른 API를 호출하지 않고는 커널 콜백 배열을 쓰기 불가능하게 만듭니다.

동일한 논리는 이 도구에서 ETW Threat Intelligence 이벤트 생성을 비활성화하기 위해 남용된 `ProviderEnableInfo`와 같은 민감한 ETW 변수에도 적용될 수 있습니다.

### 사용자 모드 탐지
프로세스가 사용자 영역 후킹을 적극적으로 회피하려고 시도하고 있다는 첫 번째 지표는 로드된 모듈에 해당하는 각 DLL에 대한 파일 액세스입니다. 정상적인 실행 중에 사용자 영역 프로세스는 `LoadLibrary` 호출 외에는 DLL 파일을 거의 읽을 필요가 없으며, 특히 `ntdll.dll`의 경우 더욱 그렇습니다.

API 후킹이 우회되는 것을 방지하기 위해 EDR 제품은 모니터링되는 각 프로세스 내에서 메모리의 후크가 변경되지 않았는지 주기적으로 확인할 수 있습니다.

마지막으로, 후크 제거를 수반하지 않는 후킹 우회(트램펄린 남용, 직접 시스템 콜 사용 등)를 탐지하기 위해 EDR 제품은 남용된 시스템 콜과 관련된 커널 콜백(예: `NtCreateProcess` 시스템 콜의 `PsCreateProcessNotifyRoutine`, `NtOpenProcess` 시스템 콜의 `ObRegisterCallbacks` 등)을 사용하여 사용자 모드 호출 스택 분석을 수행할 수 있으며, 시스템 콜이 정상 경로(`kernel32.dll` -> `ntdll.dll` -> 시스템 콜)에서 트리거되었는지 비정상 경로(예: `program.exe` -> 직접 시스템 콜)에서 트리거되었는지 확인할 수 있습니다.

## 감사의 말

- 커널 콜백 열거 및 제거:
  https://github.com/br-sn/CheekyBlinder

- 취약한 `Micro-Star MSI Afterburner` 드라이버를 통한 커널 메모리 읽기/쓰기 기본 요소:
  https://github.com/Barakat/CVE-2019-16098/

- ETW Threat Intelligence 공급자 비활성화:
  https://public.cnotools.studio/bring-your-own-vulnerable-kernel-driver-byovkd/exploits/data-only-attack-neutralizing-etwti-provider

- 드라이버 설치/제거: https://github.com/gentilkiwi/mimikatz

- EDR 드라이버 이름 초기 목록:
  https://github.com/SadProcessor/SomeStuff/blob/master/Invoke-EDRCheck.ps1

- `LSASS` 메모리 패치를 통해 `Wdigest`를 재활성화하여 Credential Guard 우회:
  https://teamhydra.blog/2020/08/25/bypassing-credential-guard/

## 저자

[Thomas DIOT (Qazeer)](https://github.com/Qazeer/)
[Maxime MEIGNAN (themaks)](https://github.com/themaks)

## 기여자 감사
- [v1k1ngfr](https://github.com/v1k1ngfr): Driver Signature Enforcement 우회(`g_CiOptions` 패칭) 및 GDRV.sys 드라이버 지원
- [Windy Bug](https://github.com/0mWindyBug): KDP 호환 Driver Signature Enforcement 우회(*콜백 교환* 방식) 및 미니필터 우회 기능에 대한 주요 기여

## 라이선스

CC BY 4.0 라이선스 - https://creativecommons.org/licenses/by/4.0/