Patch Guard(PG), this is one of the more prominent and effective anti-tampering kernel mitigations aimed at stopping rootkits(and shady software including PSPs) from ravaging around the kernel to accomplish their objectives such as AVs hooking
System Service Descriptor Table(SSDT)to gain visibility into system calls etc. It was first introduced in
Windows XP x64.
KPPis designed to detect any changes to critical Windows kernel structures/registers and
bugcheck(Code: 0x109/CRITICAL_STRUCTURE_CORRUPTION)or crash the system with a much dreaded
Blue/Green Screen Of Death(BSOD/GSOD).
KPPlies in its randomness(apart from its obfuscation) of these checks which means it is quite possible that the changes are not caught instantly but after some time has passed by. This way it takes away the reliability from hooking random stuff in the kernel even if it cannot stop it right away.
KPPbut since it is a moving target, vulnerabilities may be fixed as happened with
InfinityHook. Also, note that
KPPmay be disabled by using a bootkit or hooks can simply be hidden using
EPT/NPT ghost hooksby loading a rogue hypervisor.
KPPeven gets a chance to trigger on it and none will be the wiser.
BSODing a target system. In our job, no matter how small the chances are, this is not recommended at all and should only be considered as a last resort option.
Kernel Mode Code Signing(KMCS), it is another prominent and quite effective mitigations to ensure that all kernel drivers are properly signed with a valid digital signature. It was first introduced in
Windows Vista x64.
Windows 10 RS1/1607,
DSEallows third-party drivers to be loaded iff:
Attestation Signed(signed using
Extended Validation(EV)code signing certificate + countersigned by
Microsoft Windows Hardware Compatibility Publisher)
Windows Hardware Quality Labs/WHQL-testing Signed
SecureBoot(SB)is turned off from
Windows 10 RS1/1607OR
Cross Signedusing a valid certificate issued prior to 29th October, 2015
KPP-protected) by exploiting a vulnerable signed driver, using kernel shellcode/
PICas the payload instead of a driver or acquiring valid certificates from third-parties.
KASLRis designed to prevent predicting addresses of some desired kernel memory by randomizing the base address of the kernel image, kernel modules and device drivers on a per-boot/load basis. It was first introduced in
High Entropy ASLR(22 bits of entropy) and
Force ASLR(randomize even for
non-ASLRcompiled modules) along with the information disclosure leaks that have been fixed by Microsoft make this a truly effective mitigation.
KASLRover the years are:
Self-Reference PML4Ehas been randomized from the static value of
0x1ed. This consequently leads to
VArandomization of the base of paging structures(
PxE) and its entries
GDI objectshave been fixed
GdiSharedHandleTable(PEB)has been fixed
SGDT/SIDT instructionis fixed when
Low-ILprocesses cannot use
EnumDeviceDrivers()to leak kernel addresses
HAL Heap VAis now randomized
KASLRbut they usually rely on additional vulnerabilities in the form of information leaks.
DEPis designed to prevent code execution in non-executable portions of memory/data segment of memory. In other words,
DEPensures that no memory page is both writable and executable(
W^X) simultaneously. It was first introduced(fully) in
Windows 8, drivers now have a pool type known as
NonPagedPoolNxwhich essentially marks it as non-executable non-paged memory pool.
DEPis enforced on a per-page basis via a
Page Table Entry(PTE)control bit known as
Return Oriented Programming(ROP)payload in the kernel/re-using existing kernel code to execute our code, flipping the
NXbit in the
PTEor redirecting execution flow to a
SMEPprevents execution of
Kernel-Modecode residing in
User-Modepage. In other words, if code residing in
CPL-3is executed in context of
bugcheck(Code: 0xfc/ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORYor crash the system with a
BSOD/GSOD. It was first introduced(fully) in
LOCALkernel exploits where we somehow gain control over the
Ring 0, allocate memory in
User-Modeand jump to get kernel shellcode execution in
Ring 3which is not possible anymore with
SMEPis controlled by the
20th bitof the
CR4register and enforced at page level by the
User/Supervisor(U/S)bit in the
Page Table Entry(PTE).
Return Oriented Programming(ROP) chainin the kernel to flip the
KPP-protected) or using an arbitrary read/write primitive to flip the
Software SMEP, this software mitigation is designed to protect against leaking kernel memory via
Speculative Execution Variant 3or
Meltdown(CVE-2017-5754). It was first introduced in
Windows 10 RS4/1803.
Kernel Page Table Isolation(KPTI)based off of
KAISERand involves the separation of
Kernel-Modepage tables from
User-Modepage tables for each process. This means that most of the
System Spaceis not mapped in the
User-Modepage tables while the
Kernel-Modepage tables both of the mappings. The
Kernel-Modepage table base is stored in
User-Modepage table base is stored in
KVASis enforced on a per-process basis.
SystemKernelVaShadowInformationclass to check whether
KVASinclude leaking the base
PML4table and then using
ROP gadgetsto turn off the
NXbit in the
PML4Eof the shellcode
Device Guard(DG), it is an incredibly powerful and flexible second-generation application control/whitelisting solution for both
Kernel-Modecode. It was first introduced in
Windows 10 RS1/1607.
WDACallows creation and enforcement of configurable
Code Integrity(CI)policies that can either be for
Ring 0code. However, we are concerned with the
Ring 0portion only i.e. auditing/blocking conflicting device drivers via
Kernel Mode Code Integrity(KMCI) or Hypervisor-enforced Code Integrity(HVCI). It supports both
Auditmode(only log event with Event ID =
3076, do not actually block loading) and
Enforce/Blockmode(log and block it for real with Event ID =
3077). Note that there's also an additional event with Event ID =
3089that gives extended signer information of the device driver at fault.
WDACallows granular control over what
Kernel-Modecode should be allowed to load and as a result may effectively mitigate the threat from signed and vulnerable drivers.
CIpolicies start out as
XMLfiles and they are converted to a binary format before being deployed. It allows enforcement of multiple policies and they can even be signed to protect against possible tampering from a
Powershellone-liner to deploy an example
Microsoftthat only allows
Attestation Signedthird-party device drivers to load:
CIpolicy before deploying it since we do not want to be flooded by events from
Virtual Secure Mode(VSM), this is not a mitigation per se but rather a set of powerful features leveraging Microsoft's hypervisor called
Hyper-Vusing hardware virtualization capabilities of modern processors to enforce additional security boundaries. It was first introduced in
Windows 10 TS1/1507.
Second Level Address Translation(SLAT)support -
Virtualization Extensionssupport -
Mode Based Execution Control(MBEC)or
Guest Mode Execute Trap(GMET)respectively
VBSsecurity, the following additional requirements should be satisfied:
Input Output Memory Management Unit(IOMMU)support -
Trusted Platform Module(TPM)
VBS(only base features like
HyperGuard) may be enabled by executing the following command from an admin prompt and rebooting:
VBSsplits the trust into two separate partitions/VMs(also called
Virtual Trust Level(VTL)):
VTL-0 Ring 0(ntoskrnl.exe)- The assume-compromised VM which runs the normal kernel
VTL-1 Ring 0(securekernel.exe)- The protected VM also called
Secure Kernel Mode(SKM)which runs a minimalized and secure kernel,
VTL-1has full control over
VTL-0and is responsible for maintaining its security. Furthermore, access to
VTL-1pages by a lower
VTL-0can be controlled via
SLATand is thus protected from compromise even if the normal kernel is compromised.
Isolated User Mode(IUM)or
VTL-1 Ring 3where only special Microsoft-signed processes called
LsaIso.exe) can run and the normal
Ring 3where all other
User-Modecode is run i.e. in
VTL-0 Ring 3.
Secure Kernel Patch Guard(SKPG),
HGis designed to detect any changes to critical kernel structures/
bugcheck(Code: 0x18C/HYPERGUARD_VIOLATION)if any inconsistency is detected much like its predecessor
PGin the sense that
HGcan detect the changes in real-time and crash the system as soon as any tampering occurs unlike the former which is polled and adversaries may get away with a burst tampering tactic.
VTL-1 Ring 0unlike
PGand sets up
Secure Interceptsthat trigger when certain events occur in the kernel. As a result of this design, it is also better resilient to attacks.
Model Specific Register(MSR)s,
IDTRetc. This implies that we can no longer disable
SMEPvia flipping 20th bit of
CR4register nor can we use exposed
__writemsrin vulnerable drivers to achieve function pointer overwrite primitive via
MSR_LSTARand get code execution.
Global Descriptor Table(GDT)
Interrupt Descriptor Table(IDT)
PTEmanipulation to bypass
SMEPinstead of tampering with
Memory Integrity, this is one of the core components of
VBSthat is designed to enhance
CIvia hypervisor and enforce
W ^ Xin the kernel to keep in check what a malicious device driver can do even after it is allowed to load. It is also utilized by
Custom Code Integrity(CCI)when hardware support is available for strong code guarantees.
HVCImay be turned on by executing the following command from an admin prompt and rebooting:
HVCIprovides the following security guarantees:
CIis actually enforced by the hypervisor(
skci.dll in Secure Kernel/VTL-1 Ring 0). This implies that it wouldn't be possible to load unsigned drivers even if we have already compromised the kernel(
VTL-0 Ring 0) i.e. patching
+Xat the same time. This implies that
Ring 0code once loaded cannot be modified and dynamically loaded code(
Ring 0shellcode) is not allowed either since kernel cannot allocate
PTEcontrol bits in the kernel to bypass
MBEC/GMET(or it's software emulation called
Restricted User Mode(RUM)if hardware support is not available) which are additional "secured" control bits maintained by
VTL-1 Ring 0.
HVCIinclude using code-reuse techniques such as
ROP/COP/JOPpayloads in the kernel, resorting to data corruption attacks, finding leftover
+RWXpages from the early boot phase or compromising either
Ring -1/Hypervisordirectly or via
Forward-Edge Control Flow Integrity(CFI)implementation in the kernel that protects against indirect function calls by validating against a
calltargets which are additionally protected from modification by the hypervisor/
KCFGis another particularly effective mitigation along with
HVCIthat mitigates against overwriting function pointer and executing it to obtain code execution.
nt!MiInitializeKernelCfgis used to initialize the
CFG bitmapfor the kernel and
nt!_guard_dispatch_icallis used to validate
calltargets via the bitmap.
Import Address Table(IAT)entry with the address of shellcode(
KCFGdoes not take
calltargets into consideration.
VBSmitigations that is designed to enforce immutability of
+R0pages of kernel memory via
SLATand protect it from data corruption attacks.
Static KDPis aimed to prevent data corruption attacks commonly used to elevate privileges, kill defences, disable
PPLby tampering with the
nt!_EPROCESSstructure etc. with a
Ring 0R/W primitive. With
PSPdrivers can protect a section of their image using
MmProtectDriverSectionwhich would make it
EPTentries thus enforcing immutability from
VTL-0 Ring 0.
Dynamic KDPis aimed at letting device drivers allocate a secure
+ROmemory pool using
Intelfor enforcing both
Backward-Edge CFI. Support for
CEThas been added in
Windows 10 20H1/2004.
Indirect Branch Tracking(IBT)to protect against
Hardware-enforced Shadow Stackto protect against
CFGalready protects against
Forward-Edgecases, Microsoft has decided to rely on that(plus
Extended Flow Guard(XFG)) and discard
CFGdoes not provide any protection against
Backward-Edgecases which is where
CETcomes in and mitigates corruption of return addresses on the stack.
Hardware Shadow Stack, a
Control Flow Protection Faultis generated.
CETessentially takes away our ability to use
ROPto get code execution.