Question : API covered by capemon about capemon HOT 8 CLOSED

A subset. The APIs are listed in hooks.h: https://github.com/kevoreilly/capemon/blob/capemon/hooks.h

from capemon.

Out of curiosity : why this design choice? There is any rationale for not log all of them?

from capemon.

The number of exported functions in ntdll alone is > 2000, not far off 2000 in kernelbase, then there is kernel32. That's not even getting started on networking APIs. The total number in the Windows API? I am guessing many tens if not hundreds of thousands of functions. To hook them all would require work in writing hooks, which can also be technically challenging. The output from all these hooks would be massive so would slow down processing and mean interesting stuff in the logs would be drowned out by uninteresting info. Then there is the increased risk of bugs... All lead to the question of why one would want to hook everything?

from capemon.

Thank you for the reply :)
I am mainly referring to the following syscalls : https://github.com/j00ru/windows-syscalls
Probably there was a misunderstanding, I used API and should have used syscalls !

from capemon.

I see what you mean - capemon's hooks are of course not true syscall hooks. But assuming each true syscall is wrapped by a function exported by ntdll, then it would be possible to hook those functions. I think the reason this hasn't been done is just that some syscalls aren't that useful from the perspective of malware analysis.

As an aside I have been experimenting with 'nirvana' hooks in win10 which is a true syscall hooking mechanism - maybe one day I'll publish this if it's reliable enough.

from capemon.

What do you mean not true syscall hooks?

Do you mean this hooking mechanism https://infocondb.org/con/recon/recon-2015/hooking-nirvana-stealthy-instrumentation-techniques-for-windows-10 ?

from capemon.

Not sure anyway, sempahore syscalls may be interesting as well for example...

from capemon.

In general, I just mean a technique that hooks the actual syscall mechanism, so each time the syscall instruction is executed it is hooked. In capemon it's a user-mode hook of a user-mode wrapper for a syscall. So, for example, direct syscalls to NtAllocateVirtualMemory will not be captured with capemon hook on the exported function from ntdll of the same name.

from capemon.