# EDRSandBlast

`EDRSandBlast` es una herramienta escrita en `C` que utiliza un controlador firmado vulnerable para evadir las detecciones de EDR (callbacks de rutinas de notificación, callbacks de objetos y el proveedor `ETW TI`) y las protecciones de `LSASS`. También se implementan múltiples técnicas de unhooking en modo usuario para evadir la monitorización en modo usuario.

En el momento del lanzamiento, se utilizó una combinación de técnicas de modo usuario (`--usermode`) y modo kernel (`--kernelmode`) para volcar la memoria de `LSASS` bajo el escrutinio de un EDR, sin ser bloqueado ni generar eventos relacionados con "Volcado de credenciales del SO" en la consola (en la nube) del producto. Las pruebas se realizaron en 3 productos EDR distintos y fueron exitosas en cada caso.

## Descripción

### Omisión de EDR mediante la eliminación de rutinas de notificación del kernel

Los productos EDR utilizan callbacks de "Notify Routines" del kernel en Windows para ser notificados por el kernel de la actividad del sistema, como la creación de procesos e hilos y la carga de imágenes (`exe` / `DLL`).

Estos callbacks del kernel se definen desde el espacio del kernel, generalmente desde el controlador que implementa los callbacks, utilizando una serie de APIs documentadas (`nt!PsSetCreateProcessNotifyRoutine`, `nt!PsSetCreateThreadNotifyRoutine`, etc.). Estas APIs añaden rutinas de callback proporcionadas por el controlador a arrays no documentados de rutinas en el espacio del kernel:
  - `PspCreateProcessNotifyRoutine` para la creación de procesos
  - `PspCreateThreadNotifyRoutine` para la creación de hilos
  - `PspLoadImageNotifyRoutine` para la carga de imágenes

`EDRSandBlast` enumera las rutinas definidas en esos arrays y elimina cualquier rutina de callback vinculada a una lista predefinida de controladores EDR (más de 1000 controladores de productos de seguridad compatibles; consulte la [sección de detección de controladores EDR](#detección-de-controladores-y-procesos-edr)). La enumeración y eliminación son posibles gracias a la explotación de una primitiva arbitraria de lectura/escritura de memoria del kernel proporcionada por la explotación de un controlador vulnerable (consulte la [sección de controladores vulnerables](#detección-de-controladores-vulnerables)).

Los offsets de los arrays mencionados se recuperan mediante múltiples técnicas; consulte la [sección de offsets](#offsets-de-ntoskrnl-y-wdigest).

### Omisión de EDR mediante la eliminación de callbacks de objetos

Los productos EDR (e incluso EPP) a menudo registran "callbacks de objetos" mediante el uso de la API del kernel `nt!ObRegisterCallbacks`. Estos callbacks permiten que el producto de seguridad sea notificado en cada generación de handles sobre tipos de objetos específicos (Windows ahora admite callbacks de objetos relacionados con procesos, hilos y escritorios). Una generación de handle puede ocurrir al abrir un objeto (llamada a `OpenProcess`, `OpenThread`, etc.) así como al duplicar un handle (llamada a `DuplicateHandle`, etc.).

Al ser notificado por el kernel en cada una de estas operaciones, un producto de seguridad puede analizar la legitimidad de la creación del handle (por ejemplo, un proceso desconocido intenta abrir LSASS) e incluso bloquearlo si se detecta una amenaza.

En cada registro de callback mediante `ObRegisterCallbacks`, se añade un nuevo elemento a la lista doblemente enlazada `CallbackList` presente en el objeto `_OBJECT_TYPE` que describe el tipo de objeto afectado por el callback (ya sea un proceso, un hilo o un escritorio). Desafortunadamente, estos elementos se describen mediante una estructura que no está documentada ni publicada en los archivos de símbolos por Microsoft. Sin embargo, estudiarla a partir de varias versiones de `ntoskrnl.exe` parece indicar que la estructura no cambió entre (al menos) las compilaciones 10240 y 22000 de Windows 10 (de 2015 a 2022).

La estructura mencionada, que representa un registro de callback de objeto, es la siguiente:```C
typedef struct OB_CALLBACK_ENTRY_t {
    LIST_ENTRY CallbackList; // linked element tied to _OBJECT_TYPE.CallbackList
    OB_OPERATION Operations; // bitfield : 1 for Creations, 2 for Duplications
    BOOL Enabled;            // self-explanatory
    OB_CALLBACK* Entry;      // points to the structure in which it is included
    POBJECT_TYPE ObjectType; // points to the object type affected by the callback
    POB_PRE_OPERATION_CALLBACK PreOperation;      // callback function called before each handle operation
    POB_POST_OPERATION_CALLBACK PostOperation;     // callback function called after each handle operation
    KSPIN_LOCK Lock;         // lock object used for synchronization
} OB_CALLBACK_ENTRY;

Para deshabilitar las devoluciones de llamada de objetos registradas por EDR, se implementan tres técnicas en
`EDRSandblast`; sin embargo, solo una está habilitada por el momento.

#### Usando el campo `Enabled` de `OB_CALLBACK_ENTRY`
Esta es la técnica predeterminada habilitada en `EDRSandblast`. Para detectar y deshabilitar
las devoluciones de llamada de objetos relacionadas con EDR, se recorre la lista `CallbackList` ubicada en los objetos `_OBJECT_TYPE`
vinculados a los tipos *Process* y *Thread*. Ambos `_OBJECT_TYPE` son
señalados por símbolos globales públicos en el kernel, `PsProcessType` y `PsThreadType`.

Se asume que cada elemento de la lista se ajusta a la estructura `OB_CALLBACK_ENTRY` descrita anteriormente
(suposición que parece cumplirse al menos en todas las versiones de Windows 10 al momento de escribir esto).
Las funciones definidas en los campos `PreOperation` y `PostOperation` se localizan para verificar
si pertenecen a un controlador EDR, y si es así, las devoluciones de llamada simplemente se deshabilitan alternando el indicador `Enabled`.

Si bien es una técnica bastante segura, tiene el inconveniente de depender de una estructura
no documentada; para reducir el riesgo de manipulación insegura de esta estructura, se realizan
verificaciones básicas para validar que algunos campos tengan los valores esperados:
* `Enabled` es `TRUE` o `FALSE` (*no te rías, un `BOOL` es un `int`, por lo que podría ser cualquier cosa que no sea `1` o `0`*);
* `Operations` es `OB_OPERATION_HANDLE_CREATE`,  `OB_OPERATION_HANDLE_DUPLICATE` o ambos;
* `ObjectType` apunta a `PsProcessType` o `PsThreadType`.

#### Desvinculando la `CallbackList` de hilos y procesos
Otra estrategia que no depende de una estructura no documentada (y por lo tanto es teóricamente
más robusta frente a cambios del kernel NT) es la desvinculación de toda la `CallbackList`
tanto para procesos como para hilos. El objeto `_OBJECT_TYPE` es el siguiente:```C
struct _OBJECT_TYPE {
	LIST_ENTRY TypeList;
	UNICODE_STRING Name;
	[...]
	_OBJECT_TYPE_INITIALIZER TypeInfo;
	[...]
	LIST_ENTRY CallbackList;
}

#### `--validate`

Especificar `--validate` le indica a Linkly que realice validación de enlaces usando solicitudes HTTP HEAD. Esta funcionalidad verifica que los enlaces en tus archivos estén accesibles.

Esta bandera también se puede proporcionar mediante la variable de entorno:

- **Variable de entorno**: `LINKLY_VALIDATE`
  - `true` - Realizar validación de enlaces para todos los archivos
  - `false` - No validar enlaces```assembly
NtProtectVirtualMemory proc near
	jmp     sub_7FFC74490298     ; --> "hook", jump to EDR analysis function
	int 3                        ; overwritten instructions
	int 3                        ; overwritten instructions
	int 3                        ; overwritten instructions
	test byte_7FFE0308, 1        ; <-- execution resumes here after analysis
	jnz short loc_7FFCB44AD1E5
	syscall
	retn
loc_7FFCB44AD1E5:
	int 2Eh
	retn
NtProtectVirtualMemory   endp			

Identificar estos bytes es una tarea sencilla, ya que podemos realizar un *diff* limpio de
ambas versiones de la biblioteca (en memoria y en disco), como se describió anteriormente. Luego,
ensamblamos una instrucción de salto que está diseñada para redirigir el flujo de control al código
que sigue inmediatamente después del hook, en la dirección `NtProtectVirtualMemory +
sizeof(overwritten_instructions)````assembly
jmp NtProtectVirtualMemory+8

### Detección de controladores y procesos EDR
Actualmente se utilizan múltiples técnicas para determinar si un controlador o proceso específico
pertenece o no a un producto EDR.

En primer lugar, el nombre del controlador puede usarse simplemente para ese propósito. De hecho, Microsoft
asigna números específicos llamados "Altitudes" para todos los controladores que necesitan insertar callbacks
en el kernel. Esto permite un orden determinista en la ejecución de los callbacks, independiente del
orden de registro, pero basado únicamente en el uso del controlador. Una lista de (fabricantes de) controladores
que han reservado *altitude* específico se puede encontrar
[en MSDN](https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/allocated-altitudes).
Como consecuencia, Microsoft ofrece una lista casi exhaustiva de nombres de controladores de seguridad vinculados a
productos de seguridad, principalmente en las listas "FSFilter Anti-Virus" y "FSFilter Activity
Monitor". Estas listas de nombres de controladores están incrustadas en EDRSandblast, así como
contribuciones adicionales.

Además, los ejecutables y DLL de EDR suelen estar firmados digitalmente con el
certificado de firma del fabricante. Por lo tanto, verificar el firmante de un ejecutable o DLL
asociado a un proceso puede permitir identificar rápidamente productos EDR.

Además, los controladores deben estar firmados directamente por Microsoft para poder cargarse en
el espacio del kernel. Si bien el fabricante del controlador no es directamente el firmante del controlador en sí,
parece que el nombre del fabricante aún se incluye dentro de un atributo de la firma;
esta técnica de detección aún está por investigar e implementar.

Finalmente, al enfrentarse a un EDR desconocido para EDRSandblast, el mejor enfoque es ejecutar
la herramienta en modo "audit" y verificar la lista de controladores que han registrado callbacks del kernel;
luego se puede agregar el nombre del controlador a la lista, recompilar la herramienta y volver a ejecutarla.

### Bypass de RunAsPPL

El mecanismo de `Protección de la Autoridad de Seguridad Local (LSA)`, introducido por primera vez
en Windows 8.1 y Windows Server 2012 R2, aprovecha la tecnología `Protected Process
Light (PPL)` para restringir el acceso al proceso `LSASS`. La protección `PPL`
regula y restringe operaciones, como la inyección de memoria o el volcado de memoria de procesos protegidos,
incluso desde un proceso que posee el privilegio `SeDebugPrivilege`. Bajo el modelo de protección de procesos,
solo los procesos que se ejecutan con niveles de protección más altos pueden realizar operaciones en
procesos protegidos.

La estructura `_EPROCESS`, utilizada por el kernel de Windows para representar un proceso
en la memoria del kernel, incluye un campo `_PS_PROTECTION` que define el nivel de protección
de un proceso a través de sus atributos `Type` (`_PS_PROTECTED_TYPE`) y `Signer` (`_PS_PROTECTED_SIGNER`).

Al escribir en la memoria del kernel, el proceso de EDRSandblast puede actualizar su propio
nivel de protección a `PsProtectedSignerWinTcb-Light`. Este nivel es suficiente para
volcar la memoria del proceso `LSASS`, ya que "domina" a `PsProtectedSignerLsa-Light`,
el nivel de protección del proceso `LSASS` que se ejecuta con el mecanismo `RunAsPPL`.

`EDRSandBlast` implementa la autoprotección de la siguiente manera:
  - abre un identificador al proceso actual
  - filtra todos los identificadores del sistema usando `NtQuerySystemInformation` para encontrar el identificador
    abierto en el proceso actual, y la dirección de la estructura `EPROCESS` del proceso actual
    en la memoria del kernel.
  - usa la vulnerabilidad de lectura/escritura arbitraria del controlador `Micro-Star MSI
    Afterburner` para sobrescribir el campo `_PS_PROTECTION` del proceso actual
    en la memoria del kernel. Los desplazamientos del campo `_PS_PROTECTION`
    en relación con la estructura `EPROCESS` (definidos por la versión de `ntoskrnl` en
    uso) se calculan en el archivo `NtoskrnlOffsets.csv`.

### Bypass de Credential Guard

Microsoft `Credential Guard` es una tecnología de aislamiento basada en virtualización,
introducida en `Windows 10 (edición Enterprise)` de Microsoft, que impide
el acceso directo a las credenciales almacenadas en el proceso `LSASS`.

Cuando `Credentials Guard` está activado, se crea un proceso `LSAIso` (*LSA Isolated*) en
`Modo Virtual Seguro`, una característica que aprovecha las extensiones de virtualización
de la CPU para proporcionar una seguridad adicional de los datos en la memoria. El acceso al
proceso `LSAIso` está restringido incluso para un acceso con el contexto de seguridad
`NT AUTHORITY\SYSTEM`. Al procesar un hash, el proceso `LSA`
realiza una llamada `RPC` al proceso `LSAIso` y espera el resultado de
`LSAIso` para continuar. Por lo tanto, el proceso `LSASS` no contendrá ningún
secreto y, en su lugar, almacenará `Datos aislados de LSA`.

Como se indica en la investigación original realizada por `N4kedTurtle`: "`Wdigest` se puede
habilitar en un sistema con Credential Guard parcheando los valores de
`g_fParameter_useLogonCredential` y `g_IsCredGuardEnabled` en la memoria".
La activación de `Wdigest` hará que se almacenen credenciales en texto claro en la memoria
de `LSASS` para cualquier nuevo inicio de sesión interactivo (sin requerir un reinicio del
sistema). Consulte la
[publicación del blog de investigación original](https://teamhydra.blog/2020/08/25/bypassing-credential-guard/)
para obtener más detalles sobre esta técnica.

`EDRSandBlast` simplemente hace que el PoC original sea un poco más amigable para OpSec y
proporciona soporte para varias versiones de `wdigest.dll` (a través de desplazamientos
calculados para `g_fParameter_useLogonCredential` y `g_IsCredGuardEnabled`).

### Recuperación de desplazamientos
Para realizar de manera confiable las operaciones de omisión de monitoreo del kernel, EDRSandblast necesita
saber exactamente dónde leer y escribir en la memoria del kernel. Esto se hace usando desplazamientos de
variables globales dentro de la imagen de destino (ntoskrnl.exe, wdigest.dll), así como el desplazamiento
de campos específicos en estructuras cuyas definiciones son publicadas por Microsoft en archivos
de símbolos. Estos desplazamientos son específicos de cada compilación de las imágenes de destino y deben recopilarse
al menos una vez para una versión de plataforma específica.

La elección de usar desplazamientos "codificados" en lugar de búsquedas de patrones para localizar las estructuras
y variables utilizadas por EDRSandblast se justifica por el hecho de que las API no documentadas
responsables de la adición/eliminación de callbacks del kernel están sujetas a cambios y que cualquier intento
de leer o escribir en la memoria del kernel en la dirección incorrecta puede (y a menudo resultará) en un
`Bug Check` (`Pantalla azul de la muerte`). Un bloqueo de la máquina no es aceptable en escenarios tanto de
red-teaming como de pruebas de penetración normales, ya que una máquina que se bloquea
es altamente visible para los defensores y perderá cualquier credencial que aún estuviera en memoria en el
momento del ataque.

Para recuperar los desplazamientos para cada versión específica de Windows, se implementan dos enfoques.

#### Recuperación manual de desplazamientos
Los desplazamientos requeridos de `ntoskrnl.exe` y `wdigest.dll` se pueden extraer usando el
script de Python proporcionado `ExtractOffsets.py`, que se basa en `radare2` y `r2pipe`
para descargar y analizar símbolos de archivos PDB, y extraer los desplazamientos necesarios de
ellos. Los desplazamientos se almacenan luego en archivos CSV para su uso posterior por EDRSandblast.

Para admitir de forma inmediata una amplia gama de compilaciones de Windows, muchas versiones de
los binarios `ntoskrnl.exe` y `wdigest.dll` son referenciadas por
[Winbindex](https://winbindex.m417z.com/) y se pueden descargar automáticamente
(y extraer sus desplazamientos) mediante `ExtractOffsets.py`. Esto permite extraer desplazamientos
de casi todos los archivos que alguna vez se publicaron en paquetes de actualización de Windows (hasta la fecha, más de 450
versiones de `ntoskrnl.exe` y más de 30 de `wdigest.dll` están disponibles y precalculadas).

#### Recuperación y actualización automática de desplazamientos
Se ha implementado una opción adicional en `EDRSandBlast` para permitir que el programa
descargue los archivos `.pdb` necesarios del Servidor de Símbolos de Microsoft, extraiga los
desplazamientos requeridos e incluso actualice los archivos `.csv` correspondientes si están presentes.

El uso de la opción `--internet` hace que la ejecución de la herramienta sea mucho más simple, pero introduce
un riesgo adicional de OpSec, ya que se descarga un archivo `.pdb` y se coloca en el disco durante
el proceso. Esto es requerido por las funciones de `dbghelp.dll` utilizadas para analizar la base de datos
de símbolos; sin embargo, se podría implementar en el futuro un análisis completo de PDB en memoria para
eliminar este requisito y reducir la huella de la herramienta.

## Uso

El controlador vulnerable `RTCore64.sys` se puede obtener en:```
http://download-eu2.guru3d.com/afterburner/%5BGuru3D.com%5D-MSIAfterburnerSetup462Beta2.zip

### 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 LSASS process, by default as 'lsass' 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.

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

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

        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

Other options:

--dont-unload-driver                    Keep the vulnerable driver installed on the host
                                        Default to automatically unsinstall the driver.
--dont-restore-callbacks                Do not restore the EDR drivers' Kernel Callbacks that were removed.
                                        Default to restore the callbacks.

--driver <RTCore64.sys>                 Path to the vulnerable driver file.
                                        Default to 'RTCore64.sys' in the current directory.
--service <SERVICE_NAME>                Name of the vulnerable service to intall / start.

--nt-offsets <NtoskrnlOffsets.csv>      Path to the CSV file containing the required ntoskrnl.exe's offsets.
                                        Default to 'NtoskrnlOffsets.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.

--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...

-o | --output <DUMP_FILE>               Output path to the dump file that will be generated by the 'dump' mode.
                                        Default to 'lsass' 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 ntoskrnl.exe and/or wdigest.dll

## Detección
Desde el punto de vista del defensor (proveedor de EDR, Microsoft, analistas de SOC que miran la telemetría de 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 analistas de SOC), y generar una alerta ante cualquier carga de controlador inusual, o incluso bloquear controladores vulnerables conocidos. Este último enfoque es 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 incorpora 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 la memoria, el controlador EDR podría verificar periódicamente que sus devoluciones de llamada del kernel aún estén registradas, ya sea inspeccionando directamente la memoria del kernel (como hace esta herramienta), o simplemente activando eventos (creación de procesos, creación de hilos, carga de imágenes, etc.) y comprobando que las funciones de devolución de llamada son 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 hacer que el array de devoluciones de llamada del kernel no 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 ETW Threat Intelligence.

### Detección en modo usuario
El primer indicador de que un proceso está activamente tratando de evadir el hooking en modo usuario son los accesos a archivos para cada DLL correspondiente a los módulos cargados; en una ejecución normal, un proceso en modo 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 comprobar periódicamente que los hooks no se hayan alterado en la memoria, dentro de cada proceso monitorizado.

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 los hooks, los productos EDR podrían potencialmente confiar en las devoluciones de llamada del kernel asociadas a los syscalls abusados (ej. `PsCreateProcessNotifyRoutine` para el syscall `NtCreateProcess`, `ObRegisterCallbacks` para el syscall `NtOpenProcess`, etc.), y realizar un análisis de la pila de llamadas en modo usuario para determinar si el syscall fue activado desde una ruta normal (`kernel32.dll` -> `ntdll.dll` -> syscall) o anormal (ej. `program.exe` -> syscall directo).


## 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 ETW Threat Intelligence:
  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 EDR:
  https://github.com/SadProcessor/SomeStuff/blob/master/Invoke-EDRCheck.ps1

- Bypass de Credential Guard reactivando `Wdigest` a través de 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)

## Licencia

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