The Native API is a lower-level interface for interacting with Windows that is rarely used by nonmalicious programs but is popular among malware writers. Calling functions in the Native API bypasses the normal Windows API.
When you call a function in the Windows API, the function usually does not perform the requested action directly, because most of the important data structures are stored in the kernel, which is not accessible by code outside the kernel (user-mode code). Microsoft has created a multistep process by which user applications can achieve the necessary functionality. Figure 7-3 illustrates how this works for most API calls.
User applications are given access to user APIs such as kernel32.dll and other DLLs, which call ntdll.dll, a special DLL that manages interactions between user space and the kernel. The processor then switches to kernel mode and executes a function in the kernel, normally located in ntoskrnl.exe. The process is convoluted, but the separation between the kernel and user APIs allows Microsoft to change the kernel without affecting existing applications.
The ntdll functions use APIs and structures just like the ones used in the kernel. These functions make up the Native API. Programs are not supposed to call the Native API, but nothing in the OS prevents them from doing so. Although Microsoft does not provide thorough documentation on the Native API, there are websites and books that document these functions. The best reference is Windows NT/2000 Native API Reference by Gary Nebbett (Sams, 2000), although it is quite old. Online resources such as http://undocumented.ntinternals.net/ can provide more recent information.
Calling the Native API directly is attractive for malware writers because it allows them to do things that might not otherwise be possible. There is a lot of functionality that is not exposed in the regular Windows API, but can be accomplished by calling the Native API directly.
Additionally, calling the Native API directly is sometimes stealthier. Many antivirus and host-protection products monitor the system calls made by a process. If the process calls the Native API function directly, it may be able to evade a poorly designed security product.
Figure 7-4 shows a diagram of a system call
with a poorly designed security program monitoring calls to kernel32.dll. In
order to bypass the security program, some hypothetical malware uses the Native API. Instead of
calling the Windows functions ReadFile and WriteFile, this malware calls the functions NtReadFile and NtWriteFile. These functions are in
ntdll.dll and are not monitored by the security program. A well-designed
security program will monitor calls at all levels, including the kernel, to ensure that this tactic
doesn’t work.
There are a series of Native API calls that can be used to get information about the system,
processes, threads, handles, and other items. These include NtQuerySystemInformation, NtQueryInformationProcess,
NtQueryInformationThread, NtQueryInformationFile, and NtQueryInformationKey.
These calls provide much more detailed information than any available Win32 calls, and some of these
functions allow you to set fine-grained attributes for files, processes, threads, and so on.
Another Native API function that is popular with malware authors is NtContinue. This function is used to return from an exception, and it is
meant to transfer execution back to the main thread of a program after an exception has been
handled. However, the location to return to is specified in the exception context, and it can be
changed. Malware often uses this function to transfer execution in complicated ways, in order to
confuse an analyst and make a program more difficult to debug.
Note
We covered several functions that start with the prefix Nt. In some instances, such as in the export tables of ntdll.dll,
the same function can have either the Nt prefix or the Zw
prefix. For example, there is an NtReadFile
function and a ZwReadFile function. In the
user space, these functions behave in exactly the same way, and usually call the exact same code.
There are sometimes minor differences when called from kernel mode, but those differences can be
safely ignored by the malware analyst.
Native applications are applications that do not use the Win32 subsystem and issue calls to the Native API only. Such applications are rare for malware, but are almost nonexistent for nonmalicious software, and so a native application is likely malicious. The subsystem in the PE header indicates if a program is a native application.