Missing registry hooks
jgajek opened this issue · 9 comments
RegCopyTree
RegCreateKeyTransacted
RegDeleteKeyTransacted
RegDeleteTree
RegGetValue
They are not supported on Windows XP, so perhaps that is why they were missed.
I don't know that we really need all these, it might be better to just do NtCreateKeyTransacted/NtOpenKeyTransacted/NtOpenKeyTransactedEx unless these wrappers involve a ton of API logs
-Brad
Based on some testing (https://github.com/jgajek/RegMangler), it seems to me the following would make sense:
- Add hook for RegDeleteKeyTransacted. NtDeleteKey is called once the transaction is committed, but there is currently no information about the key that was deleted in Cuckoo's API log.
- Add hooks for NtCreateKeyTransacted/NtOpenKeyTransacted/NtOpenKeyTransactedEx. Adding the higher-level hooks for RegCreateKeyTransacted and RegOpenKeyTransacted would be optional, but might be desirable for consistency with the other higher-level registry hooks.
- RegCopyTree and RegDeleteTree are just wrappers around RegEnumKeyEx/RegSetValueEx/etc., but hooking them could eliminate a lot of noise in the API log when large key hierarchies are copied/deleted.
Incidentally, I suspect that the current method of faking the absence of certain registry keys to foil VM detection is not very effective -- but I will look into that separately.
I should be able to fix 1) without adding the extra hook, would be useful to have anyway.
It's certainly not comprehensive, especially when you're specifically targeting it, but I would say it's effective :) There are a million ways to detect Cuckoo even without any API usage, there's no way to comprehensively do anything about it and still get the same level of information out of the majority of malware.
-Brad
I'm not too worried about detecting Cuckoo specifically, since I don't expect most malware writers are trying to evade manual sandboxing. They are trying to evade automated sandboxing from off-the-shelf products, and they would rather use generic detection methods that are likely to work in many different scenarios. Looking for VM artifacts in the registry would qualify.
Some ways that the current registry fakery in the RegOpenKeyEx hook can be trivially bypassed:
- Use RegOpenKeyEx requesting full write access and look for the ERROR_ACCESS_DENIED result.
- Use RegCreateKeyEx and check the disposition. If new key was created or ERROR_ACCESS_DENIED, key doesn't exist. Otherwise, key exists.
- Use RegOpenKeyEx/RegEnumKeyEx on the parent subkey, and iterate through the subkeys until the right one is found.
Not to mention using the lower level Nt* API calls.
Or removing the hook and doing the call, or a million other things, yes ;) Who else is doing the hiding exactly the same as us, other than the "inspired"? If someone does what you suggest, it's an easy way to know they're targeting us specifically. Some of the changes are intentionally gimped for that very reason.
-Brad
Except that the ones I described are easy, while removing the hook is something 99% of malware writers won't bother with (just for the sake of checking the registry).
Well, except that I've seen malware removing hooks frequently, and none doing what you say (or the million other things they could do). You can't avoid the cat and mouse game with userland hooks, but there's not much sense in going out of the way to catch mice that don't exist yet. If someone actually starts using those techniques, it's something that a signature can easily be created for, and they'd still hit existing signatures regardless.
-Brad
That said, if you have a PR to fix any of those issues, I of course won't refuse it.
-Brad