What about PsSetLoadImageNotifyRoutine ?

[d-cheholia]

Hello!
I apologize at once for the perhaps naive questions.

I am studying your project and found several things:

1. When PLOAD_IMAGE_NOTIFY_ROUTINE is called, I can see that my _FILE_OBJECT parameters are:

  +0x04a ReadAccess : 0x1 ''
   +0x04b WriteAccess : 0x1 '' <----
   +0x04c DeleteAccess : 0 ''
   +0x04d SharedRead : 0x1 ''
   +0x04e SharedWrite : 0x1 ''
   +0x04f SharedDelete : 0x1 ''

You can see that WriteAccess is non-zero. In the examples from your documentation I see that WriteAccess is 0.

My example of running a program:

ProcessHerpaderping.exe X.exe Y.exe Z.exe

Am I doing something wrong?
I looked at your code and I don't think there can be WriteAccess == 0

2. I also noticed that when reading the PE header at the ImageBase address (I can get this field in the callback)
   I am reading the original PE header (not the replaced file).
   So I can compare what's currently on the disk with what's at the ImageBase address.
   This will be different when I using your current project.

My question is, are these two items proof that something went wrong with the process? (If we assume that "normal" processes for us are read-only processes)

Thank you. ❤

[jxy-s]

Indeed, those are good indicators that something wonky is happening 😄. That said, you might observe false positives on those indicators alone.

Yes, the same can be observed in both image load and process create. There are challenges with respect to preforming inspection during the image load notify routine. Security software has tended to avoid that path due to these challenges. Although it is possible to do so with some careful handling and some security software does. The state of the thread/process is in when the callback is invoked has changed over the years. And for which images it is invoked has also changed. More info in the remarks section of the MSDN documentation. And see SEC_IMAGE_NO_EXECUTE. There is also no trivial/documented way to deny the image load from occurring in that path. In contrast, the process notify routine does expose a documented way to deny process creation. For these reasons most defensive techniques against this type of evasion occurs during inspection at the process creation routine. I'll also add there are some mini-filter callbacks for doing inspection during section creation but struggle with similar caveats/drawbacks as the image load notification (see: IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION).

I also recommend giving this blog post from Microsoft a read. They outline a few indicators that I was unfamiliar with during my initial research.

[d-cheholia]

Thank you!