{"id":4228,"date":"2025-01-15T09:44:29","date_gmt":"2025-01-15T08:44:29","guid":{"rendered":"https:\/\/security.humanativaspa.it\/?p=4228"},"modified":"2025-09-29T10:54:22","modified_gmt":"2025-09-29T10:54:22","slug":"from-arbitrary-pointer-dereference-to-arbitrary-read-write-in-latest-windows-11","status":"publish","type":"post","link":"https:\/\/hnsecurity.it\/it\/blog\/from-arbitrary-pointer-dereference-to-arbitrary-read-write-in-latest-windows-11\/","title":{"rendered":"From arbitrary pointer dereference to arbitrary read\/write in latest Windows 11"},"content":{"rendered":"

In the last part<\/a> of this Windows kernel exploitation<\/strong> series<\/a>, we successfully exploited an arbitrary pointer dereference, bypassing SMEP and KVA Shadowing to finally obtain arbitrary code execution in kernel mode<\/strong>.<\/p>\r\n

However, on the latest Windows 11 some security features<\/strong> part of Virtualization-Based Security<\/a> are enabled by default and are going to mitigate<\/strong> our exploit<\/a>. The security features that we will have to face are Hypervisor-protected code integrity<\/a>, a.k.a HVCI or Memory integrity, and kernel Control Flow Guard<\/a> (kCFG).
In this article we will briefly examine what VBS, HVCI, and kCFG are and modify our original exploit code in a way that allows us to turn<\/strong> our arbitrary pointer dereference <\/strong>into\u00a0an arbitrary read\/write primitive<\/strong>, that in turn allows us to perform data-only attacks, such as elevating token privileges<\/strong>, swapping token addresses<\/strong>, disabling EDR kernel callbacks<\/strong> or setting\/unsetting PPL features of an arbitrary process<\/strong>, just to mention a few possibilities.<\/p>\r\n

Note: I started working on this article before the release of Windows 11 24h2. Windows 11 24h2 removed several kernel address leak vulnerabilities (still available if you have the SeDebugPrivilege, that is if you are an Administrator) that are leveraged in this article.<\/em><\/p>\r\n

Setting up the environment<\/h2>\r\n

If you want to follow on your own, you should follow the instructions below to create a Windows 11 VM with VBS enabled<\/strong> on VMware. First, in the Settings<\/em> of your host machine look for Core isolation<\/em> and disable Memory integrity<\/em>. After that, in VMware go into the Virtual Machine Settings > Options > Advanced<\/em> menu and check Enable VBS Support<\/em>.<\/p>\r\n

\"\"
Enabling VBS support in VMWare<\/figcaption><\/figure>\r\n

Notice this will enable also Secure Boot<\/em>. If Secure Boot is enabled you won’t be able to do kernel debugging<\/strong>. To disable it, while keeping VBS enabled, navigate to the folder of your VM and open the .vmx file<\/strong> in a text editor. Change the attribute uefi.secureBoot.enabled<\/em> to FALSE<\/strong>.<\/p>\r\n

\"\"
Disabling Secure Boot<\/figcaption><\/figure>\r\n

Now, run your VM and inside it open Settings<\/em>, navigate to Core isolation<\/em> and set Memory integrity<\/em> to enabled<\/strong>.<\/p>\r\n

\"\"
Enabling HVCI in the VM<\/figcaption><\/figure>\r\n

Restart the VM. Now your VM should have HVCI and kCFG enabled but Secure Boot disabled<\/strong>, allowing you to setup kernel debugging<\/a>.<\/p>\r\n

VBS, HVCI, and kCFG<\/h2>\r\n

Let’s first understand what VBS, HVCI, and kCFG are and what are their implications when it comes to exploit development. The following blog posts authored by Connor McGarr are very good to shed light on this topic:<\/p>\r\n