NT API Tracking

What method does Microsoft make available to a kernel developer to track the NT api calls that a user process may call? I’m familiar with ways to do this in user-land, but none of these methods are clean. I also came across an OSR tool that appears to have done something similar called IRPTracker, but it is obviously no longer supported on later versions of Windows. It stated that “IrpTracker now includes the ability to track Native API calls that can result in IRPs being sent to a device stack.”.

To get to the ultimate root of my question, I’m actually wondering how AV/Endpoint software companies are able to track things like “Process A spawns -> makes call to OpenProcess -> makes call to VirtualAllocEx with PAGE_EXECUTE_READWRITE flags -> makes call to WriteProcessMemory” and now flags Process A as suspicious since it appears to be performing some type of process injection.

The only information I see regarding filtering revolves around file system minifilters which would be great I assume for tracking file IO (file creation, deletion, etc), but what other methods exist for situations like the one I describe above?

I know there is ObRegisterCallbacks to track process and thread handles and the requested access rights for the associated handle, but that doesn’t give any more context beyond Process A attempted to acquire handle to Process B and attempted to do so with a handle that allows VM_OPERATION|VM_READ|VM_WRITE.

OpenProcess is tracked by an object callback registered with ObRegisterCallbacks . For the case described above, ObjectPreCallback routine is enough to mark a calling process as being verified if the process requested PROCESS_VM_OPERATIONS | PROCESS_VM_WRITE access rights.

VirtualAllocEx and WriteProcessMemory can be “tracked” only with user mode hooks. In the past this was kernel mode hooks.

[quote]OpenProcess is tracked by an object callback registered with ObRegisterCallbacks
. For the case described above, ObjectPreCallback routine is enough to mark a
calling process as being verified if the process requested PROCESS_VM_OPERATIONS
| PROCESS_VM_WRITE access rights.

VirtualAllocEx and WriteProcessMemory can be “tracked” only with user mode
hooks. In the past this was kernel mode hooks.[/quote]

That’s generally what I had assumed. Although, I imagined maybe there was another way from the kernel. What happened when Microsoft implemented kernel patch protection and everyone had to stop using SSDT, IDT, SYSENTER/SYSCALL, and other types of hooks for security software?

They switched to user mode hooks or to a hypervisor , the latter allows to trap into sysenter.

User mode hooks can be implemented from a driver. Seven years ago I designed and implemented a driver to set hooks from kernel mode. User mode hooks require some sort of protection from being tampered with by a user process which makes the task tricky. NtProtectVirtualMemory was not exported by a kernel so the driver did some disassembling to locate it.

Though not very useful, ETW offers a messy and complicated way that will
allow some sort of system call monitoring using the
EVENT_TRACE_FLAG_SYSTEMCALL flag. Unfortunately, this does not give
parameters for the function calls. And when the data comes in, it’s too late
to take any action. It will take some effort to download the right symbols
for your version of NTOS to resolve kernel addresses to function names.

//Daniel