La estructura `OB_CALLBACK` mencionada anteriormente también está sin documentar, y se define de la siguiente manera:```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;

Haciendo que los punteros `Flink` y `Blink` de la `LIST_ENTRY` del `CallbackList` apunten a
la `LIST_ENTRY` misma, se vacía efectivamente la lista. Dado que la estructura `_OBJECT_TYPE`
está publicada en los símbolos del kernel, la técnica no depende de desplazamientos/estructuras codificados.
Sin embargo, tiene algunos inconvenientes.

El primero es no poder deshabilitar solo las devoluciones de llamada del EDR; de hecho, la técnica afecta
a todas las devoluciones de llamada de objetos que pudieran haber sido registradas por software "legítimo". No obstante,
cabe señalar que las devoluciones de llamada de objetos no son utilizadas por ningún componente preinstalado
en Windows 10 (en el momento de escribir esto), por lo que deshabilitarlas no debería afectar la estabilidad
de la máquina (más aún si la desactivación es solo temporal).

El segundo inconveniente es que las operaciones de identificadores de procesos o hilos son realmente frecuentes (casi
continuas) en el funcionamiento normal del SO. Por lo tanto, si la primitiva de escritura en kernel utilizada
no puede realizar una escritura de `QWORD` de forma "atómica", existe una alta probabilidad de que el puntero
`_OBJECT_TYPE.CallbackList.Flink` sea accedido por el kernel en medio
de su sobrescritura. Por ejemplo, el controlador vulnerable MSI `RTCore64.sys` solo puede realizar
una escritura de `DWORD` a la vez, por lo que se necesitarán 2 IOCTL distintos para sobrescribir el puntero, entre
los cuales el kernel tiene una alta probabilidad de usarlo (lo que resulta en un bloqueo). Por otro lado,
el controlador vulnerable DELL `DBUtil_2_3.sys` puede realizar escrituras de tamaños arbitrarios en un solo
IOCTL, por lo que usar este método con él no corre el riesgo de causar un bloqueo.

#### Deshabilitar por completo las devoluciones de llamada de objetos
Una última técnica que encontramos fue deshabilitar por completo el soporte de devoluciones de llamada de objetos para hilos
y procesos. Dentro de la estructura `_OBJECT_TYPE` correspondiente a los tipos de proceso y
hilo reside un campo `TypeInfo`, que sigue la estructura documentada `_OBJECT_TYPE_INITIALIZER`.
Este último contiene un campo de bits `ObjectTypeFlags`, cuya bandera `SupportsObjectCallbacks`
determina si el tipo de objeto descrito (Proceso, Hilo, Escritorio, Token, Archivo, etc.)
admite o no el registro de devoluciones de llamada de objetos. Como se indicó anteriormente, solo los tipos de objeto Proceso, Hilo y
Escritorio admiten estas devoluciones de llamada en una instalación de Windows en el momento de escribir esto.

Dado que el bit `SupportsObjectCallbacks` es verificado por `ObpCreateHandle` o
`ObDuplicateObject` antes incluso de leer el `CallbackList` (y antes de ejecutar
las devoluciones de llamada, por supuesto), invertir el bit en tiempo de ejecución del kernel deshabilita efectivamente la ejecución
de todas las devoluciones de llamada de objetos.

El principal inconveniente del método es simplemente que *KPP* ("*PatchGuard*") monitorea la integridad
de algunas (¿todas?) las estructuras `_OBJECT_TYPE` y desencadena una [`comprobación de error 0x109`](https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x109---critical-structure-corruption)
con el parámetro 4 igual a `0x8`, lo que significa que se ha alterado una estructura de tipo de objeto.

Sin embargo, realizar la desactivación / reactivación (y la acción "maliciosa" intermedia) lo suficientemente
rápido debería ser suficiente para "adelantarse" a *PatchGuard* (a menos que tengas mala suerte y se realice una verificación
periódica justo en el momento equivocado).

### Bypass de EDR mediante desvinculación de devoluciones de llamada de minifiltros
El sistema Filter Manager de Windows permite que un EDR cargue un controlador "minifiltro" y
registre devoluciones de llamada para ser notificado de operaciones de E/S, como apertura de archivos,
lectura, escritura, etc.

Aquí hay un breve resumen de diferentes estructuras internas utilizadas por el filter manager:
- El Filter Manager establece un "marco" (`_FLTP_FRAME`) como su estructura raíz;
- Se crea una instancia de una estructura de "volumen" (`_FLT_VOLUME`) para cada "disco" gestionado por el
Filter Manager (pueden ser particiones, copias sombra, o especiales correspondientes a
named pipes o sistemas de archivos remotos);
- A cada controlador minifiltro registrado le corresponde una estructura de "filtro" (`_FLT_FILTER`),
que describe varias propiedades como sus operaciones compatibles;
- Estos minifiltros no están todos adjuntos a cada volumen; se crea una estructura de "instancia" (`_FLT_INSTANCE`)
para marcar cada una de las asociaciones filtro<->volumen;
- Los minifiltros registran funciones de devolución de llamada que se ejecutarán antes y/o después de
operaciones específicas (abrir archivo, escribir, leer, etc.). Estas devoluciones de llamada se describen en
estructuras `_CALLBACK_NODE`, y se puede acceder a ellas de diferentes maneras:
  - Una matriz de todos los `_CALLBACK_NODE` implementados por una instancia de un minifiltro
    se puede encontrar en la estructura `_FLT_INSTANCE`; la matriz está indexada por el código de "función mayor"
    del IRP, una constante que representa las operaciones manejadas por las
    devoluciones de llamada (`IRP_MJ_CREATE`, `IRP_MJ_READ`, etc.).
  - Además, todos los `_CALLBACK_NODE` implementados por instancias vinculadas a un volumen específico
    se agrupan en listas enlazadas, almacenadas en la matriz `_FLT_VOLUME.Callbacks.OperationLists`
    indexada por códigos de función mayor del IRP.

`EDRSandblast` recorre estas diferentes estructuras para detectar filtros que están
asociados con controladores relacionados con EDR, y se enumeran los nodos de devolución de llamada que contienen funciones
de monitoreo. Para deshabilitar su efecto, los nodos se desvinculan de sus
listas, haciéndolos temporalmente invisibles para el filter manager.

De esta manera, durante un período específico, el EDR puede ser completamente inconsciente de cualquier operación
de archivos. Un ejemplo básico sería la creación de un archivo de volcado de memoria de lsass en el disco,
que no desencadenaría ningún análisis del EDR y, por lo tanto, ninguna detección basada en el
archivo en sí.

### Bypass de EDR mediante desactivación del proveedor ETW Microsoft-Windows-Threat-Intelligence

El proveedor `ETW Microsoft-Windows-Threat-Intelligence` registra datos sobre los
usos de algunas API de Windows comúnmente utilizadas con fines maliciosos. Esto incluye la
API `nt!MiReadWriteVirtualMemory`, llamada por `nt!NtReadVirtualMemory` (que se
utiliza para volcar la memoria de `LSASS`) y monitoreada por la función `nt!EtwTiLogReadWriteVm`.

Los productos EDR pueden consumir los registros producidos por el proveedor `ETW TI` a través
de servicios o procesos que se ejecutan como, respectivamente,
`SERVICE_LAUNCH_PROTECTED_ANTIMALWARE_LIGHT` o
`PS_PROTECTED_ANTIMALWARE_LIGHT`, y asociados con un controlador `Early Launch Anti
Malware (ELAM)`.

Según lo publicado por
[`slaeryan` en una publicación de blog de `CNO Development Labs`](https://public.cnotools.studio/bring-your-own-vulnerable-kernel-driver-byovkd/exploits/data-only-attack-neutralizing-etwti-provider),
el proveedor `ETW TI` se puede deshabilitar por completo parcheando, en la memoria del kernel,
su atributo `ProviderEnableInfo` a `0x0`. Consulte la excelente publicación de blog mencionada anteriormente
para obtener más información sobre la técnica.

De manera similar a la eliminación de devoluciones de llamada del kernel, los desplazamientos necesarios de `ntoskrnl.exe`
(`nt!EtwThreatIntProvRegHandleOffset`, `GuidEntry` de `_ETW_REG_ENTRY`, y
`ProviderEnableInfo` de `_ETW_GUID_ENTRY`) se calculan en el
archivo `NtoskrnlOffsets.csv` para varias versiones del kernel de Windows.

### Bypass de EDR mediante bypass de hooking en el espacio de usuario
#### Cómo funciona el hooking en el espacio de usuario
Para monitorear fácilmente las acciones realizadas por los procesos, los productos EDR a menudo
implementan un mecanismo llamado *hooking en el espacio de usuario*. Primero, los productos EDR registran una devolución de llamada
del kernel (generalmente devoluciones de llamada de *carga de imagen* o *creación de proceso*, ver arriba) que les permite
ser notificados al inicio de cada proceso.

Cuando Windows carga un proceso, y antes de que realmente comience, el EDR puede
inyectar un DLL personalizado en el espacio de direcciones del proceso, que contiene su lógica
de monitoreo. Durante la carga, este DLL inyecta "*hooks*" al inicio de cada función que va a ser
monitoreada por el EDR. En tiempo de ejecución, cuando el proceso bajo vigilancia llama a las funciones monitoreadas,
estos hooks redirigen el flujo de control a algún código de supervisión
presente en el DLL del EDR, lo que le permite inspeccionar argumentos y valores de retorno de estas
llamadas.

La mayoría de las veces, las funciones monitoreadas son llamadas al sistema (como `NtReadVirtualMemory`,
`NtOpenProcess`, etc.), cuyas implementaciones residen en `ntdll.dll`. Interceptar llamadas a
funciones `Nt*` permite que los productos estén lo más cerca posible del límite entre el espacio de usuario y el
espacio del kernel (permaneciendo en el espacio de usuario), pero también se pueden monitorear funciones de algunos DLL de nivel superior.

A continuación se muestran ejemplos de la misma función, antes y después de ser enganchada por el producto 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			

#### Detección de hooks
Los hooks de espacio de usuario tienen la "debilidad" de estar ubicados en la memoria de espacio de usuario, lo que significa que son directamente observables y modificables por el proceso bajo escrutinio. Para detectar automáticamente los hooks en el espacio de direcciones del proceso, la idea principal es comparar las diferencias entre el DLL original en disco y la biblioteca residente en memoria, que ha sido potencialmente alterada por un EDR. Para realizar esta comparación, EDRSandblast sigue los siguientes pasos:
* La lista de todos los DLL cargados se enumera gracias a la `InLoadOrderModuleList` ubicada en el `PEB` (para evitar llamar a cualquier API que pudiera estar monitoreada y ser sospechosa)
* Para cada DLL cargado, su contenido en disco se lee y sus cabeceras se analizan. La biblioteca correspondiente, residente en memoria, también se analiza para identificar secciones, exportaciones, etc.
* Las reubicaciones del DLL se analizan y aplican, teniendo en cuenta la dirección base de la biblioteca cargada correspondiente. Esto permite que el contenido tanto de la biblioteca en memoria como del DLL del disco tengan exactamente el mismo contenido (en las secciones donde se aplican las reubicaciones), y así hacer que la comparación sea confiable.
* Se enumeran las funciones exportadas y se comparan los primeros bytes de las versiones "en memoria" y "en disco". Cualquier diferencia indica una alteración que se ha realizado después de que el DLL se cargó, y por lo tanto es muy probablemente un hook de EDR.

Nota: El proceso puede generalizarse para encontrar diferencias en cualquier lugar de las secciones no escribibles y no solo al inicio de las funciones exportadas, por ejemplo, si los productos EDR comienzan a aplicar hooks en medio de la función :) Por lo tanto, no es utilizado por la herramienta, esto se ha implementado en `findDiffsInNonWritableSections`.

Con el fin de evitar la monitorización realizada por estos hooks, múltiples técnicas son posibles, y cada una tiene beneficios y desventajas.

#### Bypass de hooks usando ... desenganche (unhooking)
El método más intuitivo para evitar la monitorización basada en hooks es eliminar los hooks. Dado que los hooks están presentes en la memoria a la que el propio proceso puede acceder, para eliminar un hook, el proceso puede simplemente:
* Cambiar los permisos en la página donde se encuentra el hook (RX -> RWX o RW)
* Escribir los bytes originales que se conocen gracias al contenido del DLL en disco
* Restaurar los permisos a RX

Este enfoque es bastante simple y se puede usar para eliminar todos los hooks detectados de una sola vez. Realizado por una herramienta ofensiva al inicio, esto permite que el resto del código sea completamente ajeno al mecanismo de hooking y funcione normalmente sin ser monitoreado.

Sin embargo, tiene dos desventajas principales. El EDR probablemente esté monitoreando el uso de `NtProtectVirtualMemory`, por lo que usarlo para cambiar los permisos de la página donde se han instalado los hooks es (al menos conceptualmente) una mala idea. Además, si un hilo es ejecutado por el EDR y verifica periódicamente la integridad de los hooks, esto también podría desencadenar alguna detección.

Para obtener detalles de implementación, consulte la ruta de código de la función `unhook()` cuando `unhook_method` es `UNHOOK_WITH_NTPROTECTVIRTUALMEMORY`.

**Nota importante: por simplicidad, esta técnica está implementada en EDRSandblast como la técnica base utilizada para *mostrar* las otras técnicas de bypass; cada una de ellas demuestra cómo obtener una versión no monitoreada de `NtProtectVirtualMemory`, pero realiza la misma operación después (desenganchar un hook específico).**

#### Bypass de hooks usando un trampolín personalizado
Para evitar un hook específico, es posible simplemente "saltar sobre" y ejecutar el resto de la función tal cual. Primero, los bytes originales de la función monitoreada, que han sido sobrescritos por el EDR para instalar el hook, deben recuperarse del archivo DLL. En nuestro ejemplo de código anterior, estos serían los bytes correspondientes a las siguientes instrucciones:```assembly
mov r10, rcx
mov eax, 50h

Finalmente, concatenamos estos opcodes, los almacenamos en memoria (recién) ejecutable y mantenemos un puntero a ellos. Este objeto se llama un "*trampoline*" y puede usarse como un puntero a función, estrictamente equivalente a la función original `NtProtectVirtualMemory`.

El principal beneficio de esta técnica, como para todas las técnicas a continuación, es que el hook nunca se elimina, por lo que cualquier verificación de integridad realizada en los hooks por el EDR debería pasar. Sin embargo, requiere asignar memoria primero escribible y luego ejecutable, lo cual es típico de una asignación de shellcode, atrayendo así el escrutinio del EDR.

Para detalles de implementación, consulte la ruta de código de la función `unhook()` cuando `unhook_method` es `UNHOOK_WITH_INHOUSE_NTPROTECTVIRTUALMEMORY_TRAMPOLINE`. Recuerde que la técnica solo se muestra en nuestra implementación y, al final, se usa para **eliminar** hooks de la memoria, como todas las técnicas a continuación.

#### Bypass de hook usando el propio trampoline del EDR
El producto EDR, para que su hook funcione, debe guardar en algún lugar de la memoria los opcodes que ha eliminado. Peor aún (*o "mejor", desde el punto de vista del atacante*), para usar efectivamente las instrucciones originales, el EDR probablemente se ha asignado un *trampoline* en algún lugar para ejecutar la función original después de interceptar la llamada.

Este trampoline se puede buscar y utilizar como reemplazo de la función hookeada, sin necesidad de asignar memoria ejecutable, ni llamar a ninguna API excepto `VirtualQuery`, que muy probablemente no esté monitorizada por ser una función inocua.

Para encontrar el trampoline en memoria, recorremos todo el espacio de direcciones usando `VirtualQuery` buscando memoria confirmada y ejecutable. Para cada región de memoria de este tipo, la escaneamos buscando una instrucción de salto que apunte a la dirección siguiente a las instrucciones sobrescritas (`NtProtectVirtualMemory+8` en nuestro ejemplo anterior). El trampoline se puede usar entonces para llamar a la función hookeada sin activar el hook.

Esta técnica funciona sorprendentemente bien ya que recupera casi todos los trampolines en los EDR probados. Para detalles de implementación, consulte la ruta de código de la función `unhook()` cuando `unhook_method` es `UNHOOK_WITH_EDR_NTPROTECTVIRTUALMEMORY_TRAMPOLINE`.

#### Bypass de hook usando DLL duplicada
Otro método simple para obtener acceso a una versión no monitoreada de la función `NtProtectVirtualMemory` es cargar una versión duplicada de la librería `ntdll.dll` en el espacio de direcciones del proceso. Dado que dos DLL idénticas pueden cargarse en el mismo proceso, siempre que tengan nombres diferentes, simplemente podemos copiar el archivo legítimo `ntdll.dll` a otra ubicación, cargarlo usando `LoadLibrary` (o reimplementar el proceso de carga), y acceder a la función usando `GetProcAddress` por ejemplo.

Esta técnica es muy simple de entender e implementar, y tiene una posibilidad decente de éxito, ya que la mayoría de los productos EDR no reinstalan hooks en DLL recién cargadas una vez que el proceso está en ejecución. Sin embargo, el principal inconveniente es que copiar binarios firmados por Microsoft bajo un nombre diferente a menudo se considera sospechoso por los propios productos EDR.

Sin embargo, esta técnica está implementada en `EDRSandblast`. Para detalles de implementación, consulte la ruta de código de la función `unhook()` cuando `unhook_method` es `UNHOOK_WITH_DUPLICATE_NTPROTECTVIRTUALMEMORY`.

#### Bypass de hook usando syscalls directas
Para usar funciones relacionadas con llamadas al sistema, un programa puede reimplementar syscalls (en ensamblador) para llamar a las características correspondientes del SO sin tocar realmente el código en `ntdll.dll`, que podría estar monitoreado por el EDR. Esto evita completamente cualquier hooking en modo usuario realizado en funciones de syscall en `ntdll.dll`.

Esto, sin embargo, tiene algunos inconvenientes. Primero, implica poder conocer la lista de números de syscall de las funciones que el programa necesita, lo cual cambia para cada versión de Windows. Esto se mitiga implementando múltiples heurísticas que se sabe que funcionan en todas las versiones pasadas de Windows NT (ordenando las exportaciones `Zw*` de `ntdll`, buscando la instrucción `mov rax, #syscall_number` en la función `ntdll` asociada, etc.), y verificando que todas devuelvan el mismo resultado (consulte `Syscalls.c` para más detalles).

Además, las funciones que técnicamente no son syscalls (por ejemplo, `LoadLibraryX`/`LdrLoadDLL`) también podrían estar monitoreadas, y no pueden simplemente reimplementarse usando un syscall.

La técnica de syscalls directas está implementada en EDRSandblast. Como se dijo anteriormente, solo se usa para ejecutar `NtProtectVirtualMemory` de manera segura, y eliminar todos los hooks detectados.

Para detalles de implementación, consulte la ruta de código de la función `unhook()` cuando `unhook_method` es `UNHOOK_WITH_DIRECT_SYSCALL`.

### Explotación de drivers vulnerables
Como se dijo anteriormente, cada acción que necesita una lectura o escritura en memoria del kernel depende de un driver vulnerable para proporcionar esta primitiva. En EDRSanblast, agregar soporte para un nuevo driver que proporcione la primitiva de lectura/escritura se puede hacer "fácilmente", solo se deben implementar tres funciones:
* Una función `ReadMemoryPrimitive_DRIVERNAME(SIZE_T Size, DWORD64 Address, PVOID Buffer)`, que copia `Size` bytes desde la dirección del kernel `Address` al buffer de espacio de usuario `Buffer`;
* Una función `WriteMemoryPrimitive_DRIVERNAME(SIZE_T Size, DWORD64 Address, PVOID Buffer)`, que copia `Size` bytes desde el buffer de espacio de usuario `Buffer` a la dirección del kernel `Address`;
* Una función `CloseDriverHandle_DRIVERNAME()` que asegura que todos los handles al driver estén cerrados (necesario antes de la operación de desinstalación que es independiente del driver, por el momento).

Como ejemplo, dos drivers están actualmente soportados por EDRSandblast, `RTCore64.sys` (SHA256: `01AA278B07B58DC46C84BD0B1B5C8E9EE4E62EA0BF7A695862444AF32E87F1FD`) y `DBUtils_2_3.sys` (SHA256: `0296e2ce999e67c76352613a718e11516fe1b0efc3ffdb8918fc999dd76a73a5`). El siguiente código en `KernelMemoryPrimitives.h` debe ser actualizado si el driver vulnerable usado necesita ser cambiado, o si se implementa uno nuevo.```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

### Opciones```
-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')

## Detección
Desde el punto de vista del defensor (proveedor de EDR, Microsoft, analistas de SOC que examinan la telemetría del EDR, ...), se pueden utilizar múltiples indicadores para detectar o prevenir este tipo de técnicas.

### Lista blanca de controladores
Dado que cada acción realizada por la herramienta en la memoria en modo kernel depende de un controlador vulnerable para leer/escribir contenido arbitrario, los eventos de carga de controladores deben ser examinados minuciosamente por el producto EDR (o los analistas de SOC), y generar una alerta ante cualquier carga de controlador inusual, o incluso bloquear controladores vulnerables conocidos. Este último enfoque está incluso [recomendado por Microsoft](https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/microsoft-recommended-driver-block-rules): cualquier dispositivo Windows con HVCI (*Hypervisor-protected code integrity*) habilitado incluye una lista de bloqueo de controladores, y esto se convertirá progresivamente en un comportamiento predeterminado en Windows (ya lo es en Windows 11).

### Comprobaciones de integridad de la memoria del kernel
Dado que un atacante aún podría usar un controlador vulnerable desconocido para realizar las mismas acciones en memoria, el controlador del EDR podría verificar periódicamente que sus devoluciones de llamada del kernel siguen registradas, ya sea inspeccionando directamente la memoria del kernel (como hace esta herramienta), o simplemente desencadenando eventos (creación de procesos, creación de hilos, carga de imágenes, etc.) y verificando que las funciones de devolución de llamada sean efectivamente invocadas por el kernel ejecutivo.

Como nota al margen, este tipo de estructura de datos podría protegerse mediante el reciente mecanismo [Kernel Data Protection (KDP)](https://www.microsoft.com/security/blog/2020/07/08/introducing-kernel-data-protection-a-new-platform-security-technology-for-preventing-data-corruption/), que se basa en Virtual Based Security, para evitar que el array de devoluciones de llamada del kernel sea escribible sin llamar a las API correctas.

La misma lógica podría aplicarse a variables ETW sensibles como `ProviderEnableInfo`, abusada por esta herramienta para deshabilitar la generación de eventos de Inteligencia de Amenazas de ETW.

### Detección en modo usuario
El primer indicador de que un proceso está tratando activamente de evadir el hooking del espacio de usuario es el acceso a archivos de cada DLL correspondiente a los módulos cargados; en una ejecución normal, un proceso de espacio de usuario rara vez necesita leer archivos DLL fuera de una llamada `LoadLibrary`, especialmente `ntdll.dll`.

Para proteger el hooking de API de ser eludido, los productos EDR podrían verificar periódicamente que los hooks no hayan sido alterados en memoria, dentro de cada proceso monitoreado.

Finalmente, para detectar la evasión de hooks (abuso de un trampolín, uso de syscalls directas, etc.) que no implique la eliminación de hooks, los productos EDR podrían potencialmente basarse en devoluciones de llamada del kernel asociadas a las syscalls abusadas (ej. `PsCreateProcessNotifyRoutine` para la syscall `NtCreateProcess`, `ObRegisterCallbacks` para la syscall `NtOpenProcess`, etc.), y realizar un análisis de la pila de llamadas en modo usuario para determinar si la syscall se activó desde una ruta normal (`kernel32.dll` -> `ntdll.dll` -> syscall) o una anormal (ej. `program.exe` -> syscall directa).

## Agradecimientos

- Enumeración y eliminación de devoluciones de llamada del kernel:
  https://github.com/br-sn/CheekyBlinder

- Primitivas de lectura/escritura de memoria del kernel a través del controlador
  vulnerable `Micro-Star MSI Afterburner`:
  https://github.com/Barakat/CVE-2019-16098/

- Deshabilitación del proveedor de Inteligencia de Amenazas de ETW:
  https://public.cnotools.studio/bring-your-own-vulnerable-kernel-driver-byovkd/exploits/data-only-attack-neutralizing-etwti-provider

- Instalación/desinstalación de controladores: https://github.com/gentilkiwi/mimikatz

- Lista inicial de nombres de controladores de EDR:
  https://github.com/SadProcessor/SomeStuff/blob/master/Invoke-EDRCheck.ps1

- Bypass de Credential Guard re-habilitando `Wdigest` mediante parcheo de memoria
  de `LSASS`: https://teamhydra.blog/2020/08/25/bypassing-credential-guard/

## Autores

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

## Agradecimientos a los colaboradores
- [v1k1ngfr](https://github.com/v1k1ngfr): por el bypass de la comprobación de firma de controladores (mediante parcheo de `g_CiOptions`) y soporte del controlador GDRV.sys
- [Windy Bug](https://github.com/0mWindyBug): por un bypass de la comprobación de firma de controladores compatible con KDP (mediante *intercambio de devoluciones de llamada*) y su gran contribución a la funcionalidad de bypass de minifiltro

## Licencia

Licencia CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/