Comments (10)
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.
Related Issues (20)
- Broken sleep hooks resulting in nonstable (not working) TCP sessions HOT 9
- got 520 error after implement all the rest api HOT 1
- Capemon failed to build with "error C2039: 'Dr6': is not a member of '_CONTEXT' " with MSVC on Windows arm64 HOT 1
- Problem in detonation HOT 3
- Capemon failed to build with "fatal error LNK1104: cannot open file 'atls.lib' " with MSVC on Windows arm64ec HOT 1
- [MSVC][permissive-][std:c++latest] Capemon failed to build with msvc due to error C2362 error2440 on Windows HOT 1
- Crash in yara rule matching seemingly due to compiled rule word-size mismatch HOT 20
- Infinite recursion from GetThreadID in Debugger HOT 2
- Unable to place hook. Unable to hook. HOT 1
- Crash due to wrong prototype for NtAllocateVirtualMemoryEx HOT 2
- InjectDllViaIAT failed in Windows 10 HOT 1
- Crashed in get_full_keyvalue_pathUS HOT 2
- CoCreateInstance hook Win64 exclusion HOT 3
- Detonation failure due to VS2022
- LdrLoadDll BaseAddress always NULL HOT 8
- [Compile] LINK : fatal error C1047: The object or library file 'libyara\lib\libyara64.lib' was created by a different version of the compiler HOT 2
- Capemon Testing Question HOT 2
- Capemon failed to build with fatal error C1047: The object or library file 'F:\gitP\kevoreilly\capemon\\libyara\lib\libyara64.lib' was created by a different version of the compiler than other objects like 'x64\Release\alloc.obj' HOT 2
- Improving IsPeImageRaw() HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from capemon.