Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Windows Debugging and Exploiting Part 4: NTQuerySystemInformation


Hello again! We are back with more Windows internals and it's time to get real. We already covered how to set up an environmentWinDBG basics and discussed WinDBG Time Travel DebuggingIn this part 4 of my blog series, I'll briefly describe an internal API that is widely used to leak kernel information for most of the Windows LPE (Local Privilege Escalation) exploits. We will talk about the function NTQuerySystemInformation.

NTQuerySystemInformation & System Information Classes

The function NTQuerySystemInformation is implemented on NTDLL. And as a kernel API, it is always being updated during the Windows versions with no short notice. As mentioned, this is a private function, so not officially documented by Microsoft. It has been used since early days from Windows NT-family systems with different syscall IDs as you can see on the table below []. 



Windows XP to Windows 7

Windows 8 & 2012  SP0

Windows 8.1 & 2012 R2

Windows 10







The function basically retrieves specific information from the environment and its structure is very simple:


      SYSTEM_INFORMATION_CLASS   SystemInformationClass,
      PVOID   SystemInformation,
      ULONG   SystemInformationLength,
      PULONG  ReturnLength);


In the first argument, SYSTEM_INFORMATION_CLASS (ULONG) we will set which information we want to retrieve. These classes are named Windows System Information Classes and are defined in winternl.h.

There are numerous data that can be retrieved using these classes along with the function. Information regarding the system, the processes, objects and others.

Below, the list of some classes that could be used:


  • late 5.0 starts with Windows 2000 SP4; 
  • late 5.1 starts with Windows XP SP2; 
  • very late 5.1 starts with Windows XP SP3; 
  • late 5.2 starts with Windows Server 2003 SP1; 
  • late 6.0 starts with Windows Vista SP1; 
  • late 6.1 starts with Windows 7 SP1.


Numeric Value 

Symbolic Name 




3.10 and higher 



3.10 and higher 



3.10 and higher 



3.10 and higher 



3.10 and higher 



3.10 and higher 



3.10 and higher 



3.10 and higher 






5.1 and higher 



5.1 and higher 



late 5.1 only 


5.2 and higher 



5.2 and higher 



5.2 and higher 






6.0 and higher 



6.0 and higher 



6.0 and higher 



6.0 and higher 



6.0 and higher 



6.0 and higher 



6.0 and higher 



6.0 and higher 



6.0 and higher 






10.0 and higher 



10.0 and higher 



10.0 and higher 



10.0 and higher 



10.0 and higher 



10.0 and higher 



10.0 and higher 






1803 and higher 



1803 and higher 



1803 and higher 



1803 and higher 



1803 and higher




There are multiple information classes that we could use and part of the process, it is to discover which one will be useful in our exploitation method. If we need to discover an EPROCESS or a driver base address, for each one there is a specific class that we could implement. For every class, we will need to define its structures. Some samples:

SystemModuleInformation (0x0b)
typedef struct SYSTEM_MODULE {
        PVOID  Reserved1;
        PVOID  Reserved2;
        PVOID  ImageBase;
        ULONG  ImageSize;
        ULONG  Flags;
        USHORT Index;
        USHORT NameLength;
        USHORT LoadCount;
        USHORT PathLength;
        CHAR   ImageName[256];

       ULONG                ModulesCount;
       SYSTEM_MODULE        Modules[0];

At SYSTEM_MODULE_INFORMATION->ModulesCount[i].ImageBase, you will find the base address of any kernel module. That could be used to calculate the HalDispatchTable for example, using the kernel base address. This table contains function pointers that could be overwritten during exploitation.

SystemHandleInformation (0x10)
typedef struct SYSTEM_HANDLE {
        ULONG ProcessId;
        UCHAR ObjectTypeNumber;
        UCHAR Flags;
        USHORT Handle;
        PVOID Object;
        ACCESS_MASK GrantedAccess;

        ULONG HandleCount;
        SYSTEM_HANDLE Handles[1];

In this case, at SYSTEM_HANDLE_INFORMATION->Handles[i].Object you may find the address of the object in kernel space from a specific handle that could be filtered by the process ID for example (See Proof-Of-Concept).

These are only two examples of information classes that can be utilized on an exploitation, however there are much more useful classes like SystemExtendedHandledInformation, SystemLockInformation, SystemExtendedProcessInformation, etc.

It is valid to note, that all these structures are undocumented and thanks to the great work from researchers like Mateusz Jurcyzk, Alex Ionescu and others we now have this accurately described.

More information about information classes:


I've developed a simple code to retrieve the open handle addresses from the running process using SystemHandleInformation. I tried to be as simple as possible for your education. So you may want to explore this and others information classes for discovering their functionality and identify what else can be done.

NTQuerySystemInformation() PoC -- Bruno Oliveira @mphx2
Address: 0xFFFFC90441603180, Object Type: 37, Handle: 4
Address: 0xFFFFC9043F8B7E60, Object Type: 16, Handle: 8
Address: 0xFFFFC9043F8B7F60, Object Type: 16, Handle: c
Address: 0xFFFFC90444662D50, Object Type: 36, Handle:10
Address: 0xFFFFC90440581C40, Object Type: 35, Handle:14
Address: 0xFFFFC90440096D70, Object Type: 30, Handle:18
Address: 0xFFFFC90446352290, Object Type: 21, Handle:1c
Address: 0xFFFFC904446633D0, Object Type: 36, Handle:20
Address: 0xFFFFC90446353060, Object Type: 21, Handle:24
Address: 0xFFFFC90444662EF0, Object Type: 36, Handle:28
Address: 0xFFFFC9043FD7A0F0, Object Type: 50, Handle:2c
Address: 0xFFFFC9043FDA1450, Object Type: 50, Handle:30
Address: 0xFFFFC9043FDA0730, Object Type: 50, Handle:34
Address: 0xFFFFA204CB57A840, Object Type: 3, Handle: 38
Address: 0xFFFFC9043F8B9EE0, Object Type: 16, Handle:3c
Address: 0xFFFFC9043F8C0B60, Object Type: 16, Handle:40
Address: 0xFFFFC90446A4EBD0, Object Type: 37, Handle:44
Address: 0xFFFFC90446A4D140, Object Type: 37, Handle:48
Address: 0xFFFFC9043FDA0E30, Object Type: 50, Handle:4c
Address: 0xFFFFC90440074710, Object Type: 37, Handle:50
Address: 0xFFFFC90440073C20, Object Type: 37, Handle:54
Address: 0xFFFFC90440073C20, Object Type: 37, Handle:58
Address: 0xFFFFC9043ED774F0, Object Type: 46, Handle:5c
Address: 0xFFFFC9043FDA18B0, Object Type: 50, Handle:60
Address: 0xFFFFC9043FDA1A70, Object Type: 50, Handle:64
Address: 0xFFFFC9043FDA0810, Object Type: 50, Handle:68
Address: 0xFFFFC9043FDA2B00, Object Type: 35, Handle:6c
Address: 0xFFFFC90445354740, Object Type: 30, Handle:70
Address: 0xFFFFC904463602C0, Object Type: 21, Handle:74
Address: 0xFFFFC90444663090, Object Type: 36, Handle:78
Address: 0xFFFFC904463603D0, Object Type: 21, Handle:7c
Address: 0xFFFFC90444662460, Object Type: 36, Handle:80
Address: 0xFFFFA204E5D57670, Object Type: 44, Handle:84
Address: 0xFFFFA204E5D83E70, Object Type: 44, Handle:8c


PoC source-code available on:

Checking the address on WinDBG:

lkd> !object 0xFFFFC90441603180
Object: ffffc90441603180 Type: (ffffc904384f8380) File
    ObjectHeader: ffffc90441603150 (new version)
    HandleCount: 2 PointerCount: 65536
    Directory Object: 00000000 Name: \Reference {ConDrv}



This information leak is extremely useful for bypassing the kernel randomization KASLR (Kernel Address Space Layout Randomization). Supposing we already have control in kernel with some write-what-where exploitation primitive, we need to know where exactly we should modify in order to elevate our privileges. By utilizing this API, we are now able to locate multiple objects on the kernel space and calculate offsets for any possible other that we might need. What makes this function very special, is the fact that it can be called by an unprivileged user. In other words, you don't need to be SYSTEM to request internal information from the OS. There are multiple exploits that take advantage of this fact for running. Browsing LPE exploits for Windows is easy to identify. Feel free to do some analysis on your own.



In 2017 and 2018, Google Project Zero found vulnerabilities on NTQuerySystemInformation function itself.

The vulnerabilities occur in some specific information classes and disclose more than they are supposed to do. The irony, a function that is well-known used as a resource for exploit developers, being vulnerable ¯\_(ツ)_/¯.



Once more I tried to bring some information to set a basic knowledge while discussing exploitation on Windows systems. At this time, I explained a little bit about this important function for leaking kernel space information using any unprivileged user, such data is fundamental for most of the LPE exploits, being inevitable to discuss while explaining the topic. 

Hopefully, we will start to get things more excited in each post! Again, if there is any doubt or anything that you want me to know, ping me and happy hacking!

Latest SpiderLabs Blogs

Trustwave SpiderLabs: Insights and Solutions to Defend Educational Institutions Against Cyber Threats

Security teams responsible for defending educational institutions at higher education and primary school levels often find themselves facing harsh lessons from threat actors who exploit the numerous...

Read More

Breakdown of Tycoon Phishing-as-a-Service System

Just weeks after Trustwave SpiderLabs reported on the Greatness phishing-as-a-service (PaaS) framework, SpiderLabs’ Email Security team is tracking another PaaS called Tycoon Group.

Read More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising

During an Advanced Continual Threat Hunt (ACTH) investigation that took place in early December 2023, Trustwave SpiderLabs discovered Ov3r_Stealer, an infostealer distributed using Facebook...

Read More