brad-sp
commented
9 years ago Are you sure you actually tested with my version? Not only do I not spew out repeated logs for duplicated APIs (they're combined at the cuckoomon level), but I've been aware of that IsDebuggerPresent trick for a while, and it has various forms of handling in cuckoomon. For one, we only ever bother logging the first 20 calls to the API, but we'll still end up with the overhead of the hook itself. Their code for the trick has been constant for a while, so I actually patch their code at runtime once we hit 1000 calls so that their loop actually only iterates 1000 times instead of millions of times. I did have some code previously that would simply remove the IsDebuggerPresent hook at runtime once the log limit was reached, but I removed that for some reason I forget now. If you have a hash of a particular sample it's not handling, just give me it and I'll fix it up.
Thanks, -Brad
MerX1030
Hi Brad, Thanks for this modified version of cuckoomon. I just want to raise an issue I found while trying it out with some UPATRE malware samples. Some samples repeatedly used the IsDebuggerPresent API almost a billion times before proceeding to its actual routine. This, of course, caused the BSON log to blow up in size to the point where it cannot be processed by behavior.py. For this, I am thinking that we might want to add the handling of repeated APIs to cuckoomon instead of behavior.py. That is, having a "repeated" entry in the BSON log rather than treating each API call a single entry even if they are repeated consecutively. Here's an example of an UPATRE sample that behaves as I said above. MD5: f32f43c45f3990b5fef118b7572eb6d7 SHA1: ff455fea9a63185920762a5fc2b081ee7fbe579e SHA256: 0c239ab0caca16c2bd3f845534b66631c483816f593a437f1376ae93e11897d9