Current Features
Process hiding and unhiding
Process elevation
Process protection (anti-kill and dumping)
Bypass pe-sieve
Thread hiding and unhiding
Thread protection (anti-kill)
File protection (anti-deletion and overwriting)
Registry keys and values protection (anti-deletion and overwriting)
Registry keys and values hiding
Querying currently protected processes, threads, files, hidden ports, registry keys and values
Function patching
Built-in AMSI bypass
Built-in ETW patch
Process signature (PP/PPL) modification
Can be reflectively loaded
Shellcode Injection
APC
NtCreateThreadEx
DLL Injection
APC
NtCreateThreadEx
Querying kernel callbacks
ObCallbacks
Process and thread creation routines
Image loading routines
Registry callbacks
Removing and restoring kernel callbacks
ETWTI tampering
Module hiding
Driver hiding and unhiding
Credential Dumping
Port hiding/unhiding
Script execution
Initial operations

Kill processes

ZwTerminateProcess is simply called from kernel land to terminate any process. Additionally, you can bury a process to avoid it to restart by setting a kernel callback to process creation: If the target process is created, Banshee will set the CreationStatus of the target process to STATUS_ACCESS_DENIED.

Change protection levels

This is done by modifying the EPROCESS structure, which is an kernel object that describes a processes attributes. It also holds a value that specifies the protection level of the process.
We can directly modify this value (aka Direct Kernel Object Modification or DKOM), since we are operating in Ring 0.

Elevate any process token to SYSTEM

EPROCESS also holds a pointer to the current access token, so we can just make it point to e.g. the token of process 4 (SYSTEM) to elevate any process to SYSTEM

Enumerating and erasing kernel callbacks

For now, only Process- and Thread-Creation kernel callbacks are enumerated, by parsing the PsSetCreateNotifyProcess/ThreadRoutine routine to reach the private Psp* routine and then parsing the address of the array, where kernel callbacks are stored.

Protecting the driver file

By hooking the NTFS filesystem's IRP_MJ_CREATE handler, we can block any process from opening a handle to our driver file

Hide Process by PID

Again, EPROCESS comes to help here - it contains a LIST_ENTRY of a doubly linked list called ActiveProcessLink which is queried by Windows to enumerate running processes. If we simply unlink an entry here, we can hide our process from tools like Process Monitor or Task Manager.

Obtain a handle to the target process.
Obtain a handle to the process' primary token.
Duplicate the primary token to an impersonation token.
Get the Beacon spawnto value.
Attempt to spawn a new process with the duplicated token using CreateProcessWithTokenW.
If this attempt fails, try CreateProcessAsUserW.
Inject the Beacon shellcode into the spawned process.
Link to the Beacon in the case of P2P.

3DES Encryption
Sandbox Evasion
Analysis Evasion
Execution delay
Process Hollowing
Sign to cs and msf

Windows Defender
Malwarebytes Anti-Malware
CrowdStrike Falcon EDR (Falcon Complete + OverWatch)

Manually implementing NTAPI operations through indirect system calls
Disabling Breaking telemetry features (i.e ETW)
Polymorphism through compile-time hash generation
Obfuscating API function names and pointers
Duplicating existing LSASS handles instead of opening new ones
Creating offline copies of the LSASS process to perform memory dumps on
Corrupting the MDMP signature of dropped files
Probably other stuff I forgot to mention here