What's the deal with infamous NtQuerySystemInformation? Part 1

This is not any new topic; though it's undocumented and private NT API, NtQuerySystemInformation is quite popular among malware developers & analysts, exploit writers, security tools developers, rootkit writers etc. Microsoft recently has vaguely documented this API and also has suggested to not to use this API since it can be altered or obsoleted in future. They give such suggestions every time when they documents such APIs, simply, they don't want your application to break if they make changes in such private APIs. In addition, they're already providing well documented WIN32 APIs which wraps around these private NT APIs. But why some group of people still prefers to use such undocumented APIs such as NtQuerySystemInformation?

Before we understand NtQuerySystemInformation, lets briefly discuss about the windows and NT APIs. If we talk about the Windows it's divided into 2 parts User & Kernel land. And without any doubts all the NT APIs including NtQuerySystemInformation lives in the kernel land, which means user land processes cannot make a direct call to these APIs. There must be the way for the user land processes to call these NT APIs right? or else why would somebody be so interested in using such APIs. Indeed, here comes the syscall and SSDT (System Service Descriptor Table) to make this user/kernel communication into play. (We'll talk more on syscall, SSDT and other components in future but not in this post).

Additionally, another important point to mention here is that windows is an object based (not completely) operating system. Most resources in windows are treated as object such as process, thread, file, event, etc. Also, these objects has its own object type and its own set of data type in the Kernel. For instance if we open the notepad process it's an instance of Process Object Type. In addition to that, NT Executive subsystems are implemented to create or manage these objects. Though, NT Executive subsystems are implemented to manage specific object types and many executive subsystems are dependent to Object Manager as well. I couldn't find any better image than this on the internet????. For instance if you look at the below picture Ps is executive subsystem for managing process and thread object, Ob for managing object type (don't get confused, object executive systems maintains it's own object type as well), Mm for managing memory etc.

Let's get straight to the point: NtQuerySystemInformation not only gathers information by querying kernel objects but also accesses various global kernel structures to retrieve data. Apparently, gathering information from objects such as Process and Thread makes it more attractive. Additionally, it captures information on all processes and threads currently running and provides extensive details such as object addresses (not available in the latest Windows versions), process IDs, image names, thread-related data, handle information, and more. The information that can be retrieved using NtQuerySystemInformation are beyond process and thread objects. NtQuerySystemInformation implements huge switch case block where giving appropriate SystemInformationClass can retrieves the required information.

The list of SystemInformationClass is massive, here are couple of classes that are documented but there are many which are not listed here. NtQuerySystemInformation gives wealth of information which can be very useful to keep track of lots of system information. Nevertheless, these wealth of information could be leveraged for the attack as well. I'll pause the article here, and there will be subsequent parts to follow in the series.

Some of the details are vaguely described in this article because those were not in the scope, for clearing further doubts you can continue through the below references or dm me in the linked in:

https://www.itprotoday.com/compute-engines/inside-nts-object-manager#close-modal

https://www.matteomalvica.com/minutes/windows_kernel/

https://en.wikipedia.org/wiki/Ntoskrnl.exe