x86 DLL detonation issues in Win10 about capemon HOT 10 CLOSED

Firstly I want to apologise for not looking more closely at the sample hashes you supplied, I have had another look and can now see that it was only the second hash that actually detonated ok for me, the third, fourth and fifth all crashed with wermgr.exe being spawned. (The first hash I couldn't get hold of).

Although all four were detected, so I think I just saw the detections, clicked on one, saw it looked fine and concluded they were all fine! Sorry about that! As ever all I really need is to be able to reproduce the exception at home and I can dig into it... So here it is actually quite interesting and it began to ring some bells as I have in fact seen this before...

Anyway, let's just pick an example which I looked into this morning, hash number 4 b7e432ebcbff1842f6639e6cc8ba2cca6a7ebe6374d40fda88b9de0fa920b225.

I began by using log-exceptions=1 in order to see the exception in the behavior log:

So an access violation which is occuring for this run at 0x75f0068.

A quick check for where this memory lies shows it's memory the packer allocates to unpack and execute its payload

So this made me think the problem here might actually not be with cape, but with the packer...

I was able to detonate its unpacked payload without exception on Win10

On Windows 7 it detonates fine

It crashes on triage https://tria.ge/220927-vp9znsead8/behavioral2

And it crashes in my Win10 vm outside of cape

So I actually think here it's a dodgy packer that is not compatible with Win10 rather than an issue with capemon.

One final check I did to really convince myself was to see if the exception could be seen with no api hooks... well no api hooks would mean no RtlDispatchException but I have created a hookset which contains only this and NtContinue as these are all that are needed for the debugger to function... zerohook

so perhaps you can try this yourself - log exceptions but disable (almost) all hooks with:
log-exceptions=1,zerohook=1

only < 10 seconds needed

The same can be seen with the other two hashes that crash (f96a79f844cdcd2c31932452a6bf9aac7f04731f8eb72f2e1fa3f00e24d6aa98, 907b3cc7168067b2e2c4db2318cc9fa2ebc58963571c92665b447c447b6cc3a1)

from capemon.

Closing the issue since it was not a problem specifically with Capemon but rather a problem with the samples. Debugging documentation, logs and procedure are probably to be updated/upgraded to make it more obvious to end users when an error is coming from samples instead of Capemon. Will try to document what I learned from this raised issue for others to benefit in the future. Thanks !

from capemon.

Other than the first hash which is not on Bazaar, I have tested the other four and they work fine for me... All are Qakbot samples which detonate and produce configs.

Are you using the latest monitor? What bitness OS are you running on?

from capemon.

Hi @kevoreilly, yes I am using the latest monitor and running it on windows 10x64. I have exception logging enabled and the line which get logged multiple time in the report is CAPEExceptionFilter: Exception 0xc0000005 accessing 0x649000 caught at RVA 0x9b272 in capemon (expected in memory scans), passing to next handler. It doesn't seem to result in a catastrophic failure, however it block the VS debugger. Might it cause the report to be missing some data ? Thanks

from capemon.

Sorry not to get back you here but there are a few things to address. The line you quote is from the analysis log and is something that is irrespective of the log-exceptions option which produces output from the RtlDispatchException hook into the behavior log.

But with this option enabled or not, I have no problem detonating any of these samples in cape. There aren't any exceptions than need action that I can see.

Finally it's well worth mentioning that the VS debugger is not something that capemon is designed to work with. Therefore any issues that exist only in the presence of VS debugger are not capemon issues.

from capemon.

Yes indeed it is irrespective of the log-exceptions sorry for the confusion, was just giving a precision that it was the only big difference in config that I am running. Yes you are correct the detonation are working fine, got initially confused with the fact that the Quakbot samples were giving mixed results in terms of IOCs during some calls. Errors are still raised and the idea was to fix them as it could cause detonation problems for other unknown samples. What I was trying to show in the last comment was that even without the presence of the VS debugger, the presence of those errors message were still there even if it doesn't affect the end result. I understand that this is definitely not a priority.

from capemon.

Would you be able to show me some specific examples of the error messages to see if I can recreate them? I just want to make sure I understand where they are coming from.

from capemon.

Sure no problem, will work to give more details and specifics around the case.

from capemon.

Thanks for taking a look once again. I can get the same result regarding RtlDispatchException with a different ExceptionAddress. How did you manage to associate this with the packer/unpacker part or rather what is the process to associate the ExceptionAddress to an actual feature in Capemon ? I assume this is run specific and require a memory dump ? If I understand correctly, this is part of the malware behavior which have a bad packer so this is not a capemon misbehavior, interesting and sorry for raising a non issue. Would there be anything that could make it more evident to users that the issue is not with Capemon/Capemon features but with the malware itself ? From what I can see RtlDispatchException could mean either a bad hook/feature issue or an error with the malware itself. Is that a fair assumption to make ?

from capemon.

The exception address is variable in its base (the address of the original allocation) but here ends with the constant 0x0068. To associate the address is a question of searching the behavior and/or analysis logs. In this case the NtAllocateVirtualMemory call that alllocates this region can be seen in the behavior log. Alternatively, this will also be a line in the behavior log like:

2023-06-22 10:31:14,354 [root] DEBUG: AllocationHandler: Adding allocation to tracked region list: 0x075D0000, size: 0x41000

I would not want to have to use a memory dump so have endeavoured to try to make all the necessary information available in the web interface, although it does require a bit of knowledge where to piece it together. But the RtlDispatchException hook already looks specifically for exceptions that originate from within capemon's own memory region and should always log this to the behavior log irrespective of the log-exceptions setting to draw attention to exceptions caused by capemon itself.

from capemon.