Skip to content
KitploitKITPLOIT
HerramientasExploitsBlog
Log in
Enviar
HerramientasExploitsBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

FeedsContactoPrivacidad© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
EDRSandblast — Armamentiza controladores firmados vulnerables para evadir callbacks del kernel de EDR, callbacks de objetos, el proveedor ETW TI y ganchos de espacio de usuario para el volcado de memoria de LSASS y la extracción de credenciales. | Kitploit
Herramientas/GitHubGitHub/wavestone-cdt/edrsandblast
Herramientas DefensivasEscalada de PrivilegiosExplotaciónPruebas de PenetraciónRed Teaming
GitHubwavestone-cdt/edrsandblast

EDRSandblast

Armamentiza controladores firmados vulnerables para evadir callbacks del kernel de EDR, callbacks de objetos, el proveedor ETW TI y ganchos de espacio de usuario para el volcado de memoria de LSASS y la extracción de credenciales.

Ver Repositorio
1.8k32018hace 2 añosRevisado por Kitploit

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

EDRSandBlast

EDRSandBlast es una herramienta escrita en C que aprovecha un controlador firmado vulnerable para eludir las detecciones de EDR (devoluciones de llamada de rutina de notificación, devoluciones de llamada de objetos y el proveedor ETW TI) y las protecciones de LSASS. También se implementan múltiples técnicas de unhooking en el espacio de usuario para evadir la monitorización del espacio de usuario.

A la fecha del lanzamiento, se utilizó una combinación de técnicas de espacio de usuario (--usermode) y espacio de kernel (--kernelmode) para volcar la memoria de LSASS bajo el escrutinio de EDR, sin ser bloqueado ni generar eventos relacionados con "OS Credential Dumping" en la consola del producto (en la nube). Las pruebas se realizaron en 3 productos EDR distintos y fueron exitosas en cada caso.

Descripción

Bypass de EDR mediante eliminación de rutinas de notificación del kernel

Los productos EDR utilizan devoluciones de llamada de "Rutinas de Notificación" del kernel en Windows para ser notificados por el kernel de la actividad del sistema, como la creación de procesos y subprocesos y la carga de imágenes (exe / DLL).

Estas devoluciones de llamada del kernel se definen desde el espacio del kernel, generalmente desde el controlador que implementa las devoluciones de llamada, utilizando varias API documentadas (nt!PsSetCreateProcessNotifyRoutine, nt!PsSetCreateThreadNotifyRoutine, etc.). Estas API agregan rutinas de devolución de llamada proporcionadas por el controlador a arreglos no documentados de rutinas en el espacio del kernel:

  • PspCreateProcessNotifyRoutine para la creación de procesos
  • PspCreateThreadNotifyRoutine para la creación de subprocesos
  • PspLoadImageNotifyRoutine para la carga de imágenes

EDRSandBlast enumera las rutinas definidas en esos arreglos y elimina cualquier rutina de devolución de llamada 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). La enumeración y eliminación son posibles mediante 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). Los desplazamientos de los arreglos mencionados se recuperan utilizando múltiples técnicas; consulte la sección de desplazamientos.

Bypass de EDR mediante eliminación de devoluciones de llamada de objetos

Los productos EDR (e incluso EPP) a menudo registran "devoluciones de llamada de objetos" mediante el uso de la API del kernel nt!ObRegisterCallbacks. Estas devoluciones de llamada permiten que el producto de seguridad sea notificado en cada generación de identificadores en tipos de objetos específicos (ahora Windows admite devoluciones de llamada de objetos relacionados con procesos, subprocesos y escritorios). Puede ocurrir una generación de identificadores al abrir un objeto (llamada a OpenProcess, OpenThread, etc.) así como al duplicar un identificador (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 identificador (por ejemplo, un proceso desconocido está tratando de abrir LSASS), e incluso bloquearlo si se detecta una amenaza.

En cada registro de devolución de llamada mediante ObRegisterCallbacks, se agrega un nuevo elemento a la lista doblemente enlazada CallbackList presente en el objeto _OBJECT_TYPE que describe el tipo de objeto afectado por la devolución de llamada (ya sea un Proceso, un Subproceso o un Escritorio). Desafortunadamente, estos elementos se describen mediante una estructura que no está documentada ni publicada en 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 devolución de llamada 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;

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;

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 examina la lista CallbackList ubicada en los objetos _OBJECT_TYPE vinculados a los tipos Process y Thread. Ambos _OBJECT_TYPEs 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, de ser así, las devoluciones de llamada simplemente se deshabilitan alternando el indicador Enabled.

Aunque es una técnica bastante segura, tiene el inconveniente de basarse en una estructura no documentada; para reducir el riesgo de manipulación insegura de esta estructura, se realizan comprobaciones 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.
Descargar herramienta