BestEDROfTheMarket: A User-Mode EDR Evasion Lab for Learning and Testing

Little AV/EDR Evasion Lab for training & learning purposes. (????️ under construction..)​

 ____            _     _____ ____  ____     ___   __   _____ _
| __ )  ___  ___| |_  | ____|  _ \|  _ \   / _ \ / _| |_   _| |__   ___
|  _ \ / _ \/ __| __| |  _| | | | | |_) | | | | | |_    | | | '_ \ / _ \
| |_) |  __/\__ \ |_  | |___| |_| |  _ <  | |_| |  _|   | | | | | |  __/
|____/_\___||___/\__| |_____|____/|_| \_\  \___/|_|     |_| |_| |_|\___|
|  \/  | __ _ _ __| | _____| |_
| |\/| |/ _` | '__| |/ / _ \ __|
| |  | | (_| | |  |   <  __/ |_           Yazidou - github.com/Xacone
|_|  |_|\__,_|_|  |_|\_\___|\__|

BestEDROfTheMarket is a naive user-mode EDR (Endpoint Detection and Response) project, designed to serve as a testing ground for understanding and bypassing EDR’s user-mode detection methods that are frequently used by these security solutions.
These techniques are mainly based on a dynamic analysis of the target process state (memory, API calls, etc.),

Feel free to check this short article I wrote that describe the interception and analysis methods implemented by the EDR.

Defensive Techniques

• Multi-Levels API Hooking
• SSN Hooking/Crushing
• IAT Hooking
• Shellcode Injection Detection
• Reflective Module Loading Detection
• Call Stack Monitoring

In progress:

• Heap Monitoring
• ROP Mitigation
• AMSI Patching Mitigation
• ETW Patching Mitigation

Usage

        Usage: BestEdrOfTheMarket.exe [args]

                 /help Shows this help message and quit
                 /v Verbosity                 
                 /iat IAT hooking
                 /stack Threads call stack monitoring
                 /nt Inline Nt-level hooking
                 /k32 Inline Kernel32/Kernelbase hooking
                 /ssn SSN crushing

BestEdrOfTheMarket.exe /stack /v /k32
BestEdrOfTheMarket.exe /stack /nt
BestEdrOfTheMarket.exe /iat

Structure & Config files

???? BestEdrOfTheMarket/
    ???? BestEdrOfTheMarket.exe
    ???? DLLs/
        ???? Kernel32.dll
        ???? ntdll.dll
        ???? iat.dll
    ???? TrigerringFunctions.json
    ???? YaroRules.json
    ???? jsoncpp.dll

YaroRules.json: Contains a json array filled with the patterns you would like to be identified while monitoring threads call stacks.

{
 "Patterns": [
  "d2 65 48 8b 52 60 48 8b 52 18 48 8b 52 20 48 8b 72 50 48",
  "49 be 77 73 32 5f 33 32 00 00",
                "..."
    ]
}

TrigerringFunctions.json: Describes the functions that are already hooked or/and to hook:

ℹ️ Note on call stack monitoring: Some NT routines are more appropriate and less exposed to false positives, for instance, it is strongly recommended to monitor the NtCreateFile when targeting an encrypted shellcode loader, but you should avoid it when targeting a reflective loader in favor of NtCreateUserProcess, which is better suited.

{
  "DLLBasedHooking": {
    "NTDLL.dll": [
      "NtAllocateVirtualMemory",
      "..."
    ],
    "KERNELBASE.dll": [
      "VirtualAlloc"
      "..."
    ],
    "KERNEL32.dll": [
      "VirtualAlloc"
      "..."
    ]
  },
  "StackBasedHooking": {
    "Functions": [
      "NtCreateUserProcess",
      "..."
    ]
  },
  "SSNCrushingRoutines": {
    "Functions": [
      "NtCreateSection"
      "..."
    ]
  },
  "IATHooking": {
    "Functions": [
      "VirtualAlloc",
      "..."
    ]
  }
}

• DLLBasedHooking: Not modifiable ????​​, changing its values will have absolutely no effect at all. Information purposes only.
• StackBasedHooking: Modifiable ✅, the functions you specify here will be monitored and their call will trigger an analysis of the calling thread’s call stack.
• SSNCrushingRoutines: Modifiable ✅, the NT-level routines you will specify here will be attributed a corrupted SSN, Be careful of specifying NT-Level routines ONLY !
• IATHooking: Modifiable ✅, the functions you specify here will be hooked at IAT level

If you don’t compile your own DLLs, take a look at the functions already hooked into the DLLs provided in sources.