Currently, while using EDRSandblast, if a specific driver is blocked at loading by the EDR or Microsoft's blacklist, the whole project needs to be recompiled by changing a switch in KernelMemoryPrimitives.h https://github.com/wavestone-cdt/EDRSandblast/blob/4d2789b21b4ef48b1757bcb63dce5cdbf1a121f9/EDRSandblast/Includes/KernelMemoryPrimitives.h#L9
While this guarantees that only the exploit code of one driver will be embedded in the binary at a time, it makes the process of changing driver a bit tedious, especially if it's just for testing things or for a non "opsec-critical" pentest.
Proposed solution
Another mode should be added (e.g. #define VULN_DRIVER ALL) in order to compile all R/W primitives, and make WriteMemory, ReadMemory and CloseDriverHandle function pointers dynamically point at the appropriate functions, depending on the provided vulnerable driver.
A robust way to identify a vulnerable driver is to compute its authenticode or get it from its certificate. A code base is already existing to extract the signer from its certificate (see https://github.com/wavestone-cdt/EDRSandblast/blob/4d2789b21b4ef48b1757bcb63dce5cdbf1a121f9/EDRSandblast/Utils/SignatureOps.c ) so it should be easy to create a GetFileAuthenticode function from the same structure.
A usability problem
Currently, while using EDRSandblast, if a specific driver is blocked at loading by the EDR or Microsoft's blacklist, the whole project needs to be recompiled by changing a switch in KernelMemoryPrimitives.h https://github.com/wavestone-cdt/EDRSandblast/blob/4d2789b21b4ef48b1757bcb63dce5cdbf1a121f9/EDRSandblast/Includes/KernelMemoryPrimitives.h#L9 While this guarantees that only the exploit code of one driver will be embedded in the binary at a time, it makes the process of changing driver a bit tedious, especially if it's just for testing things or for a non "opsec-critical" pentest.
Proposed solution
Another mode should be added (e.g.
#define VULN_DRIVER ALL) in order to compile all R/W primitives, and makeWriteMemory,ReadMemoryandCloseDriverHandlefunction pointers dynamically point at the appropriate functions, depending on the provided vulnerable driver. A robust way to identify a vulnerable driver is to compute its authenticode or get it from its certificate. A code base is already existing to extract the signer from its certificate (see https://github.com/wavestone-cdt/EDRSandblast/blob/4d2789b21b4ef48b1757bcb63dce5cdbf1a121f9/EDRSandblast/Utils/SignatureOps.c ) so it should be easy to create aGetFileAuthenticodefunction from the same structure.